6 ms·

I think the last paragraph is key: > We also need to revisit the approach of compiling a high-level language to VHDL/Verilog and then using vendor-specific syn

I think the last paragraph is key: > We also need to revisit the approach of compiling a high-level language to VHDL/Verilog and then using vendor-specific synthesis tools to generate bitstreams. If FPGA vendors open up FPGA architecture details, third parties could develop new tools that compile a high-level description directly to a bitstream without going through the intermediate step of generating VHDL/Verilog. This is attractive because current synthesis times are too long to be acceptable in the mainstream. This is both an ideological as well as a practical matter. Until the whole process INCLUDING bitstream generation is open, I don't see FPGAs as a viable alternative to general purpose processors.

DanWaterworth 14y ago
I can't up vote this enough. I keep gearing up to try using an FPGA, but ever time I do, I am prevented from continuing by my revulsion of closed source tools.
- VLM 14y ago
  I recently had to burn an old fashioned eprom using a non-legacy PC and found it impossible to find a USB connected linux compatible eprom burner. Yes if you have a parallel port on your laptop (not since 2003 or so?) there's the willem programmer. Yes there's a company in .de selling a USB burner with Ubuntu software but the shipping and handling to the states was kind of extreme. Why do they charge $75 or whatever it was from .de when Seeed studios charges approx nothing from .cn? So closed source problems are hardly limited solely to high tech FPGAs. Abandoning FPGAs doesn't mean you'll eliminate closed source from your life, it just means you'll eliminate FPGAs from your life... Also I suspect you do not have a copy of the firmware inside the microcontroller that runs your mouse, or your PC 8042 keyboard controller, or innumerable microcontrollers thru the machine, so either you are already OK with using "some" closed source or don't have a full picture of your whole system. Pessimism is your friend in this case and the situation is probably much worse than you think. I ALWAYS prioritize open source above all other criteria for obvious reasons, but when its not available I do my best with what I can get... Its an engineering background thing... Much as I'd love to ideally make everything outta aerospace carbon fiber and titanium, but lets face it, my house is made mostly outta wood and my car outta steel.
  - DanWaterworth 14y ago
    The difference is necessity. I need a computer for my work and it would be infeasible to use 100% open source hardware. I don't need to play with FPGAs, but I would really like to. Hence me continually coming back to it, even if I haven't made the leap yet.
    - VLM 14y ago
      "The difference is necessity." That has to be carefully defined. My point with the eprom anecdote was that you're stuck with closed source if you put a z80 core and some rom/ram/decode logic in a FPGA and do a synthetic SoC and merely avoiding FPGA and doin' it with discrete Z80 and eprom and sram and some glue isn't going to save you, because in 2013 using PC hardware you pretty much need a closed source windows only USB eprom programmer. So if you're stuck with closed source doing a hobby project, at least do something "cool" and use the FPGA. To do "about the same thing" but open source there are several completely open source alternatives that would result in CPU controlled I/O ports being wiggled. Avoiding closed source is not just as simple as saying "no FPGAs" or closed source is solely a disease of FPGAs. for example it took years as I recall before the Propeller had a non-windows/dos stack, although the BST works pretty well now. Confusing the issue, if you just want to play around with Verilog as a language or abstract technology, Icarus is free software part of the GnuEDA project. Obviously that's playing with simulation not silicon, but it is possible. So you don't have to entirely avoid FPGA technology.
  - AndresNavarro 14y ago
    There's a difference between a development environment and the code that runs in a random device... The problem is not just closed source software (which I don't like and try not to use) but a lack of documentation of the architecture and bitstream formats. I program for a living, but wouldn't for the life of me work with a closed source compiler for an unknown architecture with no/incomplete documentation. Many people may be ok with this though (see for example, some shader compilers for embedded GPUs). There's a reason processor manufactures release all info about instructions sets and that in turn allows a lot of projects like gcc, llvm, v8, luajit, etc. to support them. I would think that opening up the details of this technology would spur a lot of innovation regarding FPGAs and HDLs, both in academia and in the industry.
