power-on reset to effect once only.

Discussion in 'VHDL' started by Niv, Nov 23, 2007.

  1. Niv

    Niv Guest

    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;
    --------------------------------------------------------------------------------
    END ARCHITECTURE rtl;
    --------------------------------------------------------------------------------

    Regards, Kev P.
     
    Niv, Nov 23, 2007
    #1
    1. Advertising

  2. Niv

    sprocket Guest

    Niv wrote:
    > 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?
     
    sprocket, Nov 23, 2007
    #2
    1. Advertising

  3. Niv wrote:

    > 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.

    --
    Paul Uiterlinden
    www.aimvalley.nl
    e-mail addres: remove the not.
     
    Paul Uiterlinden, Nov 23, 2007
    #3
  4. Niv

    Niv Guest

    On 23 Nov, 13:57, Paul Uiterlinden <> wrote:
    > Niv wrote:
    > > 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.
    >
    > --
    > Paul Uiterlindenwww.aimvalley.nl
    > e-mail addres: remove the not.


    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.
     
    Niv, Nov 23, 2007
    #4
  5. Niv

    KJ Guest

    "Niv" <> wrote in message
    news:...

    > 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
     
    KJ, Nov 23, 2007
    #5
  6. "Niv" <> wrote in message
    news:...
    > On 23 Nov, 13:57, Paul Uiterlinden <> wrote:
    >
    > 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.
     
    David Spencer, Nov 24, 2007
    #6
  7. Niv

    Guest

    On Nov 24, 10:41 am, "David Spencer" <>
    wrote:
    >
    > 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
     
    , Nov 25, 2007
    #7
  8. Niv

    sprocket Guest

    Niv wrote:
    >
    > 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.
     
    sprocket, Nov 26, 2007
    #8
  9. Niv

    Niv Guest

    On 26 Nov, 14:59, sprocket <> wrote:
    > Niv wrote:
    >
    > > 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.


    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.
     
    Niv, Nov 28, 2007
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Weng Tianxiang
    Replies:
    7
    Views:
    1,109
    Mike Treseler
    Nov 25, 2003
  2. john
    Replies:
    7
    Views:
    694
  3. Replies:
    9
    Views:
    329
    Stuart Redmann
    Nov 7, 2006
  4. Replies:
    8
    Views:
    371
    Mark Dickinson
    Apr 17, 2008
  5. Hunter Johnson

    Reset <> without having it fail once?

    Hunter Johnson, Aug 11, 2004, in forum: Perl Misc
    Replies:
    10
    Views:
    157
    Greg Bacon
    Aug 13, 2004
Loading...

Share This Page