OTP with a ROM Conversion Option Provides Flexibility and Cost Savings for On-Chip Microcode Storage

Update: Synopsys Expands DesignWare IP Portfolio with Acquisition of Kilopass Technology (Jan. 10, 2018)

By Bernd Stamme, Kilopass Technology

Abstract:

Programming time and cost for larger one-time programmable (OTP) non-volatile (NVM) on-chip memories can be significant. Depending on the process technology and the OTP memory size it can take several seconds to program the OTP with automated test equipment (ATE) in manufacturing.

OTP provides invaluable flexibility and time-to-market advantages over mask read only memory (ROM) during early product phases. High volume products that have reached a maturity level that no longer require microcode updates are increasingly under price pressure and a prime target for reducing manufacturing cost. Conversion of the on-chip OTP to mask ROM is an option to improve product margins by eliminating the programming time and cost for the OTP.

This article covers the flexibility that an OTP with ROM option provides with regard to the product life cycle of high volume products. You will learn how to estimate OTP programming cost and make trade-off analysis to help you decide whether or not a mask ROM conversion makes economical sense.

Introduction:

Historically mask (VIA or diffusion) ROM has been used as on-chip non-volatile memory to store micro code. ROM is, and will continue to be, the least expensive non-volatile on-chip memory technology. However, ROM content is fixed during manufacturing, and the cost for ROM revisions is becoming more expensive due to higher mask costs for advanced process nodes. Aside from the increasing mask tooling costs, it usually takes several weeks from releasing a ROM mask change to receiving the revised silicon. That delay often impedes product integration and validation progress resulting in much higher overall development cost, missing critical product introduction dates, and losing end-product revenue.

Most development of hardware and software (firmware, microcode) is done concurrently. Microcode stability is very difficult to achieve, and subsequent changes are necessary due to the following reasons:

1. Bugs in the design due to insufficient testing at the time of chip tape out
2. Incompatibility at the system-level with non-compliant legacy components
3. Support new features in new revisions of evolving standards (e.g., Bluetooth, USB).

Flexibility of OTP with ROM Conversion Option

Product qualification represents a significant time and resource effort, especially for SOCs (system on chip) that have to comply with communication standards (e.g., Bluetooth, 802.11, USB etc.). Extensive interoperability testing is required to ensure full functionality, interoperability with other components, and standard compliance of the entire system. It usually includes certification testing by the respective standards organization or by one of their accredited test houses.

Major changes in the SOC architecture often require re-qualification based on the end-customer’s in-house quality standards, or as defined by the standard itself. Major changes can be categorized as:

1. Changing from multi-chip module implementation (MCM) to a single-die CMOS SOC: The initial product uses a CMOS die for the SOC’s digital and analog circuits together with a separate Flash memory die to store the microcode in one chip package. This version is later replaced with a more cost-effective single CMOS die production version that stores the microcode in ROM.

2. Repartitioning of the SOC from SRAM to ROM for microcode storage: The initial product uses an on-chip SRAM to store the microcode which is being downloaded from non-volatile system memory (Flash memory, hard disk etc.) during boot time. This version is later replaced with a more cost-effective ROM-version SOC, to reduce die area and lower power consumption.

3. Changing from off-chip to on-chip microcode storage: The initial product uses external storage (EEPROM, Flash memory) in combination with on-chip SRAM depending on the read access timing requirements. This version is later replaced with a more cost-effective ROM-version SOC, eliminating the external EEPROM/Flash component and reducing on-chip SRAM size and power.

The advantage of having an OTP with a ROM conversion option is that the underlying SOC design implementation and die size does not change between the initial version and the later ROM-converted production version. Time consuming re-qualification is not required as long as the microcode revision is the same between the OTP and ROM version.

Cost Considerations

Most of the time embedded OTP memory is programmed on the manufacturing test floor during wafer sort or packaged part testing using automated test equipment (ATE). ATE programming and test costs for OTP depend on 3 parameters:

