x-heep icon indicating copy to clipboard operation
x-heep copied to clipboard

[Question] External process communication, using a file

Open francisco-rente opened this issue 9 months ago • 4 comments

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 public_flat", 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.

francisco-rente avatar May 07 '24 17:05 francisco-rente