open EtherCAT, real-time Ethernet automation control

XCore Project reviews, ideas, videos and proposals.
Post Reply
deepocean
New User
Posts: 3
Joined: Wed Jun 02, 2010 8:05 pm

open EtherCAT, real-time Ethernet automation control

Post by deepocean »

real-time Ethernet system is still expensive now.Mostly the hardware is using FPGA.
With multi-threading and local high resolution timer, it is good to build a real-time Ethernet adapter, such like EtherCAT, for automation control system.


http://en.wikipedia.org/wiki/EtherCAT

http://www.ethercat.org/


User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm
Contact:

Post by russf »

This looks pretty interesting.
It looks like any of the existing MAC based Ethernet capable kits could do the master, but the tough part is the slave. Looks as if the key questions are:

1. whether one can get access to the PHY from the core (in other words bypass the MAC).

and

2. can the core respond quickly enough to drop in bits as the telegrams pass through.

Has any of the many members of the EtherCAT Technology Group looked at XMOS?

Edit: I see that XMOS is a member of EtherCat TG, and there was an earlier thread on this topic: http://www.xmos.com/discuss/viewtopic.p ... 82&start=0

Thanks for bringing this up.

--r.
User avatar
paul
XCore Addict
Posts: 169
Joined: Fri Jan 08, 2010 12:13 am
Contact:

Post by paul »

EtherCAT as far as I understand it is a rather nasty protocol that requires you to poke bits in and out of the ethernet frame as it passes through.

They talk in documents about EtherCAT (see http://www.ethercat.org/pdf/english/ETF ... ET_IRT.pdf - top of page 410 (page 4/9 of the doc)) of sub 500ns packet delays between nodes, so to match that you potentially have very little time to get the data through the XCore (like 50 instructions!).

The PHY issue isn't big. XMOS currently interfaces with a standard MII PHY and implements it's own MAC, so access to that level is possible.

Implementation of EtherCAT would be possible, but probably not quite at the speed that the FPGA's can muster (and it sounds like a massive/expensive bit of FPGA IP).
Paul

On two occasions I have been asked, 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm
Contact:

Post by russf »

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.
deepocean
New User
Posts: 3
Joined: Wed Jun 02, 2010 8:05 pm

Post by deepocean »

Oops, I thought this is opensource protocol, if need buy IP core from EtherCAT...maybe try something else? :idea:

For sure, this is an opensource project:
http://www.orocos.org
http://www.orocos.org/orocos/applications/krypton

, looks similar,

by the way , the resolution of xmos timer is 10 ns , right?
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm
Contact:

Post by russf »

EtherCat is open, but you can buy commercial silicon or IP that implements it.

That project is open, but I could not see anything quite like EtherCat within it.

10ns resolution for timer aware ports.

--r
deepocean
New User
Posts: 3
Joined: Wed Jun 02, 2010 8:05 pm

Post by deepocean »

For industrial Ethernet, some new FPGA said support IEEE1588, (really donot know what it is, like timer sync standard for industrial Ethernet).
I think the key feature for Xmos is faster,cheaper Ethernet/IP webserver, right now no MCU can do this.
Now industrial Ethernet can not afford FPGA for all sensor/motor control, if xmos can do this, there is huge market.
User avatar
BEBDigitalAudio
Experienced Member
Posts: 82
Joined: Thu Nov 11, 2010 7:45 pm

Post by BEBDigitalAudio »

Hi all

I am dealing with real-time networks all day long, and there is a long, long history behind EtherCat.
Basically, EtherCat is opened, but up to now, there was only two ways for implementing it :

- buy the silicon solution from Beckhoff (which is nothing more than a FPGA)
- try to write the code by yourself in your own FPGA... this will take months, and you will have to invest into (very) expensive tools to verify your design

Many companies are trying to sell their stuff in that way (Digigram for the Ethersound is another typical example.. apart that they do not even publish their protocol specification). The investment before you get a working product is so big that many companies prefer to buy an IP block from the protocol designer.

But this was before... because now, there is the XMOS approach. And EtherCat can perfectly run on a G2.
The only thing is that it is quite complex to get all documentation for a correct implementation from Beckhoff.

If you really want an open solution for real-time Ethernet, look to Powerlink. All documentation is easily available, and you can even build safety critical applications up to SIL3.

I am currently porting Powerlink on the XS1, and I can tell you that it is really easier and faster than with any FPGA or other silicon solution (and nothing to see compared to EtherCat)
Thompsonian
Newbie
Posts: 1
Joined: Mon Aug 01, 2011 8:34 pm

Post by Thompsonian »

I was just wondering if you've got anywhere with the Powerlink port?
I've just started to investigate EtherCAT for a project but we are also considering Powerlink.

Ian T.
User avatar
davelacey
Experienced Member
Posts: 104
Joined: Fri Dec 11, 2009 8:29 pm

Post by davelacey »

For people interested in ethercat - there is an exploratory github repository on it:

https://github.com/xcore/sc_ethercat

It include some proof of concept code (though this is incomplete I believe).

Dave
Post Reply