SRAM emulator

Details SRAM emulator SRAM emulator

2002-03-14

2003-06-24

Dinh, Son T. (Department: 2824)

Static information storage and retrieval

Addressing

Sync/clocking

C365S194000, C365S230060, C365S238500

Reexamination Certificate

active

06584036

ABSTRACT:

FIELD OF THE INVENTION
The present invention relates to SRAM interfaces for controlling embedded SDRAM for system on chip (SOC) applications.
BACKGROUND OF THE INVENTION
Commodity SRAM and DRAM memory devices are typically used in personal computer systems for data storage. In a personal computer system, the memories are controlled either by the CPU or by an on-board memory controller. To ease system level design, commodity memories are usually required to meet minimum industry performance standards, or system manufacturer imposed performance standards such as the Intel PC133 SDRAM standard. These standards allow for the design of memory controllers that can maximize the performance of any memory that meets industry standards. Hence signalling and timing details for operating the memory are somewhat transparent to system designers since they are under the control by a CPU or memory controller. However, the limited bandwidth, caused in part by the capacitance and inductance of wire leads of the external memory prevents the memory from operating at its full potential.
One solution to this problem is to embed memory onto processors and other system-on-chip (SOC) devices, such as application specific integrated circuits (ASIC). But because SOC devices are usually application specific, there are very few standards that need to be adhered to due to the customized nature of the memory.
SRAM is commonly embedded in SOC devices because of the compatibility of its manufacturing process with logic manufacturing processes. The drawback of embedding SRAM is the relatively large area it occupies for a small storage density. New manufacturing processes allow DRAM to be embedded onto SOC devices. Embedded DRAM, such as SDRAM, are practical for SOC devices where large amounts of memory are required without compromising excessive silicon area. This high level of integration reduces costs and provides other well-known system level benefits, especially for portable applications, or in applications where physical space is limited.
Despite the advantages of embedding DRAM over SRAM onto SOC devices, overall system performance of embedded DRAM remains inadequate for high-speed applications. Control of an SRAM does not require many signals, and the timing of these signals is not heavily constrained. Hence SOC designers have been able to directly access embedded SRAM with minimum additional peripheral logic. For example, a read operation from an asynchronous SRAM only requires a write enable signal (WE) to be at the high logic level and a change in an address from which data is to be read from. SDRAM on the other hand, is more complex because it requires more signals, and the timing of the signals are tightly constrained within preset limits. Memory addresses are multiplexed into row and column addresses, and specific combinations of column address strobe (CAS), row address strobe (RAS), write enable (WE), chip select (CS) and specific address signals are applied to issue specific commands which determine the DRAM operation. In a read operation, row addresses must be asserted during a “bank activation” command cycle. Then a fixed time interval must pass before a “read” command and column addresses can be asserted. This fixed time interval is typically specified by the SDRAM manufacturer, and can vary from manufacturer to manufacturer. Due to this additional complexity, simple interfaces, or emulators, that allow SOC processors to transparently access embedded DRAM have been developed.
SRAM interfaces have been chosen because SRAMs are simple and straightforward to access. In other words, the SOC processor “sees” an SRAM device through the SRAM interface and issues SRAM control signals to access the SDRAM memory. The SRAM interface then generates the appropriate SDRAM control signals and converts received linear SRAM addresses into separate row and column addresses. Just as importantly, the SRAM interface also controls timing for activating the appropriate SDRAM control signals.
FIG. 1
is a block diagram of a prior art graphic processing ASIC that uses embedded DRAM memory. This ASIC has a video codec engine (VCE), digital signal processor (DSP), video processing unit (VPU), memory interface
50
and SDRAM memory
52
divided into two different blocks. SDRAM memory
52
can be stacked, trench or planar capacitor DRAM. Memory interface
50
is an SRAM interface, which generates SDRAM control signals from SRAM type commands. Unfortunately, prior art SRAM interfaces generate SDRAM control signals with worst-case scenario timing. More specifically, the SDRAM control signals are activated at times well beyond the minimum required time. This is mainly due to the fact that the internal SDRAM clock signals are generated synchronously to the external system clock of the SOC device.
FIG. 2
shows a read access timing diagram for the system of FIG.
1
.
The timing diagram of
FIG. 2
shows traces for the system clock signal SCLK and addresses and commands ADDR/CMND received by memory interface
50
for generation of activate signal ACT, row clock RCLK, column clock CCLK, precharge clock signal PCHCK and output data Q. This example illustrates a read operation from the system of FIG.
1
. The SDRAM memory provides data Q in response to the signals generated by the memory interface
50
. Commands are latched on the first rising edge of SCLK
60
, and decoded to generate the active ACT signal shortly thereafter. The rising edge of ACT triggers the generation of the RCLK pulse for latching a row address to activate the appropriate memory bank. Another command is latched and decoded on the second rising edge of SCLK
62
for generating the CCLK pulse. A column address is latched on the rising edge of the CCLK pulse, resulting in the output of valid data Q shortly thereafter. A PCHCK precharge pulse is then generated to precharge all the memory banks in preparation for subsequent accesses. The system of
FIG. 1
requires a minimum of two clock cycles to provide data after the initial read command and row address is latched. This is due to the fact that the row control signal RCLK is generated in the first system clock cycle and the column control signal CCLK is generated in the subsequent system clock cycle.
Unfortunately, the embedded SDRAM is capable of providing data earlier than the system of
FIG. 1
allows. More specifically, the embedded SDRAM is capable of latching column addresses earlier by issuing the CCLK pulse earlier. But because the row and column clock signals RCLK and CCLK are synchronized to the system clock SCLK, the earliest that the CCLK pulse could appear is after the second rising edge of the system clock. In a practical example, if the SDRAM core has a minimum access time of 5 ns, the time between CCLK and valid data is 2.5 ns, precharge requires 1.5 ns and the SCLK is a 100 MHz clock with a period of 10 ns, the system of
FIG. 1
would require a minimum of 12.5 ns to generate valid data. 12.5 ns is the sum of one fall clock cycle time plus the CCLK to valid data time. However, the SDRAM memory is capable of providing data in 7.5 ns. In operation though, the system of
FIG. 1
only provides new data every 20 ns, or every two clock cycles. The SDRAM on the other hand, is capable of providing new data every 9 ns, which is the sum of 7.5 ns as previously discussed plus 1.5 ns of precharge time.
Some SRAM interface designs attempt to improve SDRAM access times by using clock multipliers to generate intermediate high frequency clock signals from the external system clock. Although this technique will increase SDRAM performance, it is not cost effective because it is difficult to design a clock circuit that will reliably generate a high frequency clock signal. Additionally, this technique does not fully optimise SDRAM performance because it is inherently difficult to control an SDRAM that operates in a clock domain having finite frequency granularity.
Hence, SOC devices having embedded SDRAM memory will not operate at their full potential due to limitations in the SRAM interface that control them.

Affiliated with

Also associated with

Rating

SRAM emulator does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with SRAM emulator, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and SRAM emulator will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3146836