cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
3,062 Views
Registered: ‎09-28-2017

Standalone ELF association problem

Jump to solution

Hello,

 

I have just started working on a project with microblaze. I have tried some of the example codes provided by Xilinx and they all seem to work when programmed and run from Xilinx SDK. However, when I try to associate the compiled elf file in my Vivado project, it doesn't work. 

 

I do the following:

1) Add ELF file found in the Release folder of the SDK files to the vivado project.

2) Right clicking on the ELF file and associating it with the microblaze in the project.

3) Run the implementation and bitstream generation.

4) Program the board

 

I do not get any errors during these processes. The hardware programs successfully but nothing runs.

 

Am I missing a step? 

 

Many thanks,

Samer

 

Using Vivado 15.4

Hardware: Digilent Genesys 2 (Kintex 7)

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Visitor
Visitor
4,266 Views
Registered: ‎09-28-2017

Thank you all for the replies.

 

I have actually managed to solve the problem by choosing the "ELF/MEM File to Initialize in Block RAM" to the generated ELF file, as shown in the attached screenshot.

 

elfmem.png

 

The diagram above pops up when the Program FPGA button is clicked from the SDK. Previously, it was set to "bootloop" which now explains why the processor didn't run until code/elf is loaded from the SDK. What I don't understand is by doing this, programming the board from Vivado with the ELF file now works! Note that the bit file I am using to program the FPGA is the one generated by Vivado and not by the SDK.

 

Of course my problem is solved now but any insight on the link between changing the Block RAM initialization in the SDK and programming in Vivado with ELF association will be much appreciated.

 

Thanks again!

View solution in original post

7 Replies
Highlighted
Moderator
Moderator
3,024 Views
Registered: ‎09-12-2007
You could test your elf using the debugger. You can launch sdk. Right click on your app, debug -> debug as. In debug config, create a new system debugger debug config. Then apply and debug. Can you step through your code?

You can verify if the memory was updated by reading its contents in XSCT

connect
fpga -f download.bit
targets
targets X
Where X is the microblaze
mrd 0x00000000 0x10

This will dump the first 16 locations. This assumes the boot vector for the mb is at 0x0 ( which it is by default)

Issue could be with your app, or your microblaze itself. Is the microblaze clocked, reset correctly. You can also simulate. Here, you can use the simulation clock and reset ip from ip catalog ( in place of your existing clock and reset), the run simulation. In simulation, you can view the microblaze signals to trace the pc and instruction address.

0 Kudos
Highlighted
Visitor
Visitor
3,000 Views
Registered: ‎09-28-2017

Thank you for the reply.

 

As I have said in my original post, I have no problems running the code on the hardware from the SDK. It is only when I copy the ELF file from the SDK and associate it with the microblaze in Vivado.

 

Does the microblaze expect some signal to make it run or start? 

0 Kudos
Highlighted
Moderator
Moderator
2,952 Views
Registered: ‎09-12-2007

Ok, the post was for the benefit of all users reading on how you could debug this kind of issue. I also mentioned reading the memory in the debugger to show how the brams have been populated. Have you tried this? this will give you a better understanding on what has gone wrong. 

0 Kudos
Highlighted
Explorer
Explorer
2,938 Views
Registered: ‎06-19-2015

Hi @smkilani

 

Pls refere to This Post

 

Thanks Madhu

0 Kudos
Highlighted
Visitor
Visitor
4,267 Views
Registered: ‎09-28-2017

Thank you all for the replies.

 

I have actually managed to solve the problem by choosing the "ELF/MEM File to Initialize in Block RAM" to the generated ELF file, as shown in the attached screenshot.

 

elfmem.png

 

The diagram above pops up when the Program FPGA button is clicked from the SDK. Previously, it was set to "bootloop" which now explains why the processor didn't run until code/elf is loaded from the SDK. What I don't understand is by doing this, programming the board from Vivado with the ELF file now works! Note that the bit file I am using to program the FPGA is the one generated by Vivado and not by the SDK.

 

Of course my problem is solved now but any insight on the link between changing the Block RAM initialization in the SDK and programming in Vivado with ELF association will be much appreciated.

 

Thanks again!

View solution in original post

Highlighted
Moderator
Moderator
2,908 Views
Registered: ‎09-12-2007

The Associate ELF flow will use the "memdata" flow. Here the init_strings are updated in the Vivado project. 

SDK uses updatemem, this uses the bitstream and an MMI file (the MMI is exported in the HDF from Vivado). 

 

The advantage of using updatemem over memdata is that you can update the BRAM "on the fly" without having to implement in Vivado.

 

Question remains, why does updatemem work and associate ELF in Vivado. Do you see any warnings related to memdata in Vivado?

0 Kudos
Highlighted
Observer
Observer
2,389 Views
Registered: ‎01-06-2016

Hi!

 

I had the same problem. In my case moving from Vivado 2017.2 to Vivado 2017.3 has helped to resolve the issue.

0 Kudos