06-07-2018 11:54 PM
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.
06-08-2018 03:18 AM
There are 3 ways to populate your BRAM:
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 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:
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?
06-10-2018 11:46 PM - edited 06-10-2018 11:47 PM
@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:
06-11-2018 01:52 AM
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
06-11-2018 03:40 AM - edited 06-11-2018 06:43 AM
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?
06-11-2018 10:01 PM
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?