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
On 14/11/16 23:44, rickman wrote: > On 11/14/2016 8:00 AM, HT-Lab wrote: >> For those that haven't seen it: >> >> https://www.bloomberg.com/news/articles/2016-11-14/siemens-to-buy-mentor-graphics-of-the-u-s-for-4-5-billion >> >> >> >> Never thought Siemens would be interested in an EDA company. > > Personally, I'm not too worried about what happens with Mentor. I saw > their products when they were just getting started and have never used > any of them since. I guess I just don't have much need for expensive > commercial tools when I can use free tools from the chip vendors. But > then I don't work on large projects with multiple designers. > Just a small point regarding free tools. One of the main corporate developers of gcc, especially in the embedded world, is Code Sourcery. Several of the key gcc developers work there, and they are the main maintainers of embedded MIPS, PPC, embedded ARM (I think), as well as a number of lesser used architectures. And Code Sourcery is owned by Mentor these days. If a new owner of Mentor decided that contributing to free and open source software was no longer part of their business strategy, the impact on gcc (and related tools) would not be insignificant. Of course, I have no idea what Siemens would want to do with that part of Mentor - damaging it would certainly be a silly idea.Article: 159451
On 11/15/2016 1:30 AM, Tim Wescott wrote: > Tim Wescott <tim@seemywebsite.com> Wrote in message: >> On Mon, 14 Nov 2016 23:14:20 -0500, rickman wrote: >> >>> I have version 11.6 running on my laptop with Windows 8. For a workshop >>> tomorrow I need to update to version 11.7 service pack 2. I downloaded >>> the software and started to install it, but I can't get past the initial >>> directory creation. It actually makes the directory just fine, but the >>> tool then complains this is not a valid directory. >>> >>> I've tried using different locations and changed the directory name to >>> remove any special characters with no success. >>> >>> Any ideas? >> >> Dunno Windows much -- are you logged in as an administrator? Can't help >> you much more than that: my IT brain is at choir practice right now. >> >> -- >> 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 >> > > #1 son says you can right-click an executable, get a menu, and run > as administrator, but had nothing else in the way of stunning > cleverness. I found the problem. I was trying to install the service pack only. I thought the file was 11.7 *with* the service pack. It's all working now. -- Rick CArticle: 159452
On Tue, 15 Nov 2016 11:04:00 -0500, rickman wrote: > On 11/15/2016 1:30 AM, Tim Wescott wrote: >> Tim Wescott <tim@seemywebsite.com> Wrote in message: >>> On Mon, 14 Nov 2016 23:14:20 -0500, rickman wrote: >>> >>>> I have version 11.6 running on my laptop with Windows 8. For a >>>> workshop tomorrow I need to update to version 11.7 service pack 2. I >>>> downloaded the software and started to install it, but I can't get >>>> past the initial directory creation. It actually makes the directory >>>> just fine, but the tool then complains this is not a valid directory. >>>> >>>> I've tried using different locations and changed the directory name >>>> to remove any special characters with no success. >>>> >>>> Any ideas? >>> >>> Dunno Windows much -- are you logged in as an administrator? Can't >>> help you much more than that: my IT brain is at choir practice right >>> now. >>> >>> -- >>> 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 >>> >>> >> #1 son says you can right-click an executable, get a menu, and run >> as administrator, but had nothing else in the way of stunning >> cleverness. > > I found the problem. I was trying to install the service pack only. I > thought the file was 11.7 *with* the service pack. It's all working > now. Cool. I hope the workshop goes well! -- 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: 159453
On 11/15/2016 11:52 AM, Tim Wescott wrote: > On Tue, 15 Nov 2016 11:04:00 -0500, rickman wrote: > >> On 11/15/2016 1:30 AM, Tim Wescott wrote: >>> Tim Wescott <tim@seemywebsite.com> Wrote in message: >>>> On Mon, 14 Nov 2016 23:14:20 -0500, rickman wrote: >>>> >>>>> I have version 11.6 running on my laptop with Windows 8. For a >>>>> workshop tomorrow I need to update to version 11.7 service pack 2. I >>>>> downloaded the software and started to install it, but I can't get >>>>> past the initial directory creation. It actually makes the directory >>>>> just fine, but the tool then complains this is not a valid directory. >>>>> >>>>> I've tried using different locations and changed the directory name >>>>> to remove any special characters with no success. >>>>> >>>>> Any ideas? >>>> >>>> Dunno Windows much -- are you logged in as an administrator? Can't >>>> help you much more than that: my IT brain is at choir practice right >>>> now. >>>> >>>> -- >>>> 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 >>>> >>>> >>> #1 son says you can right-click an executable, get a menu, and run >>> as administrator, but had nothing else in the way of stunning >>> cleverness. >> >> I found the problem. I was trying to install the service pack only. I >> thought the file was 11.7 *with* the service pack. It's all working >> now. > > Cool. I hope the workshop goes well! Yes, it was one of the better workshops I've attended. They used a board with the Igloo2 on it and I wanted one with the SmartFusion2. I'm told I just need to get in touch with the Microsemi guy who left a bit early and I can get one. I just had a beer with a few of the guys and they are a pretty nice crowd. -- Rick CArticle: 159454
How can we do FPGA VHDL Verification faster and with better quality =E2=80= =93 at no extra cost? This is actually possible =E2=80=93 and with an average efficiency improvem= ent of 20 to 50% for medium to high complexity FPGAs. Less for data path or= iented designs and more for control or protocol oriented designs. At no ext= ra cost. All that is required is that you do your testbench development the same way= you do your design. Every single FPGA designer knows that a good top level= design architecture is critical. Most FPGA designers also know that a good= microarchitecture is at least as important for module design. It should th= us be obvious that a good architecture is also equally important for your t= estbench, but for some strange reason most testbenches do not have the same= good architecture as the design being verified. Most designers agree that the following are critical for an efficient devel= opment of a high quality design module: - Overview, Readability, Simplicity - Modifiability, Maintainability, Extendibility - Debuggability - Reusability So why should testbenches be any different, with on average the same time u= sage as the actual design? It should be obvious that these aspects are equally critical for testbench = development, but there has been no standard solution to build a good testbe= nch architecture =E2=80=93 until now =E2=80=93 when UVVM has been introduce= d as a free and open source solution to this challenge. See blog at EDACaf=C3=A9: http://www10.edacafe.com/blogs/aldec/2016/11/14/fpga-vhdl-verification-can-= we-do-this-faster-with-better-quality-at-no-extra-cost/ And please join the webinar tomorrow by registering at either of https://www.aldec.com/en/events/770 for presentation at 3pm CET https://www.aldec.com/en/events/771 for presentation at 11am PSTArticle: 159455
onsdag 16. november 2016 00.39.26 UTC+1 skrev rickman f=C3=B8lgende: > Yes, it was one of the better workshops I've attended. They used a=20 > board with the Igloo2 on it and I wanted one with the SmartFusion2. I'm= =20 > told I just need to get in touch with the Microsemi guy who left a bit=20 > early and I can get one. Was it Peter Trott giving the workshop, or are you in the US? I have created a product with sf2 and it is a very plesant chip to work wit= h.=20 >=20 > I just had a beer with a few of the guys and they are a pretty nice crowd= . >=20 You have to wait until you start submitting support cases until you jugde t= he crowd. I have never had any problems talking sensible to the guys at the= microsemi stand at exhibitions, but support come out of india, and that ma= y be a bit tedious. --=20 SvennArticle: 159456
On 11/16/2016 5:07 AM, Svenn Are Bjerkem wrote: > onsdag 16. november 2016 00.39.26 UTC+1 skrev rickman følgende: > >> Yes, it was one of the better workshops I've attended. They used a >> board with the Igloo2 on it and I wanted one with the >> SmartFusion2. I'm told I just need to get in touch with the >> Microsemi guy who left a bit early and I can get one. > > Was it Peter Trott giving the workshop, or are you in the US? > > I have created a product with sf2 and it is a very plesant chip to > work with. US. I have their cards, but I am terrible at remembering names. I don't recall a Peter Trott though. Mostly it was Future guys, the disti who sponsored the event. Brett Clark and Norm Palmer were two of the Microsemi guys. The presenter was... sorry, just can't remember. The reason why I went was because I have a SF2 board from Avnet which has some nice peripherals. But the documentation is not so good and there isn't much software other than the couple of exercises. I found out this is because Avnet is no longer a Microsemi disti. I've asked for a SF2 version of the board used in the workshop. The one they supplied was just an Igloo2 and not the SF2. >> I just had a beer with a few of the guys and they are a pretty nice >> crowd. >> > > You have to wait until you start submitting support cases until you > jugde the crowd. I have never had any problems talking sensible to > the guys at the microsemi stand at exhibitions, but support come out > of india, and that may be a bit tedious. Yeah, I got lots of that with Lattice. I'd ask for information and they would run me around rather than try to come up with an answer. The local FAE is the guy who gives me useful support. One answer I got allowed me to save around $2000 on the last build. -- Rick CArticle: 159457
On 11/15/2016 3:41 AM, David Brown wrote: > On 14/11/16 23:44, rickman wrote: >> On 11/14/2016 8:00 AM, HT-Lab wrote: >>> For those that haven't seen it: >>> >>> https://www.bloomberg.com/news/articles/2016-11-14/siemens-to-buy-mentor-graphics-of-the-u-s-for-4-5-billion >>> >>> >>> >>> Never thought Siemens would be interested in an EDA company. >> >> Personally, I'm not too worried about what happens with Mentor. I saw >> their products when they were just getting started and have never used >> any of them since. I guess I just don't have much need for expensive >> commercial tools when I can use free tools from the chip vendors. But >> then I don't work on large projects with multiple designers. >> > > Just a small point regarding free tools. One of the main corporate > developers of gcc, especially in the embedded world, is Code Sourcery. > Several of the key gcc developers work there, and they are the main > maintainers of embedded MIPS, PPC, embedded ARM (I think), as well as a > number of lesser used architectures. And Code Sourcery is owned by > Mentor these days. If a new owner of Mentor decided that contributing > to free and open source software was no longer part of their business > strategy, the impact on gcc (and related tools) would not be insignificant. > > Of course, I have no idea what Siemens would want to do with that part > of Mentor - damaging it would certainly be a silly idea. I seem to recall that was exactly what Oracle did with OpenOffice when they bought Sun. They were going to shut down any further development but later changed their mind. -- Rick CArticle: 159458
On 17/11/16 01:14, rickman wrote: > On 11/15/2016 3:41 AM, David Brown wrote: >> On 14/11/16 23:44, rickman wrote: >>> On 11/14/2016 8:00 AM, HT-Lab wrote: >>>> For those that haven't seen it: >>>> >>>> https://www.bloomberg.com/news/articles/2016-11-14/siemens-to-buy-mentor-graphics-of-the-u-s-for-4-5-billion >>>> >>>> >>>> >>>> >>>> Never thought Siemens would be interested in an EDA company. >>> >>> Personally, I'm not too worried about what happens with Mentor. I saw >>> their products when they were just getting started and have never used >>> any of them since. I guess I just don't have much need for expensive >>> commercial tools when I can use free tools from the chip vendors. But >>> then I don't work on large projects with multiple designers. >>> >> >> Just a small point regarding free tools. One of the main corporate >> developers of gcc, especially in the embedded world, is Code Sourcery. >> Several of the key gcc developers work there, and they are the main >> maintainers of embedded MIPS, PPC, embedded ARM (I think), as well as a >> number of lesser used architectures. And Code Sourcery is owned by >> Mentor these days. If a new owner of Mentor decided that contributing >> to free and open source software was no longer part of their business >> strategy, the impact on gcc (and related tools) would not be >> insignificant. >> >> Of course, I have no idea what Siemens would want to do with that part >> of Mentor - damaging it would certainly be a silly idea. > > I seem to recall that was exactly what Oracle did with OpenOffice when > they bought Sun. They were going to shut down any further development > but later changed their mind. > Oracle faffed around with OpenOffice so long after they bought it that everyone else involved in OpenOffice development started the LibreOffice project. (Remember, before Oracle bought Sun, most of the important OO development was already being done by outside groups.) Oracle were desperately trying to find a way to turn OO into money - but by totally misunderstanding the OO community, users and developers, they made it almost completely irrelevant. The only impact OpenOffice has now is to confuse people that don't understand the difference between OpenOffice and LibreOffice. There is no noticeable development of OO by either Oracle or anyone else. All the work is done by others, in the LibreOffice project. As far as I can tell, when Mentor bought CodeSourcery, they basically said "We'll take care of the business stuff - the sales, the marketing, the integration with other products, the contracts with cpu manufacturers for new ports, etc. You folks can continue with the technical stuff - developing gcc, making the IDE packages, the libraries, the documentation, the gcc project leadership and developer community management, etc. And you can continue with the same mixture of commercial work and work for the gcc community as you did before - we'll pay your salary just the same." My understanding is that the CodeSourcery folks were happy with that arrangement, and you only have to look at the number of posts from CodeSourcery addresses on the gcc mailing lists to see how much they contribute.Article: 159459
Does any of the current FPGA manufacturers have free tools that work under Linux? I know that Xilinx ISE used to, but that was about a decade ago. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!Article: 159460
On 2016-11-19, Tim Wescott <seemywebsite@myfooter.really> wrote: > Does any of the current FPGA manufacturers have free tools that work > under Linux? I know that Xilinx ISE used to, but that was about a decade > ago. > Microsemi does, but I have not tried them.Article: 159461
Wendell wrote: > On 2016-11-19, Tim Wescott <seemywebsite@myfooter.really> wrote: >> Does any of the current FPGA manufacturers have free tools that work >> under Linux? I know that Xilinx ISE used to, but that was about a decade >> ago. >> > Microsemi does, but I have not tried them. Xilinx ISE, Xilinx Vivado, and Altera Quartus all work under Linux. They can all be touchy about the exact Linux they're running under, which is why I've got them all walled off in VMs. Vivado I run under Ubuntu, Quartus on CentOS. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 159462
On 11/18/2016 8:05 PM, Tim Wescott wrote: > Does any of the current FPGA manufacturers have free tools that work > under Linux? I know that Xilinx ISE used to, but that was about a decade > ago. Yes -- Rick CArticle: 159463
I have Altera Quartus Prime (used to be II) on Ubuntu Linux 16.04 LTS. Lite version is free. Expect a very big installation (30+ GiB) if you install everything, e.g., SoC EDS. A smaller installation is possible, if you download and install from individual files. From Xilinx, the HLx free edition, should work, I think I last tested on Ubuntu Linux 15.10.Article: 159464
On 11/19/2016 2:46 AM, rickman wrote: > On 11/18/2016 8:05 PM, Tim Wescott wrote: >> Does any of the current FPGA manufacturers have free tools that work >> under Linux? I know that Xilinx ISE used to, but that was about a decade >> ago. > > Yes > Lattice Diamond software is available for Linux in a RPM package. I have not tried it but I will one of these days, the Linux I use as a training vehicle is Mint a derivative of Ubuntu which is Debian based and does not natively use RPM packages but I believe it has the capability to install RPM packages. -- Cecil - k5nwaArticle: 159465
Wendell <wendell@linuxfrog.mminc> wrote: > On 2016-11-19, Tim Wescott <seemywebsite@myfooter.really> wrote: >> Does any of the current FPGA manufacturers have free tools that work >> under Linux? I know that Xilinx ISE used to, but that was about a decade >> ago. >> > Microsemi does, but I have not tried them. > Libero SoC may need to have some motif library installed which is not in mainstream distros anymore. Also the patching program they use is not mainstream and seems only supported on redhat/centos. The development SDK called SoftConsole (eclipse) is in version 3.5 depending on some custom actel binary to download to the chip. I would say that it is still windows target, but linux may become viable. -- svennArticle: 159466
Here's an interesting synthesis result. I synthesized this with Vivado for Virtex-7: reg [68:0] x; reg x_neq_0; always@(posedge clk) x_neq_0 <= x!=0; // version 1 Then I rephrased the logic: reg [68:0] x; reg x_neq_0; always@(posedge clk) x_neq_0 <= |x; // version 2 These should be the same, right? Version 1 uses 23 3-input LUTs on the first level followed by a 23-long carry chain (6 CARRY4 blocks). This is twice as big as it should be. Version 2 is 3 levels of LUTs, 12 6-input LUTs on the first level, 15 total. Neither is optimal. What I really want is a combination, 12 6-input LUTs followed by 3 CARRY4s. This is supposed to be the era of high-level synthesis...Article: 159467
Tim Wescott wrote: > Does any of the current FPGA manufacturers have free tools that work > under Linux? I know that Xilinx ISE used to, but that was about a decade > ago. > Sure, I use ise 13 and 14 under Linux. Since I have a 64-bit Linux kernel, I could not get ise 10 to install directly in Linux, so I ended up putting it on a Windows virtual machine. I really didn't want to spend much time doing that to make one tiny change to a legacy project. Under the right Linux environment, ise 10 should work, too. (It used to.) JonArticle: 159468
On Sat, 19 Nov 2016 14:15:18 -0800, Kevin Neilson wrote: > Here's an interesting synthesis result. I synthesized this with Vivado > for Virtex-7: > > reg [68:0] x; > reg x_neq_0; > always@(posedge clk) x_neq_0 <= x!=0; // version 1 > > Then I rephrased the logic: > > reg [68:0] x; > reg x_neq_0; > always@(posedge clk) x_neq_0 <= |x; // version 2 > > These should be the same, right? > > Version 1 uses 23 3-input LUTs on the first level followed by a 23-long > carry chain (6 CARRY4 blocks). This is twice as big as it should be. > > Version 2 is 3 levels of LUTs, 12 6-input LUTs on the first level, 15 > total. > > Neither is optimal. What I really want is a combination, 12 6-input > LUTs followed by 3 CARRY4s. > > This is supposed to be the era of high-level synthesis... I'm not enough of an FPGA guy to make really deep comments, but this looks like the state of C compilers about 20 or so years ago. When I started coding in C one had to write the code with an eye to the assembly that the thing was spitting out. Now, if you've got a good optimizer (and the gnu C optimizer is better than I am on all but a very few of the processors I've worked with recently), you just express your intent and the compiler makes it happen most efficiently. Clearly, that's not yet the case, at least for that particular synthesis tool. It's a pity. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!Article: 159469
On 11/20/2016 5:43 PM, Tim Wescott wrote: > On Sat, 19 Nov 2016 14:15:18 -0800, Kevin Neilson wrote: > >> Here's an interesting synthesis result. I synthesized this with Vivado >> for Virtex-7: >> >> reg [68:0] x; >> reg x_neq_0; >> always@(posedge clk) x_neq_0 <= x!=0; // version 1 >> >> Then I rephrased the logic: >> >> reg [68:0] x; >> reg x_neq_0; >> always@(posedge clk) x_neq_0 <= |x; // version 2 >> >> These should be the same, right? >> >> Version 1 uses 23 3-input LUTs on the first level followed by a 23-long >> carry chain (6 CARRY4 blocks). This is twice as big as it should be. >> >> Version 2 is 3 levels of LUTs, 12 6-input LUTs on the first level, 15 >> total. >> >> Neither is optimal. What I really want is a combination, 12 6-input >> LUTs followed by 3 CARRY4s. >> >> This is supposed to be the era of high-level synthesis... > > I'm not enough of an FPGA guy to make really deep comments, but this > looks like the state of C compilers about 20 or so years ago. When I > started coding in C one had to write the code with an eye to the assembly > that the thing was spitting out. Now, if you've got a good optimizer > (and the gnu C optimizer is better than I am on all but a very few of the > processors I've worked with recently), you just express your intent and > the compiler makes it happen most efficiently. > > Clearly, that's not yet the case, at least for that particular synthesis > tool. It's a pity. 'tis true, ’tis pity, And pity ’tis ’tis true -- Rick CArticle: 159470
On 11/19/2016 02:05, Tim Wescott wrote: > Does any of the current FPGA manufacturers have free tools that work > under Linux? I know that Xilinx ISE used to, but that was about a decade > ago. Hi! For Lattice iCE40 FPGAs project IceStorm is definitely worth checking out: http://www.clifford.at/icestorm/ "The IceStorm flow (Yosys, Arachne-pnr, and IceStorm) is a fully open source Verilog-to-Bitstream flow for iCE40 FPGAs." It's demonstrated in the following presentations: A Free and Open Source Verilog-to-Bitstream Flow for iCE40 FPGAs http://www.clifford.at/papers/2015/icestorm-flow/ Verilog Synthesis and Formal Verification with Yosyshttp://www.clifford.at/papers/2016/yosys-synth-formal/ Formal Verification with Yosys-SMTBMC http://www.clifford.at/papers/2016/yosys-smtbmc/ More: "Open-Source Tools for FPGA Development" talk at this year's LinuxCon: http://events.linuxfoundation.org/sites/events/files/slides/lcj-2016.pdf https://www.youtube.com/watch?v=MI18Wk4gxA4 "Icarus Verilog & Friends" http://aggregate.org/EE480/slidesF16v1.pdf http://aggregate.org/EE480/verilog.html Best, MattArticle: 159471
On 20/11/16 22:43, Tim Wescott wrote: > On Sat, 19 Nov 2016 14:15:18 -0800, Kevin Neilson wrote: > >> Here's an interesting synthesis result. I synthesized this with Vivado >> for Virtex-7: >> >> reg [68:0] x; >> reg x_neq_0; >> always@(posedge clk) x_neq_0 <= x!=0; // version 1 >> >> Then I rephrased the logic: >> >> reg [68:0] x; >> reg x_neq_0; >> always@(posedge clk) x_neq_0 <= |x; // version 2 >> >> These should be the same, right? >> >> Version 1 uses 23 3-input LUTs on the first level followed by a 23-long >> carry chain (6 CARRY4 blocks). This is twice as big as it should be. >> >> Version 2 is 3 levels of LUTs, 12 6-input LUTs on the first level, 15 >> total. >> >> Neither is optimal. What I really want is a combination, 12 6-input >> LUTs followed by 3 CARRY4s. >> >> This is supposed to be the era of high-level synthesis... > > I'm not enough of an FPGA guy to make really deep comments, but this > looks like the state of C compilers about 20 or so years ago. When I > started coding in C one had to write the code with an eye to the assembly > that the thing was spitting out. Now, if you've got a good optimizer > (and the gnu C optimizer is better than I am on all but a very few of the > processors I've worked with recently), you just express your intent and > the compiler makes it happen most efficiently. > > Clearly, that's not yet the case, at least for that particular synthesis > tool. It's a pity. Of course sometimes you don't want optimisation. Consider, for example, bridging terms in an asynchronous circuit.Article: 159472
> I'm not enough of an FPGA guy to make really deep comments, but this > looks like the state of C compilers about 20 or so years ago. When I > started coding in C one had to write the code with an eye to the assembly > that the thing was spitting out. Now, if you've got a good optimizer > (and the gnu C optimizer is better than I am on all but a very few of the > processors I've worked with recently), you just express your intent and > the compiler makes it happen most efficiently. > I know! I often feel like I'm a software guy, but stuck in the 80s, poring over every line generated by the assembler to make sure it's optimized.Article: 159473
On Mon, 21 Nov 2016 10:07:41 +0000, Tom Gardner wrote: > On 20/11/16 22:43, Tim Wescott wrote: >> On Sat, 19 Nov 2016 14:15:18 -0800, Kevin Neilson wrote: >> >>> Here's an interesting synthesis result. I synthesized this with >>> Vivado for Virtex-7: >>> >>> reg [68:0] x; >>> reg x_neq_0; >>> always@(posedge clk) x_neq_0 <= x!=0; // version 1 >>> >>> Then I rephrased the logic: >>> >>> reg [68:0] x; >>> reg x_neq_0; >>> always@(posedge clk) x_neq_0 <= |x; // version 2 >>> >>> These should be the same, right? >>> >>> Version 1 uses 23 3-input LUTs on the first level followed by a >>> 23-long carry chain (6 CARRY4 blocks). This is twice as big as it >>> should be. >>> >>> Version 2 is 3 levels of LUTs, 12 6-input LUTs on the first level, 15 >>> total. >>> >>> Neither is optimal. What I really want is a combination, 12 6-input >>> LUTs followed by 3 CARRY4s. >>> >>> This is supposed to be the era of high-level synthesis... >> >> I'm not enough of an FPGA guy to make really deep comments, but this >> looks like the state of C compilers about 20 or so years ago. When I >> started coding in C one had to write the code with an eye to the >> assembly that the thing was spitting out. Now, if you've got a good >> optimizer (and the gnu C optimizer is better than I am on all but a >> very few of the processors I've worked with recently), you just express >> your intent and the compiler makes it happen most efficiently. >> >> Clearly, that's not yet the case, at least for that particular >> synthesis tool. It's a pity. > > Of course sometimes you don't want optimisation. Consider, for example, > bridging terms in an asynchronous circuit. OK. I give up -- what do you mean by "bridging terms"? In general, I would say that if this is an issue, then (as with the 'volatile' and 'mutable' keywords in C++), there should be a way in the language to express your intent to the synthesizer -- either a way to say "don't optimize this section", or a way to say "keep this signal no matter what", or a syntax that lets you lay down literal hardware, etc. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!Article: 159474
Tim Wescott wrote: > On Mon, 21 Nov 2016 10:07:41 +0000, Tom Gardner wrote: > >> On 20/11/16 22:43, Tim Wescott wrote: >>> On Sat, 19 Nov 2016 14:15:18 -0800, Kevin Neilson wrote: >>> >>>> Here's an interesting synthesis result. I synthesized this with >>>> Vivado for Virtex-7: >>>> >>>> reg [68:0] x; >>>> reg x_neq_0; >>>> always@(posedge clk) x_neq_0 <= x!=0; // version 1 >>>> >>>> Then I rephrased the logic: >>>> >>>> reg [68:0] x; >>>> reg x_neq_0; >>>> always@(posedge clk) x_neq_0 <= |x; // version 2 >>>> >>>> These should be the same, right? >>>> >>>> Version 1 uses 23 3-input LUTs on the first level followed by a >>>> 23-long carry chain (6 CARRY4 blocks). This is twice as big as it >>>> should be. >>>> >>>> Version 2 is 3 levels of LUTs, 12 6-input LUTs on the first level, 15 >>>> total. >>>> >>>> Neither is optimal. What I really want is a combination, 12 6-input >>>> LUTs followed by 3 CARRY4s. >>>> >>>> This is supposed to be the era of high-level synthesis... >>> I'm not enough of an FPGA guy to make really deep comments, but this >>> looks like the state of C compilers about 20 or so years ago. When I >>> started coding in C one had to write the code with an eye to the >>> assembly that the thing was spitting out. Now, if you've got a good >>> optimizer (and the gnu C optimizer is better than I am on all but a >>> very few of the processors I've worked with recently), you just express >>> your intent and the compiler makes it happen most efficiently. >>> >>> Clearly, that's not yet the case, at least for that particular >>> synthesis tool. It's a pity. >> Of course sometimes you don't want optimisation. Consider, for example, >> bridging terms in an asynchronous circuit. > > OK. I give up -- what do you mean by "bridging terms"? > > In general, I would say that if this is an issue, then (as with the > 'volatile' and 'mutable' keywords in C++), there should be a way in the > language to express your intent to the synthesizer -- either a way to say > "don't optimize this section", or a way to say "keep this signal no > matter what", or a syntax that lets you lay down literal hardware, etc. > Bridging terms refers to terms that cover transitions in an asynchronous sequential circuit. Xilinx tools specifically do not honor this sort of logic and it really has no business in their FPGA's. However, if you insist on generating asynchronous sequential logic in a Xilinx FPGA, you will need to instantiate LUTs to get the coverage you're looking for. -- Gabor
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