cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
kendrick
Adventurer
Adventurer
5,725 Views
Registered: ‎01-21-2012

Basic Timing Constraints Question

We are trying to use a Kintex-7 to drive a 1GSPS DAC. The data is presented to the DAC on a 500MHz DDR 16-bit bus with the 500MHz clock strobing in the data on the rising and falling edges.

 

In order to generate the 500MHz clock, we use a clock wizard to multiply an external 250MHz source by two. We have named this 500MHz clock net "dacClkGen" in the VHDL code. The PAD for the external 250MHz clock is "CLK_EXT_P." The pads for the 16 bit data lines are "DAC_DP*", and the output 500MHz clock pad to the dac is "DAC_DCLKP." DAC_DCLKP is connected directly to "dacClkGen." 

 

If we are reading the datasheets correctly, the output clock's rising edge must be 300ps before the positive edge data is valid, and the falling edge must be 350 ps after the falling edge data is valid.

 

We have the following constraints in our .ucf file:

 

NET "Inst_DAC_Data_Generator\dacClkGen" TNM_NET = "dacClkGen";

NET "DAC_DP*" OFFSET = OUT 350ps AFTER "CLK_EXT_P" RISING;
NET "DAC_DP*" OFFSET = OUT 300ps BEFORE "CLK_EXT_P" FALLING;

 

The problem is that during the map phase, I am given a warning stating that the net "dacClkGen" has been optimized away, so my constraint is ignored. Is there a way to force the dacClkGen net to remain so that these constraints won't be ignored? Or is there a better way to enter these constraints? 

0 Kudos
2 Replies
austin
Scholar
Scholar
5,724 Views
Registered: ‎02-27-2008

k,

 

I think you would be better off to use a clock forwarding style output (DDR output flop) for your clock, so it is precisely aligned with the data, and then align the clock by using pcb traces to adjust for the 300 to 350ps delays.  This will guarantee timing over all process, voltage and temperature in a way that will be difficult, if not impossible to accomplish in the FPGA device.

 

If you must do the delay in the FPGA device, look at using the phase shift features of the MMCM.  Using place and route to provide 300 ps of delay is not going to be very satisfactory (in my opinion).

 

Austin Lesea
Principal Engineer
Xilinx San Jose
0 Kudos
gszakacs
Instructor
Instructor
5,684 Views
Registered: ‎08-14-2007

The problem is that during the map phase, I am given a warning stating that the net "dacClkGen" has been optimized away, so my constraint is ignored. Is there a way to force the dacClkGen net to remain so that these constraints won't be ignored? Or is there a better way to enter these constraints?

 

There is no way at all to enter the constraints you want.  Basically, source synchronous logic must work

by design - not by constraint.  But if you want a small synopsis of your constraint failure, it starts with

using an output net in a TNM_NET constraint.  TNM_NET looks forward from the named net to any

clocked loads (FFs, BRAMs, DSPs, etc.) and creates a group from those instances.  Going forward

from an output net there is nothing inside the FPGA to create this group from, so the constraints that

use the group are ignored.

OFFSET OUT constraints are always relative to an input clock at the FPGA pad.  The only reasonable

OFFSET OUT constraint uses the AFTER keyword, OFFSET OUT BEFORE makes no sense.  This

constraint is to allow you to put a cap on prop delay through the FPGA from clock in to data out.

What you really wanted was some sort of output skew constraint, and that doesn't exist.

 

There is a Timing Constraints blog in the forum blogs section.

 

-- Gabor

-- Gabor
0 Kudos