How to use wider port and linking tile together on startKIT

All technical discussions and projects around startKIT
Posts: 12
Joined: Thu Dec 22, 2016 9:36 am

Re: How to use wider port and linking tile together on startKIT

Postby quyenhuynh » Tue Feb 21, 2017 7:50 am

Thanks @infiniteimprobability very much, Can you recommend for me a xcore-200 board that has cost reasonably and support about 48 output? Now, I having 4 startKIt board and I read a post about how to linking two startKIts together ( but in my case, require many startKITs. I'm afraid it will very difficult in the programming. Do you think as me?
Posts: 12
Joined: Thu Dec 22, 2016 9:36 am

Postby quyenhuynh » Tue Feb 21, 2017 8:16 am

Dear @infiniteimprobability, Are you speak about this board?
User avatar
XCore Legend
Posts: 1889
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Tue Feb 21, 2017 3:03 pm

Hi. The project we are referencing is our p/n LF1071KB XMOS Xlinks LVDS Slice Board. This product is to supply interconnect between XMOS StartKits or XMOS SliceKits (see the SQUARE & TRIANGLE slot compatibility) using standard CAT6 cable using the LVDS transceivers. The design offers support of the use of standard straight-through CAT6 cables or even cross-wired CAT6 cables. More detailed documentation will be posted but the schematic will show that we are monitoring pin # 8 of the RJ45 connector for the style of cable being used in the interconnect.

That is, if RJ45, pin # 8 is NOT connected on the remote side, then a straight through cable is being used so pin # 8 is floating but the pull-up resistor will park the line HIGH. If RJ45, pin # 8 is HIGH, the straight-through wired LVDS transceiver will enable and the cross-wired LVDS transceiver will DISABLE.

If the RJ45 connector is mated with a cross-wired cable then RJ45, pin # 8 on one side of the cable will be driven to LOW which confirms a cross-wired cable is being used so the straight-through wired LVDS transceiver will DISABLE and the cross-wired LVDS transceiver will ENABLE.

The design was developed to mate directly onto the XMOS StartKit using a single 0.1" spacing (2.54 mm pitch) 1 x 13 male pin header (on LF1071KB PCB) & female (on XMOS StartKit) pair. Using this method, the add-on board can send & receive packets from a remote connected board over the respective xLinks.

The bare PCBs for this project, the special 2 x 2 RJ45 connectors, the mating male & female header pins are in house BUT we have not yet assembled these PCBs. If there is an interest, can raise the priority to move to a small batch production.

We would like to work with XMOS and/or developers who can offer public feedback on the operation of this design.

This XMOS Slice board is to offer the interconnect / daisy-chaining of XMOS StartKits or SliceKits (confirm the symbol for compatibility). Respectively, the idea for you to consider is:

1) source a USB self-powered Hub (with a nice 4A power supply or similar) so that each kit & LVDS slice board can be properly powered

2) dock 2 x StartKits into this USB self-powered Hub - each with a LF1071KB PCB

3) Follow the details for the .XN file definition to connect 2 StartKits together from Sethu.

4) Confirm that the 2 kits are able to communicate with each other - using this same method, you should be able to continue to daisy chain to use additional StartKits for your project.

As you are finding, being s/w driven, the XMOS solutions offer many options for a resolution. If you consider this LVDS slice board, then you are only sending simple commands / data packets to interconnect between the boards. Each local board will support your 8 transducers (ie. one per thread). We have not (yet) confirmed the timing of the interconnections for your project. The LVDS slice boards operate using 2W (2 wire) mode.

The solution from infiniteimprobability is to use a wider port (ie. 8 bit) but buffer the data as 32 bit and allow the XMOS instructions to clock out 8 bits per clock cycle, automatically (ie. stream out your data automatically).

Each approach has merits. Somewhat limited on "free" time these days but as noted, if there is an interest, will push to properly document this project asap. Although we have great investment of time and expenses, this design will most likely become open sourced.

The XCORE-200 Explorer board should be fine to use with the wider port idea & buffered ports in your code but please wait on a confirmation from infiniteimprobability. Believe that there is also a XCORE-200 style of SliceKit available which will then allow for daisy-chaining of additional XCORE-200 Slice boards using the LVDS Slice board (LF1071KB). Will review the schematics of the XCORE-200 Sliceboard to confirm the use with our LVDS slice design.

You may download the first release of this project from here:

XMOS LVDS Slice Board (p/n LF1071KB)
User avatar
XCore Legend
Posts: 1124
Joined: Thu May 27, 2010 10:08 am

Postby infiniteimprobability » Wed Feb 22, 2017 10:57 am

Dear @infiniteimprobability, Are you speak about this board?
Yes - this is the one. It's the lowest cost board with xCORE200 on it.

Some more info about the approach I am thinking about:

Essentially it's a memory to port player. You have a task which runs through an array and outputs to a buffered port; it plays the bitstream. For example, an array of 625 long words will provide 4 * 625 = 2500 8b bit patterns on an 8b port. If each bit pattern is present for 10ns, then the period to play the whole bit pattern is 1/(2500 * 10e-9) = 40000Hz. This requires a task to output a 32b word every 40ns. For 100Mhz thread, this means you get 4 cpu cycles, which with dual issue, can get you up to 8 instructions, which can work with some thought. Essentially you get 8 x 10ns granularity bit patterns per 100MHz thread (or logical core as it is called).

However, to change the phase of one channel, you need to read-modify-write the entire 625 long word array. This will take about 37us. Also, you have to consider double buffering each of the bit stream arrays so that you write to one while the other is being played, then swap back. You probably need to copy from the played array so perhaps make that 50us. So this is the rate at which you can update signals. That may or may not be fast enough.

I had a quick go at the ASM inner loop and got to about 7 instructions using single issue. A colleague who is better at this than me could get it to 3 instructions. This stuff is quite complex...
Relaxing the resolution to 20ns makes a world of difference and you could probably use XC to program the inner loop.

This is why I asked the questions before (particularly how much work are you prepared to do?).. Squeezing every last drop of speed out of any architecture results in riding up the curve of diminishing returns quite quickly! But it is doable..

Who is online

Users browsing this forum: No registered users and 2 guests