Modellierung und Simulation von Networks-on-Chip mit OSCI TLM2 Adán Kohler, Martin Radetzki Institut für Technische Informatik, Abt. Embedded Systems Engineering Universität Stuttgart {kohleran,radetzki}@informatik.uni-stuttgart.de

Kurzfassung: Networks-on-Chip stellen eine zukunftsträchtige Kommunikationsinfrastruktur für hochintegrierte Schaltungen dar. Die effiziente Simulation solcher Netzwerkstrukturen spielt für die Entwicklung künftiger Systeme eine wichtige Rolle. In dieser Arbeit wird ein zyklenapproximativer Ansatz zur Beschreibung und Simulation von Networks-on-Chip auf der Basis des neuen Transaction-Level-Modeling-Standards der Open SystemC Initiative beschrieben, welcher gegenüber den besten zyklengenauen Modellen Geschwindigkeitssteigerungen bis um den Faktor 20 erreicht. Stichworte: Networks-on-Chip, Transaction-Level-Modeling

1

Einleitung

Steigende Integrationsdichten moderner System-on-Chip-Architekturen erlauben den Einsatz immer mehr funktionaler Einheiten auf einem einzigen Chip. Der damit verbundene höhere Kommunikationsbedarf erfordert neue Ansätze im Bereich der Verbindungsinfrastruktur, da „klassische“ Busarchitekturen diesen Bedarf oft nicht mehr erfüllen können. Sinkende Strukturgrößen erhöhen die Wahrscheinlichkeit von Fehlern, zudem können hierarchische Bussysteme aufgrund fehlender Regularität meist nur schwer automatisiert generiert werden. Eine mögliche Lösung dieser Probleme liegt in der Verwendung flexibler Netzwerkstrukturen, sogenannter „Networks-on-Chip“ (NoCs) zur Bewältigung der Kommunikation, da diese einerseits regulären Mustern folgen und andererseits z.B. mittels mehreren möglichen Pfaden zwischen den Kommunikationspartnern hohen Durchsatz und Fehlertoleranz bieten [2]. Zur frühzeitigen Validierung der Funktionalität sowie zur Abschätzung der zu erwartenden Performance werden Entwürfe gewöhnlich zuerst auf Systemebene beschrieben und simuliert. In dieser Phase ist man nicht an Details, sondern eher an einer hohen Simulationsgeschwindigkeit interessiert, weshalb Kommunikation zunehmend auf der Transaktionsebene (transaction level modelling, TLM) modelliert wird. Die Verabschiedung des TLM-2.0-Standards [10] der Open SystemC Initiative (OSCI) erleichtert die Erkundung des Entwurfsraumes durch Interoperabilität zwischen verschiedenen TLM-Komponenten. Durch das Verfügbarwerden von TLMBeschreibungen für IP-Cores und Bussysteme seitens der EDA-Hersteller kann in kurzer Zeit eine Vielzahl von Busarchitekturen für ein System aufgebaut und simuliert werden. In der vorliegenden Arbeit wird eine Plattform beschrieben, mit deren Hilfe NoC-Strukturen aufgebaut und als Kommunikationsinfrastruktur für TLM-fähige Komponenten eingesetzt werden können. Die Plattform ist als hierarchisch aufgebaute und modulare Klassenbibliothek in SystemC implementiert, welche auf den TLM-2.0-Standard aufbauend die Modellierung und Simulation von Network-on-Chip-Strukturen auf zyklen-approximativer Basis ermöglicht.

Der vorliegende Beitrag ist wie folgt gegliedert: In Kapitel 2 wird auf vorangegangene Arbeiten eingegangen, Kapitel 3 beschäftigt sich mit dem Aufbau und Einsatz der entwickelten Klassenbibliothek, Kapitel 4 beschreibt den internen Simulationsablauf und in Kapitel 5 schließlich werden experimentelle Ergebnisse vorgestellt.

2

Vorangegangene Arbeiten

