Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

CLOCK connected to non global clock pin

Status
Not open for further replies.

axcdd

Full Member level 3
Joined
Jan 29, 2012
Messages
155
Helped
58
Reputation
116
Reaction score
57
Trophy points
1,308
Activity points
2,133
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...
 

mrflibble

Advanced Member level 5
Joined
Apr 19, 2010
Messages
2,724
Helped
679
Reputation
1,360
Reaction score
651
Trophy points
1,393
Activity points
19,551
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. :p

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. :p 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.
 
  • Like
Reactions: axcdd

    axcdd

    Points: 2
    Helpful Answer Positive Rating

axcdd

Full Member level 3
Joined
Jan 29, 2012
Messages
155
Helped
58
Reputation
116
Reaction score
57
Trophy points
1,308
Activity points
2,133
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)
 

mrflibble

Advanced Member level 5
Joined
Apr 19, 2010
Messages
2,724
Helped
679
Reputation
1,360
Reaction score
651
Trophy points
1,393
Activity points
19,551
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...
 

ads-ee

Super Moderator
Staff member
Joined
Sep 10, 2013
Messages
7,827
Helped
1,811
Reputation
3,632
Reaction score
1,773
Trophy points
1,393
Location
USA
Activity points
59,100
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...

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.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top