ADM-XRC SDK 2.8.1 User Guide (Linux)
© Copyright 2001-2009 Alpha Data
The ddr2sram_port component is part of the memif package and implements an interface to a bank of DDR-II SSRAM memory. This component follows the generic user interface for memory ports, but also has a few additional parameters and sideband signals, as shown in the following figure:
Projects making use of this component must include all of the following source files (relative to root of SDK installation):
fpga/vhdl/chipscope/src/ilap_pkg.vhd
fpga/vhdl/chipscope/src/ilacombo_sim.vhd
fpga/vhdl/common/memif/memif_pkg.vhd
fpga/vhdl/common/memif/memif_int_pkg.vhd
fpga/vhdl/common/memif/memif_def_synth.vhd OR fpga/vhdl/common/memif/memif_def_sim.vhd
fpga/vhdl/common/memif/cmd_fifo.vhd
fpga/vhdl/common/memif/ddr2sram/ddr2sram_port.vhd
If synthesizing, the file fpga/vhdl/common/memif/memif_def_synth.vhd must be included. If simulating, the file fpga/vhdl/common/memif/memif_def_sim.vhd must be included instead.
Name | Type | Function | Note |
a_width | natural | Width in bits of the port logical address, a. | 4 |
d_width | natural | Width in bits of the port data in and out, d and q respectively. | 3 |
pinout | ddr2sram_pinout_t | This value specifies the physical configuration of the memory port. For convenience, an application may map it to one of the predefined constants. | |
ra_width | natural | Width in bits of the memory device address bus, ra. | 1 |
rc_width | natural | Width in bits of the memory device control bus, rc. | 2 |
rd_width | natural | Width in bits of the memory device data bus, rd. | 3 |
tag_width | natural | Width in bits of the tag in and out, tag and qtag respectively. |
Notes:
The signals of this interface to and from the user application are as follows:
Signal | Type | Function | Note |
a | in | Logical address User code must place a valid address on a when it asserts ce. Since a memory port effectively represents a memory device as a linear array of words of width d_width, this address is a logical address, rather than anything resembling what one might see on the ra bus. |
|
be | in | Byte enables to memory User code must place valid byte enables on be whenever a write command is entered (ce and w both asserted). A logic 1 in a given bit of be means that the corresponding byte within be will be written to memory, while a zero means that the corresponding byte will not be written to memory. |
|
burst_len | in | Burst length select (sideband signal) This input selects whether the DDR-II SSRAM devices are burst length 2 (BL2) or burst length 4 (BL4) devices: 0 => BL2 1 => BL2/BL4 If BL2/BL4 is selected, the memory port will be compatible with BL2 and BL4 devices, although a performance penalty may apply depending on how the user application uses the memiry port. If BL2 is selected, the memory will not be compatible with BL4 devices. If the burst length is unknown at build time, one should select BL4. Refer to the section below for a discussion of performance. |
6 |
ce | in | Command entry User code asserts this signal to enter a new read or write command into the memory port. When asserted, a and w must be valid. When asserted along with w, tag must also be valid. User code must not assert ce when ready is deasserted. Other than that, there are no restrictions on how few or how many clock cycles ce can remain asserted. It can be pulsed for single clk0 cycles, or asserted for many clk0 cycles (ready permitting). The address, byte enables, tag etc. of a command need not bear any relationship to that of the previous command, but refer to the section below for a discussion of performance. |
|
clk0 | in | Clock for user interface All other signals except rst are synchronous to clk0. |
5 |
clk90 | in | High speed clock, phase 90 This clock must be the same frequency as clk0 but 90 degrees behind. |
5 |
clk180 | in | High speed clock, phase 180 This clock must be the same frequency as clk0 but 180 degrees behind. |
5 |
clk270 | in | High speed clock, phase 270 This clock must be the same frequency as clk0 but 270 degrees behind. |
5 |
d | in | Data to memory User code must place valid data on d whenever a write command is entered (ce and w both asserted). |
|
dll_off | in | DLL disable (sideband signal) User code should drive this input with 0 for normal operation, but driving it with 1 causes the DOFF# field within rc to be asserted. |
6 |
q | out | Data from memory When valid is asserted by the memory port (as a result of a read command), q reflects the data read from memory. |
|
qtag | out | Tag out When valid is asserted by the memory port (as a result of a read command), qtag reflects the tag value that was assocated with that read command. |
|
ready | out | Port ready When the memory port asserts ready, user code is permitted to assert ce. Certain types of memory port may unconditionally assert ready, whereas other types of memory port may sometimes deassert ready depending on several factors. For example, a DDR-II SDRAM port is capable of buffering a certain number of commands internally, but if its command buffer is filled while it executes a refresh cycle, it will deassert ready. |
|
rst | in | Asynchronous reset for memory port May be tied to logic 0 if not required. |
|
sr | in | Synchronous reset for memory port May be tied to logic 0 if not required. |
|
tag | in | Tag in When user code asserts ce with w deasserted, it must also place a valid tag on the tag signal. When, as a result of the read command, the memory port asserts valid, the qtag output reflects the tag value originally passed. This is intended to facilitate sharing of a memory port between several data sources or data sinks, where each source or sink recognizes a particular set of tags. |
|
valid | out | Read data valid When the memory port asserts valid, it does so as a result of a read command (user code asserted ce with w deasserted). When valid is asserted, both q and qtag are valid. |
|
w | in | Write select When user code asserts ce, it must place either a logic 1 on the w signal in order to select a write command, or 0 in order to select a read command. |
Notes:
The signals of this interface to and from the memory device(s) are as follows:
Signal | Type | Function |
ra | in | Memory device address bus This bus carries address information to from the memory port to the memory device(s). |
rc | inout | Memory device control bus This bus carries control signals between the memory port and the memory device(s), and is composed of various fields. These signals are bundled together into the rc bus so that, for the most part, the user application need not care what they are. Refer to note 2 for the mapping of the rc bus to device pins. |
rd | inout | Memory device data bus This bus carries data between the memory port and the memory device(s). For each command entered via ce, two words are transferred on rd, which determines the relationship between the rd_width and d_with parameters. Refer to note 3 for details. |
This memory port features an internal command buffer capable of buffering about 10 commands before deasserting the ready signal. Most of the time, the rate of consumption of commands from the command buffer is at least as fast as production of new commands by the user application. Certain usage patterns, however, may result in a accumulated backlog in the command buffer.
A DDR-II SSRAM device has a burst length of two or four (i.e. two or four words on transferred on the rd bus). This component supports burst length four (BL4) devices, but is compatible with burst length 2 devices without modification (to see why this is so, one must understand the signalling protocol used by generic DDR-II SSRAM devices).
There are two potential performance penalties in this memory port:
Latency for read commands is fairly deterministic, since the penalties described above are limited to one cycle (although these penalties may be accumulated by successive commands). The best-case latency from entry of a read command (ce asserted with w deasserted) to valid asserted is approximately 9 clk0 cycles. Worst case latencies may be computed by adding the above penalties to the best-case latency.
The optimal usage pattern for this memory port is blocks of accesses of the same type (read or write) with addresses that increment by one on each successive access. When used optimally, a 32-bit wide DDR-II SSRAM memory port operating at a clk0 frequency of 133MHz) can sustain approximately 1GB/s.