Startseite > Halbleiter > Analog- / Mixed-Signal > ASIC-Design am Komplexitätssprung

Zum Stand der MEMS-Technologie

ASIC-Design am Komplexitätssprung

19. Dezember 2017, 17:35 Uhr | Constantin Tomaras

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 2

Die Verifikationspraxis

Welches sind die, für die MEMS-Sensorik, fünf wichtigsten Werkzeuge/Fähigkeiten, die ein Entwickler für die nächsten drei Jahre beherrschen sollte?

Die Antwort fällt nicht einfach, weil es eben so viele verschiedene Entwicklerrollen gibt. Meine Abteilung zählt sieben verschiedene Kompetenzrollen: neben System Architekt, Analog- und Digital-, Verifikations- und Testingenieur, noch Projektleiter sowie Layoutingenieur. Welche Kompetenzen für alle Rollen relevieren ist schwer zu sagen, für den Verifikationsingenieur definitiv UVM, Kenntnisse in SystemVerilog, e und SystemC.

Was unterscheidet den Chip- oder Systemdesigner vom Verifikationsingenieur?

Im Wesentlichen arbeiten Designer in einem Mindset zur Funktionskonstruktion unter dem Beweis, dass das Design die Spezifizierung erfüllt. Der Verifikationsingenieur steht diesem gegenüber und hat eben dieses zu widerlegen: Er muss die Stelle finden, an der das Design bricht. Völlig verirrt sind Verifikationsingenieure mit der Ansicht, sie müssen das Design validieren: Nein, der Verifikationsingenieur muss es falsifizieren und eigentlich Falsifikationsingenieur heißen!

Können Sie sich, „unwissenschaftliche Designs“ vorstellen, die derart konstruiert sind, dass sie nicht falsifiziert werden können?

Zunächst einmal ist falsifizieren einfacher als verifizieren. Es ist einfacher möglichst alle Bugs zu finden, als die Freiheit von Bugs zu beweisen. Wir sprachen über Komplexität. Ist diese gegeben, wird es fraglich, ob so etwas wie Freiheit von Bugs überhaupt existiert. Jedenfalls ist es auch Aufgabe des Designers ein prüfbares und verifizierbares Design zu erstellen.

Jobangebote+ passend zum Thema

Trainee Vertrieb und Produktmanagement (m/w/d) für Berufs- und Quereinsteiger

GLYN GmbH & Co. KG, Idstein

Trainee Vertrieb und Produktmanagement (m/w/d) für Bachelorabsolventen

GLYN GmbH & Co. KG, Idstein

Field Account Manager (m/w/d) für das Vertriebsbüro in Pforzheim

GLYN GmbH & Co. KG, Pforzheim

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Gibt es standardisierte Verifikationsstrategien ähnlich Monte-Carlo-Verfahren in der numerischen Simulation?

Es gibt hier best practice aber keine Kochrezepte. Verifikation ist ein Bereich, welcher die Kreativität wie in der Entwicklungsarbeit fordert. Der Designer möchte sich dadurch beweisen, dass er besonders clever entwirft und die Randbedingungen ressourcenoptimal umsetzt.

Der Verifikationsingenieur hat eben dieses Design kaputt zu schießen! Natürlich gibt es einige Standardmethoden, aber am Ende des Tages liegt die Kunst des Meisters nicht in den Werkzeugen, sondern in deren Anwendung.

Deshalb spielen geschlossene Toolchains in unserem Geschäft eher eine untergeordnete Rolle. Wir nutzen Tools von unterschiedlichsten Anbietern und erweitern und ergänzen sie auch gerne. Wir entwickeln unsere Verifikationsmethodik ständig weiter, vor allem in Richtung Analog-Mixed-Signal. Sehr viel ist eben auf Schaltplanebene entwickelt und nicht in einer Hardwarebeschreibungssprache.

Wie hilft Standardisierung in der Mixed-Signal-Designverifikation?

