cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Anonymous
Not applicable
8,606 Views

Bad reset behaviour with One-Hot encoded FSM's

Hi everyone,

 

we are currently stuck with a really strange issue with a one-hot encoded state machine.

 

It took us some time to finally discover that the "hot" bit was lost and the state vector was all zero. The FSM is pretty simple, it got an asynchronous reset that forces the FSM into an idle state and is then running a state sequence straight independently to other signal but just the clock.

 

The asynchronous reset is derived from a FF pipeline to have some DCM related locking support.

 

Just like that:

 


 

PROCESS(rst_n, clk)

BEGIN

  IF (rst_n = '0') THEN

    state <= idle;

  ELSIF (clk'event AND clk = '1') THEN

    CASE state IS

      WHEN idle => state <= step_1;

      WHEN step_1 => state <= step_2;

      WHEN step_2 => state <= step_3;

      WHEN step_3 => state <= step_1;

      WHEN OTHERS => state <= idle;  ( this one is unnecessary, because all FSM states were already described )

    END CASE;

  END IF;

END PROCESS;

 

...

 

PROCESS(clk, dcm_locked)

BEGIN

  IF (dcm_locked = '0') THEN

    rst_vector_n <= (OTHERS => '0');

  ELSIF (clk'EVENT AND clk = '1') THEN

    rst_vector_n <= rst_vector_n(14 DOWNTO 0) & '1';

  END IF;

END PROCESS;

 

rst_n <= rst_vector_n(15);

 


 

The only explanation for us is, that the state flip flops are coming out of the reset state in different clock cycles, so that the idle state (first FF) is processed, but the second state (second FF) is still in reset state, and will therefore loose the state selector bit.

 

This effect is coming up very seldomly, maybe every 100 bit files we generate. And it's hardware depending, some devices will always fail, some will always work fine, and some depend on the operating temperatur, will fail in cold state, but will work fine after the device was powered for some time.

 

We use ISE 12.4. We now fear that ISE is not taking reset wire delays into account for place & route. We only constrained the clock signal per ucf file. Since the reset is coming out of a FF in the same clock domain, ISE should be able to automatically evaluate secondary constraints. Does ISE check wire delays for asynchronous reset inputs of FF's at all??

 

Has anyone experience into this?? Your support is highly appreciated!

 

Thanks,

Andre

 

0 Kudos
8 Replies
gszakacs
Instructor
Instructor
8,602 Views
Registered: ‎08-14-2007

I think your fears are confirmed.  By default asynchronous reset timing is not checked

for setup to the clock.  I would suggest using a local synchronous reset signal for

the FSM.  The local reset can be generated from the global reset signal using an

async reset process.  Normally I use a 3-stage shift register, asynchronously reset

to "111" and shifted left on each clock.  The MSB of this S/R will be the synchronous

reset of the FSM.  I seem to remember a white paper on this sort of reset problem.

 

-- Gabor

-- Gabor
0 Kudos
Anonymous
Not applicable
8,574 Views

Wooops. I guess that explains it.

 

By saying "by default" the asynchronous reset timing is not checked, is there a way to enable it? Can I constraint the reset signal propagation like "FROM rst_n TO FFS" to achieve correct timing analysis? Or does it the "ENABLE=reg_sr_r" constraint?

 

We have an internal policy to use low-active asynchronous resets only. The use of a local synchronous reset would trigger a mad discussion about basic design rules which are in an untouchable state in our company.

 

0 Kudos
evgenis1
Advisor
Advisor
8,570 Views
Registered: ‎12-03-2007

Hi,

 

I've seen this issue in highly utilized designs, where skew of the async reset signal coming into FSM flops is significant. One way to combat this issue would be floorplanning FSM flops next to each other. 

Another option is using low-skew routes (such as used for global clocks) for the reset. Both options will reduce the probability that the issue will happen, but won't completely elimitate it.

 

Thanks,

Evgeni

Tags (1)
0 Kudos
eteam00
Professor
Professor
8,567 Views
Registered: ‎07-21-2009

I've seen this issue in highly utilized designs, where skew of the async reset signal coming into FSM flops is significant. One way to combat this issue would be floorplanning FSM flops next to each other. 

Another option is using low-skew routes (such as used for global clocks) for the reset. Both options will reduce the probability that the issue will happen, but won't completely elimitate it.

Synchronising the async reset to the FSM's clock domain would be simpler and more deterministic.

 

-- Bob Elkind

SIGNATURE:
README for newbies is here: http://forums.xilinx.com/t5/New-Users-Forum/README-first-Help-for-new-users/td-p/219369

Summary:
1. Read the manual or user guide. Have you read the manual? Can you find the manual?
2. Search the forums (and search the web) for similar topics.
3. Do not post the same question on multiple forums.
4. Do not post a new topic or question on someone else's thread, start a new thread!
5. Students: Copying code is not the same as learning to design.
6 "It does not work" is not a question which can be answered. Provide useful details (with webpage, datasheet links, please).
7. You are not charged extra fees for comments in your code.
8. I am not paid for forum posts. If I write a good post, then I have been good for nothing.
0 Kudos
Anonymous
Not applicable
8,560 Views

Well, the asynchronous reset signal we are talking about is driven by the clk signal, it's already sync'ed into the proper clock domain as shown in the above example.

 

The implementation between synchronous or asynchronous reset will be exactly equal, except that the SR input of the FF cell is differently configured. Routing is equal, physical connections as well. It's just that ISE does not care about the delays if the FF is set to asynchronous (high-active CLR used). I spend my saturday trying to find a constraint that forces the reset propagation delays to be considered, and I failed. Does it mean that it is not possible at all?

 

If this is true, then asynchronous resets can not be used at all. If getting out of the reset state is a random process and this non-deterministic, how can anyone make safe implementations? Just think of logic cores that run at 600 MHz right after the reset is released, a few nanoseconds of delay lead to totally non-controllable reset behaviour. I dislike work-arounds like floorplanning cells to certain area's to lower the propability of failure, it will never be zero.

 

Cheers,

Andre

0 Kudos
mcgett
Xilinx Employee
Xilinx Employee
8,545 Views
Registered: ‎01-03-2008

And this is why synchronous resets are strongly recommended.
------Have you tried typing your question into Google? If not you should before posting.
Too many results? Try adding site:www.xilinx.com
0 Kudos
Anonymous
Not applicable
8,473 Views

Just to end this topic properly...

 

I've found other posts in this forum concerning asynchronous resets giving me answers. Also check this for reference: http://www.xilinx.com/support/answers/14644.htm

 

I've used this inside our UCF file: "ENABLE = reg_sr_r;" and voila, the asynchronous wire delays got considered properly. Xilinx has changed the default switch for reg_sr_r from disabled (Spartan3-Generation or Virtex5-Generation and before) to enabled (Spartan6-Generation and Virtex6-Generation). So, the use of asynchronous resets on older FPGA generations are not safe by default!

 

As we are working on quite a full Spartan3A-DSP FPGA, we could not reach our timing goals at all with this ENABLE switch (timing score came up to somewhat 10*E^8). So we decided to have it disabled again and used a synchronous reset on that particular FSM instead.

 

As we used synchronized asynchronous resets (which is recommented by Altera btw), we can use the reset signal either asynchronous OR synchronous. But as the rest of our logic is not coming out of the reset state in the same clock cycle (since we have the timing analyser disabled for this), we need a new master plan dealing with the reset state.

 

As a reset is pulled only once in the very beginning (at least it's supposed so), it doesn't deserve such highly constrained timing rules, because it influences logic timings and routing resources too much. It's rather required to create a well-defined and safe post-reset behaviour.

 

Cheers,

Andre

 

0 Kudos
rcingham
Teacher
Teacher
8,469 Views
Registered: ‎09-09-2010

"As we used synchronized asynchronous resets (which is recommented by Altera btw)"

There are subtle differences between the logic internals of Altera and Xilinx FPGAs, as you have just discovered... If you need HDL code that is 'equally good' for either vendor, you will need to satisfy both lots of HDL Coding Style Guidelines.


------------------------------------------
"If it don't work in simulation, it won't work on the board."
0 Kudos