litex_sim: add inter-module messaging, external simulation control and controllable GPIO

[lschuermann]

This is quite a large changeset. It introduces three major components as outlined below, which all depend on each other. I recommend reviewing the individual commits over the very large diff.

This is still lacking some external interface documentation and examples in the form of a Markdown (non-code) document. Furthermore, it would be nice to have a user-friendly application upstream to control the simulation. I have written a small Rust library and application for that. I'm not sure whether Rust will be accepted upstream or I should rewrite it in Python.

Components / mechanisms introduced

Inter-module message passing mechanism

This introduces a generic, flexible and efficient inter-module message passing mechanism to allow for more advanced module behavior and interactions, as well as outside control of module behavior.

Possible applications for this mechanism are outside control of emulated peripherals such as GPIO, simulated hardware attached to multiple independent subsystems (e.g. GPIO + SPI) and integration of the LiteX simulation in automated systems such as CI.

The message passing mechanism does not impose any restrictions on the data exchanged between modules and each module is free to define its own interfaces through opcodes >= 256. Opcodes < 256 are reserved for globally defined operations.

These global operations include auto-announcement of instantiated module sessions in the simulation for discovery and a mechanism for interacting with outside applications (called "simctrl"). These operations are well documented in modules.h.

This further introduces a few functions which expose basic information about and control of the simulation, such as querying the current simulation time and state, and requesting the simulation to halt or resume operation.

Externally-accessible ZeroMQ/JSON based simctrl interface

On top of this generic inter-module message passing interface, an module for external communication through the "simctrl" interface based on ZeroMQ/JSON is introduced. While modules are free to define their own payload format, this introduces a standard way of talking to the simulation from an external application.

The passed messages make use of ZeroMQ multipart messages, for instance to carry payloads to simctrl-supported modules in the simulation. Thus, this module takes messages which contain a "simctrl header" and a payload forwarded to the destination module.

Furthermore, the module implements some basic standalone status & control functionality. It can be used to query the current wall clock time, simulation time and instantiated module sessions. It can halt and resume the simulation.

Controllable GPIO controller

Finally, this adds a GPIO controller module, which is exposed through simctrl. Supports driving GPIO pins, as well as querying the current pin state (input/output) and signal state. Exposes a JSON-based interface through the simctrl payload.

End result

With these changes, we have a simulation which can be used in rich CI setups, such as the one built using this infrastructure for the Tock operating system (tock/tock#2801):

Flashing kernel "../../target/riscv32imc-unknown-none-elf/release/litex_sim.bin"...
Installing app "../../libtock-c/examples/tests/mpu_walk_region"...
Starting test. This will compile a Verilated LiteX simulation and thus might take a bit...
We're up! Got the kernel greeting. Connecting to ZeroMQ simulation control socket...
Walking flash worked.
Set button input to true, currently driven by input.
Expecting to overrun flash region.
Walking RAM worked, walking flash now, will overrun!
Process faulted.
Process had a load access fault, as expected.
Test succeeded!

Furthermore, with an appropriate control binary, users have a friendly interface to interact with their simulation:

> litex_simctrl help

USAGE:
    litex_simctrl [OPTIONS] <SUBCOMMAND>

FLAGS:
    -h, --help       Print help information
    -V, --version    Print version information

OPTIONS:
    -c, --connect-uri <CONNECT_URI>    ZeroMQ connection URI to litex_sim server [default:
                                       tcp://localhost:7173]

SUBCOMMANDS:
    gpio             Interact with an instance (session) of the litex_sim GPIO module
    halt             Halt the simulation
    help             Print this message or the help of the given subcommand(s)
    info             Get information about the running litex_sim simulation
    list-sessions    List instantiated module sessions of the running litex_sim simulation
    resume           Resume the simulation

A demo of the Rust client can be seen here: https://asciinema.org/a/SiQ7Byeco0qa5ELueltiAPQqS

[enjoy-digital]

@lschuermann: This looks great, thanks! (I'll review it very soon).