FPGA GOTCHAS -The Top 11 Gotchas when developing with an FPGA

So you’re considering an FPGA for your next project…  Excellent.  The technology is pretty cool.  However, before you take the plunge, you’ll want to consider these realities.

It’s worth noting that this is a complex topic, and as such, some topics are not covered, some are just introductory, and others will evolve over time.  This paper should still give you a lot of helpful information if you’re new to the world of FPGAs.

If you feel uncomfortable about what’s under the hood of an FPGA, check out our FPGA Basics – A Look Under the Hood white paper.

Gotcha #1:  Thinking that you’re writing software

Get out of the software mindset – You’re not writing software.  Let me say that again because this is the single most important point if you’re working with FPGAs.  You-are-NOT-writing-software.  You’re designing a digital circuit.  You’re using code to tell the chip how to configure itself.  Now, before someone says it, yes, when you’re coding up one of the microprocessor cores within the FPGA, then of course you’re writing software, but that’s not what we’re talking about here.  We’re talking about when you’re coding the digital logic.

Gotcha #2:  Assuming the bulk of your algorithm is the bulk of development time

When developing with an FPGA, the core processing functions (e.g. an FFT) actually only occupy a small fraction of the overall workload.  It’s generally all the other non-core elements that end up chewing up a large fraction of your development time.

Some example functional blocks that will take large chunks of your overall effort:

• Interfacing to various external memory chips
• Creating a communications bus
• Error checking
• Developing a configuration architecture.

Gotcha #3:  Not paying enough attention to timing stability

This is a critical aspect of developing with FPGAs.  Instability can cause the FPGA to basically lose its mind, rendering outputs in unknown states either as a glitch or permanently (until reset or reload).  Good coding practices and knowing the limits from a clock frequency and part fullness standpoint will go a long way toward reducing your risk.

Gotcha #4:  Not worrying about cyber security

A lot of FPGAs embed Ethernet cores, common processor cores, and some are even running an OS, making it so FPGA-based (sometimes referred to as SoC (system on a chip)) solutions look like another computer on the network. This increases their vulnerability to more traditional attack methods. Take the time to understand your risks and mitigate them. Obscurity is generally NOT a solid security approach (check out The Great Debate: Security by Obscurity). Here are two articles to get you thinking:

• How to build an FPGA-based I&C
• Microsemi Steps Up Its Cyber Security Leadership in FPGAs: SmartFusion2 SoC FPGAs and IGLOO2 FPGAs Enhanced with Physically Unclonable Function Technology

Gotcha #5:  Not understanding the risks for safety-related applications

If you’re considering an FPGA within a safety-related application, you need to understand the risks that you’re incurring.

Here are a few articles to get you thinking:

• Safe FPGA Design Practices for Instrumentation and Control in Nuclear Plants
• SRAM-Based FPGA Systems for Safety-Critical Applications: A Survey on Design Standards and Proposed Methodologies
• Xilinx Reduces Risk and Increases Efficiency  for IEC61508 and ISO26262 Certified Safety Applications

Gotcha #6: Not having at least one driving Algorithmic reason to use an FPGA

Seems obvious, but don’t just get sucked in by the cool factor of what an FPGA can do.  Much of what will make it worthwhile to utilize an FPGA comes down to the low-level functions being performed within the device. There are roughly four processing/algorithm attributes that FPGAs are generally well-suited for, and there are another handful of algorithmic and non-algorithmic attributes that make an FPGA less desirable.  These are covered in our FPGA Basics – A Look Under the Hood white paper.

Gotcha #7: Not doing design reviews:

Seriously.  Design reviews are an important part of this process, and are not just for newbies.  The number, depth, and focus of design reviews can vary depending on the:

• Complexity of the design
• Criticality of the function or system
• Experience of the designer.

Reviews to consider include:

• Functional overview
• Detailed design
• Code
• Simulation
• Unit test.

Gotcha #8: Jumping right into coding

Since you’re essentially designing a digital circuit, as a beginner, you should not begin coding in any language until you’ve created a block diagram for your design.  The level of detail that you should show varies based on the complexity of the design, but consider creating detailed design block diagrams at the gate/FF level for at least the first 20 or so designs that you create.  After that, you may evolve to sketching out your design at a higher level, but it’s great practice to get used to seeing your designs closer to what they actually are, digital circuits.

Also consider creating timing diagrams where appropriate.  These are especially useful in designs where one output needs to be asserted relative to another output, or when feedback or handshaking is involved.

