DDR2DRAMInterface
- Dual ported
- Synchronous FIFO interface with an additional request signal
- The wrapper will monitor if the user is reading data quickly enough to prevent overflow from the memory to the user
- If there is not enough data in the fifo during a write to do a full burst write (except if the user pulls the wr_req signal low), the wrapper will terminate the burst and wait for more data.
- All DRAM operation (including refresh) is hidden from the user. The only interface the user sees is the Fifo interface along with the request control signals
- For writes:
- The user pulls the write signal high and provides the starting address
- The user waits for the write_ready signal to go high.
- The user writes the data into the fifo
- The user continues to write data into the FIFO to be sent to the DRAM
- If the wr_rdy signal goes low, the user will pull the write signal low and wait until it goes high again
- The user pulls the write signal and the wr_req low when done
- As long as the write signal is high, the controller will keep writing the data from the fifo to the next address.
- For reads:
- The user pulls the read_request signal high and provides the starting address
- The user waits for the read_ready signal to go high.
- The user reads the data from the fifo by asserting the rd signal
- If the rd_rdy signal goes low, the user will pull the rd signal low and wait until it goes high again
This forces sequential access into the DDR2 and simplifies the wrapper significantly. However, if an address is on the same row, this will lead to not using possible optimizations (no need to end transaction).
Also, the interface is a bit harder to understand (i.e. not standard fifo).
In the alternative version, for writes, data and address are provided together and addresses do not have to be sequential. This complicates the wrapper since it will have to check whether the next address is sequential or not, it will also need to maintain an additional queue of addresses.
For reads, allowing random access on each word makes the interface much more complicated since we need to maintain a FIFO for the addresses separate from the data queue since they are not emptied together and differing latencies for random accesses mean that the address FIFO might get full, leading to the additional signals. Since read times are not deterministic, this leads to this non-standard interface. It would also be hard for the user to match which read produced which data since the read latencies are variable.
This version breaks the symmetry between reads and writes, simplifies the writes, but complicates reads. In additions it requires additional hardware which will probably translate to additional latency (due to pipelining).
On the other hand, an interface such as this allows any implementation behind the interface, so that the user is not forced to do sequential access. An arbiter can be built that will look at the incoming addresses and bundle them together to maintain high throughput for random accesses.
Now, if we decide that we are just providing sequential accesses and the addresses provided should be sequential, then there would be no point in having the user provide the addresses. An interface such as this has to support random accesses bacause that is what it looks like.
- The same fifos that are used to cross the clock domains between the 200MHz clock domain and the core clock domain are used to buffer data for burst reads and writes.
- Initial implementation will use the sequential mode, later versions might use the interleaved mode for higher throughput.
- Feb 5, 2007: Single-op mode implemented and simulated
- Feb 19, 2007: Burst mode implemented and simulated
- March 5, 2007: Hardware testing completed
- XAPP549 - DDR2 SDRAM Memory Interface for Virtex-II Pro FPGAs - Xilinx Application Note for implementing DDR2 memory interfaces
- Xilinx Memory Solutions - Information about interfacing with various memory types. Includes a link to the Memory Interface Generator (MIG User Guide inside .ZIP file)