Seeing FPGAs Though Nemos's Eyes

Until recently, I had questions like "Why should one consider FPGA technology when we have well-known microcontrollers available to us?"

My name is Christos Merinopoulos (a.k.a. Nemos). On the one hand I have long been involved with electronics and embedded systems design; on the other hand, however, I have always been hesitant whenever I've had to deal with FPGA designs. This trepidation is not new for me; as far back as my college era we had courses pertaining to FPGAs -- including VHDL-- but I never seemed to gain a full understanding of FPGA technology.

Today's university courses are much improved and include many useful technologies that allow students to evaluate their FPGA designs in real hardware and in real-time; however, many students still have questions about the usefulness of FPGAs. The situation was much worse 10 or more years ago, because the cost of FPGAs and FPGA development systems was relatively high, so the only experience a student could have was via a software platform used to capture the design in VHDL and then emulate the device.

To be honest, until recently I still had questions like "Why should one consider FPGA technology when we have well-known microcontrollers available to us?" Now I feel I understand the answer to these questions, and I thought it might be useful for me to share this knowledge with others, so if you currently have these kinds of concerns, please bear with me.

Let's start with the most basic question: "What is an FPGA?" The term FPGA stands for Field-Programmable Gate Array. These are programmable logic devices, which means that they can be programmed (or configured) to act like any digital circuit; thus, we are not creating software, but instead we are building up the hardware.

Digital functions are composed of lots of simple ("primitive") logic gates, such as NOT, AND, OR, NAND, NOR, and XOR. By connecting these primitive logic gates in various topologies, we can create a digital circuit performs in a specific way. Modern FPGAs can contain the equivalent of anything from hundreds of thousands to tens of millions of primitive logic gates. In the case of an FPGA, we can configure it to perform whatever digital function(s) we require. Thus, as opposed to writing a software program that causes a microcontroller to act in a specific way, we can configure the hardware inside the FPGA to create a circuit that operates in a certain way.

Why are FPGAs becoming so famous today?
Unfortunately, the electronic industry is closely connected with production costs. In many cases, it is difficult for innovative technologies that have a relative high production cost to be adapted by the majority of users, including designers, hobbyists, and students.

In the early days of FPGAs, it was somewhat expensive -- especially for hobbyists -- to purchase the equipment required to develop and to program a device based on FPGA technology. High-end FPGAs are still very expensive, but lower-end and mid-range devices are now very affordable and -- in many cases -- the tools are also low-cost or even free.

Another consideration is that early FPGAs were somewhat limited in terms of capacity and performance. By comparison, even relatively low-end FPGAs today boast tremendous capacity and can operate at hundreds of megahertz.

In closing, I would like to ask if you also have concerns about using FPGAs. Are you currently working with FPGAs, or are you thinking that you would like to use them but you don't know how to start? Please share your thoughts in the comments below.

I want to apologize for the awful excesses to which you were exposed about which you were objecting on this blog. I was the first person to make a comment on getting started with FPGAs because it was a topic I was looking into myself, and I have certainly "done my share of embedded development" and specifically NOT using FPGAs (at least not at the current level of development) so I thought my "perspective" might possibly be useful in the discussion. It turned out that no one who was currently working at the state of the art in this field wanted to "waste their time with newbies and rookies" so they wouldn't even THINK of exchanging casual thoughts about the subject lest they reveal precious secrets about the internal workings of the "priesthood" to which they belong. You have to understand that in their world only the "blessed" are the ones to whom the arcane and mystical secrets of the inner workings of Vivado are revealed, and it is only the lesser of us mortals who are condemned to scratch out a subsistence existence with pathetic remnants of the art like ISE (whatever either of those are, I really couldn't care less). I would however point out about these "wizards" that I strongly feel that if the relationship in the following article by Martin Rowe is correct, they must certainly be working for free:

http://www.eetimes.com/author.asp?section_id=36&doc_id=1320477

