1. Home
  2. Field-Programmable Gate Arrays
  3. Microblaze Sub-Module Adventure

Microblaze Sub-Module Adventure

Tools used: EDK and ISE 6.2 on Win2000. I compiled the Memec HelloWorld project and successfully ran it on their Spartan IIELC reference design board.

With this working project, I changed its properties to a sub-module and exported it to Project Navigator project that had a schematic top level file. I created the library symbol for the sub-module, placed the sub-module and an counter on the schematic and I ran it all the way to Generate Programming File. When I downloaded the bit file, the counter worked, but the Microblaze did not. Even going back to Platform Studio and using the import function did not create a working bit file.

I found by extensive poking around that the Project Navigator does NOT automatically update the BMM file with the newly placed locations of BRAM that holds the Microblaze program. (The export from XPS did add a system.BMM, but that file did not have any placement info--the file just had the names of the BRAM instances and the memory bit positions.) Data2Mem needs the placement information to create a new download file. I found that I could use the FPGA editor in Project Navigator to find out where the last PAR operation put the BRAMs. I created a new BMM file from the system.BMM and included the placement info. Specifying this BMM file with the .ELF allowed Data2Mem to create a WORKING Microblaze sub-module bit file. You can manually run Data2Mem in the Project Navigator or use the dialog in XPS (which calls Data2Mem in the script) as long as you supply the correct BMM file.

A valid line in a BMM text file for Data2Mem is: bram_1mb/bram_1mb/ramb4_s2_s2_0 [31:30] PLACED = R3C0;

The BMM files exported to Project Navigator by XPS did not have the field starting with "PLACED.." After going from PAR to bit file creation, the BMM file still did not change, even though the subsequent Data2Mem procedure to combine the ELF data requires placement info in the BMM. It is quite reasonable not to supply any placement before PAR, because PAR is allowed to move things around, but the final placement info should be extracted and updated into the BMM file. In this example, I manually added the placement information.

I have seen a few posts regarding this problem. Is there a button or procedure in Project Navigator to automatically extract new BRAM locations and update the BMM file? Of course I already have a work-around, like forgetting about sub-modules and keeping the project exclusively in XPS !

Reply to
Morris Ho
Loading thread data ...

I'm stil working with EKD3.2 and ISE5.2 but for me it the following works perfectly fine:

I add the .bmm file to the "sources" in the project navigator tree ... after place&route I've got a new .bmm file in my ise-directory with all the placement included ...

bye, Michael

Reply to
Michael Schöberl

Probably, your hieararchy path in the BMM doesn't correctly reflect your submodule path. In submodule flow, platgen generates a system_stub.bmm instead of the system.bmm. The system_stub.bmm contains hierarchy path of the submodule in your system.

In xps, selecting "Project Options" -> "Hierarchy & Flow", you can submodule flow plus add the instance name of the instantiate submodule in your schematic toplevel. This written to system_stub.bmm

It's bitgen > Tools used: EDK and ISE 6.2 on Win2000. I compiled the Memec HelloWorld

--
/ 7\'7 Paulo Dutra (paulo.dutra@xilinx.com)
\ \ `  Xilinx                              hotline@xilinx.com
/ /    2100 Logic Drive                    http://www.xilinx.com
\_\/.\ San Jose, California 95124-3450 USA
Reply to
Paulo Dutra

Thanks for the hint Paulo.

I did follow the Project Options flow as you suggested the first time around. The only time the sub-module flow in Nav created a BMM file with BRAM locations is when I selected the sub-module (as top design) only and did the full implementation. My top level schematic was out of the picture using this method, so that implementation with the sub-module as a the new top level design was not useful.

I read that Xilinx only allows association of the BMM file with the top level design. Trying to move the BMM file from the sub-module to associate with the schematic top level design only resulted in a BRAM error, which I expected.

My understanding of a sub-module is for instantiation in a top level design. Since the BMM with placements is generated only for a top level design, I would never get a BMM file with placements with my schematic top level design, since the BMM file is associated with a sub-module. So my conclusion is that XPS allows exporting a sub-module to an existing top level design in Nav, but Nav is inconsistent in that it won't generate the placement vesion of the BMM file since the sub-module is by definition not the top level design. If you have a sample project with a XPS submodule and bitgen generated BMM file with placements, I would like to see it. Xilinx gave up on my web case 527286.

and

BRAM

had

that

last

system.BMM

You

XPS

BMM

field

BMM

to

allowed to

placement

locations

!
Reply to
Morris Ho

Without being specific on your error messages, I can't really help u.

But, more than likely you're getting an error in ngdbuild with the associated path in the BMM not matching your hierarchy path.

To find the known hierarchy path. Run the design without the BMM in iSE. Once processed through par, bring the design up in FPGA editor. You can find BRAM components with instance paths.

Your BMM needs to have the hierarchy path as identified > Thanks for the hint Paulo.

--
/ 7\'7 Paulo Dutra (paulo.dutra@xilinx.com)
\ \ `  Xilinx                              hotline@xilinx.com
/ /    2100 Logic Drive                    http://www.xilinx.com
\_\/.\ San Jose, California 95124-3450 USA
Reply to
Paulo Dutra

