Breaking News
Comments
Newest First | Oldest First | Threaded View
<<   <   Page 5 / 7   >   >>
adapteva
User Rank
Manager
Re: Apples vs oranges comparisons...
adapteva   8/8/2014 8:29:06 AM
NO RATINGS
@Wilco1,

Not sure it is possible to argue "goodness" based on reading the spec. Things don't get much better with more quantitative analysis like kernel benchmarks. Silicon area, frequency, # issues are first order effects, other factors less so imho. Personally I certainly wouldn't argue too hard with Professor Patterson design decisions:-) I learned pretty much everthying I know about computer architecture from reading his books.

It's an interesting discussion for sure, but let's not forget that the REALLY big news is that fact that the world now has a first rate free to use openly available ISA for all to use.

Who knows...maybe this will be the Linux equivalent moment for chip design...

Andreas

sbourdeauducq
User Rank
Rookie
Chisel
sbourdeauducq   8/8/2014 4:46:07 AM
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"

How exactly does Chisel enable that? I had a look at it, and it seems to be a Scala-driven HDL generator. It probably makes design easier and faster, but the area/power should be the same as when using HDL directly.

jeremybennett
User Rank
Rookie
Re: Why not build on OpenRISC
jeremybennett   8/8/2014 3:34:43 AM
NO RATINGS
@Rick,

