Recovery errors with Time Quest Timing Analyser

Is the signal synchronous to the registers it drives? Meaning, if you do recovery/removal analysis on it and look at the relationships, does that match the clocking in hardware? If it's truly coming in from an asynchronous source, then you should cut timing on it, as there's no point in trying to meet timing requirements that aren't real.

If it is a real requirement, is it on a global or not? You should see clkctrl in the data path if it's on a global. It will also be listed in the Global Signals report.

As for the Assignment Editor, you can make multiple assignments to the node. I'm not really sure what problem you're seeing.

Hi Rysc

It is a reset Strobe signal , I feel its an asynchronous signal

The Time Quest shows that there is a slack on this signal (In Recovery issues of Timing Analyzer)

when i used the "report_timing" on this violation it reported me as follows

report_timing

-from_clock {inst_PLL_Clk_ADC|altpll_component|auto_generated|pll1|clk[1] }

-to_clock { inst_PLL_Clk_ADC|altpll_component|auto_generated|pll1|clk[1] } -from {If_GetData_GX_ADC:inst_If_GetData_GX_ADC|GestionReset:inst_GestionReset|Rst_RecupData_n_o} -to {If_GetData_GX_ADC:inst_If_GetData_GX_ADC|RecupData:inst_RecupData|Fifo_Streaming:inst_Fifo_Streaming|dcfifo:dcfifo_component|dcfifo_b2i1:auto_generated|altsyncram_9h31:fifo_ram|ram_block5a0~portb_address_reg0} -recovery -npaths 10 -detail full_path -panel_name {Report Timing}

Regarding the Assignment editor i am doing this for recovery removal(as you suggested) -- Please see Rst_ADC_Board_o pin J10

Thank you for the help

By far the most effective way to avoid these timing errors is to remove its burden on timing. Reseting a mass of registers unnecessarily should be avoided. Paths like data for example usually need no resets.

Alternatively move reset to synchronous but this only moves the burden away from recovery/removal to tSU/tH but may work

--- Quote Start ---

Alternatively move reset to synchronous but this only moves the burden away from recovery/removal to tSU/tH but may work

--- Quote End ---

Do you mean "To synchronize the asynchronous reset signal using a double flop synchronizer"

I have attached a image file of what i understand by your saying

Just to be sure, did you look at recovery/removal in this document:

http://www.alterawiki.com/wiki/timequest_user_guide

(I wrote another one called Understand Recovery/Removal, but this one is more up to date.)

My initial question is about how the system works. TimeQuest analyzes asynch reset signals with synchronous timing, which is a good thing. But if the signal is coming in from a truly asynchronous source, say a pushbutton or out of a device on another clock domain, there is no reason to have TQ try to time it, since it's not a real analysis. You would need to enter an asynchronous assert/synchronous de-assert circuit.

- Synchronizing it with a double-flop synchronizer could also be used to get it into the main clock domain, but you lose the asynchronous assert capabilities. Quite often that is not a big deal.

- I do not fully agree with Kaz's comment. I get the point and agree in principle, but in practice it has the user constantly going "does this need a reset?". There is no easy way to test if the user's answer is correct either. I find it safer to just reset everything. I also don't think this hurts timing, as usually right by the data path that wouldn't have a reset is some control logic that does, so if it can meet timing to the control logic, it would have met timing to the data path. The only major advantage is if the reset is using local routing, it would save a little bit, but that's usually not too big of a deal. I just think the risk of not adding a reset to the wrong signal and the extra engineering time figuring it out are not worth it. (I'm working with someone who has a reset failure right now, where one build occasionally fails out of reset. Most other images of that build happen to meet timing. It's a complete nightmare to debug and prove why it's occurring.)

Hi Rysc,

Reseting everything is safe luxury that can't be afforded in today's large designs. You need to remove reset from where it is not needed for sure.

Reseting say dsp data path is completely meaningless in a system that "washes off" initial zeros and other filtering responses till they settle.

It is the control logic that must have reset, state machines, enables ...etc. Surely these need not be tampered with.

Hi Kalyansirinvasim,

No I don't mean that, you should do that for the asynchronous anyway.

I meant you can apply reset after clk edge instead of before...

One other way (for exams) to get rid of all the trouble is to not register the reset at all, then there will be no paths to report and you could get a clean report (but fake), though this cheating but many designers are not aware of it.

Still dangerous unless you really know what you're doing. As an example, there may be a large block that is purely datapath, but inside is a 1:2 demux and 2:1 mux that is used to send data in/out of a section that is double-clocked. The select for these two are run by a toggle flip-flop. Seems innocent enough, but if the two registers come out of reset at different times, the design won't work. 99% of the time that isn't a problem(and if the reset is on a global, it won't occur 99.99% of the time). This is the type of thing that gets missed because the user doesn't think of it as "control logic".

If the reset is on a global, I don't see any reason not to reset everything. I think you're recommendation works when truly needed, but most large designs still don't have any recovery problems and resetting everything doesn't hurt them. That being said, there are potentially cases where not resetting the datapath could help, but you need to know what you're doing since there is no analysis tool that will tell you what is and is not safe to take off the reset.