Military productivity factors in large FPGA designs

Changes in technology and requirements are leading to FPGAs playing larger roles in defense electronics designs, and consequently are creating both opportunities and risks. The opportunities include consolidation of systems into smaller and more power-efficient form factors, while the risks include design times, new Department of Defense special requirements, complexity of integration, and changes in required skill sets in the organization.

This article looks at the productivity-related risk factors, assesses their impact on designs, and attempts to quantify the risk effects of productivity on the design organization. Then, once these risks are assessed and defined, an initial cost survey is performed to discover how much of a design effort’s cost is related to the productivity tools used in both system and FPGA development.IDENTIFYING PRODUCTIVITY RISKS

Several different productivity risk factors affect defense electronic designs with FPGA design components, including personnel- and team-based schedules, intellectual property (IP) re-use and integration, DO-254 and other certifications, and system verification.

Personnel- and team-based schedules: FPGA design has often been approached and managed as an individual effort, where requirements and perhaps interface definitions are developed and handed to a single developer to turn into an FPGA. However, due to complexity, density, and third-party IP use, FPGA design and development is increasingly a team-based activity.

Where there are many opportunities to create defense organizations that take advantage of team-based design, this setup leads to several cost risks, as shown in Figure 1. The first and perhaps most important is the shortage of trained design personnel with the capability to obtain necessary security clearances. Another is the length of development schedules, especially given the addition of new verification and safety certifications in FPGA-based design. Product support and technical maturity of new technologies are quantifiable risks that must be tracked in large defense programs.

IP re-use and integration: Relying on third-party IP specialists and the re-use of common IP cores from other programs is a sensible cost reduction, but increases the resulting integration portion of FPGA-based designs, as shown in Figure 2. This is both a well-established risk and opportunity in FPGA-based design, and is most controllable when using software tools that automate the design block interconnects.

DO-254 and other certifications: Defense designs have special requirements beyond those of the normal commercial designs and tool chains. The one currently affecting defense designs the most is Design Assurance Guidance DO-254 for aviation safety. Others include common criteria verification, fail-safe design, and in some cases “trusted integrated circuit” certification or verification, all of which impact design productivity. Planning for certification and documentation activities must be planned in advance of design and development, so the impact of certification activities can be controlled and measured.

System verification: Verification is the other portion of system design that becomes a significant cost risk with design growth. The verification steps expand with the number of interconnects and potential block IP states. As shown in Figure 3, test cases can grow exponentially if not controlled and defined intelligently. When problems are discovered or requirements re-defined in verification, it is important to take an incremental approach to redesign and recompile of the design. Otherwise, burdensome compile times pose a significant risk to program schedule and resources.

FPGA productivity advantages in defense designs can be realized from the following characteristics of the Quartus II design suite. The Quartus II design suite is a bundle of FPGA design, test, verification, simulation, timing, power estimation, and place-and-route software provided by Altera for the development of designs using Altera FPGAs. The PowerPlay portion of the software allows designers to estimate and control static power consumption in designs. The Early Power Estimator is a set of parameterized spreadsheets that allows designers an accurate first look at their expected design power budget.

Incremental compile is a software-enabled system allowing designers to partition FPGA designs at inception and divide the design into distinct blocks. LogicLock allows these individual partitions to be compiled separately, and to retain their timing constraints when other partitions are independently recompiled. The process of partitioning designs into lower blocks in the architectural design phase is referred to as “bottom-up design.”

SOPC Builder is a tool bundled with Quartus II software that allows simple integration of IP blocks in an FPGA design. While the DSP Builder tool allows designers to easily transfer MATLAB- and Simulink-based design flows into FPGA instantiations. The advanced version of the DSP Builder tool allows user-provided timing constraints and latency constraints.MILITARY DESIGN EXAMPLE

In order to illustrate potential design productivity savings in an optimized design flow, a sample FPGA-based design was developed and measured with a third-party design estimation tool. This design example was co-developed with engineers at Galorath, creators of SEER-SW, SEER-H, and SEER-IC software. These tools allow users to enter parametric descriptions of their equipment designs, and to develop cost and schedule estimates for both proposal development and resource planning. The estimates are based on knowledge databases developed by Galorath and various users of the SEER-series software tools.

The military design example shown in Table 1 takes advantage of the 40nm Stratix FPGAs. This cost estimate focuses on the FPGA design only, and includes design, verification, place-and-route, and simulation, but not board design. The SEER-IC estimation tool allows the user to enter lower and upper requirement and parameter limits to measure cost and schedule risk, as well. This design example is assumed to be a very large, multi-channel sensor design. Logic element (LE) cost will likely put it in the Stratix IV class of FPGAs. There is a large number of I/O pins and new design (50 percent). The complexity of both the interfaces (front end) and processing (back end) is relatively high. Current development tools and practices are estimated to be low quality, and the (average) capability of the designers to be nominal. Requirements volatility is assumed to be normal for military programs.

Using a military FPGA design example such as this allows the user to estimate their program cost and schedule, measure progress, and control costs, as shown in Figure 4. In addition, it allows the user to look at the total impact of software productivity as an independent variable in vendor selection.

Using the assumptions described, Table 2 shows the total cost of the military reference design in both hours and dollars, using a placeholder labor hour cost. This will serve as the basis cost for estimating both the impact of software on program cost, as well as potential savings for other programs. Galorath’s SEER-IC tool divides cost into categories of architectural design, detail design, simulation, verification, and implementation, and place-and-route. The total labor effort for this application comes out to 13,800 hours, at a nominal cost of $2.7 million. Because most military programs do not lend themselves to high-volume builds, it is easy to see from this example that the NRE, or design development portion of an FPGA-based design (shown in Figure 5), is becoming one of the largest components, and a cost and schedule driver, of defense electronics. This makes it more important than ever to consider software productivity as a selection factor.

Using this design as an example, the Galorath SEER-IC tool allows the designer to isolate the impact of software on the overall FPGA-based design by leaving all other factors the same, but entering “low quality” and then “very high quality” in the “development tools and practices” input parameter. This yields the following cost swing due to software productivity:

Low-quality development tools and practices $3,199,279

Very high-quality development tools and practices $2,132,852

This equates to a total program development cost difference of $1,066,427, or 33 percent of the development cost. For the purposes of this design example, it will be considered the upper limit of what productivity savings a program can expect to see from adopting a higher productivity tool suite and set of design practices.

The next step in this design example is to determine what characteristics of a military FPGA design will offer the greatest savings from productivity tools, and assessing what potential productivity gains can be made from the Quartus II software.

Military designs are assessed on how interdependent they are with other system FPGAs, and how well the organization can divide functional blocks within a multi-FPGA design in a team-based fashion. Potential design savings is highly dependent on both the degree and methodology of IP re-use and design IP encapsulation within the design organization. Automation of interconnect tasks and data routing can lead to design savings between 10 to 25 percent of this phase of design.

The high degree of unit-level, test and use case-based verification in military designs automatically makes most designs capable of increasing productivity simply through compile time improvements. Characteristics of a design that modulate these savings include requirements volatility, high-level certifications (DO-254), and verification oversight. Total savings in this phase ranges from 10 to 25 percent.

CONCLUSION

Modern military design requirements call for modern FPGA design tools. Design parameters such as compile times have become cost and schedule drivers, and they are beginning to make measurable differences in both the FPGA design and the overall system design budget. When designing a modern military system, it is essential to factor the costs of development into both the program cost baseline, and in your vendor selection criteria.



Click here for the illustrations:

Figure 1, Figure 2, Table 1, Table 2