> 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.
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.
Well, we might have to disagree. Implying that it is just a matter of math is almost like saying that any programmer could just walk in the shoes of an EE by just doing some math. Which, of course, isn't even remotely true.
I have a high-school age kid. I taught him Java, C and chunks of PHP. He's already written a half dozen simple games. All of that in about a year of sporadic time. Now I am gettimg him started in electronics. The road ahead is far more difficult than learning to program in any language. Buying Arduinos isn't knowing electronics. There's a vast difference between using an Arduino and designing one. And, BTW, that's relatively simple embedded stuff.
I am not saying that a talented software guy can't learn to design with FPGA's. Not at all. Talented driven people can do anything with enough motivation. All I am saying is that EE doesn't magically turn into software development just because one is using an FPGA. Examples of the complexity and range of disciplines required abound, things like thermal design, signal and power integrity are disciplines in and of themselves that are often the domain of specialized EE's in design teams. The first time I laid out a design with clocks ranging from tens of MHz to GHz, as an EE with excellent command of the science behind the task at hand, it took me months to get it right. That had to work perfectly before my FPGA design and embedded code had even the slightest chance of making the board go.
I don't think he meant that EE is just a matter of math, but rather that branching out into EE can be thought of as analogous to branching out into math.
> 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
If you're thinking about CGI, honestly I'd say that the maths really isn't that hard. Most of it is basic linear algebra and a bit of signal processing.
I might be biased in saying that (because I have a solid maths background as well as a computer graphics one) ; but I've done a lot of electronics as well (including working on FPGAs) and I still feel that EE is a whole different world.
(Off-topic: I realized that you were the guy behind the C++ FQA. Thank you a million times for that! )
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.