1. Home
  2. Field-Programmable Gate Arrays
  3. EDK 8.2 Block RAM error

EDK 8.2 Block RAM error

hi,

it seems that either EDK 8.2 or ISE 8.2 has still some issues with the BRAM inits, if an EDK system has more than 1 BRAM block, then the BMM file is generated "looking good", makes sense but when it passes NGCbuild then only the first memory block gets the "PLACED" locations assigned, the second one stays af if not located, those DATA2MEM would not be able to initialize the data into second BRAM block.

I wonder if there is some trick or fix or is it required to wait for

9.1 + SPx ?

there might be a solution, namly the OpenFire (microblaze clone) includes a perl script that processes the .LL file and re-generates the BMM with proper PLACED constraint _after_ the xilinx tool flow.

Using tools from OpenFire to fix up the BUGS in EDK is how is that word

- ridicilous? but maybe its the only option currently

Antti

Reply to
Antti
Loading thread data ...

Antti,

I am not sure if I correctly understand what your problem is, but I do some massaging to all of the bmm files, which include more than one address space. Just delete all of the END_ADDRESS_SPACE lines except for the very last one and all of the ADDRESS_SPACE lines except for the very first one. Then correct the address range to include all the blocks and save the file.

/Mikhail

Reply to
MM

MM schrieb:

I tried that too, but did seem to make a difference, the second block does not get any PLACED values during ngdbild :(

two blocks only work in case of 128MB space that is made of 2 times

64kb but if i have say 32kb + 8kb then the second one is not working :(

Antti

Reply to
Antti

IIRC it only works when the blocks are of the same size.... So, if you want

40K, you might need to make it out of 5 8K blocks...

/Mikhail

Reply to
MM

MM schrieb:

1 same size rquirement is BS, the tool should tolerate also different sized blocks 2 and.. same size blocks dont work either, only first one gets PLACED, second stays unprocessed

so its just another Xilinx bug,

Antti

Reply to
Antti

It should... however it doesn't....

Well, I do have a V4 design, which uses 4 consecutive 32KB BRAM blocks each attached through an individual PLB_BRAM controller and it works (last tried in 8.1)... Perhaps you are trying to do something more advanced...

/Mikhail

Reply to
MM

"MM" schrieb im Newsbeitrag news: snipped-for-privacy@mid.individual.net...

hm, i have two 64K blocks on LMB bus, and only first one is updated in the BMM file :( I dont think this is advanced use ?

Antti

Reply to
Antti Lukats

One obvious difference is that I am working with PPC and using PLB_BRAM controllers while you are dealing with MicroBlaze... I can't say why it should matter though...

/Mikhail

Reply to
MM

MM schrieb:

BUG::: EDK 8.2 generates BMMs incompatible with ISE 8.2 when BRAM blocks are consecutive. if there is gap in address space then it all works.

there is a workaround to manually fix the generated BMM files

Antti

Reply to
Antti

So they broke it in 8.2!!!! Are you talking about the AR 24296 for the fix? This is as ugly as it can only get :( I can't beleive this....

/Mikhail

Reply to
MM

MM schrieb:

ROTFL !!!

yes, its AR24296 - but see its not a bug, its a FEATURE!!!!

Quoting Xilinx: "..is a new feature in 8.2i that does not work well.." ==========================================================

I can confirm, that this feature brakes everything in contigous memory blocks. well my workaround is simpler and doesnt require FPGA editor to be used, just wrap all memory blocks in its own ADDRESS_SPACE container and rerun ngdbuild this will update the BMM file properly, but this means that you cant do it from the GUI any more

Antti

Reply to
Antti

Hi Antti,

Could you please elaborate a little bit on your solution? I have just tried building my old design in ISE 8.2 and it doesn't update the bmm file at all, i.e. I don't see edkBmmFile_bd.bmm file being generated whatsoever... although I do know that ngbuild processes the edkBmmFile.bmm.

Thanks, /Mikhail

Reply to
MM

Antti,

Sorry, it does actually produces the file but with the exactly the same problem as you described it... So, my question on your solution still stands...

Thanks, /Mikhail

Reply to
MM

MM schrieb:

this is non working, generated by EDK 8.2

ADDRESS_MAP microblaze_0 MICROBLAZE 100 ADDRESS_SPACE bram_combined COMBINED [0x00000000:0x0002FFFF] ADDRESS_RANGE RAMB16 BUS_BLOCK END_BUS_BLOCK; END_ADDRESS_RANGE; ADDRESS_RANGE RAMB16 BUS_BLOCK

END_BUS_BLOCK; END_ADDRESS_RANGE;

ADDRESS_RANGE RAMB16 BUS_BLOCK

END_BUS_BLOCK; END_ADDRESS_RANGE; END_ADDRESS_SPACE;

END_ADDRESS_MAP;

the fix is to SPLIT the address space in seperate addresses spaces so in each address space there is only one BUS_BLOCK

the in it seems to work, eg all blocks get "PLACED" ok

Antti

Reply to
Antti

Antti,

I've done as you say but something is not working, the updated bmm file is not being created at all... You said something before to the effect that after correcting the bmm file one can't use GUI anymore... What exactly did you mean?

What is the correct syntax for the file with splitted address space? I used the one generated by 8.1. It looks like this:

ADDRESS_BLOCK plb_bram_if_cntlr_1_bram RAMB16 [0xfffe8000:0xfffeffff] BUS_BLOCK END_BUS_BLOCK; END_ADDRESS_BLOCK; ADDRESS_BLOCK plb_bram_if_cntlr_0_bram RAMB16 [0xfffe0000:0xfffe7fff] BUS_BLOCK END_BUS_BLOCK; END_ADDRESS_BLOCK; ADDRESS_BLOCK plb_bram_if_cntlr_2_bram RAMB16 [0xffff0000:0xffff7fff] BUS_BLOCK END_BUS_BLOCK; END_ADDRESS_BLOCK; ADDRESS_BLOCK plb_bram_if_cntlr_3_bram RAMB16 [0xffff8000:0xffffffff] BUS_BLOCK END_BUS_BLOCK; END_ADDRESS_BLOCK;

So the keywords are a little different... I guess that's my problem... Do I need both ADDRESS_SPACE and ADDRESS RANGE?

Thanks, /Mikhail

Reply to
MM

Never mind. I figured it out...

/Mikhail

Reply to
MM

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.