5. Implementierung

Die in Kapitel 4 vorgestellte modellbasierte Entwicklungsmethode baut in ihrer Implementierung auf verschiedenen Tools aus den Bereichen der Eingebetteten Systeme und der Systementwicklung auf. Daher werden nachfolgend die für die Umsetzung der Methode essenziellen Tools vorgestellt und der Nutzen für die hier vorliegende Methode beschrieben.

Im folgenden Abschnitt wird die Anwendung der in dieser Arbeit entwickelten modellbasierten Entwicklungsmethode auf die Systemkonzeptentwicklung anhand eines Beispiel-Auswerte-SoCs beschrieben. Dazu wurde im Zuge der hier vorliegenden Arbeit die Modellierung des Auswerte-SoCs durchgeführt. Die so erhaltenen Diagramme sollen nachfolgend zur Veranschaulichung der modellbasierten Entwicklungsmethode dienen.

Eine Sonderrolle erhält hierbei das Package Diagram, da es Teil der in dieser Arbeit entwickelten Modellierungsmethode, jedoch nicht Teil der Formalisierung ist. Grund hierfür ist die Verwendung des Package Diagram rein zur Modellierung der Modellstruktur selbst. Es wird somit nicht zur Modellierung des SoCs beziehungsweise dessen Umfelds verwendet. Die Modellierung der Modellstruktur als Package Diagram dient in erster Linie zur schnelleren Navigation im Modell, da die Anwender/-innen hierdurch zum einen Informationen über die Struktur des Modells enthalten und zum anderen über Verlinkungen schnell in die entsprechenden Diagramme des Modells navigieren können. Abbildung 5.1 zeigt die in der hier vorliegenden Arbeit entwickelte und in Abbildung 4.​4 dargestellte Modellstruktur, angewendet auf den in diesem Abschnitt zugrunde liegenden Auswerte-SoC als Beispiel.

Das Package Diagram genannt „StartPage“ zeigt die in dieser Arbeit definierte Modellstruktur anhand der Packages System Context Model, Functional Model, Technical Model und Behavioral Model und stellt zudem die wichtigsten Diagramme des jeweiligen Submodells als Block, inklusive Abbildung des Diagramms, dar. Die Abbildungen der Diagramme dienen dabei lediglich als Orientierungshilfe und werden im Verlauf der Arbeit näher betrachtet. Über die in der oberen rechten Ecke der Blöcke enthaltenen Buttons wird es den Anwendern/-innen ermöglicht, direkt zu dem jeweiligen Diagramm zu navigieren. Die finale Modellierung einer solchen StartPage ist in der Regel erst zu einem späteren Zeitpunkt der Konzeptphase möglich. Eine generalisierte Version wird den Anwendern/-innen jedoch als Teil des Automotive-SoC-Profils zur Verfügung stehen. Die Zurverfügungstellung der Modellstruktur als Teil des in dieser Arbeit entwickelten Automotive-SoC-Profils bietet dabei folgende Vorteile:

Die modellbasierte Entwicklung des SoCs beginnt, wie in Kapitel 4 beschrieben, in der Regel mit der Analyse der Anwendungsfälle und damit der Kundenforderungen. Hierzu dient das in Abbildung 5.2 dargestellte Use Case Diagram, genannt Use Case Analysis als Beispiel.

Auf der linken Seite des hier dargestellten Use Case Diagram sind die Systeme des übergeordneten Systems zu sehen, welche mit dem Auswerte-SoC interagieren bzw. mit denen der Auswerte-SoC interagiert. So wurde beispielsweise als Teil des hier gezeigten Use Case Diagram der Anwendungsfall „readout pressure signal“ modelliert. Hierbei wird das Drucksignal von einer der in der Abbildung 5.2 dargestellten „Engine Control Units“ (ECUs, Motorsteuergeräte) vom SoC angefordert. Um dieses Drucksignal an die ECU liefern zu können, benötigt der SoC wiederum eine Interaktion mit dem Sensormodul, welches den aktuellen Druck misst.

Neben den Systemen des übergeordneten Systems wurden in diesem Beispiel auf der rechten Seite des Diagramms bereits Schnittstellen zur Fehleranalyse und zum Wafer-Level-Test dargestellt und die dafür benötigten Anwendungsfälle analysiert. Die Abbildung 5.2 veranschaulicht zudem die Möglichkeit, die Standardsymbole des Use Case Diagram durch eigene Symbole zu ersetzen. Diese Funktion lässt sich auf beliebige Modellelemente in allen Diagrammen anwenden. Die Nutzung sollte sich jedoch auf das Use Case Diagram beschränken, um in Diagrammen wie BDDs und IBDs weiterhin eine grafische Wiedererkennbarkeit der Modellelemente zu erhalten.

