downloading with XMD ?

the

Yes

The reset vector is at 0xfffffffc, so there has to be some memory to vector the program off to where the rest of the memory is.

If you notice, from XMD, there are commands like mrd and mwr (memory read) and (memory write) that are available via the JTAG emulator through XMD. One could write a tcl program that did a series of writes and reads to load the program into memory. There is a the "dow" command available that takes an elf file and loads sram. Others have written tcl programs to program flash, which needs a series of mwr, mrd commands.

- Hope this helps Newman

Ok, thank you, it's getting clearer !

Stéphane.

"Newman" a écrit dans le message de news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

sjulhes wrote:

the

Yes

The reset vector is at 0xfffffffc, so there has to be some memory to vector the program off to where the rest of the memory is.

If you notice, from XMD, there are commands like mrd and mwr (memory read) and (memory write) that are available via the JTAG emulator through XMD. One could write a tcl program that did a series of writes and reads to load the program into memory. There is a the "dow" command available that takes an elf file and loads sram. Others have written tcl programs to program flash, which needs a series of mwr, mrd commands.

- Hope this helps Newman

Just one more question. In the FPGA what ressource realizes the physical external memory access ? Is it the JTAG that drives the FPGA IO to creates access cycles ? Is it the the use of the embedded hardware module which drives the EMC peripheral ? Something else ?

Thanks.

Stéphane.

"Newman" a écrit dans le message de news: snipped-for-privacy@f14g2000cwb.googlegroups.com...

sjulhes wrote:

the

Yes

The reset vector is at 0xfffffffc, so there has to be some memory to vector the program off to where the rest of the memory is.

If you notice, from XMD, there are commands like mrd and mwr (memory read) and (memory write) that are available via the JTAG emulator through XMD. One could write a tcl program that did a series of writes and reads to load the program into memory. There is a the "dow" command available that takes an elf file and loads sram. Others have written tcl programs to program flash, which needs a series of mwr, mrd commands.

- Hope this helps Newman

Newman,

Do you know if it is possible to peek/poke the memory via XMD - BRAM or cache memory (ultra-controller mode) without halting the PPC?

I heard reading the BRAM can crorrupt it.

-Tony

From Xilinx Answer 8181:

1. If Distributed RAMs or SRL16s are used in the design, reading back those LUTs could destroy the contents within if the WE is asserted while the readback is being performed on those frames.

1. The configuration logic takes over the address lines to the BRAMs, so those RAMs cannot be accessed or written to while readback of the BRAM frames is in progress.

IIRC, the BRAM contents themselves don't get trashed provided the WE is not asserted, but any reads done by the user logic while a readback is in progress have corrupted data. In other words, you can't use the bitstream readback while that BRAM is also being used by the PPC. However, the PPC is probably only using one port on the BRAM. If that is the case, you could add logic to read back the contents through the second user port on the BRAM.

Tony, Good question! Unfortunately I do not have an answer. In general, poking may present a problem without some type of semaphore protection. I've never used the cache memory in ultra-controller mode. I've observed some strange behavior when peeking memory when the PPC is running. I never was sure whether it was a limitation of the PPC jtag emulation scheme, issues of the BRAM interconnect methodology employed, or pilot error.

-Newman

XMD uses the PPC to peek/poke the memory. In other words, XMD forces the PPC to issue a PLB bus (or other interface) read/write operation. For this to happen XMD first stops the PPC.

- Peter

snipped-for-privacy@gmail.com wrote: