power-on reset to effect once only.

[Niv]

I have a chip with a power-on-reset (por) and a status input.
The first time the chip is powered, the chip internals are reset by
por.
However, a power "brown-out" that causes por to become active again,
but the chip stays active bexause its power rails stay up enough, must
only cause a chip reset if the status input is inactive. If the status
pin is active then the por should NOT generate an internal chip reset.
I've written a simple FSM that does this, but it relies on the FSM
starting up in s0, and not in any other state. Can this be guaranteed,
and for what chip vendors if any?

---------------------------------------------------------------------------------------------------------
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.NUMERIC_STD.all;

ENTITY rst_lock IS
PORT(
-- Clock and asynchronous reset
--
clock : IN STD_LOGIC;
por_n : IN STD_LOGIC;
stat_n : IN STD_LOGIC;
chip_rst : OUT STD_LOGIC
);
END ENTITY rst_lock;
--
ARCHITECTURE rtl OF rst_lock IS
TYPE state_t IS (s0, s1, s2);
SIGNAL state : state_t;
SIGNAL next_state : state_t;
BEGIN
--------------------------------------------------------------------------------
clk_state : PROCESS(por_n, clock)
BEGIN
IF por_n = '0' THEN
IF (state = s0) OR (state = s1) THEN
state <= s0;
ELSIF (state = s2) THEN
state <= s2;
END IF;
ELSIF rising_edge(clock) THEN
state <= next_state;
END IF;
END PROCESS clk_state;
--------------------------------------------------------------------------------
assign_state : PROCESS(state, por_n, stat_n)
BEGIN
CASE state IS
WHEN s0 => IF por_n = '0' THEN -- stay in reset state
next_state <= s0;
ELSE
next_state <= s1;
END IF;
WHEN s1 => IF stat_n = '0' THEN -- Stay in passive state
next_state <= s2;
ELSE
next_state <= s1;
END IF;
WHEN s2 => IF stat_n = '0' THEN -- Stay in lockout state.
next_state <= s2;
ELSE -- (Could make this a 3
way split,
next_state <= s1; -- going to s0 if por_n =
0 AND
END IF; -- stat_n =
1).
WHEN OTHERS => next_state <= s2;
END CASE;
END PROCESS assign_state;
--------------------------------------------------------------------------------
assign_outputs : PROCESS(state)
BEGIN
CASE state IS
WHEN s0 => chip_rst <= '0';
WHEN s1 => chip_rst <= '1';
WHEN s2 => chip_rst <= '1';
WHEN OTHERS => chip_rst <= '1';
END CASE;
END PROCESS assign_outputs;

 

[sprocket]

I have a chip with a power-on-reset (por) and a status input.
The first time the chip is powered, the chip internals are reset by
por.
However, a power "brown-out" that causes por to become active again,
but the chip stays active bexause its power rails stay up enough, must
only cause a chip reset if the status input is inactive. If the status
pin is active then the por should NOT generate an internal chip reset.

Why not just gate the POR with the status input?

 

[Paul Uiterlinden]

I have a chip with a power-on-reset (por) and a status input.
The first time the chip is powered, the chip internals are reset by
por.
However, a power "brown-out" that causes por to become active again,
but the chip stays active bexause its power rails stay up enough, must
only cause a chip reset if the status input is inactive.

But how do you guarantee that the brown-out did not affect any flip-flop on
the chip? If the power-supply has gone out of spec, the only way to deal
with that is a complete reset.

 

[Niv]

But how do you guarantee that the brown-out did not affect any flip-flop on
the chip? If the power-supply has gone out of spec, the only way to deal
with that is a complete reset.

Sprocket, there must be a power on reset the very first time por
occurs, i.e at switch on. Gating with the status might (but probably
not) prevent this. This just might work, I'll discuss with our safety
people; it is a safety critical bit of kit.

 

[KJ]

I've written a simple FSM that does this, but it relies on the FSM
starting up in s0, and not in any other state. Can this be guaranteed,
and for what chip vendors if any?

The short answer to this is to simply change the signal declaration of
'state' to include an initializer
SIGNAL state : state_t := s0;

Whether this gets accepted or not is a function of the device and the
synthesis software. I can say that it works with Altera parts and Quartus,
I haven't tried this with Lattice, Xilinx or Actel in too long of time that
if I remembered correctly it would still be out of date info.

In order for signal initializers to be synthesizable, the targetted part
needs to support guaranteed powerup states for flip flops.

The somewhat longer answer is that relying on signal initializers in place
of reset signals is usually not a 'good' thing but if you have a really
safety critical thingy than it is probably a very good thing since in such
an application you likely need to be in control of every flop at every
moment, not just a time after the first clock edge. But even in that
situation, it would most likely be better to use the signal initializer only
to initialize a shift register that it is used to generate an internal reset
to the device and not to initialize state machines. That way you're not
cluttering your design (and in some places forgetting) signal initializers,
you simply have your normal gating with the reset signal. Something like
the following is what I'm talking about