Another useful way to view some elements of your design is by creating state machines and flow diagrams.

Gotcha #9: Trying to use all of the FPGA!

In general, you want to use less than 100% of the part.  The amount that you’ll want to keep in reserve depends on several factors, with significant factors including:

• The generation/architecture of FPGA being utilized
• Your code quality
• The FPGA clock rate

The fuller your part is, the longer the build process (compile, synthesis, place, route, etc.) will take.  The reason this is a useful note, is that build times don’t take seconds.  Depending on many factors, they can take 20 minutes, or four hours.  In some cases it may fail to build at all, or worse yet, build, but be unstable, wasting countless hours in the lab.

Gotcha #10: Not planning for Enough Bugs

Something about that feels wrong on first read, because who actually plans for bugs?  You should.  If you do it will be one of the most stress-relieving things you do, and you’ll thank me later.  You’ll get many of the most basic level 1 bugs out during simulation, but at some point there will be a driving reason where you’ll have to move out to the lab and integrate your part of the world with the rest of the system being developed.  This is where those famous words “But it worked fine in simulation…” come into play.

The disadvantage of a run-of-the-mill basic sequential processor is that only one operation is executing at any point in time. The advantage of a sequential processor is that only one operation is executing at any point in time. When it comes to debugging, the sequential nature of the basic processor makes life easier than debugging the parallel nature of the FPGA.  While the simulation environment offered impressive visibility, now that you’re moving into hardware, your visibility into what’s going on decreases significantly.

Plan for a lot of bugs.  Take a couple hours and think through other bugs you’ve dealt with as an engineer.  Now triple that number (I’m making this multiplier up of course).  If you’re a newbie developer, you need to pull in someone that has experience with FPGA development to help with this estimate.  You’ll be wrong, but you’ll be better off than if you hadn’t thought this through.  Here are a few tips on debugging to help you along the way:  Six debugging techniques for embedded system development.

Intermittent bugs are common within FPGAs.  They can be affected by temperature, humidity, the phase of the moon (I may be exaggerating a bit there, but sometimes I wonder).

The logic analyzer is your eyes into the inner workings of the FPGA. You can view outputs of course, and you can create test points to go to a testpoint header, but you have to be able to probe all of those points, so you’ll probably need a logic analyzer, which can get very pricey (if you’re looking for an inexpensive logic analyzer, check this out: https://www.saleae.com/ , and similar).  A logic analyzer is a very important tool for FPGA-based development.

An internal logic analyzer can be helpful as well, at least in some scenarios.  You may be able to get away with embedding test resources into your device (e.g. Xilinx has the Integrated Logic Analyzer), but this will utilize FPGA logic and memory resources, and is often challenging to see enough breadth or depth about what’s going on inside your FPGA. However, generally these tools are better for augmenting a true logic analyzer, as opposed to replacing them outright.

Gotcha #11: Making fun of the software guy!

The software guy (or girl of course; the term “guy” is used here androgynously) is your best friend – If your FPGA interfaces to a higher level supervisory sort of processor and/or it provides the UI, the software guy can do things to help make your life a lot easier.  A couple of the more major categories include:

• Engineering debug panels – chances are the information you need to view is not the same as what the end-user needs to view. Having a debug panel can save you significant time, effort, and frustration.
• Special debug functions and modes – maybe there is some routine that software normally runs through with steps 1-12, but maybe you want to be able to run just step 3 and 4 repeatedly, or maybe just step 7 once. Or perhaps software can add a special function to keep track of the content or frequency of messages that you’re sending to it and set a trigger when something unexpected happens.

Work with the software developer early on to see how you can work together to facilitate the integration and debug process, and remember that it goes both ways.  Chances are there is additional functionality that you could add to aid in their debug process as well.

Next Steps:

If you’ve made it to this point in the paper, maybe you’re thinking that an FPGA may be a good fit for your upcoming application. Reach out to us here if you want to chat about your specific needs. If you’d like more useful info on industrial embedded, check out our resources page.  If you’re looking for useful info on test systems, go here.

Deep into learning mode?  Check out these resources:

• When is an FPGA Worth it and When is it NOT – when developing an Industrial Embedded System
• Using an NI CompactRIO for Industrial Embedded Monitoring & Control applications
• Outsourcing Industrial Embedded System Development Guide
• LabVIEW Industrial Automation Guide
• Online Monitoring of Industrial Equipment / Machines / Systems
• FPGA Basics for Industrial Applications