Three startKITs connected over Xlinks

[johnswenson1]

I'm working on a lighting control application using startKITs as a multi-point DMX control system.

I have built boards that connect to the startKITs that run the Xlinks through LVDS and HDMI cables. The topology is one central board that generates the DMX signal and has two HDMI ports that go to the other startKITs which have keypads attached.

I started off with the normal single tile xn file and have the DMX transmitter up and running fine.

Then I went with the 2_startkit.xn from Sethu and tried to setup a two board configuration. I have the code written for the two boards in one app and used the Sethu's instructions for splitting into two flash images and then try and flash them to the two boards.

I'm getting very inconsistent results from this, sometimes I get an error message from xrun (not xflash!) that says the configuration does not match. Sometimes I don't get any messages. Sometimes I have to have to other board powered up and connected in order to not get the message. Some times I don't get the message, but the single tile program is still running after reboot.

At no point have I ever had what is supposed to be running in the dual tile configuration actually running. To simplify things I stripped it down to a simple LED flasher(using LED0 and LED1), with different LEDs on the two tiles. This never works in the two tile configuration. It works fine with the single tile configuration.

At this point I don't know what is happening. Doing the same thing multiple times gives different results (error message from Xflash, overwriting an existing program). I don't know how to debug this, all the debug tools insist on having both chips connected in a jtag chain. I would be happpy just getting some info from one of the startkits (either tile[0] or tile[1]) but when I try and run them they want the dual tile .xe, but it won't use that because it can't get at both tiles.

At this point I'm getting ready to trash Xlinks and write my own protocol, it will probably be easier.

Any help on how to get things working?

Thanks,

John S.

[pstnotpd]

I got severly sidetracked lately but what I'm trying to do here is rather similar.

Sethu's example relies on SPI flash which is pretty cumbersome in my view. If you use the TP1 header with an XTAG2 and patch the current version of the tools it is possible to see the entire chain of startkits correctly using the debugger. But I cannot figure out how to use the sources of this configuration to work with the debugger in this way.

Inspired by this wiki topic about runtime negotiation I figured this would make a much more "hotplugable" solution in which all seperate startkits can be debugged seperately. This particular example uses static forwarding.

A short time ago I also came across a forum post about service declarations in the XN which states anything connected which implements the Xlink protocol can be properly declared this way, i.e. other startkits should work fine. If I understand it correctly this can also avoid static forwarding.

Of course this all relies on a solid runtime negotiation protocol which does rely on Xlink, but I can't find the time yet to dive into this properly. The examples give some idea how to do this though. I'd really like to go for the service option but I'm afraid I'd need some more clarification on the behaviour of the "service" and how to set this up correctly for the startkit, or any kit for that matter because I want my slicekit boards to join in as well.

I hope someone at XMOS is watching..... :o)

TODO list:

1. Create a proper XN for 1 startkit which declares the services properly to connect other startkits to the C & D links exposed on the header. As documentation is really sparse I'm having some trouble with this.
2. Create a lightweight negociation protocol which can recognize links as soon as they are connected. (exchanging "HELLO" tokens and configure the switches so that channels can be set up). Perhaps using the new overlays it is possible to free up resources on "slave" boards once the links are properly set up an have 1 board as an orchestrator or something, but I'm thinking way ahead here.....

If anyone's in for a co-op project I'd happily join in.