The RISC-V ISA discussion

[SiliconWizard]

Again this has little to do with the ISA... An ISA is not an IP, and an IP is not an actual chip... That's 2 levels to overcome to get something certified...

Given the simplicity of the RISC-V ISA (at least if you stick to I (/E) or IM for instance), I guess that an actual implementation with a simple pipeline/in-order execution and nothing too fancy should be much easier to validate than any more complex core... but that's still a lot of work. Who's going to be first to commit the resources for that? Could be interesting, but I'd be willing to bet that some big fish will have to invest serious cash for this to happen.

Could happen with government grants, but still probably through a large and reputable corporation... and then that would be mainly for strategic independance, so no wonder China has seemingly invested more so far in actual RISC-V chips than most other countries AFAIK. So the first RISC-V processor in avionics applications could well be a chinese one in chinese planes for instance...

[brucehoult]

Sorry but "Use 50% less energy" sounds too good to be true... compared to what? Apples to oranges? But if that's true,  , you're going to own the market very soon.

I didn't make a claim that some RISC-V core uses 50% less energy than some other core. What I said is that even if someone makes such a core, that's still not the main reason to use RISC-V. Conversely, even if some RISC-V core used 50% more energy, the Open Source license-free nature of it might still be a reason to use it.

Basically, the exact technical specs don't matter, as long as they are reasonably in the same ballpark as others.

They *do* happen to be pretty good, but that's just icing.

[brucehoult]

Unlike, say, people who invested in .. well, it's a long list .. PDP11/VAX/Alpha, i860/i960/Itanium, PA-RISC, SPARC, ...

It's "interesting" that a lot of those have presumably had their "intellectual property rights" expire, and COULD probably be manufactured by anyone who really wanted to.  But most have other reasons that people aren't actually interested any more.

Certainly patents have expired, but I gather you could run afoul of copyright claims on the ISA itself, or the manual, or ...  I don't know. And Trademark infringement if you claim to be compatible with something rather than simply copying it and calling it something else.

What prevents anyone who wants to from making PowerPC- (1994ish) or MIPS32/MIPS64- (1999) compatible CPUs without a license?

https://en.wikipedia.org/wiki/OpenPOWER_Foundation

I'm aware of that. It appears to require applying to join their Foundation and getting a license.

[brucehoult]

E.g. considering the temperature range, chips have the following classification:

Consumer 0°C to +95°C -> Level E
Extended Consumer -20°C to + 105°C -> Level D
Industrial -40°C to +105°C -> Level C
Automotive: -40°C to + 125°C -> Level B
Avionics: -55°C to + 125°C Level A
extended Avionics: -55°C to + 150°C Level A+ <--------------------- new spec 2015

Of course, there are other specs to be satisfied, but the point is: Motorola's, Freescale's, and AMCC's devices were/are built with ruggedized technology and designed with rules to satisfy all the specs.

As I said, the same company that is already making their PowerPC avionics chips will be making the RISC-V avionics chips.

I'm sure they didn't suddenly forget the physical specs required, or how to achieve them :-)

[legacy]

Just for the records, the transaction from m68k to PowerPC took six years, and chips were manufactured by the same company. At some point, the contracts with Motorola were then moved to the new division Freescale. This for sure added some delay, anyway, it took six years.

One of the good-good reasons for using the PowerPC architecture is in real-time operation. There is a whole market for safety-critical equipment where even a small unpredictable delay is a problem. When a delay can kill people, or destroy millions of dollars of equipment.

There are some new ARM designs that are now reaching acceptable levels of real-time operation. ARM did some progress in 2016. But ARM does not manufacture itself, so it takes a couple of years for real processors to be available after the design. Last 2018 chips are interesting, a lot interesting even if they are still significantly lower performance in processing power compared to a PowerPC.

I do believe the architecture of RISC-V can (and will) be tuned to do it better, but one thing that PPC still does better than any other chip is radiation-hardened designs thanks to the contribution by IBM.

This is not "ISA architecture", this is "how the chip is made", and this is mainly due to the fact that the chip-manufacturer has by far the best fabs for rad-hardening but they have also redesigned parts of the chip to increase reliability.

Do you know that potentially AMD has the know-how (and potentially even the fab) for the satellite market but has always refused to do it? The reason is unknown, but it's interesting, since they could have potentially switched from x86 compatible to PowerPC. But they have never done it.

Switching from PowerPC to RISC-V is not a matter of redesigning the "die film", but rather a matter of literally redesigning everything. You have to simulate everything and to run a lot of experiments on it to pass qualifications. This can be done, but it's like talking about enormous amounts of money and resources and exploring numerous dead-ends, which would eventually concretize something for the avionics market.

