Timing Constraint problem on set_input_delay

This one is ugly. There are two ways to do it:

1) The really ugly one is to constrain the D inputs in relation to the A outputs. I wouldn't use reference_pin(I never use reference_pin, as I find the generated_clock can do the same thing and adds more flexibility). So you can do something like:

create_generated_clock -name A0_clk -source [get_pins {*|clk[0]}] [get_ports {A[0]}]

This pretends A[0] is a clock. Then constrain D in relation, i.e.:

set_input_delay -clock A0_clk -max $max_roundtrip_delay [get_ports {D[*]}]

set_input_delay -clock A0_clk -min $min_roundtrip_delay [get_ports {D[*]}]

Where the $oundtrip_delay values are substituted with the max and min delays from A back to the D inputs.

You could then repeat this for each address bit. Note that you'll get timing between all these clocks, so you'll want to do a set_clock_groups to separate the A clocks apart.

The benefit of this is that if the A bits change, the constraints on D will change accordingly. The downside is it's a really complex mess.

Option 2 is to constrain A to a tight window. For example, do something like:

create_clock -name virt_clk -period $period

set_output_delay -clock virt_clk -max $period [get_ports A[*]]

Where period is your clock period. This will create an external virtual clock, so the setup relationship to this will be $period. Your set_output_delay then says there is an external delay of $period already being used up. So when you compile, this will fail timing. Then loosen the set_output_delay just enough that it meets timing. That way you know your A output won't be longer than X. You can also set a min delay on it.

Now that you know the max and min window that A takes to get out, you can then feed that information around and calculate a requirement on D's input. Then go in and constrain that accordingly.

This is hard to do without numbers, so I'm not giving all the details, but hopefully it makes sense. I actually think this is easier to do then the first option.

Thank you very much for your reply.I did timing constraint using a way like the option 2.

I used constraint set_output_delay -clock virt_clk -max 0 [get_ports A[*]] to get the

max tCO of the A.Then,I calculated the max tCO of the D for the SysClk.And using this way,I worried I forgot to change the calculated value if the tCO of A changed.

So then I wanted to use the way with reference_pin.But using the option2 of you,I think there is no necessary to worry about that.

By the way,I used the first way to do timing constraint.And I found that the data path doesn't calculate in the tCO of A.So I thought that there is something wrong

with it.Right?

Option 2 is much more like constraining two FPGAs talking to each other, whereby you have to just constrain one side to what it can do(I find the output side easiest) and then feed that information to the input side.

On your last comment, the datapath certainly needs to be in the calculation, so something went wrong.

No paths exist between clock target "A[0]" of clock "A0_Clk" and its clock source. Assuming zero source clock latency.

Clocks can't go through registers. You have to put a generated clock on the output register:

create_generated_clock -add -name {A0_Clk_reg} -source [get_pins {u_pll1|altpll_component|auto_generated|pll1|clk[0]}] [get_keepers {r_A[0]}]

create_generated_clock -add -name {A0_Clk} -source [get_keepers {r_A[0]}] [get_ports {A[0]}]

(DDR output registers don't have this requirement because the critical path is actually the clock going through the mux select, not the register, which is why most source-synchronous output designs don't do this).

Now, it gets more complicated because you have r_A[0] feeding back into the design, so now it's data and a clock. I can see it getting ugly quickly. I would strongly suggest using Option 2.

Thank you!It is very helpful.

I had no idea to remove the warning "No paths exist between clock target "A[0]" of clock "A0_Clk" and its clock source. Assuming zero source clock latency.".

And you are right,it is very ugly.I will use option 2.

Hi,I encountered another problem.

If a input signal is data and also clock,like LVDS transceiver for video,then there is a problem.

create_clock -add -name {Ext_LVDSClkA} -period 16.666 -waveform {0 7.142} [get_ports {LVDS_A_CK}]

create_clock -add -name {Ext_LVDS_fast_ClkA} -period 4.761 -waveform {0 2.380}

create_generated_clock -name {Int_PCLKA} -divide_by 1 -multiply_by 1 -phase 0 -source [get_pins u_ClkGen|u_Rx0PLL|altpll_component|auto_generated|pll1|inclk[0]] [get_pins {u_ClkGen|u_Rx0PLL|altpll_component|auto_generated|pll1|clk[0]}] -add

