A few months back I set out to write a software emulator of RISC-V for fun. I expected the instruction set encoding to lend itself well to a very simple implementation, eg. something you could decode in 5-10 lines of C plus some tables.
But the instruction encoding is much more irregular than I expected: https://github.com/ucb-bar/riscv-sodor/blob/master/src/commo...
In particular:
- The bit patterns allocated to the simplest instructions
(eg. rv32i) seem random. Why not allocate starting from zero
to allow dense jump tables?
- I can't make any sense of the groupings. A bunch of instructions
have 0b1100011 in the lowest bits, do these instructions have
something in common?
The bit patterns are often designed to make it easier to write efficient hardware designs to implement them. For example, if an instruction encodes an "immediate" value, the most significant bit of the instruction will always hold that value's sign-extension bit. And if you compare the immediate values in I-/S-/B-/J-type instructions, you can see that bits [5:10] are always in the same place. It's not exactly intuitive, but there is some rhyme and reason.
In the base instruction set, the 0b1100011 opcode encodes a set of conditional branch instructions. They perform relative jumps if rs1 == rs2, or if rs1 < rs2, etc.
https://riscv.org/specifications/isa-spec-pdf/
Take a look at the "RV32/64G Instruction Set Listings" table to get a feel for the encodings.
For example, the operands all stay in the same position, which prevents putting decode on the critical path before you can figure out which registers you need to read (which is doubly important for superscalar designs which need to compute the register dependence graph). Likewise, the sign-extend bit for immediates is always in the same place, providing relief for another potential critical path.
Computer Organization and Design, RISC-V edition, goes into these. R-types have opcode = 0b0110011, SB (branch) types have opcode = 0b1100011, etc.
The lower bits also have extra meanings (16 bit, 48 bit, etc. instruction).
This allows hardware to just branch on these bits in sub-groups. The hardware pipeline for 16 bit is different than that of 48 bit, and the 48-bit is probably even optional.
Compressed was an afterthought on Risc-V. A well thought out afterthought, but you do things differently when you know in advance.
What, they are absolutely relevant in hardware and selected to optimize the resulting generated hardware.
To see what I mean, have a gander at this:
Single Board Computers - https://www.sifive.com/boards/hifive-unleashed this seems to fit the bill. However, they don't seem to be selling those yet - the development kit for that particular CPU seems to be an FPGA soft-core.
I am currently working on an open-hardware project that requires a fair amount of grunt (or FPGA); in an effort to keep is open I was looking into RISC-V processor's. You can actually buy RISC-V hardware today as a guy on the street (i.e. Digikey etc.) but the offerings I could find were generally fast microcontrollers rather than general purpose processors.
If RISC-V is to be adopted it's probably more of a question of engineering knowledge and training than solely hardware: One of the chips I found in my search above is an interesting Chinese system on module that has a RISC-V at 400MHz, Wi-Fi, and a hardware NN coprocessor - it's a cool chip but even in Chinese the documentation is unusable and awful.
If a big western company like ST or Cypress etc. picks up RISC-V and starts making it easy and safe to actually use (for example, the section of the manual for the serial peripherals on most NXP microcontrollers is longer than all the documentation I could find for the aforementioned SoM).
The HiFive Unleashed was released (and for sale) back in 2018. From memory, there was a limited run (priced at US$1k each), as it was targeted to specific types of developers looking to do further work improving the platform.
For example, Red Hat bought some and used them for improving the RISC-V support in Fedora. From memory, Richard Jones (@rwmj here on HN) was involved with it.
In Chinese though? Or did you compare long English to short Chinese?
Because, I don't speak (or read) it either, but compared to English it's extremely information sense: its characters are closer to whole words than to Latin letters. In fact if you think of it also being like German, with Longerwordbuiltfromothers, they are, and L... would be just a few characters at most.
Not that that makes Chinese documentation any more helpful to us non-speakers, though.
I did some google translate-ing and had some help from my token Chinese friend. I might have missed it but the document had the same structure in English and Chinese. In short, you could probably work it out by reading the rtos they distribute for you to use and there is a little documentation of the actual peripherals but it is absolutely bare bones. And that's (what we would call) application notes, the actual datasheet is pretty much just some marketing BS and a PCB footprint (not that they actually provide any symbols - sometimes even the big chip makers don't bother which is quite annoying if you're stuck using anything other than Altium)
There is no RISC-V equivalent of BIOS / UEFI, multiboot, etc. We take it for granted that all motherboards and all bootable drives 'just work'. That kind of consistency is important for consumer desktop PCs (less so for rasberry-pi type machines).
This is being worked on, and I think a stable specifications are not too far away. I imagine it will still take firmware developers a long time to create motherboards that fit the spec, considering they are starting from scratch. Here is a recent presentation about the state of booting RISC-V[1].
[1]https://content.riscv.org/wp-content/uploads/2019/12/Summit_...
(Please, instead of downvoting me, just correct me?)
But of course it would be even better if they would just publish the documentation.
A replacement for the general purpose ULX3S it is not.
The FPGA manufacturers like the margins, fine, but I'm surprised people who make boards like this one but for other things don't just chuck an FPGA on them (for some definition of "just")
But I have no idea how proper it is, only ~10x the cost of the FGPA itself. I'm still interested in it though, kind of want to buy it now but to lazy to figure out how to buy it from where I am now in indonesia and imports are a PITA here :/
Link to board: https://aliexpress.com/item/4000170042795.html
Also worth noting, that you can use a fully open source flow (Yoys + nextpnr + prjtrellis) for this FPGA family. Here's a repository I made that shows a basic blinky for an ULX3S: https://github.com/q3k/ulx3s-foss-blinky/
$150
From my rudimentary understanding it looks like this doesn't have a hard CPU and has a smaller FPGA, so I'm guessing we have a fair bit of "open hardware tax" at play here too.
Edit: After a lot of back and forth, perhaps this is a good intro: https://hackaday.com/2019/01/14/ulx3s-an-open-source-lattice...
Just placed an order : https://www.crowdsupply.com/radiona/ulx3s