Protokoll-Engineering und HDL Generierung mittels einer MATLAB/Simulink Stateflow Modellierung

Transkript

1 Protokoll-Engineering und HDL Generierung mittels einer MATLAB/Simulink Stateflow Modellierung Alexander Biendarra init Institut für industrielle Informationstechnik Hochschule Ostwestfalen-Lippe Langenbruch Lemgo alexander.biendarra@hs-owl.de Carsten Pieper Fraunhofer IOSB-INA Anwendungszentrum Industrial Automation Langenbruch Lemgo carsten.pieper@iosb-ina.fraunhfer.de Robert Lindner MathWorks Adalperostrasse Ismanning robert.lindner@mathworks.de Abstract: Protokolle vereinfachen seit den 70er Jahren die Nutzung von Netzwerken und standardisieren deren Implementierung. Ihr Inhalt, welcher innerhalb ihrer Spezifikation festgelegt wird, besitzt oftmals einen beschreibenden Charakter, wie die Funktionalität umgesetzt werden soll. Eine Möglichkeit Abläufe auf eine eindeutige und nachvollziehbare Art darzustellen, bieten Zustandsautomaten mit ihrer Repräsentation in Form von Zustandsdiagrammen. Mit Hilfe des MATLAB/Simulink-Addons Stateflow wird Entwicklern die Möglichkeit gegeben, die Funktionalität eines Protokolls direkt in Form von Zustandsdiagrammen formal umzusetzen. Diese können während der Entwicklung simuliert und anschließend verifiziert werden. Abschließend kann der Automat über die durch den Embedded-Coder gegebene Möglichkeit der Codegenerierung in C oder C++ Code überführt werden. Sollen bestimmte Funktionen, welche durch das Protokoll gefordert werden in Hardware realisiert werden, kann dies über den HDL-Coder realisiert werden, wobei Code in den Beschreibungssprachen Verilog-HDL oder VHDL generierbar ist. Durch den breiten Funktionsumfang, welchen MATLAB/Simulink bietet, ist es möglich den gesamten Entwicklungsfluss, von der Modellierung über die Simulation, Verifikation und die anschließende Codegenerierung zu realisieren. Weitere Vorteile ergeben sich in der Schnittstelle zu den Simulationswerkzeugen ModelSim der Firma Mentor Graphics oder Incisive der Firma Cadence. Durch diese Schnittstelle kann eine Testbench, oder bereits vorhandener Code in Verilog-HDL oder VHDL für eine Verifikation herangezogen werden. 1 Einleitung Das Engineering von Protokollen erfolgt heutzutage mit formalen Beschreibungstechniken. Aus dieser Beschreibung wird dann die Implementierung in Programmiersprachen wie C oder C++ umgesetzt. Bestimmte Aspekte bzw. Funktionen welche in einem Protokoll spezifiziert sind, werden zudem immer häufiger in Hardware implementiert. Gründe hierfür können ein Performancegewinn oder die Entlastung der eingesetzten CPU sein. Auch im Bereich von echtzeitkritischen Funktionalitäten wird die Umsetzung in Hardware herangezogen, um eine deterministische Verarbeitungszeit zu garantieren. Diese erfolgt dann in Hardwarebeschreibungssprachen wie Verilog-HDL oder VHDL, um eine synthesefähige Beschreibung der Funktionalität zu erhalten. Ein Ansatz, die Beschreibung der zugrunde liegenden Funktionalität welche ein Protokoll beinhaltet ist, diese in Form einer formalen Beschreibungsform abzubilden. Dies kann ein Zustandsautomat mit seiner Repräsentationsform des Zustandsdiagrammes (gerichteter Graph) sein. Den besagten Ansatz nutzt das MATLAB/Simulink-Addon Stateflow. Hiermit ist eine Umsetzung der

