Hello: new to sdc constrains I have 2 cases to constrain my serial data coming in and trying to understand the differences Case 1 has been done in previous projects right or wrong but shows no timing violation. In my project I am getting a small negative slack for hold time (on Fast timing) Case 2 shows no timing violation (positive slack) This case was created based on reading the Timequest user guide. However, I don't understand how RX_CLK relates to the virtual clock It seems that the total tCo in one case should be different to the other on default relationships?? Which one is correct? For me, case 1 ties directly to the clock input on the FPGA and the tCo should account for board delays , margin and the spec tCo of the device. FPGA input is RX_CLK -Pin RC_Data0- pin tComin and tComax are defined RC_Data0 should be clocked into a shift register in the RX_CLK clock domain 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 }] Case 2 create_clock -period 20 [get_ports { RX_CLK }] create_clock –name RX_CLK _Virtual -period 20 set_input_delay -clock { RX_CLK _Virtual } -clock_fall -min -$uC_tCOmin [get_ports { RC_Data0 }] set_input_delay -clock { RX_CLK _Virtual } -clock_fall -max $uC_tCOmax [get_ports { RC_Data0 }] thank you

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

Run the report_timing I showed above for both cases and determine what's different. (Change it to a hold analysis if that's where the difference is...)

--- 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.

Set_input_delay misunderstanding | Altera Community

23 Replies

Altera_Forum
Honored Contributor
12 years ago
so in short, replacing an input clock with virtual clock does the following:

(1) adds default 20 ps as uncertainty between these two clocks
(2) ignores input path for fmax analysis but not for slack

This last item is really risky since it gives false pass on fmax.

The advantage of virtual clock apart from this uncertainty issue is that you can shift it as appropriate relative to actual clock and use it as reference instead of say modifying delay values.

I personally don't like the idea so far and would rather compute my delays. One such case raised here was when input data is clocked by a clock from fpga (opposite direction) then I can either make my calculations for delay to account for that or keep figures as they are but use virtual clock that is imagined to come with data at appropriate phase. I see this as confusing dual inverse and unnecessary approach.
Altera_Forum
Honored Contributor
12 years ago
where is that hold slack problem?
The other issue is that the tCO you use relative to falling edge. Is that because the external device gives you tCO relative to that edge?
Altera_Forum
Honored Contributor
12 years ago
I don't consider item 2) very risky. If the user is only looking at the Fmax Summary and ignoring the Setup Summary in red right next to it, that's user error. If they're only looking at the text reports and skipping setup summary(which might be easier to do), that's still user error.
You don't have to shift the clock and have the option to just modify delay values, but when the external clock is truly shifted, it's more accurate to shift the clock in your constraints then to try to figure out how to modify the delays. It can be done either way, but it provides an option.
For the case of input data clocked by clock from FPGA, using the clock coming out of the FPGA is absolutely necessary. The FPGA sends a clock out, and the delay to get out of the FPGA can vary compile to compile. This delay is then used as part of the calculation for the data coming back. If you couldn't do this, you'd have to modify the constraints after every compile to account for what happened during the fit. (Most likely the delay isn't changing, but I have seen users send out clocks that are on local routing, in which case it does vary a decent amount and this methodology is required.)
Altera_Forum
Honored Contributor
12 years ago
But why the tool would not report fmax with virtual clock in the same way as system clock, after all virtual clock is just imaginary to HELP, is't that hard to be consistent? I really think some people up there just make simple things complicated
Altera_Forum
Honored Contributor
12 years ago
What if you're virtual clock is not the same frequency as the internal clock, or what if it has an offset? For example, if they're both 10ns clocks but the external clock is offset 2.5ns, then your setup relationship is 7.5ns and hold is -2.5ns. In this case, if we have positive slack on the paths, say 2ns, would we report the Fmax as 125MHz? Are we assuming the external clock also runs at 125MHz? Does it have a 2.5ns shift or a 90 degree shift? So in trivial cases Fmax can assume what the external clock does, but in non-trivial it can't. Rather than deciding to include cross-clock domain paths depending on how complicated they are, it's more straightforward to consider Fmax as only within a domain. In the end, I think Fmax should have never been reported, as it's trying to over-simplify something that is often more complicated. (And on the designs that really only have 1 domain, or no cross-domain paths, slack is not difficult to understand at all either, so Fmax isn't really simplifying much...)
Altera_Forum
Honored Contributor
12 years ago
vlsi9, I didn't fully follow your post, but the set_min_delay requirement is a direct override of the hold relationship. Here's the way I think of it:
1) The set_input_delay constraint describes a circuit. It says there is an external register, it says what clock drives that register, what FPGA port it drives, and what the max and min datapath delays are from that register to the FPGA.
2) TimeQuest now sees a register->register path. It sees a launch and latch clock and determines a setup and hold relationship.
3) If you add a set_min_delay assignment, it overrides the hold relationship on that register to register path. But the datapath delay you had in your set_input_delay is still used.
For example, if you have a 10ns clock in the FPGA and 10ns external clock(no shifts), and do:
set_input_delay -min -3.0 -clock virt_clk [get_ports din]
You now have a 0ns hold requirement. The external datapath delay is -3ns, which means inside the FPGA the datapath must be at least 3ns longer than the clock path in order to avoid a hold violation. If you then do:
set_min_delay 1.0 -from [get_ports din]
You've now overriden the hold requirement of 0 and made it 1ns, so the over the whole path, the data must be 1ns longer than the clock. Since externally the datapath delay is -3ns, then inside the FPGA the datapath must now be 4ns longer than the clock.

