Do Not Forget to 'Cover' your SystemC Code with UVMC

For decades, it is known that SystemC is used for modeling high levels of abstraction which can be used with SystemVerilog components. One of its greatest strengths is the versatility in mixed language designs offering various mechanisms and constructs required for embedded systems modeling. But when it comes to verification of those SystemC models, it is important to verify them at any level of abstraction, especially when it involves mixed languages. Today’s modern system designs consist of multiple architectural components, involving a combination of hardware and software.

SystemC enables a high-performance simulation of system behavior and creates accurate and efficient models of hardware-software components. Although the complexity of the systems can be handled using abstraction levels offered by C/C++/SystemC, verification of these is always a bottleneck.¹ SystemC is arguably becoming a standard and is widely being adopted by the industry for system-level modeling, hence it makes sense that the verification is extensively performed.

Unfortunately, when it comes to performing cover checks in the SystemC model directly, currently there is no standard. There have been attempts made by creating a functional coverage library for SystemC² and TLM³ to name a few. But what if the model utilizes UVM Connect⁴ along with transaction-level modeling (TLM)-1.0 or 2.0?⁵

Further investigation and research are needed to ensure the IEEE 1647-2016⁶ functional coverage language features are supported in developing such libraries that would eventually become a standard in the future. Until then, in this paper, I have come up with a familiar solution of utilizing functional coverage usage by exporting them from SystemC to SystemVerilog each time a sampling event is called on the SystemC side.

First, I will share some background on coverage analysis and SystemC modeling using UVMC. Then I will provide an illustration of the workflow and demonstrate this approach with examples and results. Finally, I will summarize what we covered and suggest future work and provide references.

Background

Coverage Analysis

Functional coverage is a metric used to measure how effectively the verification system or a design under test (DUT) has verified the system's functionalities. It is separate from other coverage metrics like code coverage, state machine coverage, assertion coverage, and so on. It is employed in all forms of verification. Functional coverage not only determines if a DUT is functioning properly but if you have done verifying the chip.⁷ As mentioned in the IEEE Std 1647, the process of measuring functional coverage involves three steps, as follows:

• The user builds a coverage model, representing key architectural and microarchitectural features of the system being verified
• Coverage data is collected during the simulation and accumulated for analysis
• Coverage information is aggregated across many simulations and is analyzed to produce coverage scores

A coverage model includes one or more cover groups, which represent a data set to be sampled under certain conditions, typically with a sampling event. For each occurrence of the sampling event, each cover item samples one value and assigns that value into bins that the user has set. This approach is effective in creating a checklist to check, inserting them in the source code, and ensuring that every task is covered during verification.

Now the approach would be to send packets of data from the SC side to the SV side which can be used for sampling functional coverage each time the sample event is triggered. This way, verification of highly abstract components and system models can be done using TLM ports and sockets and the data can then be de-serialized on the SV side for functional coverage.