Connect two XU316 devices using xCONNECT Topic is solved

[alex4d1]

Hello,

I'd like to connect two XU316 devices using xCONNECT.

Can this be prototyped using two XK-EVK-XU316?
If yes, is there a reference guide/example available that I can use to help me get started?

Generally, I have trouble finding resources on how to connect 2 or more XU316 devices.
I've read the following document
https://www.xmos.com/download/private/x ... 1.0%29.pdf
and found these two posts
https://www.xcore.com/viewtopic.php?t=4837
https://www.xcore.com/viewtopic.php?t=8235
but they referring to the xCORE-200 series.

Any help is much appreciated.

Thanks
Alex

[fabriceo]

Hi Alex
you can see port mapping on this xls file here:
https://www.xcore.com/viewtopic.php?p=39764#p39764

you can workout xConnect with J13 and J15 related to xlink1 and xlink2 on tile1

form my (little) experience on this complex subject, I d recommend that you connect XL1 and XL2 on the same board, with 4 wires-jumpers (crossing up and dn) and doing a main() with 2 tasks on the tile1, trying to talk to each other.

I have done that with a an emulation of the xconnect protocol on 4 one bit port on a xu200 diyinhk board and this was very inspirational and I learnt a lot on how the protocol works, and the buffering and routing.
Here is the zip file enclosed, this is not a turnkey solution, just an outcome of some tests. the file xlink.h and xlink.xc are the one for accessing the real xlink. Hope this will give you some help.

count no less than a week to get everything working and packaged as a clean library with timeout handling, some handshake and crc check...

please share your findings :)

[alex4d1]

Hi Fabrice
Thank you for putting together the spreadsheet of the port mapping, that is a great resource!

I just realized that there is actually an official example for XLINK available here:
https://www.xmos.com/documentation/XM-0 ... xlink.html

I must have missed this as it is an FreeRTOS example directory.

This together with your example will be a great starting point. Thanks

[alex4d1]

Today I tried connecting up two XCORE.AI Explorer boards and compiled the XLINK example application in the xcore_iot repo.

I changed the I2C address parameter in the the XLINK sample application, everything else is identical to the repository content.

When wiring up the two boards I stumbled over the following in the documentation that doesn't seem quite right:
The two tables describing the pin mapping for 2wire and 5wire XLINK in the following link seem odd:
http://118.126.82.6:1333/doc/programmin ... k.html#id1
My understanding is that the 2wire link requires 4 wire connections, and the 5wire link requires 10 wire connections.

I assume this is just a mistake in the documentation and the following is correct:
2wire:

BOARD 0	BOARD 1
GND	GND
X1D65	X1D66
X1D66	X1D65
X1D64	X1D67
X1D67	X1D64

5wire:

BOARD 0	BOARD 1
GND	GND
X1D65	X1D66
X1D66	X1D65
X1D64	X1D67
X1D67	X1D64
X1D63	X1D68
X1D68	X1D63
X1D62	X1D69
X1D69	X1D62
X1D61	X1D70
X1D70	X1D61

Is my assumption correct?

If I wire up a 2wire XLINK based on the documentation both boards blink and I can see periodic I2C output, but the "received data bytes in last second" are always 0.
If I wire up a 2wire XLINK based on my assumed pin mapping board 1 crashes when board 0 is started with an RTOS interrupt error.

Code: Select all

C:\Work\03_Experiments\xcore_iot\build>xrun --id 0 --io example_freertos_xlink_1.xe
xrun: Program received signal ET_ECALL, Application exception.
      rtos_irq_handler (data=<value optimized out>) at C:/Work/03_Experiments/xcore_iot/modules/rtos/modules/rtos_support/src\rtos_irq.c:59
      59            xassert( irq_pending[ core_id ] );
      Current language:  auto; currently minimal

(Note: My board 0 has XTAG id 1 and vice versa.)
Was anyone able to get this sample application running and has some ideas what I am doing wrong?

When trying to understand the code I could find much information how the line 62 in xlink_tx.c is determined:

Code: Select all

chanend_set_dest(c_other_tile, 0x00210902); // hardcode to expected rx

Based on the AN01024 this should be: XXXXYYZZ with XXXX being the node id, YY the chanend number and ZZ the resource type. However the node id is configured to be 0x20 in the rest of the application so this doesn't add up.
Did this change with XS3?
If anyone could help me wrap my head around this?

Thanks in advance
Alex

[Joe]

Hi,

Apologies if I'm teaching granny to suck eggs here but a quick summary.

Connecting devices with xmos links is part of the xmos ecosystem and allows you to make a (say) four tile system from two two tile chips. You define which links are connected between the devices in the XN and the tools handle the rest when building your software. In your software instead of having two tiles to play with you now have four. The more links you have connected between devices the more options you have when using e.g. streaming channels. 5w links are obviously faster than 2w links.

The two devices would need to be wired in series in the JTAG chain to the debugger such that the system can be debugged correctly.

Booting a multi chip system requires a bit of care, typically for a two chip system you would have one chip boot from QSPI and the other chip boot over the xmos link. The boot mode settings on X0D4-7 allow you to choose to boot from link in a few modes which open different numbers of links. The problem is opening a lot of links can be a problem if those links are shared with IOs that are driving in to the xmos chip as they could be seen as boot data and cause the boot to fail. Easiest is to boot in mode 6 which opens only XL0 in 2w mode. So this means having XL0 as one of the links connected to the "master" (chip with QSPI).