Zusätzlich zur Analyse des Anwendungsfalls wurden eine Analyse und eine Modellierung des technischen Systemkontexts durchgeführt, deren Ergebnis in Abbildung 5.3 dargestellt ist.

Das System Context Diagram zeigt den Auswerte-SoC als Part in der Mitte des Diagramms sowie die externen Systeme, welche mit dem Auswerte-SoC interagieren. Wenn möglich, sollte hier die physikalische Anordnung der Systeme im übergeordneten System eingehalten werden. Neben den Systemen beinhaltet das System Context Diagram die Darstellung der Ports und spezifiziert bereits einige Eigenschaften des Auswerte-SoCs mittels Tags. Darüber hinaus wurden in diesem Diagramm Standardelemente, in diesem Fall Kondensatoren modelliert, um die Beschaltung des Auswerte-SoCs zu veranschaulichen. Diese Elemente wurden, wie in Abschnitt 4.​1.​3, als vorgefertigte Templates aus dem in dieser Arbeit entwickelten Automotive-SoC-Profil in das hier gezeigte Diagramm kopiert. Zudem wurden den in Abbildung 5.3 enthaltenen Parts vordefinierte Ports aus dem SoC-Profil zugeordnet sowie dem Part itsAuswerteSoC die Tags ASIL_level und Vendor hinzugefügt.

Aufbauend auf der Analyse der Anforderungsfälle folgt als Teil der hier entwickelten Modellierungsmethode die Dekomposition der Funktionen. Hierzu werden zu Beginn aus den Anwendungsfällen Funktionen abgeleitet. In diesem Fall zeigt Abbildung 5.4 die abgeleiteten Funktionen „readout-pressure-Sensor“ als Allokation des Anwendungsfalls „readout-pressure-Signal“ und die Funktion „readout_Temperature“ als Allokation des Anwendungsfalls „readout Temperature“.

Neben der Dekomposition der Funktionen sollte bei der Modellierung eine Beschreibung der Abläufe in Form von Activity Diagrams erfolgen. Dabei wird nach der in dieser Arbeit entwickelten Methode für jeden Block, welcher eine Funktion repräsentiert, ein Activity, welches dem Activity Diagram entspricht, modelliert. Abbildung 5.5 zeigt als Beispiel ein Activity Diagram als funktionalen Ablauf der „readout-pressure-Sensor“-Funktion des Auswerte-SoCs. Wie in der Abbildung 5.5 erkennbar ist, geht es dabei um eine sehr abstrakte Beschreibung der Abläufe. Diese dient in erster Linie dazu, die Funktionen des Auswerte-SoCs funktional in Beziehung zu setzen. Das Activity Diagram enthält somit alle in Abbildung 5.4 durch die Dekomposition erhaltenen Teilfunktionen der Funktion „readout-pressure-Sensor“.

Die Abbildung 5.5 zeigt zudem die bereits in Abschnitt 4.​1.​2 behandelten Swimlanes, welche nach der hier angewendeten Modellierungsmethode für die Allokation der Funktionen zu den Modulen des Technical Model dienen. Hat die Dekomposition der Funktionalität einen gewissen Reifegrad erreicht, kann die Allokation der Funktionen aus dem Functional Model zu den Modulen des Technical Model erfolgen. Dabei findet zu Beginn meist noch keine Einteilung und Zuordnung der Funktionen in die jeweiligen Domänen statt. Die Modellierung der Dekomposition der Module sowie die Allokation erfolgt im Hierarchical Technical Diagram, wie in Abbildung 5.6 dargestellt.

Dabei bleiben die Entwicklung und Modellierung in der Regel auf der System-Ebene als Maß der Abstraktion. Anders als im Hierarchical Functional Diagram sollte im Hierarchical Technical Diagram zumindest jede Hierarchieebene der Dekomposition vollständig in einem Diagramm dargestellt werden. Lediglich um eine weitere Ebene der Dekomposition für eine der hier gezeigten Submodule vorzunehmen und zu modellieren, kann es sich bei sehr komplexen Systemen anbieten, diese nächsttiefere Ebene als weiteres BDD hinter dem jeweiligen Block zu hinterlegen. Für die Modellierung der in Abbildung 5.6 dargestellten Module wurden die vorgefertigten Blöcke aus dem in dieser Arbeit entwickelten Automotive-SoC-Profil in das Model kopiert und für das entsprechende Modul angepasst.

