原创 Learning OVPsim and ModelSim Co-simulation

Thu Jun 30 2010 19:47:40 GMT+0800 (CST)     After I downloaded the latest 20100528.0 release, I ran the OVPsim examples and recompiled the examples. A license is required to run the recompiled examples! A license is also required to run the pre-compiled demos for ARM and MIPS platforms to boot Linux OS. Obtaining a free 90-day evaluation license for the first time is easy, but any commercial usage of OVPsim is charged.
    Then I read the Hardware/Software Co-Verification Using the SystemVerilog DPI paper. The synchronization between the ISS and the logic simulator can be achieved by calling exported SV task from C. The ISS written in C is a slave of the logic simulator: the C model should be called in the SV environment to execute one or a certain number of instructions for every system clock cycle. This near cycle-accurate synchronization slows down the whole system simulation, but it is the only way for the CPU model to catch a interrupt in time, which is generated by the hardware being simulated in the logic simulator.
    My current object is to build a co-simulation environment without interrupt, so the synchronization mechanism can be a little different. That is to call the exported SV task only when the address, where the hardware stub is mapped, is accessed. This is a "sync-on-demand" mechanism, which is more efficient than a "sync-every-time" mechanism, although it lacks the ability to sync the interrupt event.
    My task for the following study should be:
1. SystemVerilog DPI programming.
2. OVPsim platform building.
3. OVPsim peripheral building.
4. OVPsim compilation with DPI awareness.

Thu Jul 01 2010 20:58:55 GMT+0800 (CST)     I ran the DPI and PLI examples provided in the ModelSim User's Manual. I made scripts to run these examples easily. DPI is much simpler than PLI. And it allows C to call back into Verilog. This callback cannot be done with PLI.
    I modified the DPI example to call the OVPsim generated shared library (.so file) from ModelSim simulation.
    Taks 1 is accomplished.

Thu Jul 02 2010 21:59:13 GMT+0800 (CST)     After I studied the platform building document and the PSE peripheral modeling document, I ran and recompiled the "creatingDMAC" example.
    For my purpose of writing a peripheral with hardware stub and no real function, I should study and try to modify the simple example of "1. registers". This example adds a series of simple write-and-readable registers to the system bus on the platform.
    Task 2 is accomplished.

Thu Jul 06 2010 22:51:24 GMT+0800 (CST)     Fortunately I referred to the OVPworld Forum for discussion on interfacing OVPsim with HDL simulator. And I found the topic of "Interfaces to HDL Simulator". It guided me to study the "icmMapExternalMemory" usage in the platform building document. This saved me much time to study the peripheral modeling technique. Without a peripheral model, the platform and the co-simulation environment can be much simpler.
    I studied the "Adding Memory Callbacks" and "Explicit Local and External Memory" chapters. And then I ran and studied the "watchpoint" and "memory" examples.
    I modified the "watchpoint" example to synchronize the simulation of the OVPsim platform with ModelSim. There was printings from SV saying that the SV task was being called by the C model. The modification of the Makefile was easy thanks to the Makefile provided in the "watchpoint" example and the Modelsim DPI compilation script.
    Task 3 is accomplished: external memory callbacks can be used instead of stubs embedded in peripheral models.
    Taks 4 is accomplished: OVPsim platforms can be compiled with DPI awarness.
    My following task will be:
5. Pass value across the C and SV boundary.

Thu Jul 07 2010 22:29:46 GMT+0800 (CST)     I modified the "memory" example to allow the hardware simulated in ModelSim to provide real responses to the CPU model. This is not an easy task since I have almost forgotten the usage of pointer in C. Finally I got the pointer operation right and the value can be returned from SV to C. I studied the Doxygen ICM API to find the detailed usage of icmCpuManager::icmMemCallback class.
    A top-level HDL simulation is built (top_ovp.v). An HDL BFM (bfm_ovp.v) is connected to a behavioral HDL RAM model (ram_ovp.v) and the HDL BFM is controlled by the C model (bfm_ovp.c). The C model is called by the HDL BFM model in a Verilog initial block. This initial block starts when the HDL simulation begins and runs as a separate thread until the C model returns, that is when the OVPsim platform simulation finishes. Every time the address, where the RAM model is mapped, is accessed, a callback will be generated from the C model to the HDL BFM and the RAM model responses to the read/write transaction. The callback returns when the exported HDL task in the BFM finishes. This introduces delay in the C model and syncs the two worlds of C and Verilog.
    From a hardware designer's point of view, because the HDL BFM is actually a wrapper for the OVPsim platform C model, the whole simulation environment is a CPU-driven testbench for a behavioral RAM model. From a software designer's point of view, because the HDL BFM provides a link to a functioning HDL model, the whole OVPsim platform is complete and ready for software development and debugging.
    With a few lines of OR1K assembly code, read-after-write transactions were generated from OVPsim to ModelSim. The printing showed that the data read back was correct and the waveform in ModelSim showed that the reading and writing was generated perfectly from the BFM to the RAM.
    Task 5 is accomplished. My following task will be:
6. Run an embedded C application program on this platform with HDL RAM model.

Thu Jul 08 2010 22:00:21 GMT+0800 (CST)     I added C code of dhrystone.c as an application program for the embedded OR1K processor. Unfortunately it stuck at the beginning of the simulation (reason unclear).
    I modified the platform to run a PowerPC32 processor and the co-simulation ran almost as fast as simulation ran alone in OVPsim. I randomly selected the address span of 0xffffff90 ~ 0xffffff9f to be modeled in HDL and all the dhrystone, fibonacci and peakSpeed applications ran happily without error.
    Task 6 is accomplished.
    I need to study the Linker Script to understand the memory allocation and find a proper target address span where the HDL model should be mapped.  This will enable my following task:
7. Run an embedded Linux OS on this platform with HDL RAM model.

Thu Jul 15 2010 08:00:21 GMT+0800 (CST)    I used the 'objdump -h' command to show the section addresses of the ELF application file. The result is the same as shown in the icmLoadProcessorMemory function during the loading of the ELF file. I chose the .data section of 0x1001d538~0x1001dd7f as the address span where the HDL RAM model is mapped. The simulation ran to the end without error and the HDL RAM model was accessed several times.

    However, this success does not mean that I got the whole linking-loading-accessing process right. First, I still don't know how to modify the Linker Script to direct the linker to map the HDL RAM model to a fequently accessed address span.  Second, the icmLoadProcessorMemory function loads the implicit RAM memory with the ELF file, but it cannot initialize or load my HDL RAM model. Relying on the linker or icmLoadProcessorMemory function does not provide adequate control for my purpose of verifying the simple HDL RAM model. I need to study the examples provided in the OVPsim installation, which will show me how to access physical addresses in embedded applications with C code.

    To accomplish task 7, I should re-accomplish task 3 as originally planned: build an OVP peripheral model with link to an HDL model where the function of the peripheral is implemented.

Useful Links:
Hyperstone Builds a Better Co–Verification Environment with Questa SystemVerilog DPI
Using a processor-driven test bench for functional verification of embedded SoCs
Specification-driven functional verification with Verilog PLI &VPI and SystemVerilog DPI
ScriptSim: Seamless integration of Python, Perl, and Tk with your Verilog simulations
Using VMM, DPI, and TCL to Leverage Verification and Enable Early Testing, Emulation, and Validation