Detta dokument beskriver kort en metod för programmering PCB design rule checker (DRC) system. När PCB -designen har erhållits med hjälp av kretsdiagramgenereringsverktyget kan DRC köras för att hitta eventuella fel som bryter mot PCB -designreglerna. Detta måste göras innan efterföljande bearbetning påbörjas, och utvecklaren av kretsgeneratorn måste tillhandahålla DRC -verktyg som de flesta PCB -konstruktörer enkelt kan behärska.

Det finns många fördelar med att skriva din egen PCB -designregelkontroll. Även om PCB -designkontrollen inte är så enkel, är den inte ohanterlig, eftersom alla PCB -designer som är bekanta med befintliga programmerings- eller skriptspråk kan göra det, och fördelarna är ovärderliga.

Marknadsförda verktyg för allmänna ändamål är dock ofta inte tillräckligt flexibla för att möta specifika PCB-designbehov. Som ett resultat måste nya funktionskrav rapporteras av kunder till DRC -verktygsutvecklare, vilket ofta tar pengar och tid, särskilt om kraven ständigt uppdateras. Lyckligtvis kan de flesta verktygsutvecklare ge sina kunder ett enkelt sätt att skriva sin egen DRC för att möta deras specifika behov. Detta kraftfulla verktyg är dock inte allmänt känt eller använt. Denna artikel ger en praktisk guide för att få ut det mesta av DRC -verktyg.

Eftersom DRC måste gå igenom kretskortet för att utforma hela kretsschemat, inklusive varje symbol, varje stift, varje nätverk, varje attribut och skapa ett obegränsat antal “tillbehör” -filer om det behövs. Som beskrivs i avsnitt 4.0 kan DRC flagga alla mindre avvikelser från PCB -designregler. Till exempel kan en av de bifogade filerna innehålla alla avkopplingskondensatorer som används i PCB -designen. Om kapacitansnumret är lägre eller högre än väntat kommer röda märken att placeras där DV/DT -problem kan uppstå. Dessa tilläggsfiler kan vara nödvändiga, men de är inte nödvändigtvis skapade av något kommersiellt DRC -verktyg.

Hur man designar PCB -regelkontrollen DRC

En annan fördel med DRC är att den enkelt kan uppdateras för att rymma nya PCB -designfunktioner, till exempel de som kan påverka PCB -designregler. Dessutom, när du får tillräcklig erfarenhet inom området finns det många andra funktioner som du kan implementera.

Om du till exempel kan skriva din egen DRC kan du skriva ditt eget BOM -verktyg för att bättre tillgodose specifika användares behov, till exempel hur man får “extra hårdvara” (t.ex. uttag, radiatorer eller skruvmejslar) för enheter som inte är själva en del av kretsdiagrammet. Eller så kan PCB -designern skriva sin egen Verilog -nätlistanalysator med tillräcklig flexibilitet i PCB -designmiljön, till exempel hur man skaffar Verilog -modeller eller tidsfiler som är lämpliga för en viss enhet. Eftersom DRC korsar hela kretskortets designkretsdiagram är det faktiskt möjligt att samla all giltig information för att mata ut den simulering och/eller BOM som krävs för PCB -design Verilogs nätlistanalys.

Det skulle vara en ansträngning att diskutera dessa ämnen utan att ge någon programkod, så vi använder ett verktyg för hämtning av kretsdiagram som ett exempel. Denna artikel använder företaget Mentor Graphics för att utveckla ViewDraw-verktyget som är kopplat till PADS-Designer: s produktserie. Dessutom använde vi ViewBase -verktyget, som är ett förenklat C -rutinbibliotek som kan kallas för att komma åt ViewDraw -databasen. Med ViewBase -verktyget kan PCB -designers enkelt skriva kompletta och effektiva DRC -verktyg för ViewDraw i C/C. Det är viktigt att notera att de grundläggande principerna som diskuteras här gäller alla andra PCB -schematiska verktyg.

Inmatningsfilen

Förutom kretsdiagramdatabasen behöver DRC också inmatningsfiler som kan beskriva specifika situationer, till exempel namnet på ett legitimt nätverk som automatiskt ansluts till kraftplanet. Till exempel, om POWER-nätverket kallas POWER, ansluts POWER-planet automatiskt till POWER-planet med hjälp av en back-end-paketanordning (beroende på ViewDrawpcbfwd). Följande är en lista över inmatningsfiler som måste placeras på en fast global plats så att DRC automatiskt kan hitta och läsa och sedan spara denna information internt till DRC vid körning.

Vissa symboler måste ha externa nätsladdstift eftersom de inte är anslutna till det vanliga nätkabelskiktet. Exempelvis är ECL -enhetens VCC -stift antingen anslutna till VCC eller GROUND; Dess VEE -stift kan anslutas till GROUND eller -5.0V -planet. Dessutom kan nätkabeln också anslutas till filtret innan du når nätsladden.

En strömkabelstift är normalt inte ansluten till en enhetssymbol. Istället beskriver en egenskap hos symbolen (kallas SIGNAL här) vilken stift som är en ström- eller jordstift och beskriver nätverksnamnet som stiftet ska anslutas till.

SIGNAL = VCC: 10

SIGNAL = JORD: 20

DRC kan läsa den här egenskapen och se till att nätverksnamnet lagras i filen legal_pwr_net_name. Om nätverksnamnet inte ingår i legal_pwr_net_name kommer strömknappen inte att anslutas till strömplanet, vilket är ett allvarligt problem.

Fil legal_pwr_net_name Valfritt. Denna fil innehåller alla lagliga nätverksnamn för POWER -signaler, till exempel VCC, V3_3P och VDD. I PCB-layout/routingsverktyg måste namn vara skiftlägeskänsliga. I allmänhet är VCC inte detsamma som VCC eller VCC. VCC kan vara 5.0V strömförsörjning och V3_3P kan vara 3.3V strömförsörjning.

Filen legal_pwr_net_name är valfri, eftersom konfigurationsfilen för backend -inkapslingsenheten vanligtvis måste innehålla en uppsättning giltiga nätverkskabelnamn. Om CadencePCB används för att designa Systems Allegro -kopplingsverktyg är PCBFWD -filnamnet Allegro.cfg och har följande inmatningsparametrar:

JORD: VSS CGND GND JORD

Strömförsörjning: VCC VDD VEE V3_3P V2_5P 5V 12V

Om DRC kunde läsa allegro.cfg -filen direkt istället för legal_pwr_net_name, skulle det få bättre resultat (dvs. mindre chans att införa fel).