How do I disable Microblaze on-chip hw debug

"John" schrieb im Newsbeitrag news: snipped-for-privacy@visitech-jd.visitech.local...

there is no disable and its also not needed, you can leave the MDM component in the system it doesnt do anything if not accessed by XMD, so it doesnt matter. After cold start the Microblaze starts from the initialized BRAMs. If you are sure you dont need the MDM anymore just remove the MDM core instance and related signals and resynthesize in XPS

antti

Thanks Antti,

I am very fresh with processor capabilties in FPGA's and I still don't understand how I can make my program "free running". After I download the program it seems to stop - probably at a breakpoint. I need to run XMD to get beyond this breakpoint. I have tried to set set C_DEBUG_ENABLE = 0 and C_NUMBER_OF_PC_BRK = 0 in the MicroBlaze parameter settings but still the program does not seem to run. Any further suggestion anyone?

John

På Tue, 12 Apr 2005 12:16:10 +0200, skrev Antti Lukats :

"John" schrieb im Newsbeitrag news: snipped-for-privacy@visitech-jd.visitech.local...

in order to have stand-alone system you can not use 'download' the program must be located completly in the on chip BRAM's, so you use XPS "update bitstream" this will merge the software (.ELF file) and the FPGA hardware (.BIT), then you program the FPGA with the result. And microblaze starts..

you must have marked your software application 'MARK to init BRAMs' in XPS !!

if your application does not fit into BRAM, (XPS will warn you if that is the case) then you need some bootloader and nonvolatile media in order to initialiaze any other memories connected to the system. This may indeed be painful as you need custom linker scripts, etc. etc..

antti

I feel more and more stupid here, because I cannot figure this out. I have now followed your steps but still no running microblaze.

These are the steps I am following: First I build a XPS system, then I export this. I do some modification to the system_stub.vhd with regard to instatiated buffers then I run a P&R with other VHDL. Finally I import the result into XPS.

I have "Mark to Initialize BRAMs" set then I run update bitstream (as you said). I download the resulting bit file using IMPACT. The VHDL part of the system is running but the microblaze seems to be stuck. Something I miss now?

På Tue, 12 Apr 2005 13:02:15 +0200, skrev Antti Lukats :

"John" schrieb im Newsbeitrag news: snipped-for-privacy@visitech-jd.visitech.local...

you should never edit the system_stub.vhd, there is no need also

and its better not to import export but have the ISE project as main and include the XPS system as submodule in the ISE project

No, dont think so, if the BRAMs are at absolute address 000000 and they are initialized then microblaze should start

antti

If you choose for import, do you choose the right .bmm file? It should be something like system_stub_bd.bmm. If you choose the wrong one, your microblaze won't run.

Frank

Hi Frank,

I find three .bmm files: controller.bmm controller_stub.bmm controller_mb.bmm

But all these files are equal:

// File: D:\xilinx\test_projects\test8\implementation\controller_stub.bmm

ADDRESS_BLOCK lmb_bram RAMB16 [0x00000000:0x00003fff] BUS_BLOCK u1/lmb_bram/lmb_bram/ramb16_s4_s4_0 [31:28] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_1 [27:24] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_2 [23:20] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_3 [19:16] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_4 [15:12] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_5 [11:8] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_6 [7:4] ; u1/lmb_bram/lmb_bram/ramb16_s4_s4_7 [3:0] ; END_BUS_BLOCK; END_ADDRESS_BLOCK;

John

På Tue, 12 Apr 2005 16:39:13 +0200, skrev Frank van Eijkelenburg :

Hi John,

if that the case then they are ALL WRONG, I forgot aboutt the .BMM issue I used to fight with a LOT some while ago. Thats one reason why I did say that you should not use import export with XPS

you need a file that looks like

lmb_bram/lmb_bram/ramb16_s2_s2_0 [31:30] PLACED = X0Y11; lmb_bram/lmb_bram/ramb16_s2_s2_1 [29:28] PLACED = X0Y9;

the "PLACED ." is important this info is by the XPS flow to actually merge the SW and HW, it tells where the individual BRAMs are located. if that file is wrong then all SW bits will be around the chip in random BRAM locations

XPS generated this file in \implementation directory, if you use ISE to synthesize then ISE must know have assigned BMM to the BMM with PLACED, only then will the ISE generated bitstream actually match to what XPS expects.

as said, this may be very painful to setup, after you export, then in ISE try to add the BMM with 'placed' to the project, if that does not work then you must use the PLACED BMM from XPS implementation, then create UCF lock file locking all BRAMS to what they are in the XPS PLACED BMM then rerun ISE with the BRAM constrained .UCF file then import to XPS and use the original BMM that XPS created.

That must work. It was problematic and painful a few EDK versions ago, and as you have problems it looks like the problem still perstists.

antti

"John" schrieb im Newsbeitrag news: snipped-for-privacy@visitech-jd.visitech.local...

be

As you saw inother post, all bmm files are invalid (in the sense that they cannot used by xps to merge the software in the generated bit file). I agree with this ;)

If I look at a project I did with a microblaze (project name is bootldr and microblaze is used as submodule) I see the following:

- after creating netlist (in xps) two bmm files are created in the implementation directory (bootldr.bmm and bootldr_stub.bmm)

- add the bmm file with the name ..._stub.bmm to your ISE project

- build the final bit file

- choose for import in xps and import the by ISE generated bit file and the generated bmm file with the name ..._stub_bd.bmm (the bmm file exists in the implementation directory)

- choose for initialize bram and in the implementation your final bit file is called download.bit (in the implementation directory)

this should work.

Frank