&R9HULILNDWLRQYRQ$50'HVLJQVPLW5LYLHUD,37

Transkript

1 &R9HULILNDWLRQYRQ$50'HVLJQVPLW5LYLHUD,37 von Jaroslaw Kaczynski Technical Marketing Manager Advanced Product Group Aldec, Inc.,(LQI KUXQJ Embedded-Systeme enthalten üblicherweise einen Mikroprozessor sowie verschiedene Hardware-Peripherie und stellen eine Kombination aus Hard- und Software-Funktionalität dar. Sie werden unter anderem als zentrale Elemente in Luftfahrzeugen, der Medizintechnik, Telekommunikationssystemen eingesetzt. Ihre Popularität nahm erheblich zu, als es durch das Konzept des System-on-Chip (SoC) möglich wurde, ein komplettes System in einem einzigen Halbleiterchip unterzubringen.,,9hulilndwlrqyrq(pehgghg6\vwhphq 7\SLVFKH'HVLJQ)ORZV Die Entwicklung diskreter Embedded-Systeme gliedert sich traditionell in zwei getrennte Zweige, nämlich die Entwicklung der Systemsoftware und die Entwicklung der Peripheriemodule, also der Hardware. Die Systemsoftware-Entwickler können mit der abschließenden Verifikation ihrer Arbeit erst dann beginnen, wenn ein Prototyp der System- Hardware bereit steht. Dies jedoch ist inakzeptabel, wenn die Peripherie von Grund auf neu mit Verilog oder VHDL entwickelt wird (Bild 1), wie es etwa bei Systemen auf der Basis von ASICs (applikationsspezifische integrierte Schaltungen) oder FPGAs (Field-Programmable Gate Arrays) der Fall ist. Bild 1. Design-Flow für Embedded-Systeme auf ASIC- oder FPGA-Basis Wenn für die System-Verifikation auf das FPGA-Prototyping zurückgegriffen wird, ist das Einkreisen von Hardwareproblemen sehr schwierig und setzt meist bestimmte Modifikationen am System voraus (eingebettete Logikanalysatoren o. dgl.). Es hat nicht an Versuchen gefehlt, die Entwicklung von Peripheriemodulen und Systemsoftware zumindest zum Zweck der Verifikation miteinander zu kombinieren. Eine Verifikation des kompletten Systems mit einer HDL (Hardware Description Language) ist jedoch nicht praktikabel, da die Simulationsmodelle für Mikroprozessoren zu langsam sind, um die Systemsoftware während der HDL-Simulation zu verarbeiten. Große Schwierigkeiten bringt andererseits auch die Simulation eines ganzen Systems in C oder C++ mit sich, da sich diese Sprachen nicht für maschinennahe Hardware-Beschreibungen eignen. Das Prototyping für die Funktions-Verifikation von ASIC-Designs ist nicht sehr populär. In Bild 2 ist stattdessen ein Embedded-Systems-Design-Flow gezeigt, der sich besser für

2 diesen Zweck eignet. Wie man sieht, existieren die separaten Verifikations-Schleifen für System-Peripherie und System-Software nach wie vor. Sie enthalten diesmal jedoch keine Prototyping-Phase. Als neues Element ist stattdessen der mit Handover/Translation bezeichnete Block hinzugekommen, der den Informationsaustausch zwischen beiden Verifikationsschleifen abwickelt. Dieser Prozess schlägt zwar eine Brücke zwischen den Verifikationsschleifen für die System-Hardware und die System-Software. Er ist jedoch sehr zeitaufwendig, hauptsächlich da zuverlässige automatische Übersetzer zwischen C und HDL fehlen. Doch selbst wenn es einen solchen Übersetzer gäbe, ginge es nicht ohne eine Reihe manueller Modifikationen. Eine bedeutend bessere Lösung wäre deshalb die Integration der Entwicklungsumgebungen für die System-Hardware und die System-Software. Bild 2. Verbesserter ASIC-Design-Flow für Embedded-Systeme,QWHJULHUWH9HULILNDWLRQ Wenn weder reine Hardware- noch reine Software-Verifikationsumgebungen wirklich befriedigen können, sollte die Co-Simulation mit Hardware-Emulatoren oder Prototyping- Boards in Erwägung gezogen werden. Das klassische Konzept der Simulationsbeschleunigung setzt voraus, dass ein Teil des Systems hardwaremäßig implementiert und gemeinsam mit dem anderen, im HDL-Simulator verbleibenden Teil simuliert wird. Die Zugänglichkeit der im Simulator verbleibenden Teile ist hervorragend. Bei den in die Hardware verlagerten Teilen sind dagegen möglicherweise spezielle Maßnahmen nötig, um die Zugänglichkeit zu verbessern. Das Emulationskonzept setzt voraus, dass das gesamte System in den Emulator (oder das Prototyping-Board) übertragen wird. Diese Lösung ergibt ein Maximum an Verifikationsgeschwindigkeit, kann allerdings Einschränkungen hinsichtlich der Zugänglichkeit mit sich bringen, die jedoch für ein effizientes Debugging der System- Hardware notwendig ist. Daher stellt die Emulation das bevorzugte Verfahren für das Debugging der System-Software im (bereits stabilen) Umfeld der System-Hardware dar. Wird eine optimale, integrierte Umgebung für die Verifikation von Embedded-Systemen gewünscht, erscheint eine per Prototyping-Board beschleunigte HDL-Simulation die meisten Vorteile zu bieten. In den ersten Stadien der Systementwicklung ist die Simulationsbeschleunigung die beste Wahl. Geht es dagegen um die abschließende Verifikation der System-Software auf einer bereits fertig verifizierten Systemhardware- Plattform, so bewährt sich die Emulation noch besser. Beschleunigung und Emulation sollten mit demselben Prototyping-Board möglich sein.

3 ,,,$50 Die Firma ARM ist der wichtigste Anbieter im Bereich des Semiconductor Intellectual Property (IP) für SoCs auf der Basis von 32-Bit RISC-Mikroprozessoren (Reduced Instruction Set Computer). Die in diesem Artikel beschriebene Lösung Riviera-IPT nutzt die zur ARM7 -Familie gehörende, mit Cache ausgestattete Prozessor-Makrozelle ARM720T. Es handelt sich dabei um einen kompletten Hochleistungs-Prozessor mit 8 KB Cache, Schreibpuffer und Memory- Management-Funktionen. Sein virtuelles Speichersystem unterstützt Betriebssysteme wie Linux, Symbian OS und Windows CE. Ebenso wie alle übrigen Prozessoren der ARM7- Familie unterstützt er den komprimierten Thumb-Befehlssatz und die JTAG-basierte Software-Debug-Logik EmbeddedICE. Zu den wichtigsten Aspekten ARM-basierter Embedded-Systeme gehört die Advanced Microcontroller Bus Architecture (AMBA). Die AMBA-Spezifikation sowie detaillierte Informationen über die ARM-Cores finden Sie im Internet unter Entwickler ARM-basierter Embedded-Systeme können auf sämtliche Boards und Module der Integrator-Reihe zurückgreifen, die das Prototyping und die Verifikation des Systems wirksam vereinfachen. Spezielle Core-Module eröffnen den raschen Zugang zu Mikroprozessoren aus der ARM7- und ARM9-Familie. Riviera-IPT verwendet das Core- Modul CM720T. Bei der Arbeit an ARM-basierten Systemen kann sich der Softwareentwickler auf umfangreiche Ressourcen stützen. Die spezielle ARM Developer Suite (ADS) enthält zahlreiche Befehlszeilen-Tools sowie zwei Tools mit grafischer Benutzeroberfläche: Metrowerks Code Warrior Integrated Development Environment (IDE). AXD (extended ARM debugger).,95lylhud,37 Riviera-IPT ist eine vereinheitlichte Hardwarebeschleunigungs-Lösung, die für ein Maximum an Simulations-Performance sorgt und die Verifikation von ASIC- und FPGA-Designs gegenüber traditionellen Verifikationsmethoden um den Faktor 10 bis 50 beschleunigt. Der Geschwindigkeits- und Effizienzgewinn dieser vereinheitlichten Lösung resultiert aus der Zusammenführung mehrerer verschiedener Design- und Verifikationselemente zu einer nahtlosen Systemlösung. In dieser Systemlösung sind die Softwaresimulation für Co- Simulationen aus VHDL, Verilog, Assertions, C/C++ und SystemC sowie die Hardwarebeschleunigung kombiniert, jeweils optimiert und mit der industrieerprobten Common-Kernel-Architektur von Aldec verbunden. Die Riviera-IPT Beschleunigung ist in

