Boot Modes for 3 x XL216 TQ128 design

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
Redeye
XCore Addict
Posts: 131
Joined: Wed Aug 03, 2011 9:13 am

Boot Modes for 3 x XL216 TQ128 design

Post by Redeye »

I'm working on a design which uses 3 x XL216 TQ128 devices but I've run into a bit of a problem regarding booting them.

What I want to do is boot the first device from SPI flash, then boot the other two daisy-chained devices over xlinks. However, I'm now not sure if this is possible as the boot modes only allow for enabling of XL0 when booting over xlinks which makes daisy chaining not possible.

Am I missing something here, or is booting multiple devices not really supported for the TQ128 packages?


User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. See if this thread helps:

http://www.xcore.com/viewtopic.php?t=4691

Code: Select all

http://www.xcore.com/viewtopic.php?t=4691
Redeye
XCore Addict
Posts: 131
Joined: Wed Aug 03, 2011 9:13 am

Post by Redeye »

Thanks Mon2,

I've already got a working 3 x XL232 design which is relatively straightforward (once the tools bugs were fixed) because you can enable multiple xlinks when booting a tile from xlink, but on the TQ128 devices you can only enable L0 in 2w mode when booting via xlink which makes daisy chaining not possible. I just wanted to check I hadn't missed something because it's a bit of a show-stopper for this design.
User avatar
mon2
XCore Legend
Posts: 1913
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Post by mon2 »

Hi. I would think that you could use the OTP portion of the CPU to pull off what you are after. Have not tried it myself but being OTP, please proceed with caution to avoid bricking the CPU.

Here is a good document worth a review:

https://www.xmos.com/developer/download ... rc1%29.pdf

Code: Select all

https://www.xmos.com/developer/download/private/AN00153%3A-Programming-OTP-memory-via-SPI-boot%281.0.2rc1%29.pdf
General Idea to consider:

(main) CPU # 1 - boot from SPI - with your custom SPI flash based code, you could use any free XL to mate with the next downstream CPU

(daisy chained to CPU # 1) CPU # 2 - use OTP based code to read in boot code from CPU #1 over XL0 or another XL - with your custom OTP code, you could use any free XL to mate with the next downstream CPU

(daisy chained to CPU #2) CPU # 3 - use OTP based code to read in boot from CPU # 2 over XL0 or another XL

Talking out loud, the OTP coding could be tricky and risky. Personally would consider to boot each such CPU from a local SPI flash and then sequence the release of the reset of each. That is, allow the main CPU # 1 to release the reset of the 3rd CPU then 2nd CPU. Respectively, allow for the main CPU #1 to reflash each of the flash devices over SPI. Perhaps not as elegant as the booting over XL but practical.

Bianco did some work with XLINKs over fiber (versatile link by Avago) modules. These modules are available as simple TX / RX modules that work down to DC level yet are available upto 50 Mbps data rate:

http://www.xcore.com/viewtopic.php?t=5341

He used an Altera FPGA (could replace with a low cost Lattice ICE40 or similar) to do the same job. This project is worth a review to understand the XLINK portion of the CPU.
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

Well this is timely. I'm presently working on a 4x XL216 TQ128 system and the lack of clarity in the XMOS literature isn't helping. The latest XN file specification I can find (X3944B, 2016/10/31) says:
If the source specifies an xCONNECT Link, no Bootee elements may be specified. In a line of XS1-L devices, bootees must be contiguous to the device booting from SPI.
Isn't that saying the booting links must be direct to the device with the SPI flash?
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

By the way, Redeye, could you say why booting from L0 in 2W mode would be a showstopper? As I understand it this doesn't commit you to using that link, or prevent use in 5W mode, when the system becomes operational.
Redeye
XCore Addict
Posts: 131
Joined: Wed Aug 03, 2011 9:13 am

Post by Redeye »

mon2 - yes, I could probably get it to work that way, but it'll be a massive pain in production which rules it out for me.

CousinItt - Hopefully between us we can figure this out. I agree, documentation isn't very clear which is a shame.

After a lot of headscratching, I think I've found a topology which will boot. Can anyone see a reason why this wouldn't work?
3xXL216booting.png
3xXL216booting.png (23.1 KiB) Viewed 68968 times
3xXL216booting.png
3xXL216booting.png (23.1 KiB) Viewed 68968 times
The PCB routing isn't going to be very pretty, but as far as I can understand this will boot. I need 2 x xlinks between each device because I need a streaming channel and several non-streaming channels between each processor.
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

It looks good for booting. If you need two links between each pair of devices then all links are used, and your only choice is in which non-booting links go where, which might make layout a bit easier. I think the only drawback is that, with no spare links, there's no way to use xscope.
User avatar
CousinItt
Respected Member
Posts: 360
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

cluster links.png
cluster links.png (12.99 KiB) Viewed 67154 times
cluster links.png
cluster links.png (12.99 KiB) Viewed 67154 times
Here's the plan for my design. Device A has boot mode 000, the others have boot mode 100. X is the xtag link, and Q is the QSPI flash. The link between A and D is used in 2 way mode for booting and 5 way mode afterwards. This is a CPU module which will be used in a number of projects. The main objective (apart from having four devices) is to maximise availability of single bit ports on devices B and C. External links are shown by arrows. They are uncommitted so I'll have the choice of using the pins for I/O, 2 way or 5 way links. This will also allow the option of additional links between B,C and/or D if less I/O is needed.
Redeye
XCore Addict
Posts: 131
Joined: Wed Aug 03, 2011 9:13 am

Post by Redeye »

Just to follow up on this, after a lack of assistance with my support ticket on this I decided to do a very quick prototype PCB to prove that it'll boot. So I can confirm that this configuration boots :
3xXL216booting_v3.png
3xXL216booting_v3.png (21.48 KiB) Viewed 47979 times
3xXL216booting_v3.png
3xXL216booting_v3.png (21.48 KiB) Viewed 47979 times
It also boots with the flash connected to X1, which is more convenient for my design. When the flash is connected to X1 I have to admit that I don't really understand why X3 can boot when X2 is set to only enable XL0 on bootup. If anyone can explain this, or show me where the documentation on the multi-tile boot procedure is to explain it, I'd be very grateful.

For others who want to check their configuration, Rob at XMOS did point me in the direction of xntools which will check that your XN file configuration is valid. To view the dot graph files it generates, this link might be useful : http://www.webgraphviz.com/
Post Reply