Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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 CArticle: 159952
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 CArticle: 159953
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.comArticle: 159954
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
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
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 CArticle: 159957
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, MarkArticle: 159958
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 CArticle: 159959
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 - k5nwaArticle: 159960
> 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
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 patentsArticle: 159962
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
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
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. TheoArticle: 159965
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
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 CArticle: 159967
> 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
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 CArticle: 159969
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, MarkArticle: 159970
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 CArticle: 159971
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, MarkArticle: 159972
> 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
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
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:
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