Einen der frühesten Simulatoren für NoCs stellt das an der KTH in Stockholm entwickelte Nostrum NoC Simulation Environment (NNSE) [9] dar, mit dessen Hilfe die Kommunikationsleistung von Mesh-Strukturen für synthetischen Traffic untersucht werden können. Der Simulationskern ist ähnlich des ISO/OSI-Modells geschichtet aufgebaut und ermöglicht zyklengenaue Simulation bis auf die physische Ebene hinunter. Als Switchingverfahren kommt wormhole switching zum Einsatz, die implementierten Routingverfahren arbeiten achsenbasiert (deterministisches XY, Delta XY). Zusätzlich kann darauf noch eine Umleitungsregel gesetzt werden, welche bei belegten Ausgangsressourcen zur Anwendung kommt. Das Anbinden eigener Applikationen ist nicht dokumentiert und wird von der mitgelieferten grafischen Benutzeroberfläche nicht unterstützt. Ein weiterer frei verfügbarer Simulator, welcher das Anbinden eigener Applikationen ermöglicht und darüber hinaus ähnliche Funktionalität wie NNSE bietet, stellt der in Southampton entwickelte NIRGAM [5] dar. Er setzt ein synchron getaktetes Mesh- oder Torus-Netwerk voraus, in welchem pro Taktzyklus je ein Flit übertragen wird. Aufgrund der guten Dokumentation und einfachen Konfigurierbarkeit wurde er als Referenz für diese Arbeit eingesetzt. Während diese beiden Ansätze flit- bzw. zyklengenau arbeiten, stellt der von Lee et al. entwickelte TraNSIM [8] einen modularen NoC-Simulator dar, welcher auf Transaktionsebene arbeitet. Die Kommunikation ist mittels Standard-SystemC-Ports realisiert, über die komplette Pakete ausgetauscht werden – es kommt kein TLM-Standard zum Einsatz. Der Quellcode des Simulators ist nicht verfügbar, weshalb außer den Aussagen, dass wormhole switching sowie „deterministische und adaptive“ Routingverfahren zum Einsatz kommen, nur wenig Information auffindbar ist. Die Performance soll ca. 30 bis 70-fach höher als die einer RTL-Simulation sein. Darüber hinaus existieren einige weitere Ansätze mit ähnlicher Funktionalität der bereits beschriebenen Simulatoren: Der frei verfügbare Noxim [3] ist in SystemC geschrieben und ermöglicht die Simulation von Meshes. gpNoCsim [4] ist eine modulare, in Java geschriebene Simulationsplattform für eine Vielzahl an Strukturen und Routingalgorithmen und arbeitet wie Noxim flitgenau. Das On-Chip Communication Network-Projekt (OCCN) [1] hingegen ermöglicht die Simulation auf unterschiedlichen Ebenen, darunter auch auf Transaktionsebene über ein eigenes Protokoll. Der Ansatz von Xi und Zhong [11] verwendet ebenfalls eine eigene Form der Transaktionsmodellierung, zielt jedoch eher auf das Abschätzen des Stromverbrauchs und der Verlustleistung ab. In dieser Arbeit wird erstmals eine Simulationsplattform für NoCs vorgestellt, welche sich auf die standardisierte TLM-2.0-Bibliothek der OSCI zur Modellierung der Kommunikation stützt.

3

Aufbau der Simulationsplattform

Die hier vorgestellte Plattform bietet die Möglichkeit der Simulation auf Transaktionsebene, unterstützt prinzipiell beliebige NoC-Topologien und in der aktuellen Fassung store-and-forwardsowie wormhole switching-Funktionalität in Kombination mit geographischem, deterministischem XY- oder deflection-Routing. Durch den modularen Aufbau lassen sich einfach weitere Switching- oder Routingverfahren implementieren und mit den bestehenden Verfahren kombinieren. Verschiedene Topologien benötigen unterschiedliche Adressierungsschemata, um ein effizientes Routing zu ermöglichen. Während für Mesh-Strukturen wie z.B. CLICHÉ [7] mehrdimensionale Adressen eingesetzt werden, da hier üblicherweise entlang den Dimensionsachsen geroutet wird, benötigen Ringstrukturen wie z.B. Octagon [6] skalare Adresstypen, die Operationen wie Modulo-Rechnung oder boolesche Funktionen bieten. Aus diesem Grund kann den implementierten Klassen der zu verwendende Adresstyp über den C++-Templatemechanismus als Parameter übergeben werden und ermöglicht so dem Entwickler die Abstraktion der Switchingund Routingfunktionalität von der zu modellierenden Struktur, wo dies sinnvoll erscheint. Darüber hinaus wurde auf die Wiederverwendbarkeit bereits bestehender TLM2-Modelle mit möglichst wenig Änderungen geachtet.

