The NEORV32 Risc-V Processor

[laugensalm]

Not mentioning that every single university project is multi-cycles-based rather pipeline-based.

Not mentioning that every single project that aims for real-time and cycle-precision is multi-cycles-based rather then pipeline-based.

Not mentioning that every single project when you have to deal with pipeline needs "critic code" and instructions like { sync, isync, fence, ... } which (in every PowerPC  book) are described as "voodoo black magic code"

You may have to accept the fact that there is a majority of 'old farts' here who have designed CPUs and know what they're talking about.
Multi-cycling does not mean it's simpler, and your statement on realtime and black magic simply is not correct. You might want to read on some DSP architectures like Blackfin (instruction set designed by Intel). And there are pipelined RISC-V with deterministic cycle counts.
Pipelining is no black magic, but yes, you've got to deal with hazards. Something that is taught in an introduction to the classic MIPS architecture. The most complicated thing is to sort out the in circuit debugging in conjunction with external exception/interrupt events. Something where most (academic) projects show a big FAIL.
There's also a reason why most vendor specific architectures (NIOS, Mico32, ...) is designed similar: The concept just runs very well on an FPGA and can be implemented very minimally. On the other hand, multi cycle approaches can in some cases turn into a badly balanced logic and even cause more power consumption than the pipelined variant. Been there, done that.

[SiliconWizard]

Just because something is harder to implement doesn't mean it's crap. With that reasoning, we wouldn't be talking on a web forum.

The only "reasonable" part of DiTBho's point, IMO, is that if *they* don't feel *they* can safely implement a pipelined CPU, and it's for a professional project with a hard deadline, then they probably shouldn't even try.

That said, knowing your limits is great. Doesn't mean you should not try to overcome them. Else you're just going to stagnate.

As to determining the benefits of a CPU being able to process several times as many instructions for a given clock frequency, even a 4-year old can understand that.
Of course, as always with engineering, if you don't NEED the performance, you may consider whether it's worth the trouble. But that's engineering 101. (And still try having some kind of long-term vision - just because some architecture is not strictly *needed* right now doesn't mean it won't be in a few months/years from now, and having to do it all over again may have excessive and unjustified extra cost. But al this is again engineering 101, nothing new here.)

[DiTBho]

Just because something is harder to implement doesn't mean it's crap.

When I say that this forum is frustrating ... isn't it? Well, I said just that because people in this forum are obsessed by performance, it doesn't mean that simpler solutions are crap, neither that if you don't do pipelined stuff you are a donkey.

[brucehoult]

Just because something is harder to implement doesn't mean it's crap.

When I say that this forum is frustrating ... isn't it? Well, I said just that because people in this forum are obsessed by performance, it doesn't mean that simpler solutions are crap, neither that if you don't do pipelined stuff you are a donkey.

And if your requirements are simple enough you might just use an FSM and forget this Turing-complete stuff, неправда?

[DiTBho]

And if your requirements are simple enough you might just use an FSM and forget this Turing-complete stuff

At least it won't be affected by PacMan, which explotis Cache-miss and Pipeline-branch prediction errors 

[dolbeau]

Not mentioning that every single university project is multi-cycles-based rather pipeline-based.

The original Stanford MIPS was pipelined (became MIPS R2000).
The Berkeley RISC was pipelined (became SPARC).
Fast forward to the present, Ariane (became CVA6) and RI5CY (became cv32e40p) are pipelined.

Not mentioning that every single project that aims for real-time and cycle-precision is multi-cycles-based rather then pipeline-based.

Even the smaller Arm Cortex-R, the R4, is pipelined.

Not mentioning that every single project when you have to deal with pipeline needs "critic code" and instructions like { sync, isync, fence, ... } which (in every PowerPC  book) are described as "voodoo black magic code"

Those instructions are not required for pipelines, but for multiprocessors.

[DiTBho]

The original Stanford MIPS was pipelined (became MIPS R2000).
The Berkeley RISC was pipelined (became SPARC).

University projects like SPIM, MARS, and laboratory projects assigned to students: all multi-cycles!

[DiTBho]

Those instructions are not required for pipelines, but for multiprocessors.

Superscalars need them, as well as Multitreads need them

custom designs with non-superscalars and LIFO/FIFO memory mapped devices may need "pipeline-dedicate instructions" to mitigate.

Talking about the RISC-V ISA, there are implementations that use a "relaxed memory model" where the order of loads and stores performed by one thread may be different when seen by another. This is done to enable techniques to increase memory system performance.

Because again we are all obsessed by performance, aren't we? sure we are, and gain, FENCE is the only thing that can save your day.

[brucehoult]

Those instructions are not required for pipelines, but for multiprocessors.

Superscalars need them, as well as Multitreads need them

custom designs with non-superscalars and LIFO/FIFO memory mapped devices may need "pipeline-dedicate instructions" to mitigate.

Talking about the RISC-V ISA, there are implementations that use a "relaxed memory model" where the order of loads and stores performed by one thread may be different when seen by another.

Not by another thread. By another CPU.

[DiTBho]

Not by another thread. By another CPU.

Same CPU with resources replication

[brucehoult]

Not by another thread. By another CPU.

Same CPU with resources replication

What do you mean by that?

RISC-V caches must appear to software [1] to be physically-indexed, physically-tagged, so even if another thread accesses the same RAM at a different virtual address the correct data is seen.

[1] many implementations use virtually-indexed L1 cache so the cache access can proceed in parallel with the TLB lookup, but as long as the associative "way" size is no larger than a VM page the effect it the same. i.e. a 16 KB L1 cache must have at least 4 ways, a 32 KB L1 cache must have at least 8 ways etc. L2/L3 cache waits for TLB so can have fewer ways.

[betocool]

The reasons for me to use this processor are in no particular order:
- Documentation is pretty good, as well as examples
- Support from the mantainer is top notch. I've been working with him this week in getting to execute code from an SPI flash on my dev kit by changing the bootloader. After a few misses and some bugs we found, it's working.
- Performance wise... we'll see... very early days still, but if I can get an audio signal ADC'd and DAC'd, that will be a good start.

With the above in mind, I've felt that other implementations are more "academic" oriented, if that makes sense, in terms of creating big constructs but in a more complex way, aimed at FPGA developers rather than µC users/developers. It's fun to add a new peripheral to your micro, I love that flexibility, but after that's done some of us would want to just use the construct, flash a binary, debug the code, and be done with the project until the next one comes along.

The above is my opinion, based on observation. I'm not belittling the work other groups have done, I'm a big fan of open source, but at times it's very hard to get through the initial barrier in new projects.

Cheers,

Alberto