Assurance Plan for Complex Electronics:

Complex Electronics Background

This printer-friendly page contains the following sections:

• Complex Electronics Overview
• Complex Electronics Design Process
• Mapping Complex Electronics Design to Life Cycles

Complex Electronics Overview

Complex electronics (CE) encompasses programmable and designable complex integrated circuits. “Programmable” logic devices can be programmed by the user and range from simple chips to complex devices capable of being programmed on-the-fly. Some types of programmable devices are:

• Complex Programmable Logic Device (CPLD)
• Field Programmable Gate Arrays (FPGA)
• Application Specific Integrated Circuit (ASIC)
• System-on-chip (SoC)
• In-field or reconfigurable SoC
• FPGA microprocessors/systems
• Reconfigurable computing

“Designable” logic devices are integrated circuits that can be designed but not programmed by the user. The design is submitted to a manufacturer for implementation in the device. Application-Specific Integrated Circuit (ASIC) is an example of a designable device.

In the term complex electronics, the complex adjective is used to distinguish between simple devices, such as off-the-shelf ICs and logic gates, and user-creatable devices. Specific rules for distinguishing between simple and complex electronics are provided in the Planning for Assurance section. A good rule of thumb is, if you can program or design the internal logic of the device and it has more than a few gates and connections, it is probably complex.

Note that firmware (which is essentially software stored on a read-only device) is not considered complex electronics. The integrated circuit (e.g. EPROM) is simple electronics. The program stored in that device is software, which has a defined assurance process in place.

The sections below provide an overview of the various types of complex electronics that are covered by this assurance process.

Complex Programmable Logic Devices (CPLD)

A Complex Programmable Logic Device (CPLD) contains a set of simple Programmable Logic Device (PLD) blocks whose inputs and outputs are connected together by a global interconnection matrix. A CPLD has two levels of programmability: each PLD block can be programmed, and then the interconnections between the PLDs can be programmed. A key feature of the CPLD architecture is the arrangement of logic cells on the periphery of a central shared routing resource. CPLDs use EEPROM, SRAM, or Flash memory to hold the interconnect information.

Field Programmable Gate Array (FPGA)

Field-programmable gate arrays (FPGAs) use a different mechanism, based on gate-array technology, than CPLDs. Field programmable simply means that the device can be programmed by the user. Many field programmable devices can be programmed with the chip soldered to the circuit board, allowing true “in the field” upgrades to be possible.

FPGAs use a grid of logic gates, similar to that of an ordinary gate array. An FPGA has a collection of simple, configurable logic blocks arranged in an array with interspersed switches that can rearrange the interconnections between the logic blocks. Each logic block is individually programmed to perform a logic function (such as AND, OR, XOR, etc.) and then the switches are programmed to connect the blocks so that the complete logic functions are implemented. FPGAs vary in size from tens of thousands of logic gates to over a million.

The interconnections for the logic blocks are programmable switches. FPGAs may use EEPROM, SRAM, antifuse, or Flash technology to store the programming. In most larger FPGAs, the configuration is volatile, and must be re-loaded into the device whenever power is applied or different functionality is required.

Application Specific Integrated Circuit (ASIC)

Application Specific Integrated Circuits (ASICs) are pretty much what their acronym says - integrated circuits (ICs) designed for specific applications. Unlike standard ICs which are produced by the chip manufacturers, ASICs are designed by the end user and then produced in volume. ASICs allow a user to combine many parts and functions into a single chip, reducing cost and improving reliability.

ASICs can be large or small. They are usually produced in large quantities, and it can be very expensive to produce only a few. ASICs can include programmable logic (FPGA, CPLD, and PAL) devices as part of the chip. If the ASIC includes a microprocessor and other computer peripherals, it is usually referred to as a System-on-Chip device.

System-on-Chip (SoC)

System-on-Chip (SoC) combines all the electronics for a complete product into a single chip. SoC’s include not only the brains (e.g. microprocessor) but also all required ancillary electronics, such as switches, comparators, resistors, capacitors, timing elements, and digital logic.

