RISC-V ...  - Page 1
Forum section: electronics / general

author: Bassman59
author_rank: Super Contributor
timestamp: March 02, 2021, 07:25:19 pm
content: So is it pronounced RISC-VEE or RISC-5?

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 02, 2021, 07:41:38 pm
content: Five. As mentioned in the introduction part in the RISC-V specs:QuoteThe name of SiFive, the first company founded to sell RISC-V cores as far as I know, is also a hint.

author: brucehoult
author_rank: Super Contributor
timestamp: March 02, 2021, 11:48:10 pm
content: Today it is definitely "five", though there was originally an element of V for Vector as RISC-V was originally developed as the scalar control processor for experimental vector processors such as Hwacha.At some point is was decided that Five sounds better and it was realised that it could be counted as the fifth RISC architecture from Berkeley University:RISC-I: The origin of the term "RISC". 31 instructions, two stage pipeline, register windows. The chips worked, but not as fast as expected, presumably due to some physical design mistake.RISC-II: better register file design allowing more registers with fewer (39000) transistors. Introduced 16 bit "compressed" instructions, duplicating the most common 32 bit instructions. Outperformed VAX and 68000 by a large margin despite using an old process node. Led directly to commercial SPARC.SOAR (Smalltalk On A RISC): relatively minor modifications to optimise for running Smalltalk instead of implicitly optimising for C.https://www2.eecs.berkeley.edu/Pubs/TechRpts/1985/CSD-85-226.pdfSPUR (Symbolic Processing Using RISCs): a project to create a workstation with 6-12 CPU cores, tag bits to support LISP data types, and a coherent cache architecture to simplify parallel programming.https://www2.eecs.berkeley.edu/Pubs/TechRpts/1986/CSD-86-273.pdfSo SOAR and SPUR have been informally retro-renamed as RISC III and RISC IV :-)At some point it was decided that register windows are actually a bad idea and RISC-V doesn't have them, but the instruction set is still clearly closely related to RISC-II.

author: Bassman59
author_rank: Super Contributor
timestamp: March 03, 2021, 05:15:45 pm
content: Thanks, this is all very interesting.I'm going down the path of embedding a RISC-V into a PolarFire FPGA. So far it is not at all clear where the binary from the compiler gets stored.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 03, 2021, 05:30:08 pm
content: Quote from: Bassman59 on March 03, 2021, 05:15:45 pmIt all depends on the implementation. What core are you going to use? An existing one? Or are you going to write it yourself?Either way, what kind of instruction memory are you going to use? Block RAM? External RAM (through some cache?)If it's block RAM, and updating the FPGA configuration when updating the RISC-V binary code is OK with you, the simplest way is just to initialize the corresponding block RAM with your binary data. I don't know PolarFire FPGAs, but this is usually possible on most FPGAs.Drawback is, it's pretty annoying - you'll have to go through a complete synthesis cycle every time you update the RISC-V code. But it's also the easiest, and is OK if the end use is fixed code that is only occasionally updated.The more flexible approach is to implement a way to write new data to the memory used as instruction memory while the FPGA is already configured. Could be through a serial link, ethernet, or any interface you have at disposal for that.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 03, 2021, 06:11:02 pm
content: Quote from: Bassman59 on March 02, 2021, 07:25:19 pmJust a side thought - funnily enough, "RISC5" spelled this way actually exists. It was a small RISC CPU designed by Niklaus Wirth in the context of his Project Oberon (a whole system made of a CPU, a programming language and an OS.)Although I consider this work seminal, it was probably either considered not very influential - at least for the CPU itself - by Berkeley, or maybe even got completely ignored, so they settled for RISC-V (RISC-"five").These days, certainly when I hear "RISC-five" I unambiguously think of RISC-V, but there's still often a small thought in the background of Wirth and Oberon.For anyone curious, you can have a look:https://people.inf.ethz.ch/wirth/FPGA-relatedWork/RISC.pdfhttp://people.inf.ethz.ch/wirth/ProjectOberon/RISC5.Update.pdf

author: brucehoult
author_rank: Super Contributor
timestamp: March 03, 2021, 08:45:57 pm
content: Those are dated 2015 and 2018, which is well after the RISC-V name was chosen and the basic design was in its current form.When you said "Oberon" I assumed this was something from the late 80s when I was playing with the Oberon environment on a Mac.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 03, 2021, 10:00:32 pm
content: Those documents yes, but the project itself is a long-time evolving project. Given the age of the Oberon project, I didn't quite remember the exact date when Wirth decided to design his own processor. Officially this started in 2013 (Project Oberon 2013). He probably had this in mind for a much longer time though. Yes, The Oberon project all started in the 80s. It's still evolving.Now the naming was likely choosen almost at the same time and likely in total ignorance of one another - I thought Wirth's RISC5 origin was way older, but I have no proof of that. So we can say it's likely just pure coincidence. But I just can't help thinking of it when I hear RISC-V!Oberon OS was initially designed on a Ceres workstation (NS32k processor:https://en.wikipedia.org/wiki/NS32000)More info there:https://en.wikipedia.org/wiki/Oberon_%28operating_system%29Oberon has been a language and an OS. Both are still active projects actually. The latest official Oberon language report's version is dated 2016 and has known an number of evolutions and refinements. The Oberon system itself is still evolving:http://www.projectoberon.com/There have been a number of branches for all this too, such as ports of Oberon OS for other targets. And "forks" of the Oberon language, such as Zonnon and Active Oberon. The latest Active Oberon language report is dated 2019. It's actually an interesting language.So anyway, this was a bit of a distraction from RISC-V, sorry about that, but something interesting in computer science history.