2 Funktionalität in Form von Zustandsdiagrammen möglich, welche zudem auch die Anforderungen der Echtzeitfähigkeit erfüllen können. Innerhalb der Produktpalette, welche von MathWorks zu Verfügung gestellt wird, ist die Simulation, Verifikation sowie eine anschließende Generierung von C, C++, Verilog- HDL oder VHDL Code möglich. Im Rahmen einer Anforderungsanalyse wurde ausgehend von einer grafischen Beschreibung von Zustandsautomaten (Stateflow Diagrammen) automatisch HDL Code für taktsynchrone industrielle Kommunikationssysteme mit Echtzeitanforderungen erzeugt [JS13]. Das bit-akkurate und taktzyklus-genaue Verhalten des generierten Codes wurde im Vergleich zu einer manuell implementierten Verilog-HDL Beschreibung mittels Simulation verifiziert und die erreichte Fehlerüberdeckung analysiert. Hierzu wurden u.a. die Werkzeuge HDL-Coder und HDL-Verifier von MathWorks eingesetzt und evaluiert. In diesem Dokument wird in Kapitel 2 der Ansatz der Modellierung durch Zustandsautomaten behandelt. Kapitel 3 bezieht sich auf die Möglichkeiten der Simulation während der Entwicklung und zeigt Vorzüge gegenüber dem klassischen Vorgehen im Bereich der Entwicklung von digitalen Systemen. Anschließend wird die Möglichkeit der Verifikation erläutert. Die letzten Kapitel behandeln die Codegenerierung und eine Gegenüberstellung des automatisch erzeugten und dem manuell implementierten HDL Code. 2 Modellierung Für die Modellierung der Zustandsautomaten unter Stateflow stehen u.a. die Automatentypen Mealy und Moore zur Verfügung. Sollen Teilaspekte eines Protokolls in Hardware realisiert werden, wird Seitens MathWorks eine Abbildung mit Hilfe eines Moore-Automaten empfohlen. Der Ablauf der Modellierung ist hierbei folgender: Jede Modellierung startet mit der Erzeugung eines Charts, welches die Grundlage für die Erzeugung eines Zustandsautomaten ist. Innerhalb dieser, stehen dem Entwickler sämtliche Komponenten zur Verfügung, welche für das Erstellen von Automaten benötigt werden: Zustände, Transitionen, Verzweigungen und Starttransitionen. Zudem besteht die Möglichkeit, Zustände nebenläufig zu modellieren, wodurch eine Leader-Follower Beziehung erreicht werden kann. Auch das Modellieren einer Hierarchie zwischen verschiedenen Zuständen ist realisierbar. Die verschiedenen Komponenten können nun über eine grafische Benutzeroberfläche per Drag and Drop miteinander verschaltet werden, um die gewünschte Funktionalität abzubilden [AB11]. Abbildung 1: Zustandsdiagramm Der abgebildete Automat besitzt eine Transition, welche nicht für die eigentliche Funktion benötigt wird. Dennoch stellt sie einen nicht zu vernachlässigenden Mehrwert für die grafische Modellierung dar. Sie erhöht die Lesbarkeit des Modells und gibt dem Automaten eine klarere Struktur. Diese Art der Modellierung wurde innerhalb des MathWorks Automotive Advisory Boards (MAAB) festgehalten und sollte von jedem Entwickler innerhalb eines Projektes berücksichtigt werden. Neben den Festlegungen für die Art der Modellierung von Zustandsdiagrammen sind außerdem Namenskonventionen und Modellierungsrichtlinien von Kontrollstrukturen wie beispielsweise Schleifen oder Anweisungen eindeutig spezifiziert. Die durch die MAAB erarbeiteten Control Algorithm Modeling Guidlines using MATLAB, Simulink, and Stateflow sind in der Version 3.0 über die Onlinepräsents von MathWorks einzusehen [TM14].

