Set_input_delay misunderstanding

I'm confused when you say Tco. That refers to a registered output, where this is an input pin.

The two constraints should give almost identical results. The "correct/recommended" way is to use the virtual clock. Why?

1) The main reason is that derive_clock_uncertainty can put different uncertainty between RX_CLK and RX_CLK_Virtual, which is more accurate. Case 1 has the same clock going into the FPGA be the one outside of it. Since is applied between clocks, TimeQuest adds the uncertainty to account for uncertainty inside the FPGA, not as if it were an external clock. The difference might be 20ps(it might be nothing), so it's not overly significant.

2) Another reason for having the virtual clock is pure flexibility. You can do things to that clock and not have to alter the clock inside the FPGA. For example, you're using -clock_fall to say it clocks on the falling edge, but you also could have done "create_clock –name RX_CLK _Virtual -period 20 -waveform {10 20}". This describes a 20ns clock who's first rising edge is at 10ns and falling is at 20n, and repeats from there. This is probably more accurate, but will give you the same analysis as saying it's not shifted but clocked on the falling edge. But let's say it weren't center-aligned, but slightly off-center, say by 1ns. In your example for Case 1), you can't shift the external clock without shifting the internal one. But in case 2) you can do "create_clock -name RX_CLK_Virtual -waveform 11 21" and achieve that. So it allows you to do more. You don't need it in your example, but it's normally a good reason.

3) I also like it because it creates another clock domain that you can do timing reports on. For example, you can do:

report_timing -setup -from_clock {RX_CLK_Virtual} -npaths 100 -detail full_path -panel_name "RX_CLK_Virtual Inputs - Setup"

This will report all the input paths without having to specify all the data pins.

I have seen plenty of times where users do Case 1 and are just fine, so it's not a requirement, but there are some benefits to Case 2 that make it good practice.

The tCo timing was defined for the external device sending the data to the FPGA.

As indicated above, the results were different.

a)Case1: In case the slack was -2.04 (fast-corner) Hold time: from RC_Data0 to FF of shiftregister

slack from Node to node launch clk latch clk relation skew data delay

-2.064 RC_Data0 Data_out[31] RX_CLK RX_CLK 0.000 1.758 2.276

B) Case2 . does not show any violation ( I am not sure how to get the same report to show what is the value of the path now)

This is why I was wondering if I did something wrong as I used the same tCo-min and tC0-max for both cases and

thank you

--- Quote Start ---

Hello:

set_input_delay -clock { RX_CLK _Virtual } -clock_fall -min -$uC_tCOmin [get_ports { RC_Data0 }]

thank you

--- Quote End ---

min delay should be min tCO without minus

BTW I tried your experiment and got funny different results when swapping vir_clk with sys_clk without changing anything else!!!:

case1

create_clock -name vir_clk -period 2.706

set_input_delay -clock vir_clk -max 6 [get_ports data

[*]]

set_input_delay -clock vir_clk -min 5 [get_ports data

[*]]

case2

create_clock -name sys_clk -period 2.706 [get_ports {clk}]

set_input_delay -clock sys_clk -max 6 [get_ports data

[*]]

set_input_delay -clock sys_clk -min 5 [get_ports data

[*]]

Can you post the different results? Do a report_timing with -file "TQ_results.txt" for each one and attach, pointing out the difference? (I wouldn't be surprised if the uncertainty is different, but that's it and should be a small difference)

For source-synchronous, Tco isn't really the correct spec. What you really want to enter is the data pin's skew in relation to the clock. For example, let's say the Data has a Tco of 4ns while the clock has a Tco of 3.5ns. We don't want to enter a set_input_delay of 4ns, but of 0.5ns(Plus any board skew). Conversely if the data has a min Tco of 3ns and the clock is still 3.5ns, then the set_input_delay -min is -0.5. I was kind of thinking that's what you meant when entering Tco and -Min Tco for your values, but wanted to be explicit.

--- Quote Start ---

Can you post the different results? Do a report_timing with -file "TQ_results.txt" for each one and attach, pointing out the difference? (I wouldn't be surprised if the uncertainty is different, but that's it and should be a small difference)

For source-synchronous, Tco isn't really the correct spec. What you really want to enter is the data pin's skew in relation to the clock. For example, let's say the Data has a Tco of 4ns while the clock has a Tco of 3.5ns. We don't want to enter a set_input_delay of 4ns, but of 0.5ns(Plus any board skew). Conversely if the data has a min Tco of 3ns and the clock is still 3.5ns, then the set_input_delay -min is -0.5. I was kind of thinking that's what you meant when entering Tco and -Min Tco for your values, but wanted to be explicit.

