Ein einheitlicher Entwicklungsablauf für Embedded Systeme

Wenn Entwickler über System-on-Chip (SoC)-Entwürfe sprechen, geht es meistens um Embedded-Systeme, die sowohl Hardware als auch Software enthalten.Viele meinen sogar, dass ein Chip mindestens einen eingebetteten Prozessor enthalten muss, um als SoC zu gelten. Für Embedded-Systeme gibt es viele Design- und Verifikationsherausforderungen, und diese gelten auch für SoCs. Die Halbleitertechnologie spielt dabei eigentlich keine Rolle; eingebettete FPGA-Designs können heutzutage riesig sein und sind genauso komplex wie ASICs oder kundenspezifische Chips. Die Bewältigung der Entwicklungsherausforderungen für diese Systeme erfordert einen automatisierten, einheitlichen Ablauf, der sowohl die Hardware als auch die Software abdeckt und sich über Design, Verifizierung, Software und Dokumentation erstreckt.

Große Designs sind nur möglich, weil viel von vorangegangenen Projekten, kommerziellen IP-Anbietern und Open-Source-Sites wiederverwendet wird. Ein Großteil dieser IP‘s erfordert Embedded Software wie Firmware und Gerätetreiber, ein Hauptgrund, warum ein einheitlicher Entwicklungsablauf so wichtig ist. Das gesamte System wird anhand einer Spezifikation entwickelt, bei der es sich gewöhnlich um ein Textdokument handelt. Dies ist ein schwieriger Prozess, da die Entwickler die Absicht in eine natürliche Sprache übersetzen müssen und dann die Designer, Verifikationsingenieure und Programmierer die natürliche Sprache in Silizium und Code umsetzen müssen. Der beste Ansatz, die Entwicklung zu beschleunigen, ist die Verwendung ausführbarer Spezifikationen. So können große Mengen an Hardware und Software automatisch generiert werden.

Der Wert dieser Automatisierung ist noch größer, wenn sich die Spezifikation ändert, was bei jedem SoC-Projekt mehrmals vorkommt. Es gibt viele Gründe für solche Veränderungen, zum Beispiel neue Funktionsanforderungen, Reaktionen auf den Wettbewerb und neue Varianten der geltenden Vorschriften. Darüber hinaus kann die Einhaltung von Zeit-, Platz-, Leistungs-, Prüfbarkeits-, Sicherheits- und Schutzzielen während der Implementierung eine Anpassung der Spezifikationen nach sich ziehen. Jede Spezifikationsänderung hat Auswirkungen auf die Hardware, die Software oder beides. Bei einem rein manuellen Entwicklungsablauf haben die Designer und Programmierer keine andere Wahl, als die notwendigen Änderungen von Hand vorzunehmen.

Das eingebettete System muss erneut verifiziert werden, um die neue Funktionalität zu prüfen und sicherzustellen, dass bei der Aktualisierung nichts fehlerhaft ist. Spezifikationsänderungen wirken sich auch auf das Verifizierungsteam aus, da deren Umgebung oft ebenfalls von Hand aktualisiert werden muss. Bei einem rein manuellen Entwicklungsablauf haben die Designer und Programmierer keine andere Wahl, als die notwendigen Änderungen von Hand vorzunehmen. Ohne Automatisierung können die Teams leicht aus dem Takt geraten, wenn sich die Spezifikation ändert.  Bei der Verifizierung und Validierung werden oft Probleme aufgedeckt, die darauf zurückzuführen sind, dass die Hardware- und Softwareteams nicht mit derselben Version der Spezifikation arbeiten. All diese zusätzliche Arbeit verbraucht Ressourcen, erhöht die Projektkosten und kostet Zeit, wodurch sich die Markteinführungszeit (TTM) verlängert.