3.1

TLM-Bibliothek der OSCI

Während der Entwurfsraum-Exploration auf Systemebene sollte die abstrakte Modellierung von Kommunikation ohne Details einer späteren Implementation möglich sein. Hier setzt der TLM-Ansatz an, in welchem Kommunikation mittels atomaren Transaktionen zwischen Komponenten beschrieben wird. Eine Transaktion besteht in OSCI-TLM2 üblicherweise aus den drei Objekten Payload, Phase und Zeit und wird über sogenannte Sockets zwischen Komponenten ausgetauscht. Prinzipiell können zwei Typen von Sockets unterschieden werden: InitiatorSockets können neue Transaktionen starten („initiieren“), Target-Sockets dienen zur Annahme der Transaktionanforderungen und ermöglichen deren Bearbeitung. Vor der Benutzung müssen Initiator-Sockets an einen Target-Socket gebunden werden, um das Ziel der Transaktion festzulegen. Um Interoperabilität zwischen verschiedenen TLM-Modellen zu gewährleisten, sind Standardtypen für diese Objekte vorgegeben, welche bei Bedarf um benutzerspezifische Daten (extensions) erweitert werden können. Das Payload legt die Art des Zugriffs (lesen, schreiben) fest und enthält unter anderem einen Zeiger auf die Nutzdaten. Die Phase wird in zyklenapproximativem TLM eingesetzt, um den Fortschritt der Transaktion zu beschreiben; das Zeitargument kann verwendet werden, um der globalen Simulationszeit lokal vorauszulaufen (temporal decoupling).

3.2

Zugrundeliegendes Netzwerkmodell

Für das zu beschreibende Netzwerk wurden drei Basiselemente angenommen: 1. Verarbeitende Elemente („processing elements“, PEs), welche die miteinander kommunizierenden Applikationen modellieren;

2. kommunizierende Elemente („communicating elements“, CEs), welche selber keine Daten produzieren oder konsumieren, jedoch Daten sowohl untereinander als auch mit PEs austauschen, sowie 3. Links, welche bidirektionale Punkt-zu-Punkt-Verbindungen zwischen zwei PEs beschreiben. In einem NoC können typischerweise zwei Arten von CEs gefunden werden: • Switches dienen zur Weiterleitung der Datenpakete innerhalb des Netzwerks. Sie empfangen Datenpakete, bestimmen den weiteren Weg eines Pakets aus dessen Zieladresse (Routing) und übertragen die ankommenden Daten vom Eingang auf den im Routingprozess bestimmten Ausgang (Switching). • Netzwerkschnittstellen bilden die Verbindung Switch Switch zwischen PEs und dem Netzwerk. Sie kapseln PE-seitig produzierte Daten in netzwerkRNI RNI processing processing tauglichen Einheiten und übernehmen deren Inelement element jektion in das Netzwerk (Sendevorgang), anaLink log werden die Nutzdaten aus netzwerkseiSwitch Switch tig ankommenden Einheiten hier extrahiert und dem angeschlossenen PE – z.B. in einem PufRNI RNI fer – zugestellt (Empfangsvorgang). Da sie die processing processing element element Schnittstelle zwischen PEs (resources) und dem Netzwerk bilden, werden sie häufig als resource Abbildung 1: NoC mit Mesh-Struktur network interfaces (RNIs) bezeichnet. Ein Beispiel eines aus diesen Elementen modellierten NoCs ist in Abb. 1 zu finden.

