There’s a bit of repositioning going on in EDA-land. It involves Synopsys’s popular Verdi tool, acquired through the SpringSoft purchase. Conceived as a flexible debug tool, it also has an open scripting environment that gives engineers access to data in the fast signal database (FSDB) file. With that capability, folks have been bolting analysis utilities onto Verdi for a while on an ad hoc basis.
This hasn’t gone unnoticed at Synopsys, and they’re now in the process of repositioning Verdi: it’s not just for debug anymore. While it obviously still includes debug in its expanded portfolio, Synopsys is adding features that don’t necessarily fit the debug profile.
One of those is Verdi Coverage. This is intended to help build and track a verification plan that is tightly synchronized with the design requirements. This concept might be familiar to any of you that have seen similar tools in the software space from companies like LDRA.
The assumption here is that verification tests spring from requirements. (If it’s not required, then why are you testing it?) And all requirements should be documented in a requirements document. Verdi Coverage lets you tie tests to requirements and tick off coverage at the requirements level.
Where this can be particularly helpful is when requirements change. Yeah, it’s a thing; it happens. Who knew. Verdi Coverage tracks the requirements documents and can notice when changes occur. This allows you to go in and modify the verification plan accordingly, if needed.
How do they do that? They rely on the PDF file format for the document. Best practice is to use an outline structure in that document. They capture the text from the document, along with some meta-information about where the text is to be found.
And when the document changes? How can they pinpoint the changes? Diff technology. Off the shelf, actually. Apparently the ability to diff two files has gotten pretty good these days. (It’s not as easy as you might think: as soon as one thing changes, then everything after it might seem different unless you can identify the type and scope of the change and then get back on track with unchanged text.) The important thing is this: there’s no special formatting you need to do so that this will work. Write a well-organized, well-structured document (so that a human can process it well) and Verdi Coverage will be able to handle it.
Far from being a debug thing, this becomes a planning tool up front, creating a specific link between requirements and the elements of the verification plan. It applies across verification technologies (formal, simulation, etc.). As long as the requirements document is being kept up to date, there’s no reason for the verification plan to get out of synch with it.
You can find out more in their release.