3 Während bei der Modellierung von Funktionalitäten von Protokollen, welche im späteren beispielsweise in C-Code überführt werden, die bekannten Datentypen wie Integer oder Boolean direkt eingesetzt werden können, verhält es sich bei der Erstellung von Modellen für die spätere Generierung in Verilog-HDL oder VHDL Code anders. Auch Zuweisungen der Form out_data[2] = 1 b0, also der Belegung des dritten Bits eines Vektors mit dem Wert Null, welche bei der direkten Implementierung in einer der besagten HDL- Beschreibungssprachen das Arbeiten mit Bitvektoren durchaus erleichtern, sind in Stateflow ohne weiteres nicht möglich. Abhilfe schafft hier zum einen der für Gleitkommazahlen geeignete Datentyp fixdt und zum anderen eine Schnittstelle von Stateflow zu MATLAB. Der Datentyp fixdt kann über den Modellexplorer, einer Oberfläche zum Verwalten von Variablen, Signalen und Events, während der Deklaration von Variablen insoweit verändert werden, dass er bei einer anschließenden Generierung den Charakter einer Signaldeklaration der Form reg [n:0] annimmt. Hierzu muss während der Deklaration folgendes eingehalten werden: fixdt ist Standardmäßig so festgelegt, das bei der Erstellung drei Parameter in der Form fixdt(x,y,z) vergeben werden müssen, wo x für die Aussage steht ob es sich um einen Vorzeichenbehafteten Wert handelt, y die gesamte Wortlänge angibt und z die Anzahl der Nachkommastellen mit einem Wert versieht. Entsprechend kann dann anhand einer Gleitkommazahl die binäre Repräsentation des Wertes dargestellt werden. Zur Deklaration eines Registers mit einer Länge von 48 Bits wird der Datentyp folgendermaßen angepasst: fixdt(0,48,0). Hieraus entsteht durch die Codegenerierung ein 48 Bit breites Register. Auf dieselbe Art können alle benötigten Registergrößen bis zu einem Maximum von 128 Bit erzeugt werden. Ein weiterer Punkt ist, wie bereits angesprochen, das Stateflow nicht die Möglichkeit bietet, die mit Hilfe des Datentypen fixdt erstellten Register an einer bestimmten Bitstelle auszuwerten oder nur eine bestimmte Breite des Vektors mit einem Wert zu belegen. Um dieser Modellierungseinschränkung zu begegnen ist es möglich, über sogenannte MATLAB functions einen Baustein in das Chart einzufügen, welcher im inneren eine Teilmenge des Funktionsumfanges von MATLAB und die Möglichkeit des Programmierens eines.m- Files zu Verfügung stellt. Mit Hilfe eines einzelnen Funktionsaufrufes ist es hierdurch möglich, ein bestimmtes Bit eines Vektors auszuwerten, oder aber jedoch ein oder mehrere Bits des Vektors zu verändern. Diese Funktion kann anschließend über einen Funktionsaufruf ähnlich wie in C oder MATLAB selbst innerhalb von Zuständen für Zuweisungen, oder im Bereich von Bedingungen genutzt werden [AB11][BA14]. 3 Simulation & Verifikation Auch wenn das Vorgehen zur Modellierung der Funktionalität eines Protokolls einige Unterschiede gegenüber dem klassischen Ansatz aufgezeigt hat, kann die Simulation, welche von Simulink und Stateflow bereitgestellt wird auf gleiche Weise genutzt werden. Sobald eine Teilfunktionalität modelliert wurde, und diese durch den Compiler übersetzt werden konnte, kann diese auch simuliert werden. Für den Entwickler von Software mag dies im ersten Augenblick keinen wirklichen Mehrwert darstellen, für sein Pendant im Bereich der Hardware ist dieser Unterschied jedoch immens. Bei einer klassischen Implementierung eines digitalen Systems in Verilog-HDL oder VHDL ist eine Simulation nur in Verbindung mit einer Testbench möglich, welche ebenfalls implementiert werden muss. Für eine Simulation des Modells wird eben diese nicht benötigt. Um die grundlegende Funktionalität zu testen, kann über die in Simulink zur Verfügung gestellten Bausteine eine Simulation durchgeführt werden. Stimuli können manuell über Konstant-Blöcke, Signal Generatoren oder den Signal-Builder generiert werden. Die Ausgaben können mit Hilfe des Scopes oder durch Displays in Form von Zahlenwerten in verschiedenen Darstellungsformen wie beispielsweise dezimal, binär oder hexadezimal dargestellt werden. Werden Eingangssignale über Constant Blöcke für die Signalerzeugung genutzt, können diese beispielsweise in Verbindung mit dem Baustein Manual Switch zur Laufzeit vom Anwender angepasst werden. Der Signalfluss innerhalb des Zustandsautomaten wird zudem während der Simulation grafisch dargestellt, sodass das Verhalten des Automaten analysiert werden kann. Um trotz hoher Abtastraten das Verhalten des Modells lückenlos beobachten zu können, kann die Simulationszeit verzögert werden.

