RISC-V Support in FPGA

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

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

Den tirsdag den 2. maj 2017 kl. 02.15.05 UTC+2 skrev Rob Gaddi:
> On 05/01/2017 04:46 PM, Tim Wescott wrote:
> > On Mon, 01 May 2017 16:07:02 -0700, Kevin Neilson wrote:
> >
> >>> 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.
> >
> > 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.
> >
> 
> 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.
> 

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

On 02/05/17 17:24, 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.

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.

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

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.

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

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

On Tue, 02 May 2017 22:10:30 +0200, David Brown wrote:

> On 02/05/17 17:24, rickman wrote:

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

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
http://www.wescottdesign.com

I'm looking for work -- see my website!

Mark Curry <gtwrek@sonic.net> wrote:
> 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.

A primary motivation was to teach SystemVerilog to undergrads - rather than
teach them lowest-common-denominator Verilog that's universally accepted by
tools but is pretty tedious as a learning environment.

We tested it pretty extensively with Modelsim and Intel FPGA tools; we
didn't have enough summer to put it through Xilinx or ASIC tools but happy
to fix things if there's any issues.

Theo

On 5/2/2017 2:12 PM, Kevin Neilson wrote:
>> 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?
>
> I know it's not trivial to port to a new processor, but if there are
> savings to be had, even small ones, there is no loyalty that will
> keep somebody stuck to ARM.

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.


> Apple switched processors after decades
> in the business and it didn't seem to affect business too much.

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.


> I
> think people are conflating ubiquity with monopoly.  But people can
> switch, and as cellphone (for example) margins erode, this is one of
> the places where savings might be eked out.

Yep.

-- 

Rick C

> We tested it pretty extensively with Modelsim and Intel FPGA tools; we
> didn't have enough summer to put it through Xilinx or ASIC tools but happy
> to fix things if there's any issues.
> 
> Theo

At first glance I thought I'd seen some object-oriented stuff in there but it was just structs.  I actually used a lot of SystemVerilog a few years ago when I was only using Synplify, but now I write cores that have to work in a broad range of synthesizers which sadly don't even accept many Verilog-2005 constructs.

On 5/2/2017 5:52 PM, Kevin Neilson wrote:
>> We tested it pretty extensively with Modelsim and Intel FPGA tools; we
>> didn't have enough summer to put it through Xilinx or ASIC tools but happy
>> to fix things if there's any issues.
>>
>> Theo
>
> At first glance I thought I'd seen some object-oriented stuff in there but it was just structs.  I actually used a lot of SystemVerilog a few years ago when I was only using Synplify, but now I write cores that have to work in a broad range of synthesizers which sadly don't even accept many Verilog-2005 constructs.

I wonder what is behind that.  Much of VHDL-2008 is supported in most 
tools, at least all the good stuff.  I believe the Xilinx tools don't 
include 2008, but I haven't tried it.  Otherwise I'm told the third 
party vendors support it and the Lattice tools I've used do a nice job 
of it.

I can't understand a vendor being so behind the times.

-- 

Rick C

In article <oebfia$o4a$2@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>On 5/2/2017 5:52 PM, Kevin Neilson wrote:
>>> We tested it pretty extensively with Modelsim and Intel FPGA tools; we
>>> didn't have enough summer to put it through Xilinx or ASIC tools but happy
>>> to fix things if there's any issues.
>>>
>>> Theo
>>
>> At first glance I thought I'd seen some object-oriented stuff in there but it was just structs.  I actually used a lot of SystemVerilog a few
>years ago when I was only using Synplify, but now I write cores that have to work in a broad range of synthesizers which sadly don't even accept
>many Verilog-2005 constructs.
>
>I wonder what is behind that.  Much of VHDL-2008 is supported in most 
>tools, at least all the good stuff.  I believe the Xilinx tools don't 
>include 2008, but I haven't tried it.  Otherwise I'm told the third 
>party vendors support it and the Lattice tools I've used do a nice job 
>of it.
>
>I can't understand a vendor being so behind the times.

Rick - yeah, it's pathetic.  The synthesizable subset of SystemVerilog was 
actually fairly concretely defined in the SystemVerilog 3.1 draft, in 2005.  
We're just now - 12 years later really finding an acceptable solution for 
FPGA designs.  To repeat myself - It's really pathetic.

Vivado seems to actually have BETTER language support for SystemVerilog than 
Synplify - believe it or not.  But this only works so far until you hit some 
sort of corner case and the tool spits out a netlist which doesn't match the 
RTL.  (We've hit too many of those issues in the past 2-3 years).  

Synplify, on the other hand barfs on perfectly acceptable, synthesizable code 
(i.e. SystemVerilog features that already have parallels in VHDL).  But 
Synplify has never (for us) produced a netlist which doesn't match RTL...

Regards,

Mark

On 5/3/2017 11:22 AM, Mark Curry wrote:
> In article <oebfia$o4a$2@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>> On 5/2/2017 5:52 PM, Kevin Neilson wrote:
>>>> We tested it pretty extensively with Modelsim and Intel FPGA tools; we
>>>> didn't have enough summer to put it through Xilinx or ASIC tools but happy
>>>> to fix things if there's any issues.
>>>>
>>>> Theo
>>>
>>> At first glance I thought I'd seen some object-oriented stuff in there but it was just structs.  I actually used a lot of SystemVerilog a few
>> years ago when I was only using Synplify, but now I write cores that have to work in a broad range of synthesizers which sadly don't even accept
>> many Verilog-2005 constructs.
>>
>> I wonder what is behind that.  Much of VHDL-2008 is supported in most
>> tools, at least all the good stuff.  I believe the Xilinx tools don't
>> include 2008, but I haven't tried it.  Otherwise I'm told the third
>> party vendors support it and the Lattice tools I've used do a nice job
>> of it.
>>
>> I can't understand a vendor being so behind the times.
>
> Rick - yeah, it's pathetic.  The synthesizable subset of SystemVerilog was
> actually fairly concretely defined in the SystemVerilog 3.1 draft, in 2005.
> We're just now - 12 years later really finding an acceptable solution for
> FPGA designs.  To repeat myself - It's really pathetic.
>
> Vivado seems to actually have BETTER language support for SystemVerilog than
> Synplify - believe it or not.  But this only works so far until you hit some
> sort of corner case and the tool spits out a netlist which doesn't match the
> RTL.  (We've hit too many of those issues in the past 2-3 years).
>
> Synplify, on the other hand barfs on perfectly acceptable, synthesizable code
> (i.e. SystemVerilog features that already have parallels in VHDL).  But
> Synplify has never (for us) produced a netlist which doesn't match RTL...

Am I hearing a justification for staying with VHDL rather than learning 
Verilog as I've been intending for some time?  My understanding is that 
to write test benches like what VHDL can do it is useful to have 
SystemVerilog.  Or is this idea overblown?

-- 

Rick C