signal Reset_Shift_Reg: unsigned(5 downto 0) := (others => '0');
signal My_Internal_Reset: std_ulogic;
....
process(Clock, External_Reset)
begin
if rising_edge(Clock) then
Reset_Shift_Reg <= ieee.numeric_std.shift_left(Reset_Shift_Reg, 1);
Reset_Shift_Reg(0) <= '1';
end if;
if (External_Reset = '1') then
Reset_Shift_Reg <= (others => '0');
end if;
end process;
My_Internal_Reset <= not(std_ulogic(Reset_Shift_Reg(Reset_Shift_Reg'high)));

Take note of the other posts about alternatives and implications of the
brownouts though. Losing power somewhat and hoping that your logic didn't
get hit is dicey.

KJ

 

[David Spencer]

Sprocket, there must be a power on reset the very first time por
occurs, i.e at switch on. Gating with the status might (but probably
not) prevent this. This just might work, I'll discuss with our safety
people; it is a safety critical bit of kit.

If this is a safety critical application then it would be suicidal to not
perform a full reset on a power brown-out. As others have said, you have no
way of knowing what state your circuitry has been left in. One adds a reset
generator to ensure that a correct reset occurs in response to power
problems, yet you are trying to circumvent exactly what it is designed to
do. You may as well just remove the reset generator.

 

[kennheinrich]

If this is a safety critical application then it would be suicidal to not
perform a full reset on a power brown-out. As others have said, you have no
way of knowing what state your circuitry has been left in. One adds a reset
generator to ensure that a correct reset occurs in response to power
problems, yet you are trying to circumvent exactly what it is designed to
do. You may as well just remove the reset generator.

I second this opinion completely. I'd also point out a few other
things:

- you clearly intend to use por_n and stat_n in an asynchronous
fashion,
yet you use them to control the next_state function of a synchronous
state
machine. Unless you guarantee externally that por_n and stat_n always
provide adequate setup and hold w.r.t. clock, I can guarantee that
you've
opened a window for race conditions and/or metastability problems. In
a
design where you're talking "guarantee" and "safety-critical" this is
an issue.

- in the olden days (I'm dating myself here, I know) every
manufacturer's
data book had a big old disclaimer on page 1 saying "Not to be used in
safety
critical or life support applications". So (and this is *not* to be
taken
as competent legal advice), IMHO, no matter how good you make your
design, if
something bad happens, and it comes down to a "whose-fault-is-it"
question, it
will *always* be your fault for not noticing this. Even if you
discover that the
technical root cause of the problem was that the FPGA had a timing bug
or a reset
bug or whatever.

- basically, any digital design that requires interfacing to an analog
part
(like a reset detector, video sync slicer, PLL lock detect, etc)
requires you to
decide: "how much do I trust the decision output of the analog
circuit?".
It's been my experience that almost all analog inputs lie at some
point, so you
usually need some digital post-processing to de-glitch or gate or
whatever,
in which case I'd argue that your design is missing something. On the
other
hand, if the analog reset detector actually is "golden", then I
totally agree
with David Spencer's post above. A good commercial reset detector
usually falls
into the "golden" category. Most homemade solutions fall into the
other one

- You are basically asking for features that are somewhat out of the
scope
of the pure VHDL simulation language and tie into synthesis tool and
FPGA implementation aspects, as has been noted. Because of this, any
time you
change synthesizer vendor or tool revision, or use a new flavour or
even die revision
of part, you should due your due diligence and make sure the behaviour
you want
is still present.

If you want some good bed-time reading about bad safety critical
design, look no
farther than the investigation of the old AECL Therac cancer machine.
Check out the
long pdf report at
http://sunnyday.mit.edu/papers/therac.pdf
or a segmented html version Google found at
http://courses.cs.vt.edu/~cs3604/lib/Therac_25/Therac_1.html

Best regards,

- Kenn

 

[sprocket]

Sprocket, there must be a power on reset the very first time por
occurs, i.e at switch on. Gating with the status might (but probably
not) prevent this. This just might work, I'll discuss with our safety
people; it is a safety critical bit of kit.

You can easily calculate the power- up time of the device; make the
reset longer than that. If you can't rely on the state of an internal
gate when powering up, you can't rely on an internal state machine either.

 

[Niv]

You can easily calculate the power- up time of the device; make the
reset longer than that. If you can't rely on the state of an internal
gate when powering up, you can't rely on an internal state machine either.

I've possibly misled you by saying "safety" critical, but perhaps I
should have said
"mission" critical.
Basically, the FPGA is part of a one shot autonomous system. Once
"status" is activated, it has to try & finish its mission as best it
can. A system reset would leave te FPGA without the loaded initial
conditions, (loaded after the initial power on reset, but before
status can be set), so it wouldn't know anymore what its "mission"
was. All this is a very unlikely scenario, just trying to obviate
this slight possibility.

Apologies for the confusion.