RISC-V Support in FPGA - Page 3

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: RISC-V Support in FPGA
On 5/1/2017 11:45 AM, Robert F. Jarnot wrote:
Quoted text here. Click to load it

This design has processors plus other interconnecting logic.  Hard to  
say how much is processor.  Taking it all as processor gives around 1.54  
kLCs per processor.  There are lots of processors that are much smaller  
than this.

I don't see *any* info on the speed of these processors, so I don't know  
what the "fast" claim is based on.

--  

Rick C

Re: RISC-V Support in FPGA
See http://fpga.org/grvi-phalanx/ Processor clock speed is 300-375 MHz  
in a Kintex UltraScale. Placement constraints are required to get this  
kind of clock speed, something that Jan Gray is very good at. Follow the  
link to the 'Best Short Paper Award' for more details on how the logic  
is partitioned between processor and router. For another perspective on  
RISC-V see  
http://www.adapteva.com/andreas-blog/why-i-will-be-using-the-risc-v-in-my-next-chip/

On 05/01/2017 06:40 PM, rickman wrote:
Quoted text here. Click to load it


Re: RISC-V Support in FPGA
On 5/2/2017 11:59 AM, Robert F. Jarnot wrote:
Quoted text here. Click to load it

I suppose 300 MHz is pretty fast in an FPGA.  But what would the  
comparison point be to call it "fast".  It should be compared to other  
processors.

--  

Rick C

Re: RISC-V Support in FPGA
The soft core world is always changing, but looking at
www.ijireeice.com/upload/2015/december-15/IJIREEICE%2041.pdf seems to  
indicate that 300 MHz is fast for a soft core, with many soft cores (at  
opencores.org for example) running much slower than this. Note that  
Table 1 in the referenced article does not seem to distinguish between  
soft cores running in an FPGA and those implemented in an ASIC.

On 05/02/2017 09:55 AM, rickman wrote:
Quoted text here. Click to load it


Re: RISC-V Support in FPGA
Quoted text here. Click to load it
  
Quoted text here. Click to load it

Speaking of ARM, I still can't figure out how ARM was acquired for $32B.  I
f even a student can make a synthesizable 32-bit processor in a few weeks,  
how much value can there be in a processor?  It's almost a commodity.  I kn
ow there is a lot of value in prediction pipelines, cache logic, compilers,
 etc., but not $32b' worth.  


Re: RISC-V Support in FPGA
On Mon, 01 May 2017 16:07:02 -0700, Kevin Neilson wrote:

Quoted text here. Click to load it

So, maybe the people who SOLD it are laughing their way to the bank.

ARM processor variants have a huge installed base -- I suspect that went  
a long way to justifying the $32B.  But, if ST started offering parts  
with the RISC-V core tomorrow, at a better price, I'd switch.

--  

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: RISC-V Support in FPGA
On 05/01/2017 04:46 PM, Tim Wescott wrote:
Quoted text here. Click to load it

You would.  I probably wouldn't, having a larger team to drag around and  
all of the associated infrastructure.

But the cell phone companies, with all that already written codebase and  
10s of millions of units sold per year?  Not a chance they do.  That's  
billions of dollars of inertia.


--  
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

Re: RISC-V Support in FPGA
On Mon, 01 May 2017 17:15:01 -0700, Rob Gaddi wrote:

Quoted text here. Click to load it

I probably have 20 lines of ARM assembly written, and in retrospect that  
could just as well be carefully-crafted C.  Assuming that FreeRTOS makes  
a port, everything else is C or C++, and could just be compiled for the  
new target.

I don't know about the cell phone companies -- are they really that  
heavily invested in processor-specific stuff?

--  

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: RISC-V Support in FPGA
On 5/1/2017 8:42 PM, Tim Wescott wrote:
Quoted text here. Click to load it

Assembly language code is not the only way to be wedded to an  
architecture.  There are lots of C code written to manage the CPU and  
tightly coupled functionality not to mention optimizing code for maximum  
performance in an architecture.  Then there is the effort required to  
optimize the tools.  Yes, it is easy to port tools, but to get them  
honed for optimal usage requires a lot more effort.  I doubt that has  
been done for the RISC-V as yet.

--  

Rick C

Re: RISC-V Support in FPGA
On 02/05/17 03:46, rickman wrote:
Quoted text here. Click to load it

A sizeable part of that is hidden in the three key components - the OS
kernel, the basic libraries, and the compiler.  The huge majority of the
code on a telephone is cpu agnostic.  Most of it got bumped from 32-bit
ARM to 64-bit ARM without much bother, and the 32 to 64 bit jump is
often a bigger port issue than moving between different 32-bit
architectures.

I don't know if the current state of these RISC-V tools are good enough,
however - I believe the Linux port of RISC-V is quite new, and the gcc
port has just been redone.  For the big customers, they will want to see
a bit of maturity before considering RISC-V.

For us mere mortals, however, RISC-V is a great idea.  If nothing else,
it gives ARM some much-needed competition (which should have come from
MIPS).


Re: RISC-V Support in FPGA
On 5/2/2017 3:12 AM, David Brown wrote:
Quoted text here. Click to load it

The proportion of the code to be modified is not relevant, only the  
amount.  It is also not relevant where the code resides.  If you want to  
port to a new processor you will have to touch every bit of code that is  
specific to the processor, period.


Quoted text here. Click to load it

I had the impression MIPS is still a viable contender in many markets,  
but mostly built into ASICs.

I wonder how important the royalties are when designing a CPU into an  
SOC.  I believe the RISC-V is totally royalty free.  But I'm not  
familiar with the BSD license, but I think it allows for commercial  
versions.  So a company may spring up that adds significant value and  
charges royalties.

--  

Rick C

