xCONNECT and xTAG between two xC-200 processors

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
alwalker
Active Member
Posts: 45
Joined: Sun Apr 08, 2018 11:19 pm

xCONNECT and xTAG between two xC-200 processors

Post by alwalker »

I am working on a design project that in one version will use an XL232-1024-FB374, and in another adds an XE216-512-FB236 to provide an Ethernet interface. I’m starting with the assumption that as the XL232 is common to both designs, in the case of the dual processor version that it will be the primary processor and the XL216 the secondary one. The external flash memory is connected via the QSPI interface on the XL232 in both instances, with the anticipation for software updates via the XL216 Ethernet interface on the two processor version.

I understand using the left-hand column priority principle, that any I/O pins used for xCONNECT interfaces are stripped out of the respective multi-bit ports. So in the instance of a full xTAG connector implementation 8D4-8D7 and8 16B12-16B15 are not available in on their respective ports, but the other bits (8D0-8D3 and 16B00-16B11) are available. Is this correct please? I have X0D40-X0D43 spare on both processors.

X0D40	XL0 In 1		XL1_DN1		8D4		16B12
X0D41	XL0 In 0		XL1_DN0		8D5		16B13
X0D42	XL0 Out 0		XL1_UP0		8D6		16B14
X0D43	XL0 Out 1		XL1_UP1		8D7		16B15

How should the daisy-chained JTAG connections be made from the 20-way header to the two processors please? 

I understand that the TDI input pin 5 on the 20-way header goes to the primary processor, its TDO output goes to the TDI input of the secondary processor, and its TDO output goes back to the TDO pin 13 on the 20-way header, likewise TMS and TCK go to both processors, so it’s the other pins I’m enquiring about (the four xCONNECT connections plus DEBUG_N and RST_N).

1	NC (+5V)		2	NC
3	NC (MSEL)		4	GND
5	TDI			6	XL1_UP1
7	TMS			8	GND
9	TCK			10	XL1_UP0
11	DEBUG_N			12	GND
13	TDO			14	XL1_DN0
15	RST_N			16	GND
17	NC (UART_RX)		18	XL1_DN1
19 	NC (UART_TX)		20	GND

For the interconnections between the two processors, I have some options for connecting them, again using the left-hand column priority principle I have the following 2-wire and 5-wire interfaces available on the XL232:

X1D64	XL2 In 1		32A13
X1D65	XL2 In 0		32A14
X1D66	XL2 Out 0		32A15
X1D67	XL2 Out 1		32A16

X2D61	XL6 In 4		32A10
X2D62	XL6 In 3		32A11
X2D63	XL6 In 2		32A12
X2D64	XL6 In 1		32A13
X2D65	XL6 In 0		32A14
X2D66	XL6 Out 0		32A15
X2D67	XL6 Out 1		32A16
X2D68	XL6 Out 2		32A17
X2D69	XL6 Out 3		32A18
X2D70	XL6 Out 4		32A19

The XL216 has the following 2-wire and 5-wire interfaces available:

X0D49	XL5 In 4		32A00
X0D50	XL5 In 3		32A01
X0D51	XL5 In 2		32A02
X0D52	XL5 In 1		32A03
X0D53	XL5 In 0		32A04
X0D54	XL5 Out 0		32A05
X0D55	XL5 Out 1		32A06
X0D56	XL5 Out 2		32A07
X0D57	XL5 Out 3		32A08
X0D58	XL5 Out 4		32A09

X0D61	XL6 In 4		32A10
X0D62	XL6 In 3		32A11
X0D63	XL6 In 2		32A12
X0D64	XL6 In 1		32A13
X0D65	XL6 In 0		32A14
X0D66	XL6 Out 0		32A15
X0D67	XL6 Out 1		32A16
X0D68	XL6 Out 2		32A17
X0D69	XL6 Out 3		32A18
X0D70	XL6 Out 4		32A19

I assume that there is no particular advantage in choosing one set of ports over another?

What is the available functionality and also any limitations for the use of 2-wire and 5-wire xCONNECT interfaces please? The xCONNECT Architecture is quite a few years old now and whilst gives information about maximum speed, there isn’t much that’s specifically relevant to xC-200 processors, likewise the available application notes.

Also, I’ve been advised to restrict critical timing chanends/interfaces to within a pair of tiles (Tile 0 & 1 or Tile 2 & 3) and not to make such connections between pairs of tiles, is this established good practice please?
Last edited by alwalker on Sat Feb 19, 2022 7:21 pm, edited 1 time in total.


User avatar
CousinItt
Respected Member
Posts: 303
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

The data sheets say
The ports and xCONNECT links are multiplexed onto the physical pins. If an xConnect Link is enabled, the pins of the underlying ports are disabled. If a port is enabled, it overrules ports with higher widths that share the same pins. The pins on the wider port that are not shared remain available for use when the narrower port is enabled. Ports always operate at their specified width, even if they share pins with another port.
So the remaining pins on 8D or 16B should be available.

You connect the JTAG signals as shown here: https://www.xcore.com/viewtopic.php?t=4837

If your second processor is missing, you will need a link between its TDI and TDO connections to bring the TDO of your first processor back to the xTAG.

DEBUG_N is only available on the larger devices, so you could only feed this to the XL232. As johned says, it's not critical and you can do without it.

