Building the MIPSfpga SoC "project_linux" from scratch

Home Forums MIPS Insider MIPSfpga Building the MIPSfpga SoC "project_linux" from scratch

This topic contains 5 replies, has 3 voices, and was last updated by  ZubairLK 11 months, 1 week ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
  • #64449


    Over the last few evenings I’ve tried a few different times to walk through the MIPSfpga SoC guides to the point that I should have effectively replicated the design in Vivado 2016.2. I allowed block automation to run for the MIG 7-series, which resulted in an error about “board_if”. After a short search, it was stated on a Digilent forum that the error can be ignored since I’m using the Nexys4 DDR board definition file in my project.

    When I try to validate the resulting design, I end up with an error repeated for every M_AXI to S_AXI connection between an interconnect and a given peripheral (other than the MIG) that states:

    Bus Interface property FREQ_HZ does not match between [the S_AXI] and [the M_AXI at the interconnect].

    Most of the solution’s I’ve found online state that the issue was related to not having a clock generator (and installing one fixes the issue). The error statement above has details stating that the slave side is at 100 MHz and the master is at 10 MHz. My clock generator seems to be configured identically to the one in the 2014.4 version of the project (I opened it in 2014.4 and used it as a reference while I worked), I’m not seeing how this could be the case.

    Has anyone else seen this (even in relation to another problem)?




    IIRC, I have seen this before. The exact solution escapes my memory.

    I think when the Axi interconnect is created, it defaults to 100MHz for whatever reason.
    And we connect the clock afterwards, which causes this. Ideally, it should derive the clock for the block from the source clock.

    The work around is when to click the axi interconnect block, check the properties. There is a freq_hz property of the block (or the clock line). The clock parameter needs to be set to 50MHz. Or whatever your system clock is.

    And I think I also tried simply deleting the axi interconnect block and putting it again.




    Hi Zubair,

    What I was seeing is that the AHBLite to AXI bridge master would default to 100 MHz and the interconnect S00 and all masters would default to 10 MHz. I went every which way I could think of with connecting things up, but it always ended up this way (even swapping the order in which I connected things).

    Last night on a whim I decided to edit my MIPSfpga IP core back in the IP packager. In the original design guide, it says to infer the AHBlite interface, but it never talks about the clock. I figured, why not try the clock?

    I selected HCLK, right-clicked, and selected Auto Infer Single Bit Interface -> Clock. I was then greeted with a Vivado warning that FREQ_HZ was not set. Bingo.

    Right click HCLK again, and select Edit Interface. Then pick Parameters and add FREQ_HZ for whatever value, 50 MHz is more likely correct given the clock generator configuration, so I set it to 50000000. After repackaging and closing the project, I let Vivado upgrade and re-attempt generating output products. No more FREQ_HZ issues with the interconnect, but I did get issues about async reset warnings.

    These async reset warnings about HRESETn and the interconnect can be fixed similarly by marking HRESETn as a reset and then for HCLK, add another attribute pointed back at HRESETn: ASSOCIATED_RESET.

    I’m now left with it complaining about the async reset between the MIG and HRESETn.

    Thanks, and I hope this helps. 🙂



    Hi Thomas. I’m about to migrate to a newer version of Vivado myself and was wondering if the warnings about async reset between MIG and HRESETn is still an issue.

    Also, in your other post you mentioned you updated the MIPSfpga RTL. Did you use MIPSfpga-plus?

    Looking forward to your response and thanks for all your contributions so far.



    I never did get adding an async reset IP core to resolve that issue. Instead I had to stick with directly migrating the 2014 example project to 2016.2 followed by updating the MIPSfpga core, associating its ports correctly (clock to reset, clock to bus, etc. despite what the documentation stated), and then fixing the duplication that the project upgrade caused with the AHBLite to AXI bus.

    That last issue is caused by Vivado sort-of “giving up” as it goes through its IP core upgrades since some of the ports could map to the new AHBLite to AXI bridge and some the versions didn’t match/could migrate without some help (the remapping I described). So because of that, Vivado gives you two half-connected bridges. One is your old one, and the other is a new one. The simple solution I had was to open the project in 2014 and take a screenshot of it so I could compare notes as I “fixed” the upgraded project.

    As for the IP core, we were given a 2.0 beta release during the class along with a couple of updates to it, so that’s the core I used. I have no experience with the -plus core other than initially looking at it because it seemed to have some more progress towards peripheral integration. My professor strongly encouraged, instead, using the core we were supplied, so I did.

    Class has concluded so I’m no longer actively pursuing this project. The code for my OpenEmbedded layer and Repo Manifest are both still up on github if you would like to continue the effort. You can find them here:

    I’ve been told my paper for the class would be published at some point here at the community site. If you would like I can send it over as well. It goes in-depth with the above instructions and how to use the two repos to build the OS.

    So far, my attempts at getting a response from the community to accept a pull request/transfer of those repositories has received no response. I plan to leave them up for the foreseeable future, but it never hurts to fork ’em. 😉

    And for what it’s worth, I actually lost the OS and the build environment over the course of the last week thanks to a botched Bootcamp Assistant (macOS Sierra) first “repairing” my drive to an un-bootable state, then disk utility “repairing” it until it couldn’t make heads or tails of the fusion drive LV. The only thing I could restore was my macOS side which only has a snapshot of the output products from the project (I can post that somewhere too, it’s about 350 MB).



    I would definitely be interested in your paper. Would you mind sending it over to

Viewing 6 posts - 1 through 6 (of 6 total)

Forums are currently locked.