I think a number of users don't fully understand Recovery and Removal analysis, so I put this together. I think it's important to not only understand what analysis TimeQuest id doing, but to make sure your design's asynchronous resets correlate with that analysis. Hopefull this is of some help...

Thank you for sharing. It is useful.

Hello, I'm new here. Thank you for your posting. I'm carefully reviewing the document above. I'm confused from the outset. So please help me to understand. On page 1, I read: we have two clocks with the same period, 10ns. this results is a setup requirement of 10ns, and a hold requirement of 0ns. Let's focus narrowly on the setup requirement at first for my benefit. When I think of a "setup requirement", I envision it applying to a D flip-flop with a clock input. The setup time then is the minimum time the signal on the D input must be static prior to the registering edge of the clock input. Given this, I'm not quite sure how to follow you or conclude as you do in the italicized excerpt above. I hope you can bear with me. I appreciate your patience. :)

Hi all, I just happened to read this doc. I appreciate Rysc's efforts to stimulate discussion in this area but it is far from clear and current consensus. The central theme is very simple. every register specifies a timing window around its clk edge at which its input D must not change. This is common sense as the clk edge then wouldn't "see" what to read(read pre-edge or post edge state or end up in nonbinary state). The part before edge is setup time and that after is hold time. Setup or hold are no different in nature as they are just part of this timing window, however, avoiding their violation is as different as their relation to clk edge! Another important part of our scenario is the source of signals. In RTL chain we need to control things from the source point. this could be the pins or the internal sourcing register. We need to know how the source "sees" setup/hold of destination register from its perspective and then using delays and knowing the fact that there is always finite source Tco, then timing of dest. register can be controlled. In short: setup is avoided by not exceeding fmax(in fact setup determines fmax). hold is avoided by inserting a bit of delay on Q-D than that of clk or avoiding gated clocks. I usually leave it to the tool but user remedy for setup violation: pipeline more i.e. breakup logic into smaller clouds. reregistering is not efficient. or put less delay on Q-D or on reset. user remedy for hold violation: insert more delay on Q-D or reset. Sensible designers register the reset in its clock domain. This was discussed nicely and thoroughly in a previous thread. It is also common to target zero or negative hold(source perspective). Remember hold time is more vulnerable to violation as source data changes shortly after source clk edge(Tco)... *if your clk is even few Hz, hold time violation can occur if not catered for. but setup violation is impossible unless the flipflop is made in the kitchen

To Malachite's question, you're absolutely right, and that's what gets taught in school. We tend to call that the micro-setup(uTsu) of the register, along with the other micro parameters(uTh, Tco). Those numbers all show up in TimeQuest's calculations. The problem with them is they only specify that the latch register will fail(go metastable) if the data transitions in that tiny micro-setup/hold window. It's really not that useful information from a system perspective. (I see people do timing simulations and think it's also doing static timing analysis, where they don't realize that if the data is so late that it doesn't violate their uTsu/uTh of the register, then the data is just in the next window and the simulator will never issue a warning. Yes it's different functionality, but it really needs to be captured as an issue by static timing analysis). Anyway, yes you're right, and now forget that definition. : ) From a system-level, a source register launches data, say at time 0ns, and the destination latches it, say at time 10ns. So for your system to operate, the data needs to get their in time to be successfully latched. This includes meeting the uTsu, it includes clock delays to both the source register and destination register(i.e. clock skew) and your data delay. In other words, the setup requirement is this macro-level view of the transfer, not a characteristic of the registers by themselves.

