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
rupertlssmith@googlemail.com <rupertlssmith@googlemail.com> wrote: > I've googled about a bit, but not found the perfect answer yet. Does > anyone have any suggestions for reading material (paper or web), that > would serve as an introductory overview of FPGAs for non-technical > managers? Note that FPGAs don't "do" anything that can't be done in other ways, but they do make it faster and cheaper. To answer that question, you need to know what can be done in general with digital logic. But for a manager, cost and speed are important, and there is no easy way to answer those questions. > Something that gives a rough idea of what typically can and > cannot be achieved in hardware, and a sense of the difficulties and > effort required to do so. Thats probably a lot to ask, but if you know > of any good introductions, I would appreciate a link. Personally, I find the linear systolic array architecture very useful for FPGA implementation of algorithms. It isn't the only possibility, but, for the cases where it works, it results in nice, efficient, and scalable implementations. (For those who got this far, note that a $50 FPGA can be programmed in seconds, where an ASIC might cost millions of dollars and take years to be produced.)` -- glenArticle: 150426
I should add, in this case not really non-technicals. Ex-techies who have moved into management/BA roles. Smart people, not dummies. Just lacking in experience of FPGAs and coming from a software background. When I see a BA draw a box, label it FPGA, and start putting little boxes labelled with the names of software components in it, and alarm bell starts ringing. I need to provide them with some sort of context so they can begin to understand this technology more realistically.Article: 150427
rupertlssmith@googlemail.com <rupertlssmith@googlemail.com> wrote: > I should add, in this case not really non-technicals. Ex-techies who > have moved into management/BA roles. Smart people, not dummies. Just > lacking in experience of FPGAs and coming from a software background. Often a software background doesn't help much. Digital logic design is significantly different from software, and the implementation of algorithms is often very different. > When I see a BA draw a box, label it FPGA, and start putting little > boxes labelled with the names of software components in it, and alarm > bell starts ringing. I need to provide them with some sort of context > so they can begin to understand this technology more realistically. Well, you often have to start that way, but then you need someone that can answer the practical question. If you assume that every gate in an FPGA can be used to actually compute what needs to be computed, and can run at about 300MHz then you have an upper limit to what the FPGA can do. If the algorithm can be constructed using N bit fixed point arithmetic, then it isn't too hard to find the maximum amount of computation that can be done. Well, I am assuming that the goal is for a very computation intensive problem. If that isn't the case, then my comments might not apply. But the word "software" in your statement does bother me. There are people that believe that FPGAs are the solution to many software problem. In some cases they are, but it is easy to over generalize. -- glenArticle: 150428
In article <b8e5e93e-22af-47d3-b397-11db7cafa26e@s5g2000yqm.googlegroups.com>, Dennis Yurichev <dennis.yurichev@gmail.com> wrote: >There are another number primality tests exists, so the question is, >is there can be such primality test which is suitable for FPGA in such >way, when it will work much more effectively than =C9douard Lucas and >Derrick Henry Lehmer's primality test running on generic computer? The LL test already uses about as few multiplications as you can reasonably hope for. The inner loop of the primality test is a large FFT, which is the classic non-streaming task, done in double-precision floating point, which is another thing at which generic computers are significantly better than FPGAs. People have occasionally built a large FFT multiply (often a number-theoretic transform, since arithmetic mod 2^64-2^32+1 is rather easier to implement than double-precision FP) in FPGAs; they have to be big FPGAs, on a board with lots of attached DDR3 or QDR SRAM memory, and end up about as fast as a desktop PC at ten to fifty times the cost. Basically, Sandy Bridge or Phenom chips are an enormously cheaper source of multipliers and memory bandwidth than Xilinx. TomArticle: 150429
On Jan 20, 10:57=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > But the word "software" in your statement does > bother me. =A0There are people that believe that FPGAs are the > solution to many software problem. =A0In some cases they are, but > it is easy to over generalize. Yes, the software in question has one part that is CPU intensive, and fairly obviously parallelizable. It is also the most prominent CPU bottleneck. That should go on the FPGA. The rest of the software is quite bulky, and a lot of sequential logic. It could be run on a soft CPU on an FPGA, but I presume those might typically be programmed in C, and the existing software is not in C, so would require a port. The most obvious solution to me, is to keep 90% of the software as it already is, and just move the 10% parallel chunk to the FPGA, put it on a card that has a PCIe bus, and hope that the overhead of communicating over the bus doesn't eat away the performance advantage. I'm trying to collect together some good resources that would help managers from a software background get to grips with what an FPGA is, and understand what the advantages are. I've got plenty tech resources on the subject, and its a technical enough field that a manager is going to have to get to grips with some of the techie stuff. As I say, I'm looking for pointers to material on understanding where to draw the hardware/software line, how to estimate the size of a hardware project, and other issues not directly to do with the techie how-to side of things.Article: 150430
You wrote: > I'm looking for pointers to material on understanding where to draw > the hardware/software line, how to estimate the size of a hardware > project, and other issues not directly to do with the techie how-to > side of things. The hardware/software line and estimating hardware size are usually more ad= vanced topics that have to come from experience and domain knowledge - you'= ll be hard pressed to find high level resources on this. That is, I know ho= w to answer these questions for the area of products that I work on because= I work on those products. ChrisArticle: 150431
On Jan 20, 2:34=A0pm, Chris Maryan <kmar...@gmail.com> wrote: > The hardware/software line and estimating hardware size are usually more = advanced topics that have to come from experience and domain knowledge - yo= u'll be hard pressed to find high level resources on this. That is, I know = how to answer these questions for the area of products that I work on becau= se I work on those products. Fair enough, and I can see that you are right to say it comes from experience. In software there have been studies comparing programming effort using different systems. One notable example might be the study carried out by Erricson, before they developed Erlang, to try and demonstrate the programmers are more 'productive' using functional languages. Of course, these studies are fundamentally flawed in that to be scientific, they must measure things, and the things they try to measure are not easily or precisely quantifiable. Sometimes its fun look at the computer language shootout website, to try and get a feel for the conciseness versus performance of different languages solving the same problem. Looks like Python is very concise, but not very performant for example, so you might choose it to do rapid prototyping or rapid development of stuff where speed is not an issue. Have similar studies not been carried out in the field of hardware development, or am I just failing to find them?Article: 150432
On 01/20/2011 02:28 AM, glen herrmannsfeldt wrote: > rupertlssmith@googlemail.com<rupertlssmith@googlemail.com> wrote: > >> I've googled about a bit, but not found the perfect answer yet. Does >> anyone have any suggestions for reading material (paper or web), that >> would serve as an introductory overview of FPGAs for non-technical >> managers? > > Note that FPGAs don't "do" anything that can't be done in other > ways, but they do make it faster and cheaper. Or faster and way more expensive -- depending on what it is you're trying to do. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 150433
On 01/20/2011 02:11 AM, rupertlssmith@googlemail.com wrote: > Hi, > > I've googled about a bit, but not found the perfect answer yet. Does > anyone have any suggestions for reading material (paper or web), that > would serve as an introductory overview of FPGAs for non-technical > managers? Something that gives a rough idea of what typically can and > cannot be achieved in hardware, and a sense of the difficulties and > effort required to do so. Thats probably a lot to ask, but if you know > of any good introductions, I would appreciate a link. Find the Embedded.com website and take a look through their article data base. I know that articles on FPGA design crop up periodically in Embedded Systems Design*. They're at all sorts of different levels, so going through them may help you get an intuitive grasp. As stated, designing for an FPGA is a lot different from writing software. I do analog circuit design and embedded software quite well, but those two still don't give me the knowledge I need to write digital hardware descriptions that are competitive with even an average FPGA guy. * Why name a magazine for a silicon based industry "ESD"? -- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" was written for you. See details at http://www.wescottdesign.com/actfes/actfes.htmlArticle: 150434
> Have similar studies not been carried out in the field of hardware > development, or am I just failing to find them? I don't know if there have been studies, but your options are basically Ver= ilog or VHDL (there are a bunch of other options, including high level lang= uages, graphical flows, 'wizard' based flows, but they are extremely limit= ed and usually restricted to some tiny niche). The V vs V battle has been a= rgued to death and the applicability of one or the other generally boils do= wn to whether engineers in your area tend to know one or the other. There i= s for the most part no significant difference in the usability of one or th= e other. Once you've settled on VHDL or Verilog, the synthesis tools are al= l largely the same, as are the FPGA products from the big two FPGA vendors.= For every person that complains about brand A or brand X, there are others= who will sing their praises. If you are talking about studies of efficiency of developing in hardware vs= software, then this again becomes domain specific. ChrisArticle: 150435
rupertlssmith@googlemail.com <rupertlssmith@googlemail.com> wrote: > On Jan 20, 10:57 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> > wrote: >> But the word "software" in your statement does >> bother me. There are people that believe that FPGAs are the >> solution to many software problem. In some cases they are, but >> it is easy to over generalize. > Yes, the software in question has one part that is CPU intensive, and > fairly obviously parallelizable. It is also the most prominent CPU > bottleneck. That should go on the FPGA. > The rest of the software is quite bulky, and a lot of sequential > logic. It could be run on a soft CPU on an FPGA, but I presume those > might typically be programmed in C, and the existing software is not > in C, so would require a port. If it is really bulky, then it is probably best done as-is, and just the CPU intensive part moved. People have been working on those problems for about 20 years now. You might look at the proceedings from the FCCM (FPGAs for Custom Computing Machines) conference, which is one place that such devices have been discussed over the years. > The most obvious solution to me, is to keep 90% of the software as it > already is, and just move the 10% parallel chunk to the FPGA, put it > on a card that has a PCIe bus, and hope that the overhead of > communicating over the bus doesn't eat away the performance advantage. Yes, communication can be a problem. If you can put the interface in the place that minimizes the needed data transfer, that helps. Also, there are some that, for example, put the FPGA on the hypertransport bus to make things faster. > I'm trying to collect together some good resources that would help > managers from a software background get to grips with what an FPGA is, > and understand what the advantages are. I've got plenty tech resources > on the subject, and its a technical enough field that a manager is > going to have to get to grips with some of the techie stuff. You need someone who understands the problem domain, and the possible FPGA implementations. I have worked on the design of FPGA based search processors, and can pretty quickly tell you if a new idea makes sense or not. For other problem domains, I would not be able to do it quite as fast. > As I say, > I'm looking for pointers to material on understanding where to draw > the hardware/software line, how to estimate the size of a hardware > project, and other issues not directly to do with the techie how-to > side of things. Some of the more successful FPGA based accelerator products that I know about are produces by time-logic. You might look at what they have done. -- glenArticle: 150436
On Thu, 20 Jan 2011 09:40:15 -0800, Tim Wescott <tim@seemywebsite.com> wrote: >On 01/20/2011 02:28 AM, glen herrmannsfeldt wrote: >> rupertlssmith@googlemail.com<rupertlssmith@googlemail.com> wrote: >> >>> I've googled about a bit, but not found the perfect answer yet. Does >>> anyone have any suggestions for reading material (paper or web), that >>> would serve as an introductory overview of FPGAs for non-technical >>> managers? >> >> Note that FPGAs don't "do" anything that can't be done in other >> ways, but they do make it faster and cheaper. > >Or faster and way more expensive -- depending on what it is you're >trying to do. Or slower and more expensive; an FPGA is not the ideal device to implement a large fixed function design in large quantities. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.dspia.comArticle: 150437
On 20 Jan., 12:45, Thomas Womack <twom...@chiark.greenend.org.uk> wrote: > In article <b8e5e93e-22af-47d3-b397-11db7cafa...@s5g2000yqm.googlegroups.= com>, > Dennis Yurichev =A0<dennis.yuric...@gmail.com> wrote: > > >There are another number primality tests exists, so the question is, > >is there can be such primality test which is suitable for FPGA in such > >way, when it will work much more effectively than =3DC9douard Lucas and > >Derrick Henry Lehmer's primality test running on generic computer? > > The LL test already uses about as few multiplications as you can > reasonably hope for. > > The inner loop of the primality test is a large FFT, which is the > classic non-streaming task, done in double-precision floating point, > which is another thing at which generic computers are significantly > better than FPGAs. > > People have occasionally built a large FFT multiply (often a > number-theoretic transform, since arithmetic mod 2^64-2^32+1 is rather > easier to implement than double-precision FP) in FPGAs; they have to > be big FPGAs, on a board with lots of attached DDR3 or QDR SRAM > memory, and end up about as fast as a desktop PC at ten to fifty times > the cost. =A0 > > Basically, Sandy Bridge or Phenom chips are an enormously cheaper > source of multipliers and memory bandwidth than Xilinx. > > Tom Hi Tom, is there a reason why the algorithm uses floating point for the FFT calculation? Since the problem is the analysis of an integer number, this makes me wonder. Or is it just to make use of the FP-Coprocessor that is available in the CPU anyway, and has no mathematical reason? regards EilertArticle: 150438
Have a look at http://www.mathworks.com/ and search (top-right corner) with 'fpga' to get almost 900 leads for further reading. There are also high-level optimization war-stories on http://www.mathworks.com/solutions/ Regards / Cees On 01/20/2011 11:11 AM, rupertlssmith@googlemail.com wrote: > Hi, > > I've googled about a bit, but not found the perfect answer yet. Does > anyone have any suggestions for reading material (paper or web), that > would serve as an introductory overview of FPGAs for non-technical > managers? Something that gives a rough idea of what typically can and > cannot be achieved in hardware, and a sense of the difficulties and > effort required to do so. Thats probably a lot to ask, but if you know > of any good introductions, I would appreciate a link. > > Thanks for your help. > > RupertArticle: 150439
rickman <gnuarm@gmail.com> writes: > I'm curious, why are you using VHDL more now? Is this a job > requirement or do you prefer VHDL? Job requirement. Euroland is VHDLland too, with some exceptions. Usually means customer is somewhere else, like in North America or Asia. Even then, Verilog may be the result of autoconversion from VHDL... > Was there something about Verilog you didn't like? I liked it just fine for design. Didn't much care for writing testbenches in it. Most of my Verilog work was for telecom. For example, generating ATM cells and sending them to the design was just awful. Should've done it in Perl and put the data in a file. In fact, I did that for the received data. I'm not too keen on VHDL, but it gets the job done. I used to hate the strong typing and required conversions, but I guess I don't mind that much any more. Maybe it's influence from my recent interest in Python too.Article: 150440
On Jan 21, 10:04=A0am, Anssi Saari <a...@sci.fi> wrote: > rickman <gnu...@gmail.com> writes: > > I'm curious, why are you using VHDL more now? =A0Is this a job > > requirement or do you prefer VHDL? =A0 > > Job requirement. Euroland is VHDLland too, with some exceptions. > Usually means customer is somewhere else, like in North America or > Asia. Even then, Verilog may be the result of autoconversion from > VHDL... > > > Was there something about Verilog you didn't like? > > I liked it just fine for design. Didn't much care for writing > testbenches in it. Most of my Verilog work was for telecom. For > example, generating ATM cells and sending them to the design was just > awful. Should've done it in Perl and put the data in a file. In fact, > I did that for the received data. > > I'm not too keen on VHDL, but it gets the job done. I used to hate the > strong typing and required conversions, but I guess I don't mind that > much any more. Maybe it's influence from my recent interest in Python > too. That was the one place where I used Verilog in the past, at a telecom test equipment company. I'm near Washington, DC and a lot of the jobs around here are government. I was in a government contractor job when I learned HDL, so it was VHDL. Now I want to learn Verilog as well as I know VHDL and it is ticking me off a bit that I'm being told there are NO good text books in it. I've heard that Europe is very VHDL oriented. I have no idea what predominates in the far East. I'm curious about that. RickArticle: 150441
Anssi Saari <as@sci.fi> writes: >> Was there something about Verilog you didn't like? > > I liked it just fine for design. Didn't much care for writing > testbenches in it. Most of my Verilog work was for telecom. For I'm the opposite :-) VHDL is ok for design, but not for testbenches. SystemVerilog provides a much higher level of abstraction and features like assertions, covergroups, and randomize classes for making constraint random based testbenches. //PetterArticle: 150442
On Jan 20, 5:39 am, "rupertlssm...@googlemail.com" <rupertlssm...@googlemail.com> wrote: > I should add, in this case not really non-technicals. Ex-techies who > have moved into management/BA roles. Smart people, not dummies. Just > lacking in experience of FPGAs and coming from a software background. > > When I see a BA draw a box, label it FPGA, and start putting little > boxes labelled with the names of software components in it, and alarm > bell starts ringing. I need to provide them with some sort of context > so they can begin to understand this technology more realistically. What's a BA? I assume this is someone who doesn't really know anything about either software or hardware. I guess you have figured out by now that you won't find any reading material on this topic. As others have said, the tradeoffs depend greatly on the class of problem being solved. You said your existing code is not in C. I'm curious as to what language it is in. If it is a lot of code, it will likely be very expensive to port either to C or to hardware. What are your alternatives with this design? What are the BAs expecting to get out of using FPGAs in the design? Or do they not know enough to know what to expect, they just think FPGAs are magic? I am of the opinion that it is often easier to implement algorithms in FPGAs rather than software. Of course there is a limitation of size when implementing things in hardware (FPGAs) and you often will find hardware will be more effective if you use different organizations of the solution than what you might do in software. But I find the high degree of design visibility in a hardware simulation to far exceed what I get in a software simulation or emulation. I can see every detail of every signal. So if I can simulate the environment accurately, I can test my design in simulation to a high confidence level and rapidly debug problems. I believe you will find a wide range of opinions about where to draw that line. I am currently working on a small project that is basically a time of day clock with a fancy interface to a 100 MHz clock. Obviously the 100 MHz interface should be done in an FPGA... and a handful of PECL logic. The time of day clock logic is going to be done on a processor module called a Rabbit. I suggested that there is no reason that the entire project couldn't be done in the FPGA and I know this is very easy to do. But the engineer in charge is not so familiar with FPGAs and sees them as large PLDs to incorporate what you might have otherwise done with 7400 series chips if FPGAs weren't around. He knows enough to consider using an 8 bit embedded CPU in the FPGA, but even that is not needed. There is no reason at all to not implement the full solution in FPGA logic using FSM (finite state machines) and other functions that work equally well in both hardware and software. RickArticle: 150443
> (For those who got this far, note that a $50 FPGA can be programmed > in seconds, where an ASIC might cost millions of dollars and take > years to be produced.)` You certainly must agree that that's not a useful comparison. The development cost (time and wages) is roughly comparable for ASICs and FPGAs. Foundry costs for ASICs is where most of the cost will typically be. Add to that the extra expense of pre-foundry testing to ensure the first design works and you get a very pricey alternative to FPGAs. JJSArticle: 150444
John Speth <johnspeth@yahoo.com> wrote: >> (For those who got this far, note that a $50 FPGA can be programmed >> in seconds, where an ASIC might cost millions of dollars and take >> years to be produced.)` > You certainly must agree that that's not a useful comparison. > The development cost (time and wages) is roughly comparable for > ASICs and FPGAs. Well, you snipped out what came before, but, yes, the development time and costs that are about the same, and so is the design process. > Foundry costs for ASICs is where most of the cost will > typically be. Add to that the extra expense of pre-foundry > testing to ensure the first design works and you get a very > pricey alternative to FPGAs. Consider that I have one computer, and want to build a special purpose processor to speed up a computational task. I can do it with an FPGA fairly fast, or with an ASIC much more slowly and it will be more expensive. When I wrote that, I even considered dynamic reconfiguration (for the FPGA), and for the ASIC (with the fab time included). The partiton between hardware and software, the digital logic design, the speed of the resulting system, and the management required to do the design are about the same. Once the design is finished, you can, as I said, either load it into an FPGA or send it out to fab. -- glenArticle: 150445
On 01/21/2011 12:35 PM, John Speth wrote: >> (For those who got this far, note that a $50 FPGA can be programmed >> in seconds, where an ASIC might cost millions of dollars and take >> years to be produced.)` > > You certainly must agree that that's not a useful comparison. The > development cost (time and wages) is roughly comparable for ASICs and FPGAs. > Foundry costs for ASICs is where most of the cost will typically be. Add to > that the extra expense of pre-foundry testing to ensure the first design > works and you get a very pricey alternative to FPGAs. But, you can't ignore RISK! If an FPGA design doesn't work, it can be debugged, and unless some really fundamental design errors were made (not enough equivalent gates, speed too slow, etc. the design can be fixed, recompiled and retested, often within hours. If there is a serious flaw in an ASIC, it may not even be possible to test it far enough to know where the problem is. When your design is complete for an FPGA, testing can begin that day. With an ASIC, you send it to the foundry and wait possibly six months or more before you get the first part. JonArticle: 150446
It's very old and still a little technical but have a look at www.enterpoint.co.uk/seminar/Adding_Zest_To_Your_Electronics_With_Programma= ble_FPGA_Technology.pdf and see if that helps. There may be some new materials later this year. It's been a long time since we ran the last set but we are planning to run a new set of 1/2 day seminars and there will be materials for the manager level out of that. John Adair Enterpoint Ltd. On Jan 20, 10:11=A0am, "rupertlssm...@googlemail.com" <rupertlssm...@googlemail.com> wrote: > Hi, > > I've googled about a bit, but not found the perfect answer yet. Does > anyone have any suggestions for reading material (paper or web), that > would serve as an introductory overview of FPGAs for non-technical > managers? Something that gives a rough idea of what typically can and > cannot be achieved in hardware, and a sense of the difficulties and > effort required to do so. Thats probably a lot to ask, but if you know > of any good introductions, I would appreciate a link. > > Thanks for your help. > > RupertArticle: 150447
Brian Drummond <brian_drummond@btconnect.com> writes: > Change is probably inevitable, and maybe it's getting time for Usenet > to go the way of the morse amateur bands, and the telegraph. > > Sadly. > > - Brian Actually, signal to noise ratio is still a lot better here in Usenet newsgroups because it is quite easy to filter spam with bio-visual methods. It's a bit like morse - this is still quite alive despite the availability of Internet and other "modern" modes... 73, Frank DG1SBG (ham radio call from Germany)Article: 150448
http://www.eetimes.com/electronics-news/4212400/Xilinx-to-shutter-French-R-D-operation Yikes, this explains some stuff. I wonder how long it will take to undo the damage. Our latest projects are using Altera parts, purely because the Xilinx software is such a train wreck. JohnArticle: 150449
On Sat, 22 Jan 2011 18:20:55 -0800, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >http://www.eetimes.com/electronics-news/4212400/Xilinx-to-shutter-French-R-D-operation > >Yikes, this explains some stuff. I wonder how long it will take to >undo the damage. Damage? The damage caused by closing a software development lab? Given their software, it's probably a good thing. I just tried downloading their 12.4 software last week. It wouldn't even install. The Avnet folks got me a DVD, so I'll probably try that next week. >Our latest projects are using Altera parts, purely >because the Xilinx software is such a train wreck. I'm using a Xilinx Coolrunner part for a very simple application, mostly because they have package better suited to the application and our SMT line (small and not a CsBGA). ISE WebPack 11.1 works reasonably well but I'm not pushing it very hard (32 flops and a half dozen I/O @ 14.7456MHz clock isn't much of a stretch ;-).
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