Re: RISC-V Support in FPGA
On Tue, 02 May 2017 11:24:10 -0400, rickman wrote:

Quoted text here. Click to load it

Yes and no.  Everything that David quotes are things that are spread out  
over many users and -- with the possible exception of the OS kernel --  
are not proprietary.  So in commercial terms there's a large customer  
base to amortize the cost over -- in open-source terms anyone offering  
paid support for the processor would get paid, and the starry-eyed  
idealists will do it to help the large number of potential users.

--  
Tim Wescott
Control systems, embedded software and circuit design
We've slightly trimmed the long signature. Click to see the full one.
Re: RISC-V Support in FPGA
On 5/2/2017 11:52 AM, Tim Wescott wrote:
Quoted text here. Click to load it

This doesn't really address the original issue which was the wedding of  
a user to a CPU ISA/processor.  All of this has been done for the ARM  
and done very well.  The fact that very little of the code used in a  
product is assembly is not the important fact.  To change architectures  
a user will want to know that all of the above things have been done and  
done well in addition to the work involved in the *user* coming up to  
speed with a new ISA/processor.

I don't believe for a minute that CPU users are largely CPU agnostic  
even if most of the code it.  "Most of the code" doesn't mean most of  
the *work*.

--  

Rick C

Re: RISC-V Support in FPGA
On 5/2/2017 10:24 AM, rickman wrote:

Quoted text here. Click to load it

You don't even need to add anything, it can be used for Open or  
Commercial use but in the US you can't copyright or patent the original,  
only the changes made.

--  
Cecil - k5nwa

Re: RISC-V Support in FPGA
On 02/05/17 17:24, rickman wrote:
Quoted text here. Click to load it

That is true - but it is rather important that the parts that are  
processor specific are limited in scope.

Of course, the rest of the code (at least, the C or C++ code) needs to  
be checked and tested - there may be accidental processor specific code  
such as alignment errors that happen to work fine on one processor but  
cause bus errors on another one.

Changing architectures is not a small job, but it is not /that/ bad.  In  
the Linux world, the great majority of code works fine on a range of  
32-bit and 64-bit targets, big-endian and little-endian, with little  
more than a re-compile with the right gcc version (perhaps with a  
./configure first).  And of course, code in Java, Javascript, Python,  
Lua, HTML5, etc., is all independent from from the target cpu anyway.

Quoted text here. Click to load it

MIPS certainly still exists, and is used in a fair number of devices.  
But MIPS make cores that are at least as good as ARM cores in many  
areas, with cores that would be ideal on microcontrollers.  But the only  
off-the-shelf microcontrollers you can get with MIPS cores are the PIC32  
- a device which was launched long before it was working, had  
intentionally crippled development tools, and a name designed to invoke  
terror in any software developer.  IMHO, that greatly reduced MIPS  
chances of being a significant player in the microcontroller market, and  
I find that a great shame.

Quoted text here. Click to load it

The ISA is royalty free, but as far as I know there is nothing to stop  
you charging for a particular implementation (either as HDL source code,  
pre-generated macros, silicon, or whatever).



Re: RISC-V Support in FPGA
On Tue, 02 May 2017 22:10:30 +0200, David Brown wrote:

Quoted text here. Click to load it


If there's a value to the royalty-freeness it'll be in the wide usage,  
and the fact that manufacturers won't have to screw around with the legal  
issues.

If it ever came to it that ARM was losing out to RISC-V implementations,  
I could see them taking their considerable ARM-spertise and applying it  
to RISC-V-compatible cores.

--  

Tim Wescott
Wescott Design Services
We've slightly trimmed the long signature. Click to see the full one.
Re: RISC-V Support in FPGA
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

I know it's not trivial to port to a new processor, but if there are saving
s to be had, even small ones, there is no loyalty that will keep somebody s
tuck to ARM.  Apple switched processors after decades in the business and i
t didn't seem to affect business too much.  I think people are conflating u
biquity with monopoly.  But people can switch, and as cellphone (for exampl
e) margins erode, this is one of the places where savings might be eked out
.

Re: RISC-V Support in FPGA
On 5/2/2017 2:12 PM, Kevin Neilson wrote:
Quoted text here. Click to load it

I don't doubt that for a minute.  It would be a business driven decision  
and both the cost and the benefit would be considered.


Quoted text here. Click to load it

The issue is not how it would "affect business" since there should only  
be benefits business-wise, otherwise why switch?  The issue is the cost  
of switching.


Quoted text here. Click to load it

Yep.

--  

Rick C

Re: RISC-V Support in FPGA
Den tirsdag den 2. maj 2017 kl. 02.15.05 UTC+2 skrev Rob Gaddi:
Quoted text here. Click to load it

I'm also sure that ARM has a crap ton of patents  


Re: RISC-V Support in FPGA
On 05/01/2017 04:07 PM, Kevin Neilson wrote:
Quoted text here. Click to load it

The probably have a pretty good revenue stream. I don't remember what  
they get per processor instance, but pretty much all the major  
semiconductor houses, and several of the fabless ones are shipping  
products with ARM processors in them. They are showing up in all kinds  
of ASICs as well.

Also, coding a synthesizable, 32 bit processor is only the beginning.  
Verifying it, implementing a silicon validation suite, getting compiler  
and debugger support and getting all of that stable and accepted are  
pretty big tasks. ARM has been at this project for a LONG time (early to  
mid 90's that I know of, maybe longer). That's a lot of customer experience.

Having a uniform (fairly, anyway) ecosystem on multiple vendors is worth  
some to me. I like that the I/O, Interrupt, power control and clock  
generation stuff is at least recognizable from vendor to vendor.

I can't say whether it is all worth $32B, but I guess it was to somebody...

BobH

Site Timeline