State transitions as coverage bins
Why OSVVM™? › Forums › OSVVM › State transitions as coverage bins
Tagged: coverage fsm
- This topic has 5 replies, 3 voices, and was last updated 6 years, 6 months ago by Dave Ansell.
November 15, 2016 at 02:52 #1190
Is is possible to define a coverage bin as a state transition of an FSM? My final objective is to do a functional verification of an FSM with OSVVM, so any other ideas to achieve this are welcome!
JorgeNovember 15, 2016 at 06:51 #1191
I just found a blog entry from Aldec that solves my doubt
If anybody is interested, here is the link:
Maybe this type of example should be included in the OSVVM examples
JorgeNovember 15, 2016 at 11:01 #1201Jim LewisMember
I just fixed the link above. In all aspects it looked correct, it just did not work.
Apparently WordPress will change some special characters in a link if it is just pasted as text. Hence, a second step is required after pasting a link – select the link button, and paste the link into the link box also.
JimNovember 16, 2016 at 03:15 #1206
I didn’t know about this problem with links.
On the other hand, this example helps to verify if all the transitions have ocurred but does not keep track of what condition trigger this transition. ( In the example, there is only one signal (TMS) that triggers the transition.)
How can I implement the functional coverage keeping track of which condition triggered my transition?
I was thinking in the following:
1. Define a condition type as an enumerate type, and put here all the possible conditions that triggers a transition in the FSM. For example:
type conditions is ( C_rst, C_enable, …. etc.
2. Create a variable of this condition type in the coverage collector process. And update this variable with the status of the UUT (as it is done with the state variable)
3. Add this condition var as a third parameter to the addCross function. Ex:
One restriction of this implementation is that only one condition can be register per clock cycle.
What is your advice?
JorgeNovember 28, 2016 at 08:59 #1220Jim LewisMember
Your approach looks good. Some how you need to capture which arch is followed and make sure you have a bin for all possible archs in each state. How you represent it will vary from statemachine to statemachine. For machines like the JTAG controller, it uses the same basic inputs to each state. It may be more interesting when there is a larger set of inputs, particularly when an input is only used in a particular state and not others.
In addition to what you propose, you can recreate the entire statemachine input space within the coverage model. Each input then would be converted from a bit/std_ulogic value to integer (0 or 1). If an input is not used in a particular state, its value can be represented by ALL_BIN or GEN_BIN(0,1,1).
JimDecember 6, 2016 at 06:57 #1241Dave AnsellMember
- You must be logged in to reply to this topic.