Aldec Design and Verification
Jacek Majkowski, Senior Hardware Engineer
Jacek Majkowski is a Senior Hardware Engineer at Aldec, and a specialist in SCE-MI Co-emulation. Prior to his current role, Jacek spent 7 years in the field of hardware assisted verification. Jacek received his Master of Science in Electrical Engineering from AGH University of Science and … More »
Why I see C in SCE-MI
March 18th, 2016 by Jacek Majkowski, Senior Hardware Engineer
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.
Fortunately if you are allergic to even a bit of C code, here are three options to avoid writing it.
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.