Show HN: A RISC-V core in Racket
guillaume.baierouge.fr
Show HN: A RISC-V core in Racket
1–10 of 28 posts
Re: Show HN: A RISC-V core in Racket
#2Author here.
This post is part of an ongoing experiment to use Racket as a platform for hardware description languages. Describing a RISC-V core in Racket is a step in this direction, but the ultimate goal is neither to use Racket itself as an HDL, nor to define an embedded hardware description DSL in Racket. The long-term goal is to create an HDL that would benefit from Racket's "language-oriented programming" facilities, with the ability to simulate digital hardware, but also to generate standard Verilog or VHDL.
Re: Show HN: A RISC-V core in Racket
#3Author here. This post is part of an ongoing experiment to use Racket as a platform for hardware description languages. Describing a RISC-V core in Racket is a step in this direction, but the ultimate goal is neither to use Racket itself as an HDL, nor to define an embedded hardware description DSL in Racket. The long-term goal is to create an HDL that would benefit from Racket's "language-oriented programming" facil…
This is great! I also like your other posts in the series on tiny-hdl. Thank you for writing this up!
Re: Show HN: A RISC-V core in Racket
#4If using "signal of vector": how does an update is propagated to a process that is sensitive only to some particular bits? So, any update to that signal (whatever the bit) causes all sensitive processes to be evaluted (regardless if that would be a misfire?). How then you got such interesting performance numbers, that "signal of vector" is better?
Re: Show HN: A RISC-V core in Racket
#5Author here. This post is part of an ongoing experiment to use Racket as a platform for hardware description languages. Describing a RISC-V core in Racket is a step in this direction, but the ultimate goal is neither to use Racket itself as an HDL, nor to define an embedded hardware description DSL in Racket. The long-term goal is to create an HDL that would benefit from Racket's "language-oriented programming" facil…
Can you do a write up on the lower level algorithms like place and route, circuit constraints solving optimization, the process from the netlist stage to autorouting? The engineering behind VHDL and Verilog systems are way too opaque for most software engineers.
Re: Show HN: A RISC-V core in Racket
#6Author here. This post is part of an ongoing experiment to use Racket as a platform for hardware description languages. Describing a RISC-V core in Racket is a step in this direction, but the ultimate goal is neither to use Racket itself as an HDL, nor to define an embedded hardware description DSL in Racket. The long-term goal is to create an HDL that would benefit from Racket's "language-oriented programming" facil…
Can you do a write up on the lower level algorithms like place and route, circuit constraints solving optimization, the process from the netlist stage to autorouting? The engineering behind VHDL and Verilog systems are way too opaque for most software engineers.
The book "Electronic Design automation" by Wang, Chang, and Cheng is quite approachable.
The reason why they are opqaue is partly because the problem is hard, and secondly because the developers of the code make money directly off the tools (like compilers were in the past)
Re: Show HN: A RISC-V core in Racket
#7Earlier quoted context omitted.
Can you do a write up on the lower level algorithms like place and route, circuit constraints solving optimization, the process from the netlist stage to autorouting? The engineering behind VHDL and Verilog systems are way too opaque for most software engineers.
The book "Electronic Design automation" by Wang, Chang, and Cheng is quite approachable. The reason why they are opqaue is partly because the problem is hard, and secondly because the developers of the code make money directly off the tools (like compilers were in the past)
Physical layout CAD software is really interesting though and heavily scriptable. I’m pretty sure at least one major offering uses some kind of lisp as its extension language.
Re: Show HN: A RISC-V core in Racket
#8If using "signal of vector": how does an update is propagated to a process that is sensitive only to some particular bits? So, any update to that signal (whatever the bit) causes all sensitive processes to be evaluted (regardless if that would be a misfire?). How then you got such interesting performance numbers, that "signal of vector" is better?
In the "signal-of-vectors vs vector-of-signals" comparison, "vector" refers to the Racket data type used for arrays.
It should not be confused with "bit vectors", which are represented as integers (assuming that a bit can only be 0 or 1).
While it is theoretically feasible, I would rather not use an array to store bits.
I think that your question assumes a model of computation similar to VHDL or Verilog. The techniques I use in Racket are similar to those used in Clash ( https://clash-lang.org/ ) In VHDL or Verilog, signals are updated in reaction to events. In Racket, I implement signals as lazy data streams: values are "pulled" from signals, which can trigger the evaluation of other signals. This is possible because I restrict my models to synchronous circuits with a single clock domain.
You can read more about it in this post: http://guillaume.baierouge.fr/2021/03/14/simulating-digital-...
Re: Show HN: A RISC-V core in Racket
#9Cool!
Is there a similarly simple core to compare with in Bluespec and Clash?
Re: Show HN: A RISC-V core in Racket
#10Author here. This post is part of an ongoing experiment to use Racket as a platform for hardware description languages. Describing a RISC-V core in Racket is a step in this direction, but the ultimate goal is neither to use Racket itself as an HDL, nor to define an embedded hardware description DSL in Racket. The long-term goal is to create an HDL that would benefit from Racket's "language-oriented programming" facil…
Can you do a write up on the lower level algorithms like place and route, circuit constraints solving optimization, the process from the netlist stage to autorouting? The engineering behind VHDL and Verilog systems are way too opaque for most software engineers.
My experience in the lower-level aspects of hardware synthesis is limited but I would love to explore this topic.
I use proprietary synthesis tools for FPGAs everyday but I do not develop them. My situation is similar to that of a software engineer who uses compilers and who could only explain how they work in general terms.