SAR Case Study

5.1 Detailed Design Process Description

Because most of the software developments were verified during the architecture process, software developments in the detailed-design-process step were limited to creating those elements that were target-specific: configuration files, bootstrap and download code, target- specific test code, etc.

The top level of a detailed, behavioral, virtual prototype was a structural VHDL model defining interconnection between individual elements that made up the system, board, or module being modeled ( Figure 5- 2). The element models at the lowest level of the hierarchy were behavioral models that described function and timing, with typical lowest level elements being Application-Specific Integrated Circuits (ASICs), Programmable Logic Devices (PLD), memories, and Commercial, Off-The-Shelf (COTS) components. The COTS component could either be a chip or several chips packaged together, such as a Multi-chip Module (MCM).

The structural model at the top level of the detailed, behavioral, virtual prototype allowed the interchange of different models for the same element. For example, in the early stages of the design, functions may not have been partitioned between individual components [ASICs, Field-Programmable Gate Arrays (FPGA), PALS, etc.], and may be modeled by one composite component. Once designers partitioned the functions into individual components, they extended the structural model down an additional level of hierarchy. Post-synthesis models of custom components were used for component design verification in the virtual prototype. Data resolution on the signals between elements was bit-true. The simulation yielded the signal logic values as they would appear in the hardware when executing the same software function. A VHDL testbench applied stimulus to the VHDL model during simulation, and compared simulation outputs to the expected outputs.

The detailed, behavioral ,virtual prototype can perform timing analysis at two levels: Cycle true timing checked the time sequencing of events or signals on a cycle-by-cycle basis, such as bus-interface protocol. The second level of timing analysis checked timing within a clock cycle. This required that the component models included timing information, such as output-signal propagation delays, set-up times, and hold times. The simulations can investigate the impact of clock frequency and skew variations. A special case of clock- skew-variation investigation was simulation of systems with two or more independent clocks.

A virtual prototype was developed for the Data I/O board but not for the other boards in the SAR processor. The Data I/O board was a new board design, while the processor boards and host interface board were COTS boards, requiring no new hardware design. The purpose of the virtual prototype of the Data I/O board was to verify the correctness of the hardware design and hardware/software interaction. The virtual prototype also served as a platform for defining two new FPGAs developed for the Data I/O board. During the test and integration of the SAR's hardware/software, the virtual prototype was used to investigate anomalies and to verify changes before they were made to the hardware. The virtual prototype also served as design documentation for the Data I/O board.

The component models were at the lowest level in the model hierarchy. Only the functionality and I/O behavior were modeled for COTS components. Modeling internal details of COTS components added no value to the virtual prototype and was likely to increase the time required for a simulation run. The important thing for COTS component models was that function and timing be accurately modeled at the component I/O interface. The VHDL models for the two new FPGAs were taken down to the RTL level and included only constructs that could be handled by FPGA synthesis tools. Developing the FPGA models directly in synthesizable VHDL eliminated the intermediate step of first developing a higher level functional model of the FPGA.

The existing components that proved most difficult to model were the two RACEway FPGAs purchased from Mercury Computer Systems, Inc. Lockheed Martin Advanced Technology Laboratories (LM ATL) used proprietary information from Mercury to develop models for these two ASICs at the RTL level. This information was in the form of schematics and partial VHDL. Modeling to the RTL level was not required because LM ATL was not changing the internal design of the FPGAs. However, RTL-level models were easier than higher level functional models to generate using the information that was available. A full understanding of the FPGA operation was not required to generate RTL- level VHDL from the schematics, and all existing VHDL was at the RTL level. There was no noticeable impact on simulation time resulting from using RTL level models.

The only active components on the Data I/O board that were not included in the structural model were the Electrically Programmable Read Only Memories (EPROMs) that configured the FPGAs when power was first applied to the board. The FPGA configuration process was not modeled because the FPGA models already defined the functionality of the FPGAs.

