3 ms·
The FPGA world rarely cares about RAM limits on MCU cores unless they are trying to make something that benchmarks really well. When they have to be tiny, most
by pclmulqdq 3y ago
The FPGA world rarely cares about RAM limits on MCU cores unless they are trying to make something that benchmarks really well. When they have to be tiny, most of those MCUs run fairly short programs out of a single block RAM (which is a few kB), and actually care more about the LUT count than the BRAM count, making the C instructions actively bad.
(This mostly applies to the high end, but designers on low-end devices may be more SRAM-constrained)
- aseipp 3y agoGood points; though I admit, I was thinking more Linux-capable/"Linux-class" cores in the mid-range FPGAs which is where I spend a bunch of my time. For that, the paltry cache sizes due to limited amounts of BRAM are more noticeable (especially when other features may compete for them) so minimizing icache footprint as much as possible is win. Admittedly that's probably a marginal case versus the tiny softcores you mention; workloads that need high performance cores will practically be better off running on attached ARM processors or whatever. Anyway, all that aside, I personally wouldn't be sad to see the C extensions go away. I'm actively designing a RISC-V core for a small game console, and probably won't implement them, and will spend the time on more DV instead. I don't expect them to have any meaningful benefits for my case and mostly increase frontend complexity.
- pclmulqdq 3y agoI have made a few RISC-V cores for FPGAs personally, and I would say that the C extensions are 100% not worth your time to implement unless you need absolutely minimum RAM size.