Xlink between 2 XC-1As

Technical discussions related to any XMOS development kit or reference design. Eg XK-1A, sliceKIT, etc.
User avatar
tomcarter259
Member++
Posts: 28
Joined: Tue Mar 15, 2011 3:29 pm

Xlink between 2 XC-1As

Post by tomcarter259 »

I am trying to get a simple program working across 2 XC-1As connected with a single xlink. I know there are lots of problems involved with timing etc but hey, who doesn't like a challenge!

Hopefully a simple question to start, page 4 of the XS1-G Link Guidelines lists the names of the various links that can be put in the .xn file. Page 9 of the XC-1A Hardware Manual gives the corresponding pins to the ports. They don't seem to obviously match up to me so am I right in thinking that a 5 bit xlink using X3PortA should be X3LA in the Links part of the .xn file?

Thought I'd start with the obvious and make sure I'm plugging the cable into the right place!

Here is my .xn file in case it helps


m_y
Experienced Member
Posts: 69
Joined: Mon May 17, 2010 10:19 am

Post by m_y »

Yes, X3LA is the right one.
User avatar
tomcarter259
Member++
Posts: 28
Joined: Tue Mar 15, 2011 3:29 pm

Post by tomcarter259 »

Ok. Essentially I found this forum post from a couple of years ago about linking two XC-1s up and I'm trying to adapt it to the XC-1A and new tools.

This is the zip file with their implementation.

The method involves splitting the executable into a first-stage loader for each board and then the application for each board using xobjdump.

This is my bat file to do the splitting.

I can't work out what the difference is between what it puts into boardA.xe and appA.xe

Code: Select all

xobjdump boardA.xe -a "%XCC_DEVICE_PATH%/config_XS1-G4B-FB512.xml"
xobjdump boardA.xe -a "%XCC_DEVICE_PATH%/XS1-G4B-FB512.xn"
xobjdump boardA.xe -a 0,0,image_n0c0.elf
xobjdump boardA.xe -a 0,1,image_n0c1.elf
xobjdump boardA.xe -a 0,2,image_n0c2.elf
xobjdump boardA.xe -a 0,3,image_n0c3.elf

Code: Select all

xobjdump appA.xe -a "%XCC_DEVICE_PATH%/config_XS1-G4B-FB512.xml"
xobjdump appA.xe -a "%XCC_DEVICE_PATH%/XS1-G4B-FB512.xn"
xobjdump appA.xe -a 0,image_n0c0_2.elf
xobjdump appA.xe -a 1,image_n0c1_2.elf
xobjdump appA.xe -a 2,image_n0c2_2.elf
xobjdump appA.xe -a 3,image_n0c3_2.elf
The command for boardA specifies the node whereas the one for appA.xe doesn't but I'm not sure how the resulting .xe files differ?
m_y
Experienced Member
Posts: 69
Joined: Mon May 17, 2010 10:19 am

Post by m_y »

tomcarter259 wrote:I can't work out what the difference is between what it puts into boardA.xe and appA.xe
The elves put into boardA.xe have an "_2" in their filenames. When xobjdump splits the original XE it produces two binaries for each node/core. The first (the loader) is image_nXcY.elf the second (the application) is image_nXcY_2.elf.
User avatar
tomcarter259
Member++
Posts: 28
Joined: Tue Mar 15, 2011 3:29 pm

Post by tomcarter259 »

Great thanks for clearing that up.

I have set core[0] to flash the button LEDs to indicate that the application has loaded and is running properly. However nothing happens when I run the application image.

I can't imagine that this could be caused by the xlink failing to connect so is it likely to be a problem with the way I am doing the splitting?
m_y
Experienced Member
Posts: 69
Joined: Mon May 17, 2010 10:19 am

Post by m_y »

tomcarter259 wrote:I can't imagine that this could be caused by the xlink failing to connect so is it likely to be a problem with the way I am doing the splitting?
Experience suggests that it is most probably caused by the xlinks failing to connect. The G4 links are tetchy and problems are difficult to diagnose without a scope.

Also do you have firmware installed on the boards? There's an undocumented feature in some XC-1 firmwares which divides down the switch's clock so that it can no longer talk to normal speed switches. A program which reports the value of SSWITCH_CLK_DIVIDER whether this is the case on any of your boards.
User avatar
tomcarter259
Member++
Posts: 28
Joined: Tue Mar 15, 2011 3:29 pm

Post by tomcarter259 »

m_y wrote:Also do you have firmware installed on the boards? There's an undocumented feature in some XC-1 firmwares which divides down the switch's clock so that it can no longer talk to normal speed switches. A program which reports the value of SSWITCH_CLK_DIVIDER whether this is the case on any of your boards.
The boards have the firmware they came with still on them. How would I output the value of SSWITCH_CLK_DIVIDER? The compiler doesn't recognise it and I can't find any reference to it in the documentation.
m_y
Experienced Member
Posts: 69
Joined: Mon May 17, 2010 10:19 am

Post by m_y »

Code below. A value of 0x00 runs the switch at the maximal clock rate, 0xff at the lowest. Some XC-1 firmwares seem to program it to 0x80.

Code: Select all

#include <platform.h>
#include <xs1.h>
#include <stdio.h>

int main()
{
  par
  {
  on stdcore[0]:
  {
    unsigned int val;
    read_sswitch_reg( 0, XS1_SSWITCH_CLK_DIVIDER_NUM, val );
    printf("Reg 7: 0x%08x\n",val);
  }
  }
  return(0);
}
User avatar
tomcarter259
Member++
Posts: 28
Joined: Tue Mar 15, 2011 3:29 pm

Post by tomcarter259 »

m_y wrote:A value of 0x00 runs the switch at the maximal clock rate, 0xff at the lowest. Some XC-1 firmwares seem to program it to 0x80.
My boards all had 0x00

So would the only way to work out why its failing be to scope what's happening over the link?
m_y
Experienced Member
Posts: 69
Joined: Mon May 17, 2010 10:19 am

Post by m_y »

tomcarter259 wrote:So would the only way to work out why its failing be to scope what's happening over the link?
The method described in the links above works for suitably configured boards; I reconfirmed it myself a couple of weeks ago with pairs of XC-1s and XC-2s. Unfortunately the G4 links are almost completely opaque to software so it's very difficult to divine what's happening without spending a great deal of time picking over the entrails of the failing system. A scope is very useful at this stage, yes.
Post Reply