Copyright Shutterstock

Since the trusted foundry crisis of a few years ago, the aerospace and defence industry has re-examined its microelectronics strategy and recognised that its practices and use of advanced semiconductor manufacturing technology is lagging the commercial industry and those of potential adversaries. However, there are many oft-cited issues that create barriers to application of advanced node semiconductor technology. This article provides a quick survey of the top objections and provides brief remedy descriptions for the barriers.

Advertisement

1.    Prototyping Iteration Time: In many defence programmes the rush to initial demonstration (and milestone payment) is detrimental to overall programme costs and results. The process of physically prototyping a potential solution to an engineering challenge takes time. While it is not advisable to try and avoid early physical realisations of systems altogether, it is a best practice to short-circuit those solutions that will not ultimately suffice for eventual system production. The remedy is to apply new analysis tools and methods to the design efforts already being expended. Applying these techniques can save weeks, months and even years on complex programmes.
 

Short Circuit Infeasible Physical Prototypes

2.    Prototyping Debug: Determining whether a physical prototype of a system will fulfil the eventual system mission is a complex, time-consuming task. When shortcomings are identified, the physical prototype can be the worst possible place to debug microelectronics. While some access points are typically available via package/board pins and debug features, getting to the root cause can be a frustratingly labourious process. Yet, in aerospace and defence programmes it is common practice to 'build one and see why it doesn’t work'. The remedy is to use the design collateral necessary for prototype development as the basis for virtual execution of the system’s functions, where complete device internal visibility is possible.

Internal Device Visibility is Problematic

3.    Prototyping SWAP Accuracy: Often the cheapest, shortest schedule bid is the winner for capability prototype development in complex defence programmes. Also, frequently the size, weight and power (SWaP) requirements for the end system are ignored for the prototyping stage. This in turn leads to prototypes whose SWaP characteristics bear no resemblance to those that will be found in the production system. This is a recipe for surprises that result in cost and schedule over-runs, as well as over-design at the system level to compensate for prototype SWaP inferiority. The remedy is to augment the virtual execution of the design with physical analysis tools that also operate on the design data being developed for the physical prototype.

Discrepancy Between Prototype and Production SWaP Values

4.    SWaP Tradeoff Analysis: In order to create an accurate picture of the relative SWaP merits of alternate design solutions, a considerable effort must be expended. Because of the cost, many defence programmes pursue only a single presumptively optimal solution. Those that do pursue the exploration of multiple paths expend valuable resources for an extended period of time. Each path, whether executed in parallel or serially, represents considerable cost. The remedy is simply to apply the same tools and methods described in #3 above with the appropriate physical design kit (PDK) for each target technology of interest.
 

Prototyping for SWAP Trade-off Analysis

5.    Prototyping Iteration Cost: The standard approach to defence system prototype development and evaluation has been to carry a concept forward to fruition and then perform the assessment. This approach represents the maximum length for each iteration. Further, the distance in time between steps in the iterations only serves to dim the familiarity of the designer with the intricacies of the design. The remedy is to introduce the intervening methods described in #1, to short-circuit as many infeasible solutions as possible. Because time and materials represent cost, these methods minimise cost.

Prolonged Iteration Cycles

6.    Delay in Software Development and Integration:  Another common practice in defence system development is the serialisation of the hardware and software development processes. This can be an artifact of programme structure, or simply an ingrained historic practice. This practice maximises the overall development cycle and necessitates software-only fixes to late cycle issues uncovered. This often represents compromise on the SWaP system requirements. The remedy is to apply the established virtual execution environment for the hardware and use the software to drive the execution.
 

Serialised Hardware-Software Development

7.    Obsolete Part Replacement: Diminishing manufacturing sources (DMS) are a fact of life for aerospace and defence systems in this fast-paced, commercially driven world. It is no longer a question of whether the problem of part sourcing will become an issue or not during the prolonged life cycles of these systems. The pressing question is – have you adequately prepared for the eventuality? Will you be able to seize DMS as an opportunity for not just system maintenance but for system upgrade and capability/mission enhancement? The remedy, which should now sound familiar, is to apply a virtual execution environment but this time physically connected to the rest of the mission environment (hardware and software).

Obsolete Part Form, Fit, Function Requirements

Demystifying the Virtual Execution Environment
The aforementioned oft-cited virtual execution environment is readily available and being used widely by the majority of microelectronics design teams in consumer, automotive, communications, medical and other market segments.

Advertisement

The commercial electronics industry has developed a methodology that directly addresses the drawbacks of historical approaches. A System Prototyping methodology introduces an emulation and analysis step, as well as an explicit go/no-go step prior to committing an idea to a physical prototyping step. By using the System Prototyping methodology and metric-driven verification, companies can transition capability faster to successful finished products of higher performance and quality.

The figure below depicts the intervening position of System Prototyping. By inserting System Prototyping at this location, the time and cost of physical prototyping infeasible ideas/concepts can be short-circuited.

The System Prototyping methodology introduces intermediate SWaP analysis based on actual target technology rather than physical prototyping; enables multiple target technology tradeoffs

Incorporating these two new System Prototyping steps significantly addresses the shortcomings of the 'automatic fast path to prototype' approach:

• Faster/lower cost path to failure for infeasible concepts/ideas
• First-pass success of physical prototype with regards to function
• Confidence to use advanced process technology rather than FPGA for prototype
• Short-circuit physical prototyping of function and target technology accurate SWaP infeasible solution paths
• Ability to explore SWaP in multiple technologies more accurately without redesign

Emulation for System Prototyping
Emulation is a vital technology for system prototyping because it provides the combination of capacity, run-time performance, accuracy, linkages to physical analysis (e.g. performance and power, thermal) and visibility necessary to make accurate go/no-go decisions. Its performance is great enough to enable running application software on hardware designs resident in the emulator. Highly successful commercial companies such as NVIDIA use many emulation systems for System Prototyping flows.

Emulation technology, coupled with the System Prototyping methodology, provides insurance that new device designs can interoperate with existing components, subsystems and systems. The in-circuit-emulation (ICE) use model can be used to emulate the new design physically coupled to existing devices and boards.

Emulation systems test interoperability prior to physical prototyping and production manufacturing

The ABCs of Getting Started
Fortunately for all, getting started with System Prototyping is a straightforward process:
A Model the new hardware in a hardware description language (e.g. VHDL or Verilog) and compile it with the emulation system software
B Physically connect the emulator to any parts of the system to which the new hardware will be connected
C Load the mission software into the emulator and execute the new hardware design within the system context to assess functional completeness/correctness and interoperability
D Load the simulated/previously captured mission-specific data to drive the system execution scenario
E Apply execution traces to the analytics engines. These can be used prior to system manufacture for design assessment, and after manufacture for predictive maintenance.

 
System Prototyping Steps to Success

Whether you are working on the next generation fighter jet or upgrading a night vision rifle scope, System Prototyping can improve your team’s performance and the programme’s outcome. Further, your programme has readied your organisation for higher performance and lower cost on upgrade and derivative programmes.

Steve Carlson is Director and Solutions Architect, Aerospace and Defence

James Chew is Group Director, Aerospace and Defence

Advertisement