Recently, I was asked to present to a group of engineers about design reuse with respect to FPGA design. This is something which, as a small company, is very close to my heart, as reusing components allows us to reduce design risk, be more agile, and of course, cost-effective in delivering the solution.
As I sat down to think about design reuse and the key concepts involved, I realised that there are eight key tenets centred around one objective.
Objective – Develop, over time, an IP library which contains several IP cores which can be redeployed across a number of projects.
Modularity – This is perhaps the most obvious of the tenets, however, if we want to create a library of components which we can reuse across several applications, we need to ensure we create modules which are not only self-contained but also have clearly defined interfaces. The benefits of achieving a modular design and hence an IP library are several. Not only is design time reduced, but also technical risk is reduced. However, there are also additional benefits, such as aiding development time estimation. For example, estimation becomes identifying which of the existing IP blocks are to be used, along with identifying new modules which need developing.
When it comes to developing new modules, design reuse should be the key priority of the design activity. At Adiuvo, we have two types of IP. The first are common elements; these are small design units which do not form full IP on their own. Typical examples include counters, edge detectors, RAMs, and FIFOs, etc. This library also includes bus functional modules and AXI infrastructure. The second type are the major design units which perform a significant function and often use features from the common library.
Standardisation – One of the key principles of reuse is creating IP cores which have been standardised as much as possible. The most important factor for standardisation is with regards to interfacing, outside of the clocks and resets, etc. The main rule for reuse is to use standard interfaces, e.g. AXI or Wishbone. This makes the module not only easier to test using standard design patterns, but also makes the IP core easy to integrate with other IPs within the design. If, for some reason, you think you need to define your own custom standard, have a long think and then realise it is a bad idea. Standardising on interfaces ensures that we can easily integrate bus functional models provided by verification frameworks such as UVM, UVVM, OSVVM, and COCOTB. It also has another added advantage in that new engineers to the team already understand the protocols used, as you are using industry standard interfaces.
Parameterization – We often want a similar function, but with a slightly different configuration. For example, an image processing filter which, in one implementation, needs to support 720P, while another requires 1080P, and the final implementation requires 4K. Parameterization using either generics (VHDL) or parameters (Verilog) enables us to define the IP core once and configure its implementation and therefore resource utilisation, performance, and power depending upon its defined parameters.
One thing to ensure when we use parameters is that the verification approach needs to take into account the different configurations to ensure it functions as expected across the defined configurations or corner cases.
Documentation – When we studied for our engineering degrees, none of the lecturers ever told us that a large proportion of our time would be spent writing documents. However, documentation is one of the key aspects of engineering, and when done correctly, can enable reuse and allow future support and modification if necessary.
When it comes to reuse, at Adiuvo, we have a document template which must be completed by IP developers. This includes the IP Overview, Specification with timing diagrams and register maps, architecture, error handling, interface definition, customisation requirements, and how to work with the core, along with any known limitations or issues.
Verification & Validation – Each IP Core developed should come with a self-checking test bench which verifies the performance of the IP core against its requirements documentation and any error-handling responses as defined in the documentation.
Another benefit of using standard interfaces is that we can leverage verification frameworks such as UVVM, OSVVM, UVM, etc. to stimulate and interact with the unit under test. Typically, when we develop new test benches, we use UVVM for verification.
Maintainability – When we develop an IP Core, we should ensure that we have a focus on future scalability and maintaining backwards compatibility whenever possible. Following many of the other guidelines here will help provide a solution which is maintainable. To ensure other engineers are able to quickly and easily understand the IP Core and modify / extend it if necessary, we need to define a comprehensive coding standard. This coding standard will cover such aspects as naming styles, methodology approaches, and of course specific rules such as control signals, allowed types, etc.
Management – Management is similar to maintainability, however, it defines the policies about how we manage the life cycle of the IP core. This includes how the IP is maintained, ensuring the documentation meets the minimum standards, and defining how we manage any bugs or issues and the prioritisation of effort to address those issues. We also have policies for IP cores which will only be developed internally and those which are used externally.
Automation – Whenever possible, we want to automate the simulation and building of the IP cores into the final project. Here, we can leverage TCL and Python scripts, along with source control like Git and continuous integration using GitHub Actions, etc. We also often leverage FuseSoC to automate the build process.
Of course, over the years, I have created a number of Hackster projects which help on this journey, including:
So you want to design a FPGA IP Core https://www.hackster.io/adam-taylor/so-you-want-to-design-a-fpga-ip-core-56e0f1
Fun with FuseSoC https://www.hackster.io/adam-taylor/fun-with-fusesoc-7b2b1d
Getting to grips with GIT https://www.hackster.io/adam-taylor/getting-to-grips-with-git-2e30b2
Verifying VHDL https://www.hackster.io/adam-taylor/verifying-vhdl-da9a93
Debugging AMD FPGA AXI Designs with a RPi PICO https://www.hackster.io/adam-taylor/debugging-amd-fpga-axi-designs-with-a-rpi-pico-0f1e94
I would be interested to know what lessons or points you have to share about FPGA design IP reuse.
UK FPGA Conference
FPGA Horizons - October 7th 2025 - THE FPGA Conference, find out more here
Workshops and Webinars
If you enjoyed the blog why not take a look at the free webinars, workshops and training courses we have created over the years. Highlights include
Upcoming Webinars Timing, RTL Creation, FPGA Math and Mixed Signal
Professional PYNQ Learn how to use PYNQ in your developments
Introduction to Vivado learn how to use AMD Vivado
Ultra96, MiniZed & ZU1 three day course looking at HW, SW and PetaLinux
Arty Z7-20 Class looking at HW, SW and PetaLinux
Mastering MicroBlaze learn how to create MicroBlaze solutions
HLS Hero Workshop learn how to create High Level Synthesis based solutions
Perfecting Petalinux learn how to create and work with PetaLinux OS
Boards
Get an Adiuvo development board
Adiuvo Spartan 7 / RPi 2040 Embedded System Development Board
Adiuvo Spartan 7 Tile - Low Risk way to add a FPGA to your design.
Embedded System Book
Do you want to know more about designing embedded systems from scratch? Check out our book on creating embedded systems. This book will walk you through all the stages of requirements, architecture, component selection, schematics, layout, and FPGA / software design. We designed and manufactured the board at the heart of the book! The schematics and layout are available in Altium here Learn more about the board (see previous blogs on Bring up, DDR validation, USB, Sensors) and view the schematics here.