One stark flailure of the Altera acquisition is there has been little by way of tool chain integration. This is a CPU with a bag on the side, and that bag needs people that write HDL and understand computer architecture to make good use of. It's not really a harsh critique, but a warning that the lower you go is an increasingly smaller number and expensive lot of folks. Intel's marketing arm can't distort that reality, and their product development arm seems too taxed to bridge the gap.
> increasingly smaller number and expensive lot of folks.
There is this sentiment on HN that people in EE/embedded space don't really get paid well (compared to the average Javascript-slinging frontend dev). Is this not true for HDL folks?
We get paid bank, there are very few of us, and the older you get and the more horror stories you've seen the more you're worth (unlike software). Gray in your beard is a feature, not a flaw.
You're responsible for time critical and/or DSP things that are critical system architecture, and will never be outsourced (it's key IP, you'd be stupid to outsource that).
Don't let anyone know, we have a good thing going on.
It does get outsourced. I worked on a team that did a dsp/crypto multi core chip. The funny part is 90% of the team has now moved to US because they got paid better.
That doesn't usually stop companies. At best it creates an opening for new companies to recapture some high-value markets once the dust from the off-shoring stampede settles.
I know I took a digital logic course and did some fpga implementations in it, man that was hard. I am petrified of having to deal with HDL in the near future for my research, maybe I'll take a class or something.
In school they make you do it the hard way. I find verilog to be very similar to my process of how I write embedded C code.... short version is if you can make block diagrams and write good C, you can learn verilog.
If you want to learn, there’s a ton of free training on the major vendor’s sites (Intel FPGA and Xilinx), and a development board with everything you need might run you a few hundred. But I don’t know what your job prospects would be without a degree in EE/CompE or experience in the hardware industry...
I get paid 130k with a phd EE from tier 3 with <3 years industry experience. If you want to get in get ECE and study computer architecture and RTL. I am doing hardware modeling to predict future performance. It’s difficult to get in the industry from a tier 3 w/o experience but it’s worth it. My counterparts in FAANG are no doubt getting 300k/year. Sometimes I think maybe I should leetcode and get a software job @ FAANG because HW is difficult.
Allow me to introduce myself... not really becsuse anoniminity. But I’m effectively an EE at my company with no degree. Hardware, firmware, software, sourcing, production, validation/testing, and low volume assembly, all self taught. I’ll grt into FPGA when I have a use for it, but it certainly won’t be FFTs and DSPs but still.
I’m glad I don’t have to job surf, it would be hard without paper, but my experience would be very valuable in my tiny field.
For sure technicians that do these are a thing for finishing work, who may have AS degrees instead of BS EE. I've worked with them as well. They were always referred to as technicians that EE's hand-off more of the board-level debugging to (or even GDS II for ASIC design..). The core datapath processing algorithms were always done by EE's, though.
I work on operating systems, which is similarly niche (but probably overall easier to learn and low risk vs fabbing ASICs) an it is very bi-modal. Sr. circuit designers can write their ticket, but you have a lot of warm bodies surrounding them at large companies.
Hi, does your team have an opening? I work on performance modeling and am always curious if I could make the jump to low-level system software and learn a ton of stuff for a while.
I'm not even sure they're going to let you program the FPGA drectly (with HDL)?
I expect the main workflow will be using OpenCL to offload arbitrary work to the coprocessor along with a few Intel-provided modules capable of common tasks.
The great thing about having the FPGA on-die via UPI is that the cache-coherency, decreased latency and massive bandwidth will allow much more granular offloading of work. This is as compared with PCIe coprocessor where it only makes sense to offload larger chunks of work and minimise the communication and data passing between the two.
The greater the granularity of work that we can offload, the more viable the OpenCL/high-level synthesis/heterogeneous computing type stuff will be, as it will integrate more seamlessly into existing software development methods. This is the holy grail at the moment for FGPA vendors: to get to the point where software developers can program them on their own.
As to your point though I guess we'll find out soon what the dev tools for this will actually look like.
Using OpenCL to program an FPGA is a significantly more difficult task than programming in HDL. Atleast for what would be relevant to a Xeon co-processor. The OpenCL flow is just terrible at getting to the performance levels you need to realistically offload anything from a Xeon. Intel are certainly working on it, but that's not a realistic proposition for the next 5 years, and if the Xeon+FPGA isn't already successful in that time frame, it'll be canned long before OpenCL is a solution.
From what I've seen the only applications for this will be pre-canned FPGA images that were written in-house by Intel for things like encryption or FEC.
I'm not so sure - it's a fantastic fit for GPUs, FPGAs make sense for stream processing for video encoding - but that's more of a discrete device play where you can plug the video feeds directly into the FPGA daughter board.
Learning an HDL isn't that hard. But it's a very small part of the overall flow for real development, and arguably it's one of the easier parts anyway... That's sort of the "problem", more or less.
Even very well-oiled products like the Amazon F1 and Intel's new acceleration cards are pretty non-trivial to use unless you're an experienced engineer, and they clearly spent a lot of time polishing off the roughest edges to make it as approachable as possible. Amazon more or less paid a team of seriously experienced people to make the whole flow as painless as possible (including a pretty good software SDK, and a lot of tooling around Vivado), and it's still non-trivial!
Some of the ARM/FPGA combos are a lot more approachable overall, but the tooling, BSPs etc are normally huge pains the moment you want to get creative, and the SDKs are comparatively worse, vs the "high end" ones listed above, in my opinion. Normally I just end up replacing them with my own Linux BSP, more or less, if I need the actual host side.
A really annoying aspect of all this though is that most kits which could offer features like high-speed peripherials (PCIe, etc) are pretty expensive for hobbyist developers to acquire and use, so there's certainly a bit of a self-fulfilling-prophecy going on here.
Writing HDL isn't hard but doing it right(much like with C) I would argue is the tricky part.
The translation from Software -> Flip-Flops isn't nearly as natural and it's easy to try and apply SE techniques that while possible are totally unsuited for an FPGA.
Witness the many systems that say they can translate something high level to HDL and how poorly they perform compared to an expert. It's so easy to produce logic that will run slowly or be glitchy, and most EE graduates have very limited exposure to designing logic.
There are a multitude of foot bullets that you can generate when synthesizing valid HDL to real world hardware. These languages were meant for specification and simulation and as such allow you to do things that are plainly wrong for synthesis in the real world. It's very easy to generate a circuit that works 99.9% of the time and causes Heisenbugs if you approach it like software programming.
HDLs are fine. I've found the tooling around them to be quite atrocious (slow, buggy, opaque, gui-based) though.
Be it for synthesis, simulation, or even just compiler errors it's pretty bad compared to software.
I’ve started using SpinalHDL, https://github.com/SpinalHDL/SpinalHDL. It’s a Scala DSL that spits out Verilog or VHDL for traditional synthesis tools. But, unlike Chisel or MyHDL, in my opinion it’s a great experience. And, now it has seamless integration with Verilator for simulation, and the open-source Verilator project is very capable—they claim it beats commercial simulators: https://www.veripool.org/wiki/verilator. Since Scala is quite a bit faster than Python, the simulations run much faster than something like Cocotb too!
Have to agree this is a major pain point for wider adoption. The current tools are mainly developed by a few big EDA vendors. I'm hoping, through the growth of open hardware communities, we'll start to see more friendly tools making progress.
How do you get into HDL and FPGAs? Seems like it will become a more and more important skill since all other avenues in performance improvement have come to a halt.
I just picked up a dev board and started making it flash LEDs, put patterns on the seven-segment display, then had a play with soft CPUs. This gave me ideas on how to use the technology in my job - embedded networking.
If you are coming from a software background then maybe look at getting a board with one of the ARM+FPGA hybrid chips, you can run a proper OS on the ARM CPU and I would guess that the bus interface to the FPGA part will be simpler than using Intel's UPI.
Could try something like Icarus Verilog for an open source compiler and start building some toy designs. There are some good communities and blogs to find help.
I guess that is what you get when the entire software engineering field turns to "Javascript and a distributed database" as a solution to everything. There is a lot more out there and people should spend the time learning it.
Co-design for hardware+software is tough, for sure. But the reality is that hardware has to be present to build the software on top of it. People need something to play with. So the "bag on the side" of FPGAs here is kind of like Lego blocks for cache / acceleration. If you are running a DNN for inference, for example, cache is usually your bottleneck. Rent GPUs to train the model, figure out your bottleneck, and build your own isolated and local system for the "expensive lot of folks" to create the valuable IP.
> that bag needs people that write HDL and understand computer architecture to make good use of
Over time I suppose they could have some machine learning that automatically configures the FPGA based on which programs you are running and the types of computations they have historically used.
There’s a pretty cool story about using evolutionary algorithms to program an FPGA for a specific task: https://www.damninteresting.com/on-the-origin-of-circuits. Probably not ML in the sense you were talking but very cool nonetheless. In the end the final result was hyperoptimized FPGA code that only ran on a specific board and used a bunch of nonsensical structures that seemed to be doing nothing, yet would stop the circuit from working if removed!
I remember this, thanks for brining it up,:I had read it years ago and it always haunted me.
The evolved solution involved using only 37 out of the 100 gates available, no clock, and some units were logically disconnected yet disabling them caused the chip to fail at its task, indicating it was relying on EM effects particular to the chip. Truly amazing (and perhaps a bit creepy too).
machine learning that automatically writes HDL programs to match functionality of x86 programs and are more efficient when executed on an FPGA than a general purpose CPU haven't yet been invented...
Nor do I think they will be invented soon. Machine learning is bad at doing discrete things, bad at things requiring zero mistakes, and bad at problems for which the answer can't be perfectly verified (due to needing to solve the halting problem).
I wouldn't be surprised if Intel came up with tools which help make use of the FPGA using higher languages like C.
Xilinx is already pushing it's Vivado HLx which is pretty much that. I'm not aware of Altera's current offerings but they won't overlook this so easily.
Well there you go. So GP's concerns are largely addressed. Intel can just work on this tooling, and people who are going to use HDL are going to continue using them.
Good idea in theory, in practice it's a shit show. The current level of language support is "As long as you know how to write what you want in HDL, then you can write some C that uses custom pragmas and design patterns and attributes that will badly reproduce what you could have written in HDL in half the time".
> I wouldn't be surprised if Intel came up with tools which help make use of the FPGA using higher languages like C.
These (almost by necessity) make you write code that doesn't look like any other C code. You can't just use some pre-existing C library and compile it to use FPGA resources. At that point, why not go a step further and just use a proper HDL?
>At that point, why not go a step further and just use a proper HDL?
You're assuming that you're starting with an FPGA only project. In reality most projects that are going to be accellerated with these Xeon+FPGA systems is existing software where only a handful of hotspots will have be ported to the limited C language which is significantly less effort than rewriting the entire algorithm in HDL.
Because although HDL doesn't look difficult syntax wise, it requires a very good understanding of logic gates. People need to pretty much take a course in digital design to be able to write something meaningful.
It took me a while to grok HDL and write working code (good, maintainable code aside) even though I took digital design courses.
Intel recently released their own High Level Synthesis compiler for Quartus; like HLx, it's free and you can use it now on whatever device you want. You still have to do the interconnection to the CPU, if you have one.
Unlike Xilinx, though, Intel (very very recently) just started offering their OpenCL-for-FPGA SDK for free, and it works on most of their device families, including Arria/Xeon and Cyclone/ARM. I always found it disappointing that the OpenCL SDKs were normally licensed, since they're more-or-less a logical extension of HLS support. So that's nice of Intel.
They don't have any equivalent to Xilinx SDSoC though, but for datacenter targets they're shipping a different set of SDKs anyway (called "OPAE"), so maybe in the future they'll build something on top of the OPAE and OpenCL support (e.g. single-source model, like Sycl)
I don't know if I'd call that programmable, isn't it just sequencing work to predefined logic blocks? Can you do things that were not contemplated by the opencl design?
OpenCL provides a standardization for interacting with accelerators. It is up to the manufacturers of FPGAs to adopt the OpenCL standard. For a while, Nvidia didn't get on board because they already had CUDA and felt OpenCL was letting ATI back in the game. Xilinx makes good learner FPGAs that are compatible with the OpenCL standard.
They've got an OpenCL SDK for it now, that brings it under the same interface that a lot of folks have been using for the Phi and other many core tech Intel has been pushing for HPC.
It's not really that hard to get rolling at this point.
