add RISC-V based simulation for DSLX examples

[proppy]

It would be nice to show interfacing of a RISC-V simulator with the XLS JIT to demonstrate fast simulation from firmware of a DSLX examples (like #994 or #995).

[tmichalak]

The idea is that the RISC-V core and SoC will be emulated (with Renode) and special C++ wrappers will be used to run DSLX and IR. To sum up in more detail:

• Renode will be a pre built portable package
• DSLX will use bytecode interpreter.
• IR will use either interpreter or JIT based on user input.
• The user specifies a path to the tested file and libraries (if needed).
• The user provides channel to address mapping using command args. This mapping will be offset based for better portability. Proto file will be used for configuration to keep configuration files type common throughout XLS. Proto will contain mapping for all channels and one extra register which will contain state of input/output FIFOs, it will provide information if FIFO is not empty.
• For channels wider than byte little endian will be used. Writing to oldest byte will trigger send transaction, reading from youngest will trigger recv transaction.

[proppy]

The user provides channel to address mapping using command args. This mapping will be offset based for better portability. Proto file will be used for configuration to keep configuration files type common throughout XLS. Proto will contain mapping for all channels and one extra register which will contain state of input/output FIFOs, it will provide information if FIFO is not empty. For channels wider than byte little endian will be used. Writing to oldest byte will trigger send transaction, reading from youngest will trigger recv transaction.

I wonder if we could reuse an existing protocol adapter (ex: AXIS stream) rather than creating a XLS-specific IPC protocol. As discussed with @kgugala offline renode could dynamically load the XLS JIT dll and dispatch packet directly from renode's DMA to an AXIS stream/XLS IR JIT adapter.

wdyt?

[mtdudek]

We want to use an existing Renode socket peripheral. It has a well defined protocol for reads/writes, logging and DMA operations. This protocol is common for socket and DLL peripherals.

Socket based approach allows for easier reusability, as config and design files will be the program's parameters.

DLL/so approach will require template C++ code. This code would have to be recompiled for every design tested with Renode.

Interfacing with XLS internals, DSLX interpreter and IR interpreter/JIT, can't be avoided. Currently Renode only supports co-simulation with memory mapped devices. Configuration file is necessary, as we have to map from memory mapped device (Renode) to XLS streams.

[proppy]

Socket based approach allows for easier reusability,

Do you have examples for renode peripheral that uses socket and other examples that use in-process protocol so that we can compare and see what's more applicable here?

[proppy]

This code would have to be recompiled for every design tested with Renode. Configuration file is necessary, as we have to map from memory mapped device (Renode) to XLS streams.

I wonder if we could leverage DSLX / IR parser to infer some of this.

[mtdudek]

Do you have examples for Renode peripherals that use sockets and other examples that use in-process protocol so that we can compare and see what's more applicable here?

I have an example of Renode interfacing using sockets with simulation run in Questa simulator https://github.com/antmicro/renode-dpi-examples/blob/main/samples/axi_ram/tests.robot#L33-L47 and with Verilated code https://github.com/antmicro/renode-dpi-examples/blob/main/samples/axi_ram/tests.robot#L26-L31 Simulation’s top level systemverilog( https://github.com/antmicro/renode-dpi-examples/blob/main/samples/axi_ram/sim.sv) that is used by both Questa and Verilator flows. Extra C++ main for Verilated code https://github.com/antmicro/renode-dpi-examples/blob/main/samples/axi_ram/sim_main.cpp, it handles initial connection with Renode.

An example of dynamic libraries https://github.com/antmicro/renode-verilator-integration/blob/master/samples/fastvdma/sim_main.cpp. Adding it to the Renode system https://github.com/renode/renode/blob/master/tests/platforms/verilated/axi.robot#L42 differs only by omitting the address variable for peripheral.

Right now XLS does support emitting JIT/C++ code for IR fns, but it doesn’t have similar facilities for procs. Adding it doesn’t look straight forward:

• Procs require multiple entry and exit points, similar to coroutines
• During execution XLS IR nodes are used to determine what action should take place https://github.com/google/xls/blob/main/xls/jit/proc_jit.cc#L117-L127
• During translation to JIT, addresses of runtime objects and functions are placed inside LLVM IR tree https://github.com/google/xls/blob/main/xls/jit/ir_builder_visitor.cc#L2756-L2767 https://github.com/google/xls/blob/main/xls/jit/ir_builder_visitor.cc#L2740-L2742

With current limitations a dynamic library will have to contain XLS DSLX/IR lexer+parser, language interpreter or JIT compiler. Library would have to be provided with paths to a design, DSLX/IR libraries and configuration file. I think, due to the size and complexity of this dynamic library, it would be better to use a socket style peripheral.

I wonder if we could leverage DSLX / IR parser to infer some of this.

I was going to infer channels bit width using DSLX/IR parser. I see some challenges with inferring base address as well:

• Channel ordering during visitation will define base address, so any change to iteration order would change base addresses
• Address alignment, we can use 64 bits
• Removing channel from a design will change base address of all channels that followed removed channel, rendering any existing code that interfaced with peripheral incorrect.

[mtdudek]

@proppy which route should we take moving forward?

[proppy]

Right now XLS does support emitting JIT/C++ code for IR fns, but it doesn’t have similar facilities for procs.

I wasn't aware of this limitation, @cdleary can you confirm and possibly point to workarounds?

Library would have to be provided with paths to a design, DSLX/IR libraries and configuration file.

Couldn't this be part of the Renode simulator configuration?

which route should we take moving forward?

It seems that even if the choice was to implement a socket transport, we could start by wrapping the XLS JIT interface with a C/C++ interface that expose an AXIS stream-like transport, that could prove to be generally useful to integrate with different simulators, wdyt?

[proppy]

Also related #588 #587 and #578.

[proppy]

@tmichalak can you also provide a public link (design doc, issues?) describing the ongoing work on generalising the interface to work with other simulator like gem5?

[tmichalak]

@proppy currently we have the interface working with Renode and will shortly have it working for Gem5. The effort for Renode is described in #1123 and we will open one for Gem5 soon. #1123 is based on a couple of PRs (#1176, #1177 and #1178) that the Gem5 integration will be based on as well. The Gem5 integration is going through internal review and we shall open a PR soon along with some changes to those generic PRs that turned out to be necessary in the course of development (of course keeping it compatible with the Renode integration).