Prev: DIFF_TERM and unused pin
Next: Camera link specification
From: Antti on 17 Oct 2006 08:33
Ben schrieb:

> Hi,
>
> i'm using Block Memory Generator 2.1 for a 16bit * 1024 RAM implemented in virtex4 BRAM and want to initialize the data with a *.coe file. But if i dump the data from the *.bit file with "data2mem -d" it doesn't match completely with the data from the *.ceo file. for example:
>
> * .ceo file: memory_initialization_radix=16; memory_initialization_vector= FFFF, FFFF, 0201, 0403, 0605, 0807, 1009, ...
>
> data2mem dump:
>
> 7F FF 7F FF 01 01 02 03 03 05 04 07 09 09
>
> It seems that the Block Memory Generator does a wrong mapping of the 16 bit wide ram into the 16 + 2 wide (due to parity bits) BRAM or is this an error of data2mem?
>
> My *.bmm File looks like this: ADDRESS_SPACE bram1_space RAMB16 [0x00000000:0x000017FF] BUS_BLOCK ...BRAM[15:0] PLACED = X2Y12; END_BUS_BLOCK; END_ADDRESS_SPACE;
>
> If i use data2mem to insert BRAM initialization data from a *.mem file into the *.bit file, the data seems to be correct.

try
1) specify RAMB18 in bmm file
or
2) make sure the block ram is using 4 or more BRAMs,
in that case the parity bits are not used

Antti
http://www.microfpga.com

From: Antti on 17 Oct 2006 11:17
Ben schrieb:

> 1) I even tried RAMB18 in the *.bmm file but unfortunately this results in the same wrong data.
>
> 2) Why the parity bits aren's used if my block ram use more than 4 BRAMs? I actually need a number of seperate 16*1024 Block RAMs in my project and can't use 4 or more BRAMs for one of my Block RAMs.
>
> Someone has an idea if the bit mapping error is done by data2mem or by the Block Memory Generator?

option 3
instantiate BRAM from HDL code, that works

Antti

 | 
Pages: 1
Prev: DIFF_TERM and unused pin
Next: Camera link specification