One section of the testbench models the VMEbus activity, including writes and reads of memory-mapped registers on the Data I/O board. The testbench read the FIR filter coefficients from a file and loaded them into the FIR filter. Changing FIR filter coefficients between simulation runs did not require any change to the testbench, only a different coefficient file. Therefore, the software operations of loading FIR filter coefficients, loading other control registers, and reading status registers over the VMEbus were verified on the virtual-prototype model of the hardware prior to hardware build.

The simplest form of the testbench operated the Hot Rod fiber-optic interface in loop-back mode, a valid test mode for the Data I/O board (Figure 5-4). The testbench connected transmit data back to receive data on the Hot Rod interface. One version of the testbench supplied input data and captured output data in data files when exercising the Hot Rod interface. Another testbench operated with the executable-specification testbench as the data source and sink. These testbenches were used to verify the operation of the Data I/O board in different simulations.

Both input and output of data were modeled on the RACEway interface port. Data being applied to the Data I/O board RACEway port was read from one file by the testbench, and the board's data output to RACEway was stored in another file by the testbench. The captured data could then be compared with the expected data. The testbench modeled RACEway protocol and the sequence of operations performed by the software during data I/O operations. This verified that the RACEway port's hardware would respond correctly to software-initiated commands and RACEway protocol.

For the SAR processor, it was not necessary to redesign the Data I/O board or its FIR filter daughter card. The problems encountered during integration and test were due to manufacturing defects, incorrect or misleading vendor documentation, and synthesis tool problems. Two wires were added to the Data I/O module as a result of defects found during test and integration. The first wire corrected a problem resulting from a misinterpretation of vendor-supplied documentation for the RACEway interface ASICs. The second wire changed the operation mode of the Hot Rod fiber-optic interface. The Hot Rod was unreliable in the original operation mode. Both FPGAs were resynthesized during test and integration along with associated update of the FPGA design documentation.

5.2.2 Detailed Board Design Process

The Data I/O board design was reviewed for possible testability improvements. The modifications, which were incorporated into the design, included test modes for counters, short cycling of counters in test modes, capability to operate with a single external-clock source, deterministic state at reset, and synchronous operation (whenever possible). A Joint Test Action Group (JTAG) test port was incorporated into the Data I/O design, and scan buffers were inserted at strategic points in the data paths. These features enabled test vectors to be developed for testing either from the JTAG port or by a board tester. All of these features were modeled and verified in the detailed, behavioral, virtual prototype with the exception of JTAG. The JTAG was not modeled because it was not used during the actual hardware test, and it would have required significant additions to the component models.

The Data I/O module was designed so that manufacturing test vectors could be extracted from the Data I/O's behavioral, virtual-prototype simulations. The input vectors were generated by the testbench, and the expected response captured at the interface between the Data I/O module and the testbench.

Mentor's Design Architect tool was used to capture the schematics detailing the interconnect between module components. The interconnect was compared for consistency against the interconnect of the structural VHDL in the top-level ,detailed, behavioral model.

The timing of the Data I/O module was analyzed by adding timing generics to the component models in the detailed behavioral model. The timing for COTS components was taken from component data sheets and the timing for the FPGAs was taken from static- timing analysis of the synthesized FPGAs. The Data I/O module was simulated using worst-case timing for all components.

A drawing package was created for both board designs that made up the Data I/O module. This drawing package contained all the information needed to fabricate and assemble the boards. The Data I/O module design and theory of operation are described in Data I/O Board Hardware Description and Operation. This document describes all connectors and I/O signals and memory-mapped registers, and it describes in detail the operation of Data I/O. It proved invaluable during test and integration.

The FPGA logic was synthesized using Synopsys' FPGA Analyzer tool. The FPGA VHDL was imported into the Synopsys environment from the Mentor QuickVHDL environment. which had been used up to this point. This demonstrated an advantage of using a common language (VHDL) throughout the design process. The Synopsys output was used as the input to the NeoCAD tool that mapped the synthesized logic to the physical structure of the ATT2C15 ORCA FPGA. Any changes made in the design for synthesis purposes were reflected back to the VHDL model in the detailed, behavioral, virtual prototype. Therefore, all changes were verified in the detailed, behavioral, virtual prototype.