4 zwei speziellen Systemkonfigurationen verfügbar: 3ODWIRUP für das ASIC-Prototyping und die System-Verifikation sowie 'HVNWRS für die reine RTL-Beschleunigung. Riviera-IPT mit ARM, die hier beschriebene Umgebung für die Verifikation ARM-basierter Embedded-Systeme, stellt eine spezielle Version der Platform-Konfiguration von Riviera-IPT dar. Die gesamte Umgebung besteht aus folgenden Elementen: Riviera-Simulator HES Acceleration Board mit Core-Modul CM720T Standardmäßige ARM-Debugging-Software Design Verification Manager (DVM) diese spezielle Software konfiguriert die gesamte Umgebung. Eine ihrer wichtigsten Funktionen ist die Aufteilung des Systems auf den Simulator und das Beschleuniger-Board. Der Design Verification Manager (DVM) integriert den HDL-Simulator, den Software- Debugger, das Beschleuniger-Board und den ARM-Prozessor in einer gemeinsamen Umgebung und ermöglicht dem Designer für Analyse- und Debugging-Zwecke den einfachen Zugang zu sämtlichen logischen Zuständen. Während die elementaren Hardware- Debug-Funktionen von Riviera geboten werden, nutzt der ARM-Prozessor die standardmäßige ARM-Debugging-Software. Bild 3. Beschleuniger-Board mit dem Integrator CM720T Modul. 'LH5LYLHUD,37+DUGZDUH Simulationsbeschleunigung und System-Emulation sind in Riviera-IPT mit ARM dank des HES2 Accelerator PCI Board mit ARM Integrator Core Module (Bild 3) möglich. Ein spezielles Daughterboard ist erforderlich, um die Steckverbinder des HES2 Beschleuniger-Boards an die des Integrator-Core-Moduls CM720T anzupassen. In Bild 3 ist der linke Rand des Daughterboards unterhalb des Core-Moduls zu sehen, während unten das am CM720T angeschlossene SDRAM-Modul erkennbar ist. 'LH5LYLHUD,376RIWZDUH Riviera, der HDL-Simulator in der Riviera-IPT-Umgebung, ist dafür zuständig, die HDL- Beschreibungen der Peripheriefunktionen des Embedded-Systems sowie der Testbench zu simulieren. Zusätzlich zu VHDL- und Verilog-Beschreibungen, die auch von anderen Simulatoren unterstützt werden, bietet Riviera Support für EDIF, SystemVerilog, SystemC und Assertions in verschiedenen Formaten, sodass hier ein ideales Simulationswerkzeug für die Co-Simulation und Co-Verifikation existiert. Der Design Verification Manager (DVM) ist jener Teil der gesamten Umgebung, der ihren Betrieb synchronisiert. Mit dem DVM kann der Systemdesigner entscheiden, welche Teile des Systems in die Hardware verlagert werden und welche im Interesse besserer