1. OTP size: larger memory arrays will take more time to test and to program
2. ATE tester: a high-end SOC tester with RF or analog/mixed signal capabilities will have a higher cost than a low frequency tester
3. Technology node: OTP scales with process technology; the programming time decreases with advanced technologies for antifuse technologies

Likely candidates for OTP to ROM conversion are large density memories due to the high programming test cost. In Figure 1 below, the program test cost for OTP is determined for different ATE testers and OTP densities. This programming test cost can be eliminated with an OTP to ROM conversion when the product goes into high volume mass production. The cost savings analysis for two cases, 1Mb and 2Mb are described in Table 1 and 2, respectively.



Figure 1. ATE Programming cost for advanced process node for single part programming

Conversion Cost Trade-off Analysis:

Table 1: Example A - SOC design with 1Mb OTP, 10 million units per year production

OTP programming cost on mid-range SOC ATE (single site)	$0.13
Manufacturing cost component for programming per year 10MU*$0.13	$1.3M
VIA Mask cost for conversion: $65k*, Conversion NRE: $20k, Total ROM conversion cost	$85k
Cost savings over I year of production	$1.2M

Table 2: Example B - SOC design with 2Mb OTP, 5 million units per year production

OTP programming cost on high-end SOC ATE (single site)	$0.45
Manufacturing cost component for programming per year 5MU*$0.45	$2.3M
VIA Mask cost for conversion: $65k*, Conversion NRE: $20k, Total ROM conversion cost	$85k
Cost savings over I year of production	$2.2M

*cost for VIA Mask range from $40k to $90k for advanced process nodes (90nm and below)

ROM Conversion Flow

Kilopass offers ROM-it! to eliminate high programming test cost associated with high density OTP. When microcode is mature during mass production, customers can quickly convert OTP to ROM to reduce overall test cost. The ROM conversion flow offered by Kilopass is seamless.

Figure 2 below shows the conversion and verification steps. Yellow fields denote user deliverables or user activities. Blue fields denote vendor deliverable or activities:



Figure 2. ROM-ification conversion and verification steps

In addition to the ROM content file, the user provides the known-good OTP programming sequence using, for example, the associated VCD (value change dump) file. As an additional cross check, the VCD can then be compared with the ROM content file to catch any logical address/data discrepancies between VCD and ROM content file that are caused by formatting or manual errors.

The next step is the physical mapping of the ROM content file with the original blank OTP layout database. In the case of a metal mask (VIA) ROM, the layout locations for the programming VIA are determined and VIAs are being inserted into the layout for all programmed (logic 1) bit locations. A new layout is being created. The new ROM layout only differs from the original blank OTP layout in the VIA metal mask which is being confirmed by exclusive OR (XOR) comparison of all mask layers.

The standard design rule checks (DRC) are being performed on the new ROM layout database. A netlist is extracted and used for layout v. schematic (LVS) check and functional verification against the ROM content file. The new ROM layout database is then shipped to the user for merge with the existing full chip SOC layout database. After merge and chip level DRC and verification a new VIA mask is generated and exchanged with the previous VIA mask from manufacturing of the ROM version SOC.

Conclusion

Converting OTP to ROM provides a valuable option to reduce manufacturing cost for mature high-volume products. After a ROM conversion the user still has the option to revert back to OTP in case subsequent changes are needed. The user can keep an inventory of OTP SOCs or exchange the VIA mask in manufacturing for additional OTP SOC production. Since OTP is field-programmable, the user can verify subsequent changes quickly without delay for ROM mask-making and fab time.
An OTP with ROM conversion option provides both, a high degree of flexibility as well as low manufacturing cost.

Author Bio:

Bernd Stamme is a Director for Marketing and Applications at Kilopass Technology. He has more than 15 years of experience in the IP and semiconductor industry. Prior to Kilopass, he was the Director of IP Technology at SiRF Technology managing the licensing and successful integration of 3rd party IP into SiRF’s GPS chip sets. Before SiRF, he held management positions in LSI Logic’s CoreWare organization and worked on high speed SerDes IP, communication interfaces and processor cores. Bernd holds a Dipl.-Ing. degree in Electrical Engineering from FH Bielefeld in Germany.