Best way to force extra pad delay?

If you want to pursue your current approach, try adding a (* keep *) attribute before your inverted signal declarations. This should keep the compiler from optimizing them away:

(* keep = 1 *)

wire invert1;

(* keep = 1 *)

wire invert2;

Jake

--- Quote Start ---

Hi,

I am using TimeQuest, I have two signals CLK and CS_L both driven off the same clock that go to ports on the chip. I have them constrained to force CS_L to be delayed 1.5 nsec from CLK. TimeQuest is unable to do this so I get a timing violation.

I figured an easy way to add delay is to add a couple of back to back inverters so that the routing delay would add 500 to 1000 psec. But when I do this they get optimized away dispite setting Netlist Optimization to OFF for both nets. I also tried instantiating a not cell and turning Remove Redundant Logic Cells OFF but this didn't work either. In both cases it can not find the nets or cells in the assignment editor because they are optimized away already?

I don't want to go through the fuss of creating a clock and then skewing it with a PLL. I just wanted to insert an approximate delay.

Is there a better way to do this.

--- Quote End ---

How critical is your output timing ? Using additional inverter makes your timing depending

on temperature, device speed, power supply and your routing. If you plan to use the FPGA for a product I think you will run into problems.

--- Quote Start ---

How critical is your output timing ? Using additional inverter makes your timing depending

on temperature, device speed, power supply and your routing. If you plan to use the FPGA for a product I think you will run into problems.

--- Quote End ---

If the inserted delay is in a data path and if you analyze timing with all available process/voltage/temperature combinations (three combinations for 65 nm and one hot and one cold combination for older devices), then this should be OK (even though it's not a recommended design practice). I would be concerned about inserting delay in a clock path for any device family and especially for device families older than 65 nm.

The Fitter can insert routing delay in a data path to meet the minimum requirement if "Optimize hold timing" is set to "All paths" in "Fitter Settings". Also enable "Optimize fast-corner timing", especially if you get timing violations with the fast model without this enabled. If hold optimization in the Fitter works well enough for this design, it would be more convenient than inserting LCELLs.

--- Quote Start ---

How critical is your output timing ? Using additional inverter makes your timing depending

on temperature, device speed, power supply and your routing. If you plan to use the FPGA for a product I think you will run into problems.

--- Quote End ---

Could you explain a little bit more how the output signals "CLK" and "CS_L" are generated?

It sounds for me that you try to implement a "source synchronous" interface. Is the output signal "CLK" directly derived from a input clock ? It would also help when you post the part of the SDC file , where you set your constraints.

The Keep directive seems to have worked!!!

I did have hold time optimization setting to all paths but it does not seem to force the necessary routing conditions.

Thank you for your interest.

The interface is just a simple three wire serial interface running at around 25 - 50 MHz. So it is a source synchronous interface. The CLK signal is generated by dividing down the main clock by 2 using simple logic and the CS_L signal is driven out of the state machine. Since it is relatively low frequency it is ok if the CS_L delay varies a bit as long as it is sometime between 1.5 and 10 nsec after the CLK signal. I was going to put the delay in the CS_L path. We are using Stratix II and I run slow and fast models Certainly I agree with you there should be better ways to do this.

Pletz: It would be great to get a second opinion on my constraints if your interested.

# Create clock for IO timing

create_generated_clock -name VDAC_CLK_PIN -source [get_pins $CLKD_VDAC] -divide_by 2 [get_registers $CLKIO_VDAC]

set vdac_clocks [get_clocks $CLKD_VDAC]

foreach_in_collection clk $vdac_clocks {set vdac_period [get_clock_info $clk -period]}

set vdac_max_delay [expr ($vdac_period - 2.0)]# CS timing# setup time = 8 nsec, hold = 0 nsec (being conservative) skew 1 nsec.

set_output_delay -clock VDAC_CLK_PIN -reference_pin VDAC_SCLK_R

-add_delay -min -1.5 [get_ports {VDAC_SYNC_L}]

set_output_delay -clock VDAC_CLK_PIN -reference_pin VDAC_SCLK_R

-add_delay -max $vdac_max_delay [get_ports {VDAC_SYNC_L}]

--- Quote Start ---

The Keep directive seems to have worked!!!

I did have hold time optimization setting to all paths but it does not seem to force the necessary routing conditions.

Thank you for your interest.

The interface is just a simple three wire serial interface running at around 25 - 50 MHz. So it is a source synchronous interface. The CLK signal is generated by dividing down the main clock by 2 using simple logic and the CS_L signal is driven out of the state machine. Since it is relatively low frequency it is ok if the CS_L delay varies a bit as long as it is sometime between 1.5 and 10 nsec after the CLK signal. I was going to put the delay in the CS_L path. We are using Stratix II and I run slow and fast models Certainly I agree with you there should be better ways to do this.

Pletz: It would be great to get a second opinion on my constraints if your interested.

# Create clock for IO timing

create_generated_clock -name VDAC_CLK_PIN -source [get_pins $CLKD_VDAC] -divide_by 2 [get_registers $CLKIO_VDAC]

set vdac_clocks [get_clocks $CLKD_VDAC]

foreach_in_collection clk $vdac_clocks {set vdac_period [get_clock_info $clk -period]}

set vdac_max_delay [expr ($vdac_period - 2.0)]

# CS timing

# setup time = 8 nsec, hold = 0 nsec (being conservative) skew 1 nsec.

set_output_delay -clock VDAC_CLK_PIN -reference_pin VDAC_SCLK_R

-add_delay -min -1.5 [get_ports {VDAC_SYNC_L}]

set_output_delay -clock VDAC_CLK_PIN -reference_pin VDAC_SCLK_R

-add_delay -max $vdac_max_delay [get_ports {VDAC_SYNC_L}]

--- Quote End ---

Hi jstander,

unfortunately I have not so much experience with TimeQuest, but I think your constraints are ok.

Maybe I have an (stupid)idea how to simplify your problem. Are data signals coming out of the "fast" clock domain ? Is latency an issue ?

Kind regards

Pletz

I would be glad to here your suggestion, I know adding inverters is goofy.

Yes the clock driving the logic is 2x the output clock speed. We need to keep minimum latency .

--- Quote Start ---

I would be glad to here your suggestion, I know adding inverters is goofy.

Yes the clock driving the logic is 2x the output clock speed. We need to keep minimum latency .

--- Quote End ---

Hi jstander,

maybe this could work:

1. Resample the clock divided by 2 with a register clock by the higher clock. Add to your data signal(s) also an register and place all FF in the I/O cells of the FPGA. By inverting the divided clock you should always have 1/2 clock period between the active clock edge and your data change. The only problem I could see is whether you got always the same clock phase on the resampled clock?:confused: