Coverage Data Exchange Is No Robbery…Or Is It?
Over the last few years all the major vendors have realized that unifying the way coverage is stored in a common database allows the results of multiple verification tools to be combined and for these tools to share the data to improve coverage closure. Simulation, Emulation and Formal engines should all be using the same database to provide the user with the complete picture, and allow the analysis of all data in a common way.
-
Body
Over the last few years all the major vendors have realized that unifying the way coverage is stored in a common database allows the results of multiple verification tools to be combined and for these tools to share the data to improve coverage closure. Simulation, Emulation and Formal engines should all be using the same database to provide the user with the complete picture, and allow the analysis of all data in a common way.
By defining a common data model all tools can write and read coverage and benefit from the combined strengths of all verification techniques. Accellera’s UCIS subgroup was a technical working committee formed to define a common API, data model and provide a way of exchanging data between multiple vendors and multiple tools. The data model is an extremely important aspect of data exchange and is what complicates the sharing of data amongst proprietary formats. With functional coverage this is a little more straight forward due to standards like SystemVerilog but code coverage can be more complicated, this paper will examine the difficulties with both and illustrates how there is a requirement of some intelligence within any application doing the data transfer.
XML is an excellent exchange format however because it’s verbose, capacity problems often arise even when processing even average sized designs. One trick is to compress the ASCII data to reduce the disk space, but this adds to the processing time. For the best capacity and performance an application built upon an API to extract data from vendor A and passed onto a second application built upon vendor B is a better solution.
The application cannot only exchange data but it can also do any manipulation required. One weakness in the XML interchange use model: when there is a mismatch in two vendors’ supported XML interchange formats, it’s not possible to simply import the output generated by the other. Using an application that can manipulate the data received from the source database allows changes/updates to the data before sending to the receiving end.
This paper will present a complete solution for moving data from one UCIS-compliant database to another. Some third parties do not have support or have limited support for the UCIS API so this solution will also show how the same method can be applied using two different APIs to provide interchange of coverage data.