6 ms·

This is a solid article. I'm continually surprised by how few software engineers in industry spend the time to pick up HDL and FPGA programming in general. In m

• schabernakk 13y ago
  > I'm continually surprised by how few software engineers in industry spend the time to pick up HDL and FPGA programming in general. unsufficient tooling? I did some programming with FPGAs once and it seemed the best option I had for programming was proprietary software by altera (quartus). I never got debugging to work or perhaps I did and I didnt understand the stuff it was showing me (I am no hardware guy) My impression was that an eclipse-like ide, perhaps with a built in HW simulator would make things A LOT easier, especially for beginners like me. Of course this could be completely unrealistic and impractical for hardware design in which case I will show myself out.
  • alok-g 13y ago
    I seriously want someone to disrupt FPGA tooling. In my understanding the tooling for FPGAs has been made purposefully complicated to achieve a lock-in. The issue is that adoption of new tooling practically requires compatibility with the existing tools from the two key market holders, and I do not think even they themselves could do that anymore.
    • _yosefk 13y ago
      It's genuinely complicated; if Xilinx could disrupt Altera by making easier-to-use tools, it would. (In fact it tries with AutoESL.) I hope to explain why FPGA tooling is intrinsically hard in my next write-up.
      • amirhirsch 13y ago
        here's a few good reasons why it's hard to make easy-to-use vendor-neutral FPGA tools: - all the devices/bitstream formats are proprietary with little or no documentation of the logic blocks or programmable interconnect structures. it is probably technically easier to build a new FPGA from scratch and design tools for that, than to reverse engineer existing chips [1] - there is very little cross-compatibility between vendor products (a 4-lut here, a 6-lut there, some carry-chain logic here, a DSP block there) - all the optimizations (synthesis, place-and-route) are NP-hard problems - sequential imperative (C-like) thinking is not the correct way to make parallel systems - the FPGA vendors compete on tools and offer their software for free to push hardware. hard for an independent vendor to compete. [1] some reverse engineering efforts exist. see "From the bitstream to the netlist" http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117.6043&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.117... / http://code.google.com/p/debit/ http://code.google.com/p/debit/
        • alok-g 13y ago
          While I find your comment informative, points 3 and 4 do not really explain why vendor-neutral tools cannot exist. Point 2 (my best understanding) should not be a breaking issue if documentation and specifications are available (which is covered by point 1). It seems to me that point 5 is part of the thing they have done to prevent alternative tools to come to market. Lastly, point 1 is exactly what begs for disruption.
• _yosefk 13y ago
  I think partial reconfiguration is actually vital - you can't do stuff without it - while C-to-Verilog is not. Though I've seen people loving AutoESL; one claim - always repeated about higher-level languages - is that you can explore more possibilities and thus beat hand-coded Verilog because of the time it takes to hand-code yourself into a local optimum while missing the global optimum. I sort of ignore the language question, because Verilog feels nice enough to me, though perhaps it's important in the sense that most programmers want C.
  • bhb916 13y ago
    I agree with your assessment. PR is important to designers and system engineers and architects. C-to-Gates is important to business types.
  • lambda 13y ago
    > most programmers want C Hmm. I've always thought that most programmers want languages that offer more abstraction than C. C is probably about the opposite of what you want, since it's a fairly low level language targeting a fairly different model of computation than an FPGA. What you want is higher-level tools that are designed and built around this much more parallel model, not something that allows you to compile C to an FPGA. In fact, I think that there would be a lot more interest in creating better languages and tools for FPGAs, if there were actually open documentation on the low levels of how to program FPGAs, so people could actually write their own tools targeting them. But most vendors seem to just provide their own Verilog compilers with onerous licensing restrictions, and there's little portability between hardware, so there's nothing really good to target.
    • skaevola 13y ago
      AFAIK C is by far the most prevalent language for embedded systems, which are typically the applications FPGA's are also used for.
• sliverstorm 13y ago
  The best part of learning HDLs and other bare-metal experience, I've found, is it taught me to think in parallel and asynchronous frames.
