cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
moon5756
Explorer
Explorer
394 Views
Registered: ‎09-05-2015

Conceptual question about how microblaze is running main.c

Jump to solution

Hi all, I need some conceptual clarification on how microblaze is running main.c file.

 

Let's say I created a simple design that consists of BRAM and microblaze.

Then, the step would be

1)create bitstream

2)download bitstream on FPGA

3)run main.c file on SDK to read certain address of BRAM.

 

 

The bitstream generated on my PC(Vivado) is loaded via JTAG to FPGA.

I have a question on 3). If I build the project on SDK, it generates .elf file and it's saved on the PC.

If I click "debug as hardware," what's the exact workflow of microblaze that runs main.c? 

How does .elf file is loaded on microblaze?(through JTAG?)

And how does "printf("bram data=%d", bram_data)" print bram_data on SDK's terminal? Does the output of the print statement migrate through UART?

 

Hope I am not horribly not on the same page with others.

Thanks in advance.

 

 

0 Kudos
1 Solution

Accepted Solutions
ibaie
Xilinx Employee
Xilinx Employee
330 Views
Registered: ‎10-06-2016

Hi @moon5756 

You are not too far from the reallity. First of all I would recommend to take a look to UG898 chapter 4 whre microblaze processor usage on embedded design is explained.

As a resume the idea when you download the application to the target with the debugger is the following one:

  1. Create a bitstream with the embedded processor inside. By default the MB local memory is loaded with a bootloop.elf file that just keeps the processor looping when the reset is released.
    1. Vivado provides a way to merge an existing ELF file into your bitstream (associate ELF file) in the way that processor start executing the application straight after releasing the reset signal to the processor
  2. Download bitstream through JTAG. This is done using the System Debugger and just programs the bitstream into the FPGA. Depending the design if the clock is provided and reset deasserted then the processor will start running whatever finds in the LBRAM (either bootloop or any ELF file that has been associated)
  3. Download ELF file. The debugger can be used to download an application into memory through JTAG. Usually the debug feature within SDK will also reset processor and set the PC (program counter) in the beginning of your application so you can start running it and debug.
  4. Terminal. SDK integrates a serial console terminal option that can be used to monitor the serial port where the target is priting messages. You could use any other terminal program out of SDK as well.

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.

View solution in original post

1 Reply
ibaie
Xilinx Employee
Xilinx Employee
331 Views
Registered: ‎10-06-2016

Hi @moon5756 

You are not too far from the reallity. First of all I would recommend to take a look to UG898 chapter 4 whre microblaze processor usage on embedded design is explained.

As a resume the idea when you download the application to the target with the debugger is the following one:

  1. Create a bitstream with the embedded processor inside. By default the MB local memory is loaded with a bootloop.elf file that just keeps the processor looping when the reset is released.
    1. Vivado provides a way to merge an existing ELF file into your bitstream (associate ELF file) in the way that processor start executing the application straight after releasing the reset signal to the processor
  2. Download bitstream through JTAG. This is done using the System Debugger and just programs the bitstream into the FPGA. Depending the design if the clock is provided and reset deasserted then the processor will start running whatever finds in the LBRAM (either bootloop or any ELF file that has been associated)
  3. Download ELF file. The debugger can be used to download an application into memory through JTAG. Usually the debug feature within SDK will also reset processor and set the PC (program counter) in the beginning of your application so you can start running it and debug.
  4. Terminal. SDK integrates a serial console terminal option that can be used to monitor the serial port where the target is priting messages. You could use any other terminal program out of SDK as well.

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.

View solution in original post