Re:Designing a RISC-V CPU, Part 1: Learning hardware design ...
by tails4e on Friday February 19, 2021 @05:51AM
(#26191694)
I'd be interested in this too, I'm all for improving on the standard HDLs, but from this example I see more downsides than upsides, mostly due to the fact the synatx looks very verbose. Part of the is because its layered on top of python, so even a simple switch must be written in a more elaborate way. The code shown in the example would be very readable in SystemVerilog and quite a bit shorter. Also how does something like this handle carry for integer addition, sign extension, etc.
[ Parent
| on HN ]
Re:Designing a RISC-V CPU, Part 1: Learning hardware design ...
by colejohnson66 on Friday February 19, 2021 @01:22PM
(#26196153)
Carries are documented. Two n-bit numbers result in an (n+1)-bit number. The “n+1th” bit is obviously the carry of the result. Sign extension is handled by declaring a `Signal` as signed or unsigned during creation.
For example, both:
x = Signal(4, true)
y = signed(4)
will create a 4 bit signed number. Use `false` or `unsigned` for a signed. Setting either x or y to a Python integer will handle the sign extension behind the scenes.I will agree with you on the syntax, however. It’s caused by the fact that you’re not synthesizing your program, but writing code that generates code.
nmigen is a library, not a language. So it has to use what’s available to it. The upside is you don’t have to write tokenizers, parsers, etc, but the downside is it looks “hackish”.
For example:
m.d.comb += x.eq(y + 1)
...means: in the combinatorial domain (clockless) of the m `Module`, set x equal to y+1. If you come from a VHDL/Verilog background, nmigen’s “syntax” is pretty off putting, but if you come from a programming background (like me), the Python syntax is easier to grok IMO.Robert Baruch has a nice tutorial on nmigen: https://github.com/RobertBaruch/nmigen-tutorial