Hence, if I was a CEO, I would reach it progressively. From level C to level B, from level B to level A.

The SEU Radiation Events program is very interesting. The entry-level is for alpha-particles-tolerant systems, which can be shielded thus only concerned with internal alpha sources, and this can be mitigated by enforcing the hardware qualification process, by choosing Level A and level A+ manufacturing, and requiring that there are no impurities and/or contamination of fab. process. But Neutrons-tolerant systems have a problem with cosmic ray flux, which depends on location, altitude, and atmospheric conditions, and it's very difficult to shield; in this case, you need chips qualified for SEU. The hardenest scenario is SEU/Neutrons, which are designed, tested and qualified as "radiation-hardened".

Even the CPU's internal cache needs to be protected via parity/ECC, and the external memory cells are spread to avoid a multiple-bit upset. IBM's, Motorola's, Freescale's, and AMCC's devices were/are built with ruggedized technology and designed with rules to mitigate those threats.

-

In short, in my opinion, "real-time operations made in ruggedized technology" is the keyword you have to beat.

[David Hess]

I do believe the architecture of RISC-V can (and will) be tuned to do it better, but one thing that PPC still does better than any other chip is radiation-hardened designs thanks to the contribution by IBM.

IBM used a silicon on insulator process for PowerPC which gives a big boost to radiation resistance.

Do you know that potentially AMD has the know-how (and potentially even the fab) for the satellite market but has always refused to do it? The reason is unknown, but it's interesting, since they could have potentially switched from x86 compatible to PowerPC. But they have never done it.

AMD shared process technology with IBM so they would have the same advantage.  I suspect they never bothered because the market is so small and development tools in that market were not geared toward x86.  Things might have been different if the embedded x86 market had still existed.

[legacy]

no wonder China has seemingly invested more so far in actual RISC-V chips than most other countries

Loongson is the "Chinese MIPS", and it's where they have invested money. A lot of money.

• commercial
• industrial
• enhanced industrial
• military
• enhanced military
• aerospace

Loongson has six product grades.

[legacy]

Ron Minnich:

[..] All this said, note that the HiFive is no more open, today, than your average ARM SOC; and it is much less open than, e.g., Power. […] Open instruction sets do not necessarily result in open implementations. An open implementation of RISC-V will require a commitment on the part of a company to opening it up at all levels, not just the instruction set.

[brucehoult]

Ron Minnich:

[..] All this said, note that the HiFive is no more open, today, than your average ARM SOC; and it is much less open than, e.g., Power. […] Open instruction sets do not necessarily result in open implementations. An open implementation of RISC-V will require a commitment on the part of a company to opening it up at all levels, not just the instruction set.

When he wrote that, soon after the release of the board, the zero-stage- and first-stage bootloader code had not yet been open-sourced. That was done a couple of months later, almost a year ad a half ago.

So that comment is way out of date.

[SiliconWizard]

no wonder China has seemingly invested more so far in actual RISC-V chips than most other countries

Loongson is the "Chinese MIPS", and it's where they have invested money. A lot of money.

Does that make what I said above any less true? I don't have exact figures (maybe Bruce does), but I've seen more chinese companies designing AND releasing RISC-V-based chips than in any other part of the world, and the reason is obviously independance (oh, and cost), which China works on relentlessly.

I don't know much about Loongson, I remember some chinese regular once said it was certainly not as significant as we thought, but it would be nice to know more. China may have invested public money in Loongson, but how many commercial companies have shipped Loongson-based processors so far compared to RISC-V? Anyway, this was not meant to be a contest of anything - just stating that chinese companies are definitely interested in RISC-V, and that so far, if predictions had to be made, it doesn't look unlikely that the first RISC-V processor to be certified could be a chinese one, which was my point.

I don't know all companies actively designing RISC-V cores in the world, but it looks like SiFive is one of the rare western ones. One of its closest "equivalent" (I think) is Andes, which is taiwanese. That's a very few companies outside of China.

Anyway, I think this is getting a bit off-topic as I meant this topic as a discussion about the ISA (which RISC-V is, and nothing more), and it seems to be slipping.

[legacy]

Loongson has six product grades, including military, enhanced military and aerospace. This is not an opinion, this is a fact, and it means that China really uses Loongson for everything they internally consider serious.

[brucehoult]

no wonder China has seemingly invested more so far in actual RISC-V chips than most other countries

