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 3-month-license for the first time is easy, but it is difficult for the second time.
    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.       19057498651545.zip
    I modified the DPI example to call the OVPsim generated shared library (.so file) from ModelSim simulation.

19057691475250.zip
    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. 19057842488102.zip
    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.19057982102407.zip
    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 runs as fast as simulation run 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.19058115487748.zip
    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.


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