3.3

Klassen zur Strukturmodellierung

Die Basis der Simulationsplattform stellt das Modell der Links dar, da über sie jegliche Netzwerkkommunikation abläuft. Links werden mit Hilfe der entwickelten LinkSock_t-Klasse beschrieben und durch zwei die Größen Latenz und Bandbreite charakterisiert. Diese beiden Größen sind nicht an einen Takt gebunden, so dass auch Systeme mit mehreren unterschiedlichen Taktraten beschrieben und simuliert werden können. Eine LinkSock_t-Instanz besitzt je einen TLM-Initiator- und Target-Socket und beschreibt ein Ende eines physischen Links. Das andere Link-Ende wird über eine zweite LinkSock_t-Instanz modelliert; die Initiator-Sockets beider Enden werden an die Target-Sockets des jeweils anderen Endes gebunden (vgl. Abb. 2). bidirectional link LinkSock_t

LinkSock_t

left CE

initiator socket on left end is bound to target socket on the right initiator socket on right end is bound to target socket on the left

Abbildung 2: Modell eines Links

right CE

Die beiden an einem Link angeschlossenen CEs können nun über den Initiator-Socket ihres Transaktionen für das CE am anderen Link-Ende generieren, welche über den dortigen Target-Socket entgegengenommen werden. Wie aus obigen Ausführungen ersichtlich, sind zwei LinkSock_t-Instanzen zur Beschreibung eines bidirektionalen Links erforderlich (eine für jedes Ende), was die Modellierung von Links mit asymmetrischer Dimensionierung der Hinund Rückrichtung ermöglicht. CEs verwenden die LinkSock_t-Klasse, um miteinander Daten auszutauschen. Da das Protokoll von Switches und RNIs netzwerkseitig identisch ist, stützen sich beide auf dieselbe Basisklasse. CEs werden durch das von ihnen eingesetzte Switching- und Routingprinzip inklusive deren Verzögerungen charakterisiert, dazu kommt ein Arbitrierungsschema für den Fall, dass mehrere Pakete gleichzeitig denselben Link verwenden möchten. Die Basisklasse bietet folglich Methoden zur Parametrisierung der Switching- und Routingverzögerung, aggregiert die ausgehenden Links und definiert Schnittstellen der für Routing, Switching und Ankunft eines Paketes am Ziel benötigten Methoden. Die Funktionalität dieser Methoden wird schrittweise hinzugefügt und ermöglicht so die einfache Kombination einmal implementierter Switchingund Routingalgorithmen. Die Zusammenhänge sind in Abb. 3 dargestellt. LinkSock_ts

address_t SwitchRouter_base + nb_transport_fw(trans:TRANS&, phase:PHASE&, t:sc_time&) + nb_transport_bw(trans:TRANS&, phase:PHASE&, t:sc_time&)

address_t Switch address_t + switchPkt(trans:TRANS&, phase:PHASE&, t:sc_time&, local_phase:sw_phase_t)

SwitchRouter + routePkt(dest:const address_t&)

+ routePkt(dest:const address_t&)

+ switchPkt(trans:TRANS&, phase:PHASE&, t:sc_time&, local_phase:sw_phase_t) + routePkt(dest:const address_t&) + noc_arrive(trans:TRANS&, phase:PHASE&, t:sc_time&)

processing element address_t RNI

+ noc_socket : RNI

+ noc_arrive(trans:TRANS&, phase:PHASE&, t:sc_time&)

1

1..*

1

... + noc_incoming(trans:TRANS&, phase:PHASE&, t:sc_time&)

LinkSock_t address_t + latency : sc_time + bandwidth : float + init_sock : INITSOCK + tgt_sock : TGTSOCK

address_t

RNI_base proc_elem_if + routePkt(dest:const address_t&) + noc_transport(trans:TRANS&, phase:PHASE&, t:sc_time&)

TRANS = tlm_generic_payload

INITSOCK = tlm_initiator_socket

PHASE = tlm_phase

TGTSOCK = tlm_target_socket

