I have used the Xilinx XPS to debug a design on a custom board (on-chip hw debug). Now, I want to disable the debug so the code run once the FPGA is programmed. Beleive or not, but I don't find a easy way to to do this. Can anyone help me?
Thanks,
John
--
Sendt med M2 - Operas revolusjonerende e-postprogram:
http://www.opera.com/m2/
"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
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 :
--
Sendt med M2 - Operas revolusjonerende e-postprogram:
http://www.opera.com/m2/
"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..
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 :
--
Sendt med M2 - Operas revolusjonerende e-postprogram:
http://www.opera.com/m2/
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.
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
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...
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)
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.