Microblaze Sub-Module Adventure

[Morris Ho]

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 !

 

[Michael Schöberl]

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 !

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

 

[Paulo Dutra]

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 in the iSE flow, that writes out system_stub_bd.bm
that contains the placement info of the blockrams. The
system_stub_bd.bm by data2mem to initialize your bitstream.

Morris Ho wrote:

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 !

--
/ 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

 

[Morris Ho]

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.

"Paulo Dutra" <paulo.dutra@xilinx.com> wrote in message
news:408470CE.5030802@xilinx.com...

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 in the iSE flow, that writes out system_stub_bd.bm
that contains the placement info of the blockrams. The
system_stub_bd.bm by data2mem to initialize your bitstream.

Morris Ho wrote:
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
!




--
/ 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

 

[Paulo Dutra]

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 in
FPGA editor.

Morris Ho wrote:

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.

--
/ 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

 

[Sean Durkin]

Morris Ho wrote:

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.
[...snip...]
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.

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

 

[Morris Ho]

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 paulo@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


"Sean Durkin" <smd@despammed.com> wrote in message
news:c685g2$912lu$1@uni-berlin.de...

Morris Ho wrote:

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.
[...snip...]
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.

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