In this blog, we often talk about detailed design features or aspects of FPGA or heterogeneous SoC design. This allows us to learn about different capabilities, techniques, and approaches we can use when creating and deploying our solutions.
For the most part, however, performing the detailed implementation should not be the first thing we consider when starting a new project. Often times, projects that begin hastily with immediate code creation are often the ones that end up in significant trouble with missed deadlines.
Professional FPGA development is based around a defined process which consists of several different development stages. This process will vary from company to company and application to application. For example, an aerospace application that has to comply with standards such as DO254 will have a more detailed and stringent approach than a commercial application, for example. However, there will be common elements to the development process.
Requirements – These define the requirements which are placed on the FPGA design and include functional requirements (e.g., algorithms, performance etc.) and non-functional requirements such as the operating temperature range.
Device Assessment / Selection – Based upon the functional and non-functional requirements, the engineering team will be able to select a target device. The device assessment may also consider the capabilities of the manufacturing facility and alignment with other ongoing projects which may be able to use similar devices.
Interface Definition – This defines the interfaces of the programmable logic design and will also include external interfaces such as DDR4 and multi-gigabit transceivers.
Architecture - The architecture of the programmable logic design defines how the requirements are to be addressed. It includes the definition of the following:
Clock and Reset Architecture – This defines how many clock domains are required and their frequencies. It also defines how the clock domain crossing is handled and, if necessary, under what circumstances does the reset trigger for example just an external reset or the MMCM / PLL losing lock.
IP Modules – The modules included in the design, what functionality they provide and clarifies if the blocks exist in the IP library or need to be created from scratch.
Interfacing – This illustrates how the IP modules are to be interconnected. The best way to achieve reuse is to use a standard interconnect technology such as AXI or AXI Streaming. This enables IP modules to be reused and provides an interface standard that is easily understood and well documented.
Register Memory Maps – These are memory maps for all of the registers within the design.
Verification Strategy – How do we verify that the design has implemented all the requirements? Typically, the verification includes functional and code coverage to ensure implementation of the requirements and demonstrate the test bench exercises all the RTL in the unit under test. This strategy will include the use of simulation frameworks such as UVM, UVVM, or OSVVM and provide a range of capabilities from bus functional interfaces to score boards. Use of these frameworks enable the engineering team to focus on the verification of the UUT instead of creating the necessary test infrastructure. Along with the verification framework, we may also implement assertion-based verification in either PSL or SVA.
Implementation – Once the design has been verified, the programming bitstream is needed. The final stage of the process is to verify the internal timing analysis and the IO timing. Of course, you need layout information from the board for the IO timing such as trace length.
A certain level of documentation is important to have with this process. From development plans to device architectures, interfaces, and IP block definitions -- it all needs to be documented.
Internally at Adiuvo, we have a development flow that we tailor for use from D0254 and space applications to commercial applications. We leverage tools such as Jira, Confluence, and Git for documentation and configuration control. At the architectural level, we have developed a SysML-based flow. For verification, we leverage ModelSim and UVVM with some cocotb depending upon the project.
I think this is an area we don’t talk about very often, but it’s important to share it. For large to small companies, it is critical to have such a process. If you want to read our development process, you can find it 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
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
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.
Comments