Hi Paul,
I'd be interested to see what's needed to make it work on XMOS devices.
I note that here..
http://www.xmos.com/discuss/viewtopic.p ... 82&start=0
There is mention that EtherCat should be no problem on XMOS. I have a story related to that...
<memory lane>
Long ago I was employed by Ultra Network Technologies, in San Jose. There I became the unfortunate engineer to have to explain to my VP of Engineering why an elaborate networking switch that was intended to save the company and had had about $16M invested in it was never going to work. (I joined the project after all the achtecture was done -- not my fault :) ) . Among other things, my job was to write the code that would route all packets from one adapter plugged into the switch, over to another adapter in the same switch. Each adapter could be one of about 6 families, including FDDI, Sonet, Ethernet, BMC ,etc, and would contain masses of ports of that type - so the Ethernet had 16 Ethernet ports per adapter, for example. Many of the adapter designs were already available as prototypes, and some already had code running on them, but none of them had ever spoken across the switch.
So I rolled up my sleeves, and started writing code. Pretty soon I had my first packet across the switch, just to understand the basics, then I started looking in earnest at the task, and began structuring everything for performance. I hated that the switch design required software polling in order to establish a connection. The setup time was a minimum of about 15 i960 cycles, and compared with that the packet-time was long, so it made no sense to keep hitting a node that was busy, while traffic for other nodes was hanging around. So one would cycle around the queues of outbound packets, hoping to find a destination port that was open. If you've ever done anything like this you'll quickly recognize the problem. Totally non-deterministic.
This fiasco fits in the generic class of hand-wave-solutions, where someone does the back-of-the-envelope calculations without spotting a fatal flaw. They are so convinced that the problem is doable, that they don't want to waste time taking a few days simulating the solution. Annoyingly, such a switch would have been relatively easy to simulate. That simulation would have recognized that a *tiny* bit more hardware support could have queued the switch requests, and demanded a callback/interrupt when the first connection had been granted across the switch. A chained DMA queue on input and output from the switch would have been icing on the cake, but not strictly necessary.
The funny part (in retrospect) was when I spoke with the leading hardware guy (Dean) who had implemented the ASICs for the switch, when I told him we'd never reach our performance goals. He was sure I was wrong, and there should have been *loads* of bandwidth and time. Of course, he *knew* my code must have been wasting *loads* time. But, this was hand-coded i960 assembler, right down to the metal, and I had been around a bit. Patiently he sat with me for a few hours as I counted out the cycles, and demonstrated the issue. Once he saw that there was no single instruction to cut from the critical loop, and he recognized the probabilistic element, he understood. By then all the money was spent. The layoffs started a week or two later. This was early 90s and Silicon Valley was heaven. I was out of work for half a day - and could only smile ;)
</memory lane>
So such statements that X or Y should be "no problem" without having actually done the engineering, should be taken with a bucket of salt. If anyone has done due diligence, I'd be interested to see it.
<disclaimer> I've looked at Ethercat only very superficially. </disclaimer>
Among lots of other stuff, this is valuable: "Hardware Data Sheet ET1815 / ET1817 - Slave Controller IP Core for Xilinx FPGAs IP Core Release 2.03a". It shows what you get when you purchase the IP. And it's a lot of stuff.
The biggest question is whether the CPU can read the the inbound PHY directly via MII and MDIO sufficiently quickly and then get that data out to the outbound MII without a backlog -- wormhole routing. The MII nibbles need servicing at 25MHz, which seems doable in principle. As usual, it's having to handle exceptional cases that increases latency, with every test and branch. The protocol level tasks add up: clock maintenance, working counter maintenance, link failure detection, managing routing to the next port, interfacing to the next layer up the stack, etc.
Though I'd love to see this running on XMOS, it's only worth the considerable effort if the business plan includes selling a heck of a lot of them. Otherwise, buy Beckhoff.