Over the years, I have worked on a range of engineering projects in various roles, from being the FPGA engineer, hardware engineer to the engineering executive in charge of large system developments across the globe. Throughout these roles, I have been able to work on a diverse portfolio of applications from automotive to space, defence, and virtually every application in between.
Of course, over the years, I have seen developments go well and not so well, I am not saying what I have seen more of. One key thing that has become apparent to me in all of these developments is that projects which go wrong often fail due to common causes, the most prevalent being the lack of a well-defined, stable requirements baseline. So I thought, in this blog, I would explain why I think it is important to establish a clear requirements baseline.
Establishing a requirements baseline provides several advantages to a project:
Definition of the scope of the project: The most obvious benefit is that a clearly defined requirement set provides a clear objective for the FPGA development.
Facilitate Testing and Validation: For each requirement, we must be able to indicate how we will verify it. For most FPGA requirements, this will be via simulation; however, there may be other requirements, such as timing closure and power, which require a different approach. By identifying early on in the project how requirements will be verified, it enables the scope of the verification task to be identified and ensures customer buy-in. This also can form the basis for the verification plan later on in the development process, which outlines in depth the process to be followed for verification, e.g., self-checking, code coverage, constrained random, post-layout simulation, etc.
Technical Risk: The requirement set can be analysed to identify the technical risk in the project. A team, for example, may have significant experience implementing PCIe interfaces but might have significantly less experience when it comes to implementing a complex cryptographic algorithm and gaining certification for that algorithm by the relevant body. This unfamiliarity with the process could be classed as technical risk, and mitigation plans implemented. Similarly, the technical risk could be, for example, on the power requirements of the FPGA or fitting the design into the target device. If we are able to identify risk, we can work on how we may mitigate the risk, reducing the potential impact.
Timescales: All engineering projects aim to deliver on time, quality, and cost. A good requirements baseline can help you estimate the effort required not just for the design but also, as discussed above, the verification, and of course, identify any technical risk and mitigation plans. This can enable the engineering and management team to come up with schedules and financial budgets, although they might not like the answer that comes out.
Change management: For me, this is very important because, as a small company, changes come with a cost (either charged or not). Having a defined requirements baseline enables changes to be easily identified, scoped, and impact assessed. For some minor changes, you may decide not to charge for the change; for others, which are larger and have a more significant impact, you can charge the client. Having the baseline provides that possibility, as the impact is well defined. The baseline also enables the monitoring of the rate of change of requirements. If they are largely stable, then that is great; if they are changing often, it can be an indication of a problem which needs to be addressed, as you cannot hit a moving target.
Generating the requirements can be a long and detailed process, which requires an understanding of the system's concept of operations, the needs of stakeholders, trade studies, modelling, and research. For this reason, there is often a separate systems engineering team who produce the requirements documents, although for lower-level elements such as the FPGA, it is not unusual for the lead engineer to take on the responsibility. Being able to write good, clear requirements is a skill all engineers should master.
Regardless of who writes the requirement set, it should include both functional and non-functional requirements, for example:
Communication requirements: How does the FPGA in our case communicate with the external world? The in-depth detail of this is often defined in one or several interface control document(s).
Functional requirements: This defines what functionality the system needs to implement. This will often include performance requirements as well, for example, the accuracy of a calculation or throughput of a system. It might be more complex, however, and specify the ability of a system to extract an RF signal from a noisy environment and correctly decode it.
Environmental requirements: The operational environment the FPGA is likely to see in storage and operation. This will obviously include the operating temperature, but more demanding applications, e.g., automotive or aerospace, require additional environmental testing and certification of the device selected. What is defined in these requirements will help you establish which quality level of device is necessary.
When it comes to writing the requirements themselves, there are a set of rules which we must try to ensure we follow.
Necessary: Success cannot be achieved without these requirements.
Verifiable: You must be able to ensure the requirement can be implemented via inspection, test, analysis, or demonstration.
Achievable: Technically possible, with the constraints.
Traceable: Each lower-level requirement traces to a higher-level requirement.
Unique: Prevents contradiction between requirements.
Simple and Clear: Each requirement specifies one function.
Typically, we also use terms with very specific meanings when writing requirements:
SHALL: Denotes a mandatory requirement. “The equipment SHALL have a 1553B Interface.”
WILL: Denotes the purpose of the part or system. “The equipment WILL be used to encrypt the telecommands.”
SHOULD: Denotes a non-mandatory requirement. “The equipment SHOULD be able to store 10 encryption keys.”
A defined requirements baseline is very beneficial to all projects, and it helps large and small companies alike to understand what the end goal of the project is and when we are able to say a project is completed. This is especially important for small companies as requirements creep and ambiguity can impact your cash flow as milestones are delayed.
When it comes to managing the requirements, we tend to use specialist tools such as Enterprise Architect, Doors, Jama, ReqView etc. These provide the ability to have unique identifiers for a requirement, trace requirements and otherwise manage requirements throughout the life cycle of the project.
If specialist tools are not available in the worse case a spreadsheet can be used, it is better than nothing, but I do not recommend it.
Hopefully, now having read the blog, you can not only understand the benefits of establishing a requirements baseline for an FPGA development but are also aware of how that baseline can be used to wider effect to help you understand the scope of the project as a whole, from outlining technical risks to estimation and budgets to allow on-time, quality, and cost delivery.
Writing this blog has reminded me I have a lot to talk about with regards to technical risk and technology readiness levels, which I will pick up in a future blog.
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
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
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.
Sponsored by AMD