4 ms·

If the focus of your work is to replace discrete embedded processor blocks with FPGA's, sure, copy, paste and include might get you pretty far. That is not the

If the focus of your work is to replace discrete embedded processor blocks with FPGA's, sure, copy, paste and include might get you pretty far. That is not the case for all applications, not by a longshot. For example, I had to build a DDR memory controller from scratch in order to squeeze the last clock cycle of performance out of the device. Off the shelf cores are often very --very-- general purpose, badly written and poorly documented. The same can be true of real time image processing constructs where something like a hand-coded polyphase FIR filter can easily run twice as fast as plug-and-play modules floating about. Then there's the element of surprise. If, for example, I was developing an FPGA-based board for a drone or a medical device, I would, more than likely, require that 100% of the design be done in house (or crazy extensive testing be done to outside modules). Anyone in software has had the experience of using some open-source module to save time only to end-up paying for it dearly when something doesn't work correctly and help isn't forthcoming. If the software you are working on is for a life support device it is very likely that taking this approach is actually prohibited, and for good reason. While I fully understand your point of view, this is one that reduces software and hardware development to simply wiring together a bunch of includes. In my experience this isn't even reality in the most trivial of non-trivial real-world projects. FPGA's are not software. I see these "FPGA's for the masses" articles pop-up every so often. Here's what's interesting to me. If you are an engineer schooled in digital circuit design, developing with FPGA's is a piece of cake. There's nothing difficult about it at all, particularly when compared to the old days of wire-wrapping prototypes out of discrete chips. Sure, there can be a bit of tedium and repetition here and there. At the same time, one person can be fully responsible for a ten million logic element design...which was impossible just a couple of decades ago. If you don't understand logic circuits, FPGA's are voodoo. Guess what? A carburetor is voodoo too if you don't understand it. Let's invert the roles: Ask a seasoned FPGA engineer without (or with superficial) web coding experience to code a website --server and client side-- using JS, JQuery, HTML5, CSS3, PHP, Zend and MySQL. Right. Then let's write an article about how difficult web programming is and how it ought to be available to the masses. Then let's further suggest that you can do nearly everything in web development via freely available includes. I happen to be equally at home with hardware and software (web, embedded, system, whatever) and I can't see that scenario (development-by-includes) playing out in any of these domains.

VLM 14y ago
I agree with your design comments WRT approximately 0.1% (or less) of truly exotic level embedded work, like for military aerospace. That does not invalidate it for the other 99.9% of embedded devs. To a greater or lesser extent its just fear of the unknown. I could subject your post to copy and paste conversion and it would ring true with the conversion from mech timers to electronic contro, or discretes to ICs, or microcode based CPUs, or SBC microprocessors to single chip SoC microcontrollers, etc. The industry will adjust, over time. "Anyone in software has had the experience of using some open-source module to save time only to end-up paying for it dearly when something doesn't work correctly and help isn't forthcoming." LOL write it yourself merely means you reinvent the wheel complete with having to discover and patch all the obvious bugs first, before you even begin to catch up to the hard bugs. "simply wiring together a bunch of includes" What I'm getting at, is much as no one would be crazy enough to write their own homemade Perl database driver instead of using the world's universal standard to do the job, no one in FPGA land is crazy enough to write their own Z80 core when the T80 core at opencores has about a decade of R+D, and more importantly debugging, behind it. Plus or minus crazy regulatory/licensing requirements of course. "If you don't understand logic circuits FPGA's are voodoo" Yes insane race conditions and clocking issues are "fun". Fast digital is very much analog that is hidden behind the curtain... "...ignore the man behind the curtain..." Then again my car transmission, my wife's coffee maker, my clothes dryer, my microwave, and my dishwasher will never, ever test the boundaries of modern digital logic speeds so we're back at the 99.9% vs 0.01% argument again. "you can do nearly everything in web development via freely available includes." Well, yeah. What I am getting at is writing your own homemade clone of script.aculo.us or buying an expensive clone of it would be a complete disaster compared to just including "the real thing" and using it.
- robomartin 14y ago
  You've mentioned using processor cores a few times now. I'll assume, perhaps wrongly, that this might be a representation of your world when it comes to using FPGA's. 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.

VLM 14y ago

I agree with your design comments WRT approximately 0.1% (or less) of truly exotic level embedded work, like for military aerospace. That does not invalidate it for the other 99.9% of embedded devs. To a greater or lesser extent its just fear of the unknown. I could subject your post to copy and paste conversion and it would ring true with the conversion from mech timers to electronic contro, or discretes to ICs, or microcode based CPUs, or SBC microprocessors to single chip SoC microcontrollers, etc. The industry will adjust, over time. "Anyone in software has had the experience of using some open-source module to save time only to end-up paying for it dearly when something doesn't work correctly and help isn't forthcoming." LOL write it yourself merely means you reinvent the wheel complete with having to discover and patch all the obvious bugs first, before you even begin to catch up to the hard bugs. "simply wiring together a bunch of includes" What I'm getting at, is much as no one would be crazy enough to write their own homemade Perl database driver instead of using the world's universal standard to do the job, no one in FPGA land is crazy enough to write their own Z80 core when the T80 core at opencores has about a decade of R+D, and more importantly debugging, behind it. Plus or minus crazy regulatory/licensing requirements of course. "If you don't understand logic circuits FPGA's are voodoo" Yes insane race conditions and clocking issues are "fun". Fast digital is very much analog that is hidden behind the curtain... "...ignore the man behind the curtain..." Then again my car transmission, my wife's coffee maker, my clothes dryer, my microwave, and my dishwasher will never, ever test the boundaries of modern digital logic speeds so we're back at the 99.9% vs 0.01% argument again. "you can do nearly everything in web development via freely available includes." Well, yeah. What I am getting at is writing your own homemade clone of script.aculo.us or buying an expensive clone of it would be a complete disaster compared to just including "the real thing" and using it.

robomartin 14y ago
You've mentioned using processor cores a few times now. I'll assume, perhaps wrongly, that this might be a representation of your world when it comes to using FPGA's. 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.