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.
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.
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.
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.
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
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.
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 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.
I guess the lesson is - don't talk about gently fucking math-hipsters with chainsaws on HN.
DrDreams:
Furthermore, the routing in CPUs is a known entity at manufacturing time.
The 'routing' of a CPU is much more variable than the routing of an FPGA. Data moves around a CPU based on the program that is executing. The control logic of a CPU is the equivalent of the routing logic of an FPGA.
On FPGAs, the routing is highly variable and must be re-negotiated at nearly every compile cycle.
The 'routing' of a CPU is the same. The compiler has to perform register allocation afresh on every compilation. There's obviously a tradeoff between fast compilation vs most efficient use of resources. Both problems are NP-complete I believe.
Nowadays, we are seeing more FPGAs with dedicated, pre-made hardware blocks inside of them, such as FPUs and even CPU cores.
You just contradicted yourself. Previously, you said "FPGAs always have to match that dense silicon through configurable silicon".
Your next paragraph talks about toolchain issues. This is hardly an insurmountable problem. Someone just needs to design a high level language that can be synthesised; something akin to a python of the FPGA world if you will.
Another problem with FPGAs is the additional hardware on board needed to configure them.
I don't quite understand, do you mean the hardware that reads the bitstream, etc or the hardware that is required in order for the FPGA to be configurable, like routing, LUTs, etc.
Another guy I work with is intent on running CPU cores on FPGAs.
I do agree with you here, this is a weird perversion if the purpose is not eventually to create an ASIC.
I also don't believe that future processors will be FPGAs, but I do believe they will be a lot closer to FPGAs than CPUs.
The advantage of FPGAs is that they allow nontrivial parallelism. On a CPU with 4 cores, you can run 4 instructions at a time (ignoring the pipelining). On the FPGA, you can run any number of operations at the same time, as long as the FPGA is big enough. The problem is not the low-level nature of hardware description languages, the problem is that we still don't have a smart compiler that can release us from the difficulty of writing nontrivial massively-parallel code.
Want a system on a chip with 2 cores leaving plenty of space for an ethernet accelerator, or 3 cores without space for the ethernet accelerator? Its only an include and some minor configuration away.
"the problem is that we still don't have a smart compiler that can release us from the difficulty"
Still don't have smart programmer... its hard to spec. Erlang looking elegant, doesn't magically make it easy to map non-technical description of requirements to Erlang.
Thanks for clearing up some of my blurrier points :) I should not have included "always" in that statement about matching the density of silicon. That breaks my own rule about absolutes.
I hadn't considered the routing of a CPU at compile time similar to the routing of an FPGA. They're at different scales and have different challenges... I guess it's because I have mainly seen FPGAs in time-critical situations (where CPUs can't be used) in which it was very difficult to predict their performance and they required lots of hand-tweaking. That was in SONET routing, btw. CPUs on the other hand, usually have some time to spare, whether it is because they are overspecced, or because they are used in applications which tolerate variation in execution time (user interfaces) in comparison to FPGAs used for e.g. translating data between communications busses. It is simple to measure, reproduce and predict specs for common algorithms like the FFT, convolution, etc. for CPUs. I believe this is because the operations in the "routing" of CPU algorithms are based on the sum of known, discrete, orthogonal events like memory fetches, ALU operations, etc.
Inside FPGAs though, the timing is not as uniformly discretized. It's about taking resources of routing distance from a large pool with a large geographical component, making it highly non-linear and tricky to predict.
I think we all agree a better language would be the key to getting more out of FPGA technology! And I would like to see more FPGA-elements on traditional CPUs like ARM, x86, AVR, PIC, etc. I wonder what elements an improved hardware description language would use? It could certainly be trivially parseable by tools like antlr while still giving bit-level access...
W/r/t additional hardware, I meant hardware that configures the bitstream, such as a header or CPU interface, as well as power supplies. For example, this schematic which I grabbed as an example: http://upload.wikimedia.org/wikipedia/en/3/3f/WillWare_Usb_f... . You can see the FPGA has THREE power supplies (1.2V, 2.5V, 3.3V). This particular design doesn't need additional clock sources, fortunately, but it's rather common. Understand that this isn't a fatal flaw with FPGAs, it's simply a disadvantage- one doesn't add an FPGA alone, one adds an FPGA, power supplies, possibly a crystal, and a programming interface. It means using an FPGA incurs a bunch of overhead.
As for getting my account banned due to my reaction to a bogus article about a way of multiplication fraudulently claimed to be taught to Japanese school kids: Well if you folks in this little community don't need me around and don't feel what I have to say counts for anything and you don't like the way I say what I have to say, and you can't tolerate differences in people who are different from you, then go ahead and enjoy gassing each other up and blowing smoke up each other's asses in your sealed-off little echo chamber without me. I don't need you, either. I will still profit and benefit from the information here without contributing anything back if you're all so sure you know all the answers. And I'll be sure to let everyone I encounter know what an open and swell bunch of folks they can expect here, after everyone with a differing or seasoned opinion is silently silenced and banned. Keep slurping up your daily vomit from Jacques Mattheij. http://24.media.tumblr.com/tumblr_lfiferFT7c1qa55edo1_400.jp... .
I suspect that if you used FPGAs for less time critical applications, you'd have more room for productivity tradeoffs.
Inside FPGAs though, the timing is not as uniformly discretized. It's about taking resources of routing distance from a large pool with a large geographical component, making it highly non-linear and tricky to predict.
Such details can be abstracted over. If you only create synchronous circuits, for example, these subtle timing considerations can be handled automatically.
W/r/t additional hardware, I meant hardware that configures the bitstream, such as a header or CPU interface, as well as power supplies.
I don't really understand why such additional hardware is necessary, I'm not able to comment.
Ah yes exactly. I would not translate machine language or C into raw asynchronous VHDL I'd stick a real or virtual core in the FPGA and create the worlds most amazing accelerator peripheral to make the CPU little more than a UI and a DMA controller to keep the accelerator fed.
You don't implement your video game's title page in discrete (emulated) FPGA logic. You put your 3-d graphics engine in the FPGA and leave the author credits in plain old CPU memory.
"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"
Totally missing the point. You want 768 PWMs to run 768 servos you instantiate 768 VHDL and an onboard proc to set them up and/or UI, all done. Not all that much harder than running 1. You are not going to find 768 PWM outputs on any single chip microcontroller that I'm aware of. Actually you aren't going to find a 768+ pin microcontroller out there anywhere, although thats kinda fat its not unheard of for a FPGA. You want one PWM output, yeah you use an off the shelf PIC, but that doesn't scale. Also don't make a plain old generic PWM when you need a servo controller. Make the worlds best hardware dedicated servo controller (which is, at its core, basically a PWM, but add extensive offset and calibration registers, and maybe limit registers, and sensible hardware default on boot positions and all that, and maybe integrated hardware backlash correction, thats how you make a servo controller, not just "make a PWM" that later gets turned into a servo controller)
"often a separate clock crystal. They are high-maintenance"
This is a bit WTF the guy isn't too far off until he gets to this kind of stuff.
There's more to life than self-denial.
My idea of cool stuff can't be done without them, unfortunately.