Next: 3.0 ETC4ALFS on COTS Summary Up: Case Studies Index Previous:1.0 Introduction

Benchmark 3 Case Study

2.0 UYS-2A Signal Processor Upgrade

A VHDL performance model was created for the three modules of FPCAP/FE. Performance modeling simulation of the required processing showed the architecture meeting processing, memory, and communication bandwidth requirements.

2.1 FPCTL Module and software development

The development of the VHDL based virtual prototype of the FPCTL module was an important step in the design process in several critical areas:

• Hardware/ software co-design and investigation of design alternatives
• FPGA and PLD definition
• System verification
• Test vector generation

The virtual prototype was used to verify the design of both the hardware and software interfaces to the AN/UYS-2A legacy system and the internal interfaces within the FPCTL. This functionality verification consisted of simulating of the hardware performing low-level software operations. The detailed behavior virtual prototype also verified the operation of the FPGA and PALs designs.

The 13-week design cycle for the FPCTL module entailed concurrent design in which the virtual prototype, logic design, PCB layout, and software design proceeded in parallel. The exchange of information between the different design activities at different locations was facilitated by weekly conference calls between all parties. Preliminary versions of the hardware design and software design specifications were generated and distributed to all members of the design team for review by electronic mail. These specifications were updated at least every two weeks, and were used as the basis to decide modification to hardware and system architectures. Manufacturing engineers were brought in early in the design process to insure that the final design could be manufactured at lowest possible risk and cost. The result was a rapid turn-around of the FPCTL design with no "surprises" during module assembly, module test and system integration.

The FPCTL design shown in figure 2-1 makes use of four custom legacy ASICs of two types, the PIP/POP and the CBI/FBIT, that were designed by AT&T (now Lucent Technologies) for the AN/UYS-2A. The existing VHDL code for these two ASICs was incorporated into the detailed behavior virtual prototype. It was found that the ASIC BIST features, and several other features supporting test, were not modeled. Some additions were made to the ASIC VHDL models to provide minimal coverage of these features. The PIP/POP and CBI/FBIT ASICs are being used in a manner for which they were not designed. Using the ASIC VHDL models with the FPGA VHDL model, a new interface was developed that allowed current components to replace obsolete components. During simulation behaviors were encountered that were not anticipated from reading of the written documentation. As a result, several potential errors in interfacing to the ASICs were detected early in the design process. A big benefit from using the legacy VHDL models is the unambiguous nature of the VHDL code when compared with written documentation. Without the legacy VHDL models, insufficient information would have been available for designing the interface to the legacy ASICs without errors.

Figure 2-1 FPCTL Block Diagram

A challenging facet of FPCTL design is the interface between the various asynchronous ports, each with its own protocol. It provides all the communications interfaces to the AN/UYS-2A system buses:

• The full duplex DTN port that sends and/or receives asynchronous data at a 10-Mword (40-Mbyte) per second rate. FIFOs are used for buffering of data at the asynchronous interfaces.
• The CBUS port for short control messages over the AN/UYS-2A system control bus (CBUS). The Bus Interface FPGA handles the asynchronous interface, and provides SHARC control via memory-mapped status and control registers.
• The BIT CBUS port for system test messages over the AN/UYS-2A built in test control bus (BIT CBUS).

As well as the communications to the FPCAP modules via the LANai, a RISC processor that provides the interface between a Myrinet link (160 Mbytes per second bandwidth in each direction) and the SHARC External Processor Bus. Myrinet data being sent or received is buffered in the high-speed 128K LANai SRAM. A 128K-by-48 SRAM that can be accessed by either the SHARC or the LANai, a 512K-by-8 flash memory that boots the SHARC at power-up, a test bus controller for JTAG test of FPCAP modules, and two independent clock oscillators with clock buffers.

2.2 Virtual Prototype and Design-for-Test accelerated integration

To facilitate the use of the latest technology in new systems and the insertion of new technology into existing systems, RASSP defined the concept of hierarchical virtual prototyping for embedded multiprocessor systems. The virtual prototype provides the ability to simultaneously simulate the hardware/software co-design and predicts the performance of the design on the hardware architectures prior to building the hardware.

Exercising the detailed behavior virtual prototypes through the various operational modes performed design verification testing prior to hardware build. The result of the design verification was a design that met functional and performance objectives. The FPCTL board design had no redesign iterations, and only 4 white wire corrections were required on one of the two custom printed wiring boards on the SEM-E module shown in Figure 2-2. The corrections were necessary to correct problems due to a glitch out of one the legacy ASICs and fix a design error due to a late change in one of the FIFOs for board space reduction which was not adequately modified on the virtual prototype.

Figure 2-2 FPCTL Module

The FPCTL is a dense surface mount module preventing significant probing during test and integration. As a result, the virtual prototype was used to provide insight into the observed hardware operation. The virtual prototype was used to determine if hardware failure, design flaws, or simple misunderstandings were the cause of unexpected behaviors.

The FPCTL modules were quickly tested and debugged in 4 weeks which included verifying test programs on a Teradyne L297 Automatic Test Equipment (ATE) for manufacturing test and on a PC for field testing. This is a saving of more then a month off past designs. This 2X quicker completion of module testing was due to the design-for-test features in the hardware and software design.

1. JTAG serial scan paths are incorporated into the designs. Each FPCTL and FPCAP module can be independently tested from its JTAG port on the module test connector.

2. Manufacturing test of the SEM-E module hardware was done on a Teradyne L297 tester using test patterns developed from the virtual prototype. Several features were incorporated into the design to support this method of manufacturing test. A test connector was added to bring critical signals needed for controllability and observability to the module boundary for test access. In particular, the entire SHARC bus is brought to the test connector, thereby enabling the tester to perform reads and writes on the bus. During manufacturing test, the SHARC can be disabled, the internal clock oscillators replaced with a clock from the tester, and the various asynchronous interfaces made synchronous and deterministic. Since the number of pins in the test connector is limited, logic was added to the FPGA in the form of readable status registers. This provides observability of signals, such as the FIFO flags, that are not on the test connector.
   

   Figure 2-3 Teradyne 297 FPCTL test set-up for production test

   
   

3. An inexpensive field/depot testing of the module was set-up with a personal computer (PC) with an EZ-LAB module installed and a modified Teradyne test fixture. The first step in PC based testing is to use the JTAG interface for EZ-ICE testing of the SHARC processor. Once the SHARC functionality is established, EZ-LAB is used to conduct tests. EZ-LAB uses the SHARC links rather than the JTAG port. The SHARC link ports needed for EZ-LAB testing are brought to the test connector. Test programs are loaded into SHARC program memory, and the SHARC conducts test on the other FPCTL components. A modification of the Teradyne test fixture is used to loop the CBUS, DTN bus, and Myrinet bus output ports back to input ports when performing the tests outside the AN/UYS-2A chassis. Error detection logic in the FPGA is used to detect any bus error conditions with additional information provided by other FPGA status registers. Status registers included in the FPGA provide fault isolation information. The test programs, which run on the SHARC consists of a suite of tests each focused on one section of the hardware. The test results are reported back to the PC.
   

   Figure 2-4 FPCTL field or depot testing with PC

4. Built-in-self-test (BIST) software at power-on or directed self-test procedures for the FPCTL/FPCAP in the AN/UYS-2A chassis closely follow the EZ-LAB tests described above. Program codes for the tests are stored in the EPROMs. This code is executed at power-up, or upon command, with the result reported back to the AN/UYS-2A host (CPP).

5. Performance monitoring (PM) software to test hardware while in normal operation running algorithms.