cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
vishalpatel
Explorer
Explorer
16,385 Views
Registered: ‎05-07-2013

Setup time violation at the input pin of asyncronus reset of Flip flop.

Hi,

 

           I am using Spartan 6 FPGA(xc6slx75-3-csg484), for my project.

 

           I have used reset synchronizer(Assert asyncronusly and deassert syncronusly) yet I am getting very high timing violation(-4.5 ns) at the input pin of asyncronus reset of flip flop.

 

           So please give me guidence for the same.

 

-----Vishal Patel.

 

        

0 Kudos
15 Replies
yashp
Moderator
Moderator
16,380 Views
Registered: ‎01-16-2013

Hello,

 

Can you please give us detail about the path which are under consideration?

Better share your timing report and UCF. Share logic schematic for this usage.

 

Thanks,

Yash

0 Kudos
avrumw
Expert
Expert
16,370 Views
Registered: ‎01-23-2009

One of the requirements of a reset sycnrhonizer (like the one described in this post) is a set_false_path -from <asycnrhonous input port>.

 

Lets look at the code in the referenced post. The assertion of arst immediately affects the output of the syncronizer (rst_sync). Thus any flip-flop that is reset by rst_sync will see a combinatiorial path from arst to the asynchronous reset input of the FF. However, due to the structure of the reset bridge, only the asserting edge of the arst can propagate to the destination FFs; the deasserting edge is managed by the 2nd FF (and is synchronous). Therefore, the path from arst directly to flip-flops is false, and must be declared as such.

 

In Vivado, this would be done with

 

set_false_path -from [get_ports arst]; # or whatever the name of the signal driving the IBUF that generates arst is

 

In ISE, this is done simply by not declaring an OFFSET IN constraint for the port arst.

 

Avrum

vishalpatel
Explorer
Explorer
16,358 Views
Registered: ‎05-07-2013

Hi Avrum,

 

                Thank you for your answer.

 

                I have not declared OFFSET IN constraint for the port arst.

 

----VIshal Patel.

0 Kudos
muravin
Scholar
Scholar
16,314 Views
Registered: ‎11-21-2013

Vishal,

If I understand corectly your scenario, why would you even care defining OFFSET IN for an asyncronous signal? You can just put a TIG on it.

BR

Vlad

Vladislav Muravin
0 Kudos
avrumw
Expert
Expert
16,311 Views
Registered: ‎01-23-2009

You will need to send us the detailed timing report for the failed path.

 

It is possible that the fanout from your reset synchronizer is too high and all over the FPGA, and hence it can't make it from the synchonizer to all FFs in one clock period. If so, then you need to re-buffer your async reset. Generally what you would do is have an additional stage of something that looks like a reset bridge in every "top level module".

 

Lets say that your design has 5 top level modules (each representing roughly 1/5th of the overall gates of your design). Each of the 5 modules would take in the "rst_sync" output of the synchronizer and buffer it

 

always @(posedge clk or posedge rst_sync)
begin
  if (rst_sync)
  begin
    rst_block<= 1'b1;
  end
  else
  begin
    rst_block<= rst_sync;
  end
end

Now use this rst_block for all FFs in the block that need an asynchronous reset. The whole system still has a global asynchronously asserted reset (since the asserting edge of arst propagates combinatorially to the async reset of all FFs), but deasserts synchronously in 2 or 3 clock cycles. Furthermore, the load of the reset signals is cut down significantly.

 

This all comes down to having a methodology to manage youre resets. The global reset strategy (whether synchronous or async) requires a lot of routing and places some tough requirements on the placement - if you don't do it properly (i.e. have one reset bridge driving thousands of FFs scattered across the design), then this is going to force to tool to place everything close to the reset bridge to have it meet timing. This can mess up the timing of your design in a big way. Re-pipelining your reset (as I showed above) helps. Some, however, suggest that we move away from a global reset methodology (since FPGAs come up in a "known" state). This can be very beneficial in terms of timing, placement and routing, but has other issues that need to be dealt with, which, if done incorrectly, can lead to an unreliable system.

 