5 Debugging-Möglichkeiten im HDL-Simulator verbleiben sollen. Hier die wichtigsten Features des DVM: Import von Systembeschreibungen aus dem Riviera-Simulator Erkennung und Auswahl der im System installierten Hardware-Beschleuniger-Boards Selektion der in das Beschleuniger-Board zu verlagernden System-Module Ausführung von Synthese und Implementierung der selektierten Module Programmierung der Beschleuniger-Boards entsprechend der vom Benutzer gewählten Konfiguration Synchronisation des Betriebs von Simulator und Beschleuniger-Boards 'HU'HVLJQ)ORZYRQ5LYLHUD,37 Eine allgemeine Übersicht über den Design-Flow von Riviera-IPT mit ARM -Umgebung ist in Bild 4 zu sehen. Bild 4. Design-Flow von Riviera-IPT mit ARM -Umgebung Neben der Hard- und Software von Riviera-IPT muss der Systemdesigner Zugriff auf die Compiler, Linker und Debugger der ARM Developer Suite (ADS) haben. Eine typische Design-Session beginnt damit, dass in Riviera die Beschreibungen der System-Module angefertigt werden. Da hierfür sowohl Verilog- als auch VHDL-Vorlagen zur Verfügung stehen, ist dieser Arbeitsgang relativ einfach. In dieser Phase sollte ebenfalls die Testbench erstellt werden, die den Verifikationsprozess kontrolliert. Wenn der Designer Zugriff auf die Simulationsmodelle des ARM-Cores hat, kann der erste Verifikationsschritt vollständig in Riviera erfolgen. Steht das Simulationsmodell des ARM-Cores dagegen nicht zur Verfügung oder werden höhere Verifikationsgeschwindigkeiten verlangt, sollte der Designer den DVM starten, um die System-Module zwischen Simulator und Beschleuniger-Board aufzuteilen, was einer Wahl zwischen Simulationsbeschleunigung und Emulation gleichkommt. Es existieren außerdem zwei Systemkonfigurationen, die sich auf die maximale Verifikationsgeschwindigkeit und die Zugänglichkeit des Systems auswirken. Während sich die STANDARD-Konfiguration durch bessere Zugänglichkeit auszeichnet, aber mit einer geringeren Verifikationsgeschwindigkeit einhergeht, ist die BRIDGE-Konfiguration schneller, während es um die Zugänglichkeit einiger Teile des Systems schlechter bestellt ist. Da eine Konfigurationsänderung nicht ohne Neuprogrammierung des Boards möglich ist, sollte der Designer gleich von vornherein die geeignetste Konfiguration wählen. Ist über die Konfiguration entschieden, führt der DVM die Synthese und Implementierung (falls notwendig) durch, programmiert das Beschleuniger-Board und initialisiert die Co- Verifikation.

6 Bevor jedoch die eigentliche Co-Verifikation gestartet wird, sollte die compilierte und gelinkte Systemsoftware in den Programmspeicher des ARM Integrator Core-Moduls geladen und die Debugging-Session im AXD-Modul begonnen werden. Sind alle diese vorbereitenden Arbeitsgänge erledigt, ist das gesamte System für eine integrierte, vollständig synchronisierte Co-Verifikation von Hard- und Software bereit. Wird die Verifikation vom Riviera-Simulator aus kontrolliert (z.b. Einzelschritt-Verarbeitung des HDL-Codes), kann die Kontrolle bei Bedarf an den Mikroprozessor des Beschleuniger- Boards übertragen werden. Wann immer der Systemsoftware-Entwickler im AXD-Debugger eine Codezeile ausführt, die eine Reaktion der System-Hardware erfordert, wird die Kontrolle an Riviera übergeben, bis die nötige Rückmeldung erzeugt wird. 9)D]LW Die im vorliegenden Beitrag vorgestellte Lösung gestattet die schnelle und anwenderfreundliche Verifikation ARM-basierter Embedded-Systeme. Weiterführende Literatur zu Riviera-IPT mit ARM kann von Aldec angefordert werden.