+ noc_incoming(trans:TRANS&, phase:PHASE&, t:sc_time&)

Abbildung 3: Klassendiagramm der NoC-Plattform Transporte innerhalb NoCs werden im Vergleich zu busbasierten Übertragungen häufig mit Zusatzinformationen wie einer Adresse des Quell- und Zielsystems im Netzwerk, einer PaketID oder einem „time-to-live“-Wert versehen. Diese Informationen werden typischerweise im Paketheader abgelegt und müssen zusätzlich zu den Nutzdaten übertragen werden. Um die im Payload eingetragenen Nutzdaten nicht mit den Protokolldaten vermischen zu müssen, werden letztere zusammen mit weiteren simulationsinternen Daten als Extension an das Payload-Objekt angehängt. Die Modellierung der physischen Übertragung des Paketheaders erfolgt innerhalb der RNIs durch die Addition eines konfigurierbaren, festen Wertes auf die Menge der zu übertragenden Nutzdaten.

3.4

Verwendung der Plattform

Zum Aufbau der zu simulierenden Struktur müssen die zu verwendenden Switches und Applikationen wie gewohnt instanziiert werden, weiterhin ist die Verbindung untereinander aufzubauen. Dies geschieht über den connect_link-Aufruf eines CEs, welcher den Initiator-Socket einer lokalen LinkSock_t-Instanz an den Target-Socket einer LinkSock_t-Instanz des Ziel-CEs bindet. Die korrekte und vollständige Verbindung (jedes Link-Ende muss an exakt ein CE gebunden sein) des Netzwerks wird durch die Wahl einer entsprechenden Bindungs-Policy für die in der LinkSock_t-Klasse enthaltenen TLM-Sockets garantiert. Nach anschließender Konfiguration der Links und CEs kann die Simulation gestartet werden (vgl. Abb. 4). // define the link width (in bits) const unsigned int LWIDTH = 32; // declare type shortcuts typedef Switch_WH< XYAddress, LWIDTH > typedef Router_XY< WHSwitch_t >

WHSwitch_t; SR_XY_WH;

// instantiation of NoC components SR_XY_WH SR1("SR1", // instance name XYAddress(1,1), // network address 5); // # of outgoing links SR_XY_WH SR2("SR2", XYAddress(2,1), 5); ... // set link parameters SR1.setLinkParams( 0, // config. link #0 of switch SR1 sc_time(4,SC_US), // link latency 100000 // link bandwidth (symbols/s) ); ... // connect links SR1.connectLink( 1, // connect outgoing link #1 of switch SR1... &SR2, // ... to switch SR2’s ... 0) // ... incoming link #0 ); SR2.connectLink(0, &SR1, 1)); ... // start the simulation sc_start();

Abbildung 4: Instanziierung, Konfiguration und Simulation einer NoC-Struktur Während Kommunikation über Busse häufig Broadcast-Charakter hat und das Busmodell auch ohne Angabe eines Ziels Nachrichten übertragen kann, ist die Kenntnis des Ziels für die in Netzwerken eingesetzte mehrstufige Übertragung zwingend erforderlich. Die Zieladresse ist in der oben erwähnten Extension des Payloads abgelegt und wird von der NoC-Plattform zur Bestimmung des Übertragungswegs (Routing) eingesetzt, weshalb vor einem TLM-Transportaufruf sowohl die Existenz der Extension als auch eine korrekt gesetzte Zieladresse gewährleistet sein muss. Dies kann manuell in der Applikation geschehen – um Fehler zu vermeiden und den unterschiedlichen Kommunikationscharakter zu betonen, können dafür jedoch auch in den RNIs definierte Wrapper-Methoden eingesetzt werden, welche die Allokation und korrekte Initialisierung der Extension übernehmen. Bei Verwendung dieser Wrapper-Methoden können existierende TLM2-Modelle die NoC-Plattform mit wenigen Änderungen zur Kommunikation nutzen, wie schematisch in Tabelle 1 dargestellt.

