State machine outputs and tri-state

Discussion in 'VHDL' started by Grumps, Feb 13, 2008.

  1. Grumps

    Grumps Guest

    Hi
    I'm not a VHDL expert, just learning, so please don't shout.

    I'm using Xilinx ISE9.2sp4 and have the following code as part of a state
    machine:
    CP_IN_OUTPUT_DECODE: process (state_cp_in)
    begin
    if state_cp_in = sta_idle then
    RDY <= 'Z';
    BUSY <= '0';
    end if;

    if state_cp_in = sta_1 then
    RDY <= '0';
    BUSY <= '0';
    end if;

    if state_cp_in = sta_2 then
    RDY <= '1';
    BUSY <= '1';
    end if;
    ....
    ....etc

    The state machine goes from sta_idle, then to sta_1, then to sta_2, etc.
    RDY is a pin on the device.
    During operation, I can see RDY go low in sta_1, but not high in sta_2. I
    know it gets to sta_2 as I can observe BUSY. I don't think RDY is tri-stated
    in sta_2 as there is an external pull-up; it just stays low. Gray encoding
    is used.

    If I change the RDY to rdyi (signal) and then have:
    RDY <= 'Z' when state_cp_in = sta_idle else rdyi;
    outside of the decode process then it all behaves itself.

    Apart from lack of experience, what mistake(s) have I made?
    Thanks.
    Grumps, Feb 13, 2008
    #1
    1. Advertising

  2. Grumps

    Andy Guest

    On Feb 13, 10:24 am, "Grumps" <> wrote:
    > Hi
    > I'm not a VHDL expert, just learning, so please don't shout.
    >
    > I'm using Xilinx ISE9.2sp4 and have the following code as part of a state
    > machine:
    > CP_IN_OUTPUT_DECODE: process (state_cp_in)
    > begin
    > if state_cp_in = sta_idle then
    > RDY <= 'Z';
    > BUSY <= '0';
    > end if;
    >
    > if state_cp_in = sta_1 then
    > RDY <= '0';
    > BUSY <= '0';
    > end if;
    >
    > if state_cp_in = sta_2 then
    > RDY <= '1';
    > BUSY <= '1';
    > end if;
    > ...
    > ...etc
    >
    > The state machine goes from sta_idle, then to sta_1, then to sta_2, etc.
    > RDY is a pin on the device.
    > During operation, I can see RDY go low in sta_1, but not high in sta_2. I
    > know it gets to sta_2 as I can observe BUSY. I don't think RDY is tri-stated
    > in sta_2 as there is an external pull-up; it just stays low. Gray encoding
    > is used.
    >
    > If I change the RDY to rdyi (signal) and then have:
    > RDY <= 'Z' when state_cp_in = sta_idle else rdyi;
    > outside of the decode process then it all behaves itself.
    >
    > Apart from lack of experience, what mistake(s) have I made?
    > Thanks.


    For combinatorial processes, the number one mistake I see is that not
    all potential execution paths through the process are considered, and
    there is some path that results in no assignment to an output. This
    results in a latch, which can fool you especially if you are trying to
    figure out which state you're in by observing other outputs, which may
    be latches themselves.

    Try putting a set of default assignments to all of the outputs that
    are driven by the process, at the top of the process (right after the
    begin), with no conditionals, etc. around them. That way, you know
    there will be no latches.

    Better yet, try learning to use clocked processes exclusively, and
    expressing any combinatorial logic within those clocked processes;
    then it is impossible to get a latch. Since your outputs will be
    registered in almost all cases* you have to take that clock cycle
    delay into account.

    *Some synthesis tools allow you to create a combinatorial output from
    a clocked process using an expression of variables assigned to a
    signal after the clocked if-then clause. The resulting hardware
    behavior is cycle-accurate compared to the RTL simulation.

    Andy
    Andy, Feb 13, 2008
    #2
    1. Advertising

  3. Grumps

    Grumps Guest

    "Andy" <> wrote in message
    news:...
    > On Feb 13, 10:24 am, "Grumps" <> wrote:
    >> Hi
    >> I'm not a VHDL expert, just learning, so please don't shout.
    >>
    >> I'm using Xilinx ISE9.2sp4 and have the following code as part of a state
    >> machine:
    >> CP_IN_OUTPUT_DECODE: process (state_cp_in)
    >> begin
    >> if state_cp_in = sta_idle then
    >> RDY <= 'Z';
    >> BUSY <= '0';
    >> end if;
    >>
    >> if state_cp_in = sta_1 then
    >> RDY <= '0';
    >> BUSY <= '0';
    >> end if;
    >>
    >> if state_cp_in = sta_2 then
    >> RDY <= '1';
    >> BUSY <= '1';
    >> end if;
    >> ...
    >> ...etc
    >>
    >> The state machine goes from sta_idle, then to sta_1, then to sta_2, etc.
    >> RDY is a pin on the device.
    >> During operation, I can see RDY go low in sta_1, but not high in sta_2. I
    >> know it gets to sta_2 as I can observe BUSY. I don't think RDY is
    >> tri-stated
    >> in sta_2 as there is an external pull-up; it just stays low. Gray
    >> encoding
    >> is used.
    >>
    >> If I change the RDY to rdyi (signal) and then have:
    >> RDY <= 'Z' when state_cp_in = sta_idle else rdyi;
    >> outside of the decode process then it all behaves itself.
    >>
    >> Apart from lack of experience, what mistake(s) have I made?
    >> Thanks.

    >
    > For combinatorial processes, the number one mistake I see is that not
    > all potential execution paths through the process are considered, and
    > there is some path that results in no assignment to an output. This
    > results in a latch, which can fool you especially if you are trying to
    > figure out which state you're in by observing other outputs, which may
    > be latches themselves.
    >
    > Try putting a set of default assignments to all of the outputs that
    > are driven by the process, at the top of the process (right after the
    > begin), with no conditionals, etc. around them. That way, you know
    > there will be no latches.
    >
    > Better yet, try learning to use clocked processes exclusively, and
    > expressing any combinatorial logic within those clocked processes;
    > then it is impossible to get a latch. Since your outputs will be
    > registered in almost all cases* you have to take that clock cycle
    > delay into account.
    >
    > *Some synthesis tools allow you to create a combinatorial output from
    > a clocked process using an expression of variables assigned to a
    > signal after the clocked if-then clause. The resulting hardware
    > behavior is cycle-accurate compared to the RTL simulation.


    Thanks for the comments.
    I may go and revisit the design with this knowledge. But, it is now working
    simply be taking the tri-states out of the process.
    Grumps, Feb 13, 2008
    #3
    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. Analog Guy

    Open Drain or Tri-state???

    Analog Guy, Feb 20, 2004, in forum: VHDL
    Replies:
    1
    Views:
    2,469
    fabbl
    Feb 20, 2004
  2. Mai
    Replies:
    1
    Views:
    1,967
    Weng Tianxiang
    Aug 10, 2004
  3. Urban Stadler

    set tri-state

    Urban Stadler, Aug 2, 2004, in forum: VHDL
    Replies:
    1
    Views:
    593
    Peter Hermansson
    Aug 3, 2004
  4. john
    Replies:
    15
    Views:
    662
  5. Analog_Guy
    Replies:
    24
    Views:
    1,586
Loading...

Share This Page