RISC-V Support in FPGA

In article <ad71c774-1170-49c3-bd93-efc4a2d63c99@googlegroups.com>, 
kevin.neilson@xilinx.com says...
> 
> > I don't know how small the RISC-V can be made.  I know there is a 
> > version designed in an ASIC that can compete with the ARM CPUs and there 
> > are more than one version for FPGAs.  I would hope they had a version 
> > similar to the ARM CM-1 which is specifically targeted to programmable 
> > logic and not overly large.  
> 
> Speaking of ARM, I still can't figure out how ARM was acquired for $32B.  If 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 know there is a lot of value in prediction pipelines, cache logic, compilers, etc., but not $32b' worth. 

They didn't buy ARM so much as  they bought a concept with a business model 
that many companies had foolishly signed up to accept - that's where the 
valuation comes from. The actual commodity - like those of pyramid schemes - 
(which is what IP is effectively) - is mostly irrelevant. 

and  yes - a student can design  "A processor" - but one that fulfills a market need 
that "significantly"  (and underlined)    moves the market forward adding value
in power, performance, size, manufacturability and so on - is not so easy to do.

(Trust me - I'm working on ideas myself - it's not trivial at all)

-- 

john

=========================
http://johntech.co.uk

"Bleeding Edge Forum"
http://johntech.co.uk/forum/ 

=========================

On 5/2/2017 6:56 AM, john wrote:
> In article <ad71c774-1170-49c3-bd93-efc4a2d63c99@googlegroups.com>,
> kevin.neilson@xilinx.com says...
>>
>>> I don't know how small the RISC-V can be made.  I know there is a
>>> version designed in an ASIC that can compete with the ARM CPUs and there
>>> are more than one version for FPGAs.  I would hope they had a version
>>> similar to the ARM CM-1 which is specifically targeted to programmable
>>> logic and not overly large.
>>
>> Speaking of ARM, I still can't figure out how ARM was acquired for $32B.  If 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 know there is a lot of value in prediction pipelines, cache logic, compilers, etc., but not $32b' worth.
>
> They didn't buy ARM so much as  they bought a concept with a business model
> that many companies had foolishly signed up to accept - that's where the
> valuation comes from. The actual commodity - like those of pyramid schemes -
> (which is what IP is effectively) - is mostly irrelevant.

Yes, those "many companies" are crying all the way to the bank.

The pyramid is at the basis of most business models.  It's a great idea 
actually and everyone participates voluntarily.


> and  yes - a student can design  "A processor" - but one that fulfills a market need
> that "significantly"  (and underlined)    moves the market forward adding value
> in power, performance, size, manufacturability and so on - is not so easy to do.
>
> (Trust me - I'm working on ideas myself - it's not trivial at all)

Any yet, ARM seems to be doing very well adding value for all the chip 
makers.

-- 

Rick C

On 5/2/2017 3:12 AM, David Brown wrote:
>
> 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.

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.


> 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).

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

On Tue, 02 May 2017 11:24:10 -0400, rickman wrote:

> On 5/2/2017 3:12 AM, David Brown wrote:
>>
>> 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.
> 
> 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.

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
I'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

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:
> On 5/1/2017 11:45 AM, Robert F. Jarnot wrote:
>> Pretty small (and fast):
>> https://forums.xilinx.com/t5/Xcell-Daily-Blog/1680-open-source-ISA-RISC-V-processor-cores-run-on-one-Virtex/ba-p/742731
>>
>
> 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.
>

Theo, all,



On 30-04-17 23:41, Theo Markettos wrote:
> For those who are confused, RISC-V is not a *processor*, it's an
> *architecture*.

I agree, but I would not call risc-v (the ISA) "open source". It is an 
open standard.

Two added advantages are (I think)
- that it is free of patents (so everybody can implement it)
- it is designed to be extensible from the ground up.


> Anyone can come up with a microarchitectural implementation of the
> architecture - that's the point of an open source ISA.  Being open-source
> you can also change the architecture - but it's then your problem to
> maintain the OS/compiler/etc for your fork of the architecture.

Well, what sets is appart from most (if not all) other ISAs is that 
risc-v is *designed* to be extensible.

This is not only about the official "M, A, F, D, Q, C, P" extensions. 
Everybody can just extend the ISA with their own "optimised for my 
application" instrictions.

Concidering one of the core members of the risc-v concortium: NVIDIA. 
This means that they are able to take the risc-v ISA and extend it (e.g. 
for GPU or passive-parrallel related technologies) and sell chips based 
on a "RISC-V + NVIDIA" ISA.


The only thing that is not clear for me is if they can still call this 
"risc-v", or what would be the correct naming for this kind of "extended 
ISA".



> Berkeley happen to have some of their own implementations that they have
> also open sourced.  These might or might not suit your purposes.  Being in
> Chisel is one thing that's not everyone's cup of tea.
> But the idea is that everyone has an architectural licence, so they are free
> to come up with their own implementations, and share them.  I suspect that
> Microsemi have done their own, rather than importing the Berkeley cores, for
> instance.


I would like to point out that the ISA does not mandate that a 
implementation needs to be open-source or that you need share it.


It is completely free for a company to come up with their closed-source 
implementation of the ISA standard and sell it, either as silicon or as 
a service.

Or, you can "mix-match" licenses. Sifive (the company that sells the 
E310 CPU and hifive devboards) are an interesting example of this.
They open-sourced the RTL design but keep the knowledge of actually 
implementing a risc-v core as optimised as possible for themselfs, as a 
service to sell.



I would put it like this:
What Risc-v does is, by removing the need of licensing the basic ISA, 
that it allows companies to come up with services they want to sell, 
without being limited by a license to somebody else who has its own 
commercial agenda.


Althou risc-v is usually equated with "open source", I think it is more 
then just that.



> Theo
Cheerio! Kr. Bonne.

On 5/2/2017 11:52 AM, Tim Wescott wrote:
> On Tue, 02 May 2017 11:24:10 -0400, rickman wrote:
>
>> On 5/2/2017 3:12 AM, David Brown wrote:
>>>
>>> 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.
>>
>> 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.
>
> 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.

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

In article <0dda8652-49f2-4402-b88d-7650875bfc51@googlegroups.com>,
Kevin Neilson  <kevin.neilson@xilinx.com> wrote:
>
>> A basic RV32I (the minimal 32 bit user-mode instruction set) is very simple.
>> Here's one that's about 400 lines of SystemVerilog, that was designed by a
>> student over a few weeks as a summer project:
>> 
>> https://github.com/ucam-comparch/clarvi
>> 
>> Theo
>
>The code looks pretty clear at first glance.  I see a lot of SystemVerilog 
>constructs that don't look synthesizer-friendly, though.

I gave it a quick glance.  It all looks synthesizable to me.  We've used
SystemVerilog in both Vivado, and Synplify, and I think the code should 
work fine.  YMMV.

Regards,

Mark

On 5/2/2017 11:59 AM, Robert F. Jarnot wrote:
> 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/

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

On 5/2/2017 10:24 AM, rickman wrote:

> 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.
> 

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