SoCs could include: Digital/analog functions Sensors I/O Communications Ready made sub-circuits (IP) Programmable devices Digital Signal Processor

SoCs are usually ASICs, though they can be designed to include programmable logic components. SoCs can also be implemented on FPGAs. System-on-chip versions come in several flavors:

• Soft Instruction processor architectures allow a designer to customize the CPU architecture. The specific instructions supported, the peripherals available to it, and the number of registers is just some ways these devices can be tailored for your application. Some vendors provide mechanisms to add, delete, and create highly tailored instructions. Design packages for these architectures sometimes include performance tools with instant feedback on the performance, die size and power requirements of a particular design. With the final architecture residing in silicon, these types of architectures are well suited for high volume, low cost applications which formerly would have used ASICs.
• Configurable processors are FPGA based. In these architectures, standard and customer-derived logic engines can be easily added, modified and extended as needed. By moving discrete logic functionality to internal FPGA the designer gets a highly flexible logic solver, based around a standard processor core. With FPGA logic instead of foundry logic, the logic can be easily revised at any point in the design cycle.

In-field or reconfigurable SoC

Most system-on-chip (SoC) designs use what is called a platform-based solution, where standard components like a microprocessor core make up a significant portion of the SoC. Custom devices provide further functionality. Some of those devices may be user-configurable (e.g. if a small FPGA or CPLD is part of the System-on-Chip device), others may be designer-chosen only. These types of SoC’s are usually implemented as ASICs.

A reconfigurable SoC provides the same kind of custom support, except that the devices and peripherals are implemented using a reconfigurable matrix. The software must set up the hardware before it can be used. But from that point on, the platform-based SoC software and reconfigurable SoC software will be very similar, assuming that the microprocessor core is the same or similar and the functionality of the peripherals has the same characteristics.

With reconfigurable SoC designs, the hardware functionality can be changed simply by altering the code that performs system initialization. So, SoC could contain an analog-to-digital converter for one application, and then be reconfigured for a digital-to-analog converter, or even a totally different peripheral such as a network device, for another application. Some elements of the reconfiguration can be performed at a later time (after the basic hardware is initialized), allowing software applications to reconfigure devices

FPGA microprocessors/systems

Some system-on-chip (SoC) devices are implemented entirely on programmable logic, such as field programmable gate arrays (FPGAs). Most reconfigurable SoCs fall into this category. However, reconfigurable SoCs use a fixed microprocessor with reconfigurable peripheral devices. What if you could change your microprocessor by just reprogramming the FPGA? What if you could customize the microprocessor for your application, then change it when that application changes? That is what the FPGA microprocessor systems offer.

Recent advances in software-oriented design tools for FPGAs, combined with the ongoing increase in device densities, create a new environment for software developers. In this environment, the FPGA can be viewed as one possible target (along with traditional and non-traditional processor architectures) for a software compiler. Tools are now available to help software engineers make use of FPGA platforms, as well as platforms where traditional processors (or processor cores) and FPGAs are.

Reconfigurable computing

Typical computer systems use a single microprocessor that executes instructions sequentially. They are adaptable and configurable - you can write any kind of operating system or run any sort of application on a microprocessor. However, these systems trade speed for that adaptability.

If you have a fixed set of applications and really need more processing speed, you want an ASIC designed to meet your needs. While you can gain significant improvement in speed, you lose the ability to change the processor/ASIC uses outside of a narrow range of applications. The ASIC speed increase over general purpose microprocessors comes from a combination of optimization for the specific purpose and the ability to perform processes in parallel.

What if you want speed and adaptability? To gain speed, you need to move from the serial processing paradigm to parallel processing. One way to do this is to use multiple processors, each performing operations in parallel. Another way is through reconfigurable computing. Both of these methods keep the adaptability component, allowing the user, through software, to run a wide variety of applications.

To have reconfigurable computing (RC), you need to have hardware that can be reconfigured to implement specific functionality. RC systems contain programmable hardware and may be combined with traditional microprocessors in order to take advantage of the strengths of each device. RC has been used in applications ranging from embedded systems to high performance computing.