Parallel zum Hierarchical Technical Diagram wurde das Architecture Diagram, wie in Abbildung 5.7 dargestellt, modelliert. Hierbei werden, nach der hier entwickelten Modellierungsmethode, die zu den Blöcken aus dem Hierarchical Technical Diagram zugehörigen Parts als eine Art Instanz des Blocks zur Darstellung des Moduls in der Architektur modelliert. Wird ein Teil der Funktionalität mittels Software auf einem Mikrochip realisiert, erfolgt die Modellierung der Software-Architektur in einem gesonderten IBD.

Vergleichbar zum System Context Diagram wurden als Teil des Architecture Diagram die Ports und Verbindungen der Architektur modelliert sowie die nichtfunktionalen Eigenschaften mittels Tags spezifiziert. Durch die Verwendung der vorgefertigten Blöcke aus dem Automotive-SoC-Profil für die Modellierung des Hierarchical Functional Diagram wurden ebenso vorgefertigte Parts für die Modellierung der Architektur erzeugt. Diese enthielten bereits eine große Menge der in der Abbildung 5.7 gezeigten Ports und Tags. In Abbildung 5.7 außerdem zu sehen ist die Modellierung der externen Ports des Auswerte-SoCs auf dem Diagramm-Rahmen des Architecture Diagram.

Nach der konzeptuellen Modellierung der Architektur von Hardware und gegebenenfalls Software endet in der Regel die Konzeptphase. Die Verfeinerung der Modellierung als Teil der Entwurfsphase wird in Abschnitt 5.1 behandelt.

Neben der Modellierung des Systems beinhaltet die in dieser Arbeit entwickelte Methode die bidirektionale Verlinkung der Systemanforderungen in natürlicher Sprache mit den Modellelementen des Systemkonzepts bzw. Systemmodells. Als essenzieller Bestandteil der Methode soll hierdurch eine kombinierte Spezifikation basierend auf zwei Spezifikationsdokumenten, welche in zwei verschiedenen Tools verwaltet werden, geschaffen werden. Aus diesem Grund soll nachfolgend die toolbasierte Lösung für die bidirektionale Verlinkung der Spezifikationsdokumente vorgestellt werden. Die dabei verwendete Tool-Umgebung wurde in Abschnitt 5.1.1 vorgestellt sowie deren Nutzen für die Methode dieser Arbeit behandelt.

Die Realisierung der Verlinkung erfolgt auf Basis der IBM-Rational-Tool-Umgebung, welche bereits die Verlinkung der Systemanforderungen, in DNG als Artefakte gespeichert, mit den Rhapsody Modellelementen ermöglicht. Somit sind durch die Auswahl der Tool-Umgebung für die hier vorliegende Arbeit die technischen Voraussetzungen für die Verlinkung gegeben. Die methodischen Voraussetzungen, um eine Spezifikation aufgeteilt auf zwei Tools mit unterschiedlichen Datenbasen zu schaffen, mussten in dieser Arbeit ermöglicht werden. Abbildung 5.8 veranschaulicht die Verlinkung der Kunden- bzw. Systemanforderungen in DNG mit den Modellelementen des Systemmodells in Rhapsody, ohne dabei auf die technische und Tool-spezifische Realisierung einzugehen.

Die grauen Blöcke der Tools zeigen gleichzeitig den sogenannten Master der jeweiligen Daten. Die Systemanforderungen sollten zur Sicherstellung der Konsistenz immer in DNG spezifiziert werden. Um die Verlinkung in Rhapsody zu ermöglichen, werden die beiden Datenbasen verbunden und so eine Referenz und damit eine Repräsentation der Systemanforderungen aus DNG in Rhapsody erreicht. Die Modelle aus Rhapsody werden dabei auf dem RMM gespeichert und mittels bidirektionaler OSLC-Verlinkung mit DNG verbunden. Die Verlinkung kann dabei sowohl in DNG wie auch in Rhapsody erfolgen.

