Device driver development with the OSCI systemC library.

[Vijayvithal]

I have a systemC model of a Hardware under development.

The device driver development team would like to use this model for developing and testing the device driver.

I am currently trying to figure out what is the recommended method of interfacing the systemC code with the device driver code.

for e.g. if the driver calls a macro/function as follows:

regwrite(address,data);

I want this to trigger a method call on the systemC top module instance (say DUT) as

DUT.regwrite(address.data);


Is IPC the only possible way?
Is it possible to link the systemC code with an external driver code and create a single executable? If yes how should this linking be achieved and what needs to be added to main() to achieved the effect described above?

Please provide Pointers to example code/tutorial's  or any other information. which addresses this issue.
 

[Eyck]

What you can do is build your driver software as a shared library with a main function. In a SC_THREAD you just load the library and execute the main function. Along with this you have to implement a few utility functions (read, write, wait) which interact with the SystemC kernel or your DUT and being used by the main function (and the called functions from there). This is called host based or host compiled simulation (you may check the search engine of your choice for it). With some infrastructure it is even possible to mimic interrupt.

Another option is to use some instruction set simulator (e.g. QEMU, DBT-RISE-RISCV, or some commercial alternatives) and do you driver development using a virtual prototype...

Best regards

[David Black]

I think there are a few more options, but first, you need to acutely aware of the issue of OS thread safety. The SystemC kernel is not generally thread-safe unless you use async_request_update(), and a queue. I've done this several times.

That said you have several options:

1. Place software inside a SystemC SC_THREAD and provide convenience methods to initiate TLM transport calls. This is the simplest SystemC approach, but does not allow for modeling the actual CPU planned to be used and hence timing is not very accurate. This has the fastest performance from the SystemC point of view.
2. Place the software on a development board that has the target CPU and some type of communications to the machine where you will run SystemC. I generally use TCP/IP sockets. Replace the driver with a special socket call passing packets to to a remote machine and receiving back the response. On the SystemC side, create an OS thread to receive the socket and inject the message into SystemC via the async_request_update call and an unbounded STL queue or FIFO of some type. A TLM 1.0 FIFO might do. A receiving thread can then pass the data into the SystemC simulation and return the result. This is somewhat more overhead, but allows for a more accurate target CPU.
3. Obtain an ISS (Instruction Set Simulator) for the target processor and interface it to SystemC. This varies in complexity. You might look at existing models or talk with vendors such as Cadence or Mentor. Or perhaps your CPU vendor (e.g. Arm has some very nice models). As @Eyck suggested QEMU, DBT-RISE-RISCV. Also Gem5 (Google it).