PE-Code für ein „Standard“ TLM2 System PE-Code für NoC-Plattform class proc_elem : public sc_module, public tlm_fw_transport_if,

class proc_elem : public sc_module, public proc_elem_if

public tlm_bw_transport_if {

{

...

... // instantiate communication resources tlm_initiator_socket init_sock; tlm_target_socket

// instantiate communication resources RNI net_if;

tgt_sock; ...

... // bind the communication resources init_sock.bind(*this);

// bind the communication resources net_if.bind(*this);

init_sock.bind(target.tgt_sock); tgt_sock.bind(*this); // initiate a transaction init_sock.nb_transport_fw(trans, phase, t);

// initiate a transaction net_if.noc_transport(dest_addr, trans, phase, t); ...

... // handle incoming transactions tlm_sync_enum nb_transport_fw( tlm_generic_payload& trans,

// handle incoming transactions tlm_sync_enum noc_incoming( tlm_generic_payload& trans,

tlm_phase& phase, sc_time& t) {

tlm_phase& phase, sc_time& t) {

... }

... }

Tabelle 1: Vergleich: „Standard“ TLM2 und NoC-Plattform

4

Interner Ablauf der Simulation

Zur akkuraten zeitlichen Beschreibung durchlaufen Transaktionen intern mehrere Phasen. Zur Wahrung der Kompatibilität bei nicht-blockierendem TLM besitzt eine Transaktion eine dem Payload zugeordnete Phase des TLM-Standardtyps tlm_phase, welche zur Beschreibung der Zeitpunkte des Beginns und des Endes jeweils der Anfrage und der Antwort dient. Diese Phase kann sich nur an den Kommunikationsendpunkten (Initiator oder Ziel) ändern und bleibt folglich aus der Sicht des Netzwerks für den Transport in einer Richtung konstant, weshalb sie als globale Phase der Transaktion bezeichnet wird. Da eine Transaktion meist mehrere Switches (Hops) passieren muss, um das Ziel zu erreichen, ist parallel dazu die Verwendung einer lokalen Phase erforderlich, welche den Fortschritt der Transaktion am aktuell weiterleitenden Switch beschreibt. Während die globale Phase auf dem Hin- und Rückweg der Transaktion lediglich einen Zyklus durchläuft, wird an jedem weiterleitenden Element (Switch oder RNI) ein neuer Zyklus der lokalen Phase angestoßen. Ein Zyklus der lokalen Phase besteht aus einem oder mehreren zusammenhängenden der in Abb. 5 dargestellten Zustände. Das Fortschreiten der lokalen Phase modelliert die folgenden Zeitpunkte: • ARRIVING beschreibt den Zeitpunkt, an dem die ersten Daten eines Pakets ein CE erreichen. Im Modell entspricht dies dem Simulationszeitpunkt, an dem die TLM-Transportmethode des CEs aufgerufen wird. • ROUTE zeigt an, dass das CE genügend Daten des ankommenden Pakets erhalten hat, um den ausgehenden Link des Pakets zu bestimmen (Routing). Wie viele Daten dazu notwendig sind, ist vom modellierten Switchingverfahren abhängig: Während unter wormhole switching der Ausgangslink aller Flits eines Paketes nach dem Erhalt des ersten

Flits feststeht, muss bei store and forward auf den Erhalt des kompletten Pakets gewartet werden. Eine cut-through switching-Implementierung, welche den Routingprozess nach Erhalt des Paket-Headers (in welchem die Ziel-Adresse bzw. die virtuelle Kanal-ID steht) anstoßen kann, würde entsprechend zu diesem Zeitpunkt in die ROUTE-Phase wechseln. • In der ROUTED-Phase wurde der ausgehende Link bestimmt und das CE wartet auf die zur weiteren 1. ARRIVING Übertragung benötigten Ressourcen (Link- und Pufreceived enough data ferkapazität). to start routing process • FORWARDING stellt den Zeitpunkt dar, an dem die benötigten Ressourcen zur Verfügung stehen und das CE das Paket auf den ausgehenden Link legt. • NEXT HOP beschreibt den Zeitpunkt, an dem die im vorigen Schritt gesendeten Daten die Latenz des übertragenden Links überwunden haben und das nächste CE auf dem Pfad erreichen. Zu diesem Zeitpunkt wird die TLM-Transportmethode des Folge-CEs aufgerufen und dort ein neuer Weiterleitungszyklus gestartet (s. ARRIVING); der Zyklus im aktuellen CE ist beendet.

