REGISTER | LOGIN
Breaking News
News & Analysis

Free Core, Some Assembly Required

RISC-V rallies engineers for open hardware
1/7/2016 07:50 AM EST
23 comments
Page 1 / 3 Next >
More Related Links
View Comments: Threaded | Newest First | Oldest First
adapteva
User Rank
Author
Additional observations
adapteva   1/7/2016 9:30:32 AM
NO RATINGS
Rick, great article as usual!

A couple of additonal observations.

1.) The "google engineer' is Ron Minnich the founder of Coreboot.

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

2.) To me the highlight of the conference was the presentation on the 2nd day showing the world's first microprocessor (RISC-V) with integrated optical interconnects that was published in Nature. An incredible example of what open collaboration can achieve!!

https://aspire.eecs.berkeley.edu/2015/12/risc-v-based-photonic-processor-in-nature/

pattrsn
User Rank
Author
Re: Additional observations
pattrsn   1/7/2016 1:50:50 PM
NO RATINGS
Here is link to Nature article on optical RISC-V:

http://www.nature.com/nature/journal/v528/n7583/full/nature16454.html

GSMD
User Rank
Author
India Processor Effort
GSMD   1/7/2016 12:10:36 PM
NO RATINGS
The Indian effort got funded two years ago and two cores have been released as open source cores. Wonder who told you that funding will start only in March ! If you need more info on this effort, please ask me, I am the tech lead. Full SoCs will be released by summer. Please see bitbucket dot org slash casl. We are probably also the only risc v effort targetting the high end server market.

rick merritt
User Rank
Author
Re: India Processor Effort
rick merritt   1/8/2016 12:55:00 AM
NO RATINGS
@GSMD: Thanks for the url. Let's talk.

perl_geek
User Rank
Author
Siblings, not derivatives
perl_geek   1/7/2016 1:58:45 PM
NO RATINGS
I'm not sure who would be more offended by your description of FreeBSD as a "Linux variant"; the BSD people or the Linux people.

Though both descend from and embody The One True Religion (Unix), they are entirely separate bodies of code, with different histories and licenses. Enlightenment has many paths. :-)*

 

pattrsn
User Rank
Author
RISC-V core in 350 LUTS!
pattrsn   1/7/2016 2:03:29 PM
NO RATINGS
While there were many impressive presentations, the highlight for me was Jan Gray's "GRVI-Phalanx" that fit ~400 RISC-V cores onto a single FPGA.

Each runs at >300 MHz and needs only 350 LUTS. Stated alternatively, he is able to deliver 1 million instructions per second per LUT, which must be a new world record. Note even less ambitious processor cores take ~2000 LUTS and run at ~100-150 MHz.

This achievement is a testament to both the Gray's engineering poweress and the simple elegance of RISC-V.

modal
User Rank
Author
Re: RISC-V core in 350 LUTS!
modal   1/8/2016 2:55:19 PM
NO RATINGS
Are the videos going to be placed online again?

http://riscv.org/workshop-jun2015.html

http://riscv.org/workshop-jan2015.html


Didn't see the second seminar till just now.

krste
User Rank
Author
Re: RISC-V core in 350 LUTS!
krste   1/8/2016 7:29:12 PM
NO RATINGS
Yes, both slides (soon) and video (later) as before.

 

krste
User Rank
Author
Re: RISC-V core in 350 LUTS!
krste   1/10/2016 1:43:40 PM
NO RATINGS
Slides from the 3rd workshop are now available at the riscv.org website.

Videos to follow.

krste
User Rank
Author
Re: RISC-V core in 350 LUTS!
krste   2/15/2016 12:15:33 PM
NO RATINGS
Videos from the 3rd RISC-V Workshop are now available on the new Foundation website, at riscv.org.

Save the date for the 4th RISC-V Workshop to be held July 12-13, 2016 at MIT.

 

 

