cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
changyun
Visitor
Visitor
23,861 Views
Registered: ‎07-14-2009

How to use larger BRAM in a MicroBlaze project?

Jump to solution

Does anyone has an idea how can I use larger BRAM (more than 64K) in a MicroBlaze project? From the MicroBlaze user guide, it looks like I need to generate

a new BRAM module using core generator. I did that and now I have vhdl source file for 128K BRAM module and need to incorporate this module into my project.

I checked the Create or Import Peripheral Wizard. Seems it can incorporate peripheral modules which connect to PLB.  But in my case, I want to replace the default 64K BRAM

in XPS using my 128K one and connect it to LMB. Is there any way to do that? Or is there any way I can go to enlarge the BRAM size?  Thanks.

 

 

0 Kudos
85 Replies
roketroket
Visitor
Visitor
8,989 Views
Registered: ‎05-28-2012

I cleared project but the problem continues, can this be a problem of ISE version 14.1?

Anyone managed to connect multiple BRAMS to instruction bus in 14.1 and generate programing file with no errors?

 

0 Kudos
thirdeye
Explorer
Explorer
8,985 Views
Registered: ‎05-30-2008

@roketroket wrote:

I cleared project but the problem continues, can this be a problem of ISE version 14.1?

Anyone managed to connect multiple BRAMS to instruction bus in 14.1 and generate programing file with no errors?

 



I am not sure I ever got it to work connected ot the instruction bus.

 

I ended up attaching the extra BRAMs to the AXI after a not-so-useful webcase and getting sick of trying to make it work.

 

I was told that shoud work, but I am not sure I ever got it to.

The AXI ones definitely work for me in 13.4

 

Josh

0 Kudos
Anonymous
Not applicable
8,937 Views

Hello.  I am running into the exact same issue as roketroket.

 

I have an ISE14.1 based design with .xmp core created by XPS.  I need to increase the (contiguous) base memory of the Microblaze from 64K to 128K.

 

Just as roketroket did - I have added an addition block ram and instruction/data controllers to the LMB, and assigned one controller to address 0x00000000 to 0x0000FFFF, and the 2nd controller from 0x00010000 to 0x0001FFFF.

 

XPS DRC passes ok, and it generates a netlist successfully.

However, when I rebuild the ISE design to use the new Microblaze core, error messages occur.

 

Specifically, synthesis and Place/Route  pass ok, but after running bitgen in the 'generate programming file' portion, 16 similar error messages are created.

 

(example of 4 of these error messages follows):

Started : "Generate Programming File".
Running bitgen...
Command Line: bitgen -intstyle ise -f top.ut top.ncd

ERROR:PhysDesignRules:368 - The signal
   <cpu1/microblaze_0_i_bram_ctrl2_BRAM_PORT_BRAM_Addr<0>> is incomplete. The
   signal is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal
   <cpu1/microblaze_0_i_bram_ctrl2_BRAM_PORT_BRAM_Addr<2>> is incomplete. The
   signal is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal
   <cpu1/microblaze_0_i_bram_ctrl2_BRAM_PORT_BRAM_Addr<3>> is incomplete. The
   signal is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal
   <cpu1/microblaze_0_i_bram_ctrl2_BRAM_PORT_BRAM_Addr<4>> is incomplete. The
   signal is not driven by any source pin in the design.

 

I have cleaned both the XPS project and the ISE project., regenerated netlist in XPS, and attempted to rebuild the entire ISE design.  Unfortunately, the error(s) persist.

 

 

 

0 Kudos
thirdeye
Explorer
Explorer
8,935 Views
Registered: ‎05-30-2008

@Anonymous wrote:

Hello.  I am running into the exact same issue as roketroket.

 

I have an ISE14.1 based design with .xmp core created by XPS.  I need to increase the (contiguous) base memory of the Microblaze from 64K to 128K.

 

Just as roketroket did - I have added an addition block ram and instruction/data controllers to the LMB, and assigned one controller to address 0x00000000 to 0x0000FFFF, and the 2nd controller from 0x00010000 to 0x0001FFFF.

 

XPS DRC passes ok, and it generates a netlist successfully.

However, when I rebuild the ISE design to use the new Microblaze core, error messages occur.

 

Specifically, synthesis and Place/Route  pass ok, but after running bitgen in the 'generate programming file' portion, 16 similar error messages are created.

 