In deference to these folks and their expertise, to the extent it's possible I'll delete my previous posts on this subject, so in my absence we can see just how modest and unassuming these folks truly are. I apologize for thinking one of the "unanointed" like myself was worthy of commenting on this topic, so please accept my humble apologies for kicking off this blog. The calumny and viciousness you've observed would certainly not have occurred had it not been for my actions in the first place.

To be honest I find Vivado very easy to use, but then planahead / ISE is too.

The writing I have been doing over on Xcell Daily has focused more on the software side at the momenr so interupts, timers, watchdogs etc which is SDK based but it is important for people to understand how this all works and is intergrated trogether.

I have been writing on how to use the Zynq using the Planahead flow over on the now sadly defunct All Programmable Planet, this series of blogs will be reposted on EE Times starting this week I hope. They cover everything from getting it creating the project to adding peripherals, creating your own perihperal and adding a RTOS. I have also written a similar series for the Xilinx Xcell Journal starting with the January 2013 issue.

There is also a series of blogs over on Xcell daily blog that has focused upon using the Vivado flow. This again starts at project creation, adding perihperals, but has then looked at things like the interrupt structre, clocks and timers, bootloaders etc.

hi anon, as a fellow FPGA design engineer who just happen to pass by, I have to say, why are you wasting your time arguing with obvious amateur hobbyist. I'd stop after realizing he was complaining about JTAG and listing Atmel as FPGA vendor (what is this, the 1990s??).

FYI I worked for Xilinx, now works for a telecom equipment vendor as a FPGA engineeer. I know "a little bit" about FPGA.

Gentlemen (I assume you are all male, due to the high testosterone level vibes :)

I am new to electronics as a serious hobby, and would appreciate it if, when things get stormy, post-wise, you would take the acrimony offline. I have neither the time nor the inclination to wade through 'my ego is bigger than your ego' posts.

FPGA families each have their own strengths and quirks, making it hard to switch between vendors. The vendor tools are quite different, each with their own steep learning curves, which is another barrier for switching FPGA families. I don't know about the profit margins, but I suspect they're quite a bit higher than commodity MCUs.

In addition, FPGA design is still IMO regarded as a "black art", and many engineering organizations don't have in-house FPGA design capability. One one sense this is good for FPGA consulants, but it does mean that FPGAs are not designed in as often as they might be, which is bad for FPGA consultants. I sure hope they distribute magic wands and wizard hats at the upcoming EE Live! (formerly ESC) "FPGA boot camp".

I really hope you all had a new years day, things got a bit out of control last year - nothing a nice bottle nof champagne would not fix.
Now, back to the original post topic.
I do software for a living. Embedded software, usually even BSP and other weird stuff most programmers never heard about. Many things to consider, like multicore, multi depth caches, odd MMU/MPU systems, CPU/Coprocessor bugs, bad documentation, really odd accelerators, so on. Tough most of the time, but that is our job - to hide all of the HW peculiarities to higher level enginneers and programmers, so they can focus on what they do best: implement their algorithms.
And this is exactly where FPGA enters the show. Independently of implementing a softcore CPU on FPGA, or just have the FPGA implement accelerators (in a sense) and use external CPU, they do present an advantage over other, hardwired, architectures:
1) they are field reprogramable, so you can update them easily
2) they are relatively cheap
3) the design is faster than a CPU for specialized designs
4) they can be (some) partially reprogramable, and in runtime, which allows for efficient hw
aceleration of different tasks
5) they are cool (not thermally cool, unfortunately :) )
If you read this closely, you can see that there is no definite answer to FPGA usage. All depends on your requirements, and your need of hw design update.
I personally love them, but only advice their usage in specific scenarios.
I cannot say the same as hobby! I love them, and halfway my second CPU/SoC design. Why? Because i can, and because I enjoy doing so.
Side note for someone that said porting GNU tools is rather easy: do not believe them.
Alvie