4 Abbildung 2: Simulation eines Zustandsdiagrammes Sollte es zu einem Fehlverhalten des modellierten Automaten kommen, kann dieses mit Hilfe eines in Stateflow integrierten Debuggers untersucht werden. Über diesen besteht die Möglichkeit die Simulation schrittweise ablaufen zu lassen, Breakpoints in den Automaten einzufügen, oder aber die Simulation nach einer definierten Anzahl von Simulationsschritten anzuhalten. Auch der Zeitpunkt, wann ein Breakpoint ausgeführt werden soll, sei es wenn der Zustand betreten, man sich bereits darin befindet oder der Zustand verlassen wird ist frei wählbar [AB11]. Nach der abgeschlossenen Modellierung und ersten Simulationen, gilt es durch die Verifikation sicherzustellen, dass das Modell so wie in der Spezifikation gefordert umgesetzt wurde. Hierzu ergeben sich verschiedene Möglichkeiten diesen Nachweis der funktionalen Korrektheit zu erbringen. Im Folgenden werden die verschiedenen Ansätze näher erläutert. Simulink bietet für die Verifikation der erstellten Modelle verschiedene Ansätze. Neben der ausschließlich durch Simulink durchgeführten Verifikation bietet es mit der Schnittstelle zu den Simulationsumgebungen ModelSim der Firma Mentor Graphics oder Incisive der Firma Cadence weitere Möglichkeiten. Diese sind in der folgenden Abbildung dargestellt. Die in Abbildung 3a) dargestellt Variante, welche als Co-Simulation bezeichnet wird, eignet sich zur Verifikation mit Hilfe eines Referenzobjektes welches aus der Spezifikation abgeleitet wurde. In diesem Fall kann dies ein in Verilog-HDL oder VHDL geschriebenes Referenzmodul sein. Abbildung b) zeigt einen Ansatz wo die Schnittstelle zum Simulationstool für die Erzeugung der Stimuli und das Auswerten der Ausgangssignale verwendet wird. Abbildung c) zeigt ein Vorgehen, wo ausschließlich die Stimuli innerhalb des Simulationstools erzeugt werden. Dieses eignet sich beispielsweise bei Regressionstests, wo eine bereits vorhandene Testbench in einer Hardwarebeschreibungssprache genutzt wird. Abschließend zeigt Abbildung 3d) einen Ansatz indem nur die Auswertung der Ausgangssignale innerhalb des Simulationswerkzeuges analysiert werden.

