FPGA Programming for the Masses

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.

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.

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.

That is not my world at all. My applications have never had the luxury of being able to simply import an 8 bit processor core and a few peripherals and off we go into software land. Nearly everything I've done has been in two domains: real time image processing in hardware or beam-forming applications. In all cases virtually no use of canned modules could be made or justified. Sure, there's the SPI's and I2C's and a few other knick-knacks, but that's about it.

In fact, most of the applications I've done would end-up with external physical embedded processors because the high-speed FPGA resources could not be spared for low speed "command and control" work.

Maybe I'm living in that 0.1% you referred to?

Surely there are people doing more mundane things such as motor control, glue logic or battery chargers who might benefit from wiring together a complete custom embedded system within single Spartan FPGA and life is great. I can see that being a possibility. It just hasn't been part of my reality, for better or worst.

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?arnumber=6...

The wikipedia entry also has a link to a parallelizable algo from 20+ years ago for CCL. FPGAs certainly parallel pretty easily. I wonder if your simplified optimum solution is to calculate one cell and replicate into 20x20 matrix or whatever you can fit on your FPGA and then have a higher level CPU sling work units and stitch overlapping parts together.

More practically I'd suggest your quick prototype would be slap a SoC on a FPGA that does it in your favorite low-ish level code, since it only takes hours, then very methodically and smoothly create an acceleration peripheral that begins to do the grunt-iest of the grunt work one little step at a time.

So lets start with just are there any connections at all? That seems a blindingly simple optimization. Well thats a bitwise comparison, so replace that in your code with a hardware detection and flag. Next thing you know you've got a counter that automatically in hardware skips past all blank space into the first possible pixel... But thats an optimization, maybe not the best place to start.

Next I suppose if you're doing 4-connected you have some kind of inner loop that looks a lot like the wikipedia list of 4 possible conditions. Now rather than having the on FPGA cpu compare if you're in the same region one direction at a time, do all 4 dirs at once in parallel in VHDL and output the result in hardware to your code, and your code reads it all in and decides which step (if any) was the lowest/first success.

The next step is obviously move the "whats the first step to succeed?" question outta the software and into the VHDL, so the embedded proc thinks, OK just read one register to see if its connected and if so in which direction.

Then you start feeding in a stream and setting up a (probably painful) pipeline.

This is a solid bottom up approach. One painful low level detail at a time, only one at a time, never more than one at a time. Often this is a method to find a local maximum, its never going to improve the algo (although it'll make it faster...)

"because on FPGAs you are forced to optimize right from the start" Don't do that. Emulate something that works from the start, then create an acceleration peripheral to simplify your SoC code. Eventually remove your onboard FPGA cpu if you're going to interface externally to something big, once the "accelerator" is accelerating enough.

Imagine building your own floating point mult instead of using an off the shelf one ... you don't write the control blocks and control code in VHDL and do the adders later... your first step should be writing a fast adder only later replacing control code and simulated pipelining with VHDL code. You write the full adder first, not the fast carry, or whatever.

In general terms, yes, FPGA work can and does usually take longer than the equivalent work in the software domain. It doesn't have to be that way though.

For me it starts with language choices. I suppose that if you work in VHDL all the time you probably rock. I have an intense dislike for VHDL. I don't see a reason to type twice as much to do the same thing. Fifteen years ago VHDL had advantages with such constructs as "generate", this is no-longer the case. I realize that this can easily turn into an argument of religious nature, so we'll have to leave it at that.

One approach that I have used with great success with complex modules is to write them in software first and then port to the FPGA. Going between C and Verilog is very natural.

The key is to write C code keeping in mind that you are describing hardware all along. Don't do anything that you would not be able to easily replicate on the FPGA. You are, effectively, authoring a simulation of what you might implement in the FPGA. The beauty of this approach is that you get the advantage of immediate execution and visualization in software. Debug initial structures and assumptions this way to save tons of time.

Maybe the best way to put it is that I try not to use the FPGA HDL coding stage to experiment and create but rather to simply enter the implementation. Then my goal is to go through as few Modelsim simulation passes as possible to verify operation.

If you've done non-trivial FPGA work you have probably experienced the agony of waiting an hour and a half for a design to compiler and another N hours for it to simulate before discovering problems. The write-compile-simulate-evaluate-modify-repeat loop in FPGA work takes orders of magnitude longer than with software. I've had projects where you can only reasonably make one to half-a-dozen code changes per 18 hour day. That's the way it goes.

This is why I've resorted to extensive software-based validation before HDL coding. I've done this with, for example, challenging custom high-performance DDR memory controllers where there was a need to fiddle with a number of parameters and be able to visualize such conditions as FIFO fill/drain levels, etc. A nice GUI on top of the simulation made a huge difference. The final implementation took far less time to code in HDL and worked as required from the very start.

Another general comment. When it comes to image processing in FPGA's you don't really pay a penalty for modularizing your code to a relatively fine-grained degree. This because module interfaces don't necessarily create any overhead (the best example of this being interconnect wires). In that sense FPGA's are vastly different from software in that function or class+method interfaces generally come at a price.

Modularization can produce benefits during synthesis and placement. If you can pre-place portions of your design and do your floor planning in advance you can save tons of time. Incremental compilation has been around for a while. Still, nothing beats getting into the chip and locking down structures when it makes sense.

To circle back to the recurring theme of "FPGA for the masses" that pops-up every so often. I maintain that FPGA's are, fundamentally, still about electrical engineering and not about software development. These, at certain levels, become vastly different disciplines. Once FPGA compilers become 100 to 1,000 times faster and FPGA's come with 100 to 1,000 times more resources for the money the two worlds will probably blur into one very quickly for most applications.