XK-1A hardware manual / XS1-L01A-TQ128 question

[mikronauts]

I found a difference between the data sheet and the development board documentation.

The XK-1A manual has the SPI Flash mapped as follows:

XD36 SPI_MISO
XD37 SPI_SS
XD38 SPI_CLK
XD39 SPI_MOSI

The data sheet shows the boot SPI Flash mapped as follows:

X0D00 MISO
X0D01 SS
X0D10 SCLK
X0D11 MOSI

The data sheet mapping makes more sense to me, as it uses single bit ports.

The reason I ask is that several schematics I've looked at use the same SPI configuration as shown in the data sheet, and I wanted to know where I should place the boot flash when I make an XMOS board (TQFP48 / TQFP64 / TQFP128)

I am guessing that the SPI port pins are stored in the OTP boot loader, and can be any convenient pins, specified in the 'xn' file.

(I am still working on digesting all the pdf's)

[Bianco]

the XK-1 uses a bootloader burned into the OTP that uses different ports to load the firmware from the SPI flash. For your own boards it would be easiest to stick to the ports in the datasheet which does not require a bootloader in the OTP but uses the loader in the Boot ROM instead.

[mikronauts]

Thank you for the quick response.

I will use the data sheet defined ports on my board.

the XK-1 uses a bootloader burned into the OTP that uses different ports to load the firmware from the SPI flash. For your own boards it would be easiest to stick to the ports in the datasheet which does not require a bootloader in the OTP.

I am guessing that the SPI port pins are stored in the OTP boot loader, and can be any convenient pins, specified in the 'xn' file.

It does not work like this. The ports used by the Boot ROM cannot be changed.

[MaxFlashrom]

When using ports with a customised OTP ROM, the ports used are hard-coded into the OTP program. Without any OTP ROM being programmed the ports are hard-coded into the factory XMOS ROM bootloader.

1 bit ports are a handy resource, often more useful than wider ports, as they can easily be used completely independently with different clocks, different directions and in different threads. The ports used by the default boot loader are shared with a 5-bit XMOS Link. It is possible with a little ingenuity to use XMOS Link A as a faster 5-bit link while still using the default boot SPI configuration. A 2-1 multiplexer is required e.g. NC7SZ157 to switch the purpose of P1B0, X0D1. One will need another control output line from somewhere else, possibly another L1 output port(not necessarily 1-bit, although this is least problematic) to switch the multiplexer. Paul mentioned just such a scheme, I recall, see
https://www.xcore.com/forum/viewtopic.p ... t=Paolomio

Note that a 2-bit link A can be used even when using the ULPI interface concurrently(as even though the underlying ports are being used by the ULPI internally , the external pins are not and the pins can still be switched to link functionality)and a 5 bit link with scheme outlined above.

I understand that XCores can boot via Link, but only via Link B, as it's coded in the internal ROM. This is problematic if one is using the USB ULPI interface as Link B cannot be used concurrently with the ULPI pins. Enabling linkB will override the underlying I/O pins and via some multiplexing magic, similar to above, but on a grander scale it may be possible to enable USB and link B alternately.

It is instructive to compare the ports on the L128, the L64 and the L48.

The L01-TQ128 has X0D 0, 1, (2-9 Link A even with ULPI), 10 , 11, (12-23 unavailable with ULPI), 24, 25, (26-33 unavailable with ULPI) 34, 35, 36, (37-43 opt ULPI), 49-58;61-70(Port 32A, can be 2 -bit /5-bit link C/D)

The L01-LQ64 has X0D 0, 1, 2-9(Link A,even with ULPI )10 , 11, (12-23 unavailable with ULPI), 24, 25, (26,27,32,33 unavailable with ULPI), 34, 35, 36, (37-39 opt unavailable with ULPI) but no port 32A/LinkC/LinkD

The L01-TQ48 has one clock, no standby PCU and no debug pin(this is probably not much of a handicap)
It has X0D 0, 1, 10 , 11, (12-23 optionally ULPI), 24, 25, 34, 35, 36, (37-39 opt ULPI), 52-55(Can be 2 -bit link C)

This shows that if one is using the ULPI there's actually not much loss of functionality between the 128 pin and the 48 pin package, which is perhaps somewhat surprising! Moreover choosing the 48 rather than the 64 is superior!

Max.

[mikronauts]

Thank you - more great info.

I find the boot from link B only an annoying limitation; I'd have preferred the mode pins allowing you to select the boot link.

The 1 bit ports do look very useful, as do the other port widths - and I love the implicit ser/des functionality of buffered ports.

I do wish ports were organized differently; I'd have preffered:

32 bit port
- breaks apart into two 16 bit ports

16 bit port
- breaks apart into two 8 bit ports

8 bit port
- breaks apart into two four bit ports

4 bit port
- breaks apart into two two bit ports

2 bit port
- breaks apart into two single bit ports

Then the 64 IO L1 could have two 32 bit ports, breaking down as specified above

I know, links complicate this as 5-pin links don't map well to this; however 4 bit links would map quite well.

Regarding the ULPI - I am surprised XMOS uses it; it seems to me that even a 50MIPS L1 thread would be more than fast enough for 12mbps low speed USB - or am I missing something?

When using ports with a customised OTP ROM, the ports used are hard-coded into the OTP program. Without any OTP ROM being programmed the ports are hard-coded into the factory XMOS ROM bootloader.

1 bit ports are a handy resource, often more useful than wider ports, as they can easily be used completely independently with different clocks, different directions and in different threads. The ports used by the default boot loader are shared with a 5-bit XMOS Link. It is possible with a little ingenuity to use XMOS Link A as a faster 5-bit link while still using the default boot SPI configuration. A 2-1 multiplexer is required e.g. NC7SZ157 to switch the purpose of P1B0, X0D1. One will need another control output line from somewhere else, possibly another L1 output port(not necessarily 1-bit, although this is least problematic) to switch the multiplexer. Paul mentioned just such a scheme, I recall, see
https://www.xcore.com/forum/viewtopic.p ... t=Paolomio

Note that a 2-bit link A can be used even when using the ULPI interface concurrently(as even though the underlying ports are being used by the ULPI internally , the external pins are not and the pins can still be switched to link functionality)and a 5 bit link with scheme outlined above.

I understand that XCores can boot via Link, but only via Link B, as it's coded in the internal ROM. This is problematic if one is using the USB ULPI interface as Link B cannot be used concurrently with the ULPI pins. Enabling linkB will override the underlying I/O pins and via some multiplexing magic, similar to above, but on a grander scale it may be possible to enable USB and link B alternately.

It is instructive to compare the ports on the L128, the L64 and the L48.

The L01-TQ128 has X0D 0, 1, (2-9 Link A even with ULPI), 10 , 11, (12-23 unavailable with ULPI), 24, 25, (26-33 unavailable with ULPI) 34, 35, 36, (37-43 opt ULPI), 49-58;61-70(Port 32A, can be 2 -bit /5-bit link C/D)

The L01-LQ64 has X0D 0, 1, 2-9(Link A,even with ULPI )10 , 11, (12-23 unavailable with ULPI), 24, 25, (26,27,32,33 unavailable with ULPI), 34, 35, 36, (37-39 opt unavailable with ULPI) but no port 32A/LinkC/LinkD

The L01-TQ48 has one clock, no standby PCU and no debug pin(this is probably not much of a handicap)
It has X0D 0, 1, 10 , 11, (12-23 optionally ULPI), 24, 25, 34, 35, 36, (37-39 opt ULPI), 52-55(Can be 2 -bit link C)

This shows that if one is using the ULPI there's actually not much loss of functionality between the 128 pin and the 48 pin package, which is perhaps somewhat surprising! Moreover choosing the 48 rather than the 64 is superior!

Max.

[MaxFlashrom]

Thank you - more great info.

I find the boot from link B only an annoying limitation; I'd have preferred the mode pins allowing you to select the boot link.
I know, links complicate this as 5-pin links don't map well to this; however 4 bit links would map quite well.

Regarding the ULPI - I am surprised XMOS uses it; it seems to me that even a 50MIPS L1 thread would be more than fast enough for 12mbps low speed USB - or am I missing something?

The 2-wire links use 4 wires for full-duplex. The 5-wire links use 10 wires: 5 up, 5 down, with a different coding scheme.

The links use a transition based scheme and crosstalk is to be avoided so routing them parallel on a board without adequate spacing/shielding is to be avoided. Length matching is less critical because skew is not an issue because of the signalling scheme)

