Wat is LVS?

In de fysieke ASIC-implementatie moet de lay-out, zodra deze is gegenereerd, voldoen aan alle ontwerpregels voor een succesvolle productie en moet deze overeenkomen met het schema van het vereiste ontwerp. Om dit bij fysieke verificatie te waarborgen, wordt Design Rule Check (DRC) uitgevoerd om te controleren of de lay-out voldoet aan de regels voor foutloze fabricage of niet. Deze DRC-controles zorgen voor een goed productierendement en voorkomen fouten tijdens de productie, maar garanderen niet de correctheid van de lay-out. Er moet voor worden gezorgd dat de fysieke uitvoering van het ontwerp gelijk is aan de schema's van het ontwerp. Hiervoor wordt het elektrische circuit van layout netlist vergeleken met de schematische netlist, die bekend staat als Layout versus Schematic (LVS).

Hier worden IC Validator en IC Compiler-II (SYNOPSYS) tools gebruikt voor LVS-runs en PnR.

Zoals weergegeven in de bovenstaande afbeelding, is LVS een vergelijking tussen de lay-out, die wordt weergegeven door GDS en het schema dat wordt gegenereerd door de tool met behulp van verilog netlist.

Invoerbestanden voor LVS in ICV-tool staan ​​hieronder:

• GDS (layout-streambestand): het wordt gebruikt door de LVS-tool om een ​​lay-outnetlijst te genereren door extractie, die wordt gebruikt voor LVS-vergelijking.
• Schematische netlijst: het wordt gebruikt als een bronnetlijst voor LVS-vergelijking.
• Rule deck-bestand: Rule deck-bestand bestaat uit de vereiste instructies en bestanden om de tool te begeleiden voor het uitvoeren van LVS. Dit regeldeckbestand bevat ook een laagdefinitie, die handig is voor extractie.
• Equivalentiebestand: het wordt gebruikt door de tool voor ICV LVS-vergelijking en het bestaat uit celparen, bestaande uit een uit de lay-outnetlijst en een andere uit de schematische netlijst.

LVS-stroom

LVS-stroom bestaat voornamelijk uit extractie en vergelijking van lay-outnetlijst en schematische netlijst. LVS-stroom wordt weergegeven in figuur-2. ICV heeft een nettran-hulpprogramma voor het vertalen van invoerverilog-netlist naar ICV-schematische netlist, wat verder handig is voor vergelijkingsdoeleinden. Alle apparaten en verbindingen daartussen worden geëxtraheerd uit GDS in de lay-outextractiestap. De tool genereert ook een equivalentiepuntbestand na de extractie voor vergelijking van lay-out en schema. Dit equivalentiebestand is handig ter vergelijking. In de vergelijkingsstap wordt de geëxtraheerde netlijst vergeleken met de schematische netlijst en de tool geeft een schoon resultaat, als beide netlijsten volledig overeenkomen en zo niet, dan genereert de tool foutrapporten. In de vergelijkingsstap doet tool de vergelijking op de volgende manier: Tool vergelijkt het aantal apparaten in schema en in lay-out, het aantal netten in schema en in lay-out, soorten apparaten in schema en in lay-out, en genereert vervolgens de resultaatrapporten . Foutrapport bevat een lijst met onjuiste apparaten, onjuiste netten, wat handig is om het LVS-probleem te debuggen.

Veelvoorkomende LVS-problemen en hun foutopsporing

• Openen
• Shorts
• Ontbrekende componenten
• Wereldwijde netverbinding ontbreekt

Openen: Vormen van de netten met dezelfde lay-outtekst erop kruisen elkaar niet of raken elkaar niet waardoor er een opening in het ontwerp ontstaat. Openingen in het ontwerp zijn verantwoordelijk voor zwevende verbindingen in het ontwerp. Deze zwevende verbinding zal grote defecten veroorzaken in spaanders (ASIC/FPGA). Het is dus erg belangrijk om openingen in het ontwerp te vinden. Het uitvoeren van het open zoekprogramma van de PnR-tool voordat LVS wordt uitgevoerd, is nuttig in de vroege ontwerpfase.

Het onderstaande voorbeeld toont de detectie van de opening in het ontwerp door de LVS-tool. Rapporten die door de tool worden gegenereerd, beschrijven de openheid in het ontwerp, zoals weergegeven in het volgende fragment van het toolrapport.

Foutoverzicht toont het overzicht van gedetecteerde fouten met hun tellingen. Voor open extraheert extractor het open net als twee verschillende netten, dus het aantal netten in de lay-out is groter dan het aantal netten in het schema, zoals weergegeven in het rapport. Het rapport toont het aantal netten in de lay-out met bijbehorend schema. Het schematische net BUF_net_152645, dat wordt weergegeven door twee netten N_11965140 en N_11989743 in lay-out (vanwege de open), zoals vermeld in het rapport.

Dit type probleem kan worden opgelost door lay-outvormen van een enkel net dat open wordt gelaten te verbinden.

Bermuda's: Als lagen in lay-out met verschillende lay-outteksten elkaar overlappen of kruisen, resulteert dit in een kort ontwerp. Aanwezigheid van de kortsluiting in het ontwerp zal chipfalen veroorzaken. Het is belangrijk om shorts te vinden die aanwezig zijn in het ontwerp door PnR shorts Finding Utility uit te voeren of door LVS uit te voeren. Het volgende voorbeeld laat zien hoe de kortsluiting door de tool wordt gerapporteerd na het uitvoeren van de LVS.

Wanneer de kortsluiting in het ontwerp voorkomt, zal de extractor kortgesloten netten als een enkel net extraheren, dus er is slechts één lay-out overeenkomstig net voor twee netten in het schema, zoals vermeld in het rapport. N738 en BUF_net_189972 zijn kortgesloten netten.