Avrum

0 Kudos
muravin
Scholar
Scholar
16,309 Views
Registered: ‎11-21-2013

In short:

- Avoid resets in your design whenever you can

- If you must have resets for FSMs etc, make them synchronous

- If you must have async resets, decouple them from clocks

 

Regards

Vladislav Muravin
0 Kudos
dwisehart
Scholar
Scholar
16,307 Views
Registered: ‎06-23-2013

FSM's do not need resets: just initialize your state variables in the register declaration and the synthesizer will put give the FD or LUT the correct INIT parameter.

 

For items like FIFO18E1 which require a reset, make the reset local, not driven by a central resource.  You can do this with a shift register that operates off of the first clocks that make it to the FIFO.

 

Daniel

 

0 Kudos
avrumw
Expert
Expert
16,304 Views
Registered: ‎01-23-2009

just initialize your state variables in the register declaration and the synthesizer will put give the FD or LUT the correct INIT parameter.

 

While this is true, it is not sufficient in some applications.

 

When the FPGA intializes, your FSM will be initialized to the "default" state. It will stay there as long as the internal GSR (Global Set Reset) signal is asserted, which is part of the FPGA configuration procedure. Once initialization ends, the FPGA configuration process will deassert GSR, and your state machine is free to start operating.

 

But, the deassertion of GSR is not synchronous to anything, and is relatively slow (several nanoseconds of skew on the die).

 

So, what happens if there is a clock edge near the deassertion of the GSR? (Assuming your clocks are running, which they will be unless you do something to prevent them). Lets say that your reset state of your FSM is 000, and on that "first" clock, the input conditions would make your FSM transition to 111. Since the GSR can deassert at the same time as the clock, these FFs can go metastable. Furthermore, since the GSR has skew, it is possible for some of the FFs of your state machine to still think they are in GSR while others don't. This can make your state machine transition to any state, as each FF independently decides if it is still in GSR or not. Thus, your state machine has crashed coming out of reset...

 

The ways to avoid this are

  - explicitly (and with synchronous resets or synchronously deasserted async resets) reset critical areas of the design (like state machines)

  - ensure that your clock is not running around the deassertion of GSR

    - this can be done by careful use of BUFGCEs

  - ensure that your state machine cannot transition out of the "reset" state until a few clocks after the deassertion of GSR

  - (and probably some others)

 

But, you need to manage this issue or you end up with a design that doesn't boot up reliably.

 

Avrum

 

 

Tags (1)
0 Kudos
dwisehart
Scholar
Scholar
16,299 Views
Registered: ‎06-23-2013

I agree about using the BUFGCE's.  They can save you a lot of headaches.

 

As least for the 7 Series FPGA's, Xilinx doesn't talk about GSR anymore in the Config guide, instead they talk about DONE, GTS (Global Tri-State for the IO pins), GWE (Global Writen Enable for the CLB's, IOB's and other synchronous logic) and EOS (End of Startup).  These signals are created by an eigth-state state maching that is synchronous to the CCLK.  EOS always comes last, but the others are programmable as to which state they assert or release and you can wait on the MMCM's and DCI's, but only if you configure it that way.  Here is the default sequence (from UG470):

 

2014-06-26_11-25-06.png

Note that phase 4 happens before phase 5, but they are listed in reverse order in this table.  Here are the accompanying waveforms, which show GWE happening before GTS (so do you trust the table or the figure?):

2014-06-26_11-25-52_01.png

 

So yes, you need to be aware of the timing of the multiple events around startup.  If your state machines wait--directly or indirectly--on changing external input--could be one edge or two depending on the input--before they respond for the first time, then you will have an orderly startup.  If you just need to wait for a certain number of (BUFGCE passed) clock cycles before responding, a local shift register will do that nicely.

 

Daniel

 

