Fabian Schuiki

Not yet, spare time is currently scarce, so thinks move a bit slower. The place to start would be in [`src/bin/llhd-conv`](https://github.com/fabianschuiki/llhd/tree/master/src/bin/llhd-conv), where we would add a separate reader/writer for RTLIL,...

> I will upload it as a crate/lib to my github this week [...]. > So, this parser should enable the work on the implementation of mapping between llhd/rtlil. Cool,...

Hey @NotAFile, thanks for taking a closer look at this! LLHD intends to capture the exact semantics of Verilog and VHDL, and then offer a simpler abstraction to ingest in...

You raise an excellent point. At some point we want input/output from the simulation, as you say, to back Verilog's `$display`/`$write`, or VHDL's `report`. SystemVerilog also has a whole host...

> Was `extern` the intended way to achieve this? Yes exactly. There must be a clear separation about what is described inside an LLHD model, and what is an opaque/black-box...

> Does `extern` actually currently exist in any, even highly experimental, form? Not at the moment. It's easy to add to the IR, but I'm currently pushing Moore ahead to...

This has been solved by the new dynamic extract instructions `dextf` and `dexts`, which operate on signals/pointers, but allow for a dynamic offset. These already exist in the MLIR implementation,...

Thanks for the praise and the long article you wrote on LLHD! Admittedly I had to use Google Translate :blush:. I think a lot of the concepts in Rust would...

> @0x7CFE Yet, being able to write a single source code that would be seamlessly compiled to several targets (like Xilinx Zynq and Intel Xeon Scalable) is very interesting to...

> @sequencer Maybe `chirrtl`(the firrtl-like IR directly generated by chisel) could be a good IR to implement? You mean as a conversion input/output in `llhd-conv`? > From a firrtl transform...