Many of today's data-logging applications need to safely store huge amounts of data. As a review, data logging is where you capture and store data, then access the data at a later date for review and analysis. Examples of different types of data include temperature, dew point, voltage, current, water pressure, shock and acceleration, sound levels, motor speed RPM–the list is extensive.
Dataloggers fall into two categories: stand alone and embedded. Stand-alone dataloggers are typically external boxes that receive data via external sensors, cables, or wireless RF signals. A familiar example are those boxes you see on the side of the road that count cars as they drive over rubber cables that contain pressure sensors. When the car counting project is completed, the external box is taken back to the office and the data is transferred to a computer for analysis.
Other examples of stand-alone dataloggers include wind-velocity meters; strain-gauge measurement for things like highway bridges; multiparameter measurement of temperature, humidity, pressure, and other environmental parameters; and devices that measure temperature just like those antiquated analog strip-chart recorders, except they do so digitally and enable you to see the color strip chart on your PC, as shown in Figure 1 .
Embedded dataloggers, on the other hand, are designed and built into a larger piece of equipment and are a permanent part of that system. These dataloggers typically receive data from wires or cables within the equipment. Examples of embedded dataloggers include remote weather stations, lab equipment like gas chromatographs, motor control, medical equipment like CT scanners (shown in Figure 1b ), and so on.
Some of these applications can still use conventional hard disk drives, but many others now demand a flash memory IC-based 100% solid-state solution because of their data-capture speed, physical size, weight, power requirements, and/or hostile environment specs such as vibration, physical shock, and extreme temperature.
These flash-based nonvolatile subsystems are expected to proliferate as flash densities grow and their price points drop. However, in memory subsystems where flash is the only nonvolatile memory, several shortcomings still need to be resolved. These include:
• The risk of losing valuable data during a sudden and unexpected power failure.
• The inability to support extremely high data rates.
• The risk of unplanned memory cell “wear out” due to excessive write operations to the flash memory cells, a fundamental limitation imposed by its underlying process technology.
These shortcomings can all be corrected by adding a second nonvolatile memory, specifically a nonvolatile static random access memory (nvSRAM), as a “flash page assembly unit” to the memory subsystem. The nvSRAM also brings additional functionality to the system, which can actually increase the effective storage density of the flash memory, allowing a smaller, and therefore lower-cost flash memory device to be used, while also increasing the overall speed of the memory subsystem. This article describes this improved solid-state memory system.
Figure 2a shows a simple block diagram of a flash-based 100% solid-state memory system. Figure 2b shows the same system with the added nvSRAM for flash block assembly. As previously stated, an unexpected power failure can cause important data, currently residing within the system, to be lost in the system shown in Figure 2a . Let's take a look at a NAND flash to see how this happens.
Unlike traditional memory devices where individual bits can be written, read, and erased, NAND flash devices must write data many bits all at once. flash devices are organized in large blocks, called pages, that contain 8,192 bytes of data (Figure 3a ). Each page is divided into 16 sectors, and each sector contains 512 bytes of data (Figure 3b ).
All 512 bytes in a sector must be written at the same time, and this is the only way data can be written to the flash–one sector at a time–no more and no less. On top of that, a sector can only be written if its previous contents have first been erased. This is accomplished by erasing the entire page–that is, you must erase all 16 sectors, within a given page, all at once.
Once the page has been erased, you can write 16 new sectors–again, one sector at a time. However, once all 16 sectors have been written and the page is full, no additional sectors can be written; that is, of course, until you erase the entire page.
The problem with this approach is that you may want to keep, say, 15 of the 16 sectors and only write one new sector. But from what we just learned, you can't selectively erase just one sector–you have to erase all 16. The way around this is to first temporarily copy the contents of the entire page–all 16 sectors–to the microcontroller's internal memory–then erase the page, and then rewrite the 15 sectors you want to keep back to the flash's page, as well as writing the new sector.
Now let's say there's a power failure in the middle of this process. The temporary data that was stored in the microcontroller's internal memory while the flash page is being erased is suddenly lost–forever . Bad news, to say the least.
Now let's add an nvSRAM to the system (Figure 2b ). Instead of storing the temporary page data to the microcontroller's on-chip memory while the flash page is being erased, it's written to the nvSRAM. Once the data's safely stored in the nvSRAM, the flash page can then be erased. After the erase operation's completed, the temporary page data is copied from the nvSRAM back into the flash device. If there's any kind of power failure during this process, the data will always be safely stored in the nvSRAM. The simple addition of the nvSRAM to this system ensures that no data will be lost.
The second advantage of using the nvSRAM is speed. Instead of using the nvSRAM to simply store temporary data, it can be logically placed between the microcontroller and the flash device, and all data streamed into and out of the data-logging system's memory now uses the nvSRAM.
Since nvSRAMs are as fast as 15 ns, we've just made the nvSRAM a high-speed buffer cache, which has magically turned a rather slow flash device into a 15-ns memory. Since many data-logging applications must support incredibly high data rates, having a 15-ns device fits the bill–perfectly.
The third advantage of using the nvSRAM is to keep the flash memory from wearing out its memory cells. To review, the underlying manufacturing-process technology of flash memory limits the number of erase cycles, and after exceeding this limit, the flash memory cells can actually wear out, potentially resulting in corrupted data. Let's see how the nvSRAM fits in.
In many data-logging applications, data is captured and stored to memory, but this data is not always needed on a permanent basis. For example, a datalogger may be constantly monitoring the operation of a piece of equipment in a manufacturing operation. Most of the time, the equipment's operating normally, yet the data still enters the datalogger and is stored into memory.
If the data captured falls within acceptable limits, it's not needed, and can be erased. However, in the event that the machine suddenly begins to operate outside of acceptable limits, then this data becomes very important and therefore needs to be safely stored for future analysis by the factory–and of course, it must not be erased.
If the datalogger does NOT use the nvSRAM, all of the data is written directly to the flash, and this constant churning of data, which includes many erase cycles to purge the unneeded data, wears out the flash's memory cells.
But by adding the nvSRAM, all of that churning of data–which includes erasing unneeded data–can take place in the SRAM portion of the nvSRAM, which supports an infinite number of read-write cycles. This protects the flash from wearing out. And here's another plus: using the nvSRAM supports write times that are 33,000 times faster than flash, and this doesn't include the flash page-erase time.
Now since the nvSRAM is much lower in storage density than the flash–hundreds of times smaller–at some point, the nvSRAM begins to fill up with data. There needs to be a way to continuously manage its contents such that data stored in the nvSRAM is copied to the flash, freeing up more space on the nvSRAM for new data. This is taken care of by the microcontroller, which manages both the temporary storage of the page data during the erase cycles we discussed earlier, as well as writing new data to the flash when its own memory becomes close to filling up.
Alternately, the system designer can make this take place continuously and transparently as an MPU background process or an interrupt routine. Either approach works fine.
And here's yet another benefit the nvSRAM provides. In some data-logging applications, data can be reduced in size using any number of data compression techniques like the least-squares fit algorithm (Figure 4 ). Although data compression requires a lot of churning of data and the use of high-speed memory, the nvSRAM can be used for this function, since it has both the read-write speed and the infinite read-write cycles to support this. The results can be staggering: in some applications, data compression can reduce the data size by a factor of 100 or more, so you can use a flash device that's 100 times smaller, reducing board space and saving money.
In summary, adding the nvSRAM to any high-performance data-logging system that uses flash memory can provide significant improvements, including eliminating the possibility of losing data during power loss, increasing the speed of the system, and keeping the flash memory cells from wearing out. In addition, if data compression can be implemented in the system, the nvSRAM can support that function, while also reducing the size of the flash memory by several orders of magnitude.
Kristian Blomquist is an associate design engineer at Simtek Corp. (now Cypress Semiconductor) and is currently completing his BSEE at the University of Utah, Salt Lake City. He can be reached at firstname.lastname@example.org.