RISC-V, what do you think about ?

[legacy]

riscv dot org, they seem to be almost ready 

[HAL-42b]

I'll print one as soon as I get my FIB Milling machine

In all seriousness though, I think it has a great potential. India is already interested and may have taped out one in one of their universities. As soon as we see it taped out commercially in China we might see a serious contender to ARM.

[marshallh]

Don't know much about it but if it's like the previous "efforts" it will be a design by committee disaster and cost buttloads to produce, ensuring its demise.

Hoping I'm wrong.

[BloodyCactus]

i think this will sink like a stone and nobody will care. much like the whole open sparc thing.

maybe china will knock something out on risc-v and move on from their mips loongson stuff.

[Rasz]

brilliant .. if you are in academia

[ataradov]

I believe this core was taped out in real products. I think that was some European company doing ICs for DVRs and set-top boxes.

I can't say I'm impressed with the instruction set, but it is actually a real working core, not like one of a few thousands MIPS clones made by students and beginner FPGA designers.

[legacy]

like my soft core, which is really useless from the industry point of view(1), but very awesome for hobbyist who want to develop in assembly as they did in 1980' with m68k, but over a modern risc-like, provided with a useful TAP (debug interface (2))

(1) I wanted to reduce the complexity, so I removed the pipelining stuff, I progressively introduced the cache (coherent) and multi processing (even if up to two CPUs), also the code density is really obscene ( ) , this is not good for BRAM, but it's decent enough if you can use an external DRAM of 32 Mbyte at least

(2) I like my TAP, as THE main reason to use this toy in my free time, obviously I do not want to sell to google, or to the first chinese company, even if …
… even if ... if I was a genius at marketing, I might say that I have invented

the reality Engine, Einstein on chip

so, if someone wants to pay me thousand and thousand UKP, I might sell my super marvelous && Supercalifragilisticexpialidocious core, which is a crap from the computer science point of view (because it's not superscalar, and it comes with no pipeline under the hood) but it can easily includes a tensor do-processing unit, which can actually accelerate things within tensor components, in a quadri-dimensional coordinate system, ... whose columns are the forces per unit area, acting on the e1, e2, and e3, plus a column for e-time, which is a superset compliant with the introduction of Einstein's theory of general relativity, around 1915.

I am kidding, but I have really designed (as proof of concept, which sounds more like intellectual challenge, "we do because we can do") a TPU, and odiously nobody will ever use it even if it might be implemented

[legacy]

brilliant .. if you are in academia

in short it's what I guess

[legacy]

committee disaster

currently it's available as
1) simulator (it comes free, open source, it just takes effort to configure and compile a few things)
2) arm+fpga board (the hardware side is expensive, the software side is free but takes more effort to configure and compile things)

in choice2, the arm core initializes things, load the bitstream, bootstrap the soft core, then it provides a sort of I/O virtualization

I guess that all of this means: good only for academia, for people who want to experiment

[ataradov]

I guess that all of this means: good only for academia, for people who want to experiment

It is not. The core has been taped out in real products. They are specialty ICs, not general purpose mass-market controllers. But this thing is much more than a toy.

They also have very good documentation and toolchains.

I can't instantly find info, but I have been tracking progress of this project for quite some time. There are plenty of things I don't like about it, but it is the best shot at free and open processor we have right now.

It is like KiCad, not the best thing out there, but it is the best as far a free and open goes.

[legacy]

taped out in real products

which ones ?


edit:
and no, there is no chance to compare Kicad with Eagle/CAD (or Altium)
not for me, at least (I am used to use both to the last two, for job purposes)

[legacy]

Called boom, it's an Out-of-order RISC-V variant
RISC-V has a number of features that make an OOO machine more manageable to implement.

[legacy]

I wonder if it will teach the Tomasulo Algorithm, let's check it 

[ataradov]

and no, there is no chance to compare Kicad with Eagle/CAD (or Altium)

And yet some people do use KiCad successfully for reasonably big projects. It is not a commonplace, of course. So is RISC-V is not a common core and I would not use it in my projects in a foreseeable future, may be never. But the only way to create a competitor to ARM and others is to create anything at all and persistently work on improving it and making people aware of it existence.

[AlxDroidDev]

