How FPGAs work, and why people will buy them (2013)
embeddedrelated.com
embeddedrelated.com
This is the problem with FPGAs. Their performance and utility is not really disputed. Working with them is so un-ergonomic that it's frankly embarrassing.
The EE world is notoriously closed/proprietary making it incredibly difficult to explore novelty or customize tooling to suit specific needs. The situation is reminiscent of the pre-gcc era proprietary C compilers. Sure synthesis / place and route are much harder problems than compiling to machine code but I would guess that fact amplifies the need.
One can't really expect software's current development comfort without acknowledging its driving force (GNU/the free software movement).
See the IEEE.
> IEEE tracks a vast number of open standards
As for the IEEE 802 standards, it seems like individuals can get full access to all specification documents that are 6 months and older via the IEEE GET program: https://ieeexplore.ieee.org/browse/standards/get-program/pag.... That sounds pretty fair, no?
In general, standards groups provide access in a similar way to software companies that give out free (or low-cost) access to their tools for open source developers and university students.
I took a couple undergrad classes in CE, which makes me dangerous, but can we be that far away from building a macro system to convert small bits of imperative code into FPGA logic?
If your complaint is principle based on the stuff being non free software, then it holds. If it's on usability - not sure it does. While lengthy, the process of compiling and getting something running on silicon didn't seem any more complicated than Grade/Maven etc all based Android Studio builds.
I'm not sure many people would share your opinion that Gradle/Maven are uncomplicated.
Personally, I would say they belong to the 20% most complicated build toolchains I have encountered - which would make the FPGA process still not very uncomplicated in comparison.
I actually agree which is why I used that as a comparison. Over a million developers deal with it every day of their work lives and the FPGA tooling I dealt with did not seem any more complicated than something that's very mainstream.
The last time I worked with Vivado, I remember our interns couldn't manage to create a project or use an existing project after a whole week. It doesn't help that there are no tutorials from the vendor or the internet, or that projects can't be stored in source control.
I was told it cut out something like 95% of candidates who looked good on paper. It was an interesting approach.
I don't blame them. I tried and couldn't get it working in a day either. We were lucky we found another guy in the company who worked with that board on a different project. He showed us and he had extensive notes to get the environment working.
Embedded development really sucks.
But the amount of people who are still going the raw c route for often times unfounded reasons (c++ is slower or has more bloat), prefer one large c file, don't do code based testing, etc, in embedded is staggering.
And for more niche areas (like FPGA) it's extremely behind the times. Not to say c is behind the times, it has its time and place, but 99% of the time they aren't bale to properly articulate it.
They didn't have to hit everything, but a couple of general multiplier design points - throughout and area? A MAC, or a straight multiplier? Shift add? Do they know enough to try to hit a certain primitive (DSP48E, fast carry chains?).
The wizard-only designers frequently couldn't even understand the question, and were incapable of discussing tradeoffs of area/time/resources.
What I try to do is give candidates a bit of a hand - don't remember UART? What about SPI or I2C? Don't remember either? Ok, how would you design a communication block that looks like this (SPI).
I ask fundamental questions- what's synthesis? What's place and route? Explain timing to me. What underlies the logic minimization at the heart of FPGAs? There are a lot of questions to ask - I try to keep moving if a candidate gets nervous so that I can focus in on something that they can answer. For a lot of young people, especially tech types, if you can get them "on a roll" with something they did or were excited by, their anxiety will drop away and they'll do better. Generally we want to see what you know, but also how you think.
For more senior candidates, I take a similar approach - but I'm trying to identify weaknesses. So instead of a glide path to another problem, I'll use your answer to identify a weakness. Gave a marginal answer about something? Ok, let's see how they handle a hypothetical about pipelining, clock domain crossings, timing violations, block level design, proper reset usage, etc. We have a few questions about math implementations, timing violations, etc that are in our stable as well that have proven to be real destroyers.
There is a fundamental understanding about space, memory, and time that a good candidate will be able to grapple with that a marginal one won't - "Design two versions of this block - a small one, and a higher performance one, in broad strokes. Discuss the difference between them". - Area, throughout, latency.
Also: Show up on time. Do your best. Stay positive. Admit what you don't know. Ask questions when you're stuck. Try to learn something while you're there.
If you can find someone in the industry that is willing to do interview prep with you, do it. When I just got started, somebody sat with me and did mock interviews. It helped me a lot, so I try to pay it forward by doing that for my interns to help them get into the industry.
It's a great time to be in the game. Learn all you can, develop your passion for it, and you'll do great.
That being said, I’m also not sure the issue is entirely developer ergonomics. Personally I think the fact that the hardware is something you have to go out and buy versus just coming stock in your computer is more of a factor in developer onboarding, and the resulting mindshare.
EDIT: your cpu ISA is open, but fpga layout/bit-stream is not--locking you to your vendor's innovation and ideas for how things should be done.
People did interesting things chipping away with rocks as well.
I'm not aware of any soft resource one can't completely control in Vivado/Xilinx as every hard resource can be completely described in your own design via the primitive library. That doesn't mean it is always a good idea, but one can do it.
There's your sandbox
EDIT: If you cannot replace their tools with yours, it is a sandbox.
• Individual LUTs, with optional local or dual outputs (LUT1, LUT1_L, LUT1_D, … LUT6, LUT6_L, LUT6_D)
• Flip-flops (FDCE, FDRE, etc)
• The carry chain, which can be instantiated directly (CARRY4), or as its individual elements (MUXCY, XORCY)
• Shift registers implemented in LUTs (SRL16E, SRLC32E)
• Dynamically configurable LUTs (CFGLUT5)
https://www.xilinx.com/support/documentation/sw_manuals/xili...
https://www.xilinx.com/support/documentation/sw_manuals/xili...
Can you say anything nicer about it than that? I've used Make, ant, and cmake, I've built and packaged multiplatform GUI apps using Eclipse RCP, I've built modern web apps using npm and babel, and building Android apps was the single worst experience out of all of them. Comparing a toolchain to Android sounds more like a takedown than a defense.
Now, I'm personally of the opinion that their competitors have taken their chips into one of those nifty 3d xrays and know the exact layout of the cells anyway, but it's hard to push that idea.
https://vtechworks.lib.vt.edu/bitstream/handle/10919/51836/S...
It has a lot of details on things that are clock-related. Since Im not hardware guy, I can't ssy if it has info needed, if another work could get it building on this, or what. So, what you think?
What he covers (for the purpose of this discussion) is how the clock blocks (straight up PLLs if you've done any embedded development) are connected to the rest of the fabric. That's sort of the digital side, and the hard part is the analog side. Ie. "what are the propagation delays of different configuration of LUTs and fabric, and who can you play games with in place and route in order to meet timing". It's an important feedback step in place and route. You can get neat trivial stuff running, but without decent timing analysis it'll be hard to tell if your design will have weird bugs at runtime. Or will lack optimizations that will help you meet timing with an equivalent design. I mean, that stuff is almost a black art even with high quality timing analysis.
The EE world could use novelty tooling to increase the efficiency by which you create RTL. But that can easily be done today if you consider Verilog to be an intermediate representation.
So I think you're talking about the tooling on the steps to go from RTL to bitstream? What kind of novel tooling do you have in mind?
In Quartus and ISE, once you've set up the pin assignments, going from RTL to a bitstream is a matter of a single click.
To get the most out of hardware, you need feedback on how many LUTs each part of your design uses, where the critical dependencies are for the achievable clock rates, and so on.
It's difficult to get this information in a usable way in practice today even when you're writing Verilog. Using Verilog as an intermediate language makes the problem significantly worse.
Imagine there was the equivalent of LLVM for FPGA development. Without open bitstreams, that's never going to happen. (Even with open bitstreams, it'd need tremendous effort to get there, but at least there'd be a chance.)
In practice, if you code your Verilog with speed in mind (limited levels of combinational logic, plenty of pipeline stages, one-hot encodings, ...), the synthesis and fitter tool will do an excellent job of extracting high speed. The modern ones will do register clone, pull in registers into RAMs and DSPs etc.
In case of timing problems, the timing analyzer will already show you the critical path, the amount of LUTs, and how the critical paths is routed.
The hardest part of figuring out why a particular path is violating timing is not because of the reporting of the tools, it's because a blob of logic has been flattened and merged into a LUT, and it's hard to identify how a LUT corresponds to the RTL.
Maybe a custom tool can help debugging these kind of things, but I think it's a very narrow case, and IMO not the kind of thing that makes EDA tools unergonomic.
> It's difficult to get this information in a usable way in practice today even when you're writing Verilog. Using Verilog as an intermediate language makes the problem significantly worse.
That was not my point.
My point is: if your goal is to make FPGA design more ergonomic (whatever that means), there's a much higher !/$ in improving the front-end design process than the back-end.
... and we have no realistic hope of figuring out whether maybe the tools can be improved to help with that, because the tools aren't open :)
> if your goal is to make FPGA design more ergonomic (whatever that means), there's a much higher !/$ in improving the front-end design process than the back-end.
And my point was that it's impossible to do Pareto improvements as long as the back-end is a black box. Like, you could come up with a better high-level language for the "front-end", sure. And that new language may be more convenient for writing a design.
But if the way you synthesize this new language is via Verilog, then those nice features you mentioned, like for showing the critical path, will de facto be lost -- because the closed tools will show you the critical path in the intermediate Verilog. And if you've ever actually worked with HLS tools, you'll know that this intermediate Verilog is totally opaque unless you spend a very large time understanding the translation tool.
The new "front-end" solution will be better in some respects, but certainly worse in others, and the only way to get improvements across the board is if you have control over the whole "stack".
So I think you're making some good points, but I feel like you're missing the larger point that a truly open ecosystem is desirable precisely because improvement may come in places and from places that you would never have considered.
I can get the critical paths, device utilization, power, etc. from every vendor's software suite I'm aware of. And they are all fully scriptable from the TCL interface. Once I have a mostly stable design, I usually run Xilinx/Vivado from the command line. Same with Lattice. The reports the vendors provide are much better than what would get from the raw bitstream because it has all the symbol information. What you're proposing is akin to decompiling c from object code.
Also keep in mind there is huge variation in architectures between vendors, products, and the various product categories. For example, few things LUT based anymore. Now we have macrocells, "logic elements," and slices, etc. and that's just the soft stuff.
People have been working on implementing FPGA in higher level languages for years. Even LLVM to RTL has been tried a few times. I've observed matlab to RTL is starting to catch on in the DSP/control-system crowd.
For example, according to the Intel Arria 10 handbook, an ALM contains 2 4-input LUTs and 4 3-input LUTs, which can be combined in various ways. (See figure 7 of the A10 handbook.)
http://www.rapidwright.io
Honestly, though, I'll take absolutely none of that if an open source tool means you can just fix some of the bugs in the damn things.
[1] I assume they revoked it in the first place due to some outbreak of batshit insanity in a legal department somewhere -- presumably some of the source code should not have been released, or someone's mind changed, or something.
The interesting thing about HDLs and HDL work flows is that they can "look" like software and yet not be software. VHDL and Verilog are the only "languages" I know where you can write something that is both syntactically correct and cannot by inferred into logic by the synthesis part of the tool (equivalent of the code generator in a compiler). I am not aware of any equivalent to the Turing definition of computability which would prove for any legal construct in language X there was an implementation of synchronous logic Y that could implement it. Most of the bugs are easy to avoid once you know them though, things like a register value being assigned two different values in the same process block.
That said, I've been playing lately with an "Ultra96"[2] board which is pretty freakin' cool. quad core 64 bit ARM CPU and a nice chunk of FPGA fabric to play with as well. I think it can be the basis for a pretty sweet SDR setup.
[1] His assertion was that things had to be hidden so that they could protect the value of the software, when I countered they could put a 5% tax on every chip they sold and allocate it to software which would give his team more money than it had today, he argued he would lose sales to cheaper FPGAs, and I asked how the people trying to sell C compilers were holding up, and would anyone buy chips if they had to pay extra for their tools when a top chip maker gave away their tools for free? And then he said it needed to be proprietary to keep the quality up, and I went back and asked what C compiler he used, and he admitted they used GCC (when they were compiling for Petalinux etc) and I asked why they didn't use a proprietary C/C++ compiler? And he said they didn't keep up with the standards and gcc generated just as good code generally as the proprietary ones did. He was left with "just because" as his only rational for not making all of the documentation freely available and using the cost of the chips to leverage the tools cost (which I told him would go away as soon as the open source community had caught up with and surpassed Vivado)
What problem are you unable to solve with an FPGA because you do not have the source code to Vivado?
I understand why Xilinx doesn't want to release their source. They don't want to support it. Supporting code is a huge overhead and it's not clear, to me anyway, what Xilinx gains from the expendature.
This is untrue. [1]
> Supporting code is a huge overhead and it's not clear, to me anyway, what Xilinx gains from the expendature.
In what world is this the case? You host the project on github or the like and let people contribute bug fixes at the cost of filtering pull requests. Letting the community contribute bug fixes is a huge reason companies open source their tools.
[1]: https://www.xilinx.com/products/design-tools/vivado.html#buy
It's not as simple as an upload to github. https://opensource.com/business/16/5/how-transition-product-...
Xilinx ISE is indeed deprecated. There are quite a few parts in production which it will still generate bitstreams for, though.
Vivado is the newer replacement. It will not build designs for parts older than 7-series, though, so Xilinx ISE is still required to work with 6-series and older parts, as well as with Xilinx CPLDs.
WebPack licenses are not deprecated. The WebPack program is still active, and will generate limited licenses for both Xilinx ISE and Vivado.
If they did just that, then the source code would "appear" as people wrote back ends for the various open source HDLs that are already in existence.
The challenge that I see is that Xilinx has already had the experience of selling that data to vendors like Synopsis who sell their own synthesis tools and charge major money for them. And like a person who holds an unvested stock option for a stock that goes from price A above the strike price, to a price B that is below the strike price, they feel as if they "lost" money. Similarly, Xilinx can't see "giving up" thousands, if not millions of licensing dollars they are getting from tools vendors, just to enable an open source community to start. Because they fundamentally can't see that having a vibrant open source ecosystem benefits all players. And this in spite of the gcc example which is pretty incontrovertible in my opinion.
A decade ago, programming GPU shaders was similar to that. You could use a higher-level language but there were tight limits on everything, instructions, branches, texture lookups, etc. Here’s a summary for GL, DX was the same because they were hardware limitations of corresponding GPUs: https://stackoverflow.com/a/5601884/126995 Modern GPU chips are way more capable so that’s mostly history now.
Also HDLs are not alone in having 'quirks' that experienced engineers need to know about.. c/c++ for example. cough undefined behaviour cough
Code coverage and quality checking tools are quite good in the EE world, verification has some powerful tools to almost eliminate hardware bugs - which is especially important for asic design.
On the open sourcing of tools - there are free ones, that target real FPGAs - so can you say why these have not surpassed vivado? In fact, while impressive in their own right, they are very primitive in comparison to vivado despite being open source for years. The open source verilog tools also don't fully support all of verilog 2008/2012.
So I don't buy the open sourcing argument for the synthesis and pnr tools would dramatically affect FPGA sales. Instead higher level compilation and abstraction may be the key.
It's honestly not possible to have a "defined behaviour" in all circumstances - verilog simulators don't define event order, if you depend on them stuff will break (we all fought that battle 20 years ago), more importantly you kind of hope stuff breaks to indicate you might not be building designs that work on real hardware
2: if the tools were open source, people would be free to improve on these bags of pain that we have the pleasure of spending thousands of dollars per license.
To your example, 'I don't see Intel open-sourcing ICC'; while it would be really nice if they did[0], it's not a requirement in the same manner that it wasn't a requirement for gcc to exist.
I could be wrong here -- I do not develop for the FPGA space, however, I've run into similar problems all over the embedded space. Try developing something on one of ARM's Secure MCU products that lands comfortably in just the "open-source software" category (skipping hardware all-together). It's...tricky. To get details on the design of the security features of these products, you have to execute multiple NDAs. And this is in a security space where openness is considered a security feature. In theory, at least, if you interact with one of these NDA-protected features, publishing the source code might be a violation.
Unfortunately, I suspect that many of these features are as good as the secrets that are kept[1] -- exposure of the documentation would likely yield viable attacks[2].
[0] Not the least of which would be to be able to port some of the optimizations that icc enables for Intel processors but disables for AMD/others to be able to be used on...AMD/others.
[1] To clarify, I have not signed any NDAs with ARM, so this is entirely speculation. I'll be a party to one, shortly, so I won't be talking on the subject assuming -- as I suspect -- that doing so would run afoul of the NDA provisions.
[2] At some point the hardware world will learn from Intel and others that security through obscurity ...isn't. As with Intel, as far as we know, the issues they experienced with their management component existed for years without breach. The vulnerability was shockingly bad, was almost certainly known by adversarial governments and black-hats, who kept it a guarded secret as carefully as Intel kept the details of their management component secret. So they succeeded in keeping attackers in business and customers in the dark ... making everyone feel secure.
[1] https://wiki.myriadrf.org/LimeSDR-Mini_v1.1_hardware_descrip...
[1] https://www.xilinx.com/support/documentation/selection-guide...
[2] And yes I know I would need a ZU4EG rather than the ZU3EG that is on the board. If I was doing my own board I'd use the 4EG and add some extra memory attached right to the FPGA fabric.
iCEBreaker FPGAhttps://www.crowdsupply.com/1bitsquared/icebreaker-fpga
full disclosure: I will likely get an enthusiastic "Thank you!" for dropping this here.
http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2...
They are old, and you need a slightly older version of the Altera Quartus software suite, but they are dirt cheap.
Go to eBay, search for EP2C5TQ144, and you can find development kits including programming cable starting at $3.50.
The FPGA is tiny, but it has quite a bit of RAM, a bunch of hardware multipliers, and a sufficient amount of logic gates to create your own 32-bit RISC processor if you feel like it. And because it is so tiny, full synthesis and place & route run will take a few minutes.
You may be tempted to go the open source route with a Lattice ICE40 FPGA. There are now tons of board out there with this FPGA, and being fully open source is great. But once you start debugging, you'll be without all the goodies that come with Altera, especially SignalTap (an on-chip synthesized logic analyzer.)
Chances are that you will never outgrow the EP2C5 FPGA because you'll lose interest and move on to something else. But if you outgrow it, all you've wasted was one latte at Starbucks.
What feature gives them a taste of an FPGA?
https://www.eevblog.com/forum/projects/no-bitbanging-necessa...
FPGA's are a pain because you get a gigantic quantum jump in complexity right away. For example--a system clock. Do you want a single one? Okay, now you have to deal with distributing that clock and dealing with termination and reflections. Do you have more than one? Okay, now you need to deal with synchronizers right out the chute.
For most hacker types, the Cypress chips are a MUCH better match to what they need to do. Generally these digital tasks break down into something like "Catch a very tight margin digital signal, respond with ACK and wait signal, and signal the core that something needs serviced." (example: communicate with a GPIB device) or "Have a tight feedback loop that receives slow commands" (example: PWM for a motor with an encoder).
But the original question was which would be a good FPGA learning platform. I don't think the Cypress MCU are the best way to learn about FPGAs.
Similarly, your example of a system clock is only relevant if you're thinking about designing your own boards. That's even more beyond the scope of the question.
The AWS F1 devkit and APIs are largely oriented around making OpenCL-based designs easy and fast to develop (using Xilinx's "SDAccel" framework), but if you're just starting out you almost certainly want to start with classic RTL development using Verilog or whatnot. But "traditional" RTL development is substantially more involved. The documentation and the environment itself is largely oriented with the assumption you're a semi-experienced RTL developer and there's no real way around that part. (For example, even when using OpenCL, you're going to have a hell of a time optimizing anything without understanding real RTL/digital design principles.)
The F1 also has a non-trivial build system, meaning you have to do literally everything on AWS. Not a deal-breaker, but considering the equivalent of a "Hello World" will take you something like 30+ minutes to compile using something like a t2.2xlarge, and anything beyond that will be multi-hour (yes, this isn't an exaggeration) -- you probably don't want to just be spending money on every minor iteration.
I would suggest getting a cheap Lattice FPGA and using Project Icestorm, which is a free FOSS Verilog toolchain, in order to get started. This will cost you closer to $20 USD. https://www.latticesemi.com/icestick and http://www.clifford.at/icestorm/ -- there are allegedly good books on Verilog, but I'm afraid I can't recommend any myself...
After that, when you've got a big enough design where the monstrous VU9P -- the Xilinx chip used in the F1 -- is relevant to your interests, you'll know. :)
Source: I worked on moving/porting our designs to the AWS F1 (traditional RTL based stuff, not HLS/OpenCL -- and it was surprisingly challenging, up-to and including talking with AWS engineers directly to resolve bugs in their datacenters. And I was the software guy!)
EDIT: in fact I just looked up some benchmarks for Ryzen and it can do 3GB/s per core. So that should be enough
Doing crypto on a separate chip lets you keep they key away from system RAM and CPU cache, removing any possibility of leaks into other programs.
The thing is, if you're going to do ubiquitous encryption for something like your SATA link at scale, with a lot of units being sold -- you're better off just using a dedicated ASIC with a fixed algorithm, and your performance/power profile will skyrocket even further.
- If many units are being sold, BOM choices matter. People optimize part choices down to fractions of a penny on individual units when scale is large; ASICs and FPGAs are differences in dollars, it's a completely different order of magnitude. Power usage is similarly important for the same reasons. Cost is king, and nobody will buy/integrate your 20x more expensive SATA adapter when another alternative exists that does the same job, cheaper, faster, with lower power. So what about all that alleged 'security' advantage when nobody uses your chip at all?
- There is no indication cryptographic agility is actually advantageous for any given design, it can only be assessed in the context of a threat. It may in fact be a detriment due to exposing further attack surface (e.g. you now need a secure update mechanism). This is important because the design phase is absolutely critical and takes substantial amount of the overall development/market time -- so you don't introduce extra complexity if you don't have reason to believe you need it. (And it's also why you just tend to buy many components from other vendors, because paying a bill to them is cheaper than paying your engineers to recreate everything while assuming they won't fuck up. I'd guess that very few actual FPGA/RTL engineers actually implement AES cores outside of university, as opposed to just reusing an existing one...)
Ultimately all of this comes down to your design requirements for the product, but flexibility can come with costs and in terms of money it definitely is not free.
As well as the possibility of the crypto "code" (HDL) being open source.
They're even starting to be used for some consumer electronics.
The article is not really talking about that though, it's more about having FPGAs in mainstream desktop computers. This is still far from a reality, even if Intel seems to be pushing for it.
My point is that back then (a decade or so ago and farther back) it was relegated to low volume, high margin products, explicitly as a replacement for an ASIC. This was due to the cost of the FPGAs.
The point of this article is that by embracing the reprogrammable nature, they'll make their way into places that in fact have the volumes required for an ASIC (which might not be nearly as big as you might think), but choose an FPGA anyway in order to reconfigure out in the field. We are starting to see this and I'm seeing fairly cheap consumer electronics positions (ie. products in the range of a hundred or so dollars) asking for HDL experience more and more in my area.
Desktops aren't the only mass platform out there.
- Rigol oscilloscope
- National Instruments DAQ equipment
- Mecco laser cutter
- DJI drone
Any others where I might not have taken it apart and seen the big QFP with "Xilinx" or "Altera" on the circuit board would be interesting!
The Model S has at least one FPGA, as do some of Ubiquiti's products. I don't know about the Thinkpad, but Apple has used cheap Lattice FPGAs for interfacing between different hardware components. Macbook Pros have used them in the past (IIRC for driving the display and interfacing with the battery), as have iPhones.
Here's an interview with Rob Watts, a DAC designer who's getting the best measurements in the industry right now with his Chord DAC's (specifically Chord DAVE) http://www.the-ear.net/how-to/rob-watts-chord-mojo-tech