.
├── gem5 # Modifications to the gem5 part of RVipc
├── ipc_bin # IPC binaries to test
├── riscv-opcodes # Macros to build a custom toolchain
├── toolchain # Modifications to official RISC-V toolchain
├── shm / other testing scripts
└── README.md
Let Hart 0 be the producer, and Hart 1 be the consumer.
- Hart 0 issues
fcreatewhich sends a request to the pool to initialize a FIFO queue
- If the request completes,
statuswill show0. - If there are no available FIFOs,
statuswill show1 << ERR_NO_FIFO_AVAIL - If a FIFO already exists with the issued core,
statuswill show1 << ERR_FIFO_EXISTS - There is no dependence on Hart 1 when setting up the FIFO queue
- The FIFO pool automatically closes the FIFO if inactive for
INACTIVE_THRESHcycles
- Hart 1 issues
fconn, which sends a request to the pool to connect to a FIFO queue
- If the request completes,
statuswill show0. The FIFO is now ready to use. - If there is no FIFO set up for the core,
statuswill show1 << ERR_NO_FIFO_CREATED - If the core has already set up a prior connection with the same core,
statuswill show1 << ERR_ALREADY_INITIALIZED
- Hart 0 polls the pool with
fstatus, which sends backstatus
statuswill include information if the handshake was successful, FIFO is ready, etc.
- Hart 1 polls the pool with
fstatus, which sends backstatus
statuswill include information if the handshake was successful, FIFO is ready, etc.
- Hart 0 is now able to send with
fsend. Hart 1 is now able to recieve withfrecv.
- Hart 0/1 have to poll with
fstatus. In a many-core system, this can cause back pressure on the pool to service these instructions - The reason for this is to allow the instructions to resolve by the WB stage of the core
- If the request succeeded/failed, we would know by the WB stage, since we keep polling
- We also want to avoid trapping into the kernel, and do the entire communication via user space. This will come at the cost of no interrupts, but we expect handshakes to be low latency and not be IO-bound.