FPGA-HAMMER Rationale
Last updated at 7:44 am UTC on 14 March 2012
Warning: this page expresses strong opinions on this subject. I do not wish to start a flame war. This is a very personal take on the subject, and if it offends you, please feel free to express your own views by building your own tools and sharing with us.
For several years I've been looking for an alternative to the usual Verilog/VHDL sythesize/map/place/route/flash cycle. All I wanted was a simple tool that would let me design circuits from the bottom up, by placing primitives and modules as I please. I don't want C++, I want Forth or assembly, so to speak.
Alas, there is nothing of the kind. My hat is off to the folks who made RapidSmith and served as an inspiration (I wasn't sure I could take on a project of this complexity). Alas, RapidSmith is just an enormous Java framework of dubious value (as is any enormous Java framework, as far as I am concerned) as it did not address any of my concerns.
Why not just use the free (as in rancid beer) Xilinx tools? There are several problems with the traditional approach that were a deal-breaker to me (you may have different considerations):
- Subject to whims of the vendor. I love Xilinx, but let's face it, they are here not for me but for the shareholders. Every year they will phase out perfectly good FPGAs that will become nearly free on EBAY. To make sure I buy the expensive new ones, the 'updated' tools will no longer handle legacy chips. So I am stuck with even crappier buggy old tools. No thanks.
- Linguistically absurd. As a compiler writer I am appalled, and don't quite get what they were shooting for. Verilog tries unsuccessfully to map circuits onto a C-like syntax. Add a ridiculous 'always @' construct, foolish discrepancies with 'register' vs. 'wire' declarations, constraints and general confusion between circuit description, general-purpose programming, simulation, timing analysis and whatever. VHDL prime directive is, apparently, to force you to write a Bollywood script.
- Layers of other ridiculous tools. But wait, there is more. Synthesizers, mappers, placers, routers, simulators, oh my. Layers of pragmas, built-in constraints, separate constraint files, and more garbage to deal with. All poorly named, badly documented, and fragile
- Silent but deadly optimizations (scatological pun intended). A small typo - and after a couple of minutes of crunching, your circuit is generated with both legs amputated - the compiler decided you don't need legs after all. No, not an error condition. Check the logs in the megabytes of garbage to see what has been chopped off, if you don't like it. Want to have unconnected debugging constructs for testing with FPGA Editor? Good luck!
- Huge! A DVD full of cr_p, with each project generating hundreds of files with mysterious contents.
- Awful IDE. An embarrassing abomination, a steaming pile of excrement...Beyond useless (and I am being generous. I guess if you are a 'professional' you will buy $500,000 synthesis and verification tools.) But even shoehorning this monstrosity into make scripts doesn't help much as it still needs dozens of weird little files...
- Slow! A turnaround time of several minutes to test small changes is rudiculous. (think Smalltalk vs. C++, but much, much worse). I had to upgrade my machine twice, to get a relatively small circuit (an Apple 2 implementation) to compile in less than 2 minutes!
- Too high level I want to place and wire lookup tables, flops etc., not whatever Verilog (or God forbid, VHDL) does. I need to know, or better yet, I should be the one deciding what kind of circuits are generated. Have you looked at what happens if you naively write a case statement or a nested conditional on a 16-bit bus? It's time to buy a bigger FPGA!
- Reusable IP?Give me a bleeping break. 5 minutes to generate a bleeping counter? And then you are stuck with more mysterious files, directories full of garbage, and intermittent failures. IP my shiny metal butt.
- Flaky A small and correct change breaks the entire project? Come on, what year is this?
- Inconsistent Different circuits from the same code on different days? Does anyone actually look at the generated circuits?
- Too verbose It takes a bit of typing - and a jigabyte of files -to get from nothing to a flashing LED.
- Inflexible It's almost impossible to create and wire a lookup table (that is native to the FPGA) without interferance.
- Ridiculous and arbitrary inference rules. After years of working with the tools, you will have a pretty good idea of the exact code to write to get the exact circuit you want. Xilinx has pages and pages of 'write this sequence of code to create that' in their documentation. Am I expected to memorize this?
These are only some of my gripes. I could go on but I will leave it as an exercise for the reader:
