10. GI/ITG/GMM MBMV 2007

Transkript

1 Architektur einer Flexiblen, Wiederverwendbaren Testbench zur Verifikation Paketverarbeitender Hardware in SystemC Stephan Kubisch, Harald Widiger, Ronald Hecht, Dirk Timmermann, Martin Siemroth Institut für Angewandte Mikroelektronik und Datentechnik Universität Rostock 10. GI/ITG/GMM MBMV März 2007, Erlangen, Deutschland

2 Inhalt Architektur einer Flexiblen, Wiederverwendbaren Testbench zur Verifikation Paketverarbeitender Hardware in SystemC 1. Motivation 2. Hintergrundinformationen 3. Aufbau der Testumgebung 4. Vor- & Nachteile 5. Zusammenfassung 2

3 1. Motivation Simulation & Verifikation Designs werden komplexer! Verifikation ist umso aufwendiger bzgl. Zeit und Kosten Ziel 1: Wiederverwendbarkeit - für versch. Designs - für versch. Schritte im Design Flow Ziel 2: Handhabbarkeit - Abstraktion, Objektorientierung Eigene Forschungsarbeit Kooperation mit Siemens Networks (2Q/07 Nokia Siemens Networks) Mechanismen & Baugruppen speziell in Zugangsnetzwerken ähnliche, wiederkehrende Szenarien und Testfälle 3

4 2. Hintergrundinformationen Konfiguration & Steuerung Upstream Input Downstream Output Paketverarbeitung PPM Upstream Output Downstream Input Paketverarbeitende Systeme als Device-Under-Test (DUT) Ähnliche Interfaces - Datenpfade von links nach rechts, Konfig.- & Steuerleitungen Gleiche/ähnliche Basis-Protokolle Schichtenhierarchie nach OSI Strukturierte, gekapselte Informationseinheiten nach OSI Gemeinsamkeiten nutzbar machen & wiederverwenden 4

5 2. Hintergrundinformationen Application (Testbench) wpcap.dll packet.dll User Level NPF Device Driver Kernel Level SystemC C++, IEEE Standard Beschreibung von HW-Strukturen Basiskonzept - Module, Prozesse - Schnittstellen, Ports, Kanäle SCV, TLM und MS Bibliotheken als zusätzliche Erweiterungen WinPcap Network C++ Bibliothek Zugriff auf physikalische Netzwerkschnittstelle bekannt durch libpcap (UNIX) z.b. Snort & Wireshark 5

6 3. Aufbau der Testumgebung Gesamtstruktur Zweiteilung der Testumgebung - Testbench (= Datenebene) Stimuli-Erzeugung und Auswertung der Antworten - Testharness (= Zeitebene) Stimuli-Übertragung, abhängig vom Interface Compiler-Direktive zur Unterscheidung zwischen Software und FPGA Testbench Optionale gemeinsame Datenbasis Stimuli- Generator / Definition der Testfälle BFM send data_path_type Testharness HDL HDL entity PPM is port ( ); end PPM; BFM recv data_path_type Monitor / Analyse der Antworten Transportschicht Vermittlungsschicht Sicherungsschicht #ifdef Testharness FPGA BFM send WinPcap Testharness FPGA BFM recv WinPcap #ifdef Sicherungsschicht Vermittlungsschicht Transportschicht 6

7 3. Aufbau der Testumgebung Message-Klasse Container für Protokoll-Informationen Realisierung der typ. Struktur von Informationseinheiten nach OSI Methoden zur Manipulation eines Message-Objektes (push(), pop(), pull(), trim(), length(), ) Struktur - allokierter Speicherbereich des Objektes - für Nutzdaten reservierter Speicherbereich - aktuell gültige Daten im reservierten Bereich m_buff m_buffend m_size Gültige Daten Reserviert, momentan ungültig Allokiert, momentan nicht reserviert 7

8 3. Aufbau der Testumgebung Umsetzung der Protokoll-Hierarchie Für Stimuli-Erzeugung und Auswertung - Ver-/Entpacken von Paketen - Container für Protokolle Eine <class> pro OSI Schicht - Implementierung vererbter Schnittstellen - Ports zu über- & untergeordneter Schicht - Kommunikation über Ports & Schnittstellen nicht zwingend OSI beliebige Schichten/Protokolle class transport_layer : virtual public transport_up_if, virtual public transport_down_if, public sc_module { sc_port<application_down_if> al; //to Application Layer sc_port<network_up_if> nl; //to Network Layer }; class network_layer : virtual public network_up_if, virtual public network_down_if, public sc_module { sc_port<transport_down_if> tl; //to Transport Layer sc_port<datalink_up_if> dl; //to Datalink Layer }; class datalink_layer : virtual public datalink_up_if, virtual public datalink_down_if, public sc_module { sc_port<network_down_if> nl; // to Network Layer sc_port<physical_up_if> phy; // to Physical Layer }; 8

9 3. Aufbau der Testumgebung Bus Functional Models Übergang von Daten- in Zeitebene BFM implementiert zwei Schnittstellen - Zur Testbench, Umwandlung einer Message in echte Bits/Bytes - Protokoll der Schnittstelle des BFMs Individuell für ein DUT Beispiele: - BFM für eine VHDL-Entität - BFM für WinPcap-Schnittstelle Paket BFM send Data SoF EoF CLK DUT (VHDL) Paket BFM recv Data SoF EoF 9

10 4. Vor- & Nachteile Vorteile Die vorgestellten Mechanismen sind nur flexible Container Anpassung an/erweiterung um individuelle Funktionen C++ & SystemC sind mächtige Sprachen einfachere Beschreibung komplexer Testfälle Nutzung von WinPcap Verifikation von PPMs auch auf FPGA Prototypen (gleiche Testfälle) Nachteile Verschiedene C++ Compiler sind nicht zwingend kompatibel, z.b. ModelSim s gcc oder VisualC++ Kompromisse bzw. Umwege im Code SystemC ist nur begrenzt synthesefähig Entwickler müssen nach wie vor 2 Sprachen beherrschen 10

11 4. Zusammenfassung Gerüst einer flexiblen Testumgebung Nachbildung - Schichten-Hierarchie - typische Struktur von Informationseinheiten speziell für paketverarbeitende Systeme - Internet Paket Processing - Network-on-Chip basierte Systeme - Datenstrom-basierte Systeme (Grafik, Verschlüsselung, ) Verifikation von HDL-Modellen in Software Prototyp-Verifikation z.b. in FPGAs auf Entwicklungsboards 11

12 Vielen Dank! Fragen? 12

13 Backup Architektur einer Flexiblen, Wiederverwendbaren Testbench zur Verifikation Paketverarbeitender Hardware in SystemC m_buff = Pointer auf Start des allokierten Speicherbereiches (fix) m_buffend = Pointer Ende des allokierten Speicherbereiches (fix) m_mstart = Pointer auf Start der aktuelle gültigen Daten der Nachricht (SoF, dynamisch) m_mend = Pointer auf Ende der aktuelle gültigen Daten der Nachricht (EoF, dynamisch) m_size = gesamter für die Nachricht allokierter Speicher/Puffer m_len = aktuelle Länge einer Nachricht (headers+payload) m_room = bei Initialisierung für Nachricht reservierter Speicher/Puffer m_tail = m_size m_room, Größe des unreservierten aber allozierten Speichers (eine art reserve) m_buff m_mstart m_mend m_buffend m_length m_size m_room Gültige Daten Reserviert, momentan ungültig Allokiert, momentan nicht reserviert 13