Breaking News
Comments
Oldest First | Newest First | Threaded View
Page 1 / 7   >   >>
jeremybennett
User Rank
Rookie
Why not build on OpenRISC
jeremybennett   8/7/2014 12:07:07 PM
NO RATINGS
I'm not sold on the idea that we have to start from scratch to get an industry standard open ISA. As the article notes, we already have OpenRISC, which comes with an open bus standard (WishBone). The architecture is based on something well proven (DLX, of which David Patterson was half the design team), for which there is plenty of tutorial material.

It takes a long time to build all the software infrastructure around a new ISA. Surely far better to start with something like OpenRISC that has spent 15 years invested in its software.

The OpenRISC architecture doesn't tick all the author's boxes, but it is extensible, and the missing features (do we really need 128-bit addressing) could be added.

One feature that is not mentioned is multiprocessor support. Thanks to the work of Stefan Wallentowitz at TU Munich and others, this is something that OpenRISC now supports. It seems to me this ought to be a key feature of any new ISA.

The authors are two engineers for whom I have the greatest respect. I wish RISC-V well, because this team is certain to innovate, and that can only be good for the field. But as the basis of an industry standard open ISA? I wish they had built on what was already there, rather than starting again from scratch.

pattrsn
User Rank
Rookie
Re: Why not build on OpenRISC
pattrsn   8/7/2014 12:31:58 PM
We started in 2010, when OpenCore only had a 32-bit address space, which was a fatal flaw that was later corrected. It is still missing the small code size option, which is requirement for IoT. 

And I am not sure if everyone understands the importance of the "Base+Extension" approach to instruction sets. This is a new approach to coping with software compatability of instruction sets. As we wrote in the associated technical report:



"RISC-V is aimed at SoCs, with a base that should never change given the longevity of the basic RISC ideas; a standard set of optional extensions that will evolve slowly; and unique instructions per SoC that never need to be reused."

Software compatability with controlled evolution.