• dualogy 13y ago
  > I see the utility of FPGAs everywhere I look Examples?
  • jff 13y ago
    I see the utility anywhere a simple, repetitive task is performed with interaction from the physical world. The canonical student example is the soda machine. Sure, you could put a small Linux system in there and write Python code, but then you have millions of lines of Linux and Python code underlying your simple little soda vending code. Instead, you describe the problem as a state machine and implement it in the FPGA. This gives you an instant-on solution. I often find myself looking at the behavior of basic systems like automatic doors, card readers, thermostats, and motion-triggered light switches, thinking about their behavior and how I might describe it as a state machine. Thinking about what combination of inputs and outputs, what sensors and actuators would be needed to perform the task. It's fun.
    • Florin_Andrei 13y ago
      > The canonical student example is the soda machine. Sure, you could put a small Linux system in there and write Python code, but then you have millions of lines of Linux and Python code underlying your simple little soda vending code. Instead, you describe the problem as a state machine and implement it in the FPGA. This gives you an instant-on solution. If it's indeed just a soda machine, you could implement it in a microcontroller and code plain C for the whole thing. The FPGA seems overkill. Take Atmel for example. The Arduino boards are based on the Mega series. Fairly complex things (the ATMega microcontrollers), yet easy to program. I've played with the Tiny series - they're great if you don't need that many inputs / outputs. http://www.atmel.com/products/microcontrollers/avr/default.aspx http://www.atmel.com/products/microcontrollers/avr/default.a... It's instant-on and very low power. To me, an FPGA is better for real-time video scrambling and stuff like that.
      • HeyLaughingBoy 13y ago
        Exactly, and this is pretty much the answer to the OP's question about why software engineers haven't embraced FPGAs. Answer; there are other solutions that are simpler and much closer to their existing knowledge base. You want to build a soda machine? I can implement that logic in an 8 pin, fifty cent Atmel tinyAVR device that can be programmed in C or C++ Skills of software engineers are probably better applied to building better FPGA toolsets.
• lambda 13y ago
  The last time I looked into FPGA programming (probably back when I was in college), the cheap eval hardware cost at least a few hundred dollars a board, if not a few thousand. For something that would just be a toy to play around with, it was too much to justify spending money on. On top of that, the tooling is all proprietary, clunky, with obnoxious licensing. If you notice, that eval board you pointed to comes with "ISE® WebPACK® software with device locked SDK and ChipScope™ Pro licenses". I'm just not interested at all in any "device-locked SDKs". And finally, there's a bootstrapping problem. FPGAs aren't really a mass-market platform, because no one has them (unless they're developing custom hardware). If there are now $90 eval boards, that solves part of the problem. Another big step would be building a reasonable toolchain around it that does not consist of big clunky proprietary tools with onerous licensing. And finally, someone will need to start shipping FPGAs with a standardized interface on commodity hardware. If I can depend on their being an FPGA in a phone, in a workstation, or in COTS server hardware, there are lot more possible applications. As it is, you already have to be building your own hardware before an FPGA is something you would want to target at all. The vast majority of programmers write code to run on COTS hardware (servers, desktops, mobile), not custom hardware.
  • olouv 13y ago
    You can have a small FPGA test board here http://be.eurocircuits.com/shop/offtheshelf/product.aspx?&ano=120099-91&ad=19069&r=elektor-pcb-service http://be.eurocircuits.com/shop/offtheshelf/product.aspx?&an... for 60€. The tutorials (non-free) can be found there http://www.elektor.com/magazines/2012/december/taming-the-beast.2317130.lynkx http://www.elektor.com/magazines/2012/december/taming-the-be...
    • lambda 13y ago
      That only addresses the one point (expense of the test boards), which as I pointed out, is the one major problem that has been solved (I consider a $90 dev board reasonably affordable for tinkering, so a $70 dev board is better, but not by much). It doesn't seem to solve the other two problems, though I suspect that solving the second (lack of open tools) would go a long way towards solving the third as well (ubiquity of hardware available to target).