Prototyping multi chip systems can be hard because of the need to chain the JTAG and the fact that all xmos link wires are edge sensitive so should be treated as clocks. They need to have monotonic rising and falling edges so the signal integrity needs to be good. They also run very fast (you can set how fast in the XN) but typically if you put a scope on a link wire it might look like a 100MHz clock at the fast end. This typically means wiring them up with e.g. jumper link flying leads doesn't work. You can slow the speed of the links in the XN (with the "delays" keyword) but this only helps to some extent as the rising and falling edges still need to be non-monotonic.

We have built 4 tile systems using two XU316-EVKs, there is a header on the bottom to allow chaining the JTAG and then there are a lot of links available, the links can be wired across directly with ribbon cable to connect 5w links but the signal integrity across (even short) ribbons is not good enough to support reliable operation. The reason for this is the xmos links are locked to run at 4mA drive strength and at 3.3V they are not strong enough to correctly drive a 50 ohm transmission line. They will at 1.8V however. This isn't a big deal as in a typical system the two devices are close together and can be wired with short traces (less than 3 inches or so will work fine).

Attached a simple example of two XU316 connected with a single 2w xmos link, as well as the XN. This is somewhat of a trivial example as there's only one xmos link on the QF60 package but it shows the general scheme. With a bigger TQ128 or BGA package you would typically use a wider link (or more links) for the extra bandwidth.

Most examples of multi chip systems for xc-200 will be very similar if not identical for xcore.ai. The concept is the same for both devices.

Cheers,
Joe

[alex4d1]

Thanks Joe. I am fairly new to the XLINK topic so ANY information is greatly appreciated.

One of my takeaways from your post is that my long jumper wires might cause the issues I'm experiencing, and you were right.
I increased the inter delay and the the sample application started to work. I'll try to shorten my jumper wires next.

The attached example is a great baseline.
I also noted the advice on boot mode settings and JTAG wiring in series.

Cheers
Alex

[Joe]

I guess really there are two separate architectures for connecting devices (lets for this example say connecting two XU316 (2 tile) devices:

1.) Devices connected in same JTAG chain with the whole multi chip system described in one XN file to form a four tile system
- This is the original concept of building multi chip systems and this should just work seamlessly. You will have a single main.c/xc for the whole system and can use 4 tiles. Can boot the whole system from a single QSPI flash.

2.) Devices individually debugged each running their own 2-tile software that just happen to be interconnected using xmos links as a data transport medium.
- This would be a lot harder to get started with and debug but does have the advantage of being able to have some higher level code to allow you to recover should you ever get errors in the xmos links (so perhaps for harsh environments). Would need individual boot flash for each device.

If the two devices are relatively closely spaced on the same PCB I would definitely choose option 1. If the two devices are separated by a large distance or cables etc then option 2 becomes more attractive due to the limited error handling capability of the xmos links.

[alex4d1]

Hi Joe,

Assuming I want a system according to option 1, does it matter whether I use an xlink port on tile0 or tile1 to connect the two?
If I would connect an xlink port on tile 1 device 0 to an xlink port on tile 1 device 1, would there be any penalty for accessing the xlink on tile 0?

Thanks
Alex

[Joe]

Hi Alex,

Thanks for the useful question. It isn't particularly clear from the datasheet but on xcore.ai devices there is no relationship between the external xmos link pins and the tiles. The external xmos links (XL0, 1, 2 etc.) connect to the xCONNECT switch inside the device and the tiles are also in turn connected to the switch but tiles do not directly connect to external xmos links. See Figure 6 in the datasheet: xcore.ai FB265 datasheet

The xmos links overlap the tile IO but they are multiplexed such that they either work as tile IO from the ports (when port is enabled) or as xmos links (when the xmos link is enabled). XMOS Links take precedence over tile IO (ports) if the link is enabled.

An example would be XL5 which has one bit overlapping IO on tile 0 - XL5_IN[4] - X0D21 and the other 9 bits overlapping IO on tile 1.

So in direct answer to your question, it doesn't matter which links you use to connect the two devices outside of the considerations for booting which I mentioned before (i.e. it's mostly easier to configure boot from XL0) so if XL0 is one of the links you decide to connect that can be beneficial.

In terms of physical layout, on the package the links XL0 to XL7 are positioned on pins going anticlockwise around the device. So link 0 is bottom right with 1, 2 and 3 above it. Then on the left side we have 4, 5, 6 and finally 7 on the bottom edge of the package. This is designed such that you can place two devices side by side with one package rotated 180 degrees and you will have 4 5 wire links that can connect directly on the PCB with no crossovers. See below:

  xcore.ai #1          xcore.ai #2
                      (Rotated 180)
/-------------+      +-------------+
| 4         3 | ---- | 0      7    |
| 5         2 | ---- | 1         6 |
| 6         1 | ---- | 2         5 |
|    7      0 | ---- | 3         4 |
+-------------+      +-------------/

So you will have XL0 of first device connecting to XL3 on the second device, XL1 of first device connecting to XL2 on the second device etc. This is only one example however, many other configurations are possible.

This is for the BGA package but the same is true for the TQ128 albeit with less links available. On the QF60 there is only one link so it becomes a trivial solution.

Cheers,
Joe