Short kan worden opgelost door het net op de juiste manier om te leiden.

Binnenbroek met macro'sIn een fysiek ontwerp, door de complexiteit van het ontwerp of door verkeerde instellingen, kan het voorkomen dat de PnR-tool netten zo routeert dat er kortsluiting ontstaat met de interne geometrieën van de macro's. Het kan ook gebeuren als routeringsblokkade ontbreekt in LEF van de macro. Soms wordt tijdens het uitvoeren van handmatige aangepaste routering een kortsluiting gemaakt tussen de aangepaste route en de interne routering van de macro. Deze short is niet gemakkelijk te melden in de PnR-toolomgeving. Wanneer we de GDS van de harde macro samenvoegen met het blok op het hoogste niveau, is de short zichtbaar in de GDS. Deze short kan worden gedebugd met behulp van het VUE-hulpprogramma van ICV. Hieronder ziet u een fragment dat laat zien hoe een signaalnet onjuist over de harde macro wordt geleid. De laag wordt geblokkeerd over de macro, omdat interne geometrieën van de harde macro aanwezig zijn. Dit net veroorzaakt een kortsluiting met de interne geometrieën van de macro.

Hieronder is het fragment uit de samengevoegde GDS, dat duidelijk de korte laat zien.

Het gegenereerde rapport is vergelijkbaar met het korte rapport. Het fragment voor dit voorbeeld is als volgt.

PG kort met signaalnet: Wanneer er een PG-kortsluiting in het ontwerp zit, is het erg moeilijk om deze te identificeren. PG-kortsluiting kan een kortsluiting zijn tussen een stroomnet en een grondnet of het kan een kortsluiting zijn tussen een stroom-/aardnet en een signaalnet. Wanneer een PG-net kortsluiting maakt met een vrij lang signaalnet en aangezien het PG-net op zoveel apparaten is aangesloten, is het erg moeilijk om een ​​korte locatie te bepalen. Om dit probleem te debuggen, is er een manier in ICV om een ​​tekst toe te voegen aan het signaalnet dat kortsluit met PG net.

Hieronder volgt een voorbeeld van het toevoegen van een tekst via het signaalnet. Deze netnaam kan eenvoudig worden afgeleid uit het LVS-foutrapport. Neem een ​​willekeurige locatie waar het kortsluitsignaalnet bestaat (neem een ​​willekeurige laag) en plaats er een tekst van een tagnaam over, op een locatie die wordt gedefinieerd door de oorsprongswaarde in de onderstaande opdracht.

create_shape -shape_type tekst -laag -oorsprong <{llx lly}> -hoogte 1 -oriëntatie R0 -rechtvaardiging LB -tekst “ ”

Hieronder ziet u een voorbeeld van hoe u PG-short kunt debuggen met elk signaalnet met behulp van teksttoevoeging.

Vanwege onjuiste metalen vulling en handmatige routeringswijzigingen is er een kortsluiting ontstaan ​​tussen het VSS-net en een van de signaalnetten, zoals weergegeven in de onderstaande afbeelding.

Het was erg moeilijk om de korte locatie te achterhalen, omdat het signaalnet zelf erg lang was. Op het signaalnet werd een tekstlaag gemaakt met behulp van de hierboven getoonde opdracht en werd LVS opnieuw uitgevoerd. Nu was de kortsluiting tussen VSS en tekst gemakkelijk zichtbaar in de LVS-kortzoeker, en de bovenstaande momentopname toont de fout gemarkeerd met behulp van de VUE-database van ICV.

Ontbrekende componenten

Als een deel van het Spice-bestand of GDS-bestand ontbreekt tijdens het samenvoegen van de database, wordt de fout met ontbrekende componenten weergegeven. Bijvoorbeeld: als u cel ABC gebruikt in het ontwerp, maar niet gedefinieerd in de GDS-lijst of kruidenlijst die moet worden gebruikt voor de LVS-stroom, kan dit een fout met ontbrekende componenten veroorzaken. Ofwel moet de lijst worden aangepast of moet de ABC-cel worden uitgesloten van de LVS-vergelijking (dit hangt af van de functionaliteit van de cel, alleen fysieke cellen mogen in de vergelijking worden uitgesloten).

Wereldwijde netverbinding ontbreekt

Als de PG-pinnen van de cellen niet zijn aangesloten op een stroom-/aardnet met behulp van connect_pg_net-opdrachten, veroorzaakt dit apparaatmismatches en LVS-fouten voor het grootste deel van het ontwerp. Zelfs als de standaard PG-pinnaam van de cel bijvoorbeeld VDD is, verbindt de tool deze niet met VDD zonder ontwerp. We moeten het onderstaande commando gebruiken om dergelijke pinnen te verbinden.

connect_pg_net -net VDD [get_pins -hiërarchisch */VDD]

Conclusie

LVS is een nuttige techniek om de juistheid van de fysieke implementatie van de netlijst te verifiëren. open, kortsluitingen, ontbrekende componenten en ontbrekende wereldwijde netverbinding zijn potentiële problemen die de functionaliteit van het ontwerp kunnen beïnvloeden en die mogelijk niet in een vroege implementatiefase worden gedetecteerd, dus LVS is handig om deze problemen in het ontwerp te melden. Zodra deze problemen zijn gemeld door de fysieke verificatietool, kan deze worden opgelost met verschillende technieken, zoals besproken in dit artikel.

Chirag Rajput, Nilay Mehta & Chirag Maniya

Met dank aan: Ontwerp en hergebruik. Com

Bron: https://www.einfochips.com/blog/layout-versus-schematic-lvs-flow-and-their-debug-in-asic-physical-verification/