Designing a Highly Integrated Controller for Flash Storage Cards

Special design considerations in embedding a processor core Embedding the processor core in the ASIC began in early 1993. SanDisk faced two challenges in completing this process, including testing the processor core with high fault coverage test vectors and providing emulation support for firmware development. Motorola addressed the first challenge by conducting the testing since the CPU core was essentially a black box component. To assist in the testing, SanDisk brought out all the signals of the core cell to the pads. In keeping with the objective, to keep package pin count as low as possible, the SanDisk engineers multiplexed most of the core signals with other
device pins.

Two approaches were considered for emulation support. To emulate, the emulator needed access to the 68000 signals. The first approach was exemplified by the ORION 8800 series emulator. The CPU core was not disabled; the standard 68000 signals were brought out to the pads and the emulator was functioning essentially as a ROM emulator. The second approach was more traditional in method. The CPU core was disabled, and the emulator pod with a 68000 was plugged into the target socket. The end result was support for both modes of emulation with more pin multiplexing.

SanDisk next designed an internal bi-directional bus to interface to the CPU data bus. The original bi-directional structure of the data bus was retained in the core cell, instead of providing separate input and output buses. Motorola provided a special bus-keeper cell to prevent the bus from floating since an internal tristate bus existed. Although the pin multiplexing around the CPU core turned out to be fairly complicated, the rest of the core cell interface proceeded quite rapidly. Figure 1 shows some of the multiplexing control logic for the CPU data bus.

Starting the design process The installation of Motorola's FlexCore design system onto our SPARCStation was a straightforward procedure. The toolkit could be run in a Cadence Framework environment or in a stand-alone, text-based terminal environment. SanDisk chose the terminal environment, allowing access of the tools on PCs through remote Telnet sessions.

The first step in the design process was to synthesize all the Verilog HDL coded blocks. Instead of using the Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys Design Compiler's built-in delay equation for temperature and voltage derating, Motorola provided a set of library files covering a combination of process, voltage, and temperature conditions. SanDisk engineers synthesized the design using the worst-case operating condition library and relied on the 'fix hold' command in Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys to fix hold-time problems that may show up under the best-case operating conditions. This reduced the chances of timing errors since the design was largely synchronous. This method resulted in successful synthesis of all Verilog coded blocks. There were no timing violations under the best-case operating conditions.

Compiling RAM blocks SanDisk needed to generate all the RAM blocks because the Flash Controller contained several RAM blocks that were not standard configurations. Motorola's FlexCore design toolkit included a utility which could compile single-port or dual-port RAMs, ROMs, PLAs, and special buffers. The RAM compiler included a multiplexing factor to determine the aspect ratio of the block. The aspect ratio determines the size, speed and power consumption of the RAM. The toolkit provided a guideline for the multiplexing factor needed to obtain a square RAM block which was the most efficient. However, because the layout efficiency of a rectangular block was more critical than power consumption or speed, the suggested multiplexing factor was overridden.

With the above information, the compiler then proceeded to generate a Verilog model file and a set of Verilog technology timing files. These technology files had a one-to-one correspondence to the Synopsys .com/isdweb/&lf=isd-sendtolog"> Synopsys library files used later in the delay-calculation process. The compiler did not generate BIST structures for the compiled RAMs; therefore, it was necessary to add in special test modes that allowed the RAMs to be tested using ATPG tools on the target tester. The compiler automatically generated a name for each compiled RAM block. This presented minor inconvenience because it did not convey information about the size of the RAM. The name was a randomly generated serial number containing creation data information. However, the naming convention did help to ensure that the proper versions of the RAMs were used.

Figure 1. The bi-directional data bus structure increases
demultiplexing complexity while reducing the number of signal lines.

---

Silicon and software systems SanDisk had to run a delay calculation for the appropriate operating conditions before the simulation could run. With this calculation complete, a problem became apparent. The CPU was not initialized in the simulation. It turned out that there was a specific initialization sequence for the core which is required only for simulation purposes but was not documented. Motorola assisted in resolving the problem. Once the CPU model was running smoothly, the verification process proceeded without a hitch. To verify that the CPU mux test logic was done correctly, Motorola provided a Verilog stimulus file that they use for fault testing
the CPU.

Most of the vectors for the CPU passed. However, there was a problem that was traced to the RESET and HALT pins on the CPU. In the standard 68000, these pins are bi-directional, but in the EC000 core, they are separated into input and output pins. When appropriate changes in the stimulus file were made to account for this discrepancy, the vectors passed. With the functional and timing verification completed, the task of generating test vectors began.

Generating the test vectors by hand was time consuming because the design was not scan-based. The test vectors were very similar to the functional vectors, except for some timing restrictions (which are fairly common for ASIC testers). The first restriction was that all input signals had to be synchronized to the tester clock. The second restriction was that timing on bi-directional pins needed to be relaxed due to the tester turnaround time required for changing from input state to output state and vice versa. Since the 68000 bus cycle can be dynamically adjusted using the /DTACK signal, long delays under the worst-case condition could cause bus cycles to stretch but would not cause functional failures. On the tester, however, all signals must maintain the same timing from best case to worst case. This made it difficult to pick a sampling point that performed across operating conditions. As a result, engineering had to slow down the tester clock frequency. A revised version of the test kit fixed this problem by analyzing the vector set and suggesting a sampling window.

To test the embedded RAM blocks, SanDisk generated a set of preamble vectors that placed the device into RAM test mode. Once in that mode, Motorola supplied their own RAM test pattern, generated using their ATPG tool for RAMs. To use this ATPG tool, SanDisk engineers followed certain rules in assigning the row and column decode addresses to the tester channels (which required some minor changes to the logic). The ATPG test method saved time and effort by eliminating the need for generating test vectors for the RAMs.

Lastly, SanDisk checked the fault coverage of the test vectors. Since the design was not scan-based, engineering did not expect a high fault coverage. Using Cadence Design Systems' Verifault executables and models, the first-pass fault simulation yielded a fault coverage of approximately 85 percent. To bring the fault coverage to a higher, more desirable range, SanDisk added a vector set targeted to the uncovered faults.

To estimate the worst-case power dissipation, SanDisk used a power estimation tool that is part of the Motorola toolkit. This tool calculated power consumption by the library cells based on capacitive loading. Therefore, SanDisk added to the number calculated by the toolkit, the power numbers for the RAMs and the CPU, and an additional 10 percent to account for surge current in the I/O buffers. This provided a check on the power dissipation. The resulting value was well within the design limit.

As a result of integrating SanDisk proprietary logic on-chip with the Motorola core processor, SanDisk was able to reduce its flash disk controller chip count to two and significantly reduce component costs. SanDisk is currently working on further integration of the controller solution by pulling the external ROM chip onto the ASIC, resulting in a single-chip controller. The design re-use methodology employed now enables SanDisk to leverage much of the functional blocks and firmware from the existing controller into the next-generation controller design.

Joseph Chang is a project manager in the Systems Engineering Department at SanDisk Corporation. He has been involved in the design of San Disk's embedded controllers for the past six years. Prior to joining SanDisk, Mr. Chang spent six and a half years with MMI/AMD doing a variety of full-custom and cell-based logic products.

Sue Cozart is a technical marketing manager for Motorola's High Performance Embedded Systems Division. She has been responsible for marketing the FlexCore program throughout its development.

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

integrated system design  January 1996