(example of 4 of these error messages follows):

Started : "Generate Programming File".
Running bitgen...
Command Line: bitgen -intstyle ise -f top.ut top.ncd

ERROR:PhysDesignRules:368 - The signal
   <cpu1/microblaze_0_i_bram_ctrl2_BRAM_PORT_BRAM_Addr<0>> is incomplete. The
   signal is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal
   <cpu1/microblaze_0_i_bram_ctrl2_BRAM_PORT_BRAM_Addr<2>> is incomplete. The
   signal is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal
   <cpu1/microblaze_0_i_bram_ctrl2_BRAM_PORT_BRAM_Addr<3>> is incomplete. The
   signal is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal
   <cpu1/microblaze_0_i_bram_ctrl2_BRAM_PORT_BRAM_Addr<4>> is incomplete. The
   signal is not driven by any source pin in the design.

 

I have cleaned both the XPS project and the ISE project., regenerated netlist in XPS, and attempted to rebuild the entire ISE design.  Unfortunately, the error(s) persist.

 

 

 


I saw the same issue in 13.4 adn ended up putting 128K BRAMs on the AXI bus instead of the LMB bus. I then made the LMB bus BRAMs 8K or something since not as many were needed.

 

The linker script makes it "easy" to put different sections of the program into differnt memories.

 

My .text and .data sections tend to be large while other sections tend to be small.

I will sometimes put most code sections into the LMB BRAMs adn then add a separate AXI BRAM block or two to house the larger sections.

 

I believe there is no problem with placing the AXI BRAM address space adjacent to the LMB address space and calling them one even though on different busses, but I could be wrong about that.

 

Happy debugging!

 

Try the AXI though - I bet it will work first try - it did for me.

Josh

0 Kudos
Anonymous
Not applicable
8,908 Views

Thanks.  I will give the AXI attached BRAMs a try. 

Do you know if the bitstream tools are able to download code to the AXI attached BRAMs directly via the download.bit file?  (It seems like they should be able to be initialized with code).  Or, like external memory, do they need to be loaded using a bootloader and download utility like XMD/dow ?

 

 

 

0 Kudos
thirdeye
Explorer
Explorer
8,906 Views
Registered: ‎05-30-2008

Yes, if the linker script directs the sections of code to the BRAMs then they will be initialized in the bitstream.

This will work regardless of whether they are attached to the AXI or the LMB interface.

This is the whole advantage of using BRAMs instead of DDR for me.

Josh

0 Kudos
hamze
Adventurer
Adventurer
8,890 Views
Registered: ‎11-09-2010

In  ISE 14.1 do right-click on "generate programming file"

then choose "Process properties" and then "general option"

then uncheck first line ( DRC)

rerun generate program file

you will not see these errors

 

It seems that this option is turned on in version 14.1 while it was not in ISE 13.3

 

0 Kudos
dawatson
Observer
Observer
8,719 Views
Registered: ‎05-15-2012

Has anyone managed to attach more BRAM controllers to the LMB whilst using an AXI system? I could do this using the PLB but everytime I've tried it when using AXI I get a load of timing errors. I know you can ignore them but I'd rather have a correct implementation rather than something that could break.

0 Kudos
thirdeye
Explorer
Explorer
8,712 Views
Registered: ‎05-30-2008

@dawatson wrote:

Has anyone managed to attach more BRAM controllers to the LMB whilst using an AXI system? I could do this using the PLB but everytime I've tried it when using AXI I get a load of timing errors. I know you can ignore them but I'd rather have a correct implementation rather than something that could break.



I thought I had finally gotten them working for me attached to the AXI, but now I am not sure I ever did get it free of errors, let alone warnings. Sorry, but I am just not sure.

 

Xilinx told me it should work in a webcase.

They suggested using the AXI rather than the LMB connections to add additional BRAMs.

 

 

Josh

0 Kudos
dawatson
Observer
Observer
8,705 Views
Registered: ‎05-15-2012

I've managed to get rid of the timing errors by exporting to SDK through ISE. You can choose different placement options to try get rid of the timing errors, think the XPS must use the default (balanced) option which doesn't help!

0 Kudos
songxin
Observer
Observer
10,061 Views
Registered: ‎11-02-2010

It can not work by only changing the address size. 