5 Abbildung 3: Verifikationsmöglichkeiten Für die Verifikation von Modellen, welche im späteren für die Generierung von digitalen Systemen eingesetzt werden sollen, bietet Simulink die Möglichkeit der simulativen Verifikation durch Co-Simulation. Diese kann auf zwei Arten durchgeführt werden. Zum einen kann das modellierte Modell gegen ein Referenzmodell getestet werden, zum anderen besteht die Möglichkeit durch eine von Simulink bereitgestellte Schnittstelle zu den Simulationswerkzeugen ModelSim der Fa. Mentor Graphics oder Incisive der Fa. Cadence, eine Referenz in Form von Verilog-HDL oder VHDL Code einzubinden. Letzteres steht nach der Erzeugung als ein Simulink Funktionsblock zur Verfügung. Durch Parametrierung der Modelle, während der Erzeugung, können der oder die Takte und das Reset-Verhalten mit dem Zeitverhalten der Simulation in Simulink auf eine gemeinsame Basis gestellt werden, wodurch das synchrone ausführen des Modelles und der Referenz ermöglicht wird. Für das Stimulieren beider Komponenten kommen, wie bei der Simulation, Konstant-Blöcke, der Signal Generator oder aber der Signal Builder zum Einsatz. Letzterer lässt sich für das Erzeugen bestimmter Stimuli Sequenzen einsetzten, wobei die Sequenzdauer und die Anzahl der Signalwechsel grafisch vom Anwender parametriert werden kann. Über das Verschalten der jeweils identischen Eingänge der Komponenten mit dem Signal Builder können nun beide synchron in ihrem Verhalten beeinflusst werden [TC08]. Abbildung 4:Co-Simulationsmodell Abbildung 5: Signal Builder

6 Die Auswertung der Signale, welche von der Referenz und dem zu verifizierenden Modell ausgegeben werden, können auf unterschiedliche Art analysiert werden. Zum einen ist es möglich dies über Assertions in Form von Simulink Bausteinen zu realisieren, zum anderen können Signale während eines Verifikationsdurchlaufes aufgezeichnet und anschließend mit dem Simulation Data Inspector verglichen werden. Soll das Ziel der Verifikation durch Assertions gezeigt werden, werden diese mit den jeweils identischen Ausgängen von Modell und Referenz in Verbindung mit einem vorgeschalteten Vergleicher- Baustein verschaltet. Solange sich Modell und Referenz Taktsynchron zueinander verhalten wird der Verifikationsdurchlauf fortgesetzt. Verhalten sich die Signale nicht Synchron zueinander wird der Durchlauf abgebrochen und eine definierte, oder aber vom Anwender angepasste Fehlermeldung ausgegeben. Sollen Signale aufgezeichnet, um anschließend über den Simulation Data Inspector ausgewertet werden zu können, müssen diese vor dem Durchlauf festgelegt werden. Nach einem beendeten Durchlauf können diese dann anhand des Signalverlaufes während der Verifikation analysiert werden. Es besteht zudem auch die Möglichkeit einzelne Durchläufe miteinander zu vergleichen, um möglicherweise Unterschiede feststellen oder bewerten zu können. Die aufgezeichneten Signale werden anschließend in einem gemeinsamen Diagramm dargestellt. In einem weiteren Diagramm wird zudem die Signalabweichung dargestellt. Da die Signale bezogen auf die Zeit eines Durchlaufes dargestellt werden, kann ein Fehlverhalten auf den ersten Blick zeitlich eingegrenzt werden, wodurch die Fehlersuche verkürzt wird[ba14]. Abbildung 4: Signal Data Inspector 4 Codegenerierung am Beispiel von Verilog-HDL Abschließend muss das Modell für die Codegenerierung vorbereitet werden. Hierzu wird in einem ersten Schritt aus dem Modell ein Subsystem erzeugt. Subsysteme stellen innerhalb von Simulink die Möglichkeit dar, bestimmte Funktionalitäten zu einem eigenständigen Baustein zusammen zu fassen. Im Falle der Codegenerierung wird durch das Subsystem das Top-Level Modul repräsentiert, welches die Schnittstellen zur Außenwelt bereitstellt. Das Eingebettete Chart, welche den Zustandsautomaten enthält wird nach der Generierung als ein Modul des Top-Levels dargestellt. Somit wird die klassische Struktur einer Hardwarekomponente erzielt. Im nächsten Schritt müssen die für die Beschreibung spezifischen Parameter angepasst werden. Hierzu zählt die Entscheidung ob aus dem Modell Verilog-HDL oder aber VHDL Code generiert werden soll. Des Weiteren müssen Bezeichner für den Takt und den Reset festgelegt werden. Auch das Reset-Verhalten, ob es sich um einen synchronen oder asynchronen Reset handelt und ob er Active-Low oder Active-High realisiert werden soll. Auch die Festlegung ob während der Generierung Reports erzeugt werden sollen, welche sich beispielsweise auf den Ressourcenverbrauch beziehen, kann bestimmt werden. Abschließend kann über eine Prüfsequenz festgestellt werden, ob im Vorfeld weitere Anpassungen vorgenommen werden müssen, welche ansonsten eine Codegenerierung verhindern würden. Wird der