Die Automatisierung des Design- und Verifikationsprozesses durch die Verwendung von ausführbaren Spezifikationen war von Anfang an das Hauptaugenmerk von Agnisys. Aus den Spezifikationen generieren die Werkzeuge RTL-Designcode, Verifikationstestbenches und -tests, Gerätetreiber, Dokumentation und ATE-Programme (Automated Test Equipment) für die hergestellten Chips. Agnisys automatisiert die Entwicklung von Registern, Speichern, Sequenzen, Busschnittstellen und verschiedenen Arten von IP. Darüber hinaus stellt Agnisys Werkzeuge zur Verfügung, um all diese Elemente und vom Anwender entwickelte Blöcke zu einem kompletten SoC zu verbinden. Dies spart Zeit und Ressourcen während der anfänglichen Entwicklung und zahlt sich während des gesamten Projekts aus. Änderungen an der Spezifikation werden automatisch in der neu generierten Hardware, Software, dem Testbench und der Dokumentation berücksichtigt, so dass sichergestellt ist, dass die Teams auf dem gleichen Stand bleiben.

Agnisys hat einen einheitlichen Entwicklungsablauf für Embedded Systems definiert, der alles miteinander verzahnt. Agnisys bietet eine Methodik und Richtlinien dafür, wie und wann die einzelnen Werkzeuge eingesetzt werden, um den größten Nutzeffekt zu erzielen. Agnisys hat mit führenden Kunden zusammengearbeitet, um deren Bedürfnisse zu verstehen und einen Workflow zu entwickeln, der ihre Anforderungen erfüllt. Darüber hinaus hat Agnisys ein eigenes kleines SoC-Design entwickelt, um potenziellen Anwendern zu zeigen, wie die Werkzeuge und der Ablauf in einem realen Projekt funktionieren. Das Design bildet den Durchschnitt der über eine I2C-Schnittstelle empfangenen Sensordaten. Die Sensorwerte werden eingelesen und von der Anwendungslogik des Anwenders in einen gemittelten Wert umgewandelt, alles unter der Kontrolle der auf einer CPU laufenden Software.

Das folgende Diagramm zeigt das SoC-Design und die Stellen, an denen die Agnisys-Tools im Ablauf verwendet wurden. Die CPU ist der quelloffene SweRV Core EH1, eine 32-Bit, 2-Wege super-skalare, 9-stufige Pipeline Implementierung der RISC-V Architektur. Abgesehen von diesem Kern und der RTL- und Software-Mittelung wurde das gesamte Projekt mithilfe des Unified Flow automatisiert:

  • Die Standard Library of IP Generators (SLIP-G™) generierte die RTL für den I2C-Master und den Code zu dessen Konfiguration und Steuerung.
  • Die Agnisys IDesignSpec™-Familie generierte die RTL für die Steuer- und Statusregister (CSRs) und die APB-Schnittstelle zur Verbindung mit der CPU
  • Agnisys verwendete unseren DVinsight™ Smart Editor beim Schreiben der SystemVerilog-RTL für den Mittelwertbildungsfilter-Logikblock
  • Mit dem SoC Enterprise™ Smart SoC Assembly Tool wurden alle Blöcke miteinander verbunden und die Top-Level-RTL erstellt.
  • Specta-AV™ generierte die komplette Simulationsumgebung der Universal Verification Methodology (UVM), einschließlich Registermodell, Agenten, Abdeckung und Testsequenzen
  • Automatic SoC Verification and Validation (ASVV™) generierte eine synchronisierte C-UVM-Verifikationsumgebung und den eingebetteten C-Code zur Verifizierung der CSRs

 

einheitlichen Entwicklungsablauf für embedded Systeme

Automatic SoC Verification and Validation (ASVV™) generierte eine synchronisierte C-UVM-Verifikationsumgebung und den eingebetteten C-Code zur Verifizierung der CSRs.

Agnisys hat ein Webinar aufgezeichnet, in dem der einheitliche Embedded-Entwicklungsablauf und die Verwendung der Agnisys Werkzeuge innerhalb des Ablaufs, einschließlich der Ergebnisse für unser Beispiel-SoC-Design, näher erläutert werden.