Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 159950

Article: 159950
Subject: Re: RISC-V Support in FPGA
From: john <anon@example.com>
Date: Tue, 2 May 2017 11:56:05 +0100
Links: << >>  << T >>  << A >>
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/ 

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

Article: 159951
Subject: Re: RISC-V Support in FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 2 May 2017 11:15:21 -0400
Links: << >>  << T >>  << A >>
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

Article: 159952
Subject: Re: RISC-V Support in FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 2 May 2017 11:24:10 -0400
Links: << >>  << T >>  << A >>
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

Article: 159953
Subject: Re: RISC-V Support in FPGA
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 02 May 2017 10:52:03 -0500
Links: << >>  << T >>  << A >>
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

Article: 159954
Subject: Re: RISC-V Support in FPGA
From: "Robert F. Jarnot" <Robert.F.Jarnot@jpl.nasa.gov>
Date: Tue, 2 May 2017 08:59:10 -0700
Links: << >>  << T >>  << A >>
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.
>


Article: 159955
Subject: Re: RISC-V Support in FPGA
From: kristoff <kristoff@skypro.be>
Date: Tue, 2 May 2017 18:11:22 +0200
Links: << >>  << T >>  << A >>
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.


Article: 159956
Subject: Re: RISC-V Support in FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 2 May 2017 12:27:15 -0400
Links: << >>  << T >>  << A >>
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

Article: 159957
Subject: Re: RISC-V Support in FPGA
From: gtwrek@sonic.net (Mark Curry)
Date: Tue, 2 May 2017 16:47:41 -0000 (UTC)
Links: << >>  << T >>  << A >>
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



Article: 159958
Subject: Re: RISC-V Support in FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 2 May 2017 12:55:15 -0400
Links: << >>  << T >>  << A >>
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

Article: 159959
Subject: Re: RISC-V Support in FPGA
From: Cecil Bayona <cbayona@cbayona.com>
Date: Tue, 2 May 2017 13:03:39 -0500
Links: << >>  << T >>  << A >>
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

Article: 159960
Subject: Re: RISC-V Support in FPGA
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 2 May 2017 11:12:21 -0700 (PDT)
Links: << >>  << T >>  << A >>
> I probably have 20 lines of ARM assembly written, and in retrospect that=
=20
> could just as well be carefully-crafted C.  Assuming that FreeRTOS makes=
=20
> a port, everything else is C or C++, and could just be compiled for the=
=20
> new target.
>=20
> I don't know about the cell phone companies -- are they really that=20
> heavily invested in processor-specific stuff?

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

Article: 159961
Subject: Re: RISC-V Support in FPGA
From: lasselangwadtchristensen@gmail.com
Date: Tue, 2 May 2017 12:48:14 -0700 (PDT)
Links: << >>  << T >>  << A >>
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 


Article: 159962
Subject: Re: RISC-V Support in FPGA
From: David Brown <david.brown@hesbynett.no>
Date: Tue, 2 May 2017 22:10:30 +0200
Links: << >>  << T >>  << A >>
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).



Article: 159963
Subject: Re: RISC-V Support in FPGA
From: Tim Wescott <seemywebsite@myfooter.really>
Date: Tue, 02 May 2017 15:22:46 -0500
Links: << >>  << T >>  << A >>
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!

Article: 159964
Subject: Re: RISC-V Support in FPGA
From: Theo Markettos <theom+news@chiark.greenend.org.uk>
Date: 02 May 2017 22:20:39 +0100 (BST)
Links: << >>  << T >>  << A >>
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

Article: 159965
Subject: Re: RISC-V Support in FPGA
From: "Robert F. Jarnot" <Robert.F.Jarnot@jpl.nasa.gov>
Date: Tue, 2 May 2017 14:24:40 -0700
Links: << >>  << T >>  << A >>
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:
> 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.
>


Article: 159966
Subject: Re: RISC-V Support in FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 2 May 2017 17:34:54 -0400
Links: << >>  << T >>  << A >>
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

Article: 159967
Subject: Re: RISC-V Support in FPGA
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Tue, 2 May 2017 14:52:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
> 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 happ=
y
> to fix things if there's any issues.
>=20
> 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 ag=
o when I was only using Synplify, but now I write cores that have to work i=
n a broad range of synthesizers which sadly don't even accept many Verilog-=
2005 constructs.

Article: 159968
Subject: Re: RISC-V Support in FPGA
From: rickman <gnuarm@gmail.com>
Date: Tue, 2 May 2017 22:36:58 -0400
Links: << >>  << T >>  << A >>
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

Article: 159969
Subject: Re: RISC-V Support in FPGA
From: gtwrek@sonic.net (Mark Curry)
Date: Wed, 3 May 2017 15:22:53 -0000 (UTC)
Links: << >>  << T >>  << A >>
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

Article: 159970
Subject: Re: RISC-V Support in FPGA
From: rickman <gnuarm@gmail.com>
Date: Wed, 3 May 2017 12:47:49 -0400
Links: << >>  << T >>  << A >>
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

