Go beyond the datasheet, Part 2: Understand the considerations

In Part 1 of this two-part series, we talked about how a system designer could take advantage of the conservative nature of the integrated circuit (IC) industry.  Simply put, our devices have much more performance than what is shown in the data sheet. The reason for this being possible has to do with the variability of the process, IC design system design and end use by the ultimate consumer.

What we would like to cover in this paper are some considerations you will need to understand as you attempt to use integrated circuits outside of the data sheet.

Before we continue on with the discussion it needs to be pointed out, as it was in the previous paper, that the warranty is no longer valid once the device is used beyond the data sheet specification.  It is hoped that this paper will give you some amount of comfort as you go beyond the data sheet.

Topics to be covered in the following pages include:

• Clocks speed trends
• Tweaking the performance, power budget
• Performance vs. reliability
• Design considerations
• Assessing the risk... And conclusion

There are three ways to look at using an integrated circuit outside of the data sheet:

1. A specification on a datasheet is violated without consequences
2. A specification is violated and a compromise has to be made on another data sheet specification to compensate for the violation
3. A specification is violated and the part is compromised to the point of failure

This can be visualized as three different multi-dimensional boxes that fit within each other:

• The center most conservative box is the data sheet specification.
• The next outer box contains that space where the specifications may be outside the data sheet specification, but still well within the safe operating area of the device.
• The outer box represents the limits of the device at which, if exceeded, damage to the device will occur or the device destroyed.

An example of the use of this “middle” box is the creation of audio random access memory (ARAM) many years ago. Texas Instruments (TI) was working with a small company (DSPG) at the time trying to introduce the first digital answering machines. One of the expensive parts of the system was the memory for the speech data. At the time, it needed to be in the order of 16 Mbytes to give 30 minutes of storage time (8 Kb/s coders gave two minutes per megabyte of dynamic random access memory (DRAM). What we realized was that the DRAMs didn’t need to be good – we could use defective DRAMs.

At the time TI had a DRAM business unit. When the TI DSP and DSPG teams first visited the DRAM business unit, we were told that it would not be possible for us to use bad DRAMs. As part of our discussion we asked what the specification for the DRAM would need to be to get 100 percent yield. As that concept seemed to be foreign to the DRAM team, we (DSP and DSPG) marked up the DRAM specification to fit our application. For example, we reduced the temperature range from zero ºC to 70 ºC to a more reasonable range of zero ºC to 40 ºC. We also reduced the maximum time for refresh as our system inherently refreshed the memory much faster than most DRAM system designs. We were not given a lot of encouragement, but were told that they would take failures from burn-in and let us play with them. We agreed to that process. After a couple of weeks of waiting we called the DRAM team to ask why we hadn’t gotten any samples. The reply was “when we tested the bad devices against your specification they all passed.” What we had done was to alter the DRAM specification to make the ARAM specification such that the ARAM met the requirements of the system in which it was to be used. The ARAM business became a significant revenue source for TI by selling “bad” DRAMs rather than throwing them away.

This ARAM example demonstrates what we hope to discuss in this paper.  Fundamentally, how can we modify the specification of a device to meet the specific needs of an application without going beyond the device’s capabilities.

Looking closely inside the data sheet
You don’t need to look too far to find performance trends. Table 1 below shows the performance specifications for four variations of a single TI fixed point DSP. In other words, for this particular DSP, a different set of test conditions yield four different product spins at four different performance points.

Let’s take a closer look at the first two rows. Let’s say that you’re trying to maximize battery life in your product and you’re looking at a particular DSP which runs at 1.25 V/500 MHz according to its data sheet specification. However, if you only plan to use your final product indoors, holding the central processing unit (CPU) frequency constant, you can sacrifice the operating case temperature range and operate at a lower voltage, 1.20 V, and hence consume less power.

Now let’s take a closer look at the last two rows. One way of interpreting this information is the following: in order for the 600 MHz/133 MHz -40 to 105ºC device to be able to run at a faster CPU speed, and therefore increase your processing capability, the operating case temperature range is lowered to 0 to 90ºC only. This is a good compromise if you’re not planning to run your final product at subzero temperatures or in extreme ambient temperatures.

Lastly, looking at the first and last row of this table it’s easy to appreciate how increasing the operating core voltage can result in a performance boost.

Table 1: Fixed-point DSP data sheet parameters. These specification trends illustrate how you reach performance goals by looking at the box drawn by your specific system requirements.

Next Page: Clock speed trends