System Design

Top-Down Design Strategy Includes DFT

How one company used topdown design and DFT to produce a new system switching device.

By Ilan Carmi, John Thomson, and Carol Bagdis

When we at Chipcom Corp. (Southborough, Mass.) began readying our next-generation intelligent switching system, we faced rigorous design, cost, and scheduling pressures: the new system needed twice the functionality of its predecessor, had to cost less, and had to adhere to the same delivery schedule as the first-generation product. With a board design already in progress, the best way to meet the first two goals was to convert the system's existing FPGAs to ASICs on a one-for-one basis, then add more ASICs as necessary.

Meeting such an aggressive schedule also required changing our design and test methodologies, however. While the company produced only four or five ASICs in its history, the new switching system required more than 20. We needed an approach that cut design time, while allowing us to insert the testability necessary to prevent high rates of manufacturing defects.

Figure1. The ONcore Switching System simultaneously supports users of various networks.

To meet design, cost, and delivery goals, we adopted a top-down design methodology using VHDL, an exhaustive design-for-test (DFT) strategy, and a new suite of EDA tools that supported these approaches.

Top-down design sped chip development and helped finalize device specifications: we created high-level device descriptions in VHDL, simulated them at the board level, modified them, verified the new specifications, and repeated this process as necessary. Compared to traditional schematic-capture methods in which ASIC circuitry emerges piecemeal, this approach let us design, verify, and modify an entire device quickly.

In the area of test, a top-down approach organized and streamlined our design flow, giving our engineers more time for adding the testability necessary for high fault coverage. Additionally, our EDA tools automated test synthesis. Having the time to tailor test strategies and automatic test insertion eliminated any scheduling bottlenecks during ASIC testing.

Using a top-down, DFT strategy, Chipcom cut its ASIC development cycle in half, achieved more than 95 percent fault coverage, and delivered a next-generation product without lengthening its development cycle.

Design process overview The ONcore Switching System is a high-speed, fault-tolerant, enterprise-wide, intelligent switching hub that links users of disparate networks, including Ethernet, Token Ring, FDDI, ATM, and LAN packet-switching configurations. (Figure 1.) The product's first generation used FPGAs with densities approaching 10,000 gates. These devices were expensive; in production quantities they cost approximately $160 each. By contrast, ASICs in the same quantities (due to the one-for-one conversions) were only $10 each. Even at the prototyping stage, with an NRE of roughly $20,000, we could reach parity in just under 150 units. These cost savings played a primary role in driving our redesign effort.

Figure 2. Chipcom's 24-Port 10BASE-T Ethernet Module.

The new ONcore system required retargeting 12 FPGAs to ASICs, and creating another 10 gate arrays from scratch. Because our development process was already underway, we adopted the top-down methodologies to meet these goals over the course of a year.

The first two stages of our top-down design process took place in parallel. We created four new ASICs using traditional schematic capture and simulation with no test insertion or automatic test pattern generation (ATPG). At the same time, we used schematic capture for critical-concept FPGAs, verified them in a lab using real network data, then employed top-down tools for automated synthesis and test-insertion.

The FPGA retargeting effort laid the foundation for our full, top-down ASIC design process. Having relied so heavily on FPGAs before the development of the ONcore system, retargeting helped clarify the design issues we would face when working with denser, faster gate arrays. For example, denser ASIC speeds can drastically affect the timing and jeopardize the functionality of the retargeted design.

FPGA-to-ASIC conversion also raises new testing issues. For instance, our previous design methods included logic-level tools such as ABEL from Data I/O (Redmond, Wash.). After retargeting the software's low-level descriptions to ASICs on a one-for-one basis, their initial fault coverage was only 70 percent, far below the generally accepted industry standard of 95 percent.

Over the course of 12 months, we moved from a schematic-capture process that used little or no test insertion to a top-down one that flowed entirely from VHDL (Figure 3), and used a suite of top-down design and DFT tools from Mentor Graphics .

Within this top-down, VHDL-based design process, engineers continued to verify critical concepts in the lab. When finished, they inserted test circuitry and used ATPG to obtain high fault coverage. For new ASICs they synthesized them into gate arrays directly, using simulation to verify the gate-level implementations.

Deploying the design team Product specifications drive the makeup of design teams in our company. For example, if a system or a module calls for a gate array, we assign an ASIC designer to the project. We deployed most of the project's 30 engineers in this manner, assigning them to autonomous teams on an as-needed basis, then reassigning them to other company projects when they finished their work.

Figure 3. Beginning with behavioral-level VHDL capture, a design proceeds through synthesis, simulation, scan insertion, ATPG, layout, and finally, pattern transfer.