Darüber hinaus lassen sich die Verlinkungen als Beziehungen in den Diagrammen darstellen. Diese Funktion wurde hier schematisch in der Abbildung 5.8 zur Veranschaulichung als „Optische Verlinkung“ bezeichnet. Abbildung 5.9 zeigt einen Auszug des in Abbildung 5.4 gezeigten Hierarchical Functional Diagram und veranschaulicht dabei die Satisfy-Beziehung der „readout-pressure-Sensor“-Blocks zur hier beispielhaft dargestellten Kundenanforderung Provide pressure measurment.

Dabei wurde in diesem Fall die Repräsentation der Anforderung im Diagramm als Requirements-Block gewählt. Diese Darstellung kann schnell zu unübersichtlichen Diagrammen führen und sollte selektiv für den jeweiligen Fall gewählt werden. Alternativ ist es möglich, die Beziehung als Teil des Modells zu modellieren, ohne eine optische Repräsentation in einem Diagramm zu benötigen.

Neben der Nutzung der Plug-Ins für die Automatisierung des Entwurfs lassen sich Plug-Ins ebenso zur Automatisierung einzelner Arbeitsschritte bei der Modellierung nutzen. Hierdurch kann der Aufwand der Modellierung einer Spezifikation im Vergleich zur aktuellen Methode weiter gesenkt werden. So lässt sich über die bereits behandelte Java API von Rhapsody auch die Modellierung mittels Plug-Ins automatisieren. In dem in diesem Kapitel zugrunde liegenden industriellen Beispiel eines Auswerte-SoCs wurden beispielsweise spezifische Darstellungseigenschaften für „Stakeholder“-spezifische Sichten definiert.

Die Anwendung auf ein Diagramm würde jedoch in vielen Fällen eine manuelle Bearbeitung jedes einzelnen Modellelements eines Diagrammes benötigen. Die Einstellungsmöglichkeiten der Darstellung eines Modellelements in Rhapsody wird in den „Display Options“ (Anzeigeoptionen) zusammengefasst und kann dort mittels Dialogfenstern angepasst werden. Dies führt jedoch zu einem erheblichen manuellen Aufwand und birgt die Gefahr einer Abweichung von der definierten Standarddarstellung. Neben der Einstellung der „Display Options“ im Dialogfeld lassen sich viele dieser Einstellungen direkt mittels „Properties“ definieren.

In der hier vorliegenden Arbeit wurde daher ein Plug-In entwickelt, welches so weit wie möglich die Anpassung der „Display Options“ durch ein automatisiertes Setzen der „Properties“ ermöglicht. Dabei kann das Plug-In je nach „Stakeholder“-Sicht wiederverwendet und konfiguriert werden. Hierbei bietet Rhapsody die Option, das Starten und Ausführen des Plug-Ins direkt mittels Menüeintrag in Rhapsody zu ermöglichen. Zusätzlich zur Anpassung der „Properties“ bzw. der „Display Options“ schließt das Plug-In das aktuell geöffnete Diagramm auf, welches auf das Plug-In angewendet wurde und lädt es neu, um die neue Darstellung auf das Diagramm anzuwenden.

Um eine einheitliche Darstellung bei der Modellierung zu fördern und dabei den Aufwand so gering wie möglich zu halten, wurde als Erweiterung der Methode eine standardisierte Darstellung bei den IBDs definiert. Diese Darstellungsregeln lassen sich auch nachträglich mittels Plug-Ins auf die IBDs anwenden und werden dem Nutzer als Teil des Profils zur Verfügung gestellt. Es ist hierbei ebenfalls möglich, den Anwender/-innen eine Auswahl verschiedener Plug-Ins zur Verfügung zu stellen, welche ein bestimmtes Set aus Darstellungsregeln automatisiert anwendet. Die einheitliche Darstellung unterstützt den Leser des Modells dabei, den Sinn der Informationen leichter zu verstehen. Eine einheitliche Darstellung ist hierbei jedoch besonders wichtig, da im Laufe eines Entwicklungs-Flows eine Vielzahl verschiedener Personen an der Modellierung des Systems beteiligt sind.

Die Architekturbeschreibung ist bereits im Technical Model des Systemkonzepts in Form des Architecture Diagram enthalten und muss in der Entwurfsphase, wie in Abschnitt 4.​3.​2 beschrieben, lediglich verfeinert werden.