For 2-bit links, only one one-bit symbol is sent per transition, and only one line transitions for each symbol.
For the 5-wire links a 2-bit symbol is sent per transition, and only one line transitions for each symbol.

For Low Speed 1.5Mbps and, 12Mbps USB, called Full Speed in the standard, it may have been possible to do it without the ULPI USB PHY. The PHY saves the Xcore some work, packing bytes. However the Xcore supports High Speed (480Mbps) operation with the ULPI PHY, which certainly wouldn't be possible without it.

I imagine one could write a custom boot loader for OTP to boot from a link other than linkB. The XMOS docs say that Xcores should be wired upstream via their B-Links when chaining several together. I imagine this is because of the way they are then booted by the tools/code loader.

Max.

[mikronauts]

Thank you for the great information. I need to spend some time studying links.

I am trying to avoid the need for custom OTP boot loaders for the boards I am considering making so that the OTP is left available for custom encrypted boot loaders (if needed). As I intend to have an SPI flash chip on every board, I currently envision a scheme where the default ROM loads an initial image from the SPI flash, which would not assume link B for uploads.

Thanks,

Bill

(I was aware of the 2+2 / 5+5 nature of the links; what I was getting at in my last post was that with the I/O pin breakdown I wished XMOS had, a 4 up / 4 down full duplex link configuration would map nicely onto any 8 bit port)

The 2-wire links use 4 wires for full-duplex. The 5-wire links use 10 wires: 5 up, 5 down, with a different coding scheme.

The links use a transition based scheme and crosstalk is to be avoided so routing them parallel on a board without adequate spacing/shielding is to be avoided. Length matching is less critical because skew is not an issue because of the signalling scheme)

For 2-bit links, only one one-bit symbol is sent per transition, and only one line transitions for each symbol.
For the 5-wire links a 2-bit symbol is sent per transition, and only one line transitions for each symbol.

For Low Speed 1.5Mbps and, 12Mbps USB, called Full Speed in the standard, it may have been possible to do it without the ULPI USB PHY. The PHY saves the Xcore some work, packing bytes. However the Xcore supports High Speed (480Mbps) operation with the ULPI PHY, which certainly wouldn't be possible without it.

I imagine one could write a custom boot loader for OTP to boot from a link other than linkB. The XMOS docs say that Xcores should be wired upstream via their B-Links when chaining several together. I imagine this is because of the way they are then booted by the tools/code loader.

Max.