Hi Daniel, is there any direct comparisons of the NOEL-V vs the LEON3/4/5?
Best wishes, Chris
(First a comment on Daniel’s initial message, we hit a snag late in the day yesterday when putting together the update NOEL XCKU bitstreams so those have been delayed to today).
What we have today as part of the GRLIB area spreadsheet are comparisons of the LEONs wrt resource utilization and performance. Results from the new NOEL-V XCKU designs will be added in there as well during the day: https://www.gaisler.com/products/grlib/grlib_area.xls
Today the NOEL-V is not feature complete (missing H, C, N extensions) and lacks support for the high-performance FPU option. At the next milestone we will be able to develop more complete comparisons of performance and logic utilization.
For functionality, as more RISC-V extensions are added the NOEL-V will become more feature rich and it will also be possible to tailor the processor to a greater extent for different applications (see configurations at https://www.gaisler.com/NOEL-V)
For software support, our goal at Gaisler is to provide the same level of support for NOEL-V as for LEON (same type of toolchains available, …) so that at least someone with a user space application will be able to move between LEON and NOEL-V SoCs without caring about which RISC that is under the hood. We are not there yet and today the LEON ecosystem is more complete. We have a slide with a table comparing the SW ecosystem, I will see if I can convince Daniel to put that one on gaisler.com.
Otherwise, if you compare the two fully featured processors they will be quite similar. If you have software already for the LEON or if you need to do a product starting today, I’d go with the LEON5. If you foresee a need to run SW packages that are not available for LEON but might become available for RISC-V, if you are starting a new design, or are creating a SoC addressing a market outside space then NOEL-V becomes more relevant.
Thanks Jan! Nice to hear from you. Can you comment on the radiation tolerant features?
Would like to see the SW ecosystem slide please @daniel!
The processor cores follow the same approach as for LEON3 and LEON4 where on-chip SRAM (RAM blocks within the processor core) is protected. For protection of the logic elements within the processor this will still be target technology specific and the implementation of the processor models has been done assuming that the target technology has hardened logic (this is then accomplished by using a rad-tolerant FPGA, rad-tolerant ASIC platform or triplication). There are ideas within the processor group on other more efficient mitigation measures against SEEs and those will probably be explored first with LEON5.
On a SoC level the FT approach is again the same and we have, among other things, a new DDR2/3 controller IP core (FTADDR) with a strong EDAC for external memory.
For software, there is an internal effort on creating a FT library that will make it easier for end user software to interact with error counters and uncorrectable error handling.
In short, the two new models will have transparent handling of correctable errors and there will be news in target technology specific protection and on the software side.
Perfect - thanks Jan. I will have a download and play in simulation on the error systems.