CLOCK connected to non global clock pin

Hi,

Do you know any good arguments why dont connect clock from ADC (96MHz) (DCO) to non global clock pin in FPGA ?
We got a discussion and our one PCB guy says it doesnt matter cause compiler place it global clock line inside fpga and timequest with creat clock 80Mhz will do all the job, for whole fpga project running at that clock.....

I just run out of my arguments....but he doesnt listen...

Well, if the external clock is connected to a regular non-clock input pin then AFAIK the rest of his argument is rubbish. You can connect the input from the non-clock input to a global clock net, but then the damage is already done (clock skew). That said, if you run that crappy clock input to a PLL, and then let the VCO essentially clean things up for you then you maybe can get away with it. But then again you would probably need a feedback path, and I vaguely recall that only worked well for dedicated clock pins.

Sounds like the PCB guy doesn't want to reroute the clock signal, and his subconscious is generating BS arguments to support his conscious need for NOT WANT REROUTE GNNN.

Anyways, the dedicated clock pins have predictable low delays. Generic fabric will have higher variability in delay. For low speed you can probably get away with it, for high speed not so much. And that < 100 MHz clock probably still is low enough that you can get away with it, but don't quote me on that.

Basically it comes down to cost of rework. Either you reroute inside the fpga fabric, or on the pcb. If rerouting the clock signal on the pcb turns out to be really difficult because of whatever reason, then essentially rerouting it inside fpga fabric may be acceptable.

As a general policy however I'd say try to aim for that dedicated clock input next time when routing a board. Also, the timing analysis tools will have better known delays for that dedicated clock input making timing analysis easier.

So in short: will probably work, makes timing analysis a little harder.

Yes ofc his contrarguments are:

if you use this clock directly in your design (85% resources at xc6-150T) then fitter everything about rouitng-rerouting delays, and data incoming is synchronous to DCO, so clock skew doesnt matter (fitter will do all the work)

Well of course the clock skew matters. The counter argument he should have used was "yes there is clock skew, but for this relatively low frequency the amount of skew is still workable". Your incoming data and the global clock net will have a phase difference. And the amount of phase difference will be a lot less predictable for a generic input than for a dedicated clock input. Lets put it another way. If your input frequency was say 400 MHz his argument would be total BS.

The data + clock arriving at the fpga pins are no doubt in phase (assuming he didn't fsck that one up ). But the routing from the generic IO pad to the global clock net does introduce some skew.

The fitter doing all the work "because it knows about timing" sounds like rubbish to me. Or maybe I am missing something fundamental in which case I'd love to know what I am missing...

mrflibble said:

The fitter doing all the work "because it knows about timing" sounds like rubbish to me. Or maybe I am missing something fundamental in which case I'd love to know what I am missing...

Click to expand...

It is total rubbish, ONLY DEDICATED clock pins are COMPENSATED for the clock insertion delay to internal PLLs. If you aren't using a PLL and the clock is used directly and it's not on any of the dedicated clock pins then you will end up with a variable insertion delay which will affect all the I/O timing that for that clock. You could use directed routing to force the route to be identical from run to run and depending on which pin the PCB guy (is he even an EE?) decided to force you to use. Yes the tools can properly time the path, but you better be absolutely sure of your set_input_delay and set_output_delay constraints are 100% correct and are covering both the rising and falling data (unless you know they are identical).

As the PCB guy is a know-it-all have him create the constraints and the directed routing constraints (not sure what that is called in Altera land) for the clock and data interface from the DCO. Or do the political BS and **** it up and just bandage your design to compensate for the PCB guys I-think-I-know-it-all-but-really-don't-know-crud, and add a 20% margin to all your setup/hold constraints to make sure you don't run into any field problems down the line. Make sure you pessimistically include any DCO clock output jitter plus the source clock jitter in the clock constraint.

Then next time start reviewing the schematic before it goes to layout and demand that you get final approval of any pinout of the FPGA.