7 Generierungsprozess nun angestoßen, steht binnen kurzer Zeit, je nach Komplexität und Größe des Modells der generierte Code zu Verfügung. Die durch die Generierung gewonnene Hardwarebeschreibung in Verilog-HDL hat die in Abbildung 7 dargestellte Struktur. Die innerhalb des generierten Codes vorhandenen Kommentare werden von Simulink während der Generierung automatisch in den Code eingefügt. Sie befinden sich innerhalb des Modells an Transitionen oder im inneren von Zuständen und können individuell angepasst werden. Des Weiteren dienen sie zur Navigation zwischen dem generierten Code und dem zugrunde liegenden Modell. Durch diese ist es möglich, direkt aus dem Modell an die entsprechende Stelle des Codes zu gelangen, oder aber vom generierten Code zum Modell. Dies ist ein weiterer Vorteil in Bezug auf die Lesbarkeit und das Verständnis der umgesetzten Funktionalität[FD12]. Abbildung 5: Generierter Verilog-HDL Code 5 Bewertung des generierten Verilog-HDL Codes Um eine Aussage darüber treffen zu können, ob der über das Modell erzeugte HDL-Code dieselben Anforderungen in Bezug auf den Ressourcenverbrauch und das Timing auf der Zielplattform erfüllt, wurde der generierte Code mit dem Referenz Design verglichen. Hierzu wurden Synthesen durchgeführt, welche anschließend ausgewertet wurden. Ergebnis dieser Auswertung war, das der durch das Modell erzeugte Verilog-HDL Code einen geringfügig höheren Ressourcenverbrauch in Bezug auf benötigte Register besitzt als die manuelle Implementierung. Dieser bewegt sich allerdings, im Falle dieser Evaluierung, in einem Rahmen, welcher nicht dazu führt das Hardware eingesetzt werden muss, welche einen größeren Ressourcenvorrat vorhält. Da dieser Platz ohnehin vorhanden ist, kann er auch genutzt werden und es stellt keinen Nachteil zur manuellen Implementierung dar. Im Bereich des Timings, der Setup- und Holdzeiten der verschalteten Register bewegt sich der generierte Code im selben Bereich wie die manuelle Implementierung. Bei einer Systemtaktfrequenz von 100 MHz liegen die Werte des Slacks wie in Abbildung 8 dargestellt bei einem Unterschied von 0,119ns, was ca. 1% der Zeit einer Taktperiode entspricht. Der Slack ist ein Indikator dafür, ob ein digitales System Daten stabil, im Sinne von Fehlerfrei zur richtigen Zeit, zwischen den einzelnen Registern überträgt. Der hier Abgebildete Setup-Slack berechnet sich aus der Differenz zwischen dem Zeitpunkt, wo Daten benötigt werden und dem wo die Daten vorhanden sind. In diesem Fall sieht man im Diagramm (a) einen Setup Slack von 9,225 ns bei der Referenz, was Aussage darüber gibt, dass die Schaltung stabil arbeitet, was auch im Falle des generierten Codes (b) zutrifft. Das ein nahezu identisches Timing erreicht wurde ist ein Anhaltspunkt dafür, das auch mit dem Ansatz der Modellierung durch Stateflow bit-akkurate und taktzyklus-genaue Datenverarbeitung erreicht werden kann, was im Bereich von echtzeitkritischen Funktionen eine zwingend zu erfüllende Anforderung ist [BA14].