Supposing the industry implements this (which I don't think will happen), it's just a matter of time until each company add their own specializations and extensions to the standard, and making these extentions proprietary, just so they can advertise their product's differential. Intel will have RISC-V+, then AMD will have a RISC-V², followed by NVidia marketing a RISC-Vmax, and then in a couple of years what was meant to be an industry standard just became a sea of incompatible instruction sets, requiring tons of ifdefs in the code. So long standards!

Marketing people hate standards. Imagine this ad from NVidia: "We're just like AMD, but with a lot more hype and a nice case sticker at a higher price tag".

Besides, they don't seem to have the big players in the industry jumping on the RISC-V bandwagon. It all seems pretty limited to academia, like other forum members have stated and I agree. At the very least, they should have Samsung supporting the initiative. Intel would be nice too!

OTOH, there have been nice things that came out of Berkley, so who knows.

[ataradov]

So long standards!

And that's why you need a governing organization and certification program. They are not stupid, and I hope they have claimed proper trademarks.

Everyone had implemented the same USB specification without making changes.  The core is no different.

But you are right, there is no point for big companies to jump on it. But smaller companies may very well implement this into their products. Imagine ESP8266, but with RISC-V instead of Xtensa. Both are non-standard cores, so why not go with open if it is developed to a reasonable level.

[legacy]

And yet some people do use KiCad successfully for reasonably big projects

tell me which projects

[legacy]

Supposing the industry implements this (which I don't thing will happen), it's just a matter of time until each company add their own specializations and extensions to the standard, and making these extentions proprietary, just so they can advertise their product's differential. Intel will have RISC-V+, then AMD will have a RISC-V², followed by NVidia marketing a RISC-Vmax, and then in a couple of years what was meant to be an industry standard just became a sea of incompatible instruction sets, requiring tons of ifdefs in the code. So long standards!

Marketing people hate standards. Imagine this ad from NVidia: "We're just like AMD, but a lot more hype and a nice case sticker at a higher price tag".

Besides, they don't seem to have the big players in the industry jumping on the RISC-V bandwagon. It all seems pretty limited to academia, like other forum members have stated and I agree. At the very least, they should have Samsung supporting the initiative. Intel would be nice too!

OTOH, there have been nice things that came out of Berkley, so who knows.

exactly what I think, including species { RISC-V+, RISC-V², RISC-Vmax }, which is written in a brilliant funny way 

[ataradov]

tell me which projects

They are not public. If you don't want to believe me, then don't.

I personally prefer DipTrace and hate Altium. People have different tastes and used to different things. All those tools are perfectly usable, some provide more service, some less, not a big deal.

And I'm hearing really good things about recent code contribution to KiCad from CERN, but have not tried it myself.

[aventuri]

turning back to the main topic, i.e. if RISC-V, an interesting open source CPU, could get some steam into the "real taped-out" world... let me note that those "crazy folks" at Allwinner (who you all know for the A10/A20 family of tablet chips) did put in their new lineup H3 (flagged as a 4 core ARM32 cpu), also a "fifth" CPU, called AR100: http://linux-sunxi.org/AR100

looks like this CPU should be an ASIC version of the OpenRisc project: http://github.com/openrisc/

the funny thing is that people on linux-sunxi ML are investigating how to repurpose it, supposedly born to "control" the PMIC during deep-sleep mode of main CPUs, for real time task as it seems it can drive the whole IO space. next  to that, security concerns are investigated too, as malicious code too could try to exploit it..

let's see, but these open cores are someway compelling at some degree for manufacturers, as they do not bring the usual long NDAs and licensing paper filling tasks..

[AlxDroidDev]

So long standards!

And that's why you need a governing organization and certification program.

I think differently, but there are pros and cons of having a governing body in a standard. A company's R&D might be limited if there are too many standards to follow. OTOH, if several companies are developing on the same standard, there will be more competition on the marketplace, eventually leading to price drops.

Everyone had implemented the same USB specification without making changes.  The core is no different.

Bluetooth is a standard too, but that didn't stop Apple from making bluetooth devices that were completely incompatible with everything else and still call it Bluetooth.

Imagine ESP8266, but with RISC-V instead of Xtensa. Both are non-standard cores, so why not go with open if it is developed to a reasonable level.

  Agreed, but if one is to follow RISC-V without implementing proprietary extensions, it will be just another product in the market, w/o any advantage or differential. It will just like buying 74xx chips: you choose by the price, not by the manufacturer or marketing, since there are several people manufacturing the exact same product. It isn't so interesting to be in a market where the only deciding purchase factor is the price, unless:
- you have lower production costs than the competition, so you have a better price
- you are in an area hard to reach by the other manufacturers (due to geographic location, taxes, politics, and so on)
- you have a supply contract with a big customer
- the overall demand is still high to keep all the manufacturers "happy"

How many identical chips aren't produced by Fairchild, TI, ST, KEC, ICF, NJR, NXP, and all the other semi-conductor companies? They don't even bother marketing chips like LM317, LM324, 555, 40xx, 74xx and so on, and that's why many companies in this business either disappeared, stopped producing ICs or where bought. You don't buy "TI's LM324". You buy whichever LM324 is cheapest and in the package you need. This doesn't keep companies in the business.

[MrSlack]

the funny thing is that people on linux-sunxi ML are investigating how to repurpose it, supposedly born to "control" the PMIC during deep-sleep mode of main CPUs, for real time task as it seems it can drive the whole IO space. next  to that, security concerns are investigated too, as malicious code too could try to exploit it..

That's not a new idea. Intel ME has an ARC processor derived from a Nintendo SuperFX on the PCH that runs the ThreadX RTOS. That's chock full of shitty holes under S3 sleep as well as it can talk to all sorts of things. That covers most recent Intel CPUs and chipsets. Service processors are a horrible idea if they can talk directly to the host machine.

Open cores miss strong standardisation. We'll be in Z80 clone territory again in no time. I'd rather a license dictatorship like ARM.

TBH though the only strong, standard open ISA that has been successful is the JVM and perhaps 1% of end users actually give a crap past the high level managed compiler/interpeted layer anyway. Doesn't matter what is underneath it all. The machine is a means to an end and that end us usually piles of cash.

[ataradov]

So there is real taped out OR1000.

OR has been taped out many times. As it has been pointed out, its microcontroller profile is used as a system controller in many proprietary designs.

[ataradov]

+ Agreed, but if one is to follow RISC-V without implementing proprietary extensions, it will be just another product in the market, w/o any advantage or differential.

I don't see RISC-V used in standalone general purpose MCUs.

But in things like ESP8266, you are not differentiating on the core. Wi-Fi component is the selling point here. There are many application-specific parts that a different enough on their own, the MCU core is secondary.

And from there, it can eventually spread into general purpose market. But very eventually, like 10-15 years from now.

[AlxDroidDev]

The machine is a means to an end and that end us usually piles of cash.

I believe I've been using the wrong machines then! The ones I have never ended me piles of cash, unless I exchange my salary for zimbabwe dollars!

[HAL-42b]

Looks like it has already been taped out. This guy says they can ship to academia packs of 100 for an incredibly low price of 30.000$.

https://youtu.be/mD-njD2QKN0?t=40m45s

Also it appears India has officially adopted the ISA and NPTEL is spending 80 millions on it.

[legacy]

India has officially adopted the ISA and NPTEL is spending 80 millions on it.

so, Instruction Sets Want To Be Free: will be called "India core" ?

[legacy]

UC Berkeley Computer Science Professor, David Patterson reviews 50 years of computer architecture to show there is now widespread agreement on instruction set architecture ISA. Unlike most other fields, despite this harmony there is no open alternative to proprietary offerings from ARM and Intel. In his talk he proposes RISC-V RISC Five, which targets Systems on a Chip SoC

no open alternative to proprietary offerings from ARM and Intel

[legacy]

 

[MT]

I read years ago, like 10-12, a article about a CPU guru who said: the world dont need yet another cpu architecture.

[Kalvin]

I read years ago, like 10-12, a article about a CPU guru who said: the world dont need yet another cpu architecture.

I also read an CEO who said ""There is no reason anyone would want a computer in their home."

When I first looked at this thread my thoughts we also "oh no, yet another academic architecture". After watching the Patterson's lecture I think now otherwise, there is still room for another ISA.

[aventuri]

When I first looked at this thread my thoughts we also "oh no, yet another academic architecture". After watching the Patterson's lecture I think now otherwise, there is still room for another ISA.

yes, ..one that doesn't need to win just for the technical merit (pure performance like Intel did for many years, or better ratio performance/power/money like more recently Arm) but for other reasons too, for becoming the ISA for "the rest of us"..

as always, a "new kid in town" does just need to be "good enough" and mainly with NO-STRINGS-ATTACHED! :-)

[Jeroen3]

Not reading all the papers in depth it looks like this: "arm is expensive, we can do better".

Mandatory xkcd:

[ataradov]

Not reading all the papers in depth it looks like this: "arm is expensive, we can do better".

ARM, MIPS, PowerPC, and dozens of other RISC processors are exactly the same with minor variations on the theme.

So having at least one robust and open solution will not hurt. After all, they are doing their own thing and not asking for money, so it all god in my book.

[timb]

So long standards!

And that's why you need a governing organization and certification program.

Bluetooth is a standard too, but that didn't stop Apple from making bluetooth devices that were completely incompatible with everything else and still call it Bluetooth.

What are you blathering about? All Apple devices implement Bluetooth as defined by the Bluetooth SiG.

Now, they might implement custom Bluetooth 4 (LE) protocols, for talking from say the phone to computer (Handoff, etc.) but so do hundreds of other companies! It's part of the Bluetooth LE standard!

In fact, on iOS they actually open this up and allow apps to implement any custom protocols they want. This is how third party devices talk to iPhones without having to register with Apple's Made for iPhone program (as is the case with the Lightning and formerly Dock interfaces).

What they *don't* support is Classic Bluetooth file transfer (aside from contacts and photos), on iOS at least; OS X fully supports it.

If you don't like Apple, fine, but try knowing what you're talking about before spouting off. It takes 60 seconds on Google to verify something.

[HAL-42b]

I read years ago, like 10-12, a article about a CPU guru who said: the world dont need yet another cpu architecture.

There are two reasons that might make somebody say that: 1 - He did not anticipate the end of Moore's law. 2 - He doesn't care about Open Source.

[legacy]

The problem with RISC-V is that the target markets — small companies looking for extreme customization — simply may not be big enough to ever spark much in the way of toolset development, familiarity, or cost savings. How many companies both want to build their own extremely customized architecture and can afford to hire the engineers that would do the job more ably that a default Cortex-A5 CPU from ARM? Our guess is not many. This leaves RISC-V in an uneasy no-man’s land — the engineers with the expertise to build the products are most likely familiar with other ecosystems, while the companies that would most benefit from the cost savings and customized features can’t afford the engineers.

interesting 

[edavid]

The problem with RISC-V is that the target markets — small companies looking for extreme customization — simply may not be big enough to ever spark much in the way of toolset development, familiarity, or cost savings. How many companies both want to build their own extremely customized architecture and can afford to hire the engineers that would do the job more ably that a default Cortex-A5 CPU from ARM? Our guess is not many. This leaves RISC-V in an uneasy no-man’s land — the engineers with the expertise to build the products are most likely familiar with other ecosystems, while the companies that would most benefit from the cost savings and customized features can’t afford the engineers.

interesting 

I don't agree that it has to be customized to be useful... it could be adopted by anyone who wants to develop an SoC, but doesn't want to pay the ARM tax (like the already mentioned example of the ESP8266, or the SkyTraq NavSpark GPS).

[legacy]

it could be adopted by anyone who wants to develop an SoC, but doesn't want to pay the ARM tax

in this case, ins't better OpenRISC? OpenRISC cores come under the GPL, which requires that all derivative works also be open and free, while the RISC-V authors aim to provide several freely available CPU designs, under a BSD license, but (if I am correct) the BSD license allows derivative works such as RISC-V chip designs to be either open and free like RISC-V itself, or closed and proprietary 

[MrSlack]

I'd rather pay the ARM tax myself if I was building a product.  There's enough experience out there to be able to solve any speed bumps you hit. Also TTM is likely lower on something vendored and staff fungibility is better with something more mainstream. Not all cost is production; a lot is R&D and support and you need.

I'd rather write software with Erlang at work but it's not the real cost centre.

[ataradov]

in this case, ins't better OpenRISC?

In ideal world, yes. In ideal world we also have communism.

In real world, it is not always possible to have things free and open.

[legacy]

I'd rather pay the ARM tax myself if I was building a product

this is my mind position (including gcc, which i'd rather prefer to avoid, and I pay keil and green hills myself)
I was just trying to understand their motivations

[ataradov]

I was just trying to understand their motivations

But the reality is, all those special use applications do want to avoid ARM tax, and use crap like Cortus and Xtensa. If you are picking between ARM and anything else, no contest, ARM wins. If you are picking Cortus vs. RISC-V, RISC-V wins, IMO.

[MrSlack]

I'd rather pay the ARM tax myself if I was building a product

this is my mind position (including gcc, which i'd rather prefer to avoid, and I pay keil and green hills myself)
I was just trying to understand their motivations

Indeed - can't stand GCC/gdb. LLVM+clang is my daily driver albeit on x86-64.

[legacy]

gdb

gdb is pure crap from my point of view, even if I have developed (when I was a student) a gdb-stub for both my MIPS32 board (Atlas) and 68EC000 board (IDP)

[MrSlack]

gdb

gdb is pure crap from my point of view, even if I have developed (when I was a student) a gdb-stub for both my MIPS32 board (Atlas) and 68EC000 board (IDP)

Rather you than me. About as often as I use it now is backtraces from core files. Thank goodness for valgrind, unit tests and assertions sprinkled everywhere.

[legacy]

reality is, all those special use applications do want to avoid ARM tax, and use crap like Cortus and Xtensa. If you are picking between ARM and anything else, no contest, ARM wins. If you are picking Cortus vs. RISC-V, RISC-V wins, IMO.

ah, ok, understood 

I am more "experienced" with NIOS* (Altera IP), and picoBlaze (Xilinx IP)
I admit I still have no serious job experiences with SOC and uncommon "soft cores"

I mean, when I happen to be involved with SOC I used an ARM ASIC core
and I developed all the hardware customization (VHDL side) around it
so my experiences are: ARM chip attached to an FPGA, and the ARM side usually involves Keil
while I happen to use green hills only for tasks in avionics, and I rarely used picoblaze and NIOS2

practically I used them only when I was in academy, and I sometimes happen to use them for hobby

[legacy]

Thank goodness for valgrind, unit tests and assertions sprinkled everywhere.

yes, that is a good point, as I hate "CodePurify" and "VectorCast"

[legacy]

basically you are using something like this, I have a few positive hobby experiences with ARM 

[MT]

I read years ago, like 10-12, a article about a CPU guru who said: the world dont need yet another cpu architecture.

There are two reasons that might make somebody say that: 1 - He did not anticipate the end of Moore's law. 2 - He doesn't care about Open Source.

Or maybe he just worked undercover for IBM/Microsoft who enjoy black box designs. Newer trust the words from a guru...

[legacy]

Closed, end-to-end systems

in the new movie about Steve Jobs, the actor said
- "so, you can send an email only from a NextCube to a NextCube
because I want it closed, end-to-end systems" -

that talk has begun years earlier, inside a garage, where Wozniak said "no, absolutely no!"

The best Guru, ever

[autobot]

Besides, they don't seem to have the big players in the industry jumping on the RISC-V bandwagon. It all seems pretty limited to academia, like other forum members have stated and I agree.

There was an eetimes story about support from Google and other big companies.

[helius]

Closed, end-to-end systems
in the new movie about Steve Jobs, the actor said
- "so, you can send an email only from a NextCube to a NextCube
because I want it closed, end-to-end systems" -

Movies are usually sexed up a lot (like the recent The Big Short which made commodity analysts much more exciting than they really are)
In reality NeXT Mail was a regular mail client with the ability to display PostScript programs through the system PostScript interpreter (something shared with other Unix systems). This made it able to embed graphics, animations, and sounds in mail messages. It also had other abilities:

This feature has led several clever hackers to create NeXTmail
PostScript "viri". I have seen several of these, all pranks, none
malicious. One causes a number of spiders to scurry across the
desktop, which must be squashed with a mouse click before allowing
you to regain control of your desktop. Another causes all the window
objects to drop off the bottom of the desktop one at a time, yet
another shakes the entire desktop, giving the impression of an
earthquake.

[legacy]

In reality NeXT Mail

in the movie, it happens because

• Woz said "no, I will never build what you want" (Apple-II, Jobs wanted 2 slots, Woz wanted 8 slots)
• other people said the same to mr.Jobs, persuading him to change his silly end-to-end idea (NextCube, iMac @ hello again)

and so we get the NextStep kernel adopted by Apple, and used for the new Darwin (OSX) generation
which comes to be BSD-like

[legacy]

specifically the RISC-V's ISA: what do you think, guys?

[ataradov]

specifically the RISC-V's ISA: what do you think, guys?

It is new, so it did not have enough time to grow with all sorts of special cases and extensions.

But the design is reasonably extensible, which is good.

Instruction set itself seems to be reasonable and on par with any other RISC ISA.

[legacy]

I have downloaded it into my Kindle, and I am reading it carefully
I might grab (and learn) something interesting from them

[legacy]

analyzing RISC-V's ISA, compared to Epiphany 

[HAL-42b]

analyzing RISC-V's ISA, compared to Epiphany 

Risc-V and OpenRisc are open RISC architectures. I think they have an advantage over x86.

Epiphany on the other hand is a dark horse and is based on a very old favorite of mine - the Transputer.



That architecture was far superior to x86 even in the 80's but it was British and the world monopoly had to be 'Merican. So the transputer died in obscurity while Intel took over the world.

It is very interesting how the transputer eliminated the multi-core bottlenecks that early. Iann Barron is definitely worth listening to:

[Kalvin]

analyzing RISC-V's ISA, compared to Epiphany 

Risc-V and OpenRisc are open RISC architectures. I think they have an advantage over x86.

Epiphany on the other hand is a dark horse and is based on a very old favorite of mine - the Transputer.

That architecture was far superior to x86 even in the 80's but it was British and the world monopoly had to be 'Merican. So the transputer died in obscurity while Intel took over the world.

<video removed>

It is very interesting how the transputer eliminated the multi-core bottlenecks that early. Iann Barron is definitely worth listening to:

<video removed>

XMOS's XCORE is based in transpurter and is quite popular in real-time audio signal processing (DSP). The devices are quite inexpensive and the devices can process 1000MIPS - 4000MIPS per device. Each device can have 8 to 32 cores, and each core can run 50 MIPS up to 100+ MIPS. Some of the devices can have USB 2.0 PHY  and Gigabit Ethernet RGMII interface, too. The programming is done in C with XMOS extensions. Basically no operating system is required as the task synchronization and communications is done at hardware level using the XMOS C priimitives. The user can create additional on-chip peripherals (like CODEC I2C interfaces etc.) using XMOS C and allocating one core for each I/O task without any overhead to system functionality or real-time performance. Pretty cool.

[Sal Ammoniac]

XMOS's XCORE is based in transpurter and is quite popular in real-time audio signal processing (DSP). The devices are quite inexpensive and the devices can process 1000MIPS - 4000MIPS per device.

XMOS is an under-appreciated and cool architecture that's worth taking a look at. It some ways it's like dealing with an FPGA where multiple things are happening in parallel and some people just can't wrap their heads around that.

[ataradov]

XMOS is an under-appreciated and cool architecture that's worth taking a look at. It some ways it's like dealing with an FPGA where multiple things are happening in parallel and some people just can't wrap their heads around that.

Xmos only looks "cool". In reality, what you can do is rather limited, so if your application calls for parallelism, then just stick with FPGAs. You will be able to use normal HDLs instead of some non-intuitive C with quirky parallel extensions.

Low end Xmos devices available in reasonable packages are not capable of that much, and higher end devices are only available in BGA and require complicated power supplies. Just like FPGAs.
 

[Sal Ammoniac]

Xmos only looks "cool". In reality, what you can do is rather limited, so if your application calls for parallelism, then just stick with FPGAs. You will be able to use normal HDLs instead of some non-intuitive C with quirky parallel extensions.

Depends on your background. Software people are more likely to grok the XMOS C extensions than Verilog/VHDL.

[helius]

Xmos only looks "cool". In reality, what you can do is rather limited, so if your application calls for parallelism, then just stick with FPGAs. You will be able to use normal HDLs instead of some non-intuitive C with quirky parallel extensions.

I thought the word "intuitive" had already been banned by all thoughtful engineers? It is a red herring every time it appears.
FPGAs are very bad at dynamic processes where you add or remove activities in response to certain conditions, because the allocation of resources to each process is fixed. The languages used (HDLs) don't help you to even understand the problem, and the chips have very primitive support for it.

[legacy]

so, he said "future languages ? deprecate as many features as possible" 

[Kalvin]

XMOS is an under-appreciated and cool architecture that's worth taking a look at. It some ways it's like dealing with an FPGA where multiple things are happening in parallel and some people just can't wrap their heads around that.

Xmos only looks "cool". In reality, what you can do is rather limited, so if your application calls for parallelism, then just stick with FPGAs. You will be able to use normal HDLs instead of some non-intuitive C with quirky parallel extensions.

Low end Xmos devices available in reasonable packages are not capable of that much, and higher end devices are only available in BGA and require complicated power supplies. Just like FPGAs.

All depends on the application. The XCORE processors are quite easy for an embedded designer with C background wanting to do real-time DSP stuff, for example. The XMOS provides C compiler, the simulator and wealth of software examples how to do things:

https://github.com/xcore

And 32x32bit MAC with 64-bit accumulator doesn't hurt either as you can process 24-bit audio quite nicely, for example. The DSP library is quite extensive:

https://www.xmos.com/download/private/lib_dsp-%5Buserguide%5D%281.0.3rc1%29.pdf

Here is XCORE DSP performance application note:

https://www.xmos.com/de/download/private/AN01011%3A-DSP-performance-on-XS1-L-devices%281.0.1rc1%29.pdf

One core running at 50MIPS can perform

- Single cycle channel communication between cores
- Single cycle 32 * 32 into full 64 bit precision MACC instruction
- Single cycle instruction latency
- 16 million MACs / second
- 20 biquad EQ filters, 48kHz
- 100 tap FIR filter, 150kHz
- 256 point fast FFT, 48kHz (8 bits)
- AES decoder at 9 Mbits/sec

Each device can contain 8 to 32 of these cores and the inter-core communication is very efficient, the devices are very suitable for real-time signal processing. The performance of one core may not be too impressive (16 million MACS/s), but dividing the problem into individual blocks and running each block on a separate core, all cores running in parallel, the total performance may be quite impressive for a chip in $5 - $20 price range:

www.digikey.com/product-search/en/integrated-circuits-ics/embedded-microcontrollers/2556109?k=XMOS
 
I would say that it takes 10x - 100x less effort to implement [audio] signal processing on XCORE compared to FPGA. The designer does not have to build the DSP-processing blocks, worry about interprocess-interfaces, write microcode assembler in order to get the algorithm implemented, write testbenches for each block, simulate and debug the damn thing. That said, the modern FPGA devices are wonderful beasts containing lots of DSP processing resources with a decent price-tag, but creating and completing the actual design can be a nightmare because of the reasons stated above.

Edit: The XCORE might have been a suitable solution for David's 3D-printer as the G-Code parser and the motor controlling algorithms could have been running in parallel without a need for any G-code parser optimization:
https://www.eevblog.com/forum/blog/eevblog-843-david's-rprint-3d-printer/

I am not endorsing XMOS, but I see it as a good alternative for a real DSP-processor or FPGA.

[captbill]

Interesting. I wonder if the RISC-V specification is realized with ProjectOberon.

I can ASSURE you that this 'RISC-V' is much like Professor Wirth's RISC5 processor for Oberon. You know, Professor Wirth, who invented Pascal.

ProjectOberon.com is truly awesome. You have the whole kit: the Verilog files to synthesize the RISC5 'core', the excellent Oberon operating system which is developed in Oberon the language+compiler. All in LESS THAN 2mb. A full, graphical, OS, networking, mouse, keyboard, and sdcard file system on an FPGA.

You need the right FPGA board (with the right ram setup). Several boards are available based on this open source project. Saanlima.com has several options just for ProjectOberon. Saanlima is the producer of the Pipistrello FPGA which is like a high end version of the Pipistrello from Gadget Factory. Here is the brand ne arrival:
http://saanlima.com/store/index.php?route=product/product&product_id=64.



You can actually just use the emulator to develop on to try out before you buy the FPGA board. http://www.paddedcell.com/projectoberon/RISCW32.zip

I, honestly don't know of anywhere you have a system that you can actually begin to GRASP it all like Oberon. You really can know the whole system and nothing is too overly complex or hidden.

Truly unique. Have a look!

[HAL-42b]

First time I hear about Project Oberon, seems very interesting. Thanks for introducing me.

[captbill]

First time I hear about Project Oberon, seems very interesting. Thanks for introducing me.

I just found the official webpage for the new Pepino. It must have just recently been added.
http://www.saanlima.com/pepino/index.php?title=Welcome_to_Pepino

I would love to see Dave do 'unboxing video' of this one. I know he doesn't do silly 'unboxing videos' but this one might be a fun exception, just to demonstrate how simple you can build up this whole system from raw Verilog to a full blown development station, ON A WHIM! I had zero problems as a total noob with FPGA's to get Oberon going on the Pipistrello.

[captbill]

Xmos only looks "cool". In reality, what you can do is rather limited, so if your application calls for parallelism, then just stick with FPGAs. You will be able to use normal HDLs instead of some non-intuitive C with quirky parallel extensions.

Depends on your background. Software people are more likely to grok the XMOS C extensions than Verilog/VHDL.

How about this:

Lola-2 (LOgical LAnguage)

Lola-2 is a Verilog pre-processor written in Oberon. It takes the cryptic edge off of Verilog and presents it in a very understandable 'pascal-ish' dialect. It is really effective to help you actually see what is happening more intuitively.

Here is what's going to blow your mind: here is the Lola-2 code to BUILD THE COMPLETE PROJECTOBERON! Yes, Professor Wirth has the full RISC5 processor described in Lola-2 which compiles the Verilog files, which compiles the processor, which compiles the Oberon OS, which hosts the Oberon compiler....that compiles Lola-2!!!!

How 'complete-round-trip' is that?

Read the last line of the Lola-2 documentation https://www.inf.ethz.ch/personal/wirth/Lola/LolaCompiler.pdf


To show the viability of Lola, the entire RISC processor, including its environment and device
interfaces, has successfully been expressed in Lola                                          

[legacy]

I just found the official webpage for the new Pepino

the ram is not enough: only 2 MBytes (in the PRO version) 

[coppice]

It is very interesting how the transputer eliminated the multi-core bottlenecks that early. Iann Barron is definitely worth listening to:

They certainly didn't eliminate the multi-core bottleneck. In the released silicon the communications channels were so crippled it didn't even alleviate the bottlenecks much. Most Transputer designs were limited by comms bandwidth.

[captbill]

I just found the official webpage for the new Pepino

the ram is not enough: only 2 MBytes (in the PRO version) 

Not enough ram for what though? This little puppy will compile the whole system from the ground up in less than a minute (or was that 10 seconds?), or something crazy like that. It is very fast and I have never witnessed any lag that I remember. It also, if you dig into the specs, is only running at a measly 25mhz but I can't find anything 'slow' !! Astonishing really. I can't even imagine why I would need any more ram. In fact, if you buy the 2mb version, you will have wasted ram while Oberon is running. The 2mb 'Pro' version is to accommodate some of the other bitfiles like MacintoshPlus, Pac-Man, Doom etc.

Granted, it is not going to do 3d graphics with only a 1mb frame buffer, but this is a development system built for learning and as such has a 'simple as possible but not simpler' philosophy. The minute you add on high capacity ram you will have greatly over-complicated this beautifully simple design. Besides, nothing is to stop you from adding anything you need/desire. You simply build your own Ram.v design.

[HAL-42b]

They certainly didn't eliminate the multi-core bottleneck. In the released silicon the communications channels were so crippled it didn't even alleviate the bottlenecks much. Most Transputer designs were limited by comms bandwidth.

They did that in the era when the closest competitor was strictly single core. By reducing the need for inter-core communication they designed around the connectivity bottleneck.

Moreover, they proved even then that parallel computing can't be solved in software.

[legacy]

preface: I do not like fanatics and fanboys, including gnu-boys, apple-boys, and oberon-boys

Not enough ram for what though?

to put a few useful applications on, including debuggers
2 Mbyte is definitively too poor
also, I'd like to recycle the fpga board for other projects
and again, the ram is too poor!

[captbill]

preface: I do not like fanatics and fanboys, including gnu-boys, apple-boys, and oberon-boys

Not enough ram for what though?

to put a few useful applications on, including debuggers
2 Mbyte is definitively too poor, also I'd like to recycle the fpga board for other projects, and again, the ram is too poor

Well, this is definitely not for you then.

[legacy]

Moreover, they proved even then that parallel computing can't be solved in software.

I'd like to see the Epiphany, and hear about real-life feedbacks from users
unfortunately it seems that only a few guys are using it
and as far as I read, the IV 64-core Microprocessor (aka E64G401)
is going to have its End of Life

a kit costs ~250 euro (from Amazon), which is a bit expensive for me
and to tell you the Truth, I am tempted to "try" the fun in first person 

[legacy]

Well, this is definitely not for you then.

I think so 

I am interested only in the RISC-V core
and I am going to home-build a Papilio/PRO-like board
it will come with 8Mbyte, which is exactly what I need

[captbill]

Well, this is definitely not for you then.

I think so 

I am interested only in the RISC-V core
and I am going to home-build a Papilio/PRO-like board
it will come with 8Mbyte, which is exactly what I need

I didn't intend to derail your thread. Although it wasn't too clear if you were interested in options in the RISC5 department generally or if you were specific to the 'RISC-V' from the link you provided.

Just to clear up your ram concerns: all your programs are stored on an sdcard so no worries there. The 'flash ram' that houses the bitfiles is 16mb, much more than comes standard with most FPGA dev boards. Oberon only takes 2mb so you have plenty of room for many more. Oberon boots in less than two seconds. I can go from Oberon to Pac-Man in less than 5 seconds and that is manually. Store them in flash and switch them in probably 2.5 seconds.

Regards

[coppice]

Moreover, they proved even then that parallel computing can't be solved in software.

I'd like to see the Epiphany, and hear about real-life feedbacks from users
unfortunately it seems that only a few guys are using it
and as far as I read, the IV 64-core Microprocessor (aka E64G401)
is going to have its End of Life

a kit costs ~250 euro (from Amazon), which is a bit expensive for me
and to tell you the Truth, I am tempted to "try" the fun in first person 

If you just want to experiment to get a feel for the potential of these things, the E16G301 board is only $99 at Amazon. The E64G401 is EOL, but they don't appear to have a follow on part. It looks a lot like a business starving to death. Iann Barron is quite dismissive of nVidia in the video posted above, but they did make sure to build a sound funding base before they tried high performance computing. They also made sure every device had a good market even if HPC didn't work out. Even if Epiphany has real potential, I don't see how someone like Adapteva can hope to survive through the lean years until they reach decent revenue.

[coppice]

They certainly didn't eliminate the multi-core bottleneck. In the released silicon the communications channels were so crippled it didn't even alleviate the bottlenecks much. Most Transputer designs were limited by comms bandwidth.

They did that in the era when the closest competitor was strictly single core. By reducing the need for inter-core communication they designed around the connectivity bottleneck.

They didn't reduce the inter-core comms much. That was the problem. When they came to implement 4 proper message passing comms ports they found the silicon area needed was substantial. So, they ended up with fairly primitive ports and a lot of software overhead for comms.

Moreover, they proved even then that parallel computing can't be solved in software.

They didn't prove that. It appears to be true, but they didn't prove it. Every successful highly parallel machine to date has use predominantly hardware to make the parallelism work well, from the MPP to an nVidia GPU. That's not a proof of anything, though. I don't know whether Iann Barron was the one to instigate the use of hardware context switching while an Elliott Bros, or whether he picked it up from other people there. Elliott, and later GEC Computers, used a predominately hardware method of context switching until their end days. Although they never had the resources, or perhaps the motivation, to expand that idea into highly parallel machines, the framework was actually there and worked well. Running real time multitasking stuff on their single core machines was very efficient.

[edavid]

Interesting. I wonder if the RISC-V specification is realized with ProjectOberon.

I can assure you that it's not... the Wirthian languages have zero influence or following in the US (for good reason, in my opinion).

[captbill]

Interesting. I wonder if the RISC-V specification is realized with ProjectOberon.

I can assure you that it's not... the Wirthian languages have zero influence or following in the US (for good reason, in my opinion).

I will agree with the 'no following' part but zero influence? The man is the most watched player in all of the programming industry. C++ was created just to keep up with Delphi's success which is built from Pascal.

I'm sorry, but even the looks of this 'RISC-V' spec looks like Oracles' answer to Professor Wirth's RISC5. I think they are very intimidated by 'ProjectOberon', frankly.

I would LOVE to see an honest matchup here. You? Or are you just going to be run around in the maze of never-ending complexity because "everybody is doing it"?

[BloodyCactus]

C++ was created just to keep up with Delphi's success which is built from Pascal.

c++ (1979 at bell labs), (delphi) object pascal (1986 at apple).....

[Kalvin]

C++ was created just to keep up with Delphi's success which is built from Pascal.

c++ (1979 at bell labs), (delphi) object pascal (1986 at apple).....

Both Stroustrup's C++ and Borland Inc.'s Turbo Pascal ($49 USD) appeared first in 1983. At first the C++ compilers were slow, generated poor code, and were expensive compared to Turbo Pascal, thus Turbo Pascal was very popular among the hobbyist. Turbo Pascal was replaced by the Borland Delphi in 1995.

https://en.wikipedia.org/wiki/C%2B%2B
https://en.wikipedia.org/wiki/Turbo_Pascal

[captbill]

http://cs.brown.edu/~adf/programming_languages.html
In the late 1970’s and early 1980’s, a new programing method was being developed. It was known as Object Oriented Programming, or OOP. Objects are pieces of data that can be packaged and manipulated by the programmer. Bjarne Stroustroup liked this method and developed extensions to C known as “C With Classes.” This set of extensions developed into the full-featured language C++, which was released in 1983.

Pardon the imprecise history I stated. I could have swore C++ came later. C++ was actually C's version of OOP Pascal which most certainly was and still is the prime mover in many aspects.

The whole thing to understand is that the 'Wirthian' approach was and still is the one everyone attempts to emulate. Have you guys ever seen Lazarus/FreePascal? It has far excelled even Delphi, and it just keeps getting better and better.

http://www.lazarus-ide.org/

[BloodyCactus]

C++ was created just to keep up with Delphi's success which is built from Pascal.

c++ (1979 at bell labs), (delphi) object pascal (1986 at apple).....

Both Stroustrup's C++ and Borland Inc.'s Turbo Pascal ($49 USD) appeared first in 1983. At first the C++ compilers were slow, generated poor code, and were expensive compared to Turbo Pascal, thus Turbo Pascal was very popular among the hobbyist. Turbo Pascal was replaced by the Borland Delphi in 1995.

https://en.wikipedia.org/wiki/C%2B%2B
https://en.wikipedia.org/wiki/Turbo_Pascal

which is nice and all except captbill specifically said c++ was created to keep up with delphi... only c++ predates delphi (1995) and what delphi is built on (object pascal, 1986) by quite a bit.

being in ram compiler, turbo pascal was interesting, but still pascal and was not yet object pascal.

[eas]

http://cs.brown.edu/~adf/programming_languages.html
In the late 1970’s and early 1980’s, a new programing method was being developed. It was known as Object Oriented Programming, or OOP. Objects are pieces of data that can be packaged and manipulated by the programmer. Bjarne Stroustroup liked this method and developed extensions to C known as “C With Classes.” This set of extensions developed into the full-featured language C++, which was released in 1983.

Pardon the imprecise history I stated. I could have swore C++ came later. C++ was actually C's version of OOP Pascal which most certainly was and still is the prime mover in many aspects.

The whole thing to understand is that the 'Wirthian' approach was and still is the one everyone attempts to emulate. Have you guys ever seen Lazarus/FreePascal? It has far excelled even Delphi, and it just keeps getting better and better.

http://www.lazarus-ide.org/

OOP was broached in the 60's and most of the concepts were really fleshed out with SmallTalk, which started in 1972, though it wasn't made publicly available until 1980.

It's kind of silly to say that wirthian languages don't have much influence in the US when one considers that Pascal was everywhere in the microcomputer world of the late 70s and well into the 80s. The original Macintosh APIs were designed to be called from Pascal. TurboPascal was quite popular on PCs until Microsoft managed to seize more control over the PC software ecosystem with Windows 3. Even then, Delphi was quite popular for Windows development. The creator of the TurboPascal compiler was heavily inspired by Wirth, went on to be the architect of Delphi AND C#.

On the other hand, its probably true that most of Wirth's impact dates from work he did decades before. The same is probably true of Allan Kay (who worked on SmallTalk). I appreciate though that both seem to remain interested in designing modern, full-featured, networked computing environments that are compact, coherent, and understandable. Whether either of their later work ends up being widely adopted, I expect both will have some influence on whatever emerges once Moore's Law runs its course.

[legacy]

I am going to completed my TAP (debug processor)

I can say that it has been designed for pre-pipelined machines (e.g. 68k, 6809)
so, it also works great with multi cycles (the R2K version described in MIPS book)
while it has a LOT of problems with pipelined-cores

in first place, I can't easily do "code injection" 

I am going to try to add my TAP to RISC-V core, in its easiest form
personally I thing its ISA is very well done, and so the HDL code!

[captbill]

I have been looking closer at the RISC-V and I have to say that it is quite obviously, a direct challenger to Professor Wirth's RISC5. In fact it looks to me to be simply a much more complicated version of the brilliantly simple ProjectOberon RISC5 core. One might even say 'hey, this is a fake imposter of the true RISC5, beware!!'.

How about simply have a head to head challenge?

Here is 'Angel' the web based emulator for 'RISC-V'
http://riscv.org/angel/index.html

And here is the Oberon equivalent, that you cannot tell me wasn't where 'Angel' was inspired:
http://schierlm.github.io/OberonEmulator/

So far, for me, all 'Angel' does is appear to load for about 10 seconds and the freeze up, with a note that I need to install Chrome to make it load reasonably fast. Been waiting for over an hour and nothing. I do get a blinking cursor though.

The Oberon emulator opens almost immediately. Definitely less than 1 second. I will admit, getting a "HelloWorld" is tricky because the backspace causes the browser to do a backpage. Were it not for that, it appears to be surprisingly workable.

Now I will go try the RISC-V downloadable emulator for an honest test.

[legacy]

ProjectOberon RISC5 core

I could try to add my TAP to this core, too.
and It will be interesting, as it comes with less complexity.

[legacy]

there is a potential confusion of what RISC-five really means. Roman
five leads us to UC Berkeley project which is well publicised:
http://riscv.org/

Arabic five leads us to Project Oberon, which is much less known.

There is also an interesting discussion that compares the instructions set
of RISC-V and Epiphany:
http://www.adapteva.com/andreas-blog/analyzing-the-risc-v-instruction-set-architecture/

It seems to me that Epiphany is closer in spirit to N.Wirth thinking than
RISC-V, at least based on the fact that Epiphany's instruction set is
leaner than RISC-V.

Looking at the Adapteva/Parallella project it is a pity that each one of
these many cores of the Parallella board is not running Oberon System
modules. What an interesting project it would have been.

Another (crazy?) idea is to write the Epiphany processor core in VHDL
(avoid verilog, please!) and build a small Epiphany cluster within Zynq
Programmable Logic fabric. Ditto with RISC5. Then compare. These two
architectures must be pretty similar.

An emulated 16-core Epiphany would probably fit within Spartan6-LX150
which has 536 kB BRAM on chip, while 16-core Epiphany has 512 kB (32 kB
per core). One can probably build such a mesh with 16 kB blocks per core.

All these thought knocked to my mind when I was studying the
Adapteva/Parallella website materials for our next project. These papers
were very inspiring to me. Playing with FPGAs along these lines would be
pretty interesting.

found while I was googling

[captbill]

there is a potential confusion of what RISC-five really means. Roman
five leads us to UC Berkeley project which is well publicised:
http://riscv.org/

Arabic five leads us to Project Oberon, which is much less known.

There is also an interesting discussion that compares the instructions set
of RISC-V and Epiphany:
http://www.adapteva.com/andreas-blog/analyzing-the-risc-v-instruction-set-architecture/

It seems to me that Epiphany is closer in spirit to N.Wirth thinking than
RISC-V, at least based on the fact that Epiphany's instruction set is
leaner than RISC-V.

Looking at the Adapteva/Parallella project it is a pity that each one of
these many cores of the Parallella board is not running Oberon System
modules. What an interesting project it would have been.

Another (crazy?) idea is to write the Epiphany processor core in VHDL
(avoid verilog, please!) and build a small Epiphany cluster within Zynq
Programmable Logic fabric. Ditto with RISC5. Then compare. These two
architectures must be pretty similar.

An emulated 16-core Epiphany would probably fit within Spartan6-LX150
which has 536 kB BRAM on chip, while 16-core Epiphany has 512 kB (32 kB
per core). One can probably build such a mesh with 16 kB blocks per core.

All these thought knocked to my mind when I was studying the
Adapteva/Parallella website materials for our next project. These papers
were very inspiring to me. Playing with FPGAs along these lines would be
pretty interesting.

found while I was googling

Very interesting. What is the link to the original or what search term will get me there?

I think it is most important to carefully note this statement:

Looking at the Adapteva/Parallella project it is a pity that each one of
these many cores of the Parallella board is not running Oberon System
modules. What an interesting project it would have been.

He is apparently making a positive reference to "Oberon the language" which is truly a step forward in the programming language realm. We have only discussed the RISC5, the "core", up until now. It is Oberon the language you will really come to appreciate, as the author seems here to be pointing out. Pay close attention to that right there.

I assume by 'Oberon System Modules' he means the 'core' with the 'Oberon OS modules'. He could actually be referencing the 'Oberon Verilog Modules'.

[legacy]

what is the link to the original or what search term will get me there?

here it is

[legacy]

and here it is a little topic about Oberon on Papilio/pro

[westfw]

(heh.   In the commercial world, you get your core and/or chip using it "good enough", ship it, and compete with other vendors' decisions in the marketplace, where factors other than elegance and architectural excellence come into play (support, availability, salesmanship, price, bundling, tools, community, and more.) (We can all come up with examples of extremely popular products that do not seem to reflect the best core design choices...)  In academia, the personalities are no less intense, the competition no less fierce, but those "other factors" have a lot less weight; dueling papers and a grab for the most grad students, or something.)

(I took part of a Smalltalk class back about 1985, when I was working at Stanford.   I was quite negatively impressed with just how slow they managed to make a maxed-out (for the time) SUN workstation run.   OTOH, given how fast Moore's law pushed performance, maybe they were right to not care...)

[legacy]

when I was working at Stanford

lucky you are, I envy you 

[captbill]

what is the link to the original or what search term will get me there?

here it is

That is hilarious. The first link is 'Wojtek' in a discussion at the Oberon mailing list a everyone (including me) was searching for a compatible FPGA board for ProjectOberon. There were no FPGA development boards that had suitable ram setup. We were all knocking around ideas then.

The second link is ME (look at the OP's name), over at the Papilio forum begging for someone to try to fit it on the Papilio. That is the very thread that tipped off Magnus at Saalima about ProjectOberon. He obviously 'saw the light' and less than a week later he had Oberon running on the Pipistrello.

A small world indeed. haha

[HAL-42b]

Ok, what exactly is the light?

I have no experience with Oberon. It is obviously small and simple, which is nice but what exactly is setting it apart?

I watched one of Wirth's lectures start to end but it was rather autobiographical and didn't go into detail. I probably watched the wrong thing. Is there anything where the architecture is explained?

[captbill]

Ok, what exactly is the light?

I have no experience with Oberon. It is obviously small and simple, which is nice but what exactly is setting it apart?

I watched one of Wirth's lectures start to end but it was rather autobiographical and didn't go into detail. I probably watched the wrong thing. Is there anything where the architecture is explained?

It is all very nicely document to a very high degree. Everything is spelled out in the PDF's listed at ProjectOberon.com. Everything you need is on this one page.

Lot's of other exciting gems to be found at Professor Wirth's personal homepage. It's a goldmine, I tell ya:
https://www.inf.ethz.ch/personal/wirth/

How about comparing the 'official spec sheets' of both RISC5 and RISC-V:
RISC-V:
http://riscv.org/download.html#tab_spec_user_isa

RISC5:
https://www.inf.ethz.ch/personal/wirth/FPGA-relatedWork/RISC-Arch.pdf

[HAL-42b]

Seems like the utter simplicity itself, I love it!

Definitely the best core for learning VHDL and processors.

[JoeN]

"32-bit, 64-bit, and 128-bit address space variants for applications, operating system kernels, and hardware implementations."

128 bit address space?  What is this good for?  64 bit is 16 EiB.  Are we pushing this for any computer system?  Tianhe-2 apparently has 1,375 TiB of memory or 1.375 PiB.  So the world's largest supercomputer is using less than 1/10,000th of the 64-bit address space so far.  I guess it might be useful sometime in the semi-near future.  When do you think the first computer with 16 EiB of memory will become sentient operational?

https://en.wikipedia.org/wiki/Tianhe-2

[HAL-42b]

"32-bit, 64-bit, and 128-bit address space variants for applications, operating system kernels, and hardware implementations."

128 bit address space?  What is this good for?  64 bit is 16 EiB.  Are we pushing this for any computer system?  Tianhe-2 apparently has 1,375 TiB of memory or 1.375 PiB.  So the world's largest supercomputer is using less than 1/10,000th of the 64-bit address space so far.  I guess it might be useful sometime in the semi-near future.  When do you think the first computer with 16 EiB of memory will become sentient operational?

https://en.wikipedia.org/wiki/Tianhe-2

Not much use if you think in terms of a normal Von Neumann machine. Extremely useful if your memory consists of many physically separate chunks which you may want to share or isolate according to some criteria.

Extremely useful for security in multi-processor systems.

For example if you want cores A B C D to be able to read from a chunk of memory but only cores D E to be able to write to it. Wide address space lets you manage this in a single instruction, moreover it lets you to verify its security in hardware, regardless of the code running.

In a sense it lets you program with your soldering iron, which I like, a lot. 

[C]

"32-bit, 64-bit, and 128-bit address space variants for applications, operating system kernels, and hardware implementations."

128 bit address space?  What is this good for?  64 bit is 16 EiB.  Are we pushing this for any computer system?  Tianhe-2 apparently has 1,375 TiB of memory or 1.375 PiB.  So the world's largest supercomputer is using less than 1/10,000th of the 64-bit address space so far.  I guess it might be useful sometime in the semi-near future.  When do you think the first computer with 16 EiB of memory will become sentient operational?

https://en.wikipedia.org/wiki/Tianhe-2

How about simple hardware reducing software load.
Storage directly mapped to memory space.
the simple memory management hardware would know if a write back was needed.

[JoeN]

How about simple hardware reducing software load.
Storage directly mapped to memory space.
the simple memory management hardware would know if a write back was needed.

128 lines just to put an address on the bus.
Commensurate decoding logic for every memory mapped device.
etc.

[ale500]

64 bit Processors today don't use 64 bit physical addresses anyways, they have like 42 or 48. It is an extensible ISA, they prepared it for growth, if tomorrow there is a new way of cpu in terms of quantum something of trinary systems or whatever, it may remain unused. But at the current rate, maybe in 10 years are 128 bit systems a real possibility

The RISC5 verilog shows a very compact and simple design of a 1 cycle CPU. Very nicely done . With the same concepts I designed a RISCV core, it mostly works

There is for instance a Cyclone IV board on ebay with external SDRAM for like 40 €, that is a nice target for the Oberon system, it needs a SDRAM controller but that is not that difficult... too many projects...

I tried the simulator and I find it just great. The kind of fun that where home computers some time ago, no windows, no drivers, no updates every other day...

[captbill]

ProjectOberon RISC5 core

I could try to add my TAP to this core, too.
and It will be interesting, as it comes with less complexity.

A TAP interface. I had to look that one up. "Test Anything Protocol" you mean? Sounds very interesting. So you have some 'TAP interface routines' you could apply to the RISC5, which sets up 'taps' for probing signals via JTAG? I have no clue how to go about 'tapping' the actual core but will gladly test anything like that on my setup. One question: does all this happen over USB or would you be physically probing some pin with a logic analyser?

[helius]

A TAP is a Test Access Port, for monitoring the internal memories of the CPU. It is needed for detailed testing and instrumentation of the CPU, for instance to capture or replay pipeline stalls, hazards, and exceptions. The interface from it to the debug host can be anything, but a serial protocol like SWD or JTAG would be a usual choice; USB would be absurd.
IEEE 1149.1 JTAG only has access to I/O pins; to implement real emulators and trace tools you must have a logic block with special access to internal data and control paths.

[legacy]

A TAP is a Test Access Port, for monitoring the internal memories of the CPU. It is needed for detailed testing and instrumentation of the CPU, for instance to capture or replay pipeline stalls, hazards, and exceptions. The interface from it to the debug host can be anything, but a serial protocol like SWD or JTAG would be a usual choice; USB would be absurd.
IEEE 1149.1 JTAG only has access to I/O pins; to implement real emulators and trace tools you must have a logic block with special access to internal data and control paths.

all of the above, but my TAP is not jtag driven, it implements a custom protocol which does not look like SWD
I am developing for hobby, tempted to put it on business, may be

[legacy]

There is for instance a Cyclone IV board on ebay with external SDRAM for like 40 €, that is a nice target for the Oberon system, it needs a SDRAM controller but that is not that difficult

while the Oberon mini FPGA board costs up to 150 USD 

[legacy]

so, they are both pronounced "risk-five", even if Risc-5 is Oberon, while Risc-V is Berkeley, and they are two different projects with little things in common

this Xcell article talks about Oberon System implemented on a low cost fpga, with a little review of the whole.

[captbill]

64 bit Processors today don't use 64 bit physical addresses anyways, they have like 42 or 48. It is an extensible ISA, they prepared it for growth, if tomorrow there is a new way of cpu in terms of quantum something of trinary systems or whatever, it may remain unused. But at the current rate, maybe in 10 years are 128 bit systems a real possibility

The RISC5 verilog shows a very compact and simple design of a 1 cycle CPU. Very nicely done . With the same concepts I designed a RISCV core, it mostly works

There is for instance a Cyclone IV board on ebay with external SDRAM for like 40 €, that is a nice target for the Oberon system, it needs a SDRAM controller but that is not that difficult... too many projects...

I tried the simulator and I find it just great. The kind of fun that where home computers some time ago, no windows, no drivers, no updates every other day...

How about this:
Just like the ProjectOberon emulator, there is a Macintosh Plus core + emulator up and running on the Pipistrello/Pepino.

You have to see this Mac+ emulator...awesome. In fact, I don't remember being able to load and run an 'emulator' of any sort without lot's of setup hassles, do you? These you just download and run like any other 'application'. I haven't yet flashed this to the Pipistrello, on the 'real hardware' mainly because the emulator is just so awesome.

http://saanlima.com/store/index.php?route=module/blog/view&blog_id=9

I literally have only played around with this core and managed to find and install ThinkPascal, which to this day has the neatest debug facility I have ever seen. I even found a full TCP stack written in ThinkPascal!...which I am very tempted to hook up to my new fangled ESP8266 'transparent UART' I just managed to get running with this thing.

This is probably a fun project for one of you Mac enthusiasts out there. I will be glad to assist where I can. Of coarse, to be fair and legal, the way to go about it is to find an old MacPlus on Ebay and build an awesome supercharged Mac+.

I think the <$200 price point is a great bargain when you consider all you are getting here. You want your FPGA development system to be oversized and not undersized. You can design small projects on oversized boards but you cannot build a big project if you have an undersized FPGA.

**BEEP ALERT lower your volume**
https://youtu.be/GM59aJmsZ4g

[C]

One thing I noticed on the very quick read of the risc-V

The section where they state it is a little endian machine and ethernet is big endian.

If you want to talk to something other then more risc-V you need to match.
If it does not match then you have to spend more instructions to make it match.

If you have a data structure then you are adding the convert to and convert from this data structure functions.
Extra programming that could be slow as it is not the normal way the CPU would access the data.

If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

[edavid]

One thing I noticed on the very quick read of the risc-V

The section where they state it is a little endian machine and ethernet is big endian.

If you want to talk to something other then more risc-V you need to match.
If it does not match then you have to spend more instructions to make it match.

If you have a data structure then you are adding the convert to and convert from this data structure functions.
Extra programming that could be slow as it is not the normal way the CPU would access the data.

If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

Yes, this is why we don't connect our X86 and ARM based computers to Ethernet 

[C]

One thing I noticed on the very quick read of the risc-V

The section where they state it is a little endian machine and ethernet is big endian.

If you want to talk to something other then more risc-V you need to match.
If it does not match then you have to spend more instructions to make it match.

If you have a data structure then you are adding the convert to and convert from this data structure functions.
Extra programming that could be slow as it is not the normal way the CPU would access the data.

If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

Yes, this is why we don't connect our X86 and ARM based computers to Ethernet 

Just wanted to quote something and respond and skip the read the whole thing part.
Slower, more problems and more software does not prevent!
Just burns up a bunch of computer time.

[helius]

There are many different endian conventions used in I/O devices. When comparing CPU architectures, the main difference is the byte order between big-endian (e.g. Motorola) and little-endian (e.g. Intel) architectures. With I/O, it's the order of bits that matters, which is independent of the CPU's byte order. For example, serial links such as RS-232 are LSB first, and Ethernet is MSB first. The conversion takes place in the I/O hardware, takes no time at all, and is very rarely of concern to software.
A different issue yet again are interchange formats, that are defined so that data will have a consistent format regardless of the hardware used. Most Internet protocols are defined with big-endian numbers and macros like htons() are used to maintain this ordering. Some formats like ISO9660 CDROMs or DVDs consistently store two copies of numbers, one big-endian and the other little-endian. This is an issue for all computers and there is no way to avoid it by choosing the "right" byte order in hardware. If you have a byte-swap instruction it is very fast to do the conversion though.

[westfw]

The section where they state it is a little endian machine and ethernet is big endian.
If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

Almost all of today's processors are little endian.   Most of them have some sort of byteswap instruction, so if you do things right, you end up adding a nanosecond or so to each 20+ns memory read or write.  Hardly deadly.  A near-SOTA intel processor with the Intel bi-endian compiler, with EVERYTHING in memory byteswapped, still out-performs a near-SOTA big-endian CPU.  Been there, did the tests, shipped the product...

[coppice]

One thing I noticed on the very quick read of the risc-V

The section where they state it is a little endian machine and ethernet is big endian.

If you want to talk to something other then more risc-V you need to match.
If it does not match then you have to spend more instructions to make it match.

If you have a data structure then you are adding the convert to and convert from this data structure functions.
Extra programming that could be slow as it is not the normal way the CPU would access the data.

If you are building a computer that reads and writes most of it's IO via Ethernet would be a bad choice to pick a CPU where this took more time.

Most machines are little endian these days, but swapping bytes around can be done quickly on most machines. Its often just a single instruction. What really hurts performance when building or dissecting message buffers is the inability to perform misaligned reads and writes. If you have to chop up words to pack them into a transmit buffer things get really slow. On machines which support misaligned reads and writes they are usually a bit slower than aligned ones. However, its much much faster than chopping things up and manipulating them in software.

[legacy]

On machines which support misaligned reads and writes they are usually a bit slower than aligned ones

MIPS can have misaligned-load/store instructions

why slower ? do you mean because it implies two sub-cycles, so the pipeline needs to be stalled twice ?

[helius]

Memory is always several times slower than instructions, so all software realignment does is increase code size. If you understand what you're doing you don't define unaligned data fields in the first place.
Misaligned load/store is difficult to implement correctly across cache-line and page boundaries. In the case of MIPS, several silicon errata were caused by this (mis)feature.

[coppice]

Memory is always several times slower than instructions, so all software realignment does is increase code size. If you understand what you're doing you don't define unaligned data fields in the first place.
Misaligned load/store is difficult to implement correctly across cache-line and page boundaries. In the case of MIPS, several silicon errata were caused by this (mis)feature.

When you are dealing with comms protocols you rarely get to choose whether things are aligned.

[C]

Memory is always several times slower than instructions, so all software realignment does is increase code size.

Suggests that inside processor should be risc to keep small CPU while in memory should be CSC to lower memory use.

[edavid]

Misaligned load/store is difficult to implement correctly across cache-line and page boundaries. In the case of MIPS, several silicon errata were caused by this (mis)feature.

That's odd, since MIPS doesn't have misaligned load/store (it uses LWL/LWR/SWL/SWR instead).

[legacy]

in MIPS, lwl/lwr and swl/swr are for accessing unaligned words in memory.
The actual specification is complicated, but what it boils down to is that

lwl RT, offset(RS)
lwr RT, (offset+3)(RS)

loads the 32-bit value starting at RS+offset, no matter what the alignment of that address is. swl/swr behave analogously.

RFE rotates the lower six bits of the status register by two to the right, so the "previous" interrupt/usermode state becomes the current state and the "old" state is copied into the "previous" state. This inverts what happens on an exception. RFE is normally found in the delay slot of a jump instruction of some kind.

[justanothercanuck]

i haven't seen a RISC (besides ARM) since PA-RISC...  that horse should have stayed dead. 

[legacy]

emmm, don't forget to mention the MIPS horse in your router

[brucehoult]

I can't say I'm impressed with the instruction set, but it is actually a real working core, not like one of a few thousands MIPS clones made by students and beginner FPGA designers.

Sorry to reply to such an old topic, but we're all just getting hardware now :-)  Has your HiFive1 arrived yet?

What is it you're not impressed about with the instruction set?

I think the design is very elegant and even with the gcc somewhat immature comparisons of compiled C code with other ISAs show RISC-V to be very competitive with x86, x86_64, ARM, Aarch64 on things like number of instructions needing to be executed (especially if you count uOps for x86, not instructions), code size etc.

There are some fairly obvious things missing from the base instruction set that help some specialised tasks: popcount, count-leading-zeros, bitfield extraction and insertion. There isn't even a rotate instruction :-) It does pretty well even without those, but a "B" standard extension is being designed right now.  Even Intel only introduced many of those fairly recently in x86 history e.g. popcount in Nehalem and clz in Haswell!

[ataradov]

Sorry to reply to such an old topic, but we're all just getting hardware now :-)  Has your HiFive1 arrived yet?

Got a tracking number today. Should be here in a few days.

What is it you're not impressed about with the instruction set?

It is a typical RISC. It is good for simplicity, but not really for performance. Fewer of short, but more capable instructions means better cache utilization. It does not matter how many cycles (uOps) it takes to execute a complex CISC instruction, getting it to the core is the slowest process in reality.

There are some fairly obvious things missing from the base instruction set that help some specialised tasks

Exactly.

[brucehoult]

Memory is always several times slower than instructions, so all software realignment does is increase code size.

Suggests that inside processor should be risc to keep small CPU while in memory should be CSC to lower memory use.

Except that it turns out that the smallest code (from existing, real compilers at least) is for RISC ISAs with 16 bit instructions or even better a mix of 16 and 32 like Thumb2 and RISC-V. Compiler-generated i386 code is pretty bloated, and x86_64 adds an extra REX byte to a large percentage of instructions. VAX code wasn't all that compact either.

Some purists will say "It's not real RISC unless there is only one length of instruction". Pragmatically, two instruction lengths is a heck of a lot better than "anything you like, from 1 to 15 bytes -- and you have to decode almost all the bytes before you even know how long the instruction actually is". On Thumb2 you can tell the instruction length from the first 4 bits, and on RISC-V from the first 2 bits.

Interestingly, this is something IBM got right 50 years ago with the IBM 360. Instructions could be 2, 4, or 6 bytes long and you could tell the length from the first two bits. Something else they got right was that each instruction has at most one operand in memory (one of the few redeeming features of x86).

[ataradov]

On Thumb2 you can tell the instruction length from the first 4 bits, and on RISC-V from the first 2 bits.

Does not make much of a difference. You are thinking how hard it is to make a decoder, not how fast the resulting decoder is. Most X86 instructions are decoded via combinatorial logic, it is just much more complicated, but it does not matter all that much. Well, except for parameters that have noting to do with computational performance, like power consumption and die area.

The fact is, today X86 has the best performance of all available architectures. It is not just ISA, it is a general architecture of the system. X86 is incredibly complicated, that's why all home brew cores are RISC, something average person can actually comprehend.

AArch64 may get somewhat close, especially considering much better power consumption and lower price, but that's in the future.

[brucehoult]

It is a typical RISC. It is good for simplicity, but not really for performance. Fewer of short, but more capable instructions means better cache utilization. It does not matter how many cycles (uOps) it takes to execute a complex CISC instruction, getting it to the core is the slowest process in reality.

I agree that program size and making best use of L1 instruction cache and fetch(&decode) bandwidth is one of the most important things. Not only for speed but especially for power usage.

The Berkeley guys have shown that across SPECINT by far the smallest code sizes for 32 bit ISAs are Thumb2 and RISC-V, while for 64 bit RISC-V stands alone as it's the only one with 16 bit instructions available.

Thumb2 is a couple of percent smaller because of PUSH/POP multiple at function entry/return. Interestingly, that's been deprecated even in 32 bit mode in ARMv8 and new code is encouraged to use load/store pair and compilers already do so if you specify -march=armv8.

RISC-V has a trick to replace PUSH/POP multiple when code size is the most important thing: using a non-standard link register (e.g. t0) to call special subroutines to push or pop a set of registers. If you don't insist on a complete set but just, say, a choice between ra&s0 or ra&s0-s1 or ra&s0-s2 or ra&s0-s6 or ra&s0-s11 (i.e. 2, 3, 4, 8, or 13 registers) then it's a total of less than 200 bytes of library code.

riscv-gcc already has an experimental flag to do this -msave-restore and later it will probably migrate to being standard for -Os or -Oz

Did you see my little counting primes benchmark I've tried on the HiFive1 and a bunch of other things? The RISC-V code turned out to be by far the smallest, 10% less even than Thumb2. The ARM code uses push/pop multiple to free up enough registers, but because it has 32 registers including 15 volatile registers (8 argument plus 7 temp) RISC-V turned out not to need to save/restore anything at all.

https://www.eevblog.com/forum/crowd-funded-projects/raspberry-pi-zero-82789/msg1131652/#msg1131652

[ataradov]

Interestingly, that's been deprecated even in 32 bit mode in ARMv8 and new code is encouraged to use load/store pair and compilers already do so if you specify -march=armv8.

That's because there are lots of problem with them, especially with bus time scheduling and interrupts with the need to either increase interrupt latency or implement abandoning.

RISC-V has a trick to replace PUSH/POP multiple when code size is the most important thing

AVR-GCC did this from the beginning with -mcall-prologues.

The RISC-V code turned out to be by far the smallest

I'm not sure if I'm interested in code size anymore. Flash is reasonably cheap, and in reality, price difference between different flash size MCUs is not that huge (for adjacent memory sizes that is). QSPI flash is even cheaper and can be as fast as embedded flash. I'd rather see manufacturers move in that direction.

[brucehoult]

The fact is, today X86 has the best performance of all available architectures. It is not just ISA, it is a general architecture of the system. X86 is incredibly complicated, that's why all home brew cores are RISC, something average person can actually comprehend.

AArch64 may get somewhat close, especially considering much better power consumption and lower price, but that's in the future.

Not too much in the future. Apple's A10 in the iPhone 7 is faster than the x86s that have been in MacBook Airs. The A9x in the iPad Pro is thereabouts too.

Not that hobbyists have access to those. The Odroid XU4 is the fastest cheapish ARM SBC I know of, with a 2 GHz quad A15. It turns out that (at least on that one benchmark I just gave a link to) RISC-V on qemu on an i7 is slightly faster!

Turns out riscv-qemu is around 2.5 times faster than arm-qemu or aarch-qemu. I think that's mostly because there is no need to emulate condition codes, and the translation of RISC-V's "compare and branch" instruction "cmp rx,ry;bxx" is fused into a single uOP on recent x86s.

[ataradov]

Not too much in the future. Apple's A10 in the iPhone 7 is faster than the x86s that have been in MacBook Airs. The A9x in the iPad Pro is thereabouts too.

I'll believe it, when I see desktop machines running on ARM and not being painfully slow, like some ARM-based Chromebooks.

[brucehoult]

I'm not sure if I'm interested in code size anymore. Flash is reasonably cheap

Then I don't understand what you meant a few minutes ago when you wrote "Fewer of short, but more capable instructions means better cache utilization. It does not matter how many cycles (uOps) it takes to execute a complex CISC instruction, getting it to the core is the slowest process in reality."

Small code size makes better use of cache and fetch bandwidth, both among the most power hungry things, which is important in both battery powered embedded and in racks of servers with thousands of cores. The only place it doesn't matter now is laptops and desktops :-)

[ataradov]

Small code size makes better use of cache and fetch bandwidth

That jump to the register load/store place incurs slow jump instruction and additional cache fetches for that load/store code. I don't really care if each function has all of its register saves/restores explicitly listed.

[brucehoult]

Small code size makes better use of cache and fetch bandwidth

That jump to the register load/store place incurs slow jump instruction and additional cache fetches for that load/store code. I don't really care if each function has all of its register saves/restores explicitly listed.

That's correct of course.

But the call/return are only 1 cycle each (thanks to BTB and return address stack -- even on HiFive1) and the code will be shared by so many functions that it probably stays in cache. With even 16 KB of L1 it should even reduce cache pressure overall -- that only requires each prologue/epilog routine to be used from two functions (especially if one of the larger ones is).

But if you don't want to pay that then fine, put your save&restore code inline. You'll still only be a couple of percent bigger than Thumb2 and smaller than anything else (much smaller on a 64 bit system).

[hamster_nz]

. Something else they got right was that each instruction has at most one operand in memory (one of the few redeeming features of x86).

Not wanting to be pedantic, but from my youth I remember  MOVS/MOVSB/MOVSW/MOVSD

Move byte/word/dword from DS:[(E)SI] to ES:[(E)DI]

http://www.fermimn.gov.it/linux/quarta/x86/movs.htm

PS. My HiFive1 is everything that was promised - everything I tried worked. So it is now living on the shelf looking for a project. About the only thing that surprised me was I/O was a little bit slower than I am used to with a uC - 9 or so cycles per register access.

[legacy]

Sorry to reply to such an old topic

no problem, glad to see new posts 

but we're all just getting hardware now :-)  Has your HiFive1 arrived yet?

which hw are you talking about? Here I am on fpga

[brucehoult]

. Something else they got right was that each instruction has at most one operand in memory (one of the few redeeming features of x86).

Not wanting to be pedantic, but from my youth I remember  MOVS/MOVSB/MOVSW/MOVSD

Move byte/word/dword from DS:[(E)SI] to ES:[(E)DI]

Yes, I'm aware of that :-)  That's one of the big warts on x86 and at various times has run a lot lot slower than writing a loop or unrolled code yourself. *Especially* as you may have had to load one or both of DS and ES beforehand, and that's been a major cycle suck, depending on which CPU.

You could do a segment override to make it copy both from and to ES, but that turns out to have had a major problem early on .. see "Chapter 27, In Which It Blows Up In My Face" here: https://trixter.oldskool.org/2013/01/18/optimizing-for-the-8088-and-8086-cpu-part-3-a-case-study-in-speed/

Note that normal x86 instructions have one register operand and one register/memory operand. They might both read and write the memory operand, but they only have to calculate and check the address for segfault/pagefault etc once. That's important.

PS. My HiFive1 is everything that was promised - everything I tried worked. So it is now living on the shelf looking for a project. About the only thing that surprised me was I/O was a little bit slower than I am used to with a uC - 9 or so cycles per register access.

Yes, but 9 cycles isn't very long at 320 MHz :-)

All my Arduino bits and pieces are back in NZ. I just took delivery a couple of days ago of a little kit of parts http://onpad.ru/shop/cubie/arduino/ardiuno_kit2/1852.html

I've put the 4 digit 7 segment display on the breadboard and run all 12 pins from the display to digital I/Opins (7 segments plus dot, 4 for digit select) and made a little minutes:seconds countdown timer. There's one 595 shift register there, so in the weekend I'm going to change it to use that for the segment/dot select. I'm trying to find out where I can get some more 595's by themselves.

I'm actually a bit worried that the "shiftOut()" arduino function might be a bit too fast for the 595 if the RISC-V is running with a fast clock! After setting the data line it just does digitalWrite(clockPin, LOW); digitalWrite(clockPin, HIGH) with no delay between. The 595 should accept about 20 Mhz with  5V power, but at 2 V it's only spec'd for 5 Mhz. 3.3 will be somewhere between.

Anyway, I'll see.

[brucehoult]

[which hw are you talking about? Here I am on fpga

This hardware: https://www.crowdsupply.com/sifive/hifive1

Seems hamster_nz and I have ours, ataradov should have very soon.

I'm thinking of getting an Arty to play with as well. Looks like a good way to learn FPGA things, whether you load the HiFive1 bitfile into it (or modify it), or use their MicroBlaze one, or just play with something else entirely. I see there are small bare FPGA chips under $10, but $99 seems not bad for one with 20k LUTs and LEDs and switches and ethernet and USB and 256 MB RAM and Arduino connectors.

[brucehoult]

This evening I made a quick hack trying to do D/A just by calling good old digitalWrite(pin, bool) from software once every microsecond. I don't seem to have the filtering quite right, but it's much better with it than without it.




(The "Challenge accepted" bit is about this https://twitter.com/DavidGrubb18/status/829711362016342017)

[ataradov]

This is awesome. My board arrives on Monday. Unfortunately, on Tuesday I'm leaving for a business trip

[ataradov]

Got my board today. USPS rocks.

Compiling the toolchain right now. Their build system seems to be a bit wanky and it looks like it rebuilds absolutely everything from scratch after a failure. EDIT: It appears that it does not actually rebuild everything, which is good.

I can't find any links to precompiled toolchains either. They really need to step up their game if they want this to go anywhere.

[brucehoult]

Got my board today. USPS rocks.

Compiling the toolchain right now. Their build system seems to be a bit wanky and it looks like it rebuilds absolutely everything from scratch after a failure. EDIT: It appears that it does not actually rebuild everything, which is good.

I can't find any links to precompiled toolchains either. They really need to step up their game if they want this to go anywhere.

If you want everything pre-compiled and hand-held all you have to do is open preferences in your Arduino IDE and enter "http://static.dev.sifive.com/bsp/arduino/package_sifive_index.json" into "Additional Boards Manager URLs". Can't get much easier than that!

If you want to use them from the command line you'll then find the build stuff in ...

~/.arduino15/packages/sifive/tools/riscv32-unknown-elf-gcc/3f7b3696217548bc31aeccf9a0c89bdfa4e16a8f/bin

... and openocd in ...

~/.arduino15/packages/sifive/tools/openocd/9bab0782d313679bb0bfb634e6e87c757b8d5503/bin

... so you can just add those to PATH.

Personally, I don't begrudge the 4m53s it takes (I just checked) for "make -j8 tools"  and I keep several different variations sitting around for comparison e.g. with and without using 16 bit "C" instructions.

It takes nearly as long just to upload the "Killer Queen" player app (4 MB) to the board!

[ataradov]

Personally, I don't begrudge the 4m53s it takes (I just checked) for "make -j8 tools"  and I keep several different variations sitting around for comparison e.g. with and without using 16 bit "C" instructions.

Yeah, but if they want this thing to go anywhere, they need to provide prebuilt tools. A lot of ARM success can be attributed to standardization efforts with CMSIS (at least for header files) and excellent support for GCC builds.

I've been playing with this thing since I've got it, and boy, it brings me back to mid 90s. Assembly startup, no vectored interrupts, register bits are not defined, documentation is all over the place.

I'm working on creating a simple minimal example in the spirit of my starter projects - https://github.com/ataradov/mcu-starter-projects

And the next step must be creation of SVD file, I'm not about to type a lot of magic offsets.

Also, its internal RC is all over the place. I understand that RC oscillators are not the most accurate thing ever, but +/- 50%, really?

Also, PLL seems to be pretty random as well, but I have not checked what is used for the reference there.

[ataradov]

Right now I'm struggling to find any sort of description for MCAUSE and specifically CAUSE field.

It looks like some (?) of the values are listed in encoding.h, but clearly not all. How do I configure UART interrupt? Found interrupts, but got even more confused

[brucehoult]

Personally, I don't begrudge the 4m53s it takes (I just checked) for "make -j8 tools"  and I keep several different variations sitting around for comparison e.g. with and without using 16 bit "C" instructions.

Yeah, but if they want this thing to go anywhere, they need to provide prebuilt tools. A lot of ARM success can be attributed to standardization efforts with CMSIS (at least for header files) and excellent support for GCC builds.

I've been playing with this thing since I've got it, and boy, it brings me back to mid 90s. Assembly startup, no vectored interrupts, register bits are not defined, documentation is all over the place.

The hardware is deliberately minimal. Their complaint against ARM etc is it's become too complex, big, power hungry. Software can vector interrupts very nearly as quickly as hardware can and ROM is cheaper. It's nice to be able to just poke a pointer to a C function into a vector as on Cortex M, but hardware sequencing to save registers takes extra hardware and may well save more than you need.

I'm frustrated by the lack of documentation as well. I'm figuring most things out by finding the Arduino library implementation and then stripping out the unneeded stuff. Next I want to find how to work proper hardware PWM manually so I can convert my silly little music player to use PWM instead of software bit-banging. Should improve the quality a lot, plus one of the problems with my 1 MHz toggling a pin is reading the next byte of music sample from flash takes 3 uS!

To be precise, at 256 MHz (includes timing overhead):

int8:   791 clocks = 3.09 us
int16:  935 clocks = 3.65 us
int32: 1223 clocks = 4.78 us

A consistent exactly 144 clocks (0.5625 us) per extra byte.

I think they're being conservative with the clock for the SPI and it could be faster.

I'm giving them a pass on documentation for now.  They're about 10 people and mostly rushing to get hardware (including Pi class) out.

I'll take working example code over wrong documentation ANY day!

I'm working on creating a simple minimal example in the spirit of my starter projects - https://github.com/ataradov/mcu-starter-projects

I'll check it out.

And the next step must be creation of SVD file, I'm not about to type a lot of magic offsets.

The is considerable discussion at the moment in the whole RISC-V community over the best format. Device tree? Config string? They definitely intend to have it standardised across boards in such a way that bootloaders/kernels will Just Work on different hardware without configuration.

https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/z6Lc8D9IuIg/0GQtIpPEDgAJ
https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/DS4v8slQm8Q/oMlA8QqaAAAJ
https://groups.google.com/a/groups.riscv.org/d/msg/isa-dev/dd7jC_zVOXE/MPjOhH22AgAJ

etc

Also, its internal RC is all over the place. I understand that RC oscillators are not the most accurate thing ever, but +/- 50%, really?

Also, PLL seems to be pretty random as well, but I have not checked what is used for the reference there.

The speed reported to the UART at program start is all over the place. It's done with what looks like a fairly quick&dirty loop measuring it. I suspect the actual MHz is more stable than the reporting of it :-)

[ataradov]

The hardware is deliberately minimal.

Nope, it is minimal because they could not make more complicated stuff.  There is no market for this this as it stands right now. It is a good first step, but they have a long way to go.

Software can vector interrupts very nearly as quickly as hardware can and ROM is cheaper.

I actually support customers using ARM products, and one if the most common complaints / misunderstandings is how long interrupts entry/exit takes. And in this case I see trap_entry that does 32 stores and 32 restores. This is not going to fly in a real world. All that talk that software can vector interrupts fast is just not gonna do it, they will have to figure out how to make vectored IC.

The is considerable discussion at the moment in the whole RISC-V community over the best format. Device tree? Config string?

Just use SVD. I know NIH syndrome won't let them, but SVD is a good format that is understood by all industry tools.

The speed reported to the UART at program start is all over the place. It's done with what looks like a fairly quick&dirty loop measuring it. I suspect the actual MHz is more stable than the reporting of it :-)

Possibly. I'm trying to get rid of assembly stuff for now.

[brucehoult]

I actually support customers using ARM products, and one if the most common complaints / misunderstandings is how long interrupts entry/exit takes. And in this case I see trap_entry that does 32 stores and 32 restores. This is not going to fly in a real world. All that talk that software can vector interrupts fast is just not gonna do it, they will have to figure out how to make vectored IC.

I recently did a kernel patch for Aarch64 linux. I wanted to make, effectively, a custom instruction implemented by trapping.

I was shocked to find that all synchronous traps (SWI, segfault etc etc) have a single handler and it does a 32 register save before doing anything at all to figure out the cause or dispatch on it.

I implemented my patch (which is for internal use, not upstreaming) before the register saving. I only needed two registers, grab the cause, decide if it's for me and branch to my own handler (which did its stuff and interrupt return in less than 10 instructions), otherwise fall through to the normal full register save and dispatch.

So don't tell me ARM is different or better :-)

If you want a trap handler that doesn't save all 31 registers every time you have the source and can change it to do whatever you want. Meantime, it works and is safe.

I think they pretty definitely will not do vectoring in hardware on bigger CPUs because they say it impacts badly on virtualization and hypervisors. Also register saving using normal instructions is better on big machines because it will use the normal mechanisms for wide dispatch, register renaming, out of order completion etc.

Maybe it can be different on microcontrollers though I find their arguments that a handler in ROM will perform well convincing.

[ataradov]

Maybe it can be different on microcontrollers though I find their arguments that a handler in ROM will perform well convincing.

Well, this thing is a microcontroller. Attempts at pushing the same exact core/system architecture for all applications will fail, for sure.

And I'm specifically comparing it to Cortex-M7, which achieve similar performance, but are much nicer to work with.

This this is a lot of fun, but "fun" is not what you want when working on real projects. In this stage, I simply don't see why anyone would use this.

Also, code security is unclear. Who would use a micro where you can dump the firmware from external device?

[ataradov]

Ok, I'm reading about PLIC, and this thing is incredibly complicated. This does not play well with the whole simplicity goal.

I understand that PLIC comes from RISC V spec, and that spec is probably not very well suited for MCUs, but still.

So far the amount of code that need to be written just to make stupid timer work is mind boggling.

And I still don't get how UART interrupts will work. Now I do. Ext interrupts are not external to the device, but external to the interrupt controller, this includes all peripheral interrupts. Now it is time for some sleep

[benSTmax]

Ok, I'm reading about PLIC, and this thing is incredibly complicated. This does not play well with the whole simplicity goal.

I got the same feeling when reading about interrupt subsystems for MIPS or PowerPC micros. Read it a few more times and it will get through. You can also try to read about the MIPS or PowerPC interrupts and you'll see the similarities. MIPS uses priorities and sub-priorities while RISC-V PLIC's priorities and thresholds behave in pretty much the same way. The difference between MIPS and RISC-V PLIC being the latter is also able to "merge" more interrupts. MIPS can only do single or multi vector interrupts. It cannot merge the multiple interrupts in more than one vector.  Sometimes, I find I need to re-read the same part over and over again to get into author's shoes and understand the concept it tries to explain.
  We're too used with patterns ...

I understand that PLIC comes from RISC V spec, and that spec is probably not very well suited for MCUs, but still.

Adding more pictures or some potential real-life examples will certainly help. Seeing David Patterson's name in the spec I can see why the RISC-V specs are resembling so much the MIPS ones.
I guess the difference here can be made only by silicon companies providing RISC-V based MCUs and also known for fairly good documentation. They would try to explain it better for the customers.

Ext interrupts are not external to the device, but external to the interrupt controller, this includes all peripheral interrupts. Now it is time for some sleep

Again, a lot of resemblance to the ARM's NVIC, MIPS or PowerPC Interrupt controllers.

[brucehoult]

Ok, I'm reading about PLIC, and this thing is incredibly complicated. This does not play well with the whole simplicity goal.

I understand that PLIC comes from RISC V spec, and that spec is probably not very well suited for MCUs, but still.

So far the amount of code that need to be written just to make stupid timer work is mind boggling.

And I still don't get how UART interrupts will work. Now I do. Ext interrupts are not external to the device, but external to the interrupt controller, this includes all peripheral interrupts. Now it is time for some sleep

You might want to start from 25:00 in this (or the whole thing):

[ataradov]

Ok, here is a very minimal, self contained, bare-metal example - https://github.com/ataradov/mcu-starter-projects/tree/master/fe310

[ataradov]

I'm also tempted to blow off the bootloader, since it is very slow. But I'd like to figure out the recovery strategy.

Are there any known tricks, easier than erasing the flash via external programmer? I guess something like pulling DQx to ground may do the trick?

[brucehoult]

I'm also tempted to blow off the bootloader, since it is very slow. But I'd like to figure out the recovery strategy.

I'm sure you're aware the delay in the bootloader is there to give time to hit reset again to recover to safe mode if you've loaded a disastrous app.

Are there any known tricks, easier than erasing the flash via external programmer? I guess something like pulling DQx to ground may do the trick?

I plan to look into writing to the flash from a running program. I'd like to do a little jit compiler, or a filesystem in the upper 8 MB of flash (which the standard config of openocd will not touch).

That requires turning off the memory-mapped reading of it temporarily, so your code has to either be safely and securely already in the cache (NOT easy to do, as there is no prefetch instruction), or else copied to the SRAM.

I don't think anyone (SiFive) has written code to do this yet. Talking to the flash via SPI to do the writing is straightforward enough -- I've read the flash chip manual -- I haven't tracked down how the memory mapping is set up (or disabled).

[ataradov]

I'm sure you're aware the delay in the bootloader is there to give time to hit reset again to recover to safe mode if you've loaded a disastrous app.

Well, yes. But there are better ways to deal with that. For example, many kits I've seen simply have a jumper to disconnect CS from the memory. I'm sure something similar will work here, but there is no easy way to disconnect CS. That's why I was looking at alternative ways to break the external flash in a way that ROM will just wait for the debugger.

[ataradov]

Ok, so I tried to short pin 2 (MISO) of the flash to the ground and device appears to be in a recoverable state.

So I tried to blow off the bootloader in flash and link my program at offset 0x20000000 (start of flash). It works fine, but there is still a huge delay before the first instruction of my program runs (1.5 seconds actually).

Do they mean to say that "helpful" delay is in the ROM? Or am I missing something here? Who needs a microcontroller that takes 1.5 seconds to "boot"?

[legacy]

1.5 second is a very long time 

[brucehoult]

Ok, so I tried to short pin 2 (MISO) of the flash to the ground and device appears to be in a recoverable state.

So I tried to blow off the bootloader in flash and link my program at offset 0x20000000 (start of flash). It works fine, but there is still a huge delay before the first instruction of my program runs (1.5 seconds actually).

Do they mean to say that "helpful" delay is in the ROM? Or am I missing something here? Who needs a microcontroller that takes 1.5 seconds to "boot"?

As documented in the HiFive and FE310 manuals, at boot it executes instructions starting at 0x1000 in mask ROM. Execution is as follows:

0x1000: j 0x20000 # start of OTP ROM
0x20000: j 0x21FF4
0x21FF4: fence
0x21FF8: lui t0, 0x20000000 #start of flash
0x21FFC: jr t0

I've checked those locations and they contain what the documentation says (except 0x21FFC which contains 0x28067 not 0x28057. 0x28067 is the correct opcode for a JALR zero,t0 while 0x28057 is a reserved major opcode, so that's a doc problem.

(Note: I had to run at 16 MHz to read the OTP. It misread (in different ways) at 256 MHz and 320 MHz. If this is known it should be documented)

I took the documentation to mean that the start delay is caused by the bootloader code at 0x20000000. If not, then the only other option is before we get to 0x1000.

[ataradov]

I've checked those locations and they contain what the documentation says (except 0x21FFC which contains 0x28067 not 0x28057. 0x28067 is the correct opcode for a JALR zero,t0 while 0x28057 is a reserved major opcode, so that's a doc problem.

Am I reading this correctly, and there is no actual code anywhere before the execution from flash? Only jumps? There must be some sort of flash initialization code and all that stuff.

I took the documentation to mean that the start delay is caused by the bootloader code at 0x20000000. If not, then the only other option is before we get to 0x1000.

Me too, and I think it was deliberately written this way. I'm pretty sure this delay before the green led comes on from the bootloader, is not caused by the bootloader itself. My board has no bootloader at this point, and delay is still there, I've moved turning on of the LED right after stack initialization, so it is as close to the beginning as it gets.

But I also feel like OTP ROM must do some initialization work. And I think that's were the delay is.

[brucehoult]

Am I reading this correctly, and there is no actual code anywhere before the execution from flash? Only jumps? There must be some sort of flash initialization code and all that stuff.

You'd think so.

The QSPI is so darned slow anyway that you could easily "memory map" it with no performance loss by trapping illegal addresses and having a ROM routine do the necessary SPI transaction. But even if hardware does that, you'd expect that hardware to need some setting up, get the SPI into the right mode etc.

But I also feel like OTP ROM must do some initialization work. And I think that's were the delay is.

The ROMs aren't all that big. Someone could dump and disassemble them.

[ataradov]

The QSPI is so darned slow anyway that you could easily "memory map" it with no performance loss by trapping illegal addresses and having a ROM routine do the necessary SPI transaction.

I really hope this is not the case, otherwise the whole thing is a joke.

And when done right, QSPI is actually not that much slower than on-chip Flash. A lot of Cortex-M7 devices have execute in place capability from QSPI and it works just fine.

But even if hardware does that, you'd expect that hardware to need some setting up, get the SPI into the right mode etc.

Exactly. I though that's what ROM code is doing.

The ROMs aren't all that big. Someone could dump and disassemble them.

With the whole thing being open, I'd expect ROM to be open as well. But I could not find it on a quick search.

[brucehoult]

The QSPI is so darned slow anyway that you could easily "memory map" it with no performance loss by trapping illegal addresses and having a ROM routine do the necessary SPI transaction.

I really hope this is not the case, otherwise the whole thing is a joke.

From the datasheet: "The IS25LP128 Serial Flash memory offers ... Clock frequencies of up to 133MHz allow for equivalent clock rates of up to 532MHz (133MHz x 4) allowing more than 66Mbytes/s of throughput."

"FAST READ DATA QPI OPERATION (FRD QPI, 0Bh)
The QPI FAST READ (FRD QPI) instruction is used to read memory data at up to a 133MHz clock.
The FAST READ instruction code (2 clocks) is followed by three address bytes (A23-A0—6clocks) and mode
bits, dummy byte (4clocks)"

And then the data comes back at 4 bits per clock.

So reading a 32 bit word for a "load word" instruction takes 2 + 6 + 4 + 8 = 20 clocks = 150.4 ns at 133 MHz. That's enough time for 38 instructions at 256 MHz, more at 320. Less the time to enter/exit a trap of course.

But the flash doesn't seem to be being run that fast, at least at the moment, as I said elsewhere I measured 144 CPU clocks (562.5 ns @256 MHz) for each additional byte read after the first one. That's about what you'd expect from standard SPI run at 50 MHz, not QSPI at 133.

[ataradov]

So reading a 32 bit word for a "load word" instruction takes 2 + 6 + 4 + 8 = 20 clocks = 150.4 ns at 133 MHz. That's enough time for 38 instructions at 256 MHz, more at 320. Less the time to enter/exit a trap of course.

But with cache and reading one page at a time, it is not that bad.

Flash in fast MCUs also needs a lot of wait states. SAM V71 needs 5 wait states with code running at 300 MHz.

But the flash doesn't seem to be being run that fast, at least at the moment, as I said elsewhere I measured 144 CPU clocks (562.5 ns @256 MHz) for each additional byte read after the first one. That's about what you'd expect from standard SPI run at 50 MHz, not QSPI at 133.

The flash right now is way underclocked. I even made a comment about this in my simple code. I'm not sure why and I have not had time to investigate and try to make it faster.

[brucehoult]

From Megan at SiFive:

 We recently added some helpful functions for setting the clock sources: https://github.com/sifive/freedom-e-sdk/blob/master/bsp/drivers/fe300prci/fe300prci_driver.h. But the SDK doesn't actually use them.

In the Freedom E SDK, the "init.c" code switches over to the PLL clock source (with the HFROSC as the input), and the code there sets the SPI clock divider high out of paranoia since we know we are running out of SPI, and sets the UART appropriately so printf will just work. We're not expecting to do anything with OTP in general, so we didn't make the corresponding change to the OTP's clock divider.

The PLL code is in init rather than in main so that it can be applied for the benchmark codes, which don't allow us to change main.

The majority of the time before code execution at 0x1000 is the internal "reset stretcher" logic inside the chip. When you release the reset button, this circuit inside the chip is tuned to wait 1-2s before deasserting the reset to the AON block. This is to give time for the LFROSC which AON is running off of to be nice and stable. Once the AON block is running, it spends a few of its slow (32kHz) cycles taking the rest of the chip out of reset. (note that actually on the FE310 the LFROSC isn't used, there is an external LFOSC).

Once the CPU is out of reset, it starts running at 0x1000. It is running off its HFROSC source which is not particularly accurate, at 12-20MHz or so. So all the code sources that we might start fetching from at reset (mask ROM, OTP, and mem-mapped SPI) have their clock divider settings with this in mind.

[ataradov]

So 1-2 second delay actually happens? That's not ideal to say the least.

[ataradov]

Also, the whole PLL initialization thing was reduced to this:

  SPI0_REG(SPI_REG_SCKDIV) = 8; // TODO: This seems excessive

  PRCI_PLLDIV_REG = PLL_FINAL_DIV_BY_1(1) | PLL_FINAL_DIV(0);
  PRCI_PLLCFG_REG = PLL_REFSEL(0) | PLL_BYPASS(1) | PLL_R(1) | PLL_F(32-1) | PLL_Q(1);
  PRCI_PLLCFG_REG &= ~PLL_BYPASS(1);

  uint32_t start_time = CLINT_MTIME_LO_REG;
  while ((CLINT_MTIME_LO_REG - start_time) < 4);

  while (0 == (PRCI_PLLCFG_REG & PLL_LOCK(1)));

  PRCI_PLLCFG_REG |= PLL_SEL(1);

I don't understand why you need a library to do this.

[brucehoult]

So 1-2 second delay actually happens? That's not ideal to say the least.

That's true.

It's the first production silicon, first evaluation board for not only this particular tiny company (about ten people), but for the architecture as a whole. I'm completely prepared to understand if they play it conservative to make sure that they have something that works, not something that doesn't work.

A hardware two second boot delay is not ideal and of course there are applications where you would not want to deploy this board in production as a result. None of the applications I've ever used an Arduino in, as it happens, but your applications may be different. The most critical thing I've used an Arduino for is my home heating control system. I turn it on mid autumn and it runs until the middle of spring. I'm pretty sure it's never restarted mid-season unless I decided to tweak the code and flash a new version.

Everything else is in your hands to make it less conservative if you want. Push the CPU. Increase the SPI clock and enable QSPI (or even "DDR", as I see). Find the limits.

Looks like we're stuck with the two second boot delay for now though. I'll live.

[ataradov]

It's the first production silicon, first evaluation board for not only this particular tiny company (about ten people), but for the architecture as a whole. I'm completely prepared to understand if they play it conservative to make sure that they have something that works, not something that doesn't work.

I'll live as well. In its current form, there is no way anyone will put this into a real product. There are too few peripherals, too many pins occupied for no good reason, peripheral feature set and selection is very limited. And too many power supplies. It is a fun toy, though.

And they really need NVIC for the MCU market. Interrupts are very-very slow at the moment. I'm consistently getting complaints from people about 15 cycles on Cortex-M cores.

[brucehoult]

I'll live as well. In its current form, there is no way anyone will put this into a real product.
complaints from people about 15 cycles on Cortex-M cores.

From Krste Asanovic, SiFIve Co-Founder & Chief Architect:

HiFive1 is a development board for our FE line of custom SoCs, and the current FE310 parts are engineering samples (that's why ES is stamped on package). We can quickly and cheaply customize a production FE310 variant to have the features you need. The reset stretcher is indeed configurable and hardware vectored interrupts are also available in custom SoC designs.