2. ROUTE routing done

3. ROUTED resources for outgoing transfer available

4. FORWARDING sent−out unit has traversed the link

5. NEXT HOP

Abbildung 5: Lokale Phasen einer Transaktion

Der komplette fünfstufige Zyklus wird nur in Switches durchlaufen, für RNIs gelten wegen der direkten Anbindung an ein PE gesonderte Abläufe. • Sendende RNIs brauchen weder auf die Daten zu warten, da sie bereits in lokalen Puffern vorliegen, noch muss das Paket geroutet werden, da ein RNI stets nur an einen Switch angebunden ist; ein Zyklus beginnt hier direkt in der ROUTED-Phase. • Empfangende RNIs dehnen die ARRIVING-Phase so lange aus, bis das komplette Paket angekommen ist. Ab diesem Zeitpunkt kann die an das RNI angeschlossene Applikation die Daten aus dem lokalen Puffer lesen – Routing und Weiterleitung entfallen und folglich auch die zugehörigen lokalen Phasen. Die Progression der lokalen Phasen geschieht – je nachdem, ob auf die Verfügbarkeit von Ressourcen gewartet werden muss (lokale Phase ROUTED) oder nicht (restliche lokale Phasen) – entweder zeit- oder eventgesteuert. Die zeitliche Verzögerung wird durch eine payload event queue (PEQ) realisiert, in welche die Switchingmethode zu verzögernde Transaktionen einreihen kann. Nach Ablauf des Zeitarguments wird die Switchingmethode per Callback von der PEQ erneut (mit der fortgeschrittenen lokalen Phase) aufgerufen. Transaktionen, die nach dem Routing keine freien Ressourcen vorfinden, müssen arbitriert werden. Wird keine eigene Arbitrierungsmethode spezifiziert, kommt ein Standardschema zum Einsatz, welches blockierte Transaktionen nach dem first come, first served-Prinzip entsprechend der Zeit ihrer Ankunft in einen FIFO des ausgehenden Links einreiht. Die Freigabe eines Links oder Puffers löst ein Event aus, welches bei Verfügbarkeit der jeweils anderen Ressource die vorderste Transaktion aus dem FIFO entfernt und den Weiterleitungsprozess (lokale Phase FORWARDING) anstößt.

5

Ergebnisse

Zur Sicherung der Korrektheit der Simulationsergebnisse wurden diese gegen NIRGAM validiert. Zu diesem Zweck wurde erst eine Simulation mittels NIRGAM durchgeführt, da dessen Traffic-Generatoren vor der eigentlichen Simulation Logfiles mit den Zeitstempeln der zu injizierenden Paketen generieren und diese während des anschließenden Simulationsablaufes gelesen und abgearbeitet werden. Die generierten Logfiles werden nach Ablauf der Simulation nicht gelöscht und konnten somit für die Simulation mittels der TLM-Plattform zur Generierung der gleichen Traffic-Muster wiederverwendet werden. Die ebenfalls von NIRGAM praktizierte Arbitrierung mittels eines FIFO warf dabei Probleme auf, da Transaktionen, welche zum gleichen Simulationszeitpunkt belegte Ausgangsressourcen vorfinden, eventuell in unterschiedlicher Reihenfolge in die Warteschlange eingetragen werden (Nichtdeterminismus des SystemC-Schedulers bei gleichzeitig auftretenden Events). Von diesen Fällen abgesehen konnte eine vollständige Übereinstimmung der Simulationsergebnisse festgestellt werden. Zur Messung der Simulationsperformance wurden die benötigten Laufzeiten beider Plattformen für die gleichen synthetischen Traffic-Muster bestimmt und zueinander ins Verhältnis gesetzt. Abbildung 6 zeigt den Speedup des TLM-Ansatzes für verschiedene Lastszenarien. Während sich bei einer Paketgröße von nur einem Flit und großer Last der höhere Overhead der Transaktionsmodellierung bemerkbar macht (ca. 20% langsamer als zyklengenaue Simulation), zeigen sich bereits bei fünf Flits pro Paket (und Transaktion) Steigerungen um den Faktor 2,5 bis 6. Für realistische Paketgrößen zwischen 10 und 250 Flits können je nach Last Faktoren zwischen 5 und ca. 22 erreicht werden. Da NIRGAM intern bereits Flits als kleinste Einheit zur Übertragung einsetzt, dürfte der Effekt gegenüber RTL-Simulationen noch drastischer ausfallen. NoC-TLM simulation performance (4x4 mesh, synthetic traffic) 100% load 50% load 30% load 10% load

