Renesas Electronics: RZ-N1 Vom Multi-Chip zum Single-Chip

In der industriellen Automatisierung war es bislang üblich, einen Controller für die Applikation und einen Echtzeit-Switch für die Kommunikation zu nutzen. Mit den bereits vorgestellten RZ/N1-SoCs von Renesas Electronics ist nur noch ein Chip notwendig.

Dieser Chip unterstützt die verschiedenen Industrial-Ethernet-Protokolle.

Ognen Basarovski, Senior Product Marketing Manager, Industrial Automation Marketing bei Renesas Electronics Europe, erklärt die Idee, die hinter den RZ/N1-SoCs steckt: »Heute sind typischerweise Mehrchip-Lösungen für speicherprogrammierbare Steuerungen (SPS), Switches und Bedienterminals notwendig. Wir haben mit der RZ/N-Familie Single-Chip-SoCs entwickelt, die nicht nur über alle notwendigen Funktionsblöcke für die Applikation sowie die Kommunikation verfügen, sondern sich gleichzeitig auch noch durch eine geringe Leistungsaufnahme auszeichnen.« So sind auf den SoCs je nach Ausbaustufe und Anwendungsbereich bis zu zwei Cortex-A7-Prozessorkerne und diverse Schnittstellen, einschließlich LCD-Controller, für die Applikation integriert; für die Ethernet-Kommunikation wiederum stehen ein Cortex-M3 mit einem 5-Port-Echtzeit-Switch und einem Hardware-Beschleuniger mit Multi-Protokoll-Unterstützung zur Verfügung. Die Familie umfasst derzeit drei Komponenten: die leistungsstärksten RZ/N1D-SoCs für High-End-Anwendungen wie Netzwerk-Switches, SPS und Gateways; die RZ/N1S-SoCs für Midrange-Anwendungen wie Nano-SPS und Bedienterminals; die RZ/N1L-SoCs für Low-End-Anwendungen wie Kommunikationsblöcke in Industriegeräten oder Slave-Bausteine wie Remote-I/O-Geräte. Basarovski weiter: »Immer mehr Industriekunden setzen mittlerweile ihren Schwerpunkt auf Software und weniger auf Hardware; auch diesen Trend haben wir mit der RZ/N1-Familie aufgegriffen und umgesetzt.«

Renesas hat auf den RZ/N1-SoCs zwei vollkommen unabhängige Blöcke implementiert, auf denen zwei unterschiedliche Betriebssysteme laufen können. Basarovski: »Dank dieser getrennten Blöcke ist die Kommunikation vollständig unabhängig.« Diese Unabhängigkeit hat technische und kommerzielle Gründe. Technisch gesehen laufen auf beiden Blöcken komplexe Prozesse ab, die unabhängig voneinander funktionieren müssen. In der Kommunikation sind zeitgenaue Prozesse notwendig. Wenn auf der Applikationsseite eine Last auftritt, die viel Rechenleistung benötigt, darf das keine negativen Auswirkungen auf die Kommunikation haben. Basarovski: »Kommunikation und Applikation können auch auf einem Prozessor laufen, aber mit zwei vollkommen getrennten Prozessorwelten stören sie sich nicht.« Hinzu kommt noch, dass die Applikation mehr oder minder statisch bleiben soll; dank der Trennung kann auf der Kommunikationsseite je nach Anwendung einfach und schnell zwischen verschiedenen Protokollen wie EtherNet/IP, EtherCAT, Profinet, Powerlink und Sercos gewählt werden. Basarovski weiter: »Kommerziell gesehen, ist es von Vorteil, sich auf die Applikation zu konzentrieren. Und das macht die R-IN Engine, auf die bereits verschiedene Protokolle mit einer dokumentierten API portiert wurden, möglich. Beide Seiten verbindet nur eine schmale Kommunikations-Schnittstelle.« Damit ist gewährleistet, dass die Implementierung schneller funktioniert und die gemeinsamen Tests geringer ausfallen.

Einen weiteren Vorteil der neuen SoCs sieht Basarovski darin, dass die Applikation auf einem optimierten, leistungseffizienten Core läuft, sprich dem Cortex-A7, der von der Rechenleistung her ähnlich wie der Cortex-A9 ist, aber einen deutlich niedrigeren Leistungsverbrauch aufweist. Die Kommunikation wiederum läuft auf einem Cortex-M3, der ebenfalls eine hohe Leistungseffizienz aufweist und der durch HW-Beschleuniger unterstützt wird.

Basarovski: »Außerdem haben wir bei den SoCs zum ersten Mal im Gegensatz zu den bislang üblichen zwei Ports einen 5-Port- bzw. 3-Port-Gigabit-Switch implementiert, der auch noch fortschrittliche Funktionen wie QoS, Broadcast Storm Protection, Filtering aufweist.« Das heißt, dass der Kommunikationsblock, sprich die R-IN Engine, einen Cortex-M3, HW-Beschleuniger und einen 5-Port-Echtzeit-Switch umfasst.

Hardware-Beschleuniger entlasten die CPU

Bei einer UDP-Übertragungsrate von 50 bis 60 MBit/s ist der Cortex-M3 bereits zu 100 Prozent ausgelastet, also könnte man entweder eine höhere Taktfrequenz oder einen leistungsstärkeren Core wählen. Renesas ist einen dritten Weg gegangen und hat dem Prozessorkern einen Hardware-Beschleuniger beigestellt, wodurch Funktionen des Echtzeitbetriebssystems wie Task-Scheduling und OS-Resource-Management in Hardware gegossen sind. Der Zugewinn ist immens: Selbst bei einer für Industrial Ethernet üblichen Übertragungsrate von 95 MBit/s ist die CPU nur noch zu 30 Prozent ausgelastet, weil der HW-Beschleuniger viel Arbeit übernimmt. Somit können auf dem jetzt entlasteten Cortex-M3 noch einfache Anwendungen laufen und »die Verlustleistung fällt deutlich geringer aus und damit die Wärmeentwicklung«, so Basarovski weiter.