muravin
Scholar
Scholar
13,537 Views
Registered: ‎11-21-2013

We are going almost off-topic, but there is another reason to reset the state machines by design no matter what.

 

The reason is, systems are complicated these days and no matter how true Daniel's post is, it's not so much about what and how things gets initialized on power-up; rather, there is always a situation that one cannot think of that would create problems in the system if the FSM cannot be reset through its normal operation.

 

The simplest example is a state machine that tracks some video, I am being general and hypothethical. If it does not get reset on fsync, and things go wrong somewhere, the system can become broken. By term "system" I mean FPGA and its surroundings including software that relies on the data provided by the FPGA. For example, AXI VDMA had similar problem before release 5.xx on the S2MM channel.

 

Cheers

Vlad

Vladislav Muravin
0 Kudos
balkris
Xilinx Employee
Xilinx Employee
13,509 Views
Registered: ‎08-01-2008

1 The assertion edge of an asynchronous reset has no requirement for alignment with the clock. The

only real timing requirement is that assertion to de-assertion meets the minimum required pulse width.

Most designs assert reset for many clock cycles so this is not an issue. And in many cases the static

timing analyzer doesn't know the pulse width.



2 When you de-assert asynchronous reset, the flip-flops remain in their reset state until the next

clock edge that comes at least one recovery time later. If the clock is stopped, then they hold their

cvalue indefinitely. The only case where you don't know the outcome is when you release reset

and the next clock edge comes before the recovery time has elapsed. This is what static timing

analysis checks for and reports (setup) timing errors if it happens.
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
balkris
Xilinx Employee
Xilinx Employee
13,508 Views
Registered: ‎08-01-2008

This paper seems good
http://www.eetimes.com/document.asp?doc_id=1278998
Thanks and Regards
Balkrishan
--------------------------------------------------------------------------------------------
Please mark the post as an answer "Accept as solution" in case it helped resolve your query.
Give kudos in case a post in case it guided to the solution.
0 Kudos
sppurnaye
Visitor
Visitor
13,458 Views
Registered: ‎07-09-2014

  How can i decide the setup and hold time for a D Flip Flop. Thus setup time is equal to  Clock to Q delay.Is there any standard method or formula to decide setup and hold time.

0 Kudos
yashp
Moderator
Moderator
13,455 Views
Registered: ‎01-16-2013

Hello @sppurnaye ,

 

As you are newbie in forum please follow below guidelines for your future query/issue.

 

1) Do not ask duplicate questions on different forums.

2) Do'nt hijack someones thread with your own query.

3) Always start new thread for new query/issue.

4) After getting proper info/answer always close the thread by accepting soultion as answer.

 

Regarding your query refer this: http://forums.xilinx.com/t5/Timing-Analysis/Setup-and-hold-time/m-p/487852#M6428 

 

 

Thanks,

Yash

0 Kudos
bassman59
Historian
Historian
13,439 Views
Registered: ‎02-25-2008


@muravin wrote:

We are going almost off-topic, but there is another reason to reset the state machines by design no matter what.

 

The reason is, systems are complicated these days and no matter how true Daniel's post is, it's not so much about what and how things gets initialized on power-up; rather, there is always a situation that one cannot think of that would create problems in the system if the FSM cannot be reset through its normal operation.

 

The simplest example is a state machine that tracks some video, I am being general and hypothethical. If it does not get reset on fsync, and things go wrong somewhere, the system can become broken. By term "system" I mean FPGA and its surroundings including software that relies on the data provided by the FPGA. For example, AXI VDMA had similar problem before release 5.xx on the S2MM channel.

 


I think a good rule of thumb is that you should provide a reset for state machines which need them. Snarky, yes, but true. Analyze the design and determine whether conditions exist which could cause the machine to lock up, and provide synchronous resets.

 

If you consider that "initialization" and "reset" are not necessarily the same, then you're on the right track.

----------------------------Yes, I do this for a living.
0 Kudos