Hello,
I’d would like to hear feedback on a topic that I haven’t fully grasped: fsm coverage.
Nowadays tools are able to extract an fsm from the rtl description and measure state and arc coverage automagically, but I’d like to better understand how to make sure the fsm is matching our expectation (i.e. specification).
Often when an fsm is specified in a digital spec. it’s usually buried under many layers of hierarchy in the design and it acts and reacts on internal signals that are often consequences of external events. If I want to create functional coverage (like state transition coverage, or assertion coverage), I would need to extrapolate the external events and somehow deduce from it how the fsm should behave. This “abstracted view” of the fsm behavior may not necessarily match the true implementation, let alone timings, so it’s difficult to sample coverage appropriately (e.g. how long will it take for the state to transition once the event is observable on the boundary of the dut?).
Another approach would be to “model” the fsm, recreating it from the “abstracted view” and then make sure we cover all possible legal paths. This approach though will simply ensure that our model matches the abstracted view and does not tell much whether the rtl is behaving correctly.
At this point I’m stuck in my though process and I’d like to hear out from this community on how to approach this problem and whether there’s any practical solution to it.
By the way, along this journey to understand how to cover the fsm I haven’t found much in the public domain, the only reasonably legitimate article was this one.
In reply to abasili:
FSM coverage is closer to code coverage than it is functional coverage—necessary but not sufficient. Unless the states are visible through some register interface, an FSM is part of the implementation and functional coverage needs to be sampled though external interfaces.
FSM coverage makes it easier to check that all states have been reached, and formal tools can easily check for deadlocks.
You should also read this article.
In reply to dave_59:
Thanks a lot for the pointer, I like the generator idea. If I understand well the generator gets installed in the test whose responsibility is to configure the dut with some startup sequence and then it will “hand control” to the generator which will randomly choose from which state to which state it will go through.
It’s a little less clear from the article how the model is going to be compared to the dut behavior. Assuming, as you pointed out, that we have access to the fsm states through some register access protocol of some sort, if the model is able to “predict” what’s the next starte going to be based on the stimuli, does it mean that a separate process is going to continuously perform register access to the fsm state so a transaction can be generated and closed against the model prediction in a fifo scoreboard (assuming the model is not cycle accurate)?
What if the register access protocol is too slow to capture all state transitions? Does it mean we only check initial and final state?
In the majority of the cases the VIP will perform many protocol checks, how much added value would the model comparison bring in this case? Wouldn’t the generator be sufficient to make sure we crossed all the states and all the arcs?
When it comes to functional coverage then, are we assuming at something fsm register coverage and transition or is it sufficient to sample coverage from the generator itself?
I’d be happy to read more references if necessary! Thanks a lot!