author: brucehoult
author_rank: Super Contributor
timestamp: March 03, 2021, 10:27:51 pm
content: If you read the document you find that RISC1 to RISC5 are different implementations of the same instruction set , of varying levels of complexity, gradually adding unified memory (von Neumann), 2-stage pipeline, byte addressing, using external SRAM instead of FPGA block RAM, interrupts.Seems like it's probably a decent introduction to designing a simple CPU using Verilog.

author: SiliconWizard
author_rank: Super Contributor
timestamp: March 03, 2021, 10:53:08 pm
content: The whole Oberon project has definitely a lot of learning value! And yes the CPU itself is rather barebones but easy to understand.The only oddity here, IMHO, is the use of Verilog, which I can't really explain (other than, given Wirth's age, that's probaby what he was most proficient in), knowing that VHDL is much more common in Europe, and is actually close to a "Wirthian" language!

author: Daixiwen
author_rank: Frequent Contributor
timestamp: March 04, 2021, 07:51:22 am
content: Quote from: Bassman59 on March 03, 2021, 05:15:45 pmIf you have an external SPI flash connected to the correct pins of the Polarfire FPGA and plan to use internal RAM blocks to hold the binary, you can configure the system controller inside the FPGA to automatically load data from the SPI into the RAM blocks during device initialization. Just make sure to use the init monitor component to hold the CPU in reset until the transfer is done. That's the easiest way of doing it, and as the SPI flash is a separate step in Libero you won't need to recompile the project each time you want to change the software.If you plan to use an external RAM to hold the binary, you will have to use a bootloader in a small internal RAM first that will copy the binary into the external RAM and then jump to it.

author: Bassman59
author_rank: Super Contributor
timestamp: March 05, 2021, 03:38:06 pm
content: Quote from: Daixiwen on March 04, 2021, 07:51:22 amThe silly boards I bought actually have "all of the above." (Future Avalanche.) It's just the usual thing: a new architecture and a new set of tools and examples that work but are not well documented. But what you said -- "make sure to use the init monitor component" -- is REALLY helpful, because it wasn't clear why I needed that! (It's in the examples.) It's been a few days of wading through documentation.The simple "Hello, World!" example put the RISC-V firmware into sNVM and the startup logic copies that into LSRAM. I suppose the interesting thing to do would be to store the firmware image in the SPI Flash and then have it copy it into external DDR3 SDRAM. And then work out how to update the firmware in SPI Flash without having to rebuild the FPGA.My main interest is the multi-gigabit transceivers, and for purposes of sending and receiving data over the serial link, using a processor core makes sense. Right now I'm not interested in blazing speed, just the ability to verify that the links work. A gigabit data rate works out to be 50 MHz parallel rate in the fabric, which is easy.The other piece of the puzzle is interfacing to a sensor with multiple serial DDR data outputs. That can be handled by a deserializer in each "regular" GPIO -- HSIO is apparently for the DDR memory interfaces -- which is nice. Of course the sensor has a 12-bit data word and the deserializer in the input ring doesn't do 12 bits, or 6 bits, so I worked out doing it four bits at a time and re-assembling the words in the fabric. And while I was working on that, I realized that the "regular" GPIO has a 10:1 serializer and 1:10 deserializerwithclock and data recovery, which is perfect for replacing an external chip we've been using for that. Just add 8b/10b coder and 10b/8b decoder!And at some point I'll have to spin a board for the actual product.

author: Bassman59
author_rank: Super Contributor
timestamp: March 05, 2021, 03:46:17 pm
content: Quote from: SiliconWizard on March 03, 2021, 05:30:08 pmMicrosemi/Microchip provide a complete implementation of a RISC-V, and all of the tools needed, including an Eclipse-based IDE/debugger.QuoteFor a small "Hello, World!" example, the processor can execute out of block RAM, which gets initialized (by the FPGA's internal system controller thingie) from either internal "uPROM" or a different internal nonvolatile memory called sNVM. It can also be initialized from an SPI flash device. The processor can also execute out of DDR3 SDRAM.QuoteThat is indeed the easiest way to do it, and as you note it requires re-spinning the FPGA to update the micro firmware, and that's why the other options are presented.QuoteMicrosemi already provides the tools to do just that.What they provide is quite comprehensive, and as someone's Uncle Ben from Queens NYC might have once said, "with great power comes great ... complexity." So it's a small matter of wading through the documentation and the examples and doing some, you know, research and development.

author: Daixiwen
author_rank: Frequent Contributor
timestamp: March 08, 2021, 07:50:02 am
content: Quote from: Bassman59 on March 05, 2021, 03:38:06 pmI also noticed that if you don't use that monitor to reset the logic, the CPU never initializes correctly at start up and hangs in such a bad way that you can't even reset it through JTAG.Yeah Microsemi's documentation is just enough so that you think you have all you need when you are at the specification and component choosing phase, but when you start implementing things you realize how incomplete it is. And it's extremely difficult to find the information you are looking for

author: oliviasmithh900
author_rank: Contributor
timestamp: March 08, 2021, 10:59:05 pm
content: REading this post is so informational, wow you guys are like pro .... Btw its FIVE