Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎01-24-2015

Constraint of output relative to input clock





What I am trying to do is illustrated above.

There is a clock that is output from an external device that acts as a timing reference so that the FPGA can meet setup and hold times relative to that clock. What I am struggling with is to figure out what the timing constraints should look like in this situation.


clock period = 10 ns

t_setup = 2 ns

t_hold = 0 ns


FYI, the IC I'm trying to interface with is a AD9915 DDS. It outputs a sync clock that is generated from the internal DDS clock running at much higher frequency using a PLL. The DDS IC then outputs this clock to let upstream devices know when data inputs to the DDS can be updated. The input to the DDS is data only, there is no clock output from the FPGA.


When I try to add an offset constraint directly, i.e.

TIMEGRP "tnm_outs" OFFSET = OUT 5 ns AFTER "clk_in";

the result is that clock path and datapath delays are too long to meet the constraint.


I made a little toy project to isolate the issue. What I see is that even with a FF packed into the IOB, the offset out constraint gives me a timing violation. ISE tells me that the clock path delay is 4.653 ns and the data path delay is 4.301 ns. Timing analysis output from this experiment is attached.


Based on this, I think this is not the right approach. How do the constraints need to look like in this situation?


Thanks a lot for any help in advance!



0 Kudos
1 Reply
Registered: ‎01-23-2009

So the tool is telling you (pretty clearly) that you cannot bring a clock in and get an output out in 8ns using this architecture. This has nothing to do with the constraints - in fact your constraints have no impact on this path. All the resources used here (input bufer, BUFG, OLOGIC, output buffer) are all in fixed locations (based on your LOC constraints) and used dedicated routing resources.


So, where do you go from here.


One thing to recognize is that the clocking architecture you are using is quite slow - there is a lot of insertion delay getting to and going through the global clock network. It is (at least partly) for this reason that all FPGAs have some kind of clock management cell (DCM, MMCM, PLL) that can do "clock deskew" - this removes some (but not all) of the clock insertion delay of the clock. This will reduce your clock insertion delay, and hence speed up the total path.


The other thing to consider is your I/O standard. All Xilinx I/O pads can be programmed for different I/O standards, different drive strengths, and different slew rates. The delay of the pad is very highly affected by these choices; you can get better timing using faster drive strengths and slew rates (at the cost of power, signal integrity and noise).


I also want to point out that 8ns is probably not enough - you have board delays from the external device to the FPGA (on the clock line) and more board delays on the way back (on the data lines). So the FPGA needs to take no more than 8ns-(the board delays)...


So, in the end, this is a pretty tough architecture for an FPGA. With the above changes you should probably be able to meet your 10ns period, but you will be pushing the limits of performance of this type of interface architecture...



Tags (1)
0 Kudos