Understanding Recovery and Removal in TimeQuest

[Altera_Forum]

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

[Altera_Forum]

Thank you for sharing. It is useful.

[Altera_Forum]

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

[Altera_Forum]

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

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

Hello Rysc: 

 I have a DK-DSP-3C120N kit.Recently,I'm struggling with the DDR2 HP Controller under the direction of AN517(Using High-Performance DDR, DDR2, and DDR3 SDRAM With SOPC Builder).The design is targeted to the Cyclone® III EP3C120F780C7 Kit.  In this example,the SOPC system contain a Half-Rate DDR2 Controller working at 150MHz(altmemddr_auxfull),the PLL of the controller simultaneously generate a 75MHz output clock(altmemddr_sysclk) which been used as SOPC system clock.  After compilation,I got three critical warning,cause by JTAG.The TimeQuest report negative slack(-2.435) in Summary(Removal) of altera_reserved_tck. The Top Failing Paths (Removal:altera_reserved_tck) is this: Slack:-2.435 From---altera_reserved_tck  To-----pzdyqx:nabboc|pzdyqx_impl:zdyqx_impl_inst|FNUJ6967  I've tried to slow the DDR2 clock down to 133.333MHz,the NIOS clock down to 66.667MHz,but the slack value still negative.  I lose my head of this because I've constrained the JTAG using the templet:# JTAG Signal Constraints constrain the TCK port create_clock -name tck -period 100.000 [get_ports altera_reserved_tck]# Cut all paths to and from tck set_clock_groups -asynchronous -group [get_clocks altera_reserved_tck]# Constrain the TDI port set_input_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tdi]# Constrain the TMS port set_input_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tms]# Constrain the TDO port set_output_delay -clock altera_reserved_tck -clock_fall 1 [get_ports altera_reserved_tdo]  I didn't know what's wrong with it. Can you help me? Thank you very much!

[Altera_Forum]

The Top Failing Paths (Removal:altera_reserved_tck) is this: 

Slack:-2.435 From---altera_reserved_tck  To-----pzdyqx:nabboc|pzdyqx_impl:zdyqx_impl_inst|FNUJ6967 Can you list the Source Clock and destination Clock? Just taking a guess, it's the same clock and probably the jtag clock. Also, look at the Clock Skew in the Statistics tab. The pzdyqz hierarchy is something you didn't create. Are you using any Opencore Plus IP(IP that you don't have a license for and a time-limited/tethered version is created)?

[Altera_Forum]

Thank your help! 

Here is the .txt file about the clock source,and another TimeQuest warning to the cpu.sdc file---which was autogenerated by the SOPC Builder.

[Altera_Forum]

1) The From Node is the same as the clock. Is this an input path? 

2) The To Node, I believe, is for OpenCore Plus. Can you go to the Compilation Report, Analysis & Synthesis and look at the IP section. It tells how each core was licensed(Licensed, Opencore or Opencore Plus). I've seen cases where the OpenCore Plus inserts logic with gated clocks that has hold violations. At the end of the day it was something we ignored and everything worked fine, but worth complaining to the generator of the core(if that's it.) By the, way do a "report_timing -removal -to pzdyqx:nabboc|pzdyqx_impl:pzdyqx_impl_inst|FNUJ6967 -npaths 20 -detail full_path -file "removal.txt" THen add the removal.txt to this, and I can take a look at it. Bottom line this is code you can't modify and do much for, so it's probably something you can ignore. I know that's not a "good feeling", but if it's just the opencore plus stuff, then it goes away once you get the license. (And under Assignments -> Settings -> Fitter, do you have Optimize Hold Timing set to All Paths, and Multi-Corner Optimization checked?)

[Altera_Forum]

Hello,Rysc: 

The altera_reserved_tck is the clock of JTAG.It's a reserved signal of altera which not emerging in my design. Thank you for your analysis,I'm sure this warning was caused by the time limited mechanism.

[Altera_Forum]

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]

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]

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]

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]

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.