Developing FPGA solutions can be a challenge and as a consultant, We often see designs which are facing difficulties late in the development cycle. Oddly enough, often the challenge isn’t implementing the functionality but instead, achieving a solution which is on schedule, cost, and quality. Of course, schedule and cost are closely linked. If we run over on schedule, the costs will increase. However, costs will also increase if we try to increase engineering resources in order to maintain the schedule, start looking at third-party IP, or do any number of mitigations. Increases in cost eats into a company’s profit margins and ability to perform future developments, while late schedule delivery impacts their reputation and the future project pipeline.

The third element, which is the quality aspect, is also critically important. Poor quality design will not only drive schedule and cost, but also prevents the ability to leverage the design or elements of the design for future iterations or derivatives. This is often called technical debt, meaning when we know something is not that great but it helps us achieve the deadlines, so we accept it. Of course, we always intend to go back and fix it, but don’t often do. Examples of technical debt include not creating test benches for modules and testing on the hardware, or allowing designs to get unwieldy as the deadlines loom thereby making future maintenance difficult.

Having thought about this a little, We think there are several elements which can be used by engineering teams to help reduce the technical and programmatic risk on FPGA development.

1. Schedule – The development schedule should be defined from metrics and based upon previous development experience of similar IP blocks, FPGAs and verification standards. These metrics should be easily available, provided engineers record the hours spent on a project. Regardless of company size, this is important to record and track to ensure the project is not going over budget. However, even if it does go over budget, do not be tempted to “cheat” and stop recording the hours or assign them to another task. If you have an accurate recording of the hours a development took, then you can use these for estimation on future developments and not go over budget. Over the years we have created a fairly simple excel spread sheet that enables us to assign a complexity to a block (complex, medium, simple) and use metric-based figures to determine the estimate. This estimation also enables customization for design and verification flow (e.g., light weight prototyping or full ESA / DO254 certification etc.).

2. Development Plan – Knowing how to design an FPGA is only part of being an FPGA engineer. A key element is knowing how you are going to go from the concept and the requirements to a completed and verified design. The best way to work this out is to write a development plan. It doesn’t have to be War and Peace but it should be based on your development processes and tailor them accordingly, aligned with the schedule. This will enable team member to know what is expected of them in the development, when reviews are going to performed, and what is expected as the inputs and results of those reviews.

3. Architecture – One of the key skills of an FPGA developer is to be able to work out the system solution and the architecture. This architecture should be as simple and elegant as possible and follow the KISS principle. Anyone can make a complex architecture but a skilled and experienced engineer can implement complex solutions within simple, modular and flexible architecture. One of the key points of the architecture is to make it as simple and easy to understand as possible for the benefit of other team members and reviewers, in addition to your future self when you come back in six to 12 months’ time. One of the key pitfalls to avoid is creating large flat designs, leveraging hierarchy, especially in IP Integrator is the key to a good design. Hierarchy has several advantages and enables the design to be split into the functional modules, grouping needed functions together. This can make understanding the design and debugging much simpler. Hierarchy can also be very useful when combined with an IP reuse strategy. When using IP Integrator, we can create reusable hierarchical blocks using TCL which allow common functions of IP to be quickly and easily recreated in future designs.

4. Technical De-Risking – We all know that the earlier we find an issue, the easier and less costly it is to fix it. In FPGA development, we often use development boards to prototype algorithms and functions we think will present a technical risk in order to retire the risk early in the program. If we are developing custom boards for our FPGA, some technical risk carries in until we get the board and the final FPGA design and then try to achieve timing closure. This can be the point where of a lot of pain and stress is experienced because it’s where things get very expensive to the schedule and cost if there are issues. In order to retire the risk of timing closure early in the project, we can pin plan the project and also write the IO structures of the FPGA design as early as possible in addition to performing trail synthesis and place and route to ensure timing closure can be achieved. This retires the risk where you get to the end if the project and experience IO timing closure issues. The best way to do this is to implement your timing structures in RTL etc. and then create a simple logic structure behind them to stop optimization during synthesis. You can then apply the necessary timing constraints and reduce the risk of reaching the end of development and there being no timing closure possible.

5. Standard Interfaces - This one goes back to most of the points We have made so far in this blog. To be able to achieve on-time development with reduced risk, it’s critical to reuse as much IP as possible. To create this library and enable maximal reuse, you need to define a standard interface for the IP blocks. This allows you to keep the architecture simple because you are using a standard interface and also enables reuse on future projects. We try to focus on using either AXI, AXI Lite or AXI Stream because these easily integrate with IP provided in Vivado as well as purchased third-party IP. If you write an IP block which is in demand, and you have standard interfaces, you can always leverage it and offer it for sale.