Hi Rysc, Since I posted my thoughts I will try to remove some confusion. Essentially it is the register setup/hold that is all there. Altera calls it micro sometimes or reg Tsu/TH ...xilinx calls it reg Tsu/TH. I believe the term micro is very misleading. Anyway, the central point in fulfilling timing is that the source of signals(D,clk) should not violate timing of destination register. If the interest is at input registers then we are only intersted to know the reg Tsu/TH at pin perspective(what you call it macro...). The internal(micro or reg ...) are irrelevant practically here. The relation is this: Tsu(at pin) = reg Tsu + data delay -clk delay TH(at pin) = reg TH -data delay + clk delay i.e. the delays cause a shift of timing window but can't change its length Thus you can have TH(at pin) zero or negative implying nothing more than that data is forced a good delay by the time it reaches the register compared to clk. Devices with zero or negative hold are very attractive because otherwise TH can be violated readily as data from source changes after launching edge by a whisker(1 or 2 ns). The same applies internally but here instead of pins we have the source register responsible to fulfil timing of destination with respect to the next latching clk edge. It is the tool that looks after the values, not the field designer. At the output register, the designer takes over but needs to know the Tsu/TH of extrnal device(at device pins or preferrabley at fpga pins) then controls Tco(or delays) at fpga. Hope this is clear

Understanding Recovery and Removal in TimeQuest

15 Replies

Altera_Forum
Honored Contributor
15 years ago
Hi,

So how do we get rid of this altera jtag (USB Blaster) problem? I am using NEEK, Quartus II 10.0sp1 Web Version and was trying to do NiosII Hardware Development Tutorial.

this is the .sdc# Update -period with clock period (in nanoseconds) of the clock driving the fpga
create_clock -name sopc_clk -period 20 [get_ports PLD_CLOCKINPUT]
# Setting LED outputs as false path, since no timing requirement
set_false_path -from * -to [get_ports LEDG
[*]]
# Constraining JTAG interface# TCK port
create_clock -name altera_reserved_tck -period 100 [get_ports altera_reserved_tck]# from altera knowledge support# create_clock -period "100.000 ns" -name {altera_reserved_tck} {altera_reserved_tck}# Clock constraints# create_clock -name "MCLOCK" -period 20ns [get_ports {altera_reserved_tck}] -waveform {0.000ns 10.000ns}# Automatically calculate clock uncertainty to jitter and other effects.# derive_clock_uncertainty
# cut all paths to and from tck
set_clock_groups -exclusive -group [get_clocks altera_reserved_tck]# constrain the TDI port
set_input_delay -clock altera_reserved_tck 20 [get_ports altera_reserved_tdi]# constrain the TMS port
set_input_delay -clock altera_reserved_tck 20 [get_ports altera_reserved_tms]# constrain the TDO port
set_output_delay -clock altera_reserved_tck 20 [get_ports altera_reserved_tdo]
Altera_Forum
Honored Contributor
12 years ago
Sorry for reviving the old thread but I have some questions after going through the useful document. When we talk about recovery violation, are we talking about when reset is asserted (i.e, ensuring all dest registers get reseted together) or when the reset is de-asserted (i.e, all the dest registers get out of reset)?
Altera_Forum
Honored Contributor
12 years ago
I've only seen people care about the reset de-assertion, but if your source is synchronous for both and you meet timing, then both work. Often designers create an asynchronous assert/synchronous de-assert circuit, which will then only be synchronous on the de-assertion. I talk about this in the TimeQuest User Guide on alterawiki.com
Altera_Forum
Honored Contributor
12 years ago
Thanks Rysc.

If I have a synchronous reset signal with high fanout that is failing timing, will changing this to asynchronous reset help in timing closure?
Altera_Forum
Honored Contributor
12 years ago
it might or might not. If it does then it is due to sheer probabilty of fitting. In both cases there is path to be respected. In fact with asynchronous ports being used I expect less logic be used and this becomes substantial for high fanout reset.
May be better you approach reset with less fanout or replicate it manually. The notion of reseting every register is old fashoined and you better not apply reset when not needed for example data paths that can have any value at reset release need not have reset. If you do remove reset then don't just comment it out from top of process as this will lead to latches. Instead remove it and rewrite a process without reset.

Forum Discussion

Understanding Recovery and Removal in TimeQuest

15 Replies

Recent Discussions

Docker image for Quartus Pro 26.1 missing ?

Quartus did not start

Timing analysis - long combinational path

timing violation fix

Issues with downloading