Reconfigurable computing uses in-situ reconfigurable FPGAs as computing devices to accelerate operations which otherwise would be performed by software. The FPGA can be programmed with a digital circuit which implements the function to be performed, such as a fast square root operation. The processor can then access this function, as if it were in its own instruction set. When the processor needs another function, such as multiplying two numbers, the FPGA can be reprogrammed for that function.

To make this all work, the FPGA must be capable of being reconfigured quickly and allow only parts of the device to be reprogrammed. Reconfiguration has to be fast, or you quickly eat up the speed advantage you gain from moving the functions from the microprocessor to dedicated hardware. You would also lose too much time if the FPGA had to be entirely reprogrammed when you just want to change part of it. Fortunately, modern FPGAs are up to the challenge.

Design Process for Complex Electronics

Creating complex electronics begins where all systems and subsystems begin - with defining the requirements for the device. Without good requirements, the most elegant design or implementation could utterly fail to meet the original need. Designing and implementing complex electronics occurs within the context of the larger system, as shown in the stylized diagram below.

Requirements for the complex electronics are driven by the system they are a part of and the environment where they will be used. A simple home appliance will place fewer demands (requirements) on a device than a sophisticated satellite application will. At a minimum, the home appliance usually doesn’t need to worry about high energy cosmic particles that can cause single event upsets. Because these devices are hardware, the process of complex electronics design involves looking at both the chip capabilities and constraints (e.g. how many gates does it have, how much power does it need) and how the design works with and against those constraints and capabilities.

This section covers the following topics:

• Design Life Cycle
• Requirements
• Design Entry
• Design Views
• Synthesis
• Simulation
• Implementation
• Programming the device
• Test
• Verification

Design Life Cycle

The basic design flow starts with the decomposition of system or sub-system requirements to the particular complex electronic device. After that is completed, the engineers take the requirements and generate a design, often in a hardware description language (design entry). The design has to be “compiled” for the device (design synthesis). Synthesis is more complicated than just running a compiler, however. During synthesis, the design is mapped to the logic gates of the device. Simulations are used to verify that the design is correct and can meet the requirements and performance goals.

The implementation of complex electronics involves mapping of the logic (design) to the chip. The placement of the logic blocks within the chip, and the routing between blocks, are some of the processes that occur during implementation. This process is loosely comparable to the linking step in software, where the compiled program is fixed up for the software environment it will operate in. At the end of the implementation phase, the final step is to “burn” or program the device.

While the simulation that occurs before the design is committed to hardware can find most defects, the actual hardware device needs to be tested in the circuit. Real signals are applied and the real output is tested. You usually can’t get the degree of testing with in-circuit verification that you can with simulation, because inputting out-of-range signals might be difficult, access to the hardware pins might not be possible, and in real projects, someone always wants to use the hardware as soon as it’s completed. However, functional testing in a variety of conditions is an important verification step. Errors in the silicon chip are possible. Errors induced by the tools are more likely. And sometimes the real world acts differently than expected and can influence how the device works.

Requirements and Specifications

The first step in the design process is to understand (and document) the functions the complex electronics device must perform and the constraints under which it operates. Designing complex electronics should start with creating the specification, and not with jumping into the design process. The act of documenting the requirements has some useful effects that actually can save you time in the long run:

• The design team thinks through the issues and reaches agreement. Some issues are well understood at a high level, but raise additional questions when working at the hardware level.
• Interfaces to other areas (software, other hardware) are defined and available for review by all affected parties.
• Non-engineers can understand what the chip or device is supposed to do.
• If the trade-offs and rationales are documented, as well as the requirements, future design changes will require less impact assessment.
• The requirements can be reviewed to assure that they provide measurable, testable criteria.
• Requirements traceability into the design and implementation can be performed - which is vital in mission- or safety-critical applications.

Design Entry