However, Chipcom did not want to simply create a market-leading product; we wanted to develop and promote consistent design and test methodologies across the entire development effort. By themselves, autonomous hardware teams did not support this goal, so to foster communication among the various hardware groups, we created a top-down ASIC design center and staffed it with four ASIC engineers. The design center worked closely with and exported methodologies to the various hardware-development groups. We then invested heavily in training, spending approximately $4,000-$6,000 per team member, to create a well-trained core of people that understood top-down methodologies thoroughly and could spread them throughout the company.

For hardware engineers, training included a one-week "boot camp," with 12-hours-per-day instruction in VHDL design and synthesis. As part of their course work, these engineers designed and synthesized an ASIC using their new tools. Previously, the four ASIC design center engineers had attended three intense one-week courses covering VHDL design, synthesis, and ATPG.

Top-down design required a new way of thinking about creating and producing systems. Nowhere was this demand more apparent than in the changes it forced upon the hardware engineers. As a rule, this group worries about functionality, but a top-down approach can raise significant manufacturing issues early in the design process. Using fault coverage statistics, for example, we can calculate the manufacturing defects in a production run of ASICs (Figure 4). To minimize returns--and preserve market share and profitability--fault coverage must be high. One of our top-down design process successes is that hardware engineers have a much better understanding of the downstream impact on manufacturing.

For all our accomplishments, however, it is important to acknowledge the trial-and-error nature of our work. We simultaneously developed methodologies, team configurations, and product designs. Scheduling drove everything. While we tried to pick good test cases for our approaches, not every one worked. For example, some early design strategies violated the DFT rules we eventually adopted. As a result, we had to isolate these violations and make minor circuit changes by hand so our test tools could insert scan circuitry and perform ATPG.

Today, while our design and DFT methodologies are more concrete, the roles and responsibilities of our design center and hardware-development groups are still evolving. Eventually, both will become part of a top-down, VHDL design process encompassing all system hardware and software.

From VHDL to ASICs As mentioned earlier, our top-down strategy evolved to the point where we created and synthesized designs directly from VHDL descriptions. We developed FPGAs to test critical concepts when necessary, then once satisfied with the performance in a system, synthesized them to gate arrays.

Regardless of the device, after synthesis we verified all basic functions. We evaluated the topology of its clock structure and inserted scan chains, targeting most of its flip-flops. When working with multiple clocks, we partitioned the scan chains; our design tools segregated the chains automatically. We then ran another quick functionality check using simulation tools and waveform comparison.

As for a DFT strategy, we built ours around test synthesis and ATPG. Our goal was as much as possible to make a design testable without rearranging its circuitry. In the retargeted FPGAs, for example, almost 80 percent of the registers ran off the master clock, making it easy to link them with a scan chain. For the remaining circuitry, which included asynchronous microprocessor interfaces and gated clocks, we ran fault simulation using functional vectors, then used combinatorial and sequential ATPG tools to target the remaining faults. Using this approach, we improved overall fault coverage from 70 percent to 95 percent in a day's time. Both partial- and full-scan approaches were used.

We learned several important lessons during our top-down, DFT process. For example, it is important to consider the design tradeoffs when retargeting FPGAs to ASICs. Retargeting a fully functional FPGA to a gate array can cause timing problems. A long hold time, for example, may never appear because of the new silicon's speed. Yet designing a critical-path FPGA with only an ASIC in mind can create a device whose circuitry exceeds its physical boundaries. In fact, several of our critical-concept designs outgrew their original FPGAs. To test them, we used representative functionality. For instance, a design that handled multiple data channels in the field might need only one channel for lab testing. Once we verified the single channel's functionality, we were able to synthesize the entire multi-channel description directly to an ASIC.

With automatic test insertion, we were concerned about affecting the function and performance of the original design. To ensure that test-insertion did not alter the functionality of a retargeted design, we used test-vector comparison techniques to check simulation results at each design step.

Fault grading slows process With design and test-insertion complete, we moved on to what would be the most problematic phase in our system effort: fault grading.

Whether it was retargeting FPGAs or designing an ASIC from scratch, fault grading took more effort than we anticipated. We used a statistical fault grader to determine coverage, but its results conflicted with those of our ASIC vendor's simulator. For instance, a design with 85 percent coverage using the fault grader attained over 90 percent coverage on the sign-off simulator.

We had discovered a basic weakness in the fault grader: its accuracy depended on expected high fault coverage. Because our task was to raise coverage, we abandoned the fault grader for the Mentor Graphics deterministic simulator we had been using. While more accurate, the simulator lengthened the coverage verification process from a few minutes per pass to about an hour.

We began our new fault-grading process by running the fault simulator using functional vectors. We then saved the simulator's list of undetected faults and fed them into our ATPG tools as the target faults. We found this approach reduced both run time and test-pattern length.

