Prev: How to over clock for DSP48
Next: Absolute value of a two's complement number
From: Wipster on 22 Apr 2010 15:25
Hi,
The age old problem it seems data2mem and BMM files and I am stuck
with a new problem I cant find the answer for.
I have some generic ram in verilog which the xilinx software suite
looks at and maps to two RAMB16s (higher two bytes and lower two
bytes) so I have made a BMM file with the right names and widths
depths etc Thats fine, it recognizes them and updates the _bd.bmm with
the locations they have been mapped too.
However the CPU does not turn over, I did a bit of digging and did a
dump of working and non working BRAM data, it seems that on the
working dump the higher two byte block is bit-shifted right 2 (I'm
guessing because readmemh uses the parity as the lsbs).
Is there a way I can tell data2mem that I want the parity on the other
side or not atall so it inserts the code properly because its giving
an offset when it inserts, its also interesting to note that the lower
block matches perfectly?
I have tried using RAMB18 but that didn't generate anything that
looked right. Here is the working, two bit shifted, readmemh output:
http://pastebin.com/0hgNpAnP and here is the non working data2mem, non
bit shifted version: http://pastebin.com/Tcs3PJjZ

Much thanks,
Ben
From: Wipster on 23 Apr 2010 15:45
On Apr 22, 8:25 pm, Wipster <benwhit...(a)gmail.com> wrote:
> Hi,
> The age old problem it seems data2mem and BMM files and I am stuck
> with a new problem I cant find the answer for.
> I have some generic ram in verilog which the xilinx software suite
> looks at and maps to two RAMB16s (higher two bytes and lower two
> bytes) so I have made a BMM file with the right names and widths
> depths etc Thats fine, it recognizes them and updates the _bd.bmm with
> the locations they have been mapped too.
> However the CPU does not turn over, I did a bit of digging and did a
> dump of working and non working BRAM data, it seems that on the
> working dump the higher two byte block is bit-shifted right 2 (I'm
> guessing because readmemh uses the parity as the lsbs).
> Is there a way I can tell data2mem that I want the parity on the other
> side or not atall so it inserts the code properly because its giving
> an offset when it inserts, its also interesting to note that the lower
> block matches perfectly?
> I have tried using RAMB18 but that didn't generate anything that
> looked right. Here is the working, two bit shifted, readmemh output:http://pastebin.com/0hgNpAnPand here is the non working data2mem, non
> bit shifted version:http://pastebin.com/Tcs3PJjZ
>
> Much thanks,
> Ben

Just to give an update on this, I have found the problem.
It seems that map connects 16 bits of the first RAMB16 as you would
expect but then connects the parity of that block and 14 bits of the
second RAMB16. Data2mem assumes parity bits are parity bits so the
codewords where missing the top bits, this is corrected by going into
the unrouted xdl and editing the connections back to connect to the 16
data bits of both.

And there you go, hopefully they can fix this issue as its a time
consuming correction.

Ben
 | 
Pages: 1
Prev: How to over clock for DSP48
Next: Absolute value of a two's complement number