The first step in creating a design for complex electronics is to choose how you will enter (capture) your design. Early chip designs were primarily performed with schematic capture. Schematic capture (also called schematic entry) creates the electronic diagram, or schematic, of the electronic circuit. This is usually done interactively with the help of a schematic capture tool also known as schematic editor.

While schematic capture works fine for simple designs, complex electronics almost always require the use of a hardware description language (HDL). HDLs are any languages that are used for formal description of electronic circuits. These languages can describe the operation, design, and simulation tests of the circuit. HDLs can show several aspects of the design, including the temporal behavior and spatial structure. One major difference between HDLs and software languages is the aspect of timing and concurrency.

One very nice aspect of HDLs is that they can be used as “executable specification” to simulate the circuit. Simulation software can be part of the tool suite provided by the vendor or a third-party program. Simulators read the HDL “code” and model the structure and flow of the circuit through time.

The two primary description languages are VHDL and Verilog. Older HDLs, such as ABEL and CUPL, are still in use, especially for simple designs. Another trend in hardware description languages is to add hardware-specific elements to software programming languages. JHDL is implemented on top of the Java language. SystemC adds hardware constructs as a C++ class library. Still, VHDL and Verilog are by far the most common hardware description languages in use.

Regardless of the method chosen to input the design (a hardware description language or schematic capture), a software tool (or tool suite) is required. All major complex electronics vendors offer design tools optimized for their devices at a relatively low cost. Third-party tools are common, and can provide additional capability. These tools are also often quite expensive. However, because the boundaries between design entry, simulation, synthesis, and place-and-route are well defined, designers can mix-and-match tools from different vendors.

A tool suite may include the following types of tools:

• HDL capture and design environment
• May include configuration management
• HDL simulator
• Logic Analyzer
• Logic Synthesis (this is a critically important tool)
• Layout (physical synthesis)
• Design management

Design Views

Complex electronic devices are designed at several levels, and with several “views”, or ways of looking at the device. Each of the various views of the device is refined at each of the levels of representation. The Y diagram below shows how all these views and levels are related.

Modern design approaches for complex electronics focuses on the behavioral/functional aspects of the devices, and uses sophisticated tools to create the appropriate structural and physical aspects of the design. Earlier design approaches required much more manipulation at lower levels of the device circuit. With increasing complexity of the devices, the design aspects have been moved “up” into a more abstract domain, and the grunt work of converting the design into a usable circuit is left to the tools. This abstraction allows the designer and others to understand how the device functions within the context of the system.

A specification in a hardware description language consists of one or more modules. The top level module specifies a closed system containing both test data and hardware models. Component modules normally have input and output ports. Events on the input ports cause changes on the outputs. Events can be either changes in the values of wire variables (i.e., combinational variables) or in the values of reg variables (i.e., register variables), or can be explicitly generated abstract events. Modules can represent pieces of hardware ranging from simple gates to complete systems (e.g., microprocessors), and they can be specified either behaviorally or structurally, or by a combination of the two.

A behavioral specification defines the behavior of a digital system (module) using traditional programming language constructs (e. g., ifs, and assignment statements). This description of a complex electronic device divides the device (chip) into several functional blocks that are interconnected. A hardware description language (HDL) is used to describe the behavior of each block. Functional blocks can be a finite state machine, a set of registers and transfer functions, or even a set of other interconnected functional blocks.

A structural specification expresses the digital system (module) as a hierarchical interconnection of sub modules. The components at the bottom of the hierarchy are either primitives or are specified behaviorally. It is in the structural specification that individual inputs and outputs are defined. The structural specification may also be called the architecture body.

Synthesis

Design synthesis is the process that takes the higher level designs and optimally translates them to a gate-level design which can be mapped to the logic blocks in a complex electronic device. It is during synthesis that timing and area constraints can be specified by the user. Unlike software which executes sequentially, the elements of a complex electronic chip will execute in parallel, with specific timing requirements. However, in general, you can think of synthesis as a form of compiling, translating the readable language into instructions that are implemented in the integrated circuit.

