For last couple of years myself and my team is developing Accelerated TestBench for our multi-million SoC with several ARM processors on it. This whole concept of simulation acceleration is exciting for me because of the long waiting hours on simulation environment is reduced into few minutes in emulation setup. However, developing a testbench needs a unique approach since the boundary between the HVL and HDL have to be clearly defined and efficiently connected. This connection made between the HDL and HVL can be done using either of methods such as DPI, SCEMI and MARG. However, the popular among them is SCEMI pipe because of its easy of use and higher level of abstraction.
The choice of languages for developing the HVL layer are several and among them the popular are C++, C , System-C, System-Verilog, UVM and e. I did spend significant amount of time in developing HVL using C++, System-C and UVM. Lets see my understandings on the Advantages and Disadvantages on each of this language for developing ATB.
C++ based HVL layer:
The C++ functions in the HVL layer is triggered by the DPI function in the testbench. However the data transfers are done through the SCEMI pipe. Variable length data transfer is a tough nut with DPI, but quite easy with SCEMI.
Advantages:
It is the fastest since the computational overhead in the HVL layer is the minimal.
Disadvantages:
By default, everything is in a single thread. Once the ATB moves into handling more complex scenarios which has to service interrupts independently using another slave thread, we will need to have a multi threaded environment. To use multiple threads we need to use the boost library which requires an expert hand in C++ and significant amount of time on setting up this non-reusable code.
System-C based HVL layer :
Unlike C++ functions triggered by the DPI call in the testbench, the System-C based HVL layer is triggered by its own in the beginning of simulation. The System-C can have several concurrent threads working parallelly from the start itself.
Advantages:
Advantages of C++ along with threads using SC_THREAD. More RTL friendly programming is possible since we have the bit/byte data types.
Disadvantages:
For debugging, we have to manually add print statements and methods into the classes, structures etc. Randomization of structure/class is a pain since it take a lot of code, even to randomize a small set of variables in structure.
UVM System-Verilog based HVL layer :
In UVM based testbench, the HVL layer is the actual top for the simulation, where in other languages, the hdl testbench is the top.
Advantages:
Strength of UVM such as defined hierarchy, easy to understand others testbench (if you know UVM), excellent debuggability because of built-in helper MACROs, etc.
If you are a single contributor for the development of ATB, C++ or System-C may be the best choice. If there are several contributors involved, UVM is suggested method. It is because, the uniform debug options and hierarchy will help the engineers other than the owner of the module to understand the data flow and debug it.
Disadvantages:
Slowest among all the methods because of the large computational overhead which will make the Emulator to wait for longer duration between transactions. Protocol layering is almost not possible because one UVC cannot drive another UVC. It is because, as per the UVM, a driver cannot call a sequence. Hence the driver of upper layer cannot call the sequence of lower layer. If you are only accustomed with pure C or SV testbenches, you might have not come across this issue since calling one function from another function is simple.
Comparisons:
With C++ based ATB, the speed is coming with the cost of lower debuggability. However, if speed is of the utmost concern, this is the right choice.
| HVL Languages | Emulation Speed | Ease of Implementation | Abstraction | Multiple processes | Debuggability |
| C++ | Fastest | Easy | None | Not easy | Low |
| System-C | Fast | Randomization is hard | Low | Easy | Low |
| UVM (SV) | Slowest | Easy | High | Inherent | Very High |
Emulation Speed:
Emulation speed, our main goal, is affected by several factors. One among the major contributor that slows down the emulation is number of synchronization required between HDL with HVL. To synchronize, the free running clock in the emulator have to be stopped until the synchronization completes. Whenever there are significant amount of clock stopping happens, the total time required for the completion of emulation goes high. However, the synchronization is unavoidable, but it depends on how fast we can service the request from the SCEMI pipe. Larger testbench such as UVM, will take more time to service the SCEMI requests.
Abstraction:
One interesting difference between uvm based testbench vs c based testbench is that, in c based testbench the environment instantiates testcase, where in uvm, testcase instantiates environment. This is kind of inside out scenario. Now, if you ask about the advantage of this approach, I have noticed two of them. One, you will be able run any testcase by command line arguments at run time. Second, if the testcase needs a slightly different environment or driver to accommodate a unique scenario, then it is a piece of cake with uvm.
Conclusion:
With C++ based ATB, the higher speed is coming with the cost of lower debuggability. However, if speed is of the utmost concern, that is the right choice. System-C is better than C++ because of its hardware level abstraction and even C engineers (Firmware Engineers) can write good ATB. UVM has the best debuggability, but you need to have engineers those are well trained with UVM methodology for developing a acceleration friendly ATB and also expect a lower emulation speed.
Useful Abbreviations:
HDL –> Hardware description language, is used to design digital logic Eg: VHDL, Verilog
HVL –> Hardware Verification language, is used to Functionally verify the digital logic designed using a HDL Eg: e, system-C, system-Verilog
References:
1) http://www.cadence.com/rl/Resources/white_papers/UVM_OVM_Accell_WP.pdf
2) http://www.cadence.com/rl/Resources/conference_papers/1.4_presentationIndia.pdf