llhd
llhd copied to clipboard
fabianschuiki
Rust itself as LLHD frontend
First of all, let me say that I'm really impressed by your project! I waited for something like this for quite a while and really happy that finally we have something to work on. I even wrote an article (based on your paper published on Arxiv) on a Russian major tech site, where I tried to advertise your project and briefly explain its goals and key concepts.
I'd like to know your opinion on the subject, though. Rust as a language is very interesting because of it's power and expressiveness. I'm wondering, could Rust type system be used to enforce bus access protocols existing in the hardware? Ideally that should be zero cost and end up being transpiled to LLHD. I can imagine having some system on top of Rust, say, based on custom hardware-aware wrapper types and procedure macros that would hopefully allow writing gateware with a minimum overhead. Or maybe even transpiling Rust MIR to LLHD IR. I understand that currently it's quite challenging. Maybe later, when rustc become librarified that would be possible.
Of course, there are projects like Kaze, but it's a bit different.
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 make sense in an HDL, most importantly traits and the robust type system. It might be possible to try and map Rust to hardware directly, but efforts like this have a tendency to run into roadbumps due to the large semantic gap between program descriptions and hardware descriptions.
My personal gut feeling is that we need a new language which borrows (pun intended) heavily from Rust and/or similar languages, but extends the type system to specifically apply to hardware description. Traits and essentially a SAT solver in the type system is an excellent feature to have. But we probably need more, like getting rid of the 1-/4-/8-byte bias, adding bit-granularity, additional constraints and invariants in the type system (like always-power-of-two, one-hot), etc. Also there is a large spectrum of type-system-derived formal checks that have not been explored in HDLs thus far, but would be very attractive in hardware design.
Thanks for the detailed reply!
Whilst I totally agree on your opinion on specialized languages and extended type systems, I think at least for now it would be an interesting experience to play a bit with proc macros and try to imagine how such language should work and behave. To me, those “roadbumps” you've mentioned, are especially interesting, since they often provide some hints on what to do and what not.
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 me. I do understand that such approach may (and probably would) have some limitations, but it's interesting nevertheless. Rust's ownership semantics, its ability to express state machines in a very straightforward and natural way, and its systems-oriented nature are too appealing to ignore.
It was shown already that proc macros are very powerful tool that may be used to create ad-hoc domain specific languages. I'm wondering how far one can go with just that.
Maybe chirrtl(the firrtl-like IR directly generated by chisel) could be a good IR to implement?
From a firrtl transform developer view, I think a LLVM-like transform flow manager and correspond annotation system is also required.
@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 me.
I agree, this is a very nice proposition. And certainly Rust would be better suited for this than C/C++, which is very commonly used in High-Level Synthesis.
It was shown already that proc macros are very powerful tool that may be used to create ad-hoc domain specific languages. I'm wondering how far one can go with just that.
This would be an interesting direction of exploration. There's not much standing in the way of just taking Rust MIR (or the LLVM it emits), and mapping that to LLHD.
@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 developer view, I think a LLVM-like transform flow manager and correspond annotation system is also required.
Agreed, such a transform flow manager has been on the todo list for quite some time. And metadata annotations will be very useful for debugging information, etc.
You mean as a conversion input/output in llhd-conv?
I think chirrtl can be the input to llhd, or with few firrtl transform to keep the hardware same as it original design in chisel. Maybe I can give some help on this.
Agreed, such a transform flow manager has been on the todo list for quite some time. And metadata annotations will be very useful for debugging information, etc.
Yes, firrtl did it really brilliant, and I'm also a super fan to Scala and Rust :) Hope we can get rid of Verilog and SV finally with llhd:) Hope llhd can become another yosys in the future.(we really need a synthesis tool in Rust)
@sequencer I think chirrtl can be the input to llhd, or with few firrtl transform to keep the hardware same as it original design in chisel. Maybe I can give some help on this.
It seems that the plan over at Chisel is to eliminate CHIRRTL altogether (freechipsproject/firrtl#727). Is that still a thing? Wouldn't it be better in that case to target FIRRTL for LLHD conversion? Or would CHIRRTL provide additional benefits?
Yes, firrtl did it really brilliant, and I'm also a super fan to Scala and Rust :) Hope we can get rid of Verilog and SV finally with llhd:)
Fully agreed 😃!
Hope llhd can become another yosys in the future.(we really need a synthesis tool in Rust)
That would be a pretty fun exercise indeed. However Yosys is doing an excellent job and rightfully has a lot of community momentum, so it's crucial that LLHD works well with it.
It seems that the plan over at Chisel is to eliminate CHIRRTL altogether (freechipsproject/firrtl#727).
Yep, chirrtl will be eliminated finally, I means only absorbing few transforms, shift left as much as possible, since some optimizations will remove the original information from RTL designer.
I am also very impressed by your project😃. I think making Rust itself as LLDH frontend is too heavy.But alternatively, is it possible LLDH support import Rust func to LLDH func/process and calling these external func in LLDH? Like System DPI... It will be very powerful when building high-level/cosim model. Currently I'm building a RISCV ISS, and trying to find a better way to support timing-model and even cosim with RTL. If I can export my high-level model to LLDH, it will be very exacting😃.
I am also very impressed by your project. I think making Rust itself as LLDH frontend is too heavy.But alternatively, is it possible LLDH support import Rust func to LLDH func/process and calling these external func in LLDH? Like System DPI... It will be very powerful when building high-level/cosim model.
Yes, it is planned to be able to call into external native functions from your LLHD code. Of course that wouldn't be synthesizable, but it's a handy tool for all kinds of testing, as you say yourself.
Currently I'm building a RISCV ISS, and trying to find a better way to support timing-model and even cosim with RTL. If I can export my high-level model to LLDH, it will be very exacting.
Very nice :smiley:
Thanks! And furthermore, is it possible to use LLDH simulator as Rust lib? Then it can be integrated into another top bin.😃
And furthermore, is it possible to use LLDH simulator as Rust lib?
Not yet, but there is nothing preventing that. It's just a few tweaks in the llhd-sim crate.
my understanding is llhd mainly is for hardware desciprtion, instead of simulation. is there any benchmark about the sim speed on llhdl-sim and other simulators?
my understanding is llhd mainly is for hardware desciprtion, instead of simulation.
It targets both. For one, it can describe the hardware itself. But also, it allows for the description of testbenches that apply stimuli to that hardware and observe the results. The goal is to be able to fully capture synthesizable hardware and testbenches written in HDLs like SystemVerilog or VHDL. Tools like simulators can then execute the model to create a simulation trace, synthesizers can convert the synthesizable aspect to hardware, or you can have some fancy mapping to simulation hardware even.
is there any benchmark about the sim speed on llhdl-sim and other simulators?
llhd-sim is pretty slow, because it aims at being simple and complete. However it's pretty straightforward to write an LLVM-based simulator with better performance. See the LLHD paper for details and comparisons.
Is CIRCT project target to LLVM-based simulator? In its website(https://circt.llvm.org/), I didn't see one path from structural LLHD to executable. circilator will be developed to translate LLHD to cpp. It would be better to convert LLHD to executable.
Yes this is definitely part of the goals of the CIRCT project. circt-sim (extension of llhd-sim) is what you are probably interested in (LLVM-based translation of LLHD/other CIRCT dialects to a simulation executable).