Die Modellierung und Generierung der Architektur wird nachfolgend am Beispiel des Processor-Subsystems veranschaulicht. Dieses beinhaltet die kontrollflussorientierten Module des Beispiel-SoCs. Für die Beschreibung der Architektur wird, wie in Abschnitt 4.​1 beschreiben, im ersten Schritt die Dekomposition mittels BDD modelliert. Abbildung 5.10 zeigt das Processor-Subsystem mit den enthaltenen kontrollflussorientierten Modulen als Beispiel eines Hierarchical Technical Diagram.

Das Processor-Subsystem besteht in diesem Beispiel aus dem Processor als Repräsentation eines spezifischen Mikrocontrollers, dem zugehörigem RAM und ROM, zwei Bussen, dem CRC Module sowie dem „One-Time-Programmable“ (OTP)-Modul. Aufgrund der geringen Relevanz der technischen Funktionalität der einzelnen Module für die hier vorliegende Arbeit, werden diese nicht näher behandelt.

Durch die Modellierung der Hardware-Submodule im BDD als Directed Composition des Cortex-Subsystems werden entsprechende Parts der Hardware-Submodule erzeugt. Diese Teile werden zur Modellierung des Architecture Diagram im IBD verwendet. Abbildung 5.11 zeigt das Architecture Diagram des Processor-Subsystem als IBD.

Ein- und Ausgänge der Hardwaremodule werden im Architecture Diagram als sogenannte „ProxyPorts“ modelliert. Darüber hinaus sind in der Abbildung 5.11 für die Module bereits Beispiel „ValueProperties“ definiert, welche die Eigenschaften der Module spezifizieren und zudem der Generierung der Architekturbeschreibung in SystemC für den Virtuellen Prototyp dienen.

Als Teil der Verfeinerung der Architektur wird die Modellierung von On-Chip-Bussen durchgeführt. Wie in Abbildung 5.11 und Abbildung 5.10 zu sehen, werden die Busse im Architecture Diagram, wie alle Module der Architektur, als Blöcke im BDD und als Parts im IBD modelliert. In der Entwurfsphase reicht diese abstrahierte Darstellung der Busse meist jedoch nicht mehr aus und es wird zusätzlich zur Architektur des SoCs auf System-Ebene eine Modellierung der Busarchitektur benötigt. Abbildung 5.12 zeigt die modellierte Busarchitektur des in diesem Kapitel genutzten Beispiel-SoCs.

Dabei wird zur Modellierung der nächsttieferen Abstraktionsebene in diesem Beispiel hinter dem Part itsCore-Bus ein weiteres IBD mit der Busarchitektur hinterlegt. Vergleichbar mit dem Architecture Diagram werden hierzu die Module, welche über den Bus verbunden sind, als Parts modelliert sowie die Verbindungen zwischen den Modulen, welche Bestandteil des Busses sind, als Connectoren abgebildet.

Für die Implementierung der nachfolgend in Abschnitt 5.3.4 beschriebenen modellgetriebenen Verifikation wurde die Architektur des SoCs aus Abbildung 5.11 zusätzlich verfeinert, wie in Abbildung 5.13 gezeigt. Dabei wurde dem Modell das CRC-OTP-Subsystem hinzugefügt und die Architektur der bereits in Abbildung 5.10 enthaltenen Module OTP und CRC Module wie folgt modelliert bzw. verfeinert.

Da in dieser Arbeit der Fokus auf der Vorstellung der Methode zur modellbasierten Systementwicklung und dem modellgetriebenen Entwurf liegt, wird in diesem Abschnitt nicht näher auf die Funktionen der einzelnen Submodule in dem hier gezeigten Beispiel-SoC eingegangen. Abbildung 5.13 zeigt beispielhaft die Möglichkeit einer detaillierten und implementierungsnahen Modellierung, welche für die modellgetriebene Automatisierung in der Regel benötigt wird.