--- Quote End ---

If you mean my results then here they are:

sys_clk: fmax 238, io worst slack -1.495, worst core slack +.278

vir_clk: fmax 411, io worst slack -1.475, worst core slack +.278

fmax (I think) is different but strangely io setup slacks are almost same, core slack is same but this funny fmax just doesn't make sense. Moreover 411 is > my request ! I thought fmax covers io path. Am I missing something?

Regarding tCO: you are right that the main idea is to enter data offset relative to clock at input pins but your terminology is not familiar, I have never heard of clock tCO??? tCO is defined for data at external chip boundary(not fpga pins) relative to its clock

When using tCO only we assume clock and data board delays are equal otherwise they are added to tCO equations.

edit: I think what TQ is doing it first it add 20 ps as uncertainty between vir_clk and sys_clk (this accounts for different io setup slack). Moreover it does not include -ve slack when calculating fmax on vir_clk case. in case of sys_clk it takes -1.495 into account and so fmax goes down to 238

Right. I was saying "clock Tco" to help with understanding, i.e. when the clock comes out. You're right that it's probably not defined, and just data in relation to the clock is defined, so it might be more confusing.

So the setup analysis is identical with identical slacks, which is correct.

Personally, I don't like Fmax and avoid using it. It only analyzes paths within a domain, as it's often not clear how to speed up the Fmax of separate clocks. When the clocks look identical, like in this case, we could say they speed up identically, but there are cases where there are transfers between domains that just don't fit into the idea of Fmax. As a result, Fmax just reports when the launch clock and latch clock are the same. (This path is still analyzed correctly in setup analysis, and if it failed it would show up there, so it's not like it's being missed.) So when we use a virtual clock, this path isn't part of the Fmax calculation, but it is when we use the same clock going into the FPGA. Makes sense and I believe correct. (Again, Fmax is not something TimeQuest analyzes and can correctly be done within multi-clock designs. It was added because a lot of people asked for it, especially small CPLD designs. I really think it's worthwhile to ignore Fmax and get in the habit of relying on slack, since this is the real metric for static timing analysis)

uncertainty is only applied between clocks, and it is a limitation that it can't be applied on specific paths. That being said, it models things like clock jitter, which occur at the clock source and are not path specific. So when the user takes a clock that goes into the FPGA, and also says it's used externally, the tool can only apply one uncertainty number. In the end, this is the wrong way to do it, but is legal .sdc and so the tool won't error out. But when the user correctly creates a virtual clock, the tools can show that there will be jitter on the internal clock in relation to this external one, which reduces the requirement by 20ps.

(I was looking to see if this was reported by Check Timing, but it doesn't appear so. That being said, there are cases where the clock on an I/O pin is used for external timing. It's when the clock is sent out the FPGA via an output or bidir pin, and is then used in a set_output_delay to latch the data externally, or a set_input_delay to latch the data back into the FPGA, such as a read from an asynchronous RAM. In this case the set_input_delay uses a clock that is inside the FPGA, and the lack of uncertainty is correct.)

Thank you for all the replies. I still need to digest the information..

Another question related to my example

Case 1

create_clock -period 20 [get_ports { RX_CLK }]

set_input_delay -clock { RX_CLK } -clock_fall -min $uC_tCOmin [get_ports { RC_Data0 }]

set_input_delay -clock { RX_CLK } -clock_fall -max $uC_tCOmax [get_ports { RC_Data0 }]

Adding this constrain removes the slack violation for hold time (shown in previous msg) using case 1 above but I am not quiet sure how these 2 constrains work together (even after reading the TQ guide)

|Data_out[31]} is the receiving FF of the shift register

set_min_delay -from [get_ports {RC_Data0 }] -to [get_registers {RCVR_Part|Data_out[31]}] -6

I want to clarify that the RC_Data0 is also an output to another pin of the FPGA (pin to pin -no logic) . The timing of the out pin is not critical at all. The important timing is the latching of RC_DAT0i to the first FF of the shifregister

Input pins to FPGA Internal logic

---->>RX_CLK -----------------------> shiftReg1_FF-clk

---->>RC_Data0-----------------------> shiftReg1_FF-Q

|

|

| Outpin of PFGA

|------------------>> RC_DAT0

thank you