Hi Laura,Thanks for the quick response! To clarify, in the image I posted, each row is a 'word' in the DRAM. They are separated into 32-bit chunks for clarity. So, there are as many rows under this (conceptually) as there are addresses in the dram.
The first row is address 0, so we shouldn't see counter wrapping. IMHO, there shouldn't be any '1's in the upper bits -- besides the top two, which are set by the concat block in the model (picture attached for convenience)
Thanks for the tip about the controller! For this application, we only need 2^20 memory locations, so we're good this time.
--Ryan Monroe On 03/13/2012 12:47 PM, Laura Spitler wrote:
Hi Ryan, I believe I understand what's going on assuming that your output should be read by columns and not by rows (and that there are more rows for each column below what you printed out). The counter in the design is something like 29-bits (I may have the exact value off). For a DRAM with 1 GB of memory, there are only 2^25 address, so extra 1's you're seeing at the top of the word is the counter wrapping. That said, there was a bug in the original verliog code ( mlib_devel_10_1/xps_lib/XPS_ROACH_base/pcores/dram_controller_v1_00_a/hdl/verilog/dram_controller.v ) where ROW_WIDTH = 13 instead of ROW_WIDTH = 14. This should have been fixed, but you should probably double check it. If the bug is still there, only 2^24 addresses are written. Hope that helps. Laura On Tue, Mar 13, 2012 at 3:09 PM, Ryan Monroe<[email protected]> wrote:Hey all, I'm trying to use the dram as a coefficient buffer, but I'm having some problems with the demos. I tried to use test_dram_10_1 to fill the dram and subsequently read out the results, but it looks like the upper eight bits of every 32-bit word are being corrupted (or used as some kind of parity bits??) Attached is a printout of the first couple of words read from the dram. As expected, the lower bits are a counter and the upper two bits increase across the row, so to speak. However, the following six bits (which should be '0's, since they're part of a counter which starts at '0'), are all 1s! Anyone else seen this? (note: I'm using ISE 13.4. Might be the problem...) Thanks guys! --Ryan Monroe
<<attachment: test_dram_model.png>>
