cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tim_severance
Scholar
Scholar
6,299 Views
Registered: ‎03-03-2017

Vivado/SDK 2018.3 download.bit not running Microblaze

I have a Kintex-7 325T project that worked just fine in Vivado/SDK 2018.1 but when I reimplemented in 2018.3 and rebuilt the application and tried to program the FPGA with the application.elf built into the download.bit Microblaze never starts and I never get any printf outputs out of the UART terminal output.   But, if I program the FPGA into bootloop and the manually run the application using Application->Run-As->Launch on Hardware (System Debugger) then it seems to work find.

How can I get the application to run out of download.bit?   Is there some new setting in Vivado/SDK 2018.3 that I may be missing?

Thanks.

Tim

0 Kudos
25 Replies
luminal101
Participant
Participant
6,266 Views
Registered: ‎02-10-2017

I'm having the same issue since upgrading to 2018.3. The S/W works fine when launching via the system debugger. But when using 'Program FPGA' (and choosing the generated .elf file for the software configuration) then the Microblaze doesn't seem to start.

I was using Vivado/SDK 2018.2.2 before without this issue. So I repeat Tim's question: What changed in 2018.3 that we seem to miss?

tim_severance
Scholar
Scholar
6,247 Views
Registered: ‎03-03-2017

Fortunately I do not necessarily need to use 2018.3 so I am reverting back to 2018.1 until there is a solution to this problem.

Tim

0 Kudos
toulgaridis
Participant
Participant
6,228 Views
Registered: ‎12-04-2015

 

I shared a post yesterday reporting the same issue: link

It seems like there is a bug in .mmi file generation, but I am not sure yet.

If you find any solution please let me know.

ghhunter
Visitor
Visitor
6,196 Views
Registered: ‎06-10-2017

Unfortunately, I am facing the same problem. And I have always suspected that some settings are not properly configured.

toulgaridis
Participant
Participant
6,161 Views
Registered: ‎12-04-2015

We have found a solution, but it is sub-optimal. You have to edit the generated .mmi file:

I assume that you see the following pattern in the .mmi file (ignore the "<AddressSpace Name= ... "), using 32-bit BRAM Interface:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Product Version: Vivado v2018.3 (64-bit)              -->
<!-- SW Build 2405991 on Thu Dec  6 23:38:27 MST 2018  -->
<!--                                                         -->
<!-- Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.   -->
<!-- Dec  7 2018                                             -->
<!--                                                         -->
<!-- This file is generated by the software with the Tcl write_mem_info command. -->
<!-- Do not edit this file.                                                      -->

<MemInfo Version="1" Minor="6">
  <Processor Endianness="Little" InstPath="bd_i/SOFT_MB_SUB_SYS/SOFT_MB">
    <AddressSpace Name="bd_i_SOFT_MB_SUB_SYS_SOFT_MB.bd_i_SOFT_MB_SUB_SYS_SOFT_MB_LOCAL_MEMORY_dlmb_bram_if_cntlr" Begin="0" End="131071">
      <BusBlock>
        <BitLane MemType="RAMB36" Placement="X14Y24">
          <DataWidth MSB="0" LSB="0"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>
        <BitLane MemType="RAMB36" Placement="X17Y22">
          <DataWidth MSB="1" LSB="1"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>
        <BitLane MemType="RAMB36" Placement="X16Y26">
          <DataWidth MSB="2" LSB="2"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>

.....

        <BitLane MemType="RAMB36" Placement="X15Y18">
          <DataWidth MSB="6" LSB="6"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>
        <BitLane MemType="RAMB36" Placement="X16Y23">
          <DataWidth MSB="7" LSB="7"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>

.....

        <BitLane MemType="RAMB36" Placement="X14Y22">
          <DataWidth MSB="29" LSB="29"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>
        <BitLane MemType="RAMB36" Placement="X15Y19">
          <DataWidth MSB="30" LSB="30"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>
        <BitLane MemType="RAMB36" Placement="X15Y22">
          <DataWidth MSB="31" LSB="31"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>
      </BusBlock>
    </AddressSpace>

 I am referring to the Microblaze Local BRAM ONLY. In this configuration the BitLanes have the following order: 0, 1, 2, ... , 29, 30, 31.

The aforementioned order seems to cause the swapping problem I described in this thread.

So, you have to manually cut and paste the <BitLanes> in order to achieve the following order: 7, 6, ... , 2, 1, 0, 15, 14, ... , 9, 8, 23, 22, ... , 17, 16, 31, 30, ... , 25, 24.

It is important to maintain the "Placement=..." of a specific BitLane with the bit it corresponds to!

An example of an edited .mmi file would look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Product Version: Vivado v2018.3 (64-bit)              -->
<!-- SW Build 2405991 on Thu Dec  6 23:38:27 MST 2018  -->
<!--                                                         -->
<!-- Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.   -->
<!-- Dec  7 2018                                             -->
<!--                                                         -->
<!-- This file is generated by the software with the Tcl write_mem_info command. -->
<!-- Do not edit this file.                                                      -->

<MemInfo Version="1" Minor="6">
  <Processor Endianness="Little" InstPath="bd_i/SOFT_MB_SUB_SYS/SOFT_MB">
    <AddressSpace Name="bd_i_SOFT_MB_SUB_SYS_SOFT_MB.bd_i_SOFT_MB_SUB_SYS_SOFT_MB_LOCAL_MEMORY_dlmb_bram_if_cntlr" Begin="0" End="131071">
      <BusBlock>
        <BitLane MemType="RAMB36" Placement="X16Y23">
          <DataWidth MSB="7" LSB="7"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>
        <BitLane MemType="RAMB36" Placement="X15Y18">
          <DataWidth MSB="6" LSB="6"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>

