Entwicklungsumgebungen
Low-Power-Spezifizierung in IDEs
Fortsetzung des Artikels von Teil 1
Leistungsspezifikation
Als die Industrie die Bedeutung eines Standardformates zur Spezifizierung der Leistung erkannte, wurden zwei Arbeitsgruppen gegründet. Die Silicon Integration Initiative (Si2) definierte das Common Power Format (CPF), Accellera definierte das, neuerdings IEEE1801-2015 standardisierte Unified Power Format (UPF). Trotz ihrer Unterschiede versuchen alle Leistungsumsatz-Formate alle Aspekte des Low-Power-Designs zu dokumentieren und diese Information an automatisierte Werkzeuge für Design und Verifikation weiterzugeben.
Eine IEEE1801- oder CPF-Spezifikation geht über die RTL-Designbeschreibung hinaus. Das ist notwendig um die Beschreibung von der Implementierung zu trennen und eine einzige Beschreibungsdatei in den unterschiedlichen Entwicklungsschritten zu verwenden. Allerdings können Spezifikation und RTL-Beschreibung damit während des Designflusses divergieren: Umbenennung von Blöcken oder Signalen sowie Änderungen in der Designhierarchie können an der Spezifikation vorbei gehen und Verifikationsfehler verursachen.
Die Definition der Leistungsspezifikation in einem eigenen, zweckgebundenen Format, gestaltet diese unabhängig von der eingesetzten Design- und Verifikationssprache. Deshalb kann so eine Datei, bzw. große Teile davon, über viele Projekte hinweg verwendet werden. Damit ergibt sich allerdings ein weiterer Eintrag in der langen Liste von Sprachen und Formaten mit der ein SoC-Entwicklungsteam umgehen können muss.
IDE zur Vereinfachung
Eine IDE für das SoC-Design und Verifikation kann den Lernprozess für das Arbeiten mit Leistungsspezifikationen unterstützen. Spezifikationscode kann im Kontext analysiert und die Struktur der Sprachen und Formate visualisiert werden.
Im Hintergrund läuft dabei immer ein Compiler, der den Sourcecode mit jeder Änderung verarbeitet und das Design in eine Datenbank, respektive der vollständigen Verifikationsumgebung, übersetzt. Eine typische IDE kann dabei viele nützliche Aufgaben erfüllen, u.a.:
- Syntaxprüfung
- Statische Analyse
- Visualisierung und Formatierung
- Kompilierung und Interpretation
- Simulation für das Debugging
Die Kombination von Programmiersprachen zu Hardwarebeschreibung, Verifikation und Leistungsspezifizierung durch eine IDE erweitert die Analysemöglichkeiten einschließlich der Debuggingphase.
Unterstützende Darstellung
Visualisierung ist wahrscheinlich die offensichtlichste Unterstützung, welche eine IDE beim Schreiben und Testen jeglichen Design- oder Verifikationscodes leisten kann. Eine IDE bietet viele Darstellung, z.B. SourceCode-Editor, Hierarchie-Browser oder den Designplan. Zwischen diesen Ansichten kann bei Betrachtung eines Signals oder Elementes umgeschalten werden.
Farbkodierung ist ein gängiger Weg um gemeinsame Elemente über diese Ansichten hinweg zu verbinden. Bild 1 zeigt eine für das Low-Power-Design relevante IDE. Mit dem Laden der Leistungssspezifikation und anderer Design- und Verifikationsformate wurden die Leistungsbereiche erkannt.
Jobangebote+ passend zum Thema
Jeder Bereich wird in einzigartiger Farbe angezeigt, die sowolhl im Hierarchiebrowser als auch im Designplan vorkommt. Im Beispiel fallen die meisten Designelemente in den “PDCore”-Leistungsbereich, der grün markiert ist. Der UART-Block kann je nach Bedarf ein-/ausgeschaltet werden; Der “Pduart”-Bereich ist rot markiert. Ein dritter Bereich “Pdsmc” ist im Browser lila markiert, der Designplan weist diese Hierarchie aber nicht aus. Diese Blöcke würden erst bei Anzeige bis herunter in den SMC-Block sichtbar.
- Low-Power-Spezifizierung in IDEs
- Leistungsspezifikation
- Unterstützter Arbeitsfluss
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Neues Release
Sigasi Studio 4.0 & XPRT
Systemdesign / Low-Power-Verifikation
Optimierte Leistungs- und Temperaturkompromisse
Industriesteckverbinder von Harting
Schnittstellen-Entwurf nach Maß
Intensivseminar mit Robert Berger
Fundierter Schnelleinstieg in Embedded Linux
Elektronik-Zeitreise
Fernsehen im Bergbau
