On-chip code storage in SoCs gets another option

Code storage in smaller embedded systems always presents some hard choices. You can put code in cheap, dense, metal-mask ROM on-chip in any modern CMOS process. But then a software bug fix or a new feature risks overflowing whatever patch-ROM provisions you have made and causing a mask spin. You can use on-chip Flash to get density plus reprogrammability, but then you are limited to more expensive and mature process choices, today 90nm and above. Hence often the cheapest solution is simply to put the code in an external serial Flash chip. But that creates board-space, reliability, and security questions. And since execution in place is impossible, you may end up having to enlarge your chip’s SRAM, running up the chip cost again, and incidentally increasing the energy consumption during code execution.

One can imagine another alternative without venturing into the realms of future memory technologies. For example, antifuse one-time-programmable (OTP) memory has been around at high densities for years, used as small configuration-memory blocks in FPGAs. And Kilopass Technology, for one, has for years offered small blocks of OTP antifuse memory in standard CMOS processes for applications such as parameter storage. Putting the two ideas together-dense antifuse OTP and data storage-to create on-chip code store seems like an obvious move. And this is just what Kilopass has done.

But like most obviously good ideas, the surface conceals a lot of hard work. Useful code storage implies by-32 arrays, not individual bits. It demands fast read times so you don’t have to shadow the code store with SRAM. And, since code storage means capacity, and high density demands the smallest possible bit cell, the array needs a redundancy scheme. There should be a patch facility, so that changing a few lines of code doesn’t mean throwing away all the parts you’ve already programmed. And it would be a good idea to conceal the inner workings of the write cycle, such as the write state machine and the charge pumps that create the 6V programming voltage, inside the IP so that the block looks like memory.

All of this Kilopass has done, leading to the announcement of Gusto-the company’s code-storage IP. To give some idea of the work involved, Kilopass vice president of marketing Linh Hong says that the actual bit-cell array represents only about half the area of the IP block. The rest goes into charge pumps, interface and control circuitry.

The IP is available in preconfigured hard blocks of from 512 kbits to 4 Mbits, organized as 32-bit words. Read access time is 20ns. The company claims the memory consumes a tenth the dynamic power (in read mode) and  a fortieth the standby power of conventional memory.

One of the significant advantages, according to Hong, is security. Since the code store is on-chip, there is no code stream exposed as inter-chip traffic. Further, since programming creates only a tiny channel through the antifuse, it is nearly impossible to read the state of the antifuses by examination from outside the chip, unless the designer thoughtfully provides a vulnerable test or debug mode. You would almost have to surgically expose each antifuse element and examine it with a scanning microscope.

Kilopass is offering the Gusto memory IP initially in 40nm TSMC and UMC standard processes, and in IBM’s 45nm SoI. Hong said that Gusto has successfully taped-out in each of these processes, and that more offerings are planned.