The meeting as always was dragging on but slowly concluding. The changes requested at a late stage in the development process had been made to the FPGA. The root cause at the system level which led to the change request was understood and the method of implementation was judged by independent FPGA experts as acceptable. Crucially, the full verification suite had been run both on the FPGAs and on the system. This was important as—in the not-to-distant future—these FPGAs will be blasted into space to help search for new planets.
All that remained was to reflect the changes across the documentation, but this is where the issues became apparent. A small change to the requirements has a massive ripple-on effect with respect to the documentation used to capture the system’s definition, analysis, verification, and validation. This small change would require a raft of documents to be updated, a not inconsiderable task when deadlines are approaching. The meeting concluded with actions on the system and FPGA design team to update the documents, issue them for review, and schedule a delta qualification review.
Increasingly, the number of documentation artefacts that are generated as part of the program is an issue with the development of complex projects. A documentation-centric approach has several limitations. The information from systems engineering activities is contained within a series of documents. This makes analysing data difficult and often means the understanding of it can vary due to human interpretation. A documentation-centric approach also means there can be duplication of data across documents, which makes maintenance difficult and can lead to conflicting information.
What is model-based design?
Model-based design (MBD) is a formalised application of modelling to support system requirements, design, analysis, verification, and validation. This starts at the conceptual phase and continues throughout the remainder of the engineering life cycle.
Model based design therefore takes much of the data that would be traditionally have been included in documents in a documentation-centric flow and moves it into a model. These models are often built around a data base, which allows information to be shared and reused across different visualisations of the model. A single source of truth ensures that each element of information is created only once and then reused as required. Using a model therefore gives the engineering team a solution that can be analysed much easier than a disparate set of documentation.
In situations like the one presented in the introduction to this column, a change requires we find all impacted documents and update them. By comparison, since information is linked together in a model-based flow, it is much easier to make changes as any modifications are automatically propagated though the model.
Another significant benefit of a model-based approach is standardisation. Engineers often communicate information via diagrams and walls of text. A model-based approach introduces standardisation in the way information is presented though the use of specific diagrams. An even greater advantage of model-based engineering is the ability to create computer programs that can read the model and automate key tasks.
MBD and FPGA development
The example presented in the opening paragraph was based on a previous FPGA project implemented using a traditional documentation-centric flow.
More recently, our FPGAs and projects have been developed using a model-based engineering flow. In this flow, we use MBD tools to capture the system. In the most recent case, this model captures both the FPGA and microprocessor along with their interactions.
To achieve this, we used an industry standard tool, Enterprise Architect, which enabled us to capture the technical baseline of the project. By means of this tool, we captured the requirements and behaviour diagrams, which demonstrated the desired functionality. We were also able to capture the internal architecture of the FPGA design.
Within this internal architecture, we are able to define the functional blocks, their interface classes (e.g., AXI, AXI Stream, or custom) along with the clocking architecture. This structure diagram shows the architecture of the FPGA design including the interconnects used to connect the modules together.
From this structure diagram, Adiuvo has internally developed automation tools that are able to process the model and generate a VHDL netlist of the structure. Along with this netlist, register maps and integration information such as interface control diagrams and C/Python functions are also generated.
This automation tool automatically pulls in elements from our Adiuvo IP library, which contains commonly used modules such as AXI interconnects, FIFOs, direct memory access (DMA) etc. The tool also generates stubs to which any custom modules to be developed will be attached.
In the same way the model-based approach enables the level of abstraction for the FPGA to be raised, we also raise the level of abstraction (where appropriate) for the development of the modules. To do this, we leverage MATLAB and Simulink along with the appropriate toolboxes to enable hardware description language (HDL) generation.
Simulink is well-suited to FPGA design as we can model not only signal processing but also state machines and combinatorial logic. Along with developing the functionality in Simulink, we can also use it to develop the test bench and test cases, thereby enabling a single environment for modelling and verification.
This model-based approach—which combines Enterprise Architect for most of the model-based design with Simulink models for detailed functionality—enables the development of an FPGA from a single source of truth, cutting down on the documentation and its maintenance while enabling development at a higher level of abstraction.
Using this approach, Adiuvo recently developed a large video processing FPGA for a space application. The design drives a high-end scientific CMOS image sensor and processes the video before outputting it over gigabit serial links. The entire design consists of approximately 100,000 lines of VHDL, most of which was generated automatically using either Enterprise Architect or Simulink.
Conclusion
By deploying a process that focusses on the front-end of the lifecycle, employing techniques such as model-based design and continuous integration, we can significantly reduce our overall development timeframes. Furthermore, this approach produces the high-quality designs mandated by the most challenging of applications.