KarlS01
User Rank
Author
Re: RISC-V core in 350 LUTS!
KarlS01   2/15/2016 10:34:25 AM
NO RATINGS
RISC-V has 32 16 bit registers plus a 32 bit instruction register so "350 LUTs" is marketing talk.

Also the speed is probably for the latest generation of FPGA and the 100 MHz is for older less expensive generations.

I looked at the RISC ISA spec and it is still load/add/store kind of stuff with a heavy emphasis on immediate type instructions so the 16 bit base has a 32 bit instruction word to hold the immediate operand along with 2 source registwe addresses and a destination register address.

A fine academic exercise (hopefully there will be more HW types that know what goes on inside a computer)  But on the other hand, HW design is not about computer design.

What is good about it is that it was pointed out that so many can be put on a chip.  Now we can think about dedicating a RISC-V to each thread that is run on an RTOS with all the headaches of interrupts and scheduling.  KISS may live on.

 

krste
User Rank
Author
Re: RISC-V core in 350 LUTS!
krste   2/15/2016 12:18:32 PM
NO RATINGS
RV32I has 31x32-bit integer registers plus zero register.  There is no 16-bit base for RISC-V.

KarlS01
User Rank
Author
Re: RISC-V core in 350 LUTS!
KarlS01   2/15/2016 12:54:24 PM
NO RATINGS
Then I truly do not un derstand page 26 that shows compute instructions and 32 bit integer compute instructions with "W" as the last letter of the mnemonic and op code 0111011 vs 00110011.

krste
User Rank
Author
Re: RISC-V core in 350 LUTS!
krste   2/15/2016 1:03:09 PM
NO RATINGS
The *W variants of RV64 (the 64-bit base ISA) instructions produce 32-bit sign-extended results in 64-bit registers.  They support common operations on 32-bit values in 64-bit  registers.

KarlS01
User Rank
Author
Re: RISC-V core in 350 LUTS!
KarlS01   2/15/2016 1:44:14 PM
NO RATINGS
OK, the point was that there is more to anFPGA thanLUTs. 

The spec has a separate section for 64 bit version and it seems logical that sign extension would be automatic just as it is for immediates.

Is there real need for 64 bit aside from memory addressing(which is probably managed by OS and MMU?)

Rather than a new RISC,  compiler, debugger, etc.  Why not execute the usual HLL statrments?  Certainly the compiler would be simpler.  In fact app debug could be done then loaded onto the chip analogous to using an FPGA and loading the bit stream.

And there is the memory, cache(s) MMU, IO, memory wall, and von Neumann bottleneck.

And this is all justified to be independent of ARM?

krste
User Rank
Author
Re: RISC-V core in 350 LUTS!
krste   2/15/2016 2:38:59 PM
NO RATINGS
Re: The point: a minimal RV32I implementation is very small in LUT usage, competitive with the smallest, and less capable, stack implementations.

Re: 64-bit: Yes, addressing is main reason to extend to 64-bits, and even smartphones use 64-bit addressing now.  See Bell and Strecker, ISCA-3.

Re: Why not execute usual HLL statements? See last 35 years of Comp Arch literature.

Re: von Neumann bottleneck: much hyped, wrongly named, non-problem.

Re: all this to be independent of ARM?  No - we did this to do things ARM doesn't support, like simple implementations, like openly sharing RTL between groups, or at the time, 64-bit addressing (ARM v8 happened later).

KarlS01
User Rank
Author
Re: RISC-V core in 350 LUTS!
KarlS01   2/17/2016 12:57:44 PM
NO RATINGS
"Re: The point: a minimal RV32I implementation is very small in LUT usage, competitive with the smallest, and less capable, stack implementations."

And which stack machines were used for comparison and what benchmsrks weere used?

"Re: von Neumann bottleneck: much hyped, wrongly named, non-problem"

And the room was filled with smoke from funny cigarettes. 

"Re: Why not execute usual HLL statements? See last 35 years of Comp Arch literature."

