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.

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 1500 bytes (or more than 9000 bytes for jumbo frames). With SCE-MI Pipes there is no need to pre-define the size of message and send 1500 bytes for each frame, whether used or not – so for smallest payload it is enough to send 46 bytes instead of 1500, just marking byte #46 as EOM.

For the rest of this article, visit the Aldec Design and Verification Blog.

Tags: direct programming interface, IP, sce-mi, system c, system verilog, systemverilog

Categories: IP, sce-mi

This entry was posted on Friday, March 18th, 2016 at 2:36 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.