create_generated_clock -name {Int_PCLKA_2X} -divide_by 1 -multiply_by 2 -phase 0 -source [get_pins u_ClkGen|u_Rx0PLL|altpll_component|auto_generated|pll1|inclk[0]] [get_pins {u_ClkGen|u_Rx0PLL|altpll_component|auto_generated|pll1|clk[1]}] -add

create_generated_clock -name {Int_IOCLKA} -divide_by 2 -multiply_by 7 -phase 45 -source [get_pins u_ClkGen|u_Rx0PLL|altpll_component|auto_generated|pll1|inclk[0]] [get_pins {u_ClkGen|u_Rx0PLL|altpll_component|auto_generated|pll1|clk[2]}] -add

set tCO_max 0.5

set tCO_min -0.2

set_input_delay -add_delay -clock [get_clocks {Ext_LVDS_fast_ClkA}] -max [expr $tCO_max] [get_ports {LVDS_A_D[*]}]

set_input_delay -add_delay -clock [get_clocks {Ext_LVDS_fast_ClkA}] -min [expr $tCO_min] [get_ports {LVDS_A_D[*]}]

set_input_delay -add_delay -clock [get_clocks {Ext_LVDS_fast_ClkA}] -clock_fall -max [expr $tCO_max] [get_ports {LVDS_A_D[*]}]

set_input_delay -add_delay -clock [get_clocks {Ext_LVDS_fast_ClkA}] -clock_fall -min [expr $tCO_min] [get_ports {LVDS_A_D[*]}]

set_input_delay -add_delay -clock [get_clocks {Ext_LVDS_fast_ClkA}] -max [expr $tCO_max] [get_ports {LVDS_A_CK}]

set_input_delay -add_delay -clock [get_clocks {Ext_LVDS_fast_ClkA}] -min [expr $tCO_min] [get_ports {LVDS_A_CK}]

set_input_delay -add_delay -clock [get_clocks {Ext_LVDS_fast_ClkA}] -clock_fall -max [expr $tCO_max] [get_ports {LVDS_A_CK}]

set_input_delay -add_delay -clock [get_clocks {Ext_LVDS_fast_ClkA}] -clock_fall -min [expr $tCO_min] [get_ports {LVDS_A_CK}]

In the TimeQuest Timing Analyzer tool,the launch clock of LVDS_A_CK is Ext_LVDSClkA not Ext_LVDS_fast_ClkA.I don't know why the launch clock is not Ext_LVDS_fast_ClkA.

Hey Rysc,

In that example you gave using number 2. How do you figure out the period for the virtual clock? Say for example I have a flash memory bust (address and data lines and control lines) I need to constrain. If I constrain them to a virtual clock period how would I go about figuring out what that period needs to be?

Your virtual clock is almost always the same period as the clock latching the data inside the FPGA. Basically your virtual clock says when data is launched. So if your virtual clock has a period of 10, it will launch data at 0, 10, 20, etc.

(If you do a "set_input_delay -clock_fall -clock virtual_clock..." then your describing another register launching at 5,15,25, etc.)

The key it to run report_timing -setup and -hold on the inputs to see what the setup and hold relationships are and that they make sense. They are based on the relationship between your external virtual clock and the internal clock latching the data.

Ok. So if I have a flash device that has no clock, but only address, data and some control signals (OE, CS, WE etc...) how do you constrain that? I am starting to understand how to constrain an interface with a clock. You basically tie your data, address and other signals to the clock that drives say the external memory device like sdram. So it seems like from what I've read, you just make sure that all of the non-clock signals meet timing relative to the sdram clock.

I'm confused though on my example because I don't have a clock going to the flash part and the setup and hold times for data and address are all relative to control lines. So for example the setup and hold times for reading data is relative to OE control line and writing data setup and hold times for address and data are relative to WE (write enable). Depending on whether you write or read from the device determines which control lines are of interest. I'm really trying to understand the time constraints world better so I'm interested to know the proper way to constrain an interface like this where there is no real CLOCK.

From studying your other posts, handbooks and the cookbook for timequest it seems like if you have a couple signals or outputs and you want to know if they meet timing relative to ONE other signal you can make this one other signal a virtual clock. Then check the setup and hold times of the group of signals against the virtual clock which ends up comparing a group of asynchronous signals against a single signal of interest. I hope this isn't confusing, but basically I have a nios ii design that talks to a flash part and in trying to learn constraints/timing better I'm trying to constrain my design. Since there is no clock to the flash part I don't know how to model the virtual clock. Same thing with a UART. How do you constrain a uart since there is no clock, I think it would be the same idea I just need some guidance.