XScope Hardware Questions

[gerrykurz]

I am developing an application using two L16 parts. Right now I have most of it working on two L16 slice kits. The master board tiles are labeled 0 and 1, the slave board tiles are labeled 2 and 3 in the xn file.

I currently have a 5 wire xConnect link between XLB of tile 1 on the master board and XLB of tile 2 on the slave board. I would like to add a second 5 wire xConnect link using XLA of tile 1 on the master board to either XLA or XLB of tile 3 on the slave board.

My question is around the hardware implementation of xScope. On the master board, xScope uses a 2 wire xConnect link using XLA of tile 0. Does it also need to use XLA of tile 2 on the slave board to have xScope functionality on the slave board?

Can the extra pins of XLA not used by xScope be used for I/O? I would like to eliminate the SPI mux circuit and just hardwire the spi interface to the flash memory and hardwire the xScope link to the plug chain connector.

[Bianco]

My question is around the hardware implementation of xScope. On the master board, xScope uses a 2 wire xConnect link using XLA of tile 0. Does it also need to use XLA of tile 2 on the slave board to have xScope functionality on the slave board?

You only need one link to the XTAG2 debug adapter for a multi-package setup.
So if it is already connected to the first board, the XLA of the second board is free for use.

Can the extra pins of XLA not used by xScope be used for I/O? I would like to eliminate the SPI mux circuit and just hardwire the spi interface to the flash memory and hardwire the xScope link to the plug chain connector.

The pins used for a 5-wire link but not by a 2-wire link can use their normal function when the link is in 2-wire mode. xScope is 2-wire.

[segher]

Why do you want to add this extra link? A triangle (as you
would have with nodes 1-2-3) cannot be optimally routed (*),
and AFAIK the tools cannot handle it at all either. If you want
extra bandwidth or cocurrency you're much better off adding
a second link 1-2.

(*) Consider the highest node id bit that is not the same for
all three nodes; one node (call it X) has it different from the
other two (Y and Z). Now X will route messages to Y and
Z identically.

[gerrykurz]

I don't really understand your reply. I am trying to reduce latency in ethernet packet forwarding.

By having packets routed from tile 1 to tile2 and then onto tile 3, I am adding an extra xConnect link which will increase latency.

I don't understand why I cannot route tile 1 xla to tile 3 xla and tile 1 xlb to tile 2 xlb directly in hardware.

See the attached schematic pdf....

[segher]

The extra hop adds latency, sure, but very little. Did you
measure it?

"Routing" refers to how messages are steered through the
network, not to laying out wires on a board :-)

[gerrykurz]

OK, I admit that I am a hardware guy and I don't understand the intricacies of the tools and the compiler nor do I want to. I just want to make it work for my application with the minimum amount of effort, like everyone else wants to do. (Well that is my core assumption)

Yes, I have measured the latency's and for the most part it is pretty good using only one 5 wire channel between the two parts but there is some extreme differences as well. The range is from 200 usec to 8 msec. I admit that I have not had the time to track down this discrepancy.

However, as a hardware engineer, I have to disagree with your basic premise. At the lowest level, all "routing" occurs over wires whether they are on a pcb between parts or inside of a chip between "cores" in this instance.

You have still not answered my basic question as to why the "routing" that I have proposed in "hardware" will not work with the tool set or have given me an alternative that will meet my design goals.

My application is professional audio and there is a market place bias that audio latency is an issue whether or not people can actually perceive it or not. I cannot control this bias, I can only try and design products that will meet my clients requirements and my clients market design criteria whether I agree with them or not.

I am trying to design a hardware implementation that will give me the lowest latency with limited experience with XMOS chips and XMOS tools.

I would appreciate an explanation of why my hardware design is not optimal and what alternatives there are to achieve my design goal of lowest latency.

With regards,

Gerry

[gerrykurz]

OK, I have looked into this in the XMOS documentation.

Are you saying that the compiler will not handle my implementation without specifying the network topology manually in the xn file?

My proposed network topology is not a triangle, it is a tree with with node 1 (tile 1) having links to nodes 0, 2 and 3.

By properly specifying the switch node id's, direction tables and link directions, I can't see why my network topology won't work.

[segher]

A tree can route optimally, yes. Nodes 2 and 3 have four
nice fast links between them (inside the package) but you
can opt not to use them.

But AFAIK the tools will still not be able to do the initialisation:
straight lines work, and nothing else does, last I heard.

I also still think it is useless -- the jitter in the latency (which
you will need to correct for anyway) is bigger than the
improvement you get from saving one hop.

[gerrykurz]

Well according to the published documentation (at least as I read it), a tree configuration will work fine as long as it is specified in the xn file.

And yes the latency jitter is an issue that I need to deal with.....

However, with two bidirectional 5 wire links, one from master tile 1 to slave tile 2 and one from master tile 1 to slave tile 3, there exists the possibility of setting up two fully bidirectional steaming links to get the absolute minimum latency possible.

If there is an XMOS hardware expert out there that can verify all of this, I would greatly appreciate it....