Neben der Verfeinerung der Architektur erfolgt, wie in Abschnitt 4.​2.​2 beschrieben, in der Entwurfsphase eine Spezifikation und Modellierung des Modulverhaltens als Teil des Behavioral Model. Neben der eindeutigen Spezifikation wird durch die Formalisierung und Modellierung des Verhaltens ein implementierungsnahes und maschinenlesbares Format erreicht und somit der Grundstein für die Realisierung eines modellgetriebenen Systementwurfs gelegt. Die dabei entstehenden Flowchart Diagrams sind im Behavioral Model in ein Hardware- und ein Software-Package unterteilt. Hierdurch wird eine Generierung verschiedener Programmiersprachen für das jeweilige Package des SoC-Modells ermöglicht. Für die Definition der Zielsprache wird für einen definierten Teil des Modells, wird im Modell eine Rhapsody-spezifische Konfigurationsdatei angelegt. Auf diese Weise ist es möglich, C++-Code bzw. SystemC-Code lediglich für den Teil der verhaltensbeschreibenden Diagramme zu generieren, welcher für die Generierung des Virtuellen Prototyps, wie in Abschnitt 4.​3.​1 beschrieben, benötigt wird. Da bei der Modellierung und Generierung der Verhaltensbeschreibung die Verwendung der korrekten Registernamen entscheidend ist, wurden mittels des in Abschnitt 4.​1.​4 beschriebenen automatisierten Transfers die Registernamen aus der IP-XACT-Registerbeschreibung in das SysML-Modell übertragen. Abbildung 5.14 zeigt einen Auszug der so übertragenen Registernamen, welche im Modell als ValueProperties vertreten werden und in der Modellierung der Verhaltensbeschreibung wie Variablen verwendet werden können.

Nachfolgend soll die Modellierung und anschließende Generierung der Hardware-Verhaltensbeschreibung anhand einer Teilfunktion des hier zugrunde liegenden Beispiel-SoCs veranschaulicht werden. Abbildung 5.15 zeigt hierzu das Flowchart Diagram einer zyklischen Redundanzprüfung (CRC-Berechnung) für einen 32 Bit-unsigned-Integer-Wert in Form einer modellierten For-Schleife.

Der Algorithmus der zyklischen Redundanzprüfung wird häufig zur Erkennung von Fehlern bei der Datenübertragung verwendet [90]. Hierzu wird der Wert der einzelnen Bits der Variablen „input“ betrachtet und an die CRC-Berechnungsfunktion übergeben. In der Abbildung 5.15 ist die stark implementierungsnahe Modellierung des Modulverhaltens zu erkennen, welche als Grundlage für die nachfolgend beschriebenen Lösungen der modellgetriebenen Automatisierung des Systementwurfes benötigt wird.

Synopsys® Virtualizer Studio (Virtualizer Studio) ist ein Eclipse-basiertes Tool, welches die Funktionalitäten mehrerer anderer Synopsys-Werkzeuge vereint und diese um eine eigene Anwenderoberfläche erweitert. Für die hier vorliegende Arbeit wurde Virtualizer Studio für die Instanziierung und Vernetzung von Hardware-IPs verwendet, um daraus Systeme oder Teilsysteme für die Implementierung eines Virtuellen Prototyps zu erstellen. Darüber hinaus lassen sich die Virtuellen Prototypen in Virtualizer Studio zusammen mit der Software simulieren und testen. An vielen Stellen wird den Anwender/-innen zudem die Möglichkeit der Abstrahierung geboten, um so die Entwicklungszeiten und den Aufwand für die Implementierung des Virtuellen Prototyps zu verringern. Ein Vorteil bei der Verwendung von Virtualizer Studio ist das zur Verfügung stehende Python-„Application Programming Interface“ (API, Programmierschnittstelle) des Tools. Nahezu alle manuell ausführbaren Aktionen können hierdurch via Python-Skript automatisiert werden. Somit wird eine Möglichkeit der Automatisierung bei der Erstellung von Virtuellen Prototypen eröffnet und findet in dieser Arbeit wie im nachfolgenden Abschnitt 5.3.2 beschrieben Anwendung [70] [91].

Der folgende Abschnitt zur Automatisierung im Bereich der Virtuellen Prototypen baut auf der Arbeit aus [15] auf. Dieser Ansatz soll im ersten Schritt um die Generierung einer Verhaltensbeschreibung der kontrollflussorientierten Module erweitert werden, wie in Abschnitt 4.​3 beschrieben und in Abbildung 4.​12 dargestellt. Die Generierung wird dabei anhand des in Abschnitt 5.2 vorgestellten Modells eines Beispiel-SoCs behandelt.

Um zusätzlich zur Automatisierung der Entwicklung von Virtuellen Prototypen Teile des SoC-Entwurfs selbst zu automatisieren, wird nachfolgend die in Abschnitt 4.​3 konzeptuell behandelte Generierung von Softwarecode auf Basis des SysML-Modells beschrieben. Dabei wurde ein vergleichbarer Ansatz zur Generierung der SystemC-Verhaltensbeschreibung gewählt.

