3 ms·
Right, well, the problem with all articles of this kind is that the authors are doing the equivalent of trying to force a square peg into a round hole. You do
by robomartin 7y ago
Right, well, the problem with all articles of this kind is that the authors are doing the equivalent of trying to force a square peg into a round hole.
You do not PROGRAM an FPGA in the software engineering sense of the word, you CONFIGURE it.
You do not use a programming language to create your configuration bitstream; you use a HARDWARE DESCRIPTION LANGUAGE.
You describe the hardware you want and how it is to be interconnected. You do this either explicitly —by literally using code that wires resources as you specify—or by inference— using idioms, if you will, that you know result in specific hardware within the device.
Thinking of Verilog or VHDL as software programming languages is wrong and can only lead to frustration. FPGA’s are still very much the domain of hardware engineering. Well, at least if what we are after are efficient high-performance results.
If, as a software engineer, you want to take advantage of an FPGA to accelerate processing, you should work with a capable FPGA hardware engineer to create a device with an “API” (using the term loosely) that exposes the desired functionality. I’ve done just that more times than I can remember; hanging a large FPGA off something like a small 8 bit 8051-derivative processor that allows the micro to access powerful computing resources exposed through means easily accesible with simple C functions in real time.
If you use the right tool for the job and do it correctly it can be blissful; try to force a paradigm that does not match reality and all you get is frustration.
- ncmncm 7y agoThe author is obviously deeply aware of all this. It is exactly what he is complaining about. Why should he have to hire you to do something he could do himself, given better tooling? It is the same problem as business people had, needing to explain their problem to a system analyst and get programmers to code it. Then spreadsheets came along, and 99% of business programming just totally disappeared into it. Maybe you can do it better than he could. Doesn't matter, there's only one of you, and what he could do would be good enough. Just like spreadsheets.
- robomartin 7y agoYour perspective on this is flawed. The comparison to spreadsheets isn’t applicable here. Not even close. That said, I do not expect you to understand my perspective if you are not a hardware engineer. This isn’t a put-down, just reality. There have been many attempts to make FPGA’s fit into a nice software engineering paradigm. I can’t think of one, a single one, that compares well to what a hardware engineer can do by treating it like hardware. A simple example I can give you comes from my own work going back about 15 years. Part of my design needed a very high performance multiphase FIR filter. The tools, even with all possible optimizations enabled, could not get the performance we needed out of this chip. If we wanted to stay with that approach the only option was to go up to a larger and faster FPGA as well as up one speed grade. That would have cost a bundle. Instead, I hand-placed, wired and routed the filters. As a result I was able to get 2.5 times the performance the compiler could get. We were able to stay with the smaller chip and squeezed even more out of it during the five year product life cycle. FPGA’s are hardware, not software.
- ncmncm 7y agoIf you built the exact same product today, almost the cheapest FPGA you can buy would be fantastically overprovisioned. So, today, all your extra effort then would be superfluous, and you could treat the design like software, using defaults. Programming computers used to be like hardware; where you stored a variable on the drum mattered because you couldn't afford to wait a whole rotation to fetch it again. Now most code is just code, and Python is often fast enough for production. I know the difference. When I take packets from a 40Gbps link, I'm programming hardware. I'm counting cycles. Most problems are not like that, and don't deserve your attention. That doesn't mean they shouldn't be done, it just means somebody else should do them, using less specialized tools.
- robomartin 7y agoAnd that’s where you are wrong. Who builds the same product they were building 15 or 20 years ago? It never gets simpler unless what you are working on is trivial. Technology has always been about pushing the limits. You never have enough chip resources, speed and computing power to spin the next step up in a design, much less keep up with the state of the art in any non-trivial domain a decade or two later. Put a different way: If you are using FPGA’s correctly they will never be like software...because that’s wasteful of resources and performance. If it’s easy and “like software” it can probably be done in software with an off-the-shelf CPU/GPU.
- ncmncm 7y agoNot true. Many, many people have so much computing power to spare they program in Python. In some cases Python isn't up to the job, and C++ on a microcontroller isn't quite, either, but a cheap FPGA could do it easily. What is true is that they don't hire you for those projects. People who have harder problems and enough money to bring you to bear do. But you are far from representative. Are they using FPGAs correctly? Who cares? They don't.
- robomartin 7y agoIt would sure help your case if you provided representative use cases. Look through Xilinx application notes and the reality of FPGA’s is very clear. It’s fine to discuss these things academically, but, as a practitioner and businessman the demarcation lines are very clear, both on technical and financial grounds.