Claire Xen  🏳️‍⚧️ 🏳️‍🌈 🧙🏻‍♀️ BLM  🏴 🚩

The VexRiscv decoder does that as part of the elaboration process. It should be possible to extract the Simplify code as a stand-alone thing. https://github.com/SpinalHDL/VexRiscv/blob/6334f430fe1bed302733c6ea6c44f8b514f3e2c6/src/main/scala/vexriscv/plugin/DecoderSimplePlugin.scala#L175 …

Interesting. As a side-note, it seems @SpinalHDL has some nifty features (like the latency matching too). This is what I like best about the new HDLs. They all bring in new ideas. Chisel's diplomacy looks pretty cool for example

I implemented my own latency matching (along with automated pipelining) in a simple C-esque HLS tool for a FPGA AR project. The 3-4 weeks spent writing that tool easily saved me 6 weeks of RTL dev and meant creating more demo apps was much less painless.

Interesting. In my view, I don't think we will have a new omnipresent HDL, bit rather a lot of different (graphical and textual) DSLs to help with different tasks. What you describe is super useful for DSP. Someone stitching together a SoC need a whole different toolset and so on

But to achieve this we need better tooling and foundations. Standard libraries, a common IR that EDA tools can target directly. What @M_Labs_Ltd and @whitequark do with nmigen is a step in the right direction in my opinion

Other people will vehemently disagree but imo, especially given the existing (open and closed source) software ecosystem, simple Verilog is a good intermediate representation for integrating designs created from different DSLs.

Given the existing tooling, I agree. But there are things lost in the process that makes debugging harder. This can be improved by still sticking to verilog, but my feeling is that most new HDL devs are more interested in fixing their verilog pet peeves than taking care of this