FPGAs
Ein Baustein für alle Protokolle
Fortsetzung des Artikels von Teil 1
Mehrere Protokolle in ein und demselben Baustein
Kann ein und derselbe FPGA-Baustein mehrere verschiedene Busschnittstellen beherbergen bzw. mehrere verschiedene Protokoll-Stacks gleichzeitig abarbeiten?
In einen FPGA lassen sich gleichzeitig verschiedene Kommunikationsprotokolle integrieren. Dies ermöglicht etwa die Implementierung hierarchischer Architekturen wie des Kommunikationssystems eines Roboters, der als Slave einer Zellsteuerung und gleichzeitig als Master einer Robotersteuerung agiert.
Möglich ist es natürlich auch, mehrere Slave-Protokolle für einen parallelen Einsatz in einen FPGA-Baustein zu laden; allerdings sehen wir darin keinen realen Anwendungsfall, weil ein Gerät immer nur in einem Netz eingesetzt wird.
Es gibt mittlerweile Multiprotokoll-Prozessoren auf ARM-Basis wie den »Sitara« von Texas Instruments, der die Protokoll-Software verschiedener Feldbusse und Industrial-Ethernet-Systeme beherbergen kann. Das Unternehmen betont, dass Lösungen auf Basis des »Sitara« keinen externen FPGA- oder ASIC-Baustein mehr erfordern. Könnten solche Prozessoren FPGAs in der industriellen Kommunikation überflüssig machen? Welche Vor- und Nachteile haben FPGAs gegenüber diesen Prozessoren?
Unserer Erfahrung nach sind Gerätehersteller in der Regel an einer Gesamtlösung interessiert. Das heißt, sie wollen nicht für den Protokoll-Stack A nach einem Anbieter suchen und für den Protokoll-Stack B mit einem zweiten Anbieter verhandeln. Vielmehr suchen sie nach einer Lösung aus einer Hand, wie sie von Softing zur Verfügung steht.
Wichtig für die FPGA-Lösung ist auch, dass Softing für alle Kommunikationsprotokolle eine einheitliche Schnittstelle anbietet. Außerdem kann ein Gerätehersteller über die bereits angesprochenen Vorteile hinaus mit dem FPGA-Ansatz zusätzliche Funktionalität erreichen. So unterstützt die Softing-Lösung auch einen transparenten Ethernet-Kanal, über den Standardanwendungen in eine Gesamtlösung eingebunden werden können.
Wie sieht die Energiebilanz der beiden Lösungen aus, gelten doch ARM-Prozessoren als besonders energiesparend?
Die Energiebilanz hängt immer vom konkreten Einsatzfall ab und muss die Gesamtlösung, also auch den eingesetzten Ethernet-PHY oder Spannungswandler, umfassen. So benötigt das Softing-Produkt RTEM nur etwa ein Drittel der Gesamtleistungsaufnahme für den Betrieb des FPGAs. Dementsprechend sind hier nicht nur die Angaben zur typischen Leistungsaufnahme im Datenblatt relevant. Wenn die Leistungsaufnahme dennoch verglichen werden soll, zeigen die von uns gemessenen FPGA-Werte eine ähnliche Größenordnung wie die von Texas Instruments genannten typischen »Sitara«-Zahlen. Darüber hinaus scheint mir wichtig, dass bei unseren bisherigen Diskussionen mit Kunden niemals die Leistungsaufnahme eines FPGAs als K.o.-Kriterium genannt wurde.
Welchen Programmieraufwand hat ein Automatisierungsgeräte-Hersteller, der auf FPGA-Basis verschiedene Feldbus- und Industrial-Ethernet-Schnittstellen in ein bestimmtes Gerät implementieren will?
Mit dem Simple Device Application Interface (SDAI) bietet die Softing-Lösung eine einheitliche Programmierschnittstelle zur Anbindung der Anwendung an die unterstützten Kommunikationsprotokolle. Das bedeutet, dass die Anwendung nicht für jedes unterstützte Protokoll extra angepasst werden muss. Das SDAI bietet eine schlanke Funktionsschnittstelle und ist entsprechend einfach zu verwenden. Es hat seine Leistungsfähigkeit bereits in Tausenden von Automatisierungsgeräten bewiesen.
Darüber hinaus bietet das SDAI die nötige Flexibilität für den Einsatz einer FPGA-Lösung. Es ermöglicht etwa, Anwendung und Kommunikationsanbindung auf einem FPGA-Prozessor zu realisieren, diese Funktionen auf zwei Prozessoren innerhalb eines FPGAs aufzuteilen oder einen separaten Mikroprozessor für die Anwendung zu nutzen.
- Ein Baustein für alle Protokolle
- Mehrere Protokolle in ein und demselben Baustein
- Welchen Programmieraufwand haben Anwender?
Lesen Sie mehr zum Thema
