Ich wollte schon immer ein Integrationsbeispiel des BML050-Microscanners in der DESIGN&ELEKTRONIK lesen. Wie nimmt der Markt das Gerät mittlerweile an?
Wir haben sehr viele Anfragen. Da wir uns noch in der Produkteinführungsphase befinden, konzentrieren wir uns zunächst auf einzelne Kunden, die Resonanz ist sehr gut.
Welche Aufgabe leitete sich im Microscanner für das ASIC-Design ab? Können Sie diese Aufgabe spezifizieren?
Die Aufgabe ist ja, die elektrische Funktionalität zur Verfügung zu stellen. Dazu regelt ein Haupt-ASIC die beiden MEMS-Mikro-Spiegelbewegungen, verarbeitet das Videosignal zur Ansteuerung der Laser und wertet die Positionsdaten für die Interaktivitätsfunktion aus.
Da es sich um eine neue Produktklasse handelt, hat sich die Spezifikation über die Entwicklungszeit stark verändert. Tatsächlich war es ein wesentliches Problem, diese so zu fassen, dass sie über alle abzubildenden Anwendungsfälle realisierbar bleibt. Die Signalvielfalt im System zählt Videosignale ebenso wie Signale, die sich auf Systemebene ergeben, z.B. zur Lageregelung der Spiegel. Diese haben stark unterschiedliche Zeitkonstanten und Auflösungen der Signalwerte. Im Powermanagement sind Dinge, wie die Steuerung des Lasermoduls unter Auswertung der externen Signalvielfalt, umzusetzen.
Welche Verifikations-Herausforderung birgt das Microscanner-Projekt?
Da spielen viele unterschiedliche Domänen auf einem SoC-ASIC zusammen: Eine erhebliche Designfunktionalität mit klassischen Zustandsmaschinen zur Steuerung der Abläufe, eine Image Pipeline für das Videosignal, mehrere eigene Bosch DSP-Cores auf dem Signalverarbeitungspfad, verschiedene A/D und D/A Wandler und Analogschaltungen zur Erfassung der Momentanposition der Spiegel: Die Herausforderung liegt in der Berücksichtigung all dieser unterschiedlichen Signaltypen in einem Mikrosystem, besonders da diese auf unterschiedlichen Zeitskalen variieren. Das verkompliziert die Verifikation enorm.
Welche Verifikationsstrategie adressierte diese Herausforderungen?
Unsere UVM-Methodik muss nicht nur den Digitalpfad, sondern das Mixed-Signal-Design abbilden. Damit ergibt sich das Thema „Handhabung vieler Freiheitsgrade“: Die einzelnen Domänen Analog bzw. Digital werden von unterschiedlichen Teams entwickelt. Wir mussten eine Verifikationsumgebung erstellen, die allen Bedürfnissen Rechnung trägt; frühzeitige Fehlererkennung in der Debuggingphase auf Modulebene aber auch Regressionsfähigkeit der Verifikation auf Systemebene. Hierbei wird den unterschiedlichen Bedürfnissen von Analog-, Digital- und Verifikationsentwicklern Rechnung getragen. Wir tracken die Anzahl der gefundenen und gelösten bugs und issues. Erst wenn die Neuentdeckungsrate klein und stabil wird, sind wir reif fürs Tapeout. Damit hierbei der Tapeouttermin nicht immer wieder verschoben wird, sondern die Neuentdeckungsrate steiler sinkt, haben wir viel Aufwand investiert.
Welche Lehren ziehen Sie aus Ihrem A/M-S-Verifikationsprojekt?
Die Hauptlehre ist: Es gestaltet sich schwierig den GUI-affinen A/M-S-Designern eine scripting-nahe Arbeitsweise aufzuzwingen. Besser ist, sie in ihrer Arbeitsweise möglichst gut in das Gesamtprojekt zu integrieren. Ein Konzept mit dem sich alle wohl fühlen ist besser als das große einheitliche Konzept zu fordern, bei dem alle beteiligten Rollen ihre Arbeitsweise völlig umstellen müssen. Das hat immer sehr gut funktioniert.
Ihre längerfristigen A/M-S-Verifikationsziele?
Die A/M-S-Verifikation soll schneller werden. Momentan ist das der zeitbegrenzende, kritische Pfad in unseren Entwicklungsprojekten. Manche A/M-S-Simulations-Laufzeiten messen zwei und mehr Wochen, Fortschritte im Software- und Methodenbereich sollen das verkürzen.
Sind das algorithmische Probleme?
Das sind eher Probleme, die mit der Modellierungstiefe entstehen und sich mit der Designkomplexität mehren. Bei entsprechend präziser Modellierung entstehen viele Gleichungen mit Schaltelementen. Dann stellt sich die Frage, welche Designmodule gröber modelliert werden können. Dabei treten oft Effekte im physikalischen Silizium auf, die eine sinnvolle Abstraktion erschweren. Als Folge begegnet man im ASIC-Debugging Effekten, welche die Simulation nicht kannte. Diese werden dann in der Simulation nachgebildet. Erst so bildet sich die Erfahrung aus.
Welches ist Ihr Lieblingstrick in der Designerstellung und Verifikation?
Da gebe ich Ihnen lieber eine besondere Empfehlung als einen Trick: Man sollte jedem Ergebnis von Simulator und Tool noch ein Misstrauen entgegenbringen. Es ist gar nicht so selten, dass man an dieser Stelle irgendetwas falsch gemacht hat und das Ergebnis falsch interpretiert. Es muss gar nicht ein Fehler des Tools sondern seiner Anwendung sein.
Die Situation ist ähnlich dem Abschreiben der Dezimalen eines Taschenrechnerergebnis‘: Hier sollte man immer die Frage stellen, welche Genauigkeit man von so einem Wert tatsächlich erwarten kann.
Herr Dr. Symanzik, vielen Dank für das Gespräch und Ihre Zeit!