Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

tri-state input in FSM

Hello,

I have built a FSM that has a shared bidir bus as an input and output. The problem that I have is that I continuously have to check the bus if it addresses me and sometimes it goes into high impedance during the communication with somebody else. Once that happens, my FSM goes into a dont care state and it does not recover anymore, even if the bus changes value. Can somebody explain how I can recover my FSM and keep it in a loop after it has gone into a dont care state, which was caused by checking a high-impedance bus?

Any help would be appreciated

4 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Hardware input state can't be high z, it's either low or high, or possibly an intermediate voltage of unclear level. z input state can possibly occur in simulation.

    I don't know however, what you mean with a "don't care state" of the FSM. I guess, you are rather talking about an illegal state which can be brought up by timing violations, if asynchronous input signals to a state machine aren't properly registered.

    Besides registering of input signals, forcing safe state machine encoding should be able to avoid the problem. Refer to the Quartus Software Handbook.

    Can you please clarify, if you talk about simulation or hardware behaviour?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    I am talking about simulation. The FSM goes into 'XX' state and it does not recover.

    I actually thought about registering the input signal, but even there I cannot check it if it is at high Z. I still have problem even if I have something like this:

    always @ (posedge clk)

    begin

    if (bus == 16'dZZ) bus_reg <=16'd0;

    else bus_reg <=bus;

    end

    What do you mean by "forcing safe state machine encoding" ? If you mean to assign to each state a value and making sure that the control always selects a defined state, I already did that. The problem is that in the start state I always check the bus if it has my address and if the bus has ZZ, my FSM goes into XX state (which is undefined) and it does not recover from it even if the bus changes value and tries to address me.

    I know that in actual implementation having pull ups.downs would probably solve the problem, but I am trying to simulate it.

    Any further idea? Thanks for your help.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    you should have accesss to the output enable signal (or read enable from the other end) that will tell you when the tri-state bus is being changed to 'Z'. If you dont have access to this, you will not know when it is safe to read the bus.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    In the first place, you should think about a design that works reliable in real hardware. Secondly care for consistent simulation.

    Constructs like if (bus == 16'dzz) aren't synthesizable and thus don't help to create reliable design operation. If high 'Z' happens in real FPGA hardware, the FSM will jump to any of the available next states. This unpredictable behaviour is marked by a 'X' in simulation. There is no chance to get a consistent simulation in this case. Only an unconditional transition, e.g. a reset can recover a known FSM state.

    The said safe FSM encoding doesn't help here. Also registering the input signal will result in a 'X' state during high Z.