Why I See C In SCE-MI

The two questions I hear most often while doing presentations about SCE-MI transaction based emulation are, “Can we have coffee break?” and “Why do we need a thin C layer between two SystemVerilog tops”?

You a probably reading this during a coffee break, so let’s jump to second question. It refers to this diagram showing how to connect a SystemVerilog testbench (usually UVM) with DUT in SystemVerilog using a DPI transactor, as defined by the Function-based Interface of SCE-MI.

There are two main reasons for this. First, the SCE-MI standard was designed with the assumption that a testbench will use C/C++ modelling environment such as SystemC. Second, DPI (SystemVerilog Direct Programming Interface) was designed as inter-language communication mechanism based on function calls, so the user can define function in one language (C or SV) and call it from another (SV or C). So to use the DPI interface between the SV testbench and SV DUT it is necessary to use thin C layer.

Fortunately if you are allergic to even a bit of C code, here are three options to avoid writing it.

1. SV-Connect
The latest version of standard, SCE-MI 2.3, introduces SV-Connect – a little feature that is very useful and makes you wonder why it wasn’t there before. It is simply the automatic generation of this thin C layer! All the user has to do is to follow the naming convention: each DPI function on HDL side should have it counterpart on HVL side prefixed with “svc_” (or any user-specified prefix) for pairing function calls with their definitions.

SCE-MI specification “encourages EDA vendors to produce C layer implementations that are transparent to the users”. For example, by using SystemVerilog VPI (Verilog Procedural Interface) to scan users’ sources to gather all necessary information from SV sources and automatically generate C layer.

A little trick—if you need more than a thin layer of C and have some logic in C code, you can still use SV-Connect to generate the templates to be filled with your implementation.

A function-based (DPI) model is ideal for modelling reactive communication (control signals, small data transfers), and SV-Connect is here to save the hassle of writing a C layer.

2. Pipes Interface
There are three interfaces defined in a SCE-MI specification: Macro-, Function- and Pipe-based, but only Pipes have API for testbench in SystemVerilog (in addition to C API), making them straightforward to use in a UVM environment. Transaction pipes are one-way channels for passing data from TB to DUT (input pipes) or from DUT to TB (output pipes). Messages are transferred using function calls (non-blocking operations) and tasks (blocking operations).

In addition to this, Pipes have very useful features for variable length messaging—meaning that you do not have to send predefined amount of data, it can be changed in runtime. So the first feature is the End-of-message marking mechanism, a flag to show that this is end of packet. Let’s take an ethernet transactor as an example. The smallest payload is 46 bytes, largest 1,500 bytes (or more than 9,000 bytes for jumbo frames). With SCE-MI Pipes there is no need to pre-define the size of message and send 1,500 bytes for each frame, whether used or not—so for smallest payload it is enough to send 46 bytes instead of 1,500, just marking byte #46 as EOM.

Another useful feature is data shaping. Pipes can act as nozzle (think SIPO—Serial Input Parallel Output) or funnel (opposite—Parallel Input, Serial Output). So if Ethernet DUT outputs 32-bit of data on each clock we can use the nozzle pipe and read whole payload (does not matter—46 or 1,500 bytes) in the testbench at once. Also, for example in video applications, we can generate a whole line of picture, or even a whole picture frame in testbench, use the funnel pipe and reading it in hardware pixel-by-pixel, or whatever is convenient.

Pipes-based model is perfect for batch communication (streaming large amounts of data) and comes with added benefit of SV API (along with analogous C API).

3. OTS
Or you can skip the coding, keep reading articles and drinking coffee, and just use off-the-shelf transactors, also known as synthesizable VIP (Verification IPs). In this case, you’ll need a marketing pitch for your manager… so here you are.

Purchasing VIPs:

• Ensures independent implementation of VIP and IP—the key thing in quality of verification.
• Reduces time-to-market—providing complete testsuite and accelerating testing process.
• Provides better human resources management—team can focus on differentiating product not on writing low-level tests.
• Lowers risk of failure (e.g. respin).

To conclude: there are ways to use SCE-MI without writing a line of C code, staying in the realm of verification, and design-friendly SystemVerilog. Ahhhh, and in case you wondered—I drank six coffees writing this article.