My lmb_controller size is originally set as  64k.

My program size is smaller than 64K, but close (60k) however, the program doesn't work properly(it actually starts to work but doesn't work as it should), and the compiler option is set as no optimization. 

in this case, I doubt it may need larger bram, so I set the size as 128K

However, it doesn't work out and the program runs almost the same as before.

is 64K set  to be  the maximum size ?

 

 

0 Kudos
songxin
Observer
Observer
10,059 Views
Registered: ‎11-02-2010

I did add more bram and bram controller to merge a 96k bram. the linker script is as follows

 

_STACK_SIZE = DEFINED(_STACK_SIZE) ? _STACK_SIZE : 0x400;
_HEAP_SIZE = DEFINED(_HEAP_SIZE) ? _HEAP_SIZE : 0x400;

 

pic_ilmb_cntlr_pic_dlmb_cntlr : ORIGIN = 0x00000050, LENGTH = 0x0000FFB0
pic_ilmb_cntlr2_pic_dlmb_cntlr2 : ORIGIN = 0x00010000, LENGTH = 0x00008000
pic_ilmb_cntlr_all_pic_dlmb_cntlr_all : ORIGIN = 0x00000050, LENGTH = 0x00017FB0

 

the program size is 

text data bss dec hex filename
53700 872 3088 57660 e13c *..../executable.elf

 

the program doesn't work properly either.

 

should I enlarge the Heap size or Stack size?

But When I set the optimization level -O1, the program runs more properly ( could execute more commands)

 

 

 

0 Kudos
gusevv
Adventurer
Adventurer
10,044 Views
Registered: ‎11-13-2008

Songxin,

 

If the EDK does not complain that your program does not fit into the BRAM, then it is likely a problem with your heap/stack. Now you have set it to 1024. Do you define large arrays either statically or using malloc()?

 

Realize that if you define the larger heap/stack, then your program size will increase beyond 60K and you might not fit into the 64K. So, you can do the 2 BRAM controllers trick mentioned earlier. Optimization might help, but you will not be able to properly debug your code.

 

If you go the 2-controllers way, you can see whether you can access the memory beyond the 64K by using the XMD's rd/wr.

 

Thanks,
Victor

0 Kudos
hedink
Visitor
Visitor
10,007 Views
Registered: ‎06-09-2010

I am also using ISE 14.1 and I tried 5 different ways to get more BRAM. 

 

1) added BRAM to LMB bus

2) added bram to AXI4 lite bus

3) added bram to AXI bus (cached)

4) added multiple smaller BRAMs to AXI bus (cached)

5) added multiple smalller BRAMs to AXI lite bus

 

Each time I exceeded 64K I got the missing bitlane error from data2mem

 

When I reduced the total memory to 64k +-8k it worked

 

Has anyone using 14.1 got this to work?

 

0 Kudos
goran
Xilinx Employee
Xilinx Employee
9,996 Views
Registered: ‎08-06-2007

Hi,

 

This might be fixed in 14.2

Install it and see if it solves your issues.

Using a later release will sometimes help.

 

Göran

0 Kudos
hedink
Visitor
Visitor
9,988 Views
Registered: ‎06-09-2010

I installed 14.2,  it has the same behaviour exactly.

 

I have a working buildable project,  all I do is add another 32k or 64k and it failes to generate bitfiles

 

0 Kudos
hedink
Visitor
Visitor
9,975 Views
Registered: ‎06-09-2010

Well, just for kicks, I installed ISE 13.4 and reverted my project.

Same project settings, same code.

 

No Problem getting extra BRAM

 

I guess there is no point upgrading further till they fix the bugs.

 

0 Kudos
mari
Visitor
Visitor
9,582 Views
Registered: ‎06-01-2012

I get following errors after the adding of DDR2:

ERROR:PhysDesignRules:368 - The signal
   <config2/MicroBlaze_inst/bram_cntlr_0_BRAM_PORT_BRAM_Addr<30>> is incomplete.
   The signal is not driven by any source pin in the design.
ERROR:PhysDesignRules:368 - The signal
   <config2/MicroBlaze_inst/bram_cntlr_0_BRAM_PORT_BRAM_Addr<31>> is incomplete.
   The signal is not driven by any source pin in the design.
