cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
maty
Contributor
Contributor
853 Views
Registered: ‎06-27-2019

Debugging/Running 4+ Microblazes

Good morning,

I have a a design where I have 8 microblazes that live in different sections of RAM, however they all share the same library. The microblazes reset vector (set through Vivado) live in the following,

MB1 = 0x20000000

MB2 = 0x20080000

MB3 = 0x20100000

MB4 = 0x20180000

...

MB7 = 0x20380000

 

Now in the SDK. Inside each of the Microblaze linker script I double and tripled checked and their base address are all correct. For the DDR size I set them all to 0x00080000 (the offset for each MB). This all seem to make sense.

 

The problem arises when I try to debug them. For some odd reason I cannot debug the last 4 Microblazes. The first 4 work perfect, but never the last 4, no matter what I try. Is there something that I am missing.

Couple things to note. The DP, DC, and IC from each Microblaze is going to HP0 (I had HP0 and HP1 at one point, but removed HP1, just in case). The XSCT console sets the PC to the right location and downloads the right .elf file to each Microblaze.

 

Help please...

MDM.PNG
MB Memory.PNG
Debug Cfg.PNG
Debug.PNG
0 Kudos
8 Replies
maty
Contributor
Contributor
838 Views
Registered: ‎06-27-2019

One more image to add to this madness.

On the top left Microblaze #4 is stopped at 0x00000000, which is wrong. On the top right, in the XSCT Console, Slot4 (Microblaze 4) was set to PC 0x20200000. And in the bottom, looking at address 0x20200000, it al looks good. Why was Microblaze #4 PC not stopped at 0x20200000? How did it get to 0x00000000?

Full picture.PNG
0 Kudos
maty
Contributor
Contributor
729 Views
Registered: ‎06-27-2019

Bump. Still need some assistance if anyone has any insight on what could be causing this issue.

0 Kudos
sadanan
Xilinx Employee
Xilinx Employee
715 Views
Registered: ‎10-21-2010

Hi @maty,

Are the last 4 MBs area optimized? If so, can you change the MB config and check. Some versions of area optimized MBs have problems with PC access

0 Kudos
maty
Contributor
Contributor
711 Views
Registered: ‎06-27-2019

Hello,

All 4 MB have identical configurations (except the reset vector). I just checked and all 8 of them have performance to be optimized, not area. I created 1 hierarchy and then copy and pasted it 7 times.

Something I can add to this. All 8 of the MB execute code from the upper half of RAM, 0x20000000+. The DC and IC lines have access from 0x20000000 to 0x3FFFFFFF. The lower half of RAM is where the Zynq core and the MB share uncached data.

0 Kudos
kennard
Observer
Observer
680 Views
Registered: ‎10-03-2019

I'm not certain, but I think I read somewhere in the XSDB or MDM (MicroBlaze Debug Module) documentation that the system debugger only supports up to 4 MicroBlazes in a single design.

0 Kudos
maty
Contributor
Contributor
653 Views
Registered: ‎06-27-2019

@kennard I cannot find this information. However, if I try to only debug MB4 or MB4 through MB7, they still reset to vector 0x00000000. That was one of the first things I tried, debugging the Zync core, MB1, and MB4. MB1 and Zynq wored perfectly, MB4 was off in the weeds.

0 Kudos
maty
Contributor
Contributor
632 Views
Registered: ‎06-27-2019

Found this piece of information,

https://www.xilinx.com/support/answers/21108.html

0 Kudos
maty
Contributor
Contributor
546 Views
Registered: ‎06-27-2019

So I started over to see exactly what broke the debugging and this is how far I got.

Here is the .tcl file with minimal IP blocks. Adding 6 GPIO blocks broke the debugging. I was able to debug all 6 Microblazes until I added 6 GPIO blocks.

Can someone try it out and let me know if it works for them? And does someone know why this keeps happening?

0 Kudos