[Question] External process communication, using a file

[francisco-rente]

Hello, I'm currently developing a Coarse-Grained Reconfigurable Array simulator, with the intent of using it in a co-simulation environment with a RISC-V co-processor. I've chosen x-heep and at this point, only require a Verilator simulation level. The difficulty relies on the communication part, since the CGRA simulator is an external process to the x-heep environment. Please keep in mind I'm extremely novice at working with HDLs.

For this purpose, I need a bidirectional channel capable of transmitting data between the CGRA and the RISC-V, and ultimately, I may resort to using a simple temporary file for a proof-of-concept platform. I would have to implement a read-and-write mechanism that, in essence, transfers and reads bytes from/to the simulated CPU. A simple flow would be to use "commands" stored in the x-heep's processor memory (at a predefined address), which is then analyzed in the main test-bench and forwarded to a file (or eventually a pipe) that the CGRA Java process could read and interpret.

I've searched through the code and documentation, which mentions an EXT_SLAVE_START_ADDRESS, although I'm not completely aware of its functions. Is there a way to expose and access this external memory in the tb_top.cpp, by address value? I've seen the possibility of "_verilator publicflat", but don't know if it applies to whole memory contents. Another approach my thesis advisor recommended is overwriting the ecall handler of the CPU, storing the action in a determined memory address, and once again, reading it and writing it to a file in tb_top.cpp. Are these approaches feasible? If so, how can I access memory contents in the main verilator test-bench?

Any help would be appreciated. Thank you.

[davideschiavone]

Hi @francisco-rente , try to have a look at the systemC example where the RTL from X-HEEP is first bridge to a SystemC class to respect the protocol, then it becomes software only. In your case you would need to adapt the memory only interface with something that both read and wrote into the xheep memory

[francisco-rente]

Hello, @davideschiavone . First of all, thanks for the feedback and help. What we have right now in our fork is a similar behavior to what you described in your comment without SystemC. We incorporated a CGRA mock interface (in RTL) that overrides reads/writes in its address with C DPI calls. These connect and communicate with the other process using a Unix domain socket.

For now, it serves our proof-of-concept purpose nicely, but in the future, we will look into the SystemC bridge, as it may allow for better configurability and offer advantages regarding the protocol and performance estimates.

[davideschiavone]

@francisco-rente what you are doing is very interesting, would you like to submit a PR to this documentation file https://github.com/esl-epfl/x-heep/blob/main/docs/source/How_to/eXtendingHEEP.md with a link to your fork a short description of what you are doing in that fork? Thx, also, if I may ask, what is your university or company?

[francisco-rente]

Certainly! It is expected that until the end of the week the repo will move to a different place, in order to ensure the continuity of the project, but we'll try and create the PR during this week. I'm currently finishing my master's research at the SPeCS laboratory of the Faculty of Engineering of the University of Porto (FEUP).