• fieldforceapp 13y ago
  >High Level Synthesis isn't here yet Plenty of commercial development on that front recently. Forte Design Systems [1] is selling tools targeting both FPGA and ASIC design using a C++ class library front end (SystemC). Synopsys has two flows in their Synphony product line, one which synthesizes from C called Synphony C Compiler [2] and another flow based on Matlab libraries which isn't really synthesis per se but supports mapping between Matlab Simulink to FGPAs [3]. Use of these (including AutoESL) seem focused on certain domains. Image processing, cryptography and machine vision seem popular areas just now. [1] http://www.forteds.com/products/cynthesizer.asp http://www.forteds.com/products/cynthesizer.asp [2] http://www.synopsys.com/Systems/BlockDesign/HLS/Pages/SynphonyC-Compiler.aspx http://www.synopsys.com/Systems/BlockDesign/HLS/Pages/Synpho... [3] http://www.synopsys.com/Systems/BlockDesign/HLS/Pages/Synphony-Model-Compiler.aspx http://www.synopsys.com/Systems/BlockDesign/HLS/Pages/Synpho...
  • bhb916 13y ago
    I find it interesting that Synopsys would attempt to compete directly with Xilinx's System Generator product. The latter is to my knowledge completely endorsed and supported by The Mathworks. Something to investigate ...
    • fieldforceapp 13y ago
      The comercial tools market is usually based around "flows," which is a fancy way to say they try to bundle their offerings. While Xilinx is primarily interested in an FPGA flow, Synopsys of course would be happy to help you retarget your design to the more expensive ASIC flows as well. In addition, Synopsys offers hardware prototyping & emulation. All of which means while there's competition with Xilinx (and Altera, and Mathworks too) each vendor is focused a different use case of FPGA's.
• damian2000 13y ago
  I was lucky enough to be able to do a tiny bit of FPGA programming last year in Verilog. Its deceiving how similar to C it seems initially, then when you start getting into it how vastly different it is to normal programming. I remember thinking that everything is literally running in parallel.
• robomartin 13y ago
  > I'm continually surprised by how few software engineers in industry spend the time to pick up HDL and FPGA programming in general. While I appreciate your sentiment, it isn't programming, it's hardware design. To do anything beyond the somewhat trivial you need to learn a pile of EE stuff. Thinking of FPGA's as software might be nice, but that's not reality. Some examples of this are signal integrity, metastability, transmission lines, propagation delays, timing closure, SSO, etc. And that's the tip of the iceberg. You can't just shove in a 600MHz clock, write something that looks like software and expect the darn thing to work. I once spent nearly three months chasing a 3 nanosecond timing problem on a complex design. The "code" was perfect. It was a layout, routing and timing problem. FPGA's are not software. Of course, this is assuming an EE has done the hard work of designing a solid board with all the right I/O, interfaces as well as the all the initialization and setup files. Again, as an example, a DDR3 bank is not a trivial piece of hardware to design, layout, interface and configure. None of this is to say that it is impossible for a non-EE to learn and become quite capable at developing with FPGA's. however, this isn't just like learning a new programming language. I'll venture a guess that most programmers would have trouble committing to going down the deep and twisted rabbit hole they'd have to navigate. Again, not impossible. Seen it done. But it isn't software and it requires serious dedication.
  • _yosefk 13y ago
    I agree about the pile of EE stuff, but it's not unlike having to learn a pile of math to work on, say, graphics; it's two areas into which programmers can naturally branch out, but it's not trivial. And yes, you'd need EEs around; you'd need artists around to ship nice graphics, ultimately, or you'd need to be one yourself. Another angle - to be really good at C, you basically have to be fluent in assembly, at least in reading it, so you could say that C isn't just another language, or "C isn't a high-level language, it's a portable assembler", analogously to "FPGA isn't software, it's hardware design." In reality there's a continuum between hardware and software design, as there is a continuum between programming and math, programming and art, high level languages and low level languages, etc.
    • robomartin 13y ago