- DrDreams 14y ago
  Speaking as an embedded developer, I see a number of other embedded devs hobbying around with FPGAs. However, I very rarely see convincing use cases for FGPAs. This article seems to lean toward the belief many of my colleagues have, that FPGAs are right around the corner in terms of general usefulness. However, I disagree strongly. I find that they are highly-specialized devices. Before reading the rest of my writing, consider that at this time, brilliant hardware designers are putting similar amounts of work into both general purpose CPUs and into FPGAs. However, CPUS are comprised of dense blocks of special-purpose silicon for common purposes, such as floating-point math. FPGAs always have to match that dense silicon through configurable silicon, which is less dense. Furthermore, the routing in CPUs is a known entity at manufacturing time. On FPGAs, the routing is highly variable and must be re-negotiated at nearly every compile cycle. That's a huge time sink, both in terms of build time and in predicting performance. Especially since those short routes that you get at the beginning of a project, typically end up being longer by the end of it. Nowadays, we are seeing more FPGAs with dedicated, pre-made hardware blocks inside of them, such as FPUs and even CPU cores. These have more of a chance of catching on for general purpose computing. Notice however, that on these devices, it's the general-purpose CPU dominating, leaving the FPGA as a configurable peripheral, subordinate to the dense, pre-designed silicon. Although one may be able to match GPU performance with an FPGA, it's usually just not worth it. It will take dozens of hours of FPGA coding and simulation. Compiling and fitting and the rest of the FPGA dev chain is very time-consuming and resource-intensive, compared to the speed and elegance of gcc. Speaking of standard development practices, FPGA code is not nearly as portable as C. It often has special optimizations done for the sake of the device implemented. http://opencores.org http://opencores.org has a number of more generic modules available, but still, FPGA code does not scale as well as C code. There are add-on packages that help write FPGA synthesis code - code synthesizers, but they make matters especially complicated. The syntax of Verilog and VHDL is not well-designed for scaling. Speaking of these languages, if you are used to languages written to be parsed easily, such as lisp, python, or even C and Java to some extent, you will be very appalled at the structure of Verilog and VHDL. There are many redundant entities, lots of excess verbiage and all kinds of special cases. It really has evolved very little since the days of the Programmed Array of Logic (PAL). Another problem with FPGAs is the additional hardware on board needed to configure them. It's one more component or interface that is not needed when using CPUs. It's an additional software image to maintain, revision, store in source control, etc. FPGAs also often require more power supplies and better power supply conditioning than a regular CPU and often a separate clock crystal. They are high-maintenance. FPGAs do shine though in a few specific instances: 1. When there is a particular, uncommon high-speed bus protocol you need to communicate with and can not buy pre-designed silicon for. This does not mean, e.g. USB. It means something like a non-standard digital camera interface or embedded graphic display. 2. Software Radio. 3. Obscure, but computationally-intensive algorithms like Bitcoin. I hope my words have convinced some people to cool their lust for FPGAs, because I feel they're a bit of a dead-end or distraction for many who are attracted to the idea of "executing their algorithm extremely fast" or "becoming a chip designer." I have seen many students and professionals burn up hours and hours of their time getting something to run on an FPGA which could just as easily have been CPU-based. For example, one student implemented a large number of PWM oscillators on an FPGA where it would have been much simpler to use the debugged, verified, PWM peripherals on microcontrollers. Another guy I work with is intent on running CPU cores on FPGAs. This is an especially perverse use of the FPGA. Unless you've got some subset of the CPU which adds incredible value to the process, you're exchanging the the density of the VLSI/ASIC version of the chip for the flexible, less dense version on FPGA. This may be useful in rare situations, such as adding an out-of-order address generator to an existing core for speeding up an FFT, but it suffers an incredible performance and developer time hit to get to this point.
- amirhirsch 14y ago
  I think that the demand for Open Source FPGA tools is a real thing, but it is a very old problem now. The bitstream format hasn't been exposed since the xilinx xc6200 in the 90's, which has led to it being commonly used in FPGA compiler research. There have been efforts to reverse engineer the bitstream format, a notable paper on the subject is called "from the bitstream to the netlist:" http://dl.acm.org/citation.cfm?id=1344729 http://dl.acm.org/citation.cfm?id=1344729 This paper will explain how to reverse engineer the xilinx bitstream by examining the xdl intermediary format. the source code from this project is here (not updated since 2008): http://code.google.com/p/debit/source/list http://code.google.com/p/debit/source/list I think that in addition to open source tools, FPGAs will need cloud-hosted simulation, synthesis and place-and-route tools that can handle scaling up to designs with many millions of logic gates. Even in a well-partitioned design, a small change to the logic takes forever to recompile to FPGA.