Article: 159971
Subject: Re: RISC-V Support in FPGA
From: gtwrek@sonic.net (Mark Curry)
Date: Wed, 3 May 2017 17:59:18 -0000 (UTC)
Links: << >>  << T >>  << A >>
In article <oed1dk$a7b$2@dont-email.me>, rickman  <gnuarm@gmail.com> wrote:
>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 - I was speaking of Synthesizer support within FPGA tools only.

Simulation support depends entirely on your vendor, and is an entirely 
different beast.  We've been happy with Modelsim for all our SystemVerilog
simulations - for many years.  Can't comment much on other simulation 
vendors, and their support.  I've not used VCS, or NCSIM (or whatever 
they're now called) in many years.  Never tried Xilinx "free" simulators,
but for "free" I'd expect you'd get what you pay for.

I'll not wade any deeper into language wars - use what you're most
comfortable with.  Doesn't hurt to have experience with both.

Regards,

Mark

Article: 159972
Subject: Re: RISC-V Support in FPGA
From: Kevin Neilson <kevin.neilson@xilinx.com>
Date: Wed, 3 May 2017 11:22:54 -0700 (PDT)
Links: << >>  << T >>  << A >>
> Rick - yeah, it's pathetic.  The synthesizable subset of SystemVerilog wa=
s=20
> actually fairly concretely defined in the SystemVerilog 3.1 draft, in 200=
5. =20
> We're just now - 12 years later really finding an acceptable solution for=
=20
> FPGA designs.  To repeat myself - It's really pathetic.

In my case, I mostly write for Vivado, but I have to write code which will =
also work for some ASIC synthesis tools which don't like anything too moder=
n.  I'm not sure why; I just know I have to keep to a low common denominato=
r.

Anyway, and this is a different topic altogether, I've reverted to writing =
very low-level code for Vivado.  I've given up the dream of parameterizable=
 HDL.  I do a lot of Galois Field arithmetic and I put all my parameterizat=
ion in Matlab and generate Verilog include files (mostly long parameters) f=
rom that.  The Verilog then looks about as understandable as assembly and I=
 hate doing it but I have to.  It's the same thing I was doing over ten yea=
rs ago with Perl but now do with Matlab.  Often Vivado will synthesize the =
high-level version with functions and nested loops, but it is an order of m=
agnitude slower (synthesis time) than the very low-level version.  And some=
times it doesn't synthesize how I like.  I've just given up on high-level s=
ynthesizable code.

Article: 159973
Subject: Lattice ECP5 succesor ( with DDR4 phy) ?
From: Brane2 <brankob@avtomatika.com>
Date: Wed, 3 May 2017 12:04:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
AFAIK ECP5 is good for interfacing with DDR3, but not DDR4.

Is there a plan to introduce new members with DDR4 or perhaps new family with such interface ?

Article: 159974
Subject: Re: RISC-V Support in FPGA
From: gtwrek@sonic.net (Mark Curry)
Date: Wed, 3 May 2017 19:52:57 -0000 (UTC)
Links: << >>  << T >>  << A >>
In article <e4a7957e-c42e-4846-b8ab-ebcf170238dd@googlegroups.com>,
Kevin Neilson  <kevin.neilson@xilinx.com> wrote:
>> 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.
>
>In my case, I mostly write for Vivado, but I have to write code which will also work for some ASIC synthesis tools which don't like anything too
>modern.  I'm not sure why; I just know I have to keep to a low common denominator.
>
>Anyway, and this is a different topic altogether, I've reverted to writing very low-level code for Vivado.  I've given up the dream of
>parameterizable HDL.  I do a lot of Galois Field arithmetic and I put all my parameterization in Matlab and generate Verilog include files (mostly
>long parameters) from that.  The Verilog then looks about as understandable as assembly and I hate doing it but I have to.  It's the same thing I
>was doing over ten years ago with Perl but now do with Matlab.  Often Vivado will synthesize the high-level version with functions and nested loops,
>but it is an order of magnitude slower (synthesis time) than the very low-level version.  And sometimes it doesn't synthesize how I like.  I've just
>given up on high-level synthesizable code.

(continuing a bit OT...)

Kevin,

That's unfortunate.  We've been very successful with writing parameterizable code - even 
before SystemVerilog. Heck even before Verilog-2001.  Things like N-Tap FIRs, 
Two-D FIRs.  FFTs, Video Blenders, etc...  All with configurable settings - 
bit widths, rounding/truncation options/etc..  I think in a previous job I had a 
parametizable Galois Field Multiplier too.

I'm not sure what trouble you had with the tools.  It takes a bit more up front work,
but pays off quite a bit in the end.  We really had no choice, given the number of 
FPGAs we do, along with how many engineers support them.  Lot's of shared code
was the only way to go. 

If you've got something you like, then I suggest keeping it.  But for others,
I think writing parameterizable HDL isn't too much trouble - and is made
even easier with SystemVerilog.  And higher level too.

Regards,

Mark




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search