amaranth VS riscv-isa-manual

He probably meant Amaranth.

As an aside, the latest and active development of nMigen has been rebranded a few months ago to Amaranth and can be found here: https://github.com/amaranth-lang/amaranth . In case people googled nMigen and came to the repository that hasn't been updated in two years.

Hmm. A followup question: are there any cheats/hacks that would make it possible (if painful) to for example explore the world of USB3, PCIe, or Linux on low-end-ish ARM (eg https://www.thirtythreeforty.net/posts/2019/12/my-business-c..., based on the 533MHz https://linux-sunxi.org/F1C100s), without needing to buy equipment in the mid-4-figure/low-5-figure range, if I were able to substitute a statistically larger-than-average amount of free time (and discipline)?

For example, I learned about https://github.com/GlasgowEmbedded/glasgow recently, a bit of a niche kitchen sink that uses https://github.com/nmigen/nmigen/ to lower a domain-specific subset of Python 3 (https://nmigen.info/nmigen/latest/lang.html) into Verilog which then runs on the Glasgow board's iCE40HX8K. The project basically makes it easier to use cheap FPGAs for rapid iteration. (The README makes a point that the synthesis is sufficiently fast that caching isn't needed.)

In certain extremely specific situations where circumstances align perfectly (caveat emptor), devices like this can sometimes present a temporary escape to the inevitable process of acquiring one's first second-hand high-end oscilloscope (fingers-crossed the expensive bits still have a few years left in them). To some extent they may also commoditize the exploration of very high-speed interfaces, which are rapidly becoming a commonplace principal of computers (eg, having 10Gbps everywhere when USB3.1 hits market saturation will be interesting) faster than test and analysis kit can keep up (eg to do proper hardware security analysis work). The Glasgow is perhaps not quite an answer to that entire statement, but maybe represents beginning steps in that sort of direction.

So, to reiterate - it's probably an unhelpfully broad question, and I'm still learning about the field so haven't quite got the preciseness I want yet, but I'm curious what gadgetry, techniques, etc would perhaps allow someone to "hack it" and dive into this stuff on a shoestring budget? :)

Worth knowing that are two "nmigen"s nowadays - the one originated in M-Labs and one under a project also called nmigen:

https://github.com/nmigen/nmigen

It's a fork, made for reasons, but more actively developed. whitequark (long time author/contributor) works on this fork, and no longer the M-Labs version.

Sounds like nmigen might be a good open source successor to the project that you describe: https://github.com/nmigen/nmigen

https://github.com/riscv/riscv-isa-manual/releases

Regarding the recent "How to improve the RISC-V specification" post [0], I just wanted to point out, that the latest draft manual is already a great improvement. (see link above)

It includes a lot of the newly ratified extensions: bitmanip,zicond,vector,vector crypto, ...

And there are a bunch of included SAIL definitions for bitmanip and zicond, but other instructions are still missing the SAIL code. Most notably, the SAIL definitions from the RV32I/RV64I base isa are also missing.

I asked for the further SAIL integration plans here: https://github.com/riscv/riscv-isa-manual/issues/1369

Here is an example SAIL snippet from cpopw:

    let bitcount = 0;

I encourage you to look at the newest isa manual draft on github: https://github.com/riscv/riscv-isa-manual/releases

It includes the more recently extensions, and e.g. the bitmanip instructions all have associated pseudo code.

Here is e.g. the code for cpopw:

    let bitcount = 0;

I tried searching the spec [1] for "overflow" and here is what it says at page 17:

> We did not include special instruction-set support for overflow checks on integer arithmetic operations in the base instruction set, as many overflow checks can be cheaply implemented using RISC-V branches.

> For general signed addition, three additional instructions after the addition are required

Is this "cheap", replacing 1 instruction with four? According to some old mainframe era research (cannot find link now), addition is the most often used instruction and they suggest that we should replace each one with four?

Their "rationale" is not rational at all. It doesn't make sense.

Overflow check should be free (no additional instructions required), otherwise we will see the same story we have seen for last 50 years: compiler writers do not want to implement checks because they are expensive; language designers do not want to use proper arithmetic because it is expensive. As a result, there will be errors and vulnerabilities. A vicious circle.

[1] https://github.com/riscv/riscv-isa-manual/releases/download/...

Why not use the actual release PDF instead from their github? https://github.com/riscv/riscv-isa-manual

https://github.com/riscv/riscv-isa-manual/releases/download/Priv-v1.12/riscv-privileged-20211203.pdf Part 2

If you don't want to cheat then read the RISC-V ISA manual: https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf

Yeah you are on the right track. Processors are designed on top of an Instruction Set Architecture (ISA). For an example you can look on top of the RISC-V specifications:https://github.com/riscv/riscv-isa-manual/releases/download/Ratified-IMAFDQC/riscv-spec-20191213.pdf (possible PDF download)