- nitrogen 14y ago
  DrDreams: it looks like a comment you made 41 days ago resulted in your account being disabled (see https://news.ycombinator.com/threads?id=DrDreams https://news.ycombinator.com/threads?id=DrDreams). I'm quoting this sibling comment here for readability by those who do not enable showdead, as it is relevant to the FPGA discussion. DrDreams 29 minutes ago | link [dead] Speaking as an embedded developer, I see a number of other embedded devs hobbying around with FPGAs. However, I very rarely see convincing use cases for FGPAs. This article seems to lean toward the belief many of my colleagues have, that FPGAs are right around the corner in terms of general usefulness. However, I disagree strongly. I find that they are highly-specialized devices. Before reading the rest of my writing, consider that at this time, brilliant hardware designers are putting similar amounts of work into both general purpose CPUs and into FPGAs. However, CPUS are comprised of dense blocks of special-purpose silicon for common purposes, such as floating-point math. FPGAs always have to match that dense silicon through configurable silicon, which is less dense. Furthermore, the routing in CPUs is a known entity at manufacturing time. On FPGAs, the routing is highly variable and must be re-negotiated at nearly every compile cycle. That's a huge time sink, both in terms of build time and in predicting performance. Especially since those short routes that you get at the beginning of a project, typically end up being longer by the end of it. Nowadays, we are seeing more FPGAs with dedicated, pre-made hardware blocks inside of them, such as FPUs and even CPU cores. These have more of a chance of catching on for general purpose computing. Notice however, that on these devices, it's the general-purpose CPU dominating, leaving the FPGA as a configurable peripheral, subordinate to the dense, pre-designed silicon. Although one may be able to match GPU performance with an FPGA, it's usually just not worth it. It will take dozens of hours of FPGA coding and simulation. Compiling and fitting and the rest of the FPGA dev chain is very time-consuming and resource-intensive, compared to the speed and elegance of gcc. Speaking of standard development practices, FPGA code is not nearly as portable as C. It often has special optimizations done for the sake of the device implemented. http://opencores.org http://opencores.org has a number of more generic modules available, but still, FPGA code does not scale as well as C code. There are add-on packages that help write FPGA synthesis code - code synthesizers, but they make matters especially complicated. The syntax of Verilog and VHDL is not well-designed for scaling. Speaking of these languages, if you are used to languages written to be parsed easily, such as lisp, python, or even C and Java to some extent, you will be very appalled at the structure of Verilog and VHDL. There are many redundant entities, lots of excess verbiage and all kinds of special cases. It really has evolved very little since the days of the Programmed Array of Logic (PAL). Another problem with FPGAs is the additional hardware on board needed to configure them. It's one more component or interface that is not needed when using CPUs. It's an additional software image to maintain, revision, store in source control, etc. FPGAs also often require more power supplies and better power supply conditioning than a regular CPU and often a separate clock crystal. They are high-maintenance. FPGAs do shine though in a few specific instances: 1. When there is a particular, uncommon high-speed bus protocol you need to communicate with and can not buy pre-designed silicon for. This does not mean, e.g. USB. It means something like a non-standard digital camera interface or embedded graphic display. 2. Software Radio. 3. Obscure, but computationally-intensive algorithms like Bitcoin. I hope my words have convinced some people to cool their lust for FPGAs, because I feel they're a bit of a dead-end or distraction for many who are attracted to the idea of "executing their algorithm extremely fast" or "becoming a chip designer." I have seen many students and professionals burn up hours and hours of their time getting something to run on an FPGA which could just as easily have been CPU-based. For example, one student implemented a large number of PWM oscillators on an FPGA where it would have been much simpler to use the debugged, verified, PWM peripherals on microcontrollers. Another guy I work with is intent on running CPU cores on FPGAs. This is an especially perverse use of the FPGA. Unless you've got some subset of the CPU which adds incredible value to the process, you're exchanging the the density of the VLSI/ASIC version of the chip for the flexible, less dense version on FPGA. This may be useful in rare situations, such as adding an out-of-order address generator to an existing core for speeding up an FFT, but it suffers an incredible performance and developer time hit to get to this point.
- CamperBob2 14y ago
  An unenlightened attitude. You use "closed source tools" every time you start your car, use your telephone, watch TV, or run on a treadmill at the gym. What's so special about FPGA development?
  - DanWaterworth 14y ago
    The difference is necessity. I don't own a mobile phone for example, or a car or a treadmill for that matter.
    - CamperBob2 14y ago
      (Shrug) What's more "necessary" than being able to build cool stuff? There's more to life than self-denial.
      - DanWaterworth 14y ago
        I can build cool stuff without one =P
        CamperBob2 14y ago
        To the extent that's true, you're indeed better off avoiding FPGAs. No argument there. People use these things when there's no other way to do the job. My idea of cool stuff can't be done without them, unfortunately.
Dwolb 14y ago
Here is an article essentially discussing this issue: http://www.edn.com/design/systems-design/4330078/EDA-tools-for-FPGAs-break-down-the-complexity-gridlock http://www.edn.com/design/systems-design/4330078/EDA-tools-f... It boils down to economics: 3rd party companies that make EDA tools for the semiconductor industry can't tweak and sell their tools at a premium to the embedded designers that use FPGAs. The reason is the FPGA designers already get their tools for free from the FPGA vendor. Moreover, the article states FPGA vendors spend more money on development of tools than on the development of the FPGAs themselves!
- alok-g 14y ago
  This is I think what the issue is. The FPGA industry has created a lock-in since they are the ones supplying both the tools and the FPGAs themselves. The tool-chains for FPGAs have become so complex that they themselves cannot make them if asked to repeat, much in the similar fashion as Microsoft could not have created software to open .doc formats from scratch that is fully compatible with existing .doc files. Free tools implies third-party companies cannot readily enter the game because the customers would not be ready to pay (even though they already are effectively paying for the tools, but why pay for them twice). Again, this is same as Microsoft bundling Windows with laptops people buy without realizing that those laptops could have been cheaper if they were loaded with Linux and there were no political moves from somewhere to prevent that from happening. To me, these are signs of a pending disruption. Watch-out however since many companies have attempted this in the past and have not survived.
csense 14y ago
> the whole process INCLUDING bitstream generation is open How many supporters would a Kickstarter need to design such an FPGA, with all specs open, and ship devices to backers in the $200-$500 range? Let's assume you wouldn't need to write the bitmungers [1] and other parts of the toolchain, the open-source community would likely produce one for you pro bono if you're shipping physical hardware to the general public at a reasonable price with open specs. If anyone is actually planning on doing this, don't forget you'll need FCC certification because you'll probably pick up customers who are non-hardware people [2] [3]. [1] Or VHDL compilers, or netlisteners, or place-and-route, or whatever the tools are called. A hardware guru I am certainly not! [2] http://www.raspberrypi.org/archives/852 http://www.raspberrypi.org/archives/852 [3] http://www.raspberrypi.org/archives/978 http://www.raspberrypi.org/archives/978

DanWaterworth 14y ago

I can't up vote this enough. I keep gearing up to try using an FPGA, but ever time I do, I am prevented from continuing by my revulsion of closed source tools.

VLM 14y ago
I recently had to burn an old fashioned eprom using a non-legacy PC and found it impossible to find a USB connected linux compatible eprom burner. Yes if you have a parallel port on your laptop (not since 2003 or so?) there's the willem programmer. Yes there's a company in .de selling a USB burner with Ubuntu software but the shipping and handling to the states was kind of extreme. Why do they charge $75 or whatever it was from .de when Seeed studios charges approx nothing from .cn? So closed source problems are hardly limited solely to high tech FPGAs. Abandoning FPGAs doesn't mean you'll eliminate closed source from your life, it just means you'll eliminate FPGAs from your life... Also I suspect you do not have a copy of the firmware inside the microcontroller that runs your mouse, or your PC 8042 keyboard controller, or innumerable microcontrollers thru the machine, so either you are already OK with using "some" closed source or don't have a full picture of your whole system. Pessimism is your friend in this case and the situation is probably much worse than you think. I ALWAYS prioritize open source above all other criteria for obvious reasons, but when its not available I do my best with what I can get... Its an engineering background thing... Much as I'd love to ideally make everything outta aerospace carbon fiber and titanium, but lets face it, my house is made mostly outta wood and my car outta steel.
- DanWaterworth 14y ago
  The difference is necessity. I need a computer for my work and it would be infeasible to use 100% open source hardware. I don't need to play with FPGAs, but I would really like to. Hence me continually coming back to it, even if I haven't made the leap yet.
  - VLM 14y ago
    "The difference is necessity." That has to be carefully defined. My point with the eprom anecdote was that you're stuck with closed source if you put a z80 core and some rom/ram/decode logic in a FPGA and do a synthetic SoC and merely avoiding FPGA and doin' it with discrete Z80 and eprom and sram and some glue isn't going to save you, because in 2013 using PC hardware you pretty much need a closed source windows only USB eprom programmer. So if you're stuck with closed source doing a hobby project, at least do something "cool" and use the FPGA. To do "about the same thing" but open source there are several completely open source alternatives that would result in CPU controlled I/O ports being wiggled. Avoiding closed source is not just as simple as saying "no FPGAs" or closed source is solely a disease of FPGAs. for example it took years as I recall before the Propeller had a non-windows/dos stack, although the BST works pretty well now. Confusing the issue, if you just want to play around with Verilog as a language or abstract technology, Icarus is free software part of the GnuEDA project. Obviously that's playing with simulation not silicon, but it is possible. So you don't have to entirely avoid FPGA technology.
- AndresNavarro 14y ago
  There's a difference between a development environment and the code that runs in a random device... The problem is not just closed source software (which I don't like and try not to use) but a lack of documentation of the architecture and bitstream formats. I program for a living, but wouldn't for the life of me work with a closed source compiler for an unknown architecture with no/incomplete documentation. Many people may be ok with this though (see for example, some shader compilers for embedded GPUs). There's a reason processor manufactures release all info about instructions sets and that in turn allows a lot of projects like gcc, llvm, v8, luajit, etc. to support them. I would think that opening up the details of this technology would spur a lot of innovation regarding FPGAs and HDLs, both in academia and in the industry.
