Modeling complex state machine in VIP

AHMEDABAD, INDIA: There exist several state machine protocols for various functionalities. Implementing functionality with State Machine approach gives better control over the execution flow. A typical Verification Environment (VE) includes Behavioral Function Model/s (BFM) and Monitor/s.

In BFM, Protocol state machine is a free running, Time Consuming Method as shown in Figure-1. Generator receives the information of states from the state machine and generates the required packets to transmit before sending it to Transmitter for transmission to DUT.

Monitor uses the same protocol state machine to check the collected traffic from the DUT as shown in Figure-2.  Functional/Compliance checker receives the state information from the state machine and expect the packet type and required functional behavior for that state. The checker registers the errors to “Error Reporting” mechanism for further debugging.

Critical junctures while implementing a typical state machine in Verification IP are:

* State machine should be able to pass through all legal and illegal state transitions. Here legal means transmitted packets belong to that state only and illegal means transmitted packets do not belong to that state.

* State machine changes the state only based on the previous states and/or protocol condition. Generator now generates the packet as per state requirement and later on transmitter transmits the packets.

* While re-using same protocol state machine with an instance in monitor to validate DUT’s state machine behavior, latency introduced through DUT state transition and packet transmission leads the monitor to behave incorrectly. A typical PASSIVE monitor state machine predicts state transition of DUT through internal logic and not by observing the real traffic from the DUT at real time.

For example:

If DUT enters into state B from state A, considering that at the same time VE monitor state machine also transits to state B. In state B, DUT should transmit packet b, but due to latency there are few cycle delays in transmission of Packet b. Now, VE monitor state machine also enters in state B, and it expects packet b and other behavior as well.  This may produce error and may transit the state machine in to other illegal state or even hang the state machine.

To overcome these issues, implementation of passive state machine in Verification IP is required.  It is called passive state machine because transition of states does not only depend upon protocol condition and previous state. It also depends on what is transmitted to DUT in case of BFM and what is collected in case of monitor. That means whatever is generated or collected in real time will become the prime condition for state transition.

There is a new approach of implementing passive state machine. Here state machine depends on what is being transmitted / collected and then transits the state. This helps maintain single module / method for state machine. For example, there is a state machine called “protocol_sm” having three states, S1, S2 and S3. Packets P1, P2 and P3 are transmitted to each state, respectively.

Pseudo code for the above state machine with new approach:

In the above example, state machine transits to state S1, S2 or S3 based on packet P1, P2 and P3 which are either generated or collected in real time. Thus, illegal state transitions like S1 => S3, S2 => S1 and S3 => S2 can also take place. In BFM (instantiated in ACTIVE agent), one can make sure of all combinations of states and packet types.

In Monitor (instantiated in PASSIVE agent), illegal transitions and packet type and state combination can be monitored through coverage of state transition.

This approach requires careful planning in Sequence Library or Generation to avoid overhead in sequence library. One can plan and constraint based on ones requirement to avoid overheads.

As a solution, passive state machine may be implemented in VIP with Real Time Feedback. The benefits of this approach are:

* Generates a modular approach for having common algorithm of state machine.

* State machine is flexible enough to travel through all legal and illegal state transitions

* The ‘transmit first, transit hence’ approach enables re-use of state machine module for PASSIVE monitor. PASSIVE monitor executes its state machine based on what the DUT is transmitting. This avoids latency issues in PASSIVE monitor.

Nilesh Ranpura, is Project Manager & Pranav Joshi, is Project Leader, Chip/ASIC Division, eInfochips.