(And it's really hard in 2014 to embrace an ISA that offers delayed branches:)

pattrsn
User Rank
Rookie
Re: Why not build on OpenRISC
pattrsn   8/7/2014 12:38:36 PM
If you want to learn more about the RISC-V ISA, go to riscv.org

jeremybennett
User Rank
Rookie
Re: Why not build on OpenRISC
jeremybennett   8/7/2014 1:32:16 PM
NO RATINGS
Hi David,

Thanks for the quick reply. I've used it as an excuse to go off and read the V2.0 ISA spec for RISC-V instead of doing the day job :-) I see that RISC-V does have multicore support in its memory model.

OpenRISC has a core instruction set, which is stable and then various extensions around that core. We have debated the number of extension sets - there are too many at present, meaning compilers need too many multilibs to use them efficiently.

As we have found with the OpenRISC GCC implementation, combinatorial explosion of multilibs may be a challenge for RISC-V. There are a 32-bit base, 64-bit base, 128-bit base and 10 standard extensions, so a compiler potentially needs 8192 multilib variants to efficiently support all possible combinations of ISA. It is possible that some extensions will have no impact on compiled code, but the number of multilibs will still be too high, so the compiler will need to restrict itself to likely popular combinations, degrading efficiency - 15-20 multilibs is a practical limit. Alternatively the user builds a compiler just for their specific architecture, but that still puts a demand on the compiler writer to be able to juggle all the possible options (consider for example how to optimally compile a * b for all C/C++ types with all possible combinations of optional ISA extensions).

BTW, OpenRISC made delayed branches optional a few years ago. All the recent implementations (e.g. Julius Baxter's mor1kx implementations) don't have delayed branches. The online version of the OpenRISC 1000 architecture spec should reflect this.

I hope RISC-V is successful, but I would rather it focussed on forward-looking innovation in ISA development, instead of industry standardization, which is innevitably backwards looking.

adapteva
User Rank
Manager
RISC-V for Parallella?
adapteva   8/7/2014 1:41:25 PM
NO RATINGS
David,

This is so cool!

What kind of use range do you see for the RISC-V?

Do you envision having variants of the architecture for different domains (like MIPS and ARM) or do you think we should move forward with a heterogeneous apporach (different ISAs/approachs for different tasks)?

btw. Love the fact that it runs on Zynq! We will give it a try on Parallella immediately.:-)

http://riscv.org/download.html#tab_#zynqfpga

Andreas

 

rick merritt
User Rank
Author
Re: Why not build on OpenRISC
rick merritt   8/7/2014 5:03:35 PM
NO RATINGS
@Jeremy: What's on the horizon for OpenRISC in terms of any new enhancements or commercial uses?

rick merritt
User Rank
Author
Re: RISC-V for Parallella?
rick merritt   8/7/2014 5:04:43 PM
NO RATINGS
@Andreas: I'd love to see whatever comparative results you get vs. ARM or MIPS.

rick merritt
User Rank
Author
Re: RISC-V eco-system
rick merritt   8/7/2014 5:09:08 PM
NO RATINGS
@GSMD: I'd love to hear more about the status of those tailored fabrics, the open IP and I believe the computer system you are bulding with all this.

I think I am looong overdue on getting back to you about this effort.

Wilco1
User Rank
CEO
Apples vs oranges comparisons...
Wilco1   8/7/2014 8:08:22 PM
NO RATINGS
"Thanks in part to the open-source Chisel hardware design system, one 64-bit RISC-V core is half the area, half the power, and faster than a 32-bit ARM core with a similar pipeline made in the identical process."

This is hardly a valid comparison. The Cortex-A5 supports fast multiplies, DSP extensions, SIMD extensions, large TLBs and caches, branch prediction, compressed instructions, hardware Java execution, security extensions, interrupt control, multi-core etc etc. The base RISC-V ISA is more similar to a Cortex-M0 which is significantly smaller and more efficient than a Cortex-A5. But like RISC-V's basic ISA it is not suitable to run eg. Android. 

It is easy to make a simple MIPS-like RISC ISA and a bare-bones CPU which appears to do well on Dhrystone. However that's hardly proof of anything. MIPS used to have various CPUs that showed that with 64-bit load/store and delayed branches you get amazing 32-bit Dhrystone scores from a simple pipeline - nice trick, just a shame that it didn't help nearly as much when running real code. Cortex-A5 actually runs Android pretty well, and I bet RISC-V with its very basic ISA won't be able to keep up.

Also this appears to be a comparison of a 5 year old widely used CPU with a simulation of an unfinished CPU. Let's compare when actual hardware is available - and instead of Dhrystone, compare with the 64-bit A53 running eg. SPEC2000.

rick merritt
User Rank
Author
OS support for RISC-V
rick merritt   8/7/2014 8:36:43 PM
NO RATINGS
Wilco suggests a question: What's going on in terms of getting Android and any other OSes in RISC-V?

Page 1 / 7   >   >>


EE Life
Frankenstein's Fix, Teardowns, Sideshows, Design Contests, Reader Content & More
Max Maxfield

Oh, No! My Antique Analog Meter Has Twitched Its Last
Max Maxfield
20 comments
Well, life is certainly full of ups and downs, isn't it? When it comes to the antique analog meters I'm using in a number of my hobby projects, things appeared to be going swimmingly well, ...

EDN Staff

11 Summer Vacation Spots for Engineers
EDN Staff
20 comments
This collection of places from technology history, museums, and modern marvels is a roadmap for an engineering adventure that will take you around the world. Here are just a few spots ...

Glen Chenier

Engineers Solve Analog/Digital Problem, Invent Creative Expletives
Glen Chenier
15 comments
- An analog engineer and a digital engineer join forces, use their respective skills, and pull a few bunnies out of a hat to troubleshoot a system with which they are completely ...

Larry Desjardin

Engineers Should Study Finance: 5 Reasons Why
Larry Desjardin
46 comments
I'm a big proponent of engineers learning financial basics. Why? Because engineers are making decisions all the time, in multiple ways. Having a good financial understanding guides these ...

Flash Poll
Top Comments of the Week
Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed

Datasheets.com Parts Search

185 million searchable parts
(please enter a part number or hit search to begin)