I’m more interested in how the tool fares in complicated situations. I recently went through coverage closure for an NPU block the old fashioned way and would like to describe one particularly difficult coverage point.

An instruction would cause a local ring buffer to move through a packet. This instruction specified how far to move in the packet and the minimum data available in the buffer. The instruction could have both immediate and register operands. Zero, one or two requests for more data could be issued by the DUT depending on the instruction and current state of the buffer. The state of this internal buffer was affected by previously executed instructions _and_ direct environment randomization at safe times in the instruction stream (to provide good coverage). If a request for more data was issued, a response was randomized by the environment. The “simple” coverage point we were interested in was ensuring both the first and second response had started and ended at all words in the buffer (i.e. responses had been written starting and ending at all buffer locations).

If this technology can identify the constraints that need to be modified to close this coverage point I would be impressed. This alone is difficult (manually) given the interconnectedness and non-liner relationships. If the tool could _automate_ the closure of this coverage point I would be sold! Do you have any comments about this problem?

Closing _code_ coverage can also be a painfully manual and time consuming process. Do you have any comments about applying this technology? A user could always write an RTL internal coverage point that _directly_ correlates to unexecuted code but if the technology automated this process that would also be impressive.

So, I’m still skeptical but hoping to give this a try….

Your skepticism is understandable and you certainly raise some very legitimate points, let me try to address them in order.

1. Coverage Target Complexity
As you correctly pointed out not all coverage points are created equal. Automatic convergence on stimulus coverage points
is relatively easy whereas on coverage points that sample say checker signals, and capture end to end design
functionality is extremely difficult. However, there is a wide of coverage targets that lie in between so the question
becomes how far along this continuum can the technology be pushed.

2. Coverage/Constraints Description
There are no restrictions on how either the class constraints or the coverage targets can be described. From the get-go
the technology was designed to be used on existing designs and verification environments without the need
to capture constraints/coverage targets in different formats. Currently, SystemVerilog and Vera are supported.

3. Capacity
Although it makes use of formal techniques, the technology is not based on pure formal analysis and does therefore not
exhibit the same memory behavior as traditional formal tools. The memory scalability profile is closer to that of a
simulator although in absolute terms is will obviously use more memory.

4. RTL assertions
There is nothing intrinsic to the technology that would prevent it from targeting cover properties and assertions.

5. Customer feedback
There is another interesting article on Deepchip (http://deepchip.com/items/0479-05.html), not sure if you had a chance
to read it.

Ultimately, the success of the technology will be determined by its ability to improve the customer’s coverage closure
process. That process involves not only targeting coverage points on low probability paths but also identifying
over-constrained randomization, un-reachable coverage points, testbench bugs, etc. Even if this technology won’t be able
to hit any cover point in any design regardless of complexity, it will surely provide its user with a wealth of useful
information that would otherwise require long hours of manual effort to collect. This by itself will significantly improve
what is now arguably the most painful verification task.

I am very skeptical about the automation of input to internal or output coverage. Any reasonably complex design will have a VERY complex relationship between the inputs and outputs that includes fixed design configuration (pins and registers), the current state of the design and the applied inputs. I would challenge this tool to automate closure on even something as simple as a PCIE DMA controller. Can coverage and constraints be written in a natural way or does the tool require some special assistance? What about capacity issues that pure formal verification tools still struggle with? Your diagram also shows coverage on the DUT. Does this imply RTL assertions? In many cases collecting coverage from a reference model is the most efficient way to collect coverage at a higher level of abstraction. Using this example this would be coverage on a complete DMA operation VS the individual register operations to configure that operation. Would the tool be able to utilize coverage in this form?

Arguably the reality of formal tools is falling well short of the marketing promises. I see lots of hype regarding nusym in deepchip (http://www.deepchip.com/items/0475-02.html) but not much in the way of actual users saying it really saved time. Is there any customer feedback on real designs?