Die Verhaltensbeschreibung der Software findet mittels Flowchart Diagram als Teil des Behavioral Model statt. Dabei werden im Behavioral Model die Software-beschreibenden Flowchart Diagrams in ein separates Package eingeordnet, um für dieses Package eine C-Codegenerierung zu ermöglichen. Aufgrund der Ähnlichkeit der Modellierung zwischen Verhalten des Virtuellen Prototyps und der Software wurde auch für die Codegenerierung ein vergleichbarer Ansatz verfolgt. So wurde für die Generierung von Softwarecode auf Basis des SysML-Modells der in Rhapsody enthaltene C-Codegenerator für die hier vorliegende Arbeit entsprechend dem Anwendungsfall konfiguriert. Die Generierung erfolgt dabei ebenfalls, wie in Abbildung 5.16 für die Generierung der SystemC-Verhaltensbeschreibung dargestellt, in zwei Schritten.

Dabei lässt sich das Ergebnis der Generierung, wie im vorangegangenen Abschnitt beschrieben, an drei Stellen des Flows beeinflussen. Diese sollen nachfolgend näher behandelt werden und gelten gleichermaßen für die Generierung der SystemC-Verhaltensbeschreibung aus dem vorangegangenen Abschnitt. Abbildung 5.19 veranschaulicht, aufbauend auf Abbildung 5.16, die drei Möglichkeiten der Einflussnahme auf die Codegenerierung.

In diesem Abschnitt wird die in dieser Arbeit entwickelte Generierung im Bereich der Verifikationserstellung vorgestellt. Dazu soll anhand der in Abbildung 5.13 gezeigten Architektur des CRC_OTP_Subsystems die Generierung von „Connectivity Checks“, wie in Abschnitt 4.​3.​3 konzeptuell beschrieben, veranschaulicht werden.

In dem in Abbildung 5.13 gezeigten Architecture Diagram sind die Ports aller Hierarchieebenen abgebildet und mittels Connectoren verbunden. Dabei sind einzelne Ports direkt innerhalb eines Moduls miteinander verbunden und andere Verbindungen gehen über mehrere Hierarchieebenen hinweg. Für die Generierung des „Connectivity Checks“ wird im ersten Schritt zu jedem Anfangs-Port der End-Port im Architecture Diagram mittels Java-Skript gesucht und anschließend in eine Tabelle übertragen. Liegen, wie in Abbildung 5.13 gezeigt, bei der Verbindung zwischen Port Prog_Enable des Moduls itsReg und Port Prog_Enable des Moduls itsProgram_FSM weitere Ports, sollen diese nicht in die Tabelle eingetragen werden.

Um diese Information in die Tabelle übertragen zu können, wird ein weiteres Skript benötigt. Im Modell verfügt jedes Modellelement über eine eigne ID. Diese ID des End-Ports wird in einem Tag automatisiert zwischengespeichert, um im nächsten Schritt den Namen des zugehörigen Parts sowie dessen hierarchische Ordnung im Modell mittels der ID des End-Ports zu extrahieren und in die Tabelle einzutragen.

Die Informationen der so erhaltenen Tabelle werden im nächsten Schritt mittels Python-Skript [92] ausgelesen und auf Grundlage der so erhaltenen Port-Variablen SystemVerilog-Assertions generiert. Die Assertions prüft hierbei lediglich, ob der Anfangs-Port portX mit dem End-Port portY im Entwurf verbunden ist. Abbildung 5.20 zeigt einen Auszug der auf Basis des in Abbildung 5.13 gezeigten Architecture Diagram generierten SystemVerilog-Assertions.

In der Abbildung 5.20 ist unter anderem das Ergebnis der Generierung für das besprochene Beispiel der Verbindung zwischen Port Prog_Enable des Moduls itsReg und Port Prog_Enable des Moduls itsProgram_FSM zu sehen. Die Automatisierung der Entwicklung von „Connectivity Checks“ auf Basis des SysML-Modells zeigt die Möglichkeiten der Effizienzsteigerung im Bereich der Verifikation auf. Durch den modellgetriebenen Ansatz lässt sich in diesem Gebiet nicht nur der Aufwand durch die Qualitätssteigerung der Spezifikation erhöhen, es lässt sich zudem der Aufwand bei der Entwicklung der Verifikation reduzieren.