Startseite > Messen + Testen > Masters of Complexity

embedded world TechTalk

Masters of Complexity

21. März 2018, 9:46 Uhr | Dr. Constantin Tomaras, Ressortredakteur für Systemdesign

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Prototyping mit FPGAs

CT: Jürgen Jäger setzt bei Cadence FPGA-basierte Prototypen für Design&Verifikation ein. Wie umfangreich fällt das aus?
Jürgen Jäger: Unser System ist ein FPGA-basierendes Prototypensystem (Bild 3), bestehend aus einer Hardwarekomponente (Gehäuse, Netzteil, FPGA-Boards, Erweiterungskarten, usw.) und mehreren Softwarekomponenten, sowohl zur Implementierung als auch zum eigentlichen Betrieb. Dieses Protium-System wird dazu verwendet eine pre-silicon-Version eines Chip/ASICs bereitzustellen, mit dem nun die gesamte Systemfunktionalität, einschließlich der externen Schnittstellen überprüft werden kann.

Jobangebote+ passend zum Thema

Ingenieur/Elektroingenieur/Elektrotechniker als Field Application Engineer

GEYER Electronic GmbH, Planegg

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

CT: Spielen Nebenbedingungen eine Rolle?
JJ: Hauptanwendungsbereich ist die Systemsoftware darauf zu entwickeln und das Zusammenspiel zwischen Hardware und Software zu prüfen und zu optimieren. Folglich muss das Protiumsystem dazu in der Lage sein, einen weiten Bereich von Applikationen abzudecken und verfügt daher über eine Vielzahl von Freiheitsgraden wie Kapazität, Arbeitsgeschwindigkeit, Systemschnittstellen (e.g. PCIe, Memories, uws.) und Designsprachen (VHDL, SystemVerilog, Verilog, etc.). Am Ende müssen all diese Freiheitsgrade ausbalanciert werden um das bestmögliche Ergebnis zu erzielen.

CT: Wie skaliert Ihr System mit weiteren Freiheitsgraden?
JJ: Da unser System dafür ausgelegt ist, im Prinzip jedes ASIC zu implementieren und jede Software laufen zu lassen, ist es notwendigerweise äußerst skalierbar. Das Grundsystem selbst kommt in unterschiedlichen Größen und kann erweitert werden. Neue Freiheitsgrade, z.B. eine weitere Schnittstelle … "heute brauchen wir zusätzlich noch einen USB-Port" ... können jederzeit mittels Erweiterungskarten hinzugefügt werden. Gleiches gilt auch für zusätzliche Softwarekomponenten. Das System wurde von Anfang an konzipiert um äußerst skalierbar und extrem erweiterbar zu sein.

CT: Nutzen Sie im Entwicklungsfluss simultan Informationen aus verschiedenen Abstraktionsebenen?
JJ: Die einfache Antwort ist "ja". Wir starten immer mit einem Marktanforderungsdokument, MRD, das auf hoher Abstraktionsebene die grundsätzlichen Funktionen und Eckwerte beschreibt. Als nächstes folgt dann eine Machbarkeitsstudie, die letztendlich in Verbindung mit dem MRD zu einem Satz von detaillierten Funktionsspezifikationen führt.
Beides ist allerdings nicht statisch, sondern wird bei Bedarf während der Entwicklungsphase immer wieder angepasst und geändert. In der Entwicklungsphase selbst, verwenden wir einen Bereich unterschiedlicher Abstraktionsebenen; von high-level-C/C++-Beschreibungen bis hin zu manuellem Layout im PCB-Design, um z.B. trace-length-matching und skew-control zu implementieren, beides ist absolut notwendig zum zuverlässigen Betrieb, aber auch um viele Freiheitsgrade bestmöglich abdecken zu können.

CT: Kennen Sie seltene Timinig-Fehler?
JJ: Ich würde sagen, dass jeder der ein hinreichend komplexes System entwickelt, mit seltenen Timingfehlern in Berührung kommt. In unserem Fall sehen wir hauptsächlich zwei Gruppen davon:

Einfache timing-violations und race-conditions, oft verursacht von Designfehlern (z.B. cross-domain-crossing), manchmal auch durch Bauteile die mit Umgebungsbedingungen zu stark driften. All diese Fehler sind oft schwer zu finden, aber einfach zu beheben sobald sie gefunden wurden.
Etwas, das mehr und mehr auftritt, weil zunehmend high-speed serial links (SERDES) verwendet werden, sind die damit verbundenen Bit-Fehler-Raten. Bit-Fehler-Raten sind in Bereichen wo SERDES oft verwendet werden, z.B. in der Telekommunikation, kein Problem. Man hört einfach nur ein kurzes Knattern am Handy oder es gibt einen falschen Pixel am Bildschirm, den man eh nicht sieht. Bei einem Protoypesystem ist das anders, jeder Bitfehler, der nicht in Echtzeit erkannt und korrigiert wird, führt zu einem echten Fehler. Wir haben daher umfangreiche Korrekturen in unserem System implementiert, die bis zu 40% der SERDES-Bandbreite beanspruchen.

CT: Beobachten Sie Emergenz?
JJ: Ja, das tun wir und nicht nur das, Aufdecken von Fehlern welche erst durch das Zusammenspiel von vielen Dingen zutage treten ist ein wichtiger Grund weshalb unsere Systeme überhaupt benötigt werden.
Ein kurzes Beispiel: Ein Anwender hat beobachtet, dass wenn er LINUX in seinem Design, auf unseren Systemen bootet, es manchmal funktioniert aber manchmal auch nicht. Jeder seiner unit-Tests, mit der die einzelnen Komponenten getrennt getestet werden, funktioniert 100%. Was ist also los? – Am Ende stellt sich heraus, dass während dem boot-Prozess eine Softwarekomponente in einem bestimmten Speicherbereich "Nullen" erwartet – Während Simulation und formaler Verifikation ist das nicht aufgefallen, weil dort Speicher nur "simuliert" werden und immer einen definierten Zustand haben.
Auf dem Prototypensystem wurden physikalische Speicherchips verwendet, die mal so und mal so aufwachen, was dann manchmal zu den Fehlern führt.
Die letztendliche Ursache, oder der Fix war, dass eine andere Softwarekomponente zur Speicherinitialisierung, die in Isolation auch 100% funktioniert, zum falschen Zeitpunkt, oder gar nicht aufgerufen wurde.

CT: Benutzen Sie KI-Algorithmen?
JJ: Interessante Frage, da könnte man nun auf die KI-Definition eingehen. Für uns ist Maschinelles Lernen wichtig, der Begriff ist zutreffender als KI.
Solche ML-Algorithmen verwenden wir an einigen Systemstellen. Zum einen während der Partitionierung eines Designs in mehrere Teile, wobei wir einen sogenannten Compile-Find durchführen, dabei werden Parameter des Partitionierungsalgorithmus nach einem Zufallsprinzip verändert und das System analysiert dann die Ergebnisse und "lernt" welche Kombination von Parametern für ein Design oder Designstyle die besten Ergebnisse liefert.

Ähnlich auch bei dem FPGA-place&route-Schritt, wobei dort nicht Parameter des Algorithmus variiert werden, sondern der Ausgangspunkt, der sogenannte Seed.
Dies ist erst der Anfang und wir arbeiten bereits an weiteren ML-Applikationen um unsere Systeme und die Nutzbarkeit für unsere Anwendern weiter zu verbessern.