EDK 8.2 Block RAM error
in [FPGA]
|
Prev: ise 7.1
Next: spartan-3e starter kit and ethernet
From: Antti on 18 Nov 2006 14:27 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
From: MM on 18 Nov 2006 16:16 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 "Antti" <Antti.Lukats(a)xilant.com> wrote in message news:1163878069.748187.262430(a)h54g2000cwb.googlegroups.com... > 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 >
From: Antti on 18 Nov 2006 17:26 MM schrieb: > 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 > 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
From: MM on 19 Nov 2006 13:15 "Antti" <Antti.Lukats(a)xilant.com> wrote in message news:1163888792.295560.43610(a)k70g2000cwa.googlegroups.com... > > 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 :( 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
From: Antti on 21 Nov 2006 14:09
MM schrieb: > "Antti" <Antti.Lukats(a)xilant.com> wrote in message > news:1163888792.295560.43610(a)k70g2000cwa.googlegroups.com... > > > > 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 :( > > 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 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 |