speedup [NIRGAM = 1.0]

20

10

5

2

1

1

10

100 packet size [flits]

Abbildung 6: NoC-TLM Performance

6

Zusammenfassung

In dieser Arbeit wurde eine flexible und modular aufgebaute Simulationsplattform vorgestellt, welche die OSCI TLM2-basierte Modellierung und Simulation einer Vielzahl von Network-onChip-Strukturen ermöglicht. Es konnte gezeigt werden, dass durch die Transaktionsmodellierung bei realistischen Paketgrößen eine 5- bis 20-fache Steigerung der Geschwindigkeit gegenüber zyklengenauen Ansätzen erreicht werden kann, ohne dabei an Genauigkeit zu verlieren.

Literatur [1] Coppola, M. et al.: “OCCN: a NoC modeling framework for design exploration“, S. 129163, Journal of Systems Architecture, Band 50, Ausgabe 2-3, Elsevier North-Holland, Inc., New York, USA, Februar 2004 [2] de Micheli, G., Benini, L.: “Networks on Chips: Technology and Tools“, Kap. 1, Morgan Kaufmann, 2006 [3] Fazzino, F., Palesi, M. und Patti, D.: “Noxim - Network-on-Chip Simulator“, URL: //sourceforge.net/projects/noxim [24.06.2008]

http:

[4] Hossain, H. et al.: “gpNoCsim - A General Purpose Simulator for Network-on-Chip“, S. 254-257, International Conference on Information and Communication Technology (ICICT), Dhaka, Bangladesh, März 2007 [5] Jain, L.: “NIRGAM - A Simulator for NoC Interconnect Routing and Application Modeling“, URL: http://nirgam.ecs.soton.ac.uk [22.10.2008] [6] Karim, F. et al.: “On-chip communication architecture for OC-768 network processors“, S. 678-683, Proc. of the 38th conference on Design automation (DAC ’01), Las Vegas, USA, Juni 2001 [7] Kumar, S. et al.: “A network on chip architecture and design methodology“, S. 105-112, Proc. of the IEEE Computer Society Annual Symposium on VLSI 2002, Pittsburgh, USA, April 2002 [8] Lee, S. et al.: “Transaction level model simulator for NoC-based MPSoC platform“, S. 170-174, Proc. of the 6th WSEAS International Conference on Instrumentation, Measurement, Circuits and Systems (IMCAS’07), Hangzhou, China, April 2007 [9] Lu, Z. et al.: “NNSE: Nostrum Network-on-Chip Simulation Environment“, Proc. of the Swedish System-on-Chip Conference (SSoCC’05), Stockholm, Sweden, April 2005 [10] Open SystemC Initiative: TLM 2.0 Standard, URL: standards/tlm20 [04.11.2008]

http://www.systemc.org/downloads/

[11] Xi, J. und Zhong, P.: “A Transaction-Level NoC Simulation Platform with ArchitectureLevel Dynamic and Leakage Energy Models“, S. 341-344, Proc. of the 16th ACM Great Lakes Symposium on VLSI (GLSVLSI ’06), Philadelphia, USA, 2006