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 decl

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 https://github.com/RobertBaruch/nmigen-tutorial