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

***********************************************************************

Antti

Antti,

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.

Matt

Antti Lukats wrote:
> 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..
> 
> ***********************************************************************
> 
> Antti
> 
> 

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

"Matthew Ouellette" <nobody@nobody.com> wrote in message
news:cpqga4$bsn5@xco-news.xilinx.com...
> Antti,
>
> 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.
>
> Matt
>
> Antti Lukats wrote:
> > 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..
> >
> > ***********************************************************************
> >
> > Antti
> >
> >