The synthesis step transforms the behavioral and structural specifications into an optimized netlist of gates. The netlist is just a description of the various logic gates in the design and how they are interconnected. During synthesis, the designer can optimize parameters and constraints in the final chip. For example, a certain amount of delay may be necessary when accessing an outside element like a sensor. This delay can be included as a constraint during the synthesis process. Other constraints may be power consumption and signal timing.

Simulation

Simulation is used in the design of complex electronics at several levels. One very nice aspect of hardware description languages is that they are “executable”, and simulators that can run the code are very common. Simulators are usually part of the tool suite provided by the vendor of the complex electronic device (e.g., FPGA).

After design entry, the design is simulated at the register-transfer level (i.e., the HDL code). Simulation at this level is very fast, allowing the designer to implement many simulations to fully understand how the device will operate. Simulation can be used to help optimize the design and refine the logic, though designers need to be careful not to use it in the undisciplined software-style code-and-fix mode. Simulation of the HDL code will look at signals and variables to check their value, trace functions and procedures, and use breakpoints to check the status of the device at specific events. This process is very similar to using a software debugger. One caveat with simulation at this level of design is that some properties are not yet defined, such as timing and resource usage.

After design synthesis, but before physical implementation, functional simulation is used to help verify the design. The goal of functional simulation is to ensure that the logic of the design does what you want it to do, per the specification, and that it produces the correct results. This type of simulation is very important to get as many bugs out of the device as possible. If any errors are discovered, then the design entry step is re-visited and necessary required changes are made, leading to a successful simulation.

After the design has been implemented, but before the device is actually programmed, a final simulation with full timing information is performed. The placement and routing process will determine any delays and other timing information, which are back-annotated to the gate-level netlist. This simulation is a much longer process, because of the timing aspects. A static timing analysis might be substituted for the timing simulation. Static timing analysis calculates the timing of combinational paths between registers and compares it against the designer’s timing constraints.

Implementation

Once a design has been created, simulated, and synthesized, the next step is implementation of the design in the particular complex electronic device. In software, implementation is usually translating the design into source code and compiling it. In complex electronics design, implementation is where the design meets the silicon - the higher level design is converted into a chip layout.

The implementation process uses the tools supplied by the device (e.g., FPGA) vendor. The functions that were defined in the design have to be matched to the available blocks, gates, and other logic elements on the chip. Some basic steps in implementing a design are:

• Floorplan
• Translate
• Map
• Place and Route

Floorplanning is the process of identifying structures that should be placed close together, and allocating space for them. In designing complex electronics, there are multiple goals that must be met, and the goals often conflict. Finding the best balance between the various goals and requirements is something of an art. Some goals are:

• Minimize space on the chip (allows choice of less costly chips)
• Meet or exceed required performance
• Place everything close to everything else to minimize transmission time in the signal paths

Floorplanning does not have to be performed by the designer for many designs/chips. Most tool suites will perform this step as part of the automated sequence that takes the design and implements it in the chip. However, if you are creating an ASIC, need the absolute best timing possible, or are trying to cram a large design into a not-so-large chip, you will probably need to actively floorplan.

Translation involves converting the results of the synthesis process to the format supported internally by the vendor’s place-and-route tools. The incoming netlist is checked for adherence to design rules and is then optimized for the chip.

Mapping takes the logic blocks and determines what logic gates and interconnections on the device should be used to implement those blocks. During the mapping step, the functions within the device (such as counters, registers, or adders) are aligned with the logic resources of the chip. The exact process is device dependent. For example, FPGAs have look-up tables that perform logic operations. The mapping tool (part of the vendor’s tool suite) collects the gates defined by the netlist into groups that will fit within the look-up tables.

Place and Route is the process of placing the logic blocks in the best spots on the chip to achieve efficient routing. Items that the place and route tool will look at include routing length (how far does a signal have to travel), track congestion (how many signals are coming into or out of an area), and path delays. While the process is usually performed automatically by the vendor-supplied tools, the designer can specify some parameters and constraints that the final layout has to meet, including:

• the initial placement of the cells
• a position for each physical connector
• a form factor

Programming the device