The last 35 years has been dedicated to RISC/super scalar and RISC was created because the compilers of thjat era were only capable of generating very simple machine code.

Meanwhile compilers have evolved to generating some form of byte code and using the RISC CPU to emulate a stack machine.

Also OOP has evolved and the use of methods that take parameters off the stack and return the rersult on the top of the stack.

Real live computers have register files and tons of circuitry to execute out of order because of memory latency.

Over the last 35 years there have been many poeople inventing ISAs and the best thing to be said is that they are different.  BUT all have the same generic ALU operations after the operands are finally available.  Most differences are load/store addressing.

And going from 32 bit addresses to 64 bit feeds the marketing hype generator, but the world will end before anymemory of that size can be filled.

I survived the real world of computer development for 30 years. 

krste
User Rank
Author
RISC-V is not a free core, it's a free and open ISA
krste   1/8/2016 4:56:36 AM
NO RATINGS
Hi Rick,

Thanks for great coverage of the event.

I just wanted to clarify for your readers that RISC-V is not an open-source core - it's a free and open ISA specification around which a whole ecosystem is being built.

Of course, there are now many open-source RISC-V cores available, and not just from Berkeley.

But there are also quite a few proprietary RISC-V cores in various stages of development, most of which will probably never be publicly announced.

 

ronaldgminnich
User Rank
Rookie
slight correction on my coreboot talk
ronaldgminnich   1/10/2016 1:31:53 PM
NO RATINGS
Hi, I enjoyed the article, but I do have a slight correction.

Coreboot runs on all Chromebook and Chromebox devices. There no Android devices that I know of running coreboot.

Coreboot runs on the RISCV simulators and has for 15 months, booting to Linux. We are hoping to have it on RV64G hardware as soon as we can get some :-)

There are no available RISCV Chromebook/box devices and I am sorry if I left that impression.

Thanks!

ron

rick merritt
User Rank
Author
Re: slight correction on my coreboot talk
rick merritt   1/10/2016 7:55:31 PM
NO RATINGS
@ronaldgminnich I rewrote the sentence on Coreboot to make these points more clear. Sorry for any confusion and stay in touch!

KarlS01
User Rank
Author
Still another RISC ISA/ load store machine,,,Ho Hum!
KarlS01   1/12/2016 10:33:44 AM
NO RATINGS
RISC came about because compilers had problems using CISC, but every RISC requires a new compiler.  On top of that, the RISC is running as/emilating a stack machine.

A compiler generates a compact intermediate language which is byte code that is EXPANDED to RISC code sometimes at run time JIT compiler which inserts the loads and stores.

Then the superscalar crowd tells us that the data is in register filess so the loads and stores do not access memory --  RISCV load and store certainly expect to access memory and will do so unless the CPU is designed as a super scalar.  Yes memory accesses may be reduced somewhat.

Systems have problems due to the "memory wall" so there certainly are a lot of memory accesses.

The compiler can essentially be eliminated by parsing the source code to extract the control flow and then a straight forward FSM can be designed to execute the control flow.

Another factor is that accxelerators and GPUs are given a block of data that is kept in local memory for peocessing,  ASMP is alive and well.

I have a prototype FPGA stack machine that uses three dual port memories and a couple of hundred LUTs to execute C source code.

JamesM951
User Rank
Manager
Re: Still another RISC ISA/ load store machine,,,Ho Hum!
JamesM951   2/15/2016 12:43:59 PM
NO RATINGS
Can you provide more info on your stack machine ?  My email is  geopzm at gmail dot com

KarlS01
User Rank
Author
Re: Still another RISC ISA/ load store machine,,,Ho Hum!
KarlS01   2/15/2016 1:48:12 PM
NO RATINGS
@James:  I will do that, but have some errands now.  Thanks.

Like Us on Facebook
EE Times on Twitter
EE Times Twitter Feed