Thanks for the png of the design; I was trying to remember how it works from memory.
But that said, I still think I'm right. A single word is a concatenation of 4 32-bit integers consisting of a 30-bit counter and the top two bits reserved as an "integer counter". Note that the freeze counter is 29 bits, but the DRAM can only see 2^24 addresses. The DRAM is therefore written 2^5 times before it stops. This is why you see the five 1's in bits 25-29. Laura On Tue, Mar 13, 2012 at 3:58 PM, Ryan Monroe <[email protected]> wrote: > 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 > >