The big OpenRISC enhancements in the last few years were the new implementations without branch delays, with much shortened pipelines, and the improvements to multicore support. The community is very active at present, so it can be hard to keep track of all the changes (see the #openrisc IRC channel on freenode.net for the ongoing conversations).

It's always hard to know with open processors who is using them - the community tends to hear after the event. OpenRISC is in some Samsung set top box chips, and in NXP/Jennic Zigbee chips (in the BA Semi variant). OpenRISC is used as a power controller in the AllWinner A1000, part of their A31 ARM based SoC. OpenRISC flew in NASA's TechEdSat a year or two ago (declaration of interest, we did a commercially robust version of the GCC C compiler for that project).

There is an ongoing project at the University of Genoa and ETH Zurich, supported by ST, which is developing a low energy multicore SoC based on OpenRISC.

I'd be interested if other readers had heard of new commercial uses.

The OpenRISC community has for a year or two considered specifying a future architecture, known as OpenRISC 2000. Perhaps we should be looking to RISC-V as the basis of that architecture? There would be a certain intellectual consistency, given OpenRISC 1000 was based on DLX. Doubtless this will be discussed at ORConf 2014 in October.

Wilco1
User Rank
CEO
Re: Apples vs oranges comparisons...
Wilco1   8/8/2014 12:09:31 AM
NO RATINGS
Well, to be honest I don't know where to start - a LOT of useful instructions are missing in RISC-V. Eg. load/store indexing, load/store of 2 or more registers, shift+add, conditional move/select, conditional compares, branch/call instructions with a larger range, immediate instructions that allow efficient 2-instruction sequences, rotate, bitfield operations, multiply accumulate (and yet there is REM???), add-carry etc.

Then there is DSP, SIMD, CLZ, etc, and although these are less frequently used, they do provide significant speedups. It's important to understand there is never a need for every instruction to improve performance across all applications - if you go down that path you end up with something like Alpha, ie no byte or halfword loads/stores as 80% of applications hardly need them! All you need is to show the benefit of an instruction outweighs its cost.

Note also the codesize impact is an important consideration - I proposed several instructions in Thumb-2 solely for the benefit of improving code density (ultimately that means lower power and improved performance). Given RISC-V will have pretty bad code density due to all the missing instructions, adding a compressed form of the ISA should be a priority.

modal
User Rank
Rookie
Re: Apples vs oranges comparisons...
modal   8/7/2014 11:30:03 PM
NO RATINGS
So you still pay pipeline penalties if you take a branch or does the architecture some how mitigate this some other way?  (delayed branch instructions helps reduce branch penalties)

 

 

pifourth
User Rank
Rookie
What about SPARC v9 rather than SPARC v8?
pifourth   8/7/2014 11:30:03 PM
NO RATINGS
Should you be comparing RISC-V to SPARC V9, which supports 64 bit operations,  rather than comparing RISC-V to SPARC V8, which supports 32 bit operations?

 

 

Wilco1
User Rank
CEO
Re: Apples vs oranges comparisons...
Wilco1   8/7/2014 11:22:01 PM
NO RATINGS
Sure it may run Linux, but the Rocket variant that was compared with the A5 doesn't appear to have an FPU or any other extension beyond the very basic 64-bit ISA. So that variant most certainly can't run SPEC well or do anything that you expect in a modern CPU (multi-core, debug, performance counters, timers, interrupt controllers and so on). Cortex-A5, while one of the smallest ARMv7-A cores, is far more advanced, significantly faster and has good code density (unlike RISC-V).

So if you wanted to do a barebones CPU comparison you should compare with an M0 or M3 with an added MMU. That would be a reasonable comparison as they have very similar features. Performance will be close on 32-bit code, but M0/M3 obviously wins big time on power, code density and area.

On the other hand, if you wanted to compare a full SPEC capable Rocket version, you'd have to give the size/power for the full version including all the extensions, FPU, MMU, caches, etc. No bait and switch like giving area/power results for a minimal version while quoting performance of the most advanced version!

The thing is, when you aim for a similar level of performance as modern ARM CPUs then you'll need a real memory system. Not a 1-way 8KB cache like the very first Alpha used more than 2 decades ago!!! That means a much larger die size and higher power.

There are SPEC scores available for various ARM cores, however you can buy pretty much any device nowadays and just run benchmarks yourself. You can use the NDK on Android devices (or Linux if you root it), but I find a Chromebook is a perfect ARM Linux development machine (lots of people run SPEC on it).

Anyway, if you actually ran the full SPEC2006 on Rocket, just publish the scores. I don't see why you have to run it first on ARM.

Dhrystone is a zombie benchmark indeed, partly because it is easy to use, gives a quick&dirty estimate of core-only performance, and all benchmarks that tried to replace it turned out to be far worse. So it won't die any time soon...

Here is an idea: to give people an idea what the ISA is like, why not publish the Dhrystone disassembly? I bet not everybody will have a spare week for downloading, building and troubleshooting the RISC-V tools...

krste
User Rank
Rookie
Re: Apples vs oranges comparisons...
krste   8/7/2014 9:47:33 PM
NO RATINGS
"Cortex-A5 actually runs Android pretty well, and I bet RISC-V with its very basic ISA won't be able to keep up"

I'm curious.  What instructions do you imagine we're missing in RISC-V G that would make Android run better?  Nearly all compiled integer code I see is dominated by the very simplest instructions and it is extremely hard to add an instruction that really improves performance across all applications.

pattrsn
User Rank
Rookie
Re: RISC-V for Parallella?
pattrsn   8/7/2014 9:45:49 PM
NO RATINGS
As the technical report says, we intend RISC-V to be used for everything from as small as Internet of Things (IoT) to as large as Cloud Computing (Warehouse Scale Computers or WSCs).

As some of other posts hint, RISC-V is a very modular ISA, while still a reasonable target for compilers.

For IoT, you'd want to use 32-bit address, integer instructions (I), and compressed instrucitons (C). We call that RV32IC

For WSC, you'd want to use at 64-bit addresses (and over the next decade maybe even 128-bit addresses), integer instructions (I), multiply-divide (M), atomic instructions (A), single (F), double (D), and even quadruple (128-bit or Q) floating point instructions: We call that combination RV64IMAFDQ

 

krste
User Rank
Rookie
Re: OS support for RISC-V
krste   8/7/2014 9:37:08 PM
NO RATINGS
We are in contact with some other OS developers, but are focused on finishing the privileged architecture specification and system binary interface specification to reduce the effort of porting OSs to different RISC-V implementations.

<<   <   Page 5 / 7   >   >>


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

Steve Wozniak Reacts to Latest iPhone
Max Maxfield
5 comments
Funnily enough, just a few days ago as I pen these words, I was chatting with my wife (Gina the Gorgeous) when she informed me that -- as a kid -- she had never played at making a ...

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)