cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
fpgae
Observer
Observer
2,727 Views
Registered: ‎05-29-2018

Problem with mircoblaze: Memdata 28-203

Jump to solution

Hello,

 

I have a block design containing a Microblaze for controlling external devices through SPI, now when I synthesized and implemented my design, I got a strange critical warning when opening the implemented design:

[Memdata 28-203] ADDRESS_SPACE or ADDRESS_MAP tag name top_i_ctrl_mb was not found. Some data may have not been translated.

If this is associated with the Microblaze, then this is the wrong name from a previous project which I have used as base structure. I could not find any ADDRESS_SPACE or ADDRESS_MAP to rename. Where are these tags located?

The resuling bitstream loads into the FPGA but seems not to be working (e.g.: my LEDs which should toggle are not toggeling (they are controlled by the Microblaze)). Additionally, the debug cores (using System ILA) are detected but Vivado Hardware manager cannot connect to them and loses the whole connection to the board.

 

I am using Vivado 2018.1, all IPs used in my block design are up to date.

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
fpgae
Observer
Observer
2,703 Views
Registered: ‎05-29-2018

I found my problem, the clock lanes were not connected with the FPGA in the expected way. I switched to another clock source and Microblaze is now running.

View solution in original post

0 Kudos
10 Replies
stephenm
Xilinx Employee
Xilinx Employee
2,699 Views
Registered: ‎09-12-2007

There are 3 ways to populate your BRAM:

  • memdata
  • updatemem
  • via the SDK debugger

memdata:

When the BRAM is added via the Block Design, there will be metadata added to the RTL code that the tools will use to populate the BRAM. The memdata uses the ELF added via the tool -> Associate ELF GUI in the Vivado to place into BRAM. By default, there is a bootloop ELF added here. There is metadata for the processor -> bram controllers -> bram. The issue is, if this chain is broken you will see issues similar to what you are seeing. 

 

updatemem:

Updatemem is an SDK tool, that is used to populate the BRAM using the MMI file. The MMI file is built using the same metadata described above.The tools will automatically create the MMI for all memory mapped memory controllers. Yu can also manually create this using the TCL command below. However, I suspect you will see errors here too:

write_mmi_info test.mmi

 

Via the SDK debugger:

Here the SDK debugger uses the address of the BRAM controller to write to the BRAM.

 

So, with this in mind. How are you adding your memory system to the Block Design? Is it external to the BD, is it added via a custom IP? ect.. Can you send a screenshot please?

 

 

 

0 Kudos
fpgae
Observer
Observer
2,644 Views
Registered: ‎05-29-2018

@stephenm: I associate the ELF file in Vivado block design directly. Additionally, I have a makefile for the Mircoblaze software code using updatemem, so that I can update an existing bitstream very fast.

The association in Vivado is done directly on the Microblaze block to which BRAM is connected.

Strange is that when I rerun everything today, there was no such critical warning. Also not when I opened the implemented design, no warning. I suspect a problem with my clock, the clock generator never reports a locked state.

 

The relevant part of the BD is shown below:

Bildschirmfoto von »2018-06-11 07-10-33«.png

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
2,634 Views
Registered: ‎09-12-2007

This looks fine. Is the BRAM getting populated? Can you open the implemented design, then do a ctrl + f, and search for the brams, and look at the bram cell properties to see if they are populated

0 Kudos
fpgae
Observer
Observer
2,630 Views
Registered: ‎05-29-2018
I found 4 entries for lmb_bram. They are all marked as placed in the cell properties.
0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
2,624 Views
Registered: ‎09-12-2007

I mean the init_xx to see if there is data here. If these are populated, then memdata worked. If not, then we have an issue

0 Kudos
fpgae
Observer
Observer
2,617 Views
Registered: ‎05-29-2018

Yes, I can see such entries, but they are named noinit. Is there an Option to see if they are actually initialized with the ELF file content for the Microblaze?

Bildschirmfoto von »2018-06-11 12-38-58«.png

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
2,603 Views
Registered: ‎09-12-2007

I mean can you check the cell property for the BRAM to see if they are populated. For example:

bram_cell.PNG

fpgae
Observer
Observer
2,590 Views
Registered: ‎05-29-2018

Sorry, I failed to check this. The local memory RAMB36E1 cells all have content listed in the cell properties. I think that the ELF was correctly uploaded into the BRAM. Also, I resynthesized and reimplemented everything, the critical warning did not occur again.

I will check the clock source again today, because I fear that this is the error.

Just for my Information: Parts of the FPGA which are not using my clock (I use an external clock from which I derive my internal clocks using clock generator IP) are running as long as the FPGA gets power, is this correct?

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
2,576 Views
Registered: ‎09-12-2007
Yes
0 Kudos
fpgae
Observer
Observer
2,704 Views
Registered: ‎05-29-2018

I found my problem, the clock lanes were not connected with the FPGA in the expected way. I switched to another clock source and Microblaze is now running.

View solution in original post

0 Kudos