I'm still using EDK3.2, but have had similar problems and maybe that will help you:

When you set the hierarchy to "sub-module" in XPS, you have to give it the name of the top instance. This name is used in the original BMM created by XPS to tell bitgen the complete path to the BRAMs. XPS also creates an example top-level-VHDL-file that is supposed to show you how to declare and instantiate the module with the MicroBlaze in it (something like "system_stub.vhd"). When you export to "Project Navigator", a new project is created with system_stub.vhd as the top-level-design file, but neither the UCF nor the BMM are added to the project sources, you have to do that manually (theoretically, ngdbuild should find the BMM automatically, but that never works for me). If you don't add the BMM, it is not updated (you normally get a new BMM like system_bd.bmm WITH the information on the placement, not an updated BMM), and then you get exactly the problems you mentioned.

But if you do add the BMM as a source to the project, it still doesn't work quite right: In EDK3.2 the top instance name you enter in the project settings is *NOT* transferred to the VHD-file. I.e. if you do copy&paste from system_stub.vhd, the instance name in your top-level does not match the instance name in the BMM file, hence "ngdbuild" just gives you an error about not being able to find the BRAMs and aborts. Same should apply if you do it with schematics.

So, this might help you:

a) add the BMM as a source to your project in Project Navigator b) make sure the instance name for the module with the MicroBlaze matches the name you specified in EDK before exporting. I've never worked with schematics, but I'm sure you can specify the instance name when you add a component.

What you should get in the end is not an updated BMM, but instead a completely new one with "_bd" appended to the name, and that is the one you have to import in XPS.

cu, Sean

Reply to
Sean Durkin

Right on. Thanks for the information Sean. You got it to work with EDK

3.2. I got it to work for EDK6.2 with help from snipped-for-privacy@xilinx.com

Here was my final comment to Xilinx on the subject:

--------------------------- OK. I did the following:

  1. changed the microblaze instance name to "xlxi_1" in top.sch
  2. removed system.bmm from the sub-module group(XPS placed it there)
  3. added system_stub.bmm associate with Top.sch
  4. added "xlxi_1" to the BRAM heirarchy path in each BRAM entry of system_stub.bmm
  5. selected Top.sch as top design and ran implementation.
  6. finally got a system_stub_bd.bmm with placements in the XPS implementation folder!

Well, that was a lot of extra work and I wished the process was documented better. The issue with XPS not exporting the right bmm file with the correct top level file is still there, but I know what do do now.

Thank you for your time. I believe the issue can be "closed" now. Morris.

--------------------------

Summary: In exporting to Project Navigator, XPS does not know what you will call your Microblaze sub-module instantiated in the top design. Hence it can't put the hierarchy path in the BMM file. Then XPS does two things wrong: it associates the wrong (system.bmm) file with the sub-module instead of the specified top level design. Once you have the instance name (you can assign this) of the sub-module in the top design, then you have to find system_stub.bmm and put the name of the sub-module instance on every text line in the BMM file where there is a BRAM specified. Then you have REMOVE the BMM file associated with the sub-module (XPS did this automatically) and ADD the system_stub.bmm (with your manually-added hierarchy paths) to the top design.

Interesting notes: I believe I received two replies from Germany. Xilinx claims to have sold 10,000 copies of EDK. I did not see this issue addressed in the Xilinx answer database. I ran into this problem within 5 days of my evaluation of EDK. A Memec FAE told me to just work in the XPS environment.

Morris

BRAM

Reply to
Morris Ho

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.