Problem connecting two XS1-L2A

[jwowi]

ISA4C.txt

We are currently working on a project with two XS1-L2A. Until now I have successfully written test programs for the AVB Board (one XS1-L2A). Now we’ve got prototypes with two XS1-L2A. We are using the attached XN-File:

Compiling a testprogram which worked on the AVB Board, failed with the error message:

Error: XN11049 Network positioning failed (may be unsupported topology)

We’ve experimented a lot and found that the problem seems to be the link between the two XS1-L2A ( Link from Node 0 to Node 2).

<Link Encoding="2wire" Delays="0,1">
<LinkEndpoint NodeId="0" Link="X0LB"/>
<LinkEndpoint NodeId="2" Link="X0LB"/>
</Link>

If I change that to: ( Link from Node 1 to Node 2)

<Link Encoding="2wire" Delays="0,1">
<LinkEndpoint NodeId="1" Link="X0LB"/>
<LinkEndpoint NodeId="2" Link="X0LB"/>
</Link>

(Which is not the actual hardware configuration!!!) I can compile it without errors. I tried to do a debug download to the board, the file is loaded, but the program stops immediately with the error message:

All call records have not exited in Multi-node boot

I have no idea what this error message means, but it may make sense since the XN-File is not correct.

My question is: Is it not possible to boot the second XS1-L2A (core 2) from core 0? Can it only be done from core 1? Or is there another problem with my XN-File?

best regards

jwowi

[Paolomio]

To quote Ali at XMOS:

The naming of the links is a little confusing. The number refers to which core is connected in the G4 device (which has 4 cores and only one switch). For the L series devices (which have a switch per core) the number refers to a specific set of links. In the case of the L2, X0Lx specifies external links , X1Lx specifies internal links between the cores.

Also, the second device must use LB in order to boot via xlinks, so you want to use:

Code: Select all

<Link Encoding="2wire" Delays="0,1">
      <LinkEndpoint NodeId="1" Link="X0LA"/>
      <LinkEndpoint NodeId="2" Link="X0LB"/>
    </Link>

Paul

[jwowi]

Hello Paul,

thank you for your reply.

Also, the second device must use LB in order to boot via xlinks, so you want to use:

Code: Select all

<Link Encoding="2wire" Delays="0,1">
      <LinkEndpoint NodeId="1" Link="X0LA"/>
      <LinkEndpoint NodeId="2" Link="X0LB"/>
    </Link>

The second device in my XN-File is using X0LB and I can’t use your suggestion, simply because X0LA on Node 1 and X0LB on Node 2 aren’t physically connected. We’re talking about hardware! The actual physical connection is:

Code: Select all

<Link Encoding="2wire" Delays="0,1">
      <LinkEndpoint NodeId="0" Link="X0LB"/>
      <LinkEndpoint NodeId="2" Link="X0LB"/>
    </Link>

So my question is still: Is it not possible to boot the second XS1-L2A (core 2) from core 0? Can it only be done from core 1? Or is there another problem with my XN-File?

best regards

Juergen

[Paolomio]

I think using X0LB on cores "1" and "2" should be fine. Have you tried this? Does it work?

Paul

[Noeldi]

The physical Connection is between Core0 (First XS1-L2A) and Core2 (Second XS1-L2A) !
So I think the question is still : Is it possible to Boot Core2 from Core0 ?

Noeldi

[Bianco]

So this is your system:

Code: Select all

                  SPI Flash
                      |
[node1] <--LINK--> [node0] <--LINK--> [node2] <--LINK--> [node3]

|________________________|            |________________________|        
           |                                       |
         L2[0]                                   L2[1]

It looks like the tools do not support that the master node is somewhere in the middle of a chain.
I can get this compiled with the link between node1 and node2.
I suggest to create a ticket at the XMOS website to get this confirmed.
I'm pretty sure that this is a tools limitation and that the architecture supports it.

[jwowi]

Hello Bianco,

thank you for your reply. Yes, you’re right, if you define the link between node 1 and node 2, it compiles without error. But then the XN-File describes someone else’s hardware not ours. And hardly surprising, you get an error message when you try to run it.
If it is really a tools limitation, I’d suggest they make their “virtual header file platform.h” less virtual and more editable. :D
We followed you suggestion and created a ticket at XMOS. I will post the results.

Best regards

Juergen

[m_y]

This is an 'issue with the current tools' and we are working to address it.

[Hooligan]

Well, I've just slammed into this brick wall as well. I have the same layout described jwowi.

Juergen, if you hear from XMOS on your ticket I and, I'm sure, others would appreciate you sharing their response.

In the mean time, I'm going to try to fake out the tool chain with a couple of separate executables. Failing that, I'll have to set up the channels manually on chip 0 and boot chip 1 which will then also have to set up the link and it's channels manually. While I'm sure that will be interesting, it won't pay the bills and is unlikely to get my customer's device to market on schedule.

Perhaps another tack would be to figure out how the XScope link is implemented and use that technique to set up the channels.

I'll post any progress here.

[lilltroll]

You mean that you have to follow figure 5 in https://www.xmos.com/download/public/XS ... 1.1%29.pdf at the moment, other config is not supported at the moment. !?

Topologies for multiple L2 devices (or a mix of L2 and L1 devices) is similar to the L1
only topologies, with the exception that the slave die within the L2 module is always
booted by the master die within the same module. Therefore to boot an L2 device
as a slave over XMOS Links, link X0LB on the master core must be used. Any free
outgoing link can then be used to boot further downstream L1 or L2 devices.

XMOS: Maybe an example with only 2 L2 devices would be great, including a warning of impossible routings, until it is fixed in the toolchain.
A "Low Cost Reference Designs" would be great as well for a 2*L2 since it starts to be common to use, or an successor to the XC-1A/XC-2 with 2*L2 without XTAG on board.