For the second part about the input port to output port being a don't care, first check if it's being analyzed by doing a report_timing between them. (I can go into details of when or why it would, but the main thing is that you don't want it). If it is being analyzed, or if you just want to make sure it's ignored, just add
set_false_path -from [get_ports RC_Data0] -to [get_ports {RCDataout{31]}]
Of course, what you're doing is just loosening the hold requirement by -6ns, which you may prefer over cutting it.
Altera_Forum
Honored Contributor
12 years ago
--- Quote Start ---
I think Fmax should have never been reported, as it's trying to over-simplify something that is often more complicated.
--- Quote End ---

slack is only part of the overall story, consider other cases like io speed violation and this case below which will certainly fool anyone focussed on slack only:
A module was failing in some builds. The design was timing clean regarding setup or hold slack and so suspicion fell on some wrong multicycle path. After painful efforts it turned out that though every multicycle path was correct but in some builds the maximum delay caused by multicycle was causing minimum pulse width violation due to a counter forced to zero at some point. This was not reported as slack failure and the integration team insisted the design was timing clean but then I looked at the report and found out restricted fmax.

Fmax can cover slack and all others and thus it is far more useful concept.
Altera_Forum
Honored Contributor
12 years ago
The Minimum Pulse Width report that should catch that. It may show up in Fmax secondarily, but Fmax wasn't designed to catch anything that wouldn't be caught in another report. More importantly, there are many cases that slack can cover that Fmax can't. Obviously hold violations are a good example, but complex domain crossings are too. I don't mean to argue so much, but I've seen users get in the habit of looking at Fmax and ignoring the other reports, which means they're often not looking at the full analysis. If they use Fmax because they're more comfortable with it and their main problems are within a domain, no problem at all. The main thing is they realize its limitations.
Altera_Forum
Honored Contributor
12 years ago
--- Quote Start ---
The Minimum Pulse Width report that should catch that. It may show up in Fmax secondarily, but Fmax wasn't designed to catch anything that wouldn't be caught in another report. More importantly, there are many cases that slack can cover that Fmax can't. Obviously hold violations are a good example, but complex domain crossings are too. I don't mean to argue so much, but I've seen users get in the habit of looking at Fmax and ignoring the other reports, which means they're often not looking at the full analysis. If they use Fmax because they're more comfortable with it and their main problems are within a domain, no problem at all. The main thing is they realize its limitations.
--- Quote End ---

Thanks Rysc. It is ok we are discussing and not arguing.
hold violations are reported as part of restricted fmax (not traditional fmax, purely historical reasons).
io toggle violations and minimum pulse/period violations as well are covered by restricted fmax.
so is fmax itself and any slack in register timing
so "restriced fmax" is final figure of merit.
for multiple clock domain naturally you look at each domain separately.
Altera_Forum
Honored Contributor
12 years ago
Hold violations are restricted Fmax? I haven't seen this, but not sure how it would work. A hold violation within a domain basically means it can't run at any rate, i.e. even 1 Hz. So not sure how it would show the magnitude of failure without a negative number or something strange like that. For multiple clock domains, it's the path between domains that are of concern. Does that path get reported in both domains, so if all paths within domain A make timing and within domain B make timing, but the path from A to B fails, then both domains get reported as failing? That could work, but be confusing. The problem with Fmax is that it assumes a different frequency. For example, a clock with a 100Mhz constraint might get a report that it can run at 120MHz. But for interactions with other domains, how do they scale together? Most cases probably could be worked, when a domain is an integer multiple of the first, but there are a number of corner cases that just don't work that way. Another example might be the two registers within a domain when sampling something asynchronously. The clock period might be 5ns, but the user has a set_max_delay of 4ns on that path to give it 1ns for the metastability of the first register to settle out. If Fmax is reported as being 250MH(4ns), is it assuming this set_max_delay is still 4ns from launch to latch, in which case there is no more metastability protection? Or does it scale to 4/5ths of the previous requirement, to 3.2ns? Or does it keep it's distance from the previous latch edge, and stay at 3ns? Technically, the last one is what I would want, but there's nothing in the constraint that says that.
Slack, on the other hand, looks at your clock requirements(and other constraints) and says whether the paths pass or fail and by how much, but it doesn't assume all paths will scale together, i.e. it doesn't report a frequency different than what you asked for. It's this assumption that Fmax does that can get tricky.
We're definitely going down the rabbit hole of corner cases, but to fully rely on a methodology it needs to cover all the cases. And even with slack, I get users asking asynchronous hand-shaking corner cases that I don't think it can handle, but that's another thread...:)

Forum Discussion

Set_input_delay misunderstanding

23 Replies

Recent Discussions

USB-BlasterII mounts as "USB-Blaster variant"

Quartus Dark Theme on Linux - Solution

Error(23098) when using IPM_IOPLL on Agliex 7

Quartus 13.1 License

Highlight similar instances of a selected word fails when scrolling