FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 04-30-2006, 02:56 AM
Fizzy
Guest
 
Posts: n/a
Default Reset

Hi,

What is the difference between Asynchronous and Synchronous reset. When
do you want to use one of them. I am desging a state machine how would
i figure out which one i want to use. How would it impact the
hardware???

Thanks

Reply With Quote
  #2 (permalink)  
Old 04-30-2006, 03:29 AM
Peter Alfke
Guest
 
Posts: n/a
Default Re: Reset

As the name implies, an asynchronous reset resets the flip-flop or
register immediately, without a clock.
A synchronous reset input effectively forces the D input Low, sotat the
flip-flop or register gets reset by the next clock, not immediately.

Synchronous resets, in conjunction with low-skew global clocks, result
in the best predictive behavior.

But in certain special cases, you might need an asynchronous reset, to
get the flip-flop reset before the next clock comes around. The penalty
is less predictable, "sloppier" timing, especially if the asynchronous
line has to drive many loads.
Peter Alfke, Xilinx

Reply With Quote
  #3 (permalink)  
Old 05-02-2006, 09:14 AM
Jochen
Guest
 
Posts: n/a
Default Re: Reset


> I am desging a state machine [..]


NEVER (again: NEVER) use async resets on statemachines!
Problem here is the "reset-release": you might end up with one FlipFlop
in "normal operation" and another one still in "reset state"
=> your statemachine might change from "one hot" into "two (too?) hot"
!!!

Reply With Quote
  #4 (permalink)  
Old 05-02-2006, 07:53 PM
Andy
Guest
 
Posts: n/a
Default Re: Reset

"Never" is a very strong word, and is almost never correct...

Asynchronous reset inputs are perfectly safe to use, and often
necessary when circuit response must be guaranteed, even in the absence
of a clock. However, they must be used carefully, controlling the
release of reset (actually a synchronous event) such that it meets
setup and hold relative to the clock.

What I recommend to resolve the release of reset problem is to
synchronously release (deassert) the reset signal tied to the async
reset inputs on the state registers. Note that the reset signal still
asserts asynchronously, it only deasserts synchronously.

rst: process (rstin, clk) is
begin
if rstin = '1' then
rstmeta <= '1';
rstout <= '1';
elsif rising-edge(clk) then
rstmeta <= '0'; -- potentially metastable
rstout <= rstmeta; -- meta-rejected
end if;
end process;

fsm: process (rstout, clk) is
begin
if rstout = '1' then
state <= reset_state;
elsif rising_edge(clk) then
case state is
...
end if;
end process;

Andy

Reply With Quote
  #5 (permalink)  
Old 05-07-2006, 06:54 AM
Alif Wahid
Guest
 
Posts: n/a
Default Re: Reset


Andy wrote:
> "Never" is a very strong word, and is almost never correct...
>
> Asynchronous reset inputs are perfectly safe to use, and often
> necessary when circuit response must be guaranteed, even in the absence
> of a clock. However, they must be used carefully, controlling the
> release of reset (actually a synchronous event) such that it meets
> setup and hold relative to the clock.
>
> What I recommend to resolve the release of reset problem is to
> synchronously release (deassert) the reset signal tied to the async
> reset inputs on the state registers. Note that the reset signal still
> asserts asynchronously, it only deasserts synchronously.
>
> rst: process (rstin, clk) is
> begin
> if rstin = '1' then
> rstmeta <= '1';
> rstout <= '1';
> elsif rising-edge(clk) then
> rstmeta <= '0'; -- potentially metastable
> rstout <= rstmeta; -- meta-rejected
> end if;
> end process;
>
> fsm: process (rstout, clk) is
> begin
> if rstout = '1' then
> state <= reset_state;
> elsif rising_edge(clk) then
> case state is
> ...
> end if;
> end process;
>
> Andy


An important thing to remember is the 'others' clause in the case
statement (missing from Andy's snippet above) that should always put the
FSM to a default/reset state. Since FSM state registers are almost
always one-hot encoded by FPGA synthesis tools, anytime it acquires an
illegal value the FSM will be self-resetting thanks to such an 'others'
clause.

Regards,

Alif.

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
simulator reset, not hardware reset danmc91 Verilog 7 04-19-2006 06:43 PM
Reset and Power-On Reset Activation XCFxxP PROMs Pablo Alvarez Sanchez FPGA 2 07-28-2005 10:34 AM
Source of reset for synchronous reset can lead to metastability? Ken FPGA 6 02-23-2005 08:07 AM
Using Sync Reset as Async Reset ALuPin FPGA 3 10-29-2004 09:56 AM


All times are GMT +1. The time now is 01:07 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved