Hi Eveyone,

The specifications goes something like this :

The device core asserts reset to the device peripherals asynchronously
and releases (deasserts) the reset synchronously after 4 clock periods

there are two possible implementations for the above spec which one is
better :

signal reset_reg : std_logic_vector(3 downto 0);

p_reset_reg : process(clk,reset_async)
begin
if (reset_async = '0') then
 -- on async reset assertion reset the registers
 reset_reg <= (others => '0');

elsif (clk'event and clk = '1') then

reset_reg(0) <= '1';

reset_shift_reg : for i in (reset_reg'LOW to reset_reg'HIGH -1) loop
reset_reg(i+1) <= reset_reg(i);
end  loop reset_shift_reg;

end if ;
end process p_reset_reg;

-- implementation 1 direct assignment of register value to reset_out

reset_out <= reset_reg(3);

-- implementation 2 assignment of decoded value of the register
-- bank to the reset out  only when all the four registers attain
-- '1' then release reset to the device

reset_out <= reset_reg(0) and reset_reg(1) and reset_reg(2) and
reset_reg(3);

"I think the second implementation reduces the problem of metastability
at the reset_out as it is less probable that ll the four flops go
metastable at the same time"

Is the above statement (" I think ... time") valid

awaiting your replies

Hi - 

I don't speak VHDL, so let's see if I've got this right:

You want to create an active-LOW reset signal that is asserted
asynchronously (presumably right after the part configures) and
deasserts synchronous to some clock.

To do this, you created a 4-bit shift register, all of whose bits are
reset LOW by some global asynchronous reset.  The D input of the shift
register input is HIGH; when the asynch reset is deasserted, each
successive clock cycle propagates the HIGH to the next stage.

You've proposed two ways of obtaining your active-LOW,
asynch-assert-synch-deassert reset from this shift register:

1) use the Q output of the last shift register FF

or

2) AND the Q outputs of each of the 4 shift register FFs.

You claim that (2) reduces the odds of a metastable propagating to the
reset signal.

I disagree: (2) is no better than (1).  Here's why.

Immediately after the deassertion of the asynch reset, only one of the
four shift register FFs can go metastable, namely the first one.
That's the only flip-flop in which the next desired state, HIGH, is
different from the current LOW state; the other 3 FFs have a LOW on
their D inputs.  Metastability arises from trying to change a FF's
state with insufficient energy; if there's no possibility of a state
change, there's no metastability.  You will not see all four FFs, or
even three or two, go metastable at once.

If the first FF goes metastable, that metastable state could propagate
to the second FF the next clock cycle, but if there's plenty of
settling time between the first and second FFs, the odds are low (I'm
going to skip the issue of just how low).  And the odds of propagating
to the third FF are even lower, and so on.  Unless you're running this
reset circuit at a very high clock speed or haven't guaranteed lots of
slack between stages, using the output of the fourth FF as a reset
should be fine.  

ANDing the four FF outputs buys you nothing.  If, against all odds,
the metastable manages to propagate to the output of the last FF,
ANDing that Q with three HIGH signals does nothing to stop the
metastable from propagating through the AND gate.  And if the
metastable doesn't make it to the last FF, the AND gate is again
superfluous.

Bob Perlman
Cambrian Design Works
http://www.cambriandesign.com


On 15 Aug 2006 21:24:18 -0700, "arant" <arant.agrawal@gmail.com>
wrote:

>Hi Eveyone,
>
>The specifications goes something like this :
>
>The device core asserts reset to the device peripherals asynchronously
>and releases (deasserts) the reset synchronously after 4 clock periods
>
>there are two possible implementations for the above spec which one is
>better :
>
>signal reset_reg : std_logic_vector(3 downto 0);
>
>p_reset_reg : process(clk,reset_async)
>begin
>if (reset_async = '0') then
> -- on async reset assertion reset the registers
> reset_reg <= (others => '0');
>
>elsif (clk'event and clk = '1') then
>
>reset_reg(0) <= '1';
>
>reset_shift_reg : for i in (reset_reg'LOW to reset_reg'HIGH -1) loop
>reset_reg(i+1) <= reset_reg(i);
>end  loop reset_shift_reg;
>
>end if ;
>end process p_reset_reg;
>
>-- implementation 1 direct assignment of register value to reset_out
>
>reset_out <= reset_reg(3);
>
>-- implementation 2 assignment of decoded value of the register
>-- bank to the reset out  only when all the four registers attain
>-- '1' then release reset to the device
>
>reset_out <= reset_reg(0) and reset_reg(1) and reset_reg(2) and
>reset_reg(3);
>
>"I think the second implementation reduces the problem of metastability
>at the reset_out as it is less probable that ll the four flops go
>metastable at the same time"
>
>Is the above statement (" I think ... time") valid
>
>awaiting your replies

Hi,

arant schrieb:

> The device core asserts reset to the device peripherals asynchronously
> and releases (deasserts) the reset synchronously after 4 clock periods
[..]
> reset_out <= reset_reg(3);
[..]
> reset_out <= reset_reg(0) and reset_reg(1) and reset_reg(2) and
> reset_reg(3);

> "I think the second implementation reduces the problem of metastability
> at the reset_out as it is less probable that ll the four flops go
> metastable at the same time"
>
> Is the above statement (" I think ... time") valid

No, it is invalid. Metastability _may_ affect the output of any gate
regardless of the other inputs.
On the other side has option 2  a more stable reset release in case of
"bouncing"
imagine your reset has a low ripple and goes clocked in as
00010110111111
Option 2 waits until all four registers are stable, option 1 may lead
to a problem if theres a   "weak" '0' which resets only part of the FF
but not the shift register properly (e.g. due to metastability). It is
very unlikely to have such a problem, but I would prefer a mixture of
both: AND at least two FF to release Reset and don't use the first FF
or first two FF for reset release to be safe against metastability.

bye Thomas

> On the other side has option 2  a more stable reset release in case of
> "bouncing"
> imagine your reset has a low ripple and goes clocked in as
> 0 0001 1011 1111
> Option 2 waits until all four registers are stable, option 1 may lead
> to a problem if theres a   "weak" '0' which resets only part of the FF
> but not the shift register properly (e.g. due to metastability). It is
> very unlikely to have such a problem, but I would prefer a mixture of
> both: AND at least two FF to release Reset and don't use the first FF
> or first two FF for reset release to be safe against metastability.

Hi Thomas,

First of all thanks for taking out time and replying to my query...

Seconly what is the meaning of a "weak" '0'' as the flops share a
common supply rail ?

If you mean the metastability due to reset removal then I can agree
that the shift register will enter an unknown random pattern after the
metastability resolution time has expired and the reset to the device
will be deasserted only when all the flops reach a '1' state.

In the event that any of the register bits settle to '1' then the specs
fail in both the implementations for reset release time of four clock
periods.

Is there any way that still meets the specs even if there is
metastability ...

Thomas Stanka wrote:
> Hi,
>
> arant schrieb:
>
> > The device core asserts reset to the device peripherals asynchronously
> > and releases (deasserts) the reset synchronously after 4 clock periods
> [..]
> > reset_out <= reset_reg(3);
> [..]
> > reset_out <= reset_reg(0) and reset_reg(1) and reset_reg(2) and
> > reset_reg(3);
>
> > "I think the second implementation reduces the problem of metastability
> > at the reset_out as it is less probable that ll the four flops go
> > metastable at the same time"
> >
> > Is the above statement (" I think ... time") valid
>
> No, it is invalid. Metastability _may_ affect the output of any gate
> regardless of the other inputs.
> On the other side has option 2  a more stable reset release in case of
> "bouncing"
> imagine your reset has a low ripple and goes clocked in as
> 00010110111111
> Option 2 waits until all four registers are stable, option 1 may lead
> to a problem if theres a   "weak" '0' which resets only part of the FF
> but not the shift register properly (e.g. due to metastability). It is
> very unlikely to have such a problem, but I would prefer a mixture of
> both: AND at least two FF to release Reset and don't use the first FF
> or first two FF for reset release to be safe against metastability.
> 
> bye Thomas

Thomas Stanka wrote:
> Hi,
>
> arant schrieb:
>
> > The device core asserts reset to the device peripherals asynchronously
> > and releases (deasserts) the reset synchronously after 4 clock periods
> [..]
> > reset_out <= reset_reg(3);
> [..]
> > reset_out <= reset_reg(0) and reset_reg(1) and reset_reg(2) and
> > reset_reg(3);
>
> > "I think the second implementation reduces the problem of metastability
> > at the reset_out as it is less probable that ll the four flops go
> > metastable at the same time"
> >
> > Is the above statement (" I think ... time") valid
>
> No, it is invalid. Metastability _may_ affect the output of any gate
> regardless of the other inputs.

That is what I am not so sure of.  If that is true, then I agree with
your assessment.  But I am pretty sure the way gates are designed, if
one input is in a state that assures the output condition, the other
inputs will not have an effect on the output even if they are not
within the proper digital voltage range.  However, if this is a LUT in
and FPGA, I am not as certain.  I believe they use pass transistors to
connect the output of memory elements to the output of the LUT.  No
matter how they decode the inputs to connect the memory element to the
output, I can see a single metastable input possibly making the LUT
output invalid.

So it depends on whether a LUT is used or a standard gate.


> On the other side has option 2  a more stable reset release in case of
> "bouncing"
> imagine your reset has a low ripple and goes clocked in as
> 00010110111111
> Option 2 waits until all four registers are stable, option 1 may lead
> to a problem if theres a   "weak" '0' which resets only part of the FF
> but not the shift register properly (e.g. due to metastability). It is
> very unlikely to have such a problem, but I would prefer a mixture of
> both: AND at least two FF to release Reset and don't use the first FF
> or first two FF for reset release to be safe against metastability.

Not a bad idea!