How to prevent FPGA-based projects from going astray -

How to prevent FPGA-based projects from going astray


During the course of my career, I have been involved with developing a number of FPGA designs for some really interesting projects. Sadly, I have also been involved in rescuing several FPGA designs that have gone badly astray. As I worked on these problem designs, it became apparent that — although the target applications and the members of the development teams were different — the designs shared some common points that doomed them to failure before the first engineer even sat down to write the first line of HDL code.


With this in mind, I thought I would run through five common issues that I've observed as part of rescuing these projects. These issues are as follows:

#1: The first concern doesn’t relate only to FPGA-based development, but to engineering in general. The problem is not having a stable requirements baseline when starting. There is always a desire to commence the project while the requirements are still maturing on the basis that progress needs to be demonstrated. However, if we jump in and start developing without fully understanding the requirements, then — all too often — any initial progress turns out to be false, and performing downstream corrections introduces additional delays and costs. What starting too early actually does is to introduce risk into the development, and this risk needs to be mitigated. I appreciate that, depending upon the application at hand, the depth and detail of the requirements can scale. I would expect many more, and more detailed, requirements for a SIL4 system than for a commercial system. However, the long and short of it is that, if the requirements are not agreed and baselined right from the beginning, there will be scope creep. Although the design may have started out with a sensible architecture for the requirements as understood, it will become increasingly complicated when the developers attempt to shoe-horn in new functionality as the baseline matures. Before long, something will break.

#2: Having understood the requirements situation, every member of the team needs to understand the plan to develop the FPGA. Therefore, it is a good idea to have a plan defining the approach that will followed from kick-off to delivery, identifying the major steps involved and the engineering review gates that will be applied during the development process. Along with the plan, we also need to document the architecture and the design, identifying each of the major functions, deciding which functions are to be newly developed and which re to leverage third-party IP or re-use existing IP (more on this later). This combined plan, architecture, and design description documentation will allow the engineering team to clearly understand the task at hand. We can also trace all the functions back to the requirement set to ensure that the proposed approach addresses all the high-level requirements.

#3: Designing the modules and the overall FPGA will take time; what will take longer, however, is verifying the design, and ensuring that it meets its requirements. This verification needs to encompass not only logical functionally, but also needs to be performed across all possible operating conditions of the device. In turn, this means that it's necessary to develop a clear verification strategy for the design; it is no longer a case of just writing the code, performing a few simulations, and then throwing the design onto the hardware.

#4: At times, we all get so close to things and set in our thinking that it becomes hard to see when we have missed something. This is what engineering design reviews were invented for. By holding these reviews, we can ensure that we are following good engineering practices and complying with internal development standards. Significantly, they also provide the ability for independent engineers to look at the design — its architecture and implementation — to ensure it will provide the required functionality. If we do not review the design as it progresses, we will fail to build in quality and we will increase any downstream integration issues.

#5: Thus far, you may have noticed that most of the points I've raised are related to process and wider engineering aspects, as opposed to the coding of the design itself. Of course, developing the code is important, but it's also important to ensure we are leveraging third-party IP and re-using internal IP. Ideally, we should re-use as many existing IP blocks from our library as possible. Where this is not possible, we will — of course — need to develop new modules. In this case, creating these new modules in such a way that they can be re-used in future projects should be foremost in our minds. To help us create these new blocks, we should consider the use of High Level Synthesis (HLS) tools. By allowing us to work at a higher level of abstraction, these tools provide the ability to more easily explore the solution space and reduce risk, development time, and costs.

The points presented above are just a few of the things I have noticed while rescuing FPGA designs. I would be very interested to hear your thoughts on projects that went astray.

2 thoughts on “How to prevent FPGA-based projects from going astray

  1. “I too have rescued numerous projects in the FPGA logic space. My conclusions are a little different then yours however. I see three problem themes: 1) Reset design is a topic given little up front thought but tends to accumulate insidious, hard to find bu

    Log in to Reply
  2. “I have additionally been included in safeguarding a few FPGA outlines that have gone seriously off track. As I chipped away at these issue plans, it ended up noticeably evident that – in spite of the fact that the objective applications and the individual

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.