Using SystemC TLM2 processor models

It is very easy to use the Fast Processor Models in SystemC TLM2 platforms.

An OVP Fast Processor Model is provided with a TLM2 interface in the form of a C++ header file. This is then included in the TLM2 platform source. It defines a SystemC module class specific to the processor type which can be instantiated in your platform. This class is derived from a generic interface, icmCPU (itself derived from sc_module). (OVP peripherals are instantiated in the same way.)

An Example Platform:

Each processor model is run from a SystemC thread. The thread executes InstructionsPerQuanta instructions on the processor without advancing SystemC time. Each instruction may or may not cause TLM2 transactions to be propagated to other components in the platform. When the allotted instructions have completed, the thread calls SystemC wait()to advance time. The SystemC scheduler will move time forward outside of these quantum executions. Thus each processor in a multi-processor simulation executes a number of instructions at a time in a round-robin schedule.

TLM2 allows comprehensive modeling of bus transactions, but each transaction adds a significant time overhead in the context of an instruction-accurate simulation. Direct Memory Interface (DMI) allows negotiation between two TLM2 models so that an initiator can directly access target memory, bypassing the TLM2 mechanism.

An OVP Fast Processor Model uses DMI negotiation by default. In practice, a processor with a fixed program memory will execute one code-fetch via TLM2. The DMI hint in that transaction will allow the simulator to map the program memory into its address space so that subsequent code-fetches do not use TLM2 transactions. DMI can be disabled with an optional argument to the model constructor.