Renode integration

[mtdudek]

This PR adds an integration layer between XLS and the Renode simulator. It's accomplished by building a shared library which implements Renode's plugin interface which allows Renode to load & use 3rd-party plugins that emulate various HW peripherals.

This particular implementation provides an XlsPeripheral - a system bus peripheral with a single block of MMIO register space. It translates register accesses into calls to the XLS's ChannelQueues inside ProcRuntime, It advances the simulation when a Tick message is received from Renode.

This way an application running on the CPU emulated by Renode can communicate with a proc running within XLS ProcRuntime. To run, XlsPeripheral requires some runtime configuration (e.g. path to DSLX/IR proc file, IR channel names) which the user has to provide via a configuration file in .textproto format.

Current state:

• Integration can be loaded into Renode, log messages will be passed to the Renode, there is stub code to test that register accesses work.
• Exposing IR SingleValue channels as memory mapped registers.
• Exposing IR Stream channels as memory mapped registers.
• Passing context from Renode to the xlsperipheral.
• Reading and building simulation based on config file from context.
• Adds DMA engine to transfer data through IRStream without CPU interaction.
• Adds DMA and wrapper for AXIStream-like channels.

Related to #997

[proppy]

Thanks for starting this.

With regards to the following statement in the PR description:

It translates register accesses into calls to the XLS's ChannelQueues inside ProcRuntime, Add DMA and wrapper for AXIStream-like channels.

Would AXIStream depend on the ChannelQueues for its implementation? or would those be two different commentation protocols? If the later can you expand on why we need both?

CPU emulated by Renode can communicate with a proc running within XLS ProcRuntime.

Can you describe the calling convention (in term of CPU operation)?

[mtdudek]

ChannelQueue is XLS IR class that is wraps channels, both single value and streaming. IRSingleValue, IRStream and IRAXStreamLike will use ChannelQueue to send/receive data from simulation. AXIStream-like uses ChannelQueue to access transfer data to/form simulation.

We map XLS streams into memory space as follows:

• SingleValue channels are treated as simple registers, reads peek value in queue and writes update this value.
• Streams use different mapping, first 8 Bytes are reserved for control register: ready, transfer, channel direction. Starting from channel address + 8 there is intermediate buffer that either holds data read from simulation, or data that are being prepared to be send to simulation

[proppy]

It's accomplished by building a shared library which implements Renode's plugin interface

Curious if a common interface could be generalized to reuse this infrastructure with other simulator? Would it makes sense to isolate the renode specific parts in a separate library?

[proppy]

AXIStream-like uses ChannelQueue to access transfer data to/form simulation.

I wonder if exposing only the AXIStream-like protocol could simplify and generalize the interface between the host simulator and the XLS IR simulation?

We could require that block that need to be simulated have to implement AXI-Stream, and the host simulator could dispatch the signal thru a C-API to the XLS IR simulation without any knowledge of the channels.

[rdob-ant]

@proppy

Curious if a common interface could be generalized to reuse this infrastructure with other simulator? Would it makes sense to isolate the renode specific parts in a separate library?

I think yes, although the difficulty of that depends on which simulator you have in mind and the specifics of the interface that it uses to communicate with peripheral "drivers". But in general I think it should be possible to reuse much of current logic since most of our MMIO peripheral code is rather generic. Current code will have some references to the renode-specific communication protocol here and there, but it should be possible to factor them out later on.

I wonder if exposing only the AXIStream-like protocol could simplify and generalize the interface between the host simulator and the XLS IR simulation? We could require that block that need to be simulated have to implement AXI-Stream, and the host simulator could dispatch the signal thru a C-API to the XLS IR simulation without any knowledge of the channels.

I don't think it matters much, since in the end all our classes, both AXI and non-AXI, are just peripherals that are controlled via MMIO regs, make level-sensitive IRQ and DMA requests to the CPU system (acting as DMA bus master), and should be periodically ticked to advance their state. So as long as we can make generic versions of all those interfaces (some of them already are generic) and implement them for a certain simulator, any simulator can be integrated this way.

[proppy]

Current code will have some references to the renode-specific communication protocol here and there, but it should be possible to factor them out later on.

Good to know!

as long as we can make generic versions of all those interfaces (some of them already are generic) and implement them for a certain simulator, any simulator can be integrated this way.

But wouldn't a hard requirement on the streaming protocol implementation make the middle interfacing layer simpler? It could only deal with an high level procol without having to deal with all of the XLS channel semantics. Or are you saying that the implementation XLS channel and AXI stream communication primtive are similar enough in complexity not to create additional burden?

[mtdudek]

I think this PR was to large to be done as a single unit. So it is now split into 4 PRs:

• [ ] #1176
• [ ] #1177
• [ ] #1178

and this one.

New PRs add generic code that can be used by other integrations, while this PR should only add Renode specific classes.

[proppy]

should we close this and favor of reviewing the demonstrator at https://github.com/antmicro/xls-cosimulation-demonstrator ?

we can then re-open a new PR once we figure out how to integrate the simulator build w/ the bazel workspace.

[mtdudek]

Closing this PR in the favour of the demonstrator repo.