Sie gestaltet die Mixed-Signal-Verifikation effizienter und lückenloser. Ich sehe heute noch an manchen Punkten eine Verifikationssituation wie vor 20 Jahren: Wenn der Designer seine Arbeit getan sieht, geht er ins Tapeout. Damit ist die Vollständigkeit der Simulation sowie der Methoden noch nicht hinreichend beschrieben. Hier entsteht eine starke Abhängigkeit von der Erfahrung des Designers und seiner Peers im Design Review. Zudem fehlt Verifikationseinsteigern oft der rote Faden. Standardisierung hilft hierbei enorm.

Wie sieht so eine Standardisierung aus, Stichwort A/M-S-toplevel-verification-methodology?

Ich denke, diese Standardisierung müsste beschreiben, welche Art von Funktion und Performanz, aber auch welche Art von Fehlern und Robustheit durch welche Simulationsmethode, auf welcher Abstraktionsebene, mit wie vielen Zyklen und welcher Genauigkeit verifiziert werden muss. Eine Kernfrage stellen die Mindestanforderungen an eine A/M-S-Applikations-Verifikation.

Weiterhin wird das Thema selbstcheckende Testbenches immer noch sehr stiefmütterlich behandelt. Bestimmte Parameter werden aus den Simulationen automatisch extrahiert und zu einer Pass-Fail-Information gesellt sich immer auch der eigene Zugang des jeweiligen Toolherstellers.

Handelt es sich bei dem „seltenen Digitalen Bug“ aus Ihrem Vortrag um ein emergentes Feature, das nicht auf einzelne Komponenten zurückgeführt werden kann? Was bedeutet das für die Verifikationsstrategie?

Ich würde das nicht so beschreiben: Es ging eher um eine neue Applikation, deren neue Art und Weise des Sensorzugriffs wir bei der Konzeption nicht im Hinterkopf hatten. So weit hatten wir an dieser Stelle noch gar nicht gedacht. Diesen Fall hatten wir also in der Verifikation noch gar nicht abgedeckt. In der Praxis entstanden bei dieser Anwendung bestimmte Konstellationen, die einen Systemschluckauf bewirken – Es reicht also nicht aus, einfach die Positivcases der Spezifikation abzuarbeiten, sondern es müssen unvorhersehbare und noch unbekannte Sachen angedacht werden.

Einen Anwendungsfall für emergente Fehler, die sich auf Komponentenebene grundsätzlich nicht nachstellen lassen, habe ich noch nicht ausreichend kennengelernt.

Verifikation basiert stark auf Erfahrungen. Aufgrund der lessons learned wird die Testbench erweitert um solche Dinge abzubilden. In der Co-Simulation aller Komponenten stößt man natürlich sehr schnell an Performanzgrenzen.

Ein besonders spannender Fall gestaltete sich derart: Ein funktionierendes System fiel unter Ergänzung einer unserer Komponenten aus. Aber in der Analyse konnte das auf eine fremde, nicht regelkonforme Komponente zurückgeführt werden, die erst im Zusammenspiel mit unserer zum Ausfall führte. Aber so etwas dem Kunden zu erklären, ist eine Herausforderung. Im Fokus steht jedoch die Lösung für den Kunden und nicht die Auseinandersetzung mit einem anderen Zulieferer. Deshalb haben wir einige Verifikationsstrategien eingeführt, die nicht nur unsere eigenen Komponenten validieren sondern auch die System-Robustheit gegenüber Standardabweichungen von Fremdkomponenten.

Bei der Robert Bosch GmbH werden in der Entwicklung von Fahrzeugsensorik Virtuelle Prototypen eingesetzt. Welche Rolle spielt diese Methode bei Bosch Sensortec?

Solche SystemC-basierte VPs setzen wir auch ein. Der wesentliche Unterschied zu Automotive besteht in einer weniger stabilen Spezifikation in unserem Fall. Im Automotivebereich herrscht eine viel stärker topdown-geplante Systementwicklung, die einen virtuellen Prototypen besser beherrschbar macht. Bei uns gestaltet es sich recht schwierig, Änderungen in den virtuellen Prototyp zu integrieren obwohl die Produktimplementierung bereits in vollem Gange ist.

Die Vorlaufzeit zwischen Konzeption und Designstart ist kritisch: Uns bleibt viel weniger Zeit zum virtuellen Prototyping.