The VProc virtual processor and the mem_model sparse memory model (part of pcievhost) components form the heart of the co-simulation for the opencpcie2-rc top level simulation test bench. The soc_cpu.VProc is based on the virtual processor and the memory used by the running programs has access to the memory model's space. Logic can also access the memeory model's address space with an provide HDL component. This component is also used in the PCIe interface driver block, and the code running on the pcievhost VIP's VProc also has access to the same memory via the API. Thus, these components are tied together tightly.
The VProc virtual processor is a VIP co-simulation component that allows a natively compiled user program to be “run” on an HDL processor component instantiated in the logic. C/C++ APIs are provided to initiate read and write transactions on the VProc HDL bus, and for the advancing simulation time.
VProc has a generic memory mapped bus and this would normally be wrapped in a module to convert this to a standard bus or interconnect protocol, such as AXI or Avalon but, for opencpcie2-rc, the bus is converted to the local soc_if interface with some simple logic. Multiple VProc test programs components can be instantiated, each with a unique “node” number.
Since the simulator is Vivado, the connection between software and HDL is done using the SystemVerilog DPI-C interface. The details of connection between the HDL and running user code won’t be discussed here but suffice it to say that the user program is running in its own thread and the VProc layer software provides both the API and the means to synchronise the user program with the simulation, keeping both in lock-step but allowing the user program to be free flowing code. For each instantiated VProc node the user code has a specific “main” entry point of the form VUserMain<n>, where <n> is the VProc’s node number: e.g. VUserMain0, which must have C linkage for DPI requirements. The user programs are compiled into a library and, along with a VProc code library, are linked into a shared object, VProc.so, which is loaded by the simulator at run time. There are both C and C++ low level APIs available to user programs and abbreviated versions are shown below.
As well as basic read and write transactions methods, there is also a “tick” method. User programs run infinitely fast with respect to simulation time, so simulation time is advanced when a transaction method is called but can also be advanced with the tick method without a memory access transaction. Using these APIs directly gives the means to construct pure test programs that can run on the soc_cpu.VPROC component to drive the CSR registers in the core logic and instigate operations. A very simple program of this nature is shown below.
The opencpcie2-rc test bench makes use of the mem_model co-simulation component HDL. This consists of a sparse memory model , written in C as part of the pcievhost IP, with co-simulation capabilities via a mem_model HDL component with various Avalon style ports for memory mapped, burst and write functions. Code running in VProc can access the C model directly via an API, with an abbreviated version shown below.
The write functions take address and data parameters and, for wider words, a little-endian flag (le) to select between endian
modes. The read functions take an address and (where appropriate) an le parameter and return the read value. All functions have a node parameter. Note that the “node” in the API functions is not the same as for VProc but refers to individual address spaces. In almost all use cases this will be the same and is 0.
This model can also be accessed from the HDL using the mem_model HDL component, which may be instantiated any number of times, but always accesses the same memory. This allows multiple VProc virtual processors and the simulated test bench logic to access a common memory space.
The 5.sim/models/cosim directory contains library code for the VProc virtual processor and mem_model sparse memory model co-simulation verification IP, suitable for the Vivado logic simulation environment (other simulators are not supported at this time). This directory contains the HDL modules for the two components, with the HDL top level modules being f_VProc.sv and mem_model.sv, which reference the sub-modules (f_VProc.v and mem_model.v) along with the Verilog header files, with `include inclusions. Thus only these top level files need to be compiled and this directory included in the search path, though this is all taken care of in the MakefileVProc.mk make file in the 5.sim/ directory.
The DPI software for both the models is pre-compiled into a static library as lib/libcosimlnx.a (with a lib/libcosimwin.a version for use with the MSYS2/mingw64 environment on Windows). The headers for the models are placed in the include/ directory. To use the models' APIs, the user code must include either the VProcClass.h header for the VProc C++ API, or VUser.h for the VProc C API, and the mem.h header for the memory model C API. Note that the VUser.h and mem.h inclusions must be wrapped as C linkage if included in code that will be compiled as C++. E.g.:
extern "C" {
#include "VUser.h"
#include "mem.h"
}
This is only applicable when writing natively compiled simulation test code. When compiling the application code natively for VProc, the headers will be included correctly by the co-simulation hardware abstraction layer (HAL).
More information on using these co-simulation models can be found in the VProc manual and mem_model manual.