Understanding Recovery and Removal in TimeQuest

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

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!

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)?

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.

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?)

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.