Xilinx Christmas present: EDK 6.3 !

Hi all,

Christmas is closing so everybody is making presents. So is Xilinx. I just got mine! Read the story below:

*********************************************************************** ISE/EDK/ChipScope update to 6.3

In attempt to get our EDK based SoC systems up and running again in EDK 6.3 I ended up creating simplest possible SoC using BSB (because none of working EDK 6.2 projects worked after update no matter any attempts to get them working). Attempted to debug in XMD: fatal disaster BRAM can be loaded from elf, can also look at the disassembly all is ok. Any attempt to trace or execute simplest program and all goes pasta, not any more possible to view (or write) even to LMB RAM ! Then I added ChipScope bus analyzer core to OPB bus. And simplified the test application. Here is the source code:

----------------------------------------------------------- // Xilinx Christmas Lights application ver 1.0 while (1) { i++; WriteToGPOutput(XPAR_LED_7SEGMENT_BASEADDR, i); }

----------------------------------------------------------- This is running in MicroBlaze SoC at system frequency 50MHz. Pretty much all leds should be lit, right? Or?

It looks like (due to Christmas feeling !?) Xilinx tools have decided for me that my application should be "Christmas Lights" - because that how it works! The LEDS are blinking in fancy true random fashion at "human" blink rate, ie very slowly. The visual effects are pretty cool, really!

When looking in ChipScope (OPB bus analyzer) I see writes to the GPIO port:

0x00800000, 0x01000000,0x02000000,0xFFFFFFE,0xFFFFFFC... Those are 5 example sequential writes to GPIO port (from the above program!), notice that between the GPIO writes there is always more than 512 OPB clocks of no OPB bus activity.

And yes, I did UNINSTALL ALL ISE/EDK/ChipScope before update, then installed all the new versions plus service packs, etc..



Reply to
Antti Lukats
Loading thread data ...


Can you add the LMB signals to your ChipScope trace? What is the processor doing during these 512 cycles of inactivity in between GPIO writes? One way to help find this out is to cross-reference the objdump output of the ELF file with the I-LMB to find out where in your code the processor is.

One thing you may want to try to do with to replace the GPIO drivers with simple XIo_Out32 commands that may take fewer processor clock cycles to execute. It's possible the during this 512 clock cycle OPB inactivity, MicroBlaze is actually executing the rest of the GPIO driver code.


Antti Lukats wrote:

Reply to
Matthew Ouellette

Chipscope doesnt attach to LMB, a workaround is possible but too time consuming. No idea what processors was doing during idle but it can not be software overhead for sure.

Anyway I finally have all EDK systems up and running again so it isnt a problem any for me. But if such problems happen with every minor EDK update then its a headache of course.

Antti Lukats








for me






Reply to

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.