[tails4e]

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.

[colejohnson66]

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

[tails4e]

Thanks that helps clarify things, also nice to see Robert Baruch's tutorial.