Loongson is the "Chinese MIPS", and it's where they have invested money. A lot of money.

Does that make what I said above any less true? I don't have exact figures (maybe Bruce does), but I've seen more chinese companies designing AND releasing RISC-V-based chips than in any other part of the world, and the reason is obviously independance (oh, and cost), which China works on relentlessly.

I don't know exact numbers. Obviously there have been some very nicely spec'd and priced chips and boards coming out of China, based so far on the Kendryte K210 and GigaDevices GD32VF103. China has its own internal RISC-V Foundation equivalent (in fact I think two of them) so there's a lot of interest there and it's not just talk.

I don't know all companies actively designing RISC-V cores in the world, but it looks like SiFive is one of the rare western ones. One of its closest "equivalent" (I think) is Andes, which is taiwanese. That's a very few companies outside of China.

Andes is a serious player. They're an established company, with a long client list which they seem to be successful in switching from their own NDS32 to RISC-V. Both Andes and SiFive have announced numbers for incremental or total design wins at various points in 2019 and the numbers are in the same ballpark.

The PULP project, based out of ETH Zurich and University of Bologna seem to be quite influential in Europe. NXP is using their cores, and I think a number of others too. The RISC-V Foundation is using one of their cores as a reference implementation.

There are several companies with RISC-V cores here in Russia (I'm in Moscow for the New Year holidays, and will visit SPB a couple of days too). Cloud Bear and Syntacore are the main names. I count that as "western", culturally and in the approach to engineering and technology.

[brucehoult]

Here's the latest cheap board. The same STM32 F103 clone (but RISC-V) as the Longan Nano on a spartan 33mm x 33mm board with USB, crystal, power regulator, and 'every pin exposed' via 1/10" inch spacing plated-through holes, for $3. That's 108 MHz, 128 B flash, 32 KB SRAM.

https://www.cnx-software.com/2020/01/02/polos-gd32v-alef-tiny-risc-v-mcu-board/

[hamster_nz]

Exactly what's your interest?
Building an HDL cpu-core with pipeline?
Writing a cycle-accurate pipeline simulator?
Designing an HL compiler, from HL to machine-code?

Each of these fields has its trade-off

but talking about "architecture", I wish I had "see RISC-V run" (The Book) under my Xmas tree.
Has it already been written? Let's write it! I wanna it under the tree

With synchronicity, I've just got my Xmas holiday project up and running - a R32I in VHDL, working from the ISA (not somebody elses HDL).

It is currently running this code compiled by GCC, and then dumped into ROM & RAM by a script:

Code: [Select]

char text[] = "Hello world!\r\n";

int _start(void) {
  volatile char * serial           = (char *)0xE0000000;
  volatile char * serial_tx_status = (char *)0xE0000004;
  while(1) {
    char *s = text;
    while(*s) {
      while(*serial_tx_status) {
      }
      *serial = *s;
      s++;
    }
  }
  return 0;
}

I've still got to set up the stack and so on, but that will come...

It was pretty awesome feeling to see it running in real hardware. A combination of "Wow! It works!" and "Really? It's that easy?" and self doubt like "Gosh! I never thought it would work - must have missed something...".

It's not pipelined or anything at all advanced - memory reads take two cycles (due to memory latency), everything else takes one cycle. Optimised for size, it still runs at a little over 50 MHz in an Artix-7 -1. A slightly less resource optimized version runs at 60 MHz

Resource usage is close to nothing (less than of a low end FPGA dev board):

Code: [Select]

+-------------------------+-------------------+------------+------------+---------+------+-----+--------+--------+--------------+
|         Instance        |       Module      | Total LUTs | Logic LUTs | LUTRAMs | SRLs | FFs | RAMB36 | RAMB18 | DSP48 Blocks |
+-------------------------+-------------------+------------+------------+---------+------+-----+--------+--------+--------------+
| basys3_top_level        |             (top) |        731 |        682 |      48 |    1 |  95 |      3 |      0 |            0 |
|   (basys3_top_level)    |             (top) |          0 |          0 |       0 |    0 |   0 |      0 |      0 |            0 |
|   i_top_level           |         top_level |        731 |        682 |      48 |    1 |  95 |      3 |      0 |            0 |
|     (i_top_level)       |         top_level |          1 |          0 |       0 |    1 |   1 |      0 |      0 |            0 |
|     i_bus_bridge        |        bus_bridge |        103 |        103 |       0 |    0 |   0 |      0 |      0 |            0 |
|     i_peripheral_ram    |    peripheral_ram |          1 |          1 |       0 |    0 |   1 |      1 |      0 |            0 |
|     i_peripheral_serial | peripheral_serial |         63 |         63 |       0 |    0 |  62 |      0 |      0 |            0 |
|     i_program_memory    |    program_memory |          5 |          5 |       0 |    0 |   1 |      2 |      0 |            0 |
|     i_riscv_cpu         |         riscv_cpu |        558 |        510 |      48 |    0 |  30 |      0 |      0 |            0 |
|       i_alu             |               alu |        144 |        144 |       0 |    0 |   0 |      0 |      0 |            0 |
|       i_branch_test     |       branch_test |         29 |         29 |       0 |    0 |   0 |      0 |      0 |            0 |
|       i_data_bus_mux_a  |    data_bus_mux_a |         28 |         28 |       0 |    0 |   0 |      0 |      0 |            0 |
|       i_data_bus_mux_b  |    data_bus_mux_b |         18 |         18 |       0 |    0 |   0 |      0 |      0 |            0 |
|       i_decoder         |           decoder |         66 |         66 |       0 |    0 |   0 |      0 |      0 |            0 |
|       i_program_counter |   program_counter |         79 |         79 |       0 |    0 |  30 |      0 |      0 |            0 |
|       i_register_file   |     register_file |         49 |          1 |      48 |    0 |   0 |      0 |      0 |            0 |
|       i_result_bus_mux  |    result_bus_mux |         32 |         32 |       0 |    0 |   0 |      0 |      0 |            0 |
|       i_shifter         |           shifter |        113 |        113 |       0 |    0 |   0 |      0 |      0 |            0 |
|       i_sign_extender   |     sign_extender |         24 |         24 |       0 |    0 |   0 |      0 |      0 |            0 |
+-------------------------+-------------------+------------+------------+---------+------+-----+--------+--------+--------------+


[GeorgeOfTheJungle]

[GeorgeOfTheJungle]

I was going to buy a RISC-V longan nano ($4.90) to play, but ended buying an esp32 TTGO-Display ($4.99) because for the same price I get 31x the flash, 16x more RAM, two cores instead of one, at 2x the clock speed, plus WiFi, BT, an ethernet MAC, a lipo charger, etc. The only thing I'm missing is that nice acrylic case, damn it.

https://github.com/Xinyuan-LilyGO/TTGO-T-Display
https://www.seeedstudio.com/Sipeed-Longan-Nano-RISC-V-GD32VF103CBT6-Development-Board-p-4205.html

Edit:
Something I still don't get is the SiFive HiFive1 Arduino board: take a RISC-V "freedom e310" pcb and shove in the cheapest ($1.x) single core esp32 (for WiFi+BT) there is and... sell it for $59 ?!?!? I mean...  Not a good start if you ask me.

https://www.sifive.com/boards/hifive1-rev-b
https://sifive.cdn.prismic.io/sifive%2Fa4546ced-0922-4d87-9334-e97c1a9fd9a5_hifive1.b01.schematics.pdf

[SiliconWizard]

With synchronicity, I've just got my Xmas holiday project up and running - a R32I in VHDL, working from the ISA (not somebody elses HDL).
(...)

Cool stuff. I'll let you know here when my simulator has progressed enough that I can run your example code and Bruce's small benchmark on it.
(As to working from the ISA - same here. I'm writing it 100% from scratch with no 3rd-party code.) Goal is to later implement an HDL version as well.

I saw your core is not pipelined - it would have taken you a lot more time indeed. I still haven't quite finished my implementation of a 5-stage pipeline in software (the fact it's in software doesn't make it any easier as I'm really trying to simulate a true pipeline that could be later on relatively easily translated to HDL...) Do you intend on making your core pipelined? It would also be interesting to compare how many LEs it takes (comparing non-pipelined, 3-stage and 5-stage pipelined versions for instance...) and max freq in each case...

Additional question: have you implemented the FENCE instruction?

[andersm]

Something I still don't get is the SiFive HiFive1 Arduino board: take a RISC-V "freedom e310" pcb and shove in the cheapest ($1.x) single core esp32 (for WiFi+BT) there is and... sell it for $59 ?!?!?

They're not in the business of selling boards or chips. The boards are really meant to demonstrate their technology.

[hamster_nz]

Do you intend on making your core pipelined? It would also be interesting to compare how many LEs it takes (comparing non-pipelined, 3-stage and 5-stage pipelined versions for instance...) and max freq in each case...

I don't really have any intention of pipelining it - it was mainly to work out a micro-architecture.

Additional question: have you implemented the FENCE instruction?

All memory accesses are in order, so FENCE is equivalent to a NOP.

It has been quite interesting, and has let me seen quite a few optimizations that I wouldn't have seen otherwise. Currently the slow est path is the one to support the branching instructions:

Code: [Select]

                     Delay        Levels of logic               
Instruction register 2.454        1               
Decode               4.650        3               
Register File        1.586        1               
Branch test          3.820        6               
Program Counter      1.846        2               
Instruction Memory   1.801        2               
                    16.157       15  61.9MHz

I'm looking at duplicating the register file so the decoding is completely bypassed - without those levels of logic it should be ~3ns faster,
                               

Code: [Select]

With duplicated register file (at cost of 64 LUTMEM)                               
                     Delay        Levels of logic               
Instruction register 2.454        1               
Decode               1.660        0               
Register File        1.586        1               
Branch test          3.820        6               
Program Counter      1.846        2               
Instruction Memory   1.801        2               
                    13.167       12  75.9 MHz

That will move the bottleneck to the ALU, Shifter or load/store paths.

[legacy]

Do you have mul and div? If yes, how are them implemented?

Would you like to compile and test a simple integer calculator written in C implementing a recursive descent parser? It's metalbare, it just needs char_get and char_put over a (serial?) console.

I wrote this code in 2004 to test a wild toolchain for the Game Boy. I re-used this code in 2011 to test a pipelined softcore, helping a colleague to find a couple of bugs.

[westfw]

From a "user" point of view, I really like having a standardized instruction set that has been:

• Vetted by compiler people not to be awful to generate code for.
• Vetted by hardware people to have simple implementations/
• Vetted by hardware people not to have a bunch of "known bottlenecks" that would interfere with more complex implementations (pipelining being a good example.)
• created with some extensibility in mind.
• created with some sub-setting in mind.
• was non-proprietary enough to incorporate good ideas from multiple sources.
• but was constrained enough not to get out-of-control.

[hamster_nz]

Do you have mul and div? If yes, how are them implemented?

No, just the R32I

Would you like to compile and test a simple integer calculator written in C implementing a recursive descent parser? It's metalbare, it just needs char_get and char_put over a (serial?) console.

I wrote this code in 2004 to test a wild toolchain for the Game Boy. I re-used this code in 2011 to test a pipelined softcore, helping a colleague to find a couple of bugs.

Wold love to -  I'll have to write the Serial RX though...

I've attached the sketch of the design, so you can point and laugh

[Someone]

It's not pipelined or anything at all advanced - memory reads take two cycles (due to memory latency), everything else takes one cycle. Optimised for size, it still runs at a little over 50 MHz in an Artix-7 -1. A slightly less resource optimized version runs at 60 MHz

Resource usage is close to nothing (less than of a low end FPGA dev board):

Code: [Select]

+-------------------------+-------------------+------------+------------+---------+------+-----+--------+--------+--------------+
|         Instance        |       Module      | Total LUTs | Logic LUTs | LUTRAMs | SRLs | FFs | RAMB36 | RAMB18 | DSP48 Blocks |
+-------------------------+-------------------+------------+------------+---------+------+-----+--------+--------+--------------+
| basys3_top_level        |             (top) |        731 |        682 |      48 |    1 |  95 |      3 |      0 |            0 |


Well done, thats already competitive with a microblaze without much effort.

[SiliconWizard]

Do you have mul and div? If yes, how are them implemented?

No, just the R32I

Would you like to compile and test a simple integer calculator written in C implementing a recursive descent parser? It's metalbare, it just needs char_get and char_put over a (serial?) console.

I wrote this code in 2004 to test a wild toolchain for the Game Boy. I re-used this code in 2011 to test a pipelined softcore, helping a colleague to find a couple of bugs.

Wold love to -  I'll have to write the Serial RX though...

I've attached the sketch of the design, so you can point and laugh

Well, that's pretty basic but does the job - there's nothing to really laugh about here. It's rather typical and clean.

What amazes me is that it still manages to work at 50MHz+ without pipelining. Those Artix-7 FPGAs are damn great (and yes, RV32I is very lightweight, but still.)

[SiliconWizard]

Do you have mul and div? If yes, how are them implemented?

As he said RV32I, no, it doesn't include MUL and DIV ops which are part of an extension in RISC-V ('M'). Whereas the multiplies, with his non pipelined-design, should be achievable with a simple multiply operator in HDL without harming the max frequency too much (at least on those FPGAs), the divides are another story. I doubt they can be achieved without pipelining, and then it creates a whole new data hazard to handle...