C. Suehnel: 'Design-for-Verification- ein neues Konzept für IP-basierte SoCs'

<BODY> <H1>www.duv24.net : C. Suehnel: 'Design-for-Verification- ein neues Konzept für IP-basierte SoCs'</H1> <P> <BR> [<A href="/">www.duv24.net</A>] [<A href="../index.html">back</A>] </P> <TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=top> <TABLE WIDTH=100% BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=TOP CLASS=detailBereichRedaktion>Bereich > Redaktion > <B><FONT color="#CC3300">Fachbeiträge</FONT></B></TD> <TD ALIGN=right VALIGN=bottom CLASS=detailDatum>21.01.2002</TD> </TR> </TABLE> </TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailFirma ID=topSpace>Mentor Graphics :</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailTitel>C. Suehnel: 'Design-for-Verification- ein neues Konzept für IP-basierte SoCs'</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top CLASS=detailSubtitel>Effiziente Verifikation in vier Phasen</TD> <TD VALIGN=top> </TD> <TD VALIGN=top> </TD> </TR> <TR> <TD VALIGN=top> <TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0> <TR> <TD VALIGN=top CLASS=detailContent> <TABLE WIDTH=1 BORDER=0 ALIGN=left CELLPADDING=0 CELLSPACING=0> <TR> <TD><IMG width=150 border=0 src="http://www.publish-industry.net/publish-industry/company-resources/publish-industry-master_1770549404.jpg"></TD> </TR> <TR> <TD CLASS=detailBildunterschrift></TD> </TR> </TABLE> Erschienen im <font color=#0000FF>DESIGN & VERIFICATION NR.6 2001 S. 27-30</font><br><br>in der <a href="#toolbox" style="color:red;"><b>'toolbox'</b></a> unter dieser Meldung können Sie, als registrierter USER, zu dem Fachbeitrag mit dem<BR><ul><li>'details-Button' - eine Vollversion mit allen Bildern als pdf-Datei downloaden</li><BR><li>'Email-Button' - per E-Mail direkten Kontakt zum Ansprechpartner aufnehmen</li><BR><li>'discuss it-Button' - den Beitrag mit Anderen in einem Forum diskutieren</li></ul><BR>Sollten Sie noch kein registrierter User sein, können Sie das sofort und kostenfrei in der linken Spalte nachholen!<br><br><BR>Immer komplexere ASIC-Designs treiben herkömmliche Verifikationsverfahren an ihre Grenzen. Was muss ein Verifikationsflow leisten, um diese Hürden zu überwinden, und welche Techniken benutzt man dabei?<BR><BR>Dr. Christoph Suehnel ist als Program Manager im Consulting-Bereich in den Hauptarbeitsgebieten System- Verifikation, Design-for-Testability (DFT) und Intellectual Property (IP)/ Design Reuse tätig bei Mentor Graphics Deutschland.<BR><BR>Immer mehr entwickeln sich ASICs heute zu Systems-on-a- Chip (SoCs). Die Triebkräfte für diese Entwicklung sind zunächst wirtschaftliche Faktoren: der Wunsch nach leistungsfähigeren Produkten, Forderungen nach niedrigeren Entwicklungskosten, das Streben nach kürzerer Time-to-Market und Konzentration auf immer stärker differenzierte Produktdesigns. Um dieses Ziel zu erreichen, werden immer mehr Designelemente wiederverwendet. Kennzeichnend für diese Designs sind hohe Komplexität, oft mit mehreren Millionen Gatteräquivalenten, der Einsatz von IP-Cores, Singleoder Multiprozessor-Architekturen, Embedded- Memories, Schaltungsblöcken mit Analogfunktionen (Mixed-Signal, HF) sowie ein hoher Anteil an in Software realisierten Funktionen. Die Kehrseite dieser Medaille zeigt sich in der Verifikation: Der Arbeitsaufwand für diesen Prozess (Erzeugung von Testbenches und Testcases) nimmt erheblich zu. Die Testcases erfordern lange Ausführungszeiten. Die einzelnen Blöcke des Designs sind häufig in unterschiedlichen HDL-Sprachen beschrieben, was besondere Anforderungen an die Verifikationsumgebung stellt. Durch den hohen Softwareanteil muss sich die Verifikation zunehmend auf die Kommunikation zwischen einzelnen Schaltungsblöcken und auf die Hardware/Software- Co-Verifikation konzentrieren. All diesen Problemen ist eines gemeinsam: Die Simulation als zentrales Verfahren herkömmlicher Verifikationsflows erweist sich als begrenzender Faktor. Zur Erfüllung der oben genannten wirtschaftlichen Kriterien benötigt man ein neues Verifikationskonzept. <BR><BR>Leistungsanforderungen <BR><BR>Bei einem SoC muss der Entwickler in der Verifikation wesentlich komplexere Aufgabenstellungen meistern als früher. Diese sind: Integration von HDL-Beschreibungen (VHDL, Verilog), C-Modellen und bestehenden Hardwareschaltungen (Test- Chips) in die Verifikationssuite Einbindung analoger Schaltungsblöcke (Analog/Mixed-Signal, HF) Beschleunigung des Verifikationsprozesses Umfassende Verifikation der Interaktionen zwischen Soft- und Hardware Navigation in und Verwaltung von hochkomplexen Designs Konzentration auf Simulation und Emulation auf RTL-Ebene; Einschränkung der Regressionssimulation auf Gatterebene Abtrennung der Timing-Analyse von der funktionalen Verifikation Vorrangiges Ziel des neuen Prozesses ist geringerer Zeitaufwand. Bei herkömmlichem Vorgehen lassen sich mit normaler Simulation je nach Komplexität des in den Simulator geladenen Modells Verifikationsgeschwindigkeiten von 1 bis 10 Hz erreichen – völlig unzureichend für moderne SoC-Designs. Mit Emulationsverfahren lässt sich bei Designs mit einer Komplexität von über einer Million Gatteräquivalenten eine Ausführungsgeschwindigkeit von etwa 100 bis 500 kHz erreichen. <BR><BR>Der neue Verifikationsprozess<BR><BR>Der neue Designflow besteht aus vier Phasen. Am Ende einer jeden Phase steht eine Sign-Off- Prozedur für die entsprechende Darstellung des Designs (Abb. 1). Beim RTL-Design ist die Kreativität des Entwicklers gefordert. Hier entsteht die ‚goldene Referenz‘ des Designs. Diese Referenz ist der Maßstab für alle anderen Verifikationsaufgaben für die nachfolgenden Phasen der Entwicklungsarbeit. In der Design-for-Verification-Strategie konzentriert sich die funktionale Validierung auf die beiden RTL-Entwicklungsschritte RTLBlock- und Top-Level-Design. Der RTL-Entwicklungsprozess ist eine Kombination aus Bottom-up- und Top-down-Design. Dabei werden die Funktionsblöcke eines Chips entwickelt und verifiziert. Parallel dazu erzeugt man die oberste Ebene anhand verfügbarer Module wie z.B. IP-Cores. Für Blöcke, die zu dieser Zeit nicht verfügbar sind, legt man leere Dummy- Module an. Die Chip-Verifikationsumgebung muss bereits in frühen Stufen der Entwicklung zur Verfügung stehen. Die Verifikation befasst sich mit den Interaktionen zwischen den Funktionsblöcken. In beiden Entwicklungsphasen – dem RTL-Block- und dem RTL-Top-Level-Design – nutzt die Verifikation Patterns oder Testbenches. Beim Auftreten von Fehlern modifiziert man die RTL-Beschreibung und verifiziert sie erneut. Als Ergebnis dieser RTL-Entwicklungsschritte entsteht das funktionale Referenzmodell (‚goldenes‘ RTL-Modell). In der Phase des Gate-Level-Designs wird das RTL-Modell synthetisiert. Dabei entsteht eine Gate-Level-Netzliste, die sich nach einer Verifikation von Funktion und Timing genauso verhält wie das goldene RTL-Modell. Herkömmliche Flows nutzen in dieser Entwicklungsphase die Gate-Level-Simulation zur Verifikation von Funktion und Timing. Im Gegensatz dazu trennt man in der Design-for-Verification- Strategie funktionale Verifikation und Timing-Verifikation voneinander. Hier treten formale Äquivalenz-Überprüfung, statische Timing- Analyse und eine Simulation mit einem minimalen Satz an Verifikationsvektoren an die Stelle der herkömmlichen Gate-Level-Simulation. Um zu verhindern, dass Logikfehler Timing- Probleme verursachen, ist eine Timing-Analyse im Gate-Level-Design zwingend erforderlich. In der Post-Layout-Phase des Gate-Level-Designs wurde Taktlogik (Treiber) in die Schaltung eingefügt und Platzierung sowie Routing wurden durchgeführt. Obwohl diese Prozesse keine Auswirkung auf den Funktionsumfang haben sollten, verändern sie doch die Netzliste und können unbeabsichtigt Verfälschungen der Funktion verursachen. Um diese Netzlisten-Veränderungen aufzufinden, nutzt der Design- for-Verification-Flow die formale Äquivalenzüberprüfung und eine umfassende statische Timinganalyse an Stelle der Regressionssimulation früherer Flows. Der Design-for-Verifikation- Flow arbeitet mit formaler Verifikation, Emulation und Hardware/Software-Co-Verifikation, um auch bei komplexen Designs mit hohem Software- Anteil kurze Entwicklungszyklen zu ermöglichen. Was leisten diese Techniken und welche Vorteile bieten sie gegenüber den bisherigen Verfahren?<BR><BR>Formale Verifikation<BR><BR>Je komplexer Designs werden, umso effizienter ist die formale Verifikation: Umfassende Simulationen sind nicht mehr nach jeder Revision eines Designs möglich. Die formale Verifikation nutzt zwei verschiedene Techniken: formale Modellüberprüfung (RTL gegen RTL) und formale Äquivalenzüberprüfung (RTL gegen Gatter, Gatter gegen andere Gatter). Bei der formalen Modellüberprüfung kann der Anwender nachweisen, dass gewisse Aspekte seines Designs immer wie beabsichtigt funktionieren. Dazu spezifiziert man Eigenschaften des Designs wie z.B. ‚die Read- und Write-Enable- Signale dürfen niemals gleichzeitig True sein‘. Das Modellüberprüfungswerkzeug ermittelt dann, ob diese Eigenschaften unter allen funktionalen Umständen zutreffen. Im Gegensatz dazu muss man für die Simulation zahlreiche Stimulus-Patterns (Vektoren) erzeugen, bevor man damit diese Eigenschaften überprüfen kann. Die formale Modellüberprüfung liefert einen automatischen und vollständigen Nachweis, dass sich die Logik unter allen denkbaren Eingangsbedingungen korrekt verhält – ohne dass man dazu einen einzigen Vektor erzeugen müsste. Modellüberprüfung löst drei Probleme. Erstens: Das Werkzeug untersucht sämtliche möglichen Fälle und entdeckt Situationen, die von den Vektoren nicht abgedeckt wurden. Zweitens: Eigenschafts-Überprüfungen lassen sich auch an einem unfertigen Design durchführen; man kann sie auch an Unterschaltungen oder einzelnen Modulen ausführen. Im Gegensatz dazu benötigen die meisten vektorgestützten Testbenches eine komplett vorliegende Logikschaltung. Und drittens: Viele EigenschaftsÜberprüfungen lassen sich wesentlich schneller als jede Simulation ausführen, da sie keine separate Testbench benötigen. Äquivalenzüberprüfungswerkzeuge sind das kritische Bindeglied zwischen dem herkömmlichen Entwicklungsprozess und der Einführung formaler Methoden durch den ASIC-Entwickler. Sie lassen sich besonders einfach bedienen, benötigen sehr wenig Benutzereingaben und arbeiten mit den normalen Hardware-Beschreibungssprachen. Ziel der Äquivalenzüberprüfung ist es, den Bedarf für Simulation auf Gate-Ebene zu verringern oder komplett zu erübrigen. Die Äquivalenzüberprüfung muss daher eine Gate-Level-Simulation überall dort ersetzen können, wo eine funktionale Überprüfung auf Gate-Ebene erfolgt. Dazu gehören auch Post-Syntheseüberprüfungen zum Nachweis, dass die Gatter den RTL-Code, Scan- oder Clock-Insertion und Re-Bufferring korrekt implementieren. Auf Gatterebene kann die formale Äquivalenzüberprüfung des Designs gegenüber der RTL-Referenz einen Gate-Level-Regressionstest ersetzen. Spätere Revisionen lassen sich komplett verifizieren, ohne die Integrität des Designs zu beeinträchtigen. Abb. 1: Der Design-for-Verification-Flow; die einzelnen Design-Phasen und die dabei eingesetzten Verifikationstechniken. Die farbig hinterlegten Felder entsprechen den neuen Verifikationsmethoden. <BR><BR>Hardware-Emulation<BR><BR>Hardware-Emulation ist ein Verfahren zur Beschleunigung der Verifikationsläufe in Hardware, die man für klar definierte Abstraktionsebenen wie RTL oder Gate-Level einsetzen kann. Mit Hilfe der Emulation können Entwickler mehrere Design-Iterationen pro Tag realisieren. Wichtige Vorteile der Hardware-Emulation sind: schnelle und automatische Compilierung des Designs, Beschleunigung der Verifikation auf Registertransfer- oder Gate-Ebene mit kompletten Debugging-Funktionen, Co-Simulation mit synthetisierbarem RTL-Code oder C-Testbenches/ C-Modellen, Beschleunigung der Verifikation von gesamten Verifikationssuiten für gründlichen Test, In-Circuit-Verifikation für virtuelles Silizium und die Integration bestehender Hardware wie z.B. von Prozessoren oder einer Hardware-Verifikationsumgebung in die Verifikationssuite.<BR><BR>Hardware/Software-Co-Verifikation<BR><BR>Wenn Hard- oder Software-Fehler unerkannt bleiben, bis die Software auf einem physikalischen Prototypen läuft, dann verursacht dies aus zwei Gründen hohe Kosten: Solche Fehler verlängern die Entwicklungszeit, so dass das Produkt sein Zeitfenster am Markt verfehlen kann; technische Änderungen am Hardware- Prototypen sind zudem außerordentlich kostspielig. Mit Hardware/Software-Co-Verifikation lassen sich solche Probleme wirksam bekämpfen. Vor der Herstellung eines SoCs und dem Aufbau eines Hardware-Prototypen kann man mit dieser Technik die Hard- und Softwarekomponenten integrieren und testen. Implementationsfehler mit Auswirkungen auf die Hardware/ Software-Schnittstelle lassen sich nur schwer erkennen, wenn sich die Verifikation ausschließlich auf die Hardware oder die Software und nicht auf beide als Einheit konzentriert. Die Hardware/Software-Co-Verifikation erledigt zwei unterschiedliche Aufgaben. Die erste ist die Verifikation der Software auf einem sinnvollen Hardware-Modell; dabei will man erkennen, ob die Software korrekt arbeitet. Die zweite Aufgabe ist die Verifikation der Hardware (RTL oder Gate-Level) anhand einer Software; hierbei will man ermitteln, ob die Hardware- Abbildung mit einer gegebenen Software korrekt zusammenarbeitet. Bei ersterer Aufgabe nutzt man meist ein CModell der Hardware mit Debugger-Funktionen; die Ausführung dieses Tasks läuft ähnlich ab wie die Software-Verifikation (Nutzung von Breakpoints usw.). Weil das C-Modell der Hardware nicht für die Erzeugung einer Gate- Level-Beschreibung verwendet wird, kann man auf diesem Wege nur die Software verifizieren. Für die zweite Aufgabe nimmt man an, dass die Software korrekt funktioniert. Nun geht es in der Verifikation darum, ob die Software auf der RTL/Gate-Level-Beschreibung korrekt ausgeführt wird.<BR><BR>Simulation<BR><BR>Simulation ist die beste herkömmliche Methode für die Überprüfung der Funktion eines Designs auf RTL- oder höherer Ebene. Bei komplexen Systemen ist die Verifikation kostspielig; sie erfordert lange Ausführungszeiten und die Herstellung von Testvektoren ist zeitraubend. Als Ergebnis des Verifikationsprozesses entsteht ein der Spezifikation entsprechendes Referenzmodell des Systems. Es gibt keine Möglichkeit, den Arbeitsaufwand für diese Art der Verifikation zu verringern. Nach Änderungen des Modells muss der gesamte Verifikationsablauf erneut ausgeführt werden, was mehrere Tage dauern kann. Wenn also Fehler erst spät im Entwicklungszyklus gefunden werden, können sie zu empfindlichen Verzögerungen führen.<BR><BR>Timing-Analyse<BR><BR>Eine statische Timing-Analyse ist für eine Gate- Level-Verifikation zwingend erforderlich. Dabei muss man sowohl Pre- wie Post-Layout- Netzlisten untersuchen. Die Analyse überprüft das statische Timing, indem es die Laufzeiten der Pfade zwischen getakteten Elementen in einer Schaltung aufaddiert. Anschließend werden die Summen mit den spezifizierten Timing- Constraints für jeden Pfad der Schaltung verglichen und alle daraus folgenden Timing-Verletzungen in einem Bericht zusammengestellt. Die statische Timing-Analyse ist am effektivsten, wenn man sie an funktionell korrekten Netzlisten durchführt. Herkömmliche Methoden verbinden eine funktionale Verifikation eines Gate-Level-Designs mit der Timing-Analyse. Dieses Vorgehen ist zeitraubend und auf große Designs nicht anwendbar. In einer modernen Design-for-Verification-Strategie überprüft man nur solche Netzlisten auf die Einhaltung der Timing-Anforderungen, deren Äquivalenz zur RTL-Referenz bereits nachgewiesen ist. Die dynamische Timing-Analyse ist eine Timing- Simulation, sie überprüft das Timing einer Schaltung anhand von Testvektoren, die zur Erkennung von Timingfehlern ausgelegt wurden. Dieses Vorgehen ist eine Erweiterung der Simulation; es gewährleistet, dass das Timing einer Schaltung in ihrem funktionellen Kontext überprüft wird. Mit dieser Testart werden Timingfehler ermittelt, die in der Schaltung funktionell bestehen, allerdings können Fehler, die sich auf nicht angesprochenen Pfaden befinden, nicht ermittelt werden. Die dynamische Timing-Analyse ist ein optionaler Entwicklungsschritt, den man nur zur Untersuchung von Timingfehlern anwenden sollte, die auf logischen Operationen wie Race-Conditions beruhen.<BR><BR>Code- und Funktionsabdeckung<BR><BR>Die Codeabdeckung ist eine Methode zur Bewertung der Qualität eines Verifikationsvektorsatzes. Ein kompletter Verifikationsdatensatz würde alle denkbaren Kombinationen von Eingangszuständen für das zu überprüfende Modell umfassen. Die Erzeugung eines solchen Satzes von Verifikationsvektoren ist jedoch kaum möglich, da die Anzahl möglicher Kombinationen meist sehr groß ist. Daher stellt man eine repräsentative Auswahl dieser Eingangszustände zusammen. Die Codeabdeckung-Methode ermittelt, ob diese Auswahl gewisse Kriterien erfüllt, wie z.B., ob jedes Statement im auszuführenden VHDL-Code angesprochen wird. Anders gesagt, die Qualität der Testbench wird gemessen. Mit Codeabdeckungstechniken kann man die Vollständigkeit der Verifikation eines jeden Bauteils parallel zu dessen Entwicklung überprüfen. Solche Tests sollte man regelmäßig während des Entwicklungsprozesses durchführen, um die Qualität des Designs zu überprüfen. Codeabdeckung (Code Coverage) beruht auf Überprüfung der Ausführung von HDL-Code- Statements und liefert daher quantitative Angaben über die Verifikationsqualität, jedoch keine Aussage über die Vollständigkeit und Korrektheit der Funktion. Die funktionale Abdeckungsanalyse (Functional Coverage) ist eine Bewertung, die auf der spezifikationsgestützten Abdeckungsanalyse beruht. Der Verifikationsingenieur muss den Funktionsumfang definieren, der in der Verifikation überprüft wird. Dabei kann er verschiedene Prioritätsebenen des Funktionsumfangs definieren. Dieser Bewertungsmaßstab liefert eine große Übersicht der Verifikationsqualität eines Designs. Er überwindet die Nachteile der Codeabdeckungsbewertung und ermöglicht eine Verfolgung des funktionellen Verifikationsfortschrittes.<BR><BR>Zusammenfassung<BR><BR>Das hier beschriebene Verifikationskonzept samt zugehöriger Verifikationsumgebung wurde an einem Design mit 2,5 Millionen Gatteräquivalenten zuzüglich eines Hard-IP-Cores entwickelt und erfolgreich ausgeführt. Das SoC beinhaltete mehrere Prozessoren. Für die Testbench wurde eine prozessorbasierte Architektur ausgewählt. Der Aufwand zur Erzeugung der Testbench ließ sich dabei drastisch verringern. Außerdem eignet sich das benutzte Testbench-Konzept zur Wiederverwendung. Die Testcases wurden in C-Code implementiert, was eine Beschleunigung der Erzeugung dieser Testfälle ermöglichte, da sich ein Verhalten schneller in C als in VHDL oder Verilog implementieren lässt. Beim Debugging der Testcases war keine erneute Compilierung der Testbench erforderlich. Aufgrund der hohen Verifikationsgeschwindigkeit ließen sich alle Testcases in weniger als zwei Wochen ausführen. Darüber hinaus wurde das Design in einer bestehenden Systemhardware-Umgebung (In- Circuit-Simulation) überprüft. In dieser Konfiguration ließen sich ca. 20 Minuten Echtzeitabläufe ausführen.<BR><BR>more @ click DV61251<a name="toolbox"></a ><BR></TD> </TR> <TR> <TD CLASS=detailQuelle> </TD> </TR> </TABLE> </TD> <TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=1 HEIGHT=1 ALT=""></TD> <TD WIDTH=174 VALIGN=top></TD> </TR> <TR> <TD VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=393 HEIGHT=1 ALT=""></TD> <TD WIDTH=28 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=28 HEIGHT=1 ALT=""></TD> <TD WIDTH=174 VALIGN=top><IMG NAME="" SRC=/pi/spacer.gif WIDTH=174 HEIGHT=1 ALT=""></TD> </TR> </TABLE> <P><I>Diese Seite wurde am 25.09.2004, 13:12 Uhr aktualisiert</I></P> </BODY>