.....

        <BitLane MemType="RAMB36" Placement="X17Y22">
          <DataWidth MSB="1" LSB="1"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>
        <BitLane MemType="RAMB36" Placement="X14Y24">
          <DataWidth MSB="0" LSB="0"/>
          <AddressRange Begin="0" End="32767"/>
          <Parity ON="false" NumBits="0"/>
        </BitLane>

.....

    </AddressSpace>

 

For more information you can read this wiki.

luminal101
Participant
Participant
6,104 Views
Registered: ‎02-10-2017

I can confirm that this solution works. Thank you very much for sharing!

But then why is the .mmi file messed up in the first place? Is this simply a bug?

 

tim_severance
Scholar
Scholar
6,092 Views
Registered: ‎03-03-2017

Xilinx, any response??

0 Kudos
ghhunter
Visitor
Visitor
6,076 Views
Registered: ‎06-10-2017

Thank you!  I have verified that this modification works. It would be nice to be able to modify the code that generates the .mmi file. This can reduce the probability of errors when manually modifying large .mmi files. At the same time, it can save time. It took more than 10 minutes to modify the 512kb .mmi file this afternoon. I hope that Xilinx can update the patch to fix this problem.

0 Kudos
tim_severance
Scholar
Scholar
6,061 Views
Registered: ‎03-03-2017

Is it just me, or does it seem like Xilinx is responding less and less to these forums?   It seems like a year ago I was always getting responses within a day, but now I almost never get a response from Xilinx.

0 Kudos
sitting
Voyager
Voyager
5,828 Views
Registered: ‎05-04-2014

I try this workaround and it works for me. Thank you very much. 

0 Kudos
stephenm
Xilinx Employee
Xilinx Employee
5,816 Views
Registered: ‎09-12-2007

This is a known issue, and a change request is filed to address this issue

duthv
Xilinx Employee
Xilinx Employee
5,645 Views
Registered: ‎09-14-2007

Hi,

Unfortunately as was reported earlier, this is indeed an issue that snuck in.. We have identified the problem and are working on a patch to resolve this issue ASAP. Please watch this forum for an update when the patch is made available.

 

Thanks for the patience and understanding

 

Thanks

Duth

 

stefana
Xilinx Employee
Xilinx Employee
5,091 Views
Registered: ‎10-08-2010

The tactical patch for Vivado 2018.3 is now available: AR# 71948.

tim_severance
Scholar
Scholar
5,046 Views
Registered: ‎03-03-2017

Thank you for getting this resolved.   If my Vivado->About Vivado shows the below window does this mean I got the patch installed correctly?

2019-02-18 09_26_59-Vivado 2018.3_AR71948.png

Thanks.

Tim

stefana
Xilinx Employee
Xilinx Employee
5,026 Views
Registered: ‎10-08-2010

Yes, that looks correct. I get the same here after installing the patch.

 

diqua
Observer
Observer
4,905 Views
Registered: ‎06-08-2018

You saved me time and a headache.

Tank you!

diego

0 Kudos
4,841 Views
Registered: ‎05-29-2018

This is a scandal!

How can Xilinx release such a version?

Are there no test before release?

0 Kudos
4,833 Views
Registered: ‎05-29-2018

We worked with Version 2017.2 and there was no problem with MMI file export to SDK, now it does not work anymore.

When I type the command manual it does also not work!

 

Tcl concole:

write_mem_info system.mmi

ERROR: [Common 17-69] Command failed: Failed to create the: /home/user/system.mmi The design contains processors. Verify processor instances and connectivity.

0 Kudos
m3atwad
Voyager
Voyager
4,724 Views
Registered: ‎05-25-2016

I had this same problem.  Thank you for resolving this!

0 Kudos
diqua
Observer
Observer
4,699 Views
Registered: ‎06-08-2018

This works fine. It would be nice to have the whole patches list in https://www.xilinx.com/support/download.html page.
0 Kudos
diqua
Observer
Observer
4,699 Views
Registered: ‎06-08-2018

Plese put the whole patches list in https://www.xilinx.com/support/download.html page.
0 Kudos
clutch12
Explorer
Explorer
4,064 Views
Registered: ‎06-05-2014

@stefana this patch works great for 2018.3. However, it seems this did not make it to 2019.1, or at least I'm having issues with 2019.1. Am I the only one? Or, will there be a patch that can be released for 2019.1?

0 Kudos
stefana
Xilinx Employee
Xilinx Employee
4,046 Views
Registered: ‎10-08-2010

The patch is only for 2018.3, and should not be necessary in 2019.1. The issue has been solved and it should work out of the box. I have tested the functionality successfully with SDK 2019.1.

If you see any issues, let us know.

stephenm
Xilinx Employee
Xilinx Employee
4,039 Views
Registered: ‎09-12-2007

Can you try without the patch installed? Do you see the same issue? If so, can you share the HDF file ( with bit file included) please

clutch12
Explorer
Explorer
4,025 Views
Registered: ‎06-05-2014

based on the feedback that it *should* work I started a completely new test design and it did indeed work. 

I wonder if upgrading the existing 2018.3 design was the issue. 

0 Kudos