ERROR:Bitgen:25 - DRC detected 2 errors and 2 warnings.  Please see the
   previously displayed individual error or warning messages for more details.

These signals are referenced to the Port of LMB. There were no changes in this Port.

I work with ISE 14.1 and Digilent Atlys Board.

 

0 Kudos
dshine
Visitor
Visitor
8,999 Views
Registered: ‎11-03-2011

I know this thread is stale but I am having a similar problem and I didn't actually see a solution here that works for me.  I have a microblaze design in a Spartan 6 built using ISE 14.4.  I am trying to chain together mutiple 64kB BRAM blocks as recommedende in the thread and have triedd both LMB and AXI bus connections without success.  Most recently I implemented an AXI system with three BRAM blocks together.  The hardware compiles without error and I edited the linker script manually (attached) but when I run Data2Mem I get the error below. 

 

data2mem -bm C:/Xilinx/BBS_Main_Xilinx/WorkSpace/mb_system_hw_platform/system_bd.bmm -bt C:/Xilinx/BBS_Main_Xilinx/WorkSpace/mb_system_hw_platform/system.bit -bd C:/Xilinx/BBS_Main_Xilinx/WorkSpace/BBS_Project/Debug/BBS_Project.elf tag microblaze_0 -o b C:/Xilinx/BBS_Main_Xilinx/WorkSpace/mb_system_hw_platform/download.bit

 

ERROR:Data2MEM:31 - Out of bounds code segment for ram space in 'C:\Xilinx\BBS_Main_Xilinx\WorkSpace\mb_system_hw_platform\system_bd.bmm'.
Memory space 'microblaze_0.axi_bram_ctrl_0_bram_block_combined' occupies [0x00000000:0x0000FFFF]
Code segment #2 occupies [0x0000F660:0x00011C63]
make[1]: [post-build] Error 7 (ignored)

 

The linker script is attached but the key sections are copied below:

 

MEMORY
{
mcb3_lpddr_S0_AXI_BASEADDR : ORIGIN = 0x48000000, LENGTH = 0x08000000
axi_bram_ctrl_0_S_AXI_BASEADDR : ORIGIN = 0x00000050, LENGTH = 0x0000FFB0
axi_bram_ctrl_1_S_AXI_BASEADDR : ORIGIN = 0x00010000, LENGTH = 0x00010000
axi_bram_ctrl_2_S_AXI_BASEADDR : ORIGIN = 0x00020000, LENGTH = 0x00008000
AXI_BRAM : ORIGIN = 0x00000050, LENGTH = 0x00027FB0
}

 

.text : {
*(.text)
*(.text.*)
*(.gnu.linkonce.t.*)
} > AXI_BRAM

 

The BMM file is attached as well.  Thanks!!

0 Kudos
hamze
Adventurer
Adventurer
8,995 Views
Registered: ‎11-09-2010
0 Kudos
dshine
Visitor
Visitor
6,206 Views
Registered: ‎11-03-2011

hamze - You are awesome!!!  That thread was the last piece of the puzzle - can't thank you enough.

 

This Xilinx world is truly un-navigable without you forum gurus...

 

Dave

0 Kudos
hamze
Adventurer
Adventurer
6,201 Views
Registered: ‎11-09-2010

 

Yes, with new BMM format you can't use that trick. In my project, whenever it finishs, I change few lines of generated BMM to be in the same format as my old projects. Then I import it to SDK.

I uses ISE 14.7.

 

0 Kudos
Anonymous
Not applicable
6,180 Views
I created an ar for this along time ago. But is still relevant here
http://www.xilinx.com/support/answers/52063.htm
0 Kudos
andrewcb
Explorer
Explorer
5,981 Views
Registered: ‎07-03-2008

I'm glad I found this thread, it's been a useful read.

 

We too found that by modifying the bmm before expoting we could fix the problem. Well almost - the only problem comes when we try to generate an encrypted bitstream (targeting a v6), because bitgen re-creates the bmm during the process and we don't get chance to fix it before bitgen calls data2mem and it all falls over.

 

Has anyone got a fix for this?

 

Andrew

0 Kudos
Anonymous
Not applicable
5,973 Views
0 Kudos
sri_478
Newbie
Newbie
411 Views
Registered: ‎10-12-2020

hello sir,

how can i use 1 Mega byte BRAM in spartan 6 

0 Kudos