Is your Verification plan pulling you in multiple directions? Try FSM Coverage A quick look into FSM Coverage Sunil Sahoo, Corporate Applications Engineer Like(1) Comments (8) The verification process is long and time consuming, especially when you are not sure what you are looking for. There are a lots of directions you can go looking for bugs but without a guide, without a plan you will most likely be going in circles. A plan for verification is needed, and as the name suggests you need a Verification Plan. This plan consists of a variety of things that you can check you design against, like functional coverage, assertions, code coverage, etc. One of the most important and probably the easiest of these to verify is the code coverage, because unlike functional and assertion coverage, you don’t have to do a lot of work to enable code coverage. Lot of simulators have this function in built and you can enable it by just turning on a few switches. Code coverage comes in a few different types, the traditional statement, branch coverage. More complex expression and condition coverage. A more selective toggle coverage as well. All these types of coverage’s measure different kinds of metrics and each of them gives you a different insight to what your design is doing. There is also another type of coverage that can tell you how your state machine behaves and check if it is following your verification plan. This is known as FSM coverage. FSM coverage does require some type of input from the user regarding the machine properties in order for the simulator to collect the necessary metrics and display it as a coverage report. This can be done using pragmas in the code. A pragma is a line of code that starts with a comment delimiter for the language you are using. So if you are using SystemVerilog it starts with // or /*. If you are using VHDL it starts with -- SystemVerilog // one-line comment /* block comment */ VHDL // one-line comment /* block comment */ Aldec simulators support both the SystemVerilog LRM pragmas for FSM coverage and also has its own Aldec Proprietary pragmas. This allows this code to be used in any tool because for a tool that does not support these pragmas, it just looks like a comment. So for FSM coverage the first thing we need to specify is the state register. This can be done by: // Aldec enum fsm_enc CURRENT = state The CURRENT pragma name tells the simulator that the register cst is the State register for this state machine. Next we specify the states, any ignored or illegal states as well. // Aldec enum case1 STATES=start,stop,run We can then specify any transitions we want to see happening during our simulations. Also we can specify any illegal transitions that we don’t want to see. /* Aldec enum fsm_enc TRANS = fetch1 -> done, pad -> done, fetch1 -> fetch2, fetch2 -> fetch3, fetch3 -> encode, fetch3 -> pad, encode->fetch1 Aldec enum fsm_enc ILLEGAL_TRANS = fetch1 -> encode, fetch1 -> pad, encode -> pad, pad -> encode*/ Similarly we can then define any sequence of state transitions that we want to see happening in our design, /* Aldec enum fsm_enc SEQ = fetch1 -> fetch2 -> fetch3 -> encode, fetch1 -> fetch2 -> fetch3 -> pad */ also if you don’t want to a sequence of state changes happening you can specify that with ILLEGAL_SEQ pragma name. After you specify all of the above, when you run your simulation with FSM coverage enabled, the tool will automatically parse the information from the pragmas and then check your design to see if those specified properties for the state machine has been executed. The end result is part of the Aldec’s acdb file, which can be exported to a html or text report. Here is a sample report of how the FSM coverage looks: In this report you can see that all the states are reached and all the transitions you are interested have happened, the sequences that you wanted to make sure the state machine takes have also happened and lastly the transitions you didn’t want to happen, which are deemed illegal, did not happen. So all in all a report that you want. This report gives you an idea of how the FSM coverage helps you find which direction you want to go with your verification. If a state is missing you know exactly where to look to fix that problem. If an illegal transition occurs you know where to go and take a look to resolve the issue. This is how FSM coverage helps you verify your design, if you don’t have it yet, our simulators have this capability so go ahead and give it a try and let us know if it helps. Request a free evaluation. Tags:Coverage,Debugging,Design,FPGA,SystemVerilog,Verilog,VHDL
