3 ms·
There's a LOT more to this discussion. SiFive claims they can fit a RV32E core into 13.5k gates, but to my knowledge, that's just the core itself without any o
by hajile 4y ago
There's a LOT more to this discussion.
SiFive claims they can fit a RV32E core into 13.5k gates, but to my knowledge, that's just the core itself without any of the IO, memory, etc.
A small 8051 implementation can be made in 2.7k gates with a lot of typical implementations using between 8 and 14k gates (but with a lot of proprietary features not actually in the spec).
Setting aside the question of power efficiency of 8-bit cores, the real question becomes one of instruction density as that determines the size of the storage and RAM (increasing these can have dramatic cost differences). To my knowledge, RV32E doesn't have a compressed instruction variant meaning every instruction is 32 bits long. 8051 instructions are between 8 and 24-bits long (generally, 8-bit for math, 16-bit for MOV, and 24-bit for immediates).
If you're working mostly on 8 or 16-bit data like a TON of MC work is, then I don't see how RV32E could have any advantage. If you're working with a lot of 32 or 64-bit data, then I can easily see a RV32E chip requiring less space for the same results.
A 16-bit only variant of RISC-V that repurposes the remaining 50% of the instruction space (used for marking 32 and 48-bit instructions) would be a much more interesting option here IMO.
- zozbot234 4y ago> To my knowledge, RV32E doesn't have a compressed instruction variant meaning every instruction is 32 bits long. AIUI, the E variant is designed to work quite well with the standard compressed encoding. Of course implementing compressed instruction decode takes some area, too; there will be some crossover point at which the density benefits of compressed instructions will more than pay for the higher complexity of decode.
- monocasa 4y agoYeah, I've heard from someone implementing it that on an RV32I core (so not quite a RV32E, but pretty close), the area difference between implementing the compressed instructions and not was about the same as 64 bytes of SRAM. There is a cross over point, but it's pretty damn low. Particularly when you weigh the reduced size of the code memory needed, it's almost always a no brainer.