8 Abbildung 6: Gegenüberstellung des Timings der Referenz (a) und des generierten Codes (b) 6 Zusammenfassung Das vorgestellte Vorgehen zur Umsetzung von Protokollfunktionalitäten in Hardware hat gezeigt, dass es möglich ist auf Basis einer formalen Beschreibungsmethode durch Zustandsdiagramme Verilog-HDL Code zu erzeugen. Dieser ist synthesefähig und gibt zudem die Möglichkeit Echtzeitanforderungen in Modellen abzubilden und mit Hilfe des HDL-Coder in Verilog-HDL Code umzusetzen. Durch das Modellieren der Funktionalität in Zustandsdiagrammen wird eine nachvollziehbare und klar strukturierte Möglichkeit gegeben ein Protokoll abzubilden. Grade im Bereich Sicherheitskritischer Anlagen kann dies einen Mehrwert bedeuten, da somit die voneinander abweichende Umsetzung einer Funktionalität gut dargestellt werden kann. Im Bereich der Simulation besitzt der vorgestellt Ansatz einen klaren Vorteil zum bisherigen Vorgehen im Bereich der Entwicklung digitaler Systeme. Durch die Möglichkeit die Automaten, dessen Funktionalität im späteren eins-zu-eins in Verilog-HDL umgesetzt werden, mit den durch Simulink bereitgestellten Bausteinen zu simulieren, erspart dies das Erstellen einer Testbench in der Taktsignale, Resetsignale und die Stimuli für die Eingänge implementiert werden müssen. Bei der Durchführung der Verifikation kann ebenfalls auf die Bausteine von Simulink zurückgegriffen werden. Zudem bietet die Schnittstelle zu den Simulationsumgebungen ModelSim oder Incisive die Möglichkeit bereits vorhandene Testbenches, Referenzcode oder Stimuli während der Verifikation zu nutzen. Die Gegenüberstellung der Ergebnisse bezüglich des Ressourcenverbrauchs und des zugrunde liegenden Timings von Referenz- und Generiertem-Code hat gezeigt, dass durch den Ansatz der Codegenerierung ein annähernd identischer Verbrauch an Ressourcen in Bezug auf die Anzahl von benötigten Registern erzielt wird. Auch das Timingverhalten ist mit einem Unterschied von ca. 1% in Bezug auf den Slack, bei gleichem Constraining beider Systeme, annähernd identisch. 7 Literaturverzeichnis [JS13] Informationsportal für Echtzeit-Ethernet in der Industrieautomation, Jürgen Schwager, [AB11] Angermann, A; Beuschel, M; Rau, M; Wolfarth, U: MATLAB Simulink Stateflow. Oldenbourg Verlag, 2011 [TM14] Control Algorithm Modeling Guidelines Using MATLAB, Simulink,and Stateflow, The Mathworks Inc., [BA14] Biendarra, A.: Evaluierung eines modellbasierten Entwicklungsprozesses für die automatische HDL- Codegenerierung mittels MATLAB/Simulink [TC08] Errkinen, T; Conrad, M: Verification, Validation, and Test with Model-Based Design. The Mathworks, 2008 [FD12] Filipova, K.V; Dimov, T: Model Based Hardware Design with Simulink HDL Coder. International Conference Challenges in Higher Education and Research in 21th Century, 2012