Boot Modes for 3 x XL216 TQ128 design

Technical discussions around xCORE processors (e.g. General Purpose (L/G), xCORE-USB, xCORE-Analog, xCORE-XA).
Redeye
Experienced Member
Posts: 104
Joined: Wed Aug 03, 2011 9:13 am

Boot Modes for 3 x XL216 TQ128 design

Postby Redeye » Mon Nov 05, 2018 5:08 pm

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: 1282
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Mon Nov 05, 2018 8:10 pm

Hi. See if this thread helps:

viewtopic.php?t=4691

Code: Select all

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

Postby Redeye » Mon Nov 05, 2018 8:16 pm

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: 1282
Joined: Thu Jun 10, 2010 11:43 am
Contact:

Postby mon2 » Tue Nov 06, 2018 2:12 am

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:

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.
CousinItt
Experienced Member
Posts: 72
Joined: Wed May 31, 2017 6:55 pm

Postby CousinItt » Thu Nov 08, 2018 4:58 pm

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?
CousinItt
Experienced Member
Posts: 72
Joined: Wed May 31, 2017 6:55 pm

Postby CousinItt » Thu Nov 08, 2018 5:03 pm

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
Experienced Member
Posts: 104
Joined: Wed Aug 03, 2011 9:13 am

Postby Redeye » Thu Nov 08, 2018 10:10 pm

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 5260 times
3xXL216booting.png
3xXL216booting.png (23.1 KiB) Viewed 5260 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.
CousinItt
Experienced Member
Posts: 72
Joined: Wed May 31, 2017 6:55 pm

Postby CousinItt » Fri Nov 09, 2018 1:36 pm

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.
CousinItt
Experienced Member
Posts: 72
Joined: Wed May 31, 2017 6:55 pm

Postby CousinItt » Sat Nov 10, 2018 4:28 pm

cluster links.png
cluster links.png (12.99 KiB) Viewed 3446 times
cluster links.png
cluster links.png (12.99 KiB) Viewed 3446 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.

Who is online

Users browsing this forum: No registered users and 28 guests