Once the design is successfully verified and found to meet timing and performance requirements, the final step is to actually program the device. At the completion of placement and routing, a binary programming file is created. It’s used to configure the device. The process of programming is usually dependent on the type of memory used to store the device configuration and on the device type (e.g., FPGA or ASIC).

Test

Once the device is programmed, a set of functional tests are performed to verify the device programming was correct, and that there are no silicon or tool-induced defects that affect the device. The level of testing performed depends on how critical the device is – mission or safety critical devices will undergo more thorough functional tests than those that play a less important role.

Verification

Verification is a parallel set of activities to design and development. Various tasks are performed at each phase of the development. The specific verification activities, performed by either the design engineer or quality assurance, are listed in the appropriate life cycle phase.

Mapping Complex Electronics Design to Project Life Cycle

The life cycle for complex electronics design is a subset of the total project or system life cycle. However, complex electronics also follows the same basic development process as the project. To understand how the two fit together, this section provides:

• Mapping from the complex electronics design activities to a basic project life cycle
• Mapping of complex electronics design activities to specific phase names.

Terminology used for life cycle phases varies within NASA, other government agencies, and industry. The terms used here are a commonly defined set. The listed project activities are meant to define the main activities the project will be performing. The life cycle is defined as a Waterfall life cycle because it is conceptually easy to understand. The actual timing of the phases and activities will vary with the chosen system life cycle, such as a spiral or iterative model.

The mapping between complex electronics activities and project life cycle phases is meant as a guideline only. The actual time when an activity is performed is dependent of the project, the life cycle chosen for system development, and the complex electronics type.

Project Life Cycle Phase	Project Activities	Complex Electronics (CE) Activities
Concept (Conceptual Design)	Define system concept Identify system requirements Planning for: Project tracking and control Supporting processes (e.g. configuration management, quality assurance, safety) Verification
Preliminary Design	Allocate system requirements to sub-systems Trade-off studies Create preliminary system design Identify interfaces Perform supporting processes	Planning Determine CE requirements Feasibility studies Architectural design Design verification
Detailed Design	Refine system design Prepare for implementation Baseline system design and interfaces Perform supporting processes	Design Entry Synthesis Simulation Timing Analysis Design verification
Implementation and Integration	Turn system design into hardware/software Put the pieces together Low-level testing Perform supporting processes	Floorplanning Place and Route Program/Manufacture Device testing Integration with other electronics
Test, Verification, Validation	System-level testing Acceptance testing/Validation Complete verification activities Perform supporting processes	Functional testing Environmental testing Complete verification activities
Operations and Maintenance	Install system Operate system Perform routine maintenance Repair and upgrade Perform supporting processes	Upgrade CE (if reprogrammable)

In the table above, the project “preliminary design” phase included the planning, requirements, and preliminary design for the complex electronics. The life cycles section of this assurance plan relates to the life cycle for complex electronics, and not for the project as a whole. Therefore, planning and requirements are broken out into separate phases.

The complex electronics development activities are grouped into the following phases:

Life Cycle Phase	Complex Electronics (CE) Activities
Planning	Planning (for development, verification, safety, and assurance)
Requirements	Determine CE requirements Feasibility studies
Preliminary Design	Architectural design Design Entry Design verification
Detailed Design	Synthesis Simulation Timing Analysis Design verification
Implementation	Floorplanning Place and Route Program/Manufacture Device testing
Integration	Integration with other electronics Testing at board or sub-system level
Testing	Functional testing at system level Environmental testing Complete verification activities
Operations and Maintenance	Upgrade CE (if reprogrammable)

Verification and Validation (V&V) are not included in the above table, because they are processes that occur throughout the life cycle. For example, testing is one method to verify that the system meets the requirements. An acceptance test or demonstration is a validation activity if the customer uses it to determine if the system is performing as the customer expects. Tests usually occur later in the project life cycle. Prototyping and simulation are early-life cycle validation activities. Reviews at each life cycle phase that determine that product (design architecture, low-level design, and test procedure) correctly and completely meet the requirements are verification activities.