At this design stage, however, two additional conflicts slowed our work. First was the differences among EDA tool and ASIC vendor fault dictionaries. For instance, while one dictionary used only "detected" and "undetected," categories, another added "untestable," "tied high," and "tied low." The additional classifications required that we adjust the fault coverage to suit the new categories and mask out miscomparisons between the fault dictionaries. The EDA industry would do well to create a fault dictionary standard and alleviate this conflict.

Figure 4. Increasing fault coverage during the design process raises manufacturing yields and lowers defect rates. A generally accepted industry standard for fault coverage is 95 percent.

For one design, however, we encountered a serious conflict between our design and sign-off simulators. Lacking an easy way to hand off ATPG vectors to our simulator, and faced with schedule pressures, we ran only half of the vectors before proceeding to sign-off simulation. The hope was that any significant problems would reveal themselves during this testing. Finding none, we went on to test the ASIC design on the vendor's simulator.

Unfortunately, the output of the sign-off simulator did not agree with that of the design simulator. It is not clear if this is a modeling or a design issue. We worked around the mismatch by inserting more functional vectors. Since then, Mentor Graphics has developed an automated link between our scan-insertion and ATPG tools and our design simulator, and we run all ATPG vectors through the simulator before sign-off simulation. We continue, however, to investigate the source of the mismatch.

Pattern transfer raises new cost issues After the design and test cycles we endured, and the delays due to fault grading, we looked forward to the seamless transfer of design patterns to our ASIC vendor. Unfortunately, we faced two unanticipated challenges. Both illustrate the danger of assuming that methodologies extend beyond your own EDA domain.

First we discovered our test-vector format was incompatible with the vendor's. To resolve this incompatibility, we partnered with our EDA tool supplier and ASIC vendor to develop an output-formatting tool that generated TDL-format vectors directly from our ATPG software.

Second, we assumed that the vendor's tester would support the parallel loading of our full-scan vectors. In fact, the tester required that we break up these vectors and insert portions serially. Each serial load consumed a clock cycle. Worse still, the vendor based its charges on the number of clock cycles we used, so while ATPG tools made our designs testable--one device alone used 500,000 vectors--tester limitations and the vendor's revenue model rendered this level of test too expensive.

To reduce the number of test vectors and tester cycles, we inserted multiple scan chains into our designs, using as many as six at a time. Such insertions require more pins, expand the design area. As a rule, we added pins when adding scan chains. When we lacked such pins, we pursued alternative strategies such as sharing I/O among existing data pins or multiplexing outputs.

In any event, our assumptions cost us precious schedule time. Breaking up scan chains required repeating the scan-insertion step of our synthesis process. Fortunately, in the case of the device requiring 500,000 vectors, we had the pins to support the chains, and we reduced our test vectors by an order of magnitude. Without these pins, however, we would have had to eliminate scan vectors, lower our fault coverage, and risk a higher level of manufacturing defects.

Strategy yields significant results When adopting any new EDA methodology outright, there are always bumps in the road. In our situation--importing a brand-new EDA toolset and design and test methodologies with a design cycle already underway--the results could have been disastrous.

We believe our choice of methodologies, however, was the correct one. Instituting a DFT strategy within a top-down design paradigm paid significant dividends, the most important being the on-time delivery of our new switching system. Our new methodologies also doubled ASIC functionality, while cutting design time in half. For instance, instead of eight months to create a 20,000-gate device, it now takes four: one to two months for the architectural phase, an additional week or two for design synthesis, another week for scan-chain insertion, and one more week for ATPG. Generating and testing a critical-concept FPGA, if necessary, takes two to four weeks. In two years, Chipcom has produced 22 new ASICs using this strategy. All achieved better than 95 percent fault coverage.

Part of the credit for the on-time delivery of our system lies in the strong partnerships we enjoyed with Mentor Graphics and our ASIC vendors. For example, Mentor Graphics performed six FPGA-to-ASIC conversions at its local ASIC design center, dedicating two full-time engineers to the task for more than a month. These engineers served as a sounding board as we developed synthesis and test methodologies for converted designs. Most important, by using the same design, simulation, and test tools as our designers, the vendor's engineers had an intimate understanding of the challenges we faced, and could quickly suggest ways to surmount them.

Today, with a successful product launch behind us, and well-established design practices in place, we are applying our top-down, DFT tools to more complex products. These systems include 150,000-gate ASICs requiring far more simulation and verification than our earlier designs, yet we are confident that our methodologies will continue to evolve to fully embrace the challenges posed by these and other future designs. *

Ilan Carmi is VP of Engineering, John Thomson is the EDA/ASIC manager, and Carol Bagdis is a Senior ASIC engineer in the top-down design center at Chipcom Corporation.

To voice an opinion on this or any Integrated System Design article, please e-mail your message to: michael@asic.com.

integrated system design  February 1995