
How FPGAs work, and why people will buy them (2013) - snaky
https://www.embeddedrelated.com/showarticle/195.php
======
davemp
> FPGAs are a programmable platform, but one designed by EEs for EEs rather
> than for programmers.

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).

~~~
sfifs
Actually I recently bought a Spartan 7 based FPGA board after taking the
nand2tetris course and started playing with the free version of the Vivado
suite.

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.

~~~
ThePadawan
> 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.

~~~
user5994461
Maven is just right click + build to build. Or file + import to import a
project.

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.

~~~
analognoise
I went on an interview once where part of the process was "here is a
development board. Here is a computer and the internet. Make a full adder,
connect the inputs to push buttons and the outputs to LEDs. You have all day,
by yourself, in a cubicle."

I was told it cut out something like 95% of candidates who looked good on
paper. It was an interesting approach.

~~~
user5994461
That's what the interns were trying to do. Get a push button to a LED working,
on a Xilinx SoC, with the Vivado IDE. They couldn't figure it out in days.

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.

~~~
hak8or
Not all embedded. Thankfully there is a sort of standard embedded mcu arch
showing up via arm (would love risc v but I'll take what I can get). This has
support via mainline clang/llvm and gcc, and isn't much work to get a more
modern setup going via cmake, c++17, and clion.

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.

------
tejtm
In case there is some interest in learning hardware

    
    
        iCEBreaker FPGA

The first open source iCE40 FPGA development board designed for teachers and
students.

[https://www.crowdsupply.com/1bitsquared/icebreaker-
fpga](https://www.crowdsupply.com/1bitsquared/icebreaker-fpga)

full disclosure: I will likely get an enthusiastic "Thank you!" for dropping
this here.

------
andyjohnson0
I've been considering getting an Arduino MKR Vidor 4000, which has an
integrated FPGA and is fairly new. Does anyone here have any experience with
this as a learning platform for FPGAs? (I already have reasonable experience
with Arduino) Any suggestions for alternative boards/tech?

~~~
TomVDB
Whenever people ask this question, I'm the broken record with the same reply:
start out with the cheapest kit possible, an Altera EP2C5TQ144 development
board.

[http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2...](http://land-
boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board)

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.

~~~
nraynaud
I'd advise people to start with a Cypress PSoC MCU, they have the taste of
FPGA, but have a lot of useful stuff for various projects, and I bought 10
MCUs for $10.

~~~
TomVDB
I just googled it and they seem to be MCUs with no programmable logic?

What feature gives them a taste of an FPGA?

~~~
snaky
Cypress call it 'UDB'.

[https://www.eevblog.com/forum/projects/no-bitbanging-
necessa...](https://www.eevblog.com/forum/projects/no-bitbanging-necessary-or-
how-to-drive-a-vga-monitor-on-a-psoc-5lp-programmabl/)

~~~
TomVDB
That's much more FPGA-like than I expected.

------
ThePhysicist
Does anyone have experience with cloud-hosted FPGAs (e.g. on AWS), and if so
would you recommend this platform to get started with FPGA programming?

~~~
aseipp
You should not use AWS F1 instances if you are just starting out. They will
burn a nice-sized hole in your wallet and the only thing you'll get in return
is confusion and frustration as a beginner.

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](https://www.latticesemi.com/icestick)
and [http://www.clifford.at/icestorm/](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!)

------
bcheung
This article makes me wonder if adding FPGA units to existing CPUs and GPUs
that integrate with existing silicon makes a lot more sense than having a
completely separate FPGA.

~~~
FPGAhacker
Integration of cpu and fpga has been done for years.

~~~
lucb1e
But not in household CPUs which I think is what GP meant. CPU speeds don't
increase anymore, having an FPGA that can be programmed by software such as
photo editors or encryption engines, things can be sped up a lot. (At least
for crypto, one reason to stay with particular algorithms is hardware support;
we'd be more agile if we could implement that in software without sacrificing
much speed.)

------
floatboth
I wonder if FPGAs would make good crypto devices, e.g. for disk encryption? If
you implement AES on an FPGA, is it fast enough to keep up with at least a
SATA 3 SSD?

~~~
aseipp
Yes, they can do traditional cryptography pretty well (depending on the
algorithm, of course.) AES-128 in an FPGA can encrypt a full 16-byte block
every clock cycle when done right. With 100Mhz clock that's about 2.3Gbp/s,
well within SATA 3 transfer speeds. You can achieve that with a last-last-gen
FPGA that will cost you a couple bucks out of pocket, and it will use a
fraction of the power/thermal footprint of any desktop/mobile processor that
doesn't have AES support. Likewise, you can easily scale this up -- 10gig/s
isn't even worth mentioning because it's trivial, so you can think closer to
40Gbp/s and beyond (which, today -- still not that impressive, I'm just giving
you an idea.)

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.

~~~
snaky
Or maybe, if you're going to do ubiquitous encryption for something like your
SATA link at scale, with a lot of units being sold, it would be nice to only
update the FPGA firmware when the exploit will be found in the implementation
of your crypto.

~~~
aseipp
But no hardware engineer would think of it that way in such a hypothetical
product scenario, if they were designing it. Because:

\- 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.

------
julsimon
Nice article, but it's from 2013.

~~~
monocasa
And to be fair, since then FPGAs have exploded in non ASIC prototyping use
cases.

They're even starting to be used for some consumer electronics.

~~~
LeifCarrotson
I'm interested in seeing some examples of their use in consumer electronics. I
think this article would be a lot more compelling if it had a section on
"You've already bought one if you have a (hypothetically) Roomba vaccum/ Tesla
Model S/ Thinkpad laptop/ Ubiquiti router." I'm pretty sure most of those
don't have FPGAs, but would be curious to see a list of things which do. I am
by no means a representative consumer, but I know there's an FPGA in my:

\- 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!

~~~
monocasa
The iPhone 7 has a iCE5LP4K. Those little CPLDs (which are full FPGAs these
days, but fighting that terminology seems to be a losing battle) are in
everything. Which is fair, they're fantastic power sequencing controllers and
great for coalescing I2C and SPI buses into something more easily consumed by
the application processor. Think an FPGA that constantly polls sensors,
wrapping their chip specific format in a way that let's them filter on the
CPLD and only wake up the application processor when something interesting
happens.