DrDreams 14y ago
Speaking as an embedded developer, I see a number of other embedded devs hobbying around with FPGAs. However, I very rarely see convincing use cases for FGPAs. This article seems to lean toward the belief many of my colleagues have, that FPGAs are right around the corner in terms of general usefulness. However, I disagree strongly. I find that they are highly-specialized devices. Before reading the rest of my writing, consider that at this time, brilliant hardware designers are putting similar amounts of work into both general purpose CPUs and into FPGAs. However, CPUS are comprised of dense blocks of special-purpose silicon for common purposes, such as floating-point math. FPGAs always have to match that dense silicon through configurable silicon, which is less dense. Furthermore, the routing in CPUs is a known entity at manufacturing time. On FPGAs, the routing is highly variable and must be re-negotiated at nearly every compile cycle. That's a huge time sink, both in terms of build time and in predicting performance. Especially since those short routes that you get at the beginning of a project, typically end up being longer by the end of it. Nowadays, we are seeing more FPGAs with dedicated, pre-made hardware blocks inside of them, such as FPUs and even CPU cores. These have more of a chance of catching on for general purpose computing. Notice however, that on these devices, it's the general-purpose CPU dominating, leaving the FPGA as a configurable peripheral, subordinate to the dense, pre-designed silicon. Although one may be able to match GPU performance with an FPGA, it's usually just not worth it. It will take dozens of hours of FPGA coding and simulation. Compiling and fitting and the rest of the FPGA dev chain is very time-consuming and resource-intensive, compared to the speed and elegance of gcc. Speaking of standard development practices, FPGA code is not nearly as portable as C. It often has special optimizations done for the sake of the device implemented. http://opencores.org http://opencores.org has a number of more generic modules available, but still, FPGA code does not scale as well as C code. There are add-on packages that help write FPGA synthesis code - code synthesizers, but they make matters especially complicated. The syntax of Verilog and VHDL is not well-designed for scaling. Speaking of these languages, if you are used to languages written to be parsed easily, such as lisp, python, or even C and Java to some extent, you will be very appalled at the structure of Verilog and VHDL. There are many redundant entities, lots of excess verbiage and all kinds of special cases. It really has evolved very little since the days of the Programmed Array of Logic (PAL). Another problem with FPGAs is the additional hardware on board needed to configure them. It's one more component or interface that is not needed when using CPUs. It's an additional software image to maintain, revision, store in source control, etc. FPGAs also often require more power supplies and better power supply conditioning than a regular CPU and often a separate clock crystal. They are high-maintenance. FPGAs do shine though in a few specific instances: 1. When there is a particular, uncommon high-speed bus protocol you need to communicate with and can not buy pre-designed silicon for. This does not mean, e.g. USB. It means something like a non-standard digital camera interface or embedded graphic display. 2. Software Radio. 3. Obscure, but computationally-intensive algorithms like Bitcoin. I hope my words have convinced some people to cool their lust for FPGAs, because I feel they're a bit of a dead-end or distraction for many who are attracted to the idea of "executing their algorithm extremely fast" or "becoming a chip designer." I have seen many students and professionals burn up hours and hours of their time getting something to run on an FPGA which could just as easily have been CPU-based. For example, one student implemented a large number of PWM oscillators on an FPGA where it would have been much simpler to use the debugged, verified, PWM peripherals on microcontrollers. Another guy I work with is intent on running CPU cores on FPGAs. This is an especially perverse use of the FPGA. Unless you've got some subset of the CPU which adds incredible value to the process, you're exchanging the the density of the VLSI/ASIC version of the chip for the flexible, less dense version on FPGA. This may be useful in rare situations, such as adding an out-of-order address generator to an existing core for speeding up an FFT, but it suffers an incredible performance and developer time hit to get to this point.
amirhirsch 14y ago
I think that the demand for Open Source FPGA tools is a real thing, but it is a very old problem now. The bitstream format hasn't been exposed since the xilinx xc6200 in the 90's, which has led to it being commonly used in FPGA compiler research. There have been efforts to reverse engineer the bitstream format, a notable paper on the subject is called "from the bitstream to the netlist:" http://dl.acm.org/citation.cfm?id=1344729 http://dl.acm.org/citation.cfm?id=1344729 This paper will explain how to reverse engineer the xilinx bitstream by examining the xdl intermediary format. the source code from this project is here (not updated since 2008): http://code.google.com/p/debit/source/list http://code.google.com/p/debit/source/list I think that in addition to open source tools, FPGAs will need cloud-hosted simulation, synthesis and place-and-route tools that can handle scaling up to designs with many millions of logic gates. Even in a well-partitioned design, a small change to the logic takes forever to recompile to FPGA.
nitrogen 14y ago
DrDreams: it looks like a comment you made 41 days ago resulted in your account being disabled (see https://news.ycombinator.com/threads?id=DrDreams https://news.ycombinator.com/threads?id=DrDreams). I'm quoting this sibling comment here for readability by those who do not enable showdead, as it is relevant to the FPGA discussion. DrDreams 29 minutes ago | link [dead] Speaking as an embedded developer, I see a number of other embedded devs hobbying around with FPGAs. However, I very rarely see convincing use cases for FGPAs. This article seems to lean toward the belief many of my colleagues have, that FPGAs are right around the corner in terms of general usefulness. However, I disagree strongly. I find that they are highly-specialized devices. Before reading the rest of my writing, consider that at this time, brilliant hardware designers are putting similar amounts of work into both general purpose CPUs and into FPGAs. However, CPUS are comprised of dense blocks of special-purpose silicon for common purposes, such as floating-point math. FPGAs always have to match that dense silicon through configurable silicon, which is less dense. Furthermore, the routing in CPUs is a known entity at manufacturing time. On FPGAs, the routing is highly variable and must be re-negotiated at nearly every compile cycle. That's a huge time sink, both in terms of build time and in predicting performance. Especially since those short routes that you get at the beginning of a project, typically end up being longer by the end of it. Nowadays, we are seeing more FPGAs with dedicated, pre-made hardware blocks inside of them, such as FPUs and even CPU cores. These have more of a chance of catching on for general purpose computing. Notice however, that on these devices, it's the general-purpose CPU dominating, leaving the FPGA as a configurable peripheral, subordinate to the dense, pre-designed silicon. Although one may be able to match GPU performance with an FPGA, it's usually just not worth it. It will take dozens of hours of FPGA coding and simulation. Compiling and fitting and the rest of the FPGA dev chain is very time-consuming and resource-intensive, compared to the speed and elegance of gcc. Speaking of standard development practices, FPGA code is not nearly as portable as C. It often has special optimizations done for the sake of the device implemented. http://opencores.org http://opencores.org has a number of more generic modules available, but still, FPGA code does not scale as well as C code. There are add-on packages that help write FPGA synthesis code - code synthesizers, but they make matters especially complicated. The syntax of Verilog and VHDL is not well-designed for scaling. Speaking of these languages, if you are used to languages written to be parsed easily, such as lisp, python, or even C and Java to some extent, you will be very appalled at the structure of Verilog and VHDL. There are many redundant entities, lots of excess verbiage and all kinds of special cases. It really has evolved very little since the days of the Programmed Array of Logic (PAL). Another problem with FPGAs is the additional hardware on board needed to configure them. It's one more component or interface that is not needed when using CPUs. It's an additional software image to maintain, revision, store in source control, etc. FPGAs also often require more power supplies and better power supply conditioning than a regular CPU and often a separate clock crystal. They are high-maintenance. FPGAs do shine though in a few specific instances: 1. When there is a particular, uncommon high-speed bus protocol you need to communicate with and can not buy pre-designed silicon for. This does not mean, e.g. USB. It means something like a non-standard digital camera interface or embedded graphic display. 2. Software Radio. 3. Obscure, but computationally-intensive algorithms like Bitcoin. I hope my words have convinced some people to cool their lust for FPGAs, because I feel they're a bit of a dead-end or distraction for many who are attracted to the idea of "executing their algorithm extremely fast" or "becoming a chip designer." I have seen many students and professionals burn up hours and hours of their time getting something to run on an FPGA which could just as easily have been CPU-based. For example, one student implemented a large number of PWM oscillators on an FPGA where it would have been much simpler to use the debugged, verified, PWM peripherals on microcontrollers. Another guy I work with is intent on running CPU cores on FPGAs. This is an especially perverse use of the FPGA. Unless you've got some subset of the CPU which adds incredible value to the process, you're exchanging the the density of the VLSI/ASIC version of the chip for the flexible, less dense version on FPGA. This may be useful in rare situations, such as adding an out-of-order address generator to an existing core for speeding up an FFT, but it suffers an incredible performance and developer time hit to get to this point.
CamperBob2 14y ago
An unenlightened attitude. You use "closed source tools" every time you start your car, use your telephone, watch TV, or run on a treadmill at the gym. What's so special about FPGA development?
- DanWaterworth 14y ago
  The difference is necessity. I don't own a mobile phone for example, or a car or a treadmill for that matter.
  - CamperBob2 14y ago
    (Shrug) What's more "necessary" than being able to build cool stuff? There's more to life than self-denial.
    - DanWaterworth 14y ago
      I can build cool stuff without one =P
      - CamperBob2 14y ago
        To the extent that's true, you're indeed better off avoiding FPGAs. No argument there. People use these things when there's no other way to do the job. My idea of cool stuff can't be done without them, unfortunately.

Dwolb 14y ago

Here is an article essentially discussing this issue: http://www.edn.com/design/systems-design/4330078/EDA-tools-for-FPGAs-break-down-the-complexity-gridlock http://www.edn.com/design/systems-design/4330078/EDA-tools-f... It boils down to economics: 3rd party companies that make EDA tools for the semiconductor industry can't tweak and sell their tools at a premium to the embedded designers that use FPGAs. The reason is the FPGA designers already get their tools for free from the FPGA vendor. Moreover, the article states FPGA vendors spend more money on development of tools than on the development of the FPGAs themselves!

alok-g 14y ago
This is I think what the issue is. The FPGA industry has created a lock-in since they are the ones supplying both the tools and the FPGAs themselves. The tool-chains for FPGAs have become so complex that they themselves cannot make them if asked to repeat, much in the similar fashion as Microsoft could not have created software to open .doc formats from scratch that is fully compatible with existing .doc files. Free tools implies third-party companies cannot readily enter the game because the customers would not be ready to pay (even though they already are effectively paying for the tools, but why pay for them twice). Again, this is same as Microsoft bundling Windows with laptops people buy without realizing that those laptops could have been cheaper if they were loaded with Linux and there were no political moves from somewhere to prevent that from happening. To me, these are signs of a pending disruption. Watch-out however since many companies have attempted this in the past and have not survived.

csense 14y ago

> the whole process INCLUDING bitstream generation is open How many supporters would a Kickstarter need to design such an FPGA, with all specs open, and ship devices to backers in the $200-$500 range? Let's assume you wouldn't need to write the bitmungers [1] and other parts of the toolchain, the open-source community would likely produce one for you pro bono if you're shipping physical hardware to the general public at a reasonable price with open specs. If anyone is actually planning on doing this, don't forget you'll need FCC certification because you'll probably pick up customers who are non-hardware people [2] [3]. [1] Or VHDL compilers, or netlisteners, or place-and-route, or whatever the tools are called. A hardware guru I am certainly not! [2] http://www.raspberrypi.org/archives/852 http://www.raspberrypi.org/archives/852 [3] http://www.raspberrypi.org/archives/978 http://www.raspberrypi.org/archives/978