The Static Timing Analyzer tool in the NeoCAD tool set was used to extract timing information from the two FPGA designs following placement and route. The extracted timing was back-annotated by hand into the virtual prototyped FPGA models, and the suite of simulations were performed again to verify timing at the Data I/O board level. Although this process verified timing, it did not check functionality of the final hardware implementation. A consequence was the failure to detect several logic faults introduced by the tools, and these faults were not found until test and integration

The preferred back-annotation approach would be to extract the structural VHDL model along with a Standard Delay Format (SDF) file from the FPGA layout. The structural model SDF file, and the library of cell primitives for the FPGA technology would then combine to generate the back-annotation model of the FPGA. The virtual-prototype simulations would then be performed with the back-annotation model replacing the originally developed FPGA models. This approach was not taken because the NeoCAD tool did not have VHDL-netlist capability at that time.

• Multilevel virtual prototypes were highly accurate and invaluable in quickly developing the SAR processor's design. The detailed design of the Data I/O board was functionally verified in the abstract, behavioral, virtual prototype. This minimized risk in translating requirements developed in the architecture process to the detailed
  
  Figure 5- 6: Front of Data I/O module without two daughter cards.

  design implementation. This verification was possible because the models at both virtual-prototype levels were developed in a common language (VHDL), and the two virtual prototypes were developed with a common structural hierarchy.

• The hierarchy in the detailed behavioral model should be taken down only far enough to describe that which constitutes a new design. Taking the hierarchy down too far increased simulation time and provided little payoff in simulation accuracy. For example, models of COTS components need not include internal detail of the component over which the designer has no control. Commercial, off-the-shelf component models need only model the function and timing at the component interface. In the case of a new component design, such as the FPGAs, the model should include internal detail needed to complete the design. Developing the FPGA models in synthesizable RTL-level VHDL eliminated the need to generate separate FPGA models for virtual prototyping and for synthesis.

• Design errors were minimized by matching the structural, VHDL, virtual- prototype model to the board or module layout in terms of signal interconnect and components. The PCB netlists were checked against the virtual-prototype structural model, and several differences were resolved prior to release of PCB designs for fabrication.

• The detailed, behavioral, virtual prototype was a good platform to define the two new FPGAs. The same VHDL model was used to verify the design of the Data I/O board and as input to the FPGA synthesis tools. This eliminated errors in implementing FPGA logic because the VHDL used to synthesize the FPGA was verified at the module level. Several problems were encountered where the FPGA synthesis tools failed to correctly synthesize FPGA's VHDL code. Some of the synthesis problems could be attributed to lack of familiarity with the tools, but it pointed out the need to back-annotate the synthesis output into the detailed, behavioral, virtual prototype.

• Two proprietary FPGAs from Mercury Computer Systems were used in the design of the Data I/O board's interface to RACEway. The use of these FPGAs saved design time and reduced design risk but it posed several problems in the design process. First, a complete VHDL model did not exist for either FPGA. This problem was addressed by generating models from partial VHDL and schematics obtained from Mercury Computer Systems. A misinterpretation of the data resulted in a model error that later required one wire to be added to the Data I/O board during integration and test. This pointed out one of the hazards in developing component models from someone else's documentation. However, the risk and cost of using the existing FPGAs was still less than redesigning the interface. A second issue was that the virtual prototype now contained proprietary models.

• Design defects are often a result of designers misinterpreting interface specifications. Interface incompatibilities were eliminated from a design if the virtual- prototype simulations covered all operational scenarios, and the components were accurately modeled with respect to functionality and timing. The key was having the virtual prototype model components on both sides of an interface, including when the components were modeled by the testbench.