|
|||||||||||||||||||
|
advertisement |
|
|
Interfacing E and E2 PROM memory with digital signal processors Apr 1, 2001 12:00 PM By Iantha Scheiwe and Felicia Benavidez
[For a copy of this article in PDF format, which displays figures and equations, click here. Requires Adobe Acrobat Reader, free download.] Today's 2 and 2.5G wireless devices offer a relatively full plate of features and functions. Tomorrow's 3G will extract an even higher price in terms of digital technology and storage memory for their pervasive feature set. To support this feature-hungry environment, digital signal processors and their support memory are becoming mainstream. Erasable programmable read-only memory (EPROM) and electrically erasable programmable read-only memory (EEPROM), along with latest generation DSPs, promise to field the ball. The fundamentals
An EPROM is a read-only memory chip that can be reprogrammed using a special ultraviolet device. The chips are packaged with a clear plastic cover so that the chip can be exposed to the light and be erased for reprogramming. An EEPROM, or E Digital signal processor (DSP) hardware engineers can fully utilize a processor's resources and generate an optimized memory design by interfacing their DSPs to one or more of these devices in their designs. EPROM and EEPROM memories are not fast access devices, especially in the realm of DSP applications. Even the fastest EPROM or EEPROM memories require that a DSP core running at 100 MHz generate wait states. Both types of memory devices have address stability requirements, and any interface with a DSP will require multiple wait states. This article will explain EPROM and EEPROM memory capabilities and typical applications (some will be manufacturer and device specific). Although some of the technical terms may vary from one DSP vendor to another, the same EPROM interface methods will apply regardless of vendor. EPROM and EEPROM memories
The only distinction between the two types of memories is the means by which a user or a vendor in an application erases the memory prior to reprogramming. Designers interface both devices identically in DSP applications and the two devices, if otherwise identical, are interchangeable. The terms EPROM and EEPROM are interchangeable in theory and for the discussions herein. Either memory device is available in an assortment of packaging and capacity ranges. The most widely available memory is 8-bit, but 16-bit and 32-bit memories are also available. Designers can also multiply bit rates by using multiple devices in parallel, e.g., three 8-bit devices to achieve 24-bit performance. Commercially available device memory capacities also vary widely, from 2 kB to 4 MB or more to fit nearly every design need. The primary purpose of EPROM memory is to provide non-volatile storage for critical startup programs and data. Although their access speed has increased in recent years, the current highest-speed EPROM memories can be accessed at 70 MHz. Most are considerably slower. Interface issue
With a DSP core running at 100 MHz, one wait state equals 10 ns (time is the inverse of speed). The interface between the two devices must fit the system timing requirements so both devices are compatible. The designer will have to program wait states into the DSP because EPROMs cannot drive the data bus in one clock cycle. For even the fastest EPROMs, the DSP will incur a wait state penalty that can vary anywhere from 1 to 20, or more wait states. Because the EPROM is a slower device in most design applications, the designer seeks to minimize the content of the EPROM. By downloading modestly sized programs or data stored in the EPROM to the DSP's internal random access memory (RAM), the application will achieve optimum performance much more quickly (since the data in the DSP's internal RAM runs at the same speed as the DSP). Thus, in most design interfaces with DSPs, designers will try to avoid large memory EPROM devices. In DSP applications, EPROMs are most frequently used when the system has to boot after a reset. Routine maintenance, program upgrades, or power failure can also cause a reset to occur. In terms of the operation of the DSP, the EPROM only functions to boot the DSP. When the DSP boots after reset, it needs to know what to do. A common way of telling it what to do is with an external EPROM. The DSP accesses the non-volatile EPROM at boot since the DSP's static RAM (SRAM) is volatile and cannot retain its contents if power is lost. As a result of any reset and boot, the DSP's RAM program control will be lost. Although using external EPROM to boot the DSP is common, the designer can select other approaches such as flash memory or booting from a host. In some applications, the system may also require permanent data or tables, a second use of EPROMs with a DSP. Remember, while the DSP is a high-speed device, the EPROM is not. For this reason, EPROM usage is limited in DSP applications to functions that are not time-critical, such as boot sequences. The DSP can access the required data or tables at boot time without incurring a performance penalty, as would be the case if the EPROM had to be accessed as a routine processing step. EPROMs are used because they are non-volatile, cheap and have small footprints (depending on capacity). These are the attributes that make them a good choice for boot applications. Slow speed relative to the DSP is the reason why the EPROM performs no active functions during regular DSP system operation. In some systems, a hardware device other than the DSP may require and/or cause a reset. This action will also cause the DSP to reset, which in turn triggers access to the EPROM. The particular trigger depends on the reset mode in the design. The reset mode lines in the design define whether the system triggers access to the EPROM to reset. Once the access to the EPROM is triggered, the following signal lines define the interface between the EPROM and the DSP. These signals are common to DSP interfaces with EPROMs:
Programs stored in the EPROM's non-volatile memory storage can be read and run indirectly as 8-bit data. Either a program or direct memory access (DMA) can access the EPROM and pack and store the data into the DSP's program memory. After every three accesses, the DSP packs the three 8-bit transmissions into 24-bit words for storage into program RAM. An alternative to packing three transmissions from one 8-bit device is to arrange three 8-bit EPROMs as a 24-bit bank and get 24-bit data in each transmission. This method takes the most advantage of a particular manufacturer's 24-bit word architecture, but requires additional board space and system cost. After the data loading is complete, the DSP turns program control over to the newly loaded program. This program, called the overlay loader, can then load additional data (under dynamic memory access (DMA) or program control) from the EPROM(s) into program, X data, or Y data spaces for later execution or use) An application
One application of this method can load a small program that sets a phase lock loop (PLL) at a higher frequency. The PLL initially runs at the input clock speed of the system's on-board oscillator. This speed is usually slower than the full capability of the DSP. A high-speed oscillator is not used here because it can cause signal interference on the board. By using a slower clock, the designer can use the PLL to multiply the slower oscillator to meet the maximum clock speeds of the DSP. To speed up the boot process, it is advantageous to start the PLL with a small program so that the remainder of the boot program can utilize the DSP's maximum clock speed. This is especially useful if there are many boot instructions because most applications have to boot within a limited amount of time. It's all about the boot
Boot times are defined by the individual end-use requirements of each application. In cell phones, for instance, the design can tolerate a boot time of only a few seconds. Most cell phone users are too impatient to wait longer. In another instance, when a base station boots, there's normally a large amount of data and many channels of voice that also require a large amount of data. A base station may receive a reset command during a power failure, when another component fails, or as a result of human error. Similarly, a reset command may be generated when the base station requires servicing or an upgrade. Finally, the system will have to be reset after the installation of new hardware or other new devices. The boot time requirements will vary standard-by-standard and application-by-application. The memory capacity of each EPROM depends on the non-volatile memory requirements for the particular system to reset and boot. The reset table (Table 1) is for a typical DSP from a major manufacturer. Any DSP will have a reset table proprietary to its vendor. In this particular device series, there is a reset mode that sends the DSP to fetch instructions from 8-byte wide devices. This mode, Mode 9, is the one that is used for EPROM boot. A DSP typically has many other reset modes, so the designer must look to find an appropriate mode to use. Some types of EPROMs can be upgraded or reprogrammed remotely while the DSP is still running because the EPROM is only used at start-up. During development this feature is particularly convenient because it allows for fast test-program-retest development cycles. Interfacing the DSP and EPROM
The designer sets the core speed of the DSP from one of several possible sources. All memory interface timings are derived from the period of the DSP core clock. For example, if the DSP core clock frequency is 100 MHz, then the memory interface timing is based on a 10 ns clock cycle time. In most applications, the designer wants the PLL to run as quickly as possible for optimum program execution. The designer sets the clock and PLL speeds in the PLL control register. This optimized speed will vary with the designer's choice of DSP. Note that these timing requirements are affected by various factors, including the use of a PLL and the PLL's external frequency source. These factors can cause the clock cycle to vary from 10 ns. Unlike synchronous devices, asynchronous EPROMs don't use an external clock as reference for any action. However, it's always important to perform a timing analysis for the interface to assure compatibility between the memory and the DSP. Figure 2 visually shows the flow of signals interacting between the DSP and the memory device for the READ timing. The write timing chart is identical except that the valid data on read is not driven by EPROM, but by the DSP for write.
DSP PLL and clock generation
The designer configures the DSP PLL and clock generation in the PLL control (PCTL) register to set the core speed of the DSP for optimum processor and memory performance. The PCTL register performs three sub-functions:
The designer can use combinations of these sub-functions to divide and multiply frequencies for optimum DSP performance. The operating frequency of the DSP is set in the PCTL register as follows: where: FCORE is the DSP core frequency. The remaining key factors in designing the interface between the EPROM and the DSP are the bus control register and the address attribute control registers. The bus control register defines how many wait states are necessary for the DSP to interface with the EPROM. The address attribute register determines the behavior of the address attributes (AAs). In some devices, the AA signals can act as either chip selects or additional address signals. Every designer using a DSP, regardless of vendor, will have to program the wait states and how the chip select will operate. One last factor in the interface is that the memory device and the DSP may have different voltages. In this example, an EEPROM is connected as diagrammed in the memory map layout in Figure 2. In this example, the program in the EEPROM can be loaded into the DSP at boot time and run. The running program on the DSP can then save an updated version of the program back into the EEPROM for later use. Used with this particular device, the 5.0 V EEPROM does not match the 3.3 V DSP and requires the use of a level converter. Using a level converter allows the designer to match the voltage levels as shown below in Figure 3. This situation is fairly common in many DSP designs and can be solved in similar fashion. Summary
If a designer requires a non-volatile memory for the boot program in a DSP application, an EPROM is a common selection. EPROM devices come in a wide range of sizes and memory capacities. The DSP typically runs at a much higher frequency than the memory device. Therefore, the designer will have to program wait states into the DSP because the EPROM cannot drive the data bus in one clock cycle. The program(s) stored in the EPROM can be read and run indirectly as 8-bit data, then packed and stored into DSP program memory. After every three accesses, the DSP packs the three 8-bit transmissions into 24-bit words for storage into program RAM. A common alternative is for three memory devices to send 8-bits each per access, meeting the DSP's need for 24-bit words. Although not commonly used, the overlay loader can access the same EPROM(s) after the DSP has booted and download additional data or tables at a higher clock speed. One implementation of this method is to load a small program at boot that sets the PLL at a higher frequency. 1. This pertains to this manufacturers particular device. Other devices may organize their memory differently. Implementation example
In this example, a 512 K × 8-bit boot with X data space program overlay is interfacing the EPROM and the DSP. A program loaded in the EPROM will load into the DSP at boot time and run. The booted program can then load additional programs and data from the EPROM into the DSP using overlay techniques (see Figures 4, 5 and 6).
One memory device comprises the 8-bit wide boot bus. During reset, the DSP boot code loads bytes from the EPROM, packs them into 24-bit words, and stores them into Program RAM. The first word read from the EPROM indicates the number of words to load. The second word from the EPROM contains the starting load address for the packed data. The starting load address is also the address that gains program control after the program is loaded. About the authors
Iantha E. Scheiwe is currently a senior application developer working for Motorola's Semiconductor Products Sector. Prior to her current position, she worked with an SPS software research team investigating SIMD DSP architectures. She graduated from Valparaiso University in 1996 with a B.S. in computer engineering. Felicia L. Benavidez works in Motorola's Wireless Infrastructure Systems Division where she works with customers to integrate Motorola's MSC8100 and DSP56300 families of DSPs in infrastructure applications. Benavidez graduated with a B.S. in electrical engineering from New Mexico State University.
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||
| Back to Top |