Ouch! I feel pretty silly right now... looks like that was the
problem. Good call!
--Ryan
On 03/13/2012 01:15 PM, Laura Spitler wrote:
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