Regarding RST_N I've followed the example of the explorer kit without problems. It's just another input to the reset generator. See the hardware manual for details. https://www.xmos.ai/download/xCORE-200- ... l(1.2).pdf

The xCONNECT signals going to the xTAG should be those of your main processor.

You should use Link 0 on the second processor if you want to boot over a link. See discussion here, especially Redeye's last message. https://www.xcore.com/viewtopic.php?t=6974

As far as I know the only difference between 2-way and 5-way links is the trade-off of speed vs pins used. Everything you can do with one you can do with the other.

I'm not sure about your last point. Delays increase with the number of hops between devices. I think an XL232 consists of two XL216 dies connected together. I don't know if there's an increase delay in the interconnection but I wouldn't expect it to be much. Generally delays depend on how busy your links can be at any given time.
alwalker
Active Member
Posts: 45
Joined: Sun Apr 08, 2018 11:19 pm

Post by alwalker »

Hello @CousinItt

Thank you very much for the detailed reply and the links the other relevant threads. I've attached my understanding of how the single and dual processor configurations should be connected, would you mind reviewing please?

As I've implemented the 2-wire connection to the XL0 xCONNECT interface on the XE216 processor to allow booting from the XL232, how should the .xn file be specified please? Is it a case of having to build two separate binaries for each processor or one combined build please?

Can I also implement the 5-wire connection shown in red on the diagram in parallel with the 2-wire connection to provide a faster interconnection interface please? If so, how should this be specified in the .xn file please?

With regard to the issue of connecting between pairs of tiles on a four tile device, I understood the explanation to be to do with locks on interfaces affecting timing-critical applications such as digital audio signals. It was only a passing comment, but I took it to be one based on personal experience.

With regard to resistors that have to pulled up to configure the boot mode, I found this poorly-phrased section in the data sheets under Appendix F.7 GPIO to be somewhat confusing:

Pins X0D04, X0D05, X0D06, and X0D07 are output only and are, during and after reset, pulled high and low appropriately (Section 8)

Pins X2D04, X2D05, X2D06 and X2D07 are output only and during and after reset, X2D06 is pulled high and X2D04, X2D05, and X2D07 are pulled low (Section 8)


My understanding is that after boot, these pins (which form 4B0-4B3 and subsets of wider multi-bit ports) can be configured as either inputs or outputs by the application code. On exiting reset, these pins are read to determine the boot mode (and therefore must be configured as inputs rather than outputs), and so I use a tristate buffer that is only enabled once the application code is running to avoid any level conflicts.
You do not have the required permissions to view the files attached to this post.
User avatar
CousinItt
Respected Member
Posts: 303
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

The schematics look OK. I assume all the resistors with bars above are pull-ups. You might want to consider series termination resistors for the higher speed signals - let's assume you have. Do you have any need for an interrupt from the RGMII PHY, or an independent reset?

I don't know what happens if you have DEBUG_N going to only one device in a system. It might be worth putting in a removable / cuttable link just in case.

Please remember the XL232 has two nodes (see the plain XL232 xn file in the xmos installation targets folder), and the XE216 does too, if you wish to use the USB interface.

By the way, the XL232 data sheet also includes USB interface information, but if a USB interface is present it may not be fully connected (the data sheet doesn't have a USB phy section). For layout purposes I've assumed it's necessary to honour the specs for the relevant pins.

For booting the XE216 over the link, you have to identify it as a bootee from the point of view of the node that is booting from the flash, like so

Code: Select all

          <Boot>
            <Source Location="bootFlash0"/>
            <Bootee NodeId="1"/>
          </Boot>
Similarly, you have to indicate the boot link to the second device:

Code: Select all

          <Boot>
            <Source Location="LINK" BootMode="4"/>
          </Boot>
I don't know why this isn't done for the second node in the default XN file. Maybe if more than one node is specified for the same package, it knows what to do. Also, I don't know why the node numbers 0 and 2 are used - maybe to ensure the node number corresponds to a tile? Anyway, it's easy to experiment providing the hardware is right.

The normal route is to build a single binary image that is programmed into the flash: it contains a separate code image for each tile which is transferred during the boot process.

Yes you can have a separate boot link and operational links. The links element of the XN file covers the operational links. See the default XN file and the one johned supplied for examples of how links are specified.

Agreed, the text about those pins is very confusing. My approach has been to steer clear of using them for anything other than booting (either connection to a QSPI flash or setting the boot mode) since I haven't needed to use them. If you really need to find out what they can do, it might be worth experimenting with an explorer kit before you commit to hardware, or do a bit more searching on here.
alwalker
Active Member
Posts: 45
Joined: Sun Apr 08, 2018 11:19 pm

Post by alwalker »

Thanks very much CousinItt, yes those are pull-up resistors. The diagrams are simplified to only show the information relevant to this thread, so omit much of what's in the full schematics including transmission line series termination resistors and the additional control lines for the RGMII PHY. Adding a zero ohm link in the DEBUG_N line is a good idea. I'm not using USB in this application, but point noted.

It's only the 4B0-4B3 pins on the XL232 Tile 2 that I'd want to use as conventional GPIO after booting, as the corresponding pins on Tile 0 are used for the QSPI flash interface. I don't need to use the Tile 0 4B0-4B3 pins on the XE216 implementation. I'll do some more digging on this issue and post back here anything that I find out and confirm in practice.

I'll review the XN file specification method for the links, hopefully things will be clearer as a result.