top of page
Writer's pictureAdam Taylor

MicroZed Chronicles: Technical Risk and Technology Readiness Levels


FPGAs are commonly used across a range of applications from Space, and Aerospace to Automotive, Robotics, and Commercial applications. Within these applications, it is common to have multiple FPGA-based sub-systems which implement complex tasks e.g., flight control, communications, RADAR, image processing, signal processing, etc.


Developing these FPGA-based sub-systems presents developers with several risks, both programmatic and technical. Should these risks arise, they can have a significant impact on the delivery of the final system, resulting in increased costs, missing the delivery schedule, and of course, added pressure on the development team.


Previously, we examined the importance of requirements, and how they can help us not only determine our verification approach but also identify technical risks related to requirements.



AMD Development boards created by Adivuo in the last 12 months


Technical risks are dictated by technical aspects of the project which may present a challenge. Examples of technical risk include the use of a new image sensor which is not supported by the standard embedded Linux solution for the target device. In this case, drivers would need to be ported or written, along with a hardware and FPGA design being created.

Another technical risk would be the implementation of a DDR4 memory interface. This risk would mature late in the project once the boards came back for testing/qualification and could result in significant impact to the program.


However, there are more technical risks than those identified by the requirements. Other technical risks which a project might face include:


  • Maturity – How mature are the components and tools that we will be using for implementation?

  • Stability of requirements - Are the requirements rapidly changing?

  • Development team – Is the team available and sufficiently qualified and experienced?


As the project develops, technical risks should be retired; for example, the project plan should contain a run-out date for which the risk. This risk run-out date should be the point by which we can say the risk either impacted the project or not.


For each identified technical risk, we should be able to identify not only the risk but also:

  • Mitigation Action – How can we mitigate the impact of the risk? Typical approaches could be prototyping, simulation, considering alternate solutions, and development approaches.

  • Run out date – The date by which the risk should have been realized if it was going to impact. As the project progresses, the number of technical risks should decrease as we move closer to the completion of the project.

  • Impact – The financial and schedule impact of the risk arising and impacting on the project.

  • Probability and Impact – The probability of the risk maturing and the impact of that risk maturing on the project.


This enables the FPGA lead or project manager to correctly communicate the technical risks of the development with the wider project development team.


One measure we can use to help us identify technical risks is the identification of the Technical Readiness Level (TRL). The TRL ranges from levels one to nine, with one being the lowest and nine the highest.


  1. Basic Principles Observed - Understanding of the principles involved in the issues - Using the DDR4 memory example this would be understanding the data sheet and understanding the physical layers of the DDR4 connectivity.

  2. Technology Concept - The basic concept of how the system will work, in the DDR4 example this would be identifying the pins and verifying the pin allocation and creating the schematics.

  3. Experimental Proof of Concept - Creation of a breadboard using the processing device and the DDR4 memory. This would require creation of schematics and the layout, procurement of parts and the manufacture, assembly and test of the breadboard.

  4. Technology Validated in the lab - Successful testing in the lab, the DDR4 breadboard successfully passing the stress tests and other characterisation tests.

  5. Component Technology validated in relevant environment - The breadboard being tested across temperature and vibration extremes and continuing to work to demonstrate the DDR4 is successfully working when exposed to the operating environment.

  6. System / Sub System Technology validated in relevant environment - The completed system or sub systems being designed, manufactured and tested against requirements and environment. In the DDR4 example this would be the creation of the complete solution using the DDR4 memory.

  7. System Prototype demonstrated in operational environment - assembled system tested against the operational environment.

  8. System complete and qualified - Assembled system has successfully completed the qualification testing against its operating requirements and environment.

  9. System proven in operational environment - System deployed and working in the field.


This is one of the reasons why I am a huge fan of development boards; developing a solution that works on a development board can decouple risk from custom hardware. It also enables the development team to hit the ground earlier in the development cycle and get designs in hardware demonstrating the desired functionality. It also provides a stable platform for debugging when issues arise on custom hardware, to determine the root cause.

Of course, the natural extension of development boards is the use of a System on Module (SoM). Using a SoM provides two significant benefits.

Upcoming Spartan 7 Tile


The first being combined with an existing carrier card, we are able to develop the application on hardware earlier just as we did for a development board. 


But the added advantage of a SoM is that we are able to use the SoM as part of our custom hardware; this reduces the significant technical risks associated with developing a chip-down design, for example, high-speed memory interfaces, power distribution, and of course, clocking requirements. 


This frees up the development team to focus on their value-added activities in the creation of the custom carrier board.


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



Boards

Get an Adiuvo development board



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.


0 comments

Recent Posts

See All

Comments


bottom of page