Examensarbete 10 poäng C-nivå STUDIE AV VHDL-AMS Reg.kod: Oru-Te-EXE084-ELI03/04 Emil Berglund och Johan Nygren Elektronikingenjörsprogrammet 120 p Örebro vårterminen 2004 Examinator: Sune Bergelin STUDY OF VHDL-AMS Örebro universitet Örebro University Institutionen för teknik Department of technology 701 82 Örebro SE-701 82 Örebro, Sweden
Sammanfattning Det här examensarbetet handlar om programspråket VHDL-AMS som är en utbyggnad av VHDL och hanterar både analoga och digitala signaler. Arbetet har ägt rum vid Örebro Universitet och syftet har varit att skriva en rapport som ger läsaren en övergripande bild av språket. Rapporten är också tänkt att kunna användas av tekniska institutionen på Örebro Universitet så att de lättare ska kunna besluta om VHDL-AMS är något som bör ingå i någon kurs. Det första vi gjorde var att göra en grundlig undersökning kring varför VHDL-AMS har utvecklats, vilka programspråk som är närmast konkurerar om samma användningsområde och en liten fördjupning runt VHDL eftersom VHDL-AMS bygger på det språket. Nästa steg var att ta reda på all intressant information rörande VHDL-AMS och bearbeta den. En viktig del i arbetet var att vi skulle testa hur bra de analoga simuleringarna med VHDL-AMS blev i förhållande till simuleringar i programmet MultiSim som använder programspråket SPICE. Det verktyg som vi ansåg lämpligast för uppgiften var SystemVision från Mentor Graphics, som är ett program för konstruktion och simulation av mixade system (blandade analoga och digitala signaler). Abstract This thesis deals with the programming language VHDL-AMS, which is an extension of VHDL and can handle both analogue and digital signals. The piece of work has taken place at University of Örebro and the purpose has been to write a report which give the reader a good understanding of the language. The report is also intended to be used by the technical institution at University of Örebro when they are going to decide if VHDL-AMS is something that should be included in any of their courses. First of all we made a careful investigation about why VHDL-AMS has been developed, which other programming languages that are the biggest concurrents and a deeper investigation about VHDL because VHDL-AMS is an extension of it. Next step was to find as much interesting information concerning VHDL-AMS as possible and handle it. An important part of the work was that we should test how correct the analogue simulation with VHDL-AMS became, compared to simulations tested with the program MultiSim who use SPICE as programming language. The tool that we thought most suitable was SystemVision from Mentor Graphics, which is a program developed for construction and simulation of mixed system (mixed analogue and digital signals). 1
SAMMANFATTNING...1 ABSTRACT...1 INLEDNING...4 UPPDRAGSBESKRIVNING...4 KRAV...5 SYFTE...5 BAKGRUND...6 HISTORIK...6 Programmeringsspråk...7 Digitala konstruktionsspråk...7 Analoga Programmeringsspråk...8 Verktyg för blandade system...9 EN DJUPARE GENOMGÅNG AV VHDL...10 Fördelar med VHDL...10 Nackdelar med VHDL...10 Analog simulering i VHDL...11 Egen utvidgning av VHDL...11 Några viktiga punkter att tänka på vid egenutvidgning av VHDL... 11 EN FÖRDJUPNING AV VHDL-AMS...12 FUNDAMENTALA SPRÅKKRAV...12 FÖRETAGEN SOM HAR UTVECKLAT VERKTYG FÖR KONSTRUKTION OCH SIMULERING I VHDL-AMS...13 Ansoft...13 Simplorer 6.0... 13 Cadence...13 Virtuoso ams designer simulator... 13 Mentor Graphics...14 SystemVision... 14 Synopsys...14 Saber Designer... 14 DESIGNMETODIK I VHDL-AMS...15 System- till kretsnivå...16 Några fördelar med att utveckla enligt system- till kretsnivå:... 17 Några nackdelar med att utveckla enligt system- till kretsnivå:... 17 Krets- till systemnivå...18 Gränssnittsprioritering...19 RTL- till systemnivå...19 Övrigt...19 KODNYHETER I VHDL AMS KONTRA VANLIGA VHDL...20 Kodnyheter...20 Entity och Architecture... 20 Quantity... 20 Terminal... 21 Quantity branch... 21 Nature... 21 Exempel...22 Designprogrammen blir mer grafiska...28 UNDERSÖKNING AV FÖRDELAR OCH NACKDELAR MED VHDL-AMS....28 Fördelar:...28 Nackdelar:...29 BLIR KONSTRUKTIONERNA BÄTTRE OCH ENKLARE?...29 Konstruering av elektriska system...29 Simulering av elektriska system...29 Sammanfattning av konstruktion och simulering...30 SIMULERINGAR AV SMÅ TESTSYSTEM...31 2
SÅ FUNGERAR SIMULERINGEN...31 Själva simulatorn...32 A/D-OMVANDLARE (KOD SES I BILAGA 1)...34 D/A-OMVANDLARE (KOD SES I BILAGA 2)...35 HELVÅGLIKRIKTARE (KOD SES I BILAGA 3)...36 INVERTERANDE FÖRSTÄRKARKOPPLING (KOD SES I BILAGA 4)...38 DIFFERENTIALFÖRSTÄRKARKOPPLING (KOD SES I BILAGA 5)...41 FILTERKOPPLING 1, LÅGPASS (KOD SES I BILAGA 6)...43 FILTERKOPPLING 2, HÖGPASS (KOD SES I BILAGA 7)...46 KOMPARATOR (KOD SES I BILAGA 8)...49 SAMMANFATTNING SIMULERINGAR...51 FRAMTIDSPROGNOS...52 KÄLLFÖRTECKNING...54 BÖCKER:...54 DOKUMENT OCH RAPPORTER...55 FÖRETAGSHEMSIDOR...55 YTTERLIGARE INTERNETSIDOR SOM VI HAR HAFT NYTTA AV...56 3
Inledning I drygt 20 år har man i konstruktionsarbetet av olika elektroniska system använt sig av olika programspråk och simulatorer. Tills för några år sedan (slutet av 1990-talet) så har man använt sig av olika programmeringsspråk för utveckling av de digitala respektive analoga delarna i systemen. Men de senaste åren så har arbetet med att skapa ett bra programmeringsspråk som klarar båda delarna varit i full gång. Det språk som vi ska göra en närmare undersökning av är VHDL-AMS (Very High speed integrated circuits Hardware Description Language Analog and Mixed Signal) som bygger på IEEEstandarden 1076.1 (Institute of Electrical and Electronics Engineers). Uppdragsbeskrivning Examensarbetet går ut på att göra en studie av analog simulering med det hårdvarubeskrivande språket VHDL-AMS. Studien är indelad i fem delar: Vad är VHDL-AMS? Beskrivning av historik och bakgrund till varför språket utvecklats och vad det är tänkt att användas till samt en djupare genomgång av VHDL. En fördjupning av VHDL-AMS Genomgång av fundamentala språkkrav, undersökning av vilka företag som utvecklar verktyg för VHDL AMS, designmetodik i VHDL-AMS och kodnyheter i VHDL-AMS kontra VHDL. Fördelar och nackdelar med VHDL-AMS Undersökning av vilka fördelarna och nackdelarna är med VHDL AMS. Blir konstruktionerna bättre och enklare? Simuleringar av små testsystem Simuleringar av några enkla testkonstruktioner i VHDL-AMS och jämföra med traditionella analoga simuleringar. Simulering i VHDL-AMS-verktyget SystemVision och i MultiSim för att jämföra resultatet. Framtidsprognos Hur ser framtiden ut för VHDL-AMS, har det någon möjlighet att slå igenom på allvar? Bo Janfalk, nordisk marknadschef på Mentor Graphics ger sin syn på framtidsutsikterna. 4
Krav Det första krav vi har är att i första hand välja verktyg både för konstruktion och simulering från företaget Mentor Graphics, detta p.g.a. att Örebro universitet redan använder några av deras produkter med bra resultat. Det andra är att när vi utför simuleringstestet ska resultatet jämföras med motsvarande simulering i programmet MultiSim. Syfte Syftet med examensarbetet är att samanställa en studie av VHDL-AMS så att tekniska institutionen vid Örebro universitet kan ha hjälp att besluta om man ska ta med VHDL- AMS i någon utbildning. 5
Bakgrund Historik För att få en lite bättre bild av behovet och problemen berörande ett hårdvarubeskrivande språk som kombinerar både analoga och digitala signaler ger vi först lite historik kring digitala kretsar och programspråket VHDL. Grunden för de mixade analoga och digitala systemen som finns idag kan spåras tillbaka till 1950-talet då transistorn precis börjat tagits i bruk och ersatt elektronrören. Fördelen med transistorn var att den inte utmattades lika snabbt som elektronröret. Till en början förändrades inte tillvägagångssättet man hade när man konstruerade nya system. Konstruktören ritade fortfarande upp systemet på papper och försökte räkna fram hur signalerna skulle bete sig. Efter detta testade man om det stämde i verkligheten genom att helt enkelt sätta ihop systemet och prova. Sedan fick man vid eventuella fel börja om vid ritbordet och räkna ut var felet kunde vara och sedan fortsätta testa resp. rita om tills konstruktionen fungerade korrekt. På grund av att transistorn nu fanns kunde man i början av 70-talet bygga datorer som var både tillräckligt snabba och med tillräckligt stora minnen för att kunna göra, i dagens synvinkeln, väldigt enkla simulatorer. Att man började med att skriva simulatorprogram istället för konstruktionsprogram var att man var väl medveten om att väldigt mycket effektiv konstruktionstid gick åt till att fysiskt bygga och testa systemen flera gånger på grund av alla slarv- och räknefel som gjorts. Konstruktörerna kunde nu testa sina system innan den verkliga konstruktionen gjorts. Givetvis klarade dessa enkla simulatorer inte av att testa hela systemen samtidigt och inte invecklade modeller, men trots detta reducerades antalet gånger man var tvungen att fysiskt testa avsevärt. Som en följd av detta ökade nu systemens komplexitet kraftigt och det blev snart svårt att överblicka helheten av systemen. Detta ledde till en uppdelning av systemen till mindre separata delar och då fick man problem med att många nya fel uppstod när delarna skulle sättas samman. Som lösning på det problemet började man nu att använda datorerna även i själva konstruktionen och skrev program som var konstruktören behjälplig under hela utvecklingsfasen och systemen kunde därför göras ännu mera avancerade. De första hårdvarubeskrivande programmeringsspråken kom under 1980-talets första hälft och förändrade markant elektronikutvecklingen. När man nu delade upp kretsar och kretskort i större skala, så blev en naturlig följd att skapa ett större utbud av olika kretsar. Istället för att skapa ett oändligt stort antal standardkretsar, blev lösningen istället ASIC:ar (Application-Specific Integrated Circuit ) som är en form av egna integrerade kretsar och olika programmerbara kretsar. Programmeringsspråken beskrev funktionen för kretsarna utan att veta vad det egentliga innehållet var. Genom detta kunde man tidigt i konstruktionsarbetet bestämma vilket gränssnitt som kretsarna hade mot omvärlden och övriga kretsar i systemet. 6
Tills för några år sedan (slutet av 1990-talet) har man endast använt sig av dessa programmeringsspråk för utvecklingen på den digitala sidan i systemen och så har man löst de analoga bitarna på andra sätt. Men de senaste åren så har arbetet med att skapa ett bra programmeringsspråk som klarar båda delarna varit i full gång och nu börjar fler och fler företag att intressera sig på allvar för detta. Programmeringsspråk För att kunna skilja på de olika programmeringsspråken så delar man upp dem i vilka områden de används. Digital konstruktion, verktyget klarar att analysera och hantera det logiska beteendet hos kretsen. Analog konstruktion, verktyget klarar av att hantera typiska analoga beteenden t.ex. ström, spänning och frekvens. Blandad konstruktion, verktyget klarar av att hantera båda ovanstående fallen. För att ge läsaren en inblick i några av programmeringsspråken som används till de olika kategorierna ges några små korta beskrivningar nedan. Digitala konstruktionsspråk Eftersom det finns många verktyg för digital konstruktion som är utarbetade enbart för att klara täcka ett väldigt specialiserat område så tar vi upp de mer generella verktygen t.ex. VHDL, Verilog HDL, M och UDL/I. Nedan ges en kort beskrivning av dessa språk. M är ett språk speciellt anpassat för CAD-tillverkaren Mentor Graphics simulator Lsim. Det saknas referensmanual och är inte standardiserat. Lsim är en simulator 7
som klarar av att köra SPICE-kod (Simulation Program with Integrated Circuits Emphasis) samtidigt som M-kod, vilket öppnar vägen för samtidig simulering av analoga och digitala delar i en och samma konstruktion. Språket är baserat på C. Verilog HDL är ett språk i huvudsak inriktat mot simulering av ASIC-kretsar. Det utvecklades i mitten av 80-talet av Gateway Design Association. Två stora fördelar med Verilog HDL är dess stora valbarhet av simuleringsmodeller samt dess PLI (gränssnitt) mot andra programmeringsspråk. Med hjälp av PLI kan man skriva funktioner i C som skulle vara näst intill omöjliga i själva Verilog HDL, antingen beroende på simuleringshastighet eller svårighetsgrad. Precis som VHDL(se nedan) är Verilog HDL standardiserat av IEEE, men har begränsade möjligheter för systemutveckling på högre abstraktionsnivåer. VHDL är idag det klart dominerande språket för datorstödd elektronikkonstruktion. Det är ett programmeringsspråk som stödjer olika hierarkiska designmetoder och är mycket generellt. Man kan till exempel utvidga det till att omfatta modeller på analoga komponenter vilket vi återkommer till. Språket är standardiserat av IEEE, Institute of Electrical and Electronics Engineers, vilket i sin tur innebär att det relativt enkelt kan flyttas mellan olika simulatorer och kompilatorer i olika datormiljöer. Ett tecken på att språket är mycket utbrett är att amerikanska försvaret kräver att alla logikkomponenter ska vara beskrivna i VHDL. UDL/I är ett mycket generellt språk och är liksom VHDL oberoende av speciella simulatortillverkare. Det började att utvecklas 1989 av Japan Electronic Industry Development Association. Problemet med detta språk är att det saknas väsentliga grundläggande egenskaper, vilka klassas som standard i VHDL. En viktig grupp av programspråk är de som stödjer utveckling av programmerbara logiska kretsar, PLD:er. De används flitigt för mindre konstruktioner och är oftast mycket billiga. Ett problem är att de sällan har stöd för utveckling på hög abstraktionsnivå. Analoga Programmeringsspråk Det finns inte alls lika många verktyg för analog- som det finns för digital konstruktion. De två som vi tar upp här är SPICE2 och MHDL. SPICE2 är det mest kända verktyget av de så kallade SPICE-simulatorerna. SPICE2 utvecklades på University of California i början av 70-talet, programmet var när det kom mycket kraftfullare och snabbare än vad som tidigare funnits. På grund av detta och att användningsområdet var brett blev det de facto standard för analoga simuleringar. De algoritmer som skrevs till SPICE2 var såpass bra att de fortfarande används som bas till program som används i viss utsträckning idag t.ex. PSPICE. 8
Simuleringarna som görs med grunden från SPICE2 utförs alltid baserade på de elektriska lagarna och har varit dominerande inom området simulering för analog teknik i ca 20 år. MHDL är ett hårdvarubeskrivande språk för analoga och mikrovågsbaserade system. Likt VHDL har språket stöd för att beskriva fysiska kopplingar mellan komponenter och framförallt stöd för att konstruera ett system på hög abstraktionsnivå. Inom ramen för språket finns även ett gränssnitt mot VHDL. De flesta verktyg under gruppen för analog konstruktion kan simulera digitala kretsar, men anledningen till att de inte hamnar i gruppen blandade system är att den digitala simuleringen inte sker med logikens lagar utan med de elektriska. Detta medför att man får mycket överflödig information som gör att stora system inte blir överskådliga ur en logisk synvinkel och simuleringstiderna blir långa. Verktyg för blandade system Den senast tillkomna grupp verktyg är för blandade system, mycket därför att utvecklarna har velat behålla fördelarna som både de digitala och de analoga verktygen ger. Den största komplikationen för verktygstillverkarna har varit att behålla den generella designmetodik som till exempel VHDL erbjuder, att utveckla på många olika abstraktionsnivåer. En annan tankenöt har varit att man velat behålla snabbheten i simuleringen av de digitala delarna genom att simulera med hjälp av logikens lagar istället för de elektriska, samtidigt som den noggrannhet som de analoga bitarna behöver inte ska försämras. Vi tar upp tre verktyg som klarar av design av blandade system på många abstraktionsnivåer VHDL-AMS, anavhdl och LSIM. VHDL-AMS började utvecklas redan 1992 av en arbetsgrupp från IEEE som hade målet att utvidga redan befintlig VHDL-standard för att omfatta även mixade signaler. Det nya språket som från början kom att kallas VHDL-A skulle stödja utveckling av system med både analoga och digitala signaler på många olika abstraktionsnivåer. I början av 1997 togs beslutet att det formella namnet på språket skulle vara bli VHDL-AMS. I rapporten så kommer vi senare gå in djupare på VHDL-AMS. anavhdl var ett projekt som understöds av bland annat U.S. Air Force och Department of Defense Advanced Research Agency (ARPA). Detta projekts syfte var att minimalt utöka VHDL 93 till att även omfatta analoga signaler. Namnet på språket är det samma som projektet, det vill säga anavhdl. De typer av analoga signaler som språket är optimerat för är elektriska, optiska, termiska och elektromagnetiska. LSIM från Mentor Graphics var i slutet av 1990-talet ett av de mest använda konstruktionsverktygen för utveckling av hårdvara. Det stödjer både beteende- och strukturellt beskrivna modeller av kretsar skrivna i Mentor Graphics hårdvarubeskrivande språk M (nämnt ovan). Vidare klarar simulatorn av att analysera nätlistor genererade från en del schemaritningsprogram, SPICE-kod och VHDL-kod skriven på logiknivå. En fördel med LSIM är att man kan ställa in hur simulatorn ska tolka varje individuell komponent eller krets. Om man har 10 likadana OP-förstärkare så kan man låta 3 av dem tolkas med ren logikanalysering medan resterande kan tolkas ur ett rent analogt perspektiv. Detta medför att simuleringstiderna kan minskas avsevärt. 9
En nackdel med LSIM är att denna simulator enbart analyserar elektriska analoga signaler och inte exempelvis elektromagnetiska eller optiska. Vidare är M-språket inte lika generellt som VHDL och begränsar därför möjligheterna för simulatorn att analysera beteendet på kretsar skrivna på en hög abstraktionsnivå. En djupare genomgång av VHDL Eftersom VHDL är det största hårdvaruprogrammeringsspråket och VHDL-AMS bygger på det så ger vi en liten fördjupning runt VHDL. VHDL användes ursprungligen enbart till att beskriva och verifiera beteendet på digitala kretsar och system på många olika nivåer för att klara av att hantera stora komplexa konstruktioner. Nu för tiden användes det istället av de flesta konstruktörerna för att skriva kod som syntesverktyg automatiskt översätter till annan kod och som direkt kan skapa hårdvara i ASIC:ar eller programmerbara kretsar, alltså synteserbar kod. Fördelar med VHDL VHDL är tillsammans med en lämplig simulator en komplett utvecklingsmiljö för konstruktion av digitala system. Systemet kan först beskrivas på hög abstraktionsnivå och sedan kan man mer detaljerat beskriva de lägre nivåerna. Genom simulering kan man under hela konstruktionen verifiera sitt system vid dessa steg. VHDL ger möjlighet att på ett tidigt stadium fastslå gränssnitten mot omvärlden. VHDL är optimalt ur återanvändningssynpunkt. Har man en gång skapat och verifierat en modell på en krets, kan man använda den hur många gånger och var som helst. VHDL ger möjlighet till att testa elektronikmodeller utan att ta hänsyn till teknologiberoende konstruktioner. Detta gör att man snabbt och enkelt t.ex. kan byta från standardkretsar till en programmerbar logisk krets VHDL är standardiserat och består av en textfil som enkelt kan flyttas mellan olika datorsystem. VHDL-kod finns att köpas för standardkomponenter om man inte har kompetens eller tid att skriva den själv. Dessa kallas IP-block (Intellectual Property). VHDL kan beskriva hårdvarans parallella natur på ett korrekt sätt, det vill säga många händelser vid samma tidpunkt. T.ex. behövs det vid simuleringar av digitala filter. Nackdelar med VHDL Två nackdelar är att VHDL inte stödjer utveckling av analog elektronik och att språket inte är standardiserat vad gäller syntetisering. 10
Analog simulering i VHDL VHDL var ursprungligen avsett för rent digitala miljöer men eftersom språket även klarar av att hantera heltal, reella tal och egendefinierade fysiska typer, till exempel kapacitans och resistans kan man utvidga det till att även omfatta analoga signaler. Standardiseringsorganet IEEE har utökat VHDL för att kunna hantera analoga signaler. Detta utökade språk går under namnet VHDL-AMS (IEEE 1076.1) och har utvecklats av en av IEEE:s arbetsgrupper. Nästa delavsnitt tar upp en del aspekter att tänka på om man själv skulle vilja utöka VHDL för att även omfatta analoga signaler, sedan kommer en fördjupning om VHDL- AMS. Egen utvidgning av VHDL Istället för att använda en redan färdig utvidgning av VHDL vid användandet av analoga signaler som t.ex. VHDL AMS, kan man göra en specialkonstruerad egen utvidgning. Innan man försöker det på egen hand, bör man känna till språkets generalitet och begränsningar. En viktig del är generaliteten eftersom man kan göra utvidgningen på många olika sätt. Det som styr hur man väljer att utvidga språket på är i första hand vilka modeller man har tänkt sig att utveckla i kombination med språkets begränsningar. VHDL stödjer endast de fyra grundläggande matematiska funktionerna addition, subtraktion, multiplikation och division och dessa fyra funktioner kan man använda sig av så länge man håller sig till reella tal och heltal. Börjar man att blanda in egendefinierade typer i ekvationerna gäller det att veta vad man vill få för resultat. Ett exempel, dividerar man en fysisk typ med en likadan fysisk typ får man ett heltal som svar. NÅGRA VIKTIGA PUNKTER ATT TÄNKA PÅ VID EGENUTVIDGNING AV VHDL VHDL stödjer endast de fyra grundläggande räknesätten, vilket innebär att man själv måste skriva övriga matematiska funktioner. Man bör använda reella tal om inte de modeller som man har tänkt sig att beskriva är mycket enkla. Koden blir lättare att förstå om man använder sig av egendefinierade fysiska typer istället för att använda sig av reella tal. VHDL representerar fysiska typer som heltal och begränsar således talområdet från vilket den fysiska typen antar sina värden. Man kan snabba upp vissa simuleringar genom att anpassa sina modeller för exakt de tillämpningar som de är avsedda för. Det bör tilläggas att egenutvidgning inte görs i en handvändning utan är mycket tidskrävande även för de som har mest kunskap inom VHDL. 11
En fördjupning av VHDL-AMS 1992 skulle man revidera VHDL-standarden och i inledningen av det arbetet klargjorde man att det skulle kunna vara genomförbart att utöka språket för att klara analoga signaler. Vid den här tiden fanns åtskilliga idéer på hur man skulle kunna förbättra den redan befintliga digitala funktionaliteten i VHDL och därför beslutades det att en speciell VHDL-AMS arbetsgrupp skulle tillsättas för att se hur man skulle kunna tillföra de analoga bitarna. Från början var avsikten att man skulle samla de analoga behoven som fanns 1992 och sammanföra dessa i en ny standard och vid nästa omstandardisering 1997 återigen sammanfoga den med standarden för digital VHDL (VHDL 1076). Som det ser ut idag så är VHDL-AMS en egen standard (VHDL 1076.1). Fundamentala språkkrav Det finns en del krav som är fundamentala för VHDL-AMS och som måste ingå i språket utan några som helst kompromisser. Nedan följer några av dessa. VHDL-AMS måste vara lämplig för beskrivning och simulering av digitala, analoga och blandade system på många abstraktionsnivåer. VHDL-AMS måste kunna användas oberoende av designmetodik. VHDL-AMS måste klara av tidsanalys av sammanhängande elektroniska system. VHDL-AMS måste klara av linjär frekvensanalys av sammanhängande elektroniska system i småsignalanalys. VHDL-AMS måste klara av att hantera brus, både vad det gäller modellering och analys. VHDL-AMS måste tillhandahålla mekanismer som tillåter att beteendet på de analoga och digitala delarna kan interagera. VHDL-AMS måste vara fullständigt definierat vad det gäller de grundläggande A/D och D/A mekanismerna. VHDL-AMS måste klara av att hantera analoga system skrivna på beteendenivå, där beteendet har skrivits med hjälp av en mängd av linjära eller ickelinjära differentialekvationer eller algebraiska uttryck. VHDL-AMS måste klara av att hantera diskontinuerliga analoga beteenden och vågformer. Innan vi går in mer på de rent språk- och programtekniska bitarna ger vi en överblick vilka företag som är de största aktörerna på VHDL-AMS-marknaden. 12
Företagen som har utvecklat verktyg för konstruktion och simulering i VHDL-AMS Det finns idag ett antal företag som arbetar med att utveckla olika verktyg för VHDL AMS, bland annat Mentor Graphics, Cadence, Ansoft och Synopsys. Ansoft Ansoft corporation är ett amerikanskt företag som tillverkar och utvecklar programvaror för en mängd olika behov, bland annat för design av mobiltelefoner, kommunikationssystem, bredbandskomponenter, integrated circuits (ICs) och printed circuit boards (PCBs). Ansoft har sitt huvudkontor i Pittsburgh, USA, men man finns även i Asien och Europa. SIMPLORER 6.0 Ansofts programvara för VHDL AMS heter Simplorer 6.0 och är enligt företaget lämpligt för design och simulering inom bil-, flyg- och järnvägsindustrin samt för elektriska styrsystem. Eftersom programmet klarar av VHDL AMS kan man analysera mekanik, hydraulik och termiska problem tillsammans med traditionell design av elektronik. Simplorer har ett grafiskt gränssnitt och VHDL AMS är helt integrerat i detta, koden skrivs i en inbäddad editor. Programmet är SPICE-kompatibelt och den egna kompilatorn klarar de flesta SPICE-modeller. Simplorer innehåller en del verktyg för analyser, bland annat DC- och AC-analys. Cadence Cadence Design Systems är världens största tillverkare inom EDA (electronic design automation) teknologier. Man utvecklar programvara för en mängd olika behov och man har som mål att kunderna skall kunna öka hastigheten på tillverkningsprocessen med hjälp av företagets produkter. Cadence Design Systems bildades 1988 och finns idag över hela världen. Företaget har ca 4800 anställda. VIRTUOSO AMS DESIGNER SIMULATOR Virtuoso AMS Designer Simulator är en programvara för design av mixade system och simulering som klarar mycket komplexa signaler. Programvaran är språkbaserad och klarar av standardspråken Verilog-AMS och VHDL-AMS. Programmet arbetar så att det kombinerar både de analoga och de digitala flödena samtidigt, alltså inte enskilda simuleringar av de analoga och digitala signalerna. Virtuoso AMS Designer tillåter olika sorters datainmatning. Programmet är flerspråkigt och klarar av standardspråk som Verilog-AMS, VHDL-AMS, Verilog-A, Verilog, och VHDL men även olika netlist-format som t.ex. SPICE. Detta tillåter analog bottom-up och digital top-down design att mötas på mitten. I programmet kan man designa schematiskt och programmet skapar då en nätlista automatiskt. I simuleringsmiljön ser man resultaten i waveform-fönster och kan mäta med markörer. 13
Mentor Graphics Mentor Graphics är ett av de ledande företagen inom den teknologiska utvecklingen av EDA (electronic design automation). Man erbjuder både mjukvaru- och hårdvarudesignlösningar för företag som utvecklar elektronik. Mentor Graphics har utvecklat många av de bästa produkterna och man är det enda EDA-företaget med en inbyggd mjukvarulösning. Företaget grundades 1981 och man har idag ca 3700 anställda i hela världen. Huvudkontoret är placerat i Wilsonville, Oregon. SYSTEMVISION Mentor Graphics SystemVision är en design- och simuleringsmiljö som hanterar mixade signaler med VHDL AMS och SPICE. SystemVision har ett grafiskt gränssnitt för design, VHDL AMS-verktyg, avancerad simuleringsteknologi och kraftfulla analysverktyg. SystemVision är Mentors senaste lösning för matematikbaserad datoriserad prototypframställning och kan ses som ett genombrott för mekatroniska verktyg. Man kan designa mekatroniska system genom att kombinera matematikbaserade analyser med både digitala- och mixade simuleringar. Med den matematikbaserade datoriserade prototypframställningen kan man med SystemVision designa och analysera nästan vilket system som helst, virtuellt. Elektronikbaserade analoga-, digitala- och mixade signalsystem kan kombineras och analyseras i en enda design. Icke elektriska system som mekaniska, termiska och magnetiska kan också designas och simuleras med alla andra system. Även abstrakta högnivåsystem som t.ex. s-domänen och z-domänen har full support och kan integreras med de andra systemen. Synopsys Synopsys, Inc. är ett av världens ledande företag inom tillverkning och utveckling av halvledardesign-programvara men man utvecklar också programvara för systems-onchips (SoCs) och elektroniska system. Bland kunderna finns företag inom branscherna halvledare, data, kommunikation, konsumentelektronik, flyg och andra företag som utvecklar elektronik. Företaget bildades 1986 och har idag ca 4400 anställda över hela världen. Man har sitt huvudkontor i Mountain View, California. SABER DESIGNER Saber-programvaran simulerar fysiska effekter inom flera olika ingenjörsområden, t.ex. hydraulik, elektronik, mekanik, men även signalflödesalgoritmer och mjukvara. Saber Designer används inom bil-, flyg-, kraft- och IC-industrin för att simulera och analysera system, undersystem och komponenter för att reducera behovet och användandet av prototyper som är tidsödande. Programvaran har det största modellbiblioteket inom industrin, avancerade analyser och är kompatibelt med de populäraste designmiljöerna. Man har utvecklat ett eget hårdvarubeskrivande språk för programmet, MAST, men det stödjer även VHDL AMS fullt ut. Programmet innehåller tre olika delar, sketch, guide och scope. Sketch används för design och editering. Med Sketch kan man schematiskt bygga upp virtuella prototyper i mixed-signal-miljö. 14
Guide används för analyser och det finns en hel del att välja på, bl.a. DC arbetspunkt, transient, DC överföringskarakteristik och spektral analys. Scope är ett mätinstrument som man grafiskt kan göra över 50 olika sorters mätningar av tid eller frekvens med. Nästa del i rapporten beskriver de olika designmetoder som tillämpas i VHDL-AMS Designmetodik i VHDL-AMS En viktig del när man ska konstruera elektriska system i VHDL-AMS är att bestämma vilket tillvägagångssätt man ska använda sig av. Eftersom vårat valda verktyg för simulering och konstruering är en begränsad utbildningsutgåva så har vi inte möjligheten att med något större projekt visa hur designmetodiken i VHDL-AMS går till. Istället gör vi en mer teoretisk beskrivning av det området. När man talar om designmetodik i VHDL-AMS och även VHDL hör man ofta talas om olika begrepp som nivåer, representationer, stilar och domäner så för att få en helhetssyn på det hela så krävs det att man benar upp de olika delarna. Gajskis Y-diagram, se figur 1, är en grafisk framställning som underlättar mycket. I figuren nedan finns det för varje representationsgren exempel på vad en nivå kan bestå av för att lättare förstå innebörden av de olika nivåerna. Figur 1: Gajskis Y-diagram. I kommande avsnitt tas olika designmetodiker i VHDL-AMS upp. Först tas systemnivå till kretsnivå upp, sedan dess motsats kretsnivå till systemnivå. Vidare följer gränssnittsprioritering samt en av de vanligaste designmetoderna, RTLnivå till systemnivå. Till sist kommer ett avsnitt som beskriver övriga metoder. 15
System- till kretsnivå Denna metod, Top-Down Design, är den som förespråkas mest men som i själva verket sällan används vid konstruktion i VHDL-AMS. För att göra en enkel beskrivning av denna metod följer ett exempel på hur utvecklingen av en dator skulle kunna se ut. 1. Man börjar med att skriva hur man vill att datorn ska fungera, man beskriver helt enkelt beteendet på den. Man specificerar även gränssnittet ut mot omvärlden. 2. Testning av den kod som har skrivits. Beteendet ska nu sammanfalla med den systemspecifikation som har tagits fram. Det finns en annan möjlighet och det är att man gör tvärtom och tar fram en systemspecifikation utgående från VHDL-AMSsimuleringen. 3. Man skriver beteendet för varje delsystem på samma sätt som gjordes tidigare för hela datorn d.v.s. man bryter ner datorn i mindre beståndsdelar såsom processor, minne m.m. 4. Ny testning och nu skall delsystemen fortfarande fungera tillsammans så som systemspecifikationen kräver. 5. Delsystemen bryts ner i mindre delar och man upprepar förfarandet på samma sätt som ovan. Man upprepar denna process ända tills man når ner till kretsnivån. Se figur 2 för en grafisk presentation av arbetsgången i denna designmetod. Figur 2: Från system- till kretsnivå visualiserat i ett Gajskidiagram. 16
NÅGRA FÖRDELAR MED ATT UTVECKLA ENLIGT SYSTEM- TILL KRETSNIVÅ: Redan på ett tidigt stadium får man en verifiering på att systemet fungerar så som systemspecifikationen kräver. Har man företag som skall tillverka angränsande system eller apparater kan de påbörja sin egna utveckling tidigt eftersom de tidigt får reda på hur gränssnittet ser ut. Har man gjort några tankefel vid systemtänkandet elimineras de från början. Det finns redan på ett tidigt stadium möjlighet till syntes under förutsättning att syntesverktyget man använder klarar av kod skriven på en hög abstraktionsnivå. När som helst kan systemet fördelas på olika konstruktörer. Om företaget hela tiden måste utveckla i närheten av forskningsfronten för att konkurrera med andra bolag, kan man med denna designmetod konstruera sitt system med viss framförhållning vad gäller prestanda på systemet och i princip chansa på att kretsar finns tillgängliga på marknaden när man kommer ner till kretsnivån. NÅGRA NACKDELAR MED ATT UTVECKLA ENLIGT SYSTEM- TILL KRETSNIVÅ: Efter flera uppdelningar kan denna designmetod resultera i en komponent som med dagens hårdvara visar sig vara omöjlig att konstruera. För att behärska den här designmetoden krävs kunskaper i både högnivåprogrammering och i elektronikkonstruktion och det är orsaken till att den används i så liten utsträckning idag. De flesta VHDL-AMS-programmerare är hårdvarukonstruktörer och ser därför konstruktionen framför sig och vill gärna konstruera efter denna bild. De bygger sedan ihop dessa små delar till ett helt system. 17
Krets- till systemnivå Bottom-Up Design är den klassiska metoden och baserar sig på att man har utprovade beteendemodeller på välkända kretsar som sedan monteras ihop till större och större block, tills man har realiserat hela systemet. Denna metod är i stort sett motsatsen till föregående, system- till kretsnivå. Se figur 3 för en grafisk presentation av arbetsgången. Figur 3: Från krets- till systemnivå visualiserat i ett Gajskidiagram. Några fördelar med att utveckla enligt krets- till systemnivå: Redan på ett tidigt stadium har man möjlighet till att syntetisera sin kod och kan därför anpassa storleken på sin konstruktion efter de kretsar som man har valt att använda. Då man utgår ifrån redan existerande kretsar, kommer designmetoden inte att leda till en konstruktion med komponenter som är omöjliga att realisera med dagens hårdvara. Några nackdelar med att utveckla enligt krets- till systemnivå: Denna metod leder sällan till de snabbaste algoritmerna/lösningarna. Efter ett antal sammansättningar av mycket noggranna modeller blir simuleringstiderna väldigt långa. Man måste ändra i testbänken för varje nivå. Det är svårt att byta ut enstaka komponenter eftersom man knyter samman varje komponent med dess omgivning väldigt hårt. 18
Gränssnittsprioritering Det finns en variant på system- till kretsnivå där man, efter att ha beskrivit hela systemets beteendet och dess testbänk, koncentrerar sig på gränssnitten och beskriver dessa med förfinade modeller tills man når till den nivå där buffertar och andra kretsar ut mot omvärlden är tillräckligt specificerade. De problem som är förknippade med gränssnitten och som inte kan upptäckas på de högsta nivåerna av beskrivningar löser man tidigt på detta sätt. Exempel på denna typ av problem är busskrockar eller för långa tider med högimpediva tillstånd. När man är klar med gränssnitten arbetar man sig inåt i det system som man konstruerar. Man kan dock tvingas skriva extra kod i form av översättare mellan de nya gränssnitten och den kod som utgör beteendet på själva kärnan av systemet med detta tänkande. RTL- till systemnivå Den vanligaste konstruktionsmetoden idag i VHDL-AMS är en variant på krets- till systemnivådesign där man hoppar över de första utvecklingsstegen och påbörjar sitt konstruktionsarbete på RTL-nivån (Register Transfer Level) för att sedan utveckla systemet därifrån. Denna metod förutsätter dock att man har skapat och simulerat block på RTL-nivå tidigare, samt har skrivit förenklade modeller på dessa block utan att påverka deras funktioner. De största fördelarna med denna metod är att man kommer snabbare till skott med sin konstruktion och att simuleringarna går mycket fortare med de förenklade modeller som används. Väldigt viktigt är att de modeller man använder är mycket pålitliga. Övrigt De designmetoder vi har tagit upp ovan är bara exempel på hur man kan göra i VHDL- AMS. Eftersom VHDL-AMS tillåter valfri designmetodik så är det inget som hindrar att man tillämpar egna metoder. 19
Kodnyheter i VHDL AMS kontra vanliga VHDL Eftersom vår huvudsakliga uppgift är att studera hur VHDL-AMS uppbyggda analoga kopplingar simuleras med vårat valda verktyg i jämförelse med MultiSim så går vi inte in så djupt på hur systemen är programspråksmässigt är uppbyggda. Nedan ges dock en kort beskrivning av de huvudsakliga nyheterna i tilläget AMS. Detta avsnitt kräver att man har viss vana från VHDL för att förstå förklaringarna som ges. Sättet hur man bygger upp sina system har förändrats mot vanliga användningen av VHDL där man ofta skriver själva programkoden själv. Med tillägget AMS har man eftersom språket blivit mer avancerat riktat in sig mer mot det grafiska användandet d.v.s. man använder standardmodeller som man klickar och lägger till när man skapar sina system. Det är först och främst de analoga modellerna som används så, men även på den digitala sidan har det grafiska användandet ökat. I texten nedan har vi tagit med många ord på engelska som vi har skrivit i kursiv stil. Att vi inte har översatt dem beror på att vi inte vet vad den korrekta översättningen ska vara och inte vill hitta på något eget slangord. VHDL-AMS är än så länge såpass nytt att det inte verkar finns något material alls på svenska som berör ämnet. Kodnyheter ENTITY OCH ARCHITECTURE Precis som i vanliga VHDL så byggs modellerna i VHDL AMS upp med en entity och en eller flera architectures. Entityn bestämmer modellens gränssnitt mot omvärden, vilka signaler som är inkommande och vilka som är utgående och definierar även allmänna parametrar. Architecture innehåller själva implementationen av modellen, hur den är tänkt att fungera. När en VHDL AMS modell har flera architecthures så bestämmer konstruktören vilken av dem som ska användas vid vilket tillfälle. QUANTITY I VHDL AMS introduceras en helt ny klass av objekt, quantity, som representerar de okända i de differentiella ekvationer som behövs användas för att beräkna de analoga delarna i modellen. Quanitities är skalärer eller vektorer beroende på hur de ska 20
användas. De får deklareras överallt där en vanlig signal får deklareras, med undantag för att de inte får deklareras i ett VHDL-package. Nedanstående exempel deklarerar de tre quantities q1, q2 och q3 av typen REAL quantity q1, q2, q3: REAL En quantity kan även deklareras som ett gränsnitt i portlistan för en modell och då anger man vilken typ det ska vara, t.ex. som i exemplet nedan där två gränssnitts-quantities är deklarerade som ingångar, och en som utgång.: entity summer is port (quantity in1, in2: in REAL; quantity sum: out REAL); end entity summer; TERMINAL Terminals användningsområde i VHDL-AMS består i att de fungerar som motsvarigheten till våra fysiska ihopkopplingspunkter och noder i en krets. Terminals deklareras att tillhöra det användningsområde där de ska användas. Terminals hänger nära samman med quantity branch som ofta associeras med terminals och då används terminals som mätpunkter som man t.ex. mäter vad man har för spänning över och vilken ström som flyter igenom dem. Ett exempel på en deklaration av en terminal kan se ut som följer: terminal nod1: electronic; QUANTITY BRANCH Quantitybranch är en typ av quantity som uppkommer när man associerar quantity med terminals. Antingen kan Quantity branch vara av typen across quantity branch eller av typen through quantity branch. Om man använder VHDL-AMS till att beskriva något elektriskt system så är across lika med spänning och through lika med ström. Deklarationen kan se ut så här: quantity batteri_spanning across batteri_strom through anod to katod; Här kommer batteri_spanning bli av typen across quantity branch och representeras av en spänning och batteri_strom kommer bli av typen through quantity branch och alltså representera en ström. Spänningen kommer vara potentialskillnaden mellan terminals anod och katod och strömmen kommer vara storleken på den ström som flyter mellan samma terminals. NATURE Programspråket VHDL-AMS kan man ju använda till konstruktion och simulering i olika användningsområden. Varje användningsområde har därför blivit fördefinerat så att det ska vara lätt att använda dem. T.ex. så ser definitionen för det elektriska området ut som följer: package ELECTRICAL_SYSTEM is 21
subtype VOLTAGE is REAL; subtype CURRENT is REAL; Nature electrical is voltage across current through electrical_ref reference; end package ELECTRICAL_SYSTEM; Det som menas är att typen voltage(spänning) är potentialskillnaden mellan de terminals som man associerar den med, typen current(ström) är den ström som flyter mellan dessa terminals och reference(referens) är motsvarande jord i vanliga kretsscheman. Reference används som den andra terminalen om man bara skulle ange en terminal som var associerad med en spänning eller ström. T.ex. skulle det kunna se ut så här: terminal in_plus, in_minus, forstark_out: electrical; quantity signal_niva across in_plus to in_minus; quantity output_niva across output_strom through forstark_out; Quantity signal_niva deklareras som en across branch quantity av typen spänning, eftersom spänning är elektronikområdets across-typ. Signal_niva kommer att vara potentialskillnaden mellan terminals in_plus och in_minus. Quantity output_niva är på samma sätt en across branch quantity, men eftersom endast en terminal är associerad så kommer det vara potentialen mellan forstark_out och den terminal som är satt till reference (oftast jord). Quantity output_strom deklareras som en through branch quantity och får därför värde av typen ström. Själva värdet kommer att vara storleken på den ström som flyter mellan forstark_out och referensen. Exempel För att illustrera lite av det vi har gått igenom av kodnyheterna så följer ett exempel på hur man kan skriva en 1 bits analog-till-digital (ADC) konverterare med förstärkning. Det första man börjar med är att skriva koden för entityn: library ieee_proposed; use ieee_proposed.electrical_system.all entity adc is port( quantity gain : in voltage; terminal a : electreical; signal clk : in bit; signal d_out : out bit); end entity adc; De första två raderna i entityn ovan visar vilka bibliotek som ska användas och här ser man att vi kommer att använda analoga elektriska deklarationer i entityn. Porten som heter gain är en analog quantity port och representerar ett spänningsvärde som är 22
tidskontinuerligt. Porten a är en analog terminal port av elektriskt typ och representerar en nod i kretsen. Att a är av elektrisk typ gör att den har en spänning och en ström associerad med den. De sista portarna clk och d_out är digitala signal portar av sorten bit. De kan anta de tidsdiskreta värdena 1 eller 0. Entity deklarationen ovan gör att vi skulle få en model enligt figur 4. ADC gain a clk d_out Figur 4 När entityn är färdig ska man skriva architecture body som är beskrivningen om vad som ska hända inne i själva modellen. Som nämnts tidigare kan man ha fler än en architecture. Man kan skriva architecture på ett direkt beskrivande sätt som bestämmer hur modellen ska fungera på ett abstrakt vis. Då har man antingen process statements, d.v.s. en samling händelser som kommer att köras sekventionellt, eller så har man simultaneus statements, d.v.s. när händelserna ska köras styrs av ekvationerna som ska räkna ut det. Det första av fallen process statement används vanligtvis för att beskriva digitala funktioner och simultaneus statements används vanligtvis när analoga funktioner beskrivs. För att visa vad som menas ger vi ett exempel på en architecture till ADC. architecture ideal of adc is constatnt ref: real :=5.0; quantity v_in across a; quantity v_amplified : voltage; begin v_amplified ==v_in*gain; adc_behavior: process is variable stored_d : d begin if clk='1'then if v_amplified > ref/2.0 then stored_d:='1'; else stored_d := '0'; end if; end if; d_out <= stored_d after 5ns; wait on clk; end process adc_behavior; end architecture ideal; Architecture börjar med att deklarera konstanten ref, som representerar referensspänningen för ADC och tilldelar den värdet 5,0. Efter det deklareras en analog 23
branch quantity, vin, som representerar spänningen över terminal a. Värdet för en branch quantity som den här, styrs av spänningen och strömmen som tillhör de terminals som den är associerad med. I det här fallet a och reference (jord). Nästa deklaration som görs är v_amplified av typen free quantity och representerar den förstärkta inspänningen. Tvärtemot en branch quantity så styrs inte denna quantity av någon terminal utan räknas enbart ut av ekvationerna i den beskrivna modellen. Efter begin i architecture står tilldelningen v_amplified==v_in*gain; som är en simultaneus statement och tilldelar v_amplified värdet av v_in multiplicerat med gain. Sen skapas en process med namnet adc behavior som senare avslutas med end process. I processen finns några sekventiella kommandon som kommer köras när systemet simuleras. Kommandona kommer att bestämma hur värdena på entityns portar kommer ändras över tiden. Processen fungerar på följande sätt: När simuleringen startar är ut signalen, d_out, satt till 0 och processen är aktiv. Processens variabler som står efter ordet variable initieras första körningen till 0. Sen körs raderna i sekventiell ordning rad efter rad. Första sekventiella kommandot testar om clk är 1. Om den är det, så testar nästa if-sats om v_amplified överstiger halva referensspänningen. Om den gör det så uppdateras variabeln stored_d till att sätta en 1:a på utgången annars uppdateras 0:an som variabelvärdet. Efter detta så uppdateras utgången d_out efter 5 ns. När alla dessa sekventiella rader är körda väntar processen inaktiverad på att porten eller signalen som den är känslig för, ska ändra värde. I det här fallet är det clk som styr när processen börjar köras igen. När processen nu körs så börjar den från raden begin efter process-starten och initierar alltså inte om variabeln stored_d. Istället för att göra på det här abstrakta viset så kan man istället beskriva hur motsvarande entity och architecture som vi skrev ovan, skulle se ut om vi istället använde oss av metoden att dela upp allt i olika undersystem. Då ger man istället en strukturell beskrivning av entityns genomförande. En architecture body som enbart består av ihopkopplade underssytem kallas för en structural architectural body. Figuren nedan visar hur man skulle kunna beskriva den 1 bits analog-till-digital omvandlaren som vi använde förut på ett schematiskt sätt: +5 a gain ref 1 2 R1 1kohm OP_förstärkare 3 hal_ref a_amplified 1 2 R2 1kohm komparator 3 gain d clk ff q d_out clk Figur 5 Här har vi alltså skapat motsvarande entity som förut med hjälp av resistorer, en spänningsstyrd förstärkare, en komparator och en D-vippa. För att beskriva detta i VHDL-AMS kan man skriva följande kod: 24
library ieee_proposed; use ieee_proposed.electrical_system.all entity resistor is port( terminal p1, p2 :electrical); end entity resistor; architecture ideal of resistor is quantity v accross i through p1 to p2; constant resistance : real:=10000.0; begin v==i*resistance; end architecture ideal; --------------------------------------- library ieee_proposed; use ieee_proposed.electrical_system.all entity vc_amp is port( quantity g: in voltage; terminal a, o: electrical); end entity vc_amp; architecture ideal of vc_amp is quantity v_in accross a; constant v_out across i_out through o; begin v_out==v_in*g; end architecture ideal; ---------------------------------------- library ieee_proposed; use ieee_proposed.electrical_system.all entity comparator is port( terminal plus, minus: in voltage, signal value: out bit); end entity comparator; architecture ideal of comparator is quantity diff accross plus to minus; begin comp_behavior: process is begin if diff>0.0 then value<='1' after 5 ns; else value<='0' after 5 ns; end if; wait on diff'adove(0.0); end process comp_behavior; end architecture ideal; 25
----------------------------------------- entity d_ff is port( d, clk: in bit; q :out bit); end d_ff; architecture basic of d_ff is begin ff_behavior :process is begin if clk ='1'1 then q<=d after 2 ns; end if; wait on clk; end process ff_behavior; end architecture basic; end architecture ideal; De entities som beskrivs här för resistor, förstärkare, komparator och D-vippa komponenterna liknar den entitety som vi skrev i det första fallet. Resistorns architecture body deklarerar två branch quantity som är associerad med terminals. Quantity v är en across branch quantity och representerar skillnaden i spänning mellan terminals p1 och p2. quantity i är en through branch quantity och representerar strömmen som flyter i resistorn mellan terminals. Den enda beräkning som görs är ohms lag i en simultaneus statement. I förstärkarens architecture body så deklareras branch quantities för spänningen över in och ut terminals och strömmen genom dem. Även här görs beräkningen i simulaneus statement. I architecture body för både komparatorn och D-vippan så används process statements för att beskriva funktionen. I comp_behavior processen i komparatorn så är det signalen diff above(0,0) som styr när processen ska startas. Allstå den signalen som ligger i känslighetslistan. Precis som i vanliga VHDL så kan man även i VHDL-AMS ha flera olika signaler i en process känslighetslista. Signalen diff above(0,0) ändras från falskt till sant när värdet på quantity diff stiger ovan den specificerade gränsen (0,0 i det här fallet) och ändras från sant till falskt när värdet på diff går under samma gräns. Vi använder oss av exakt samma entity som vi hade i första fallet för att binda ihop undersystemen: library ieee_proposed; use ieee_proposed.electrical_system.all entity adc is port( quantity gain : in voltage; terminal a : electrical; signal clk : in bit; signal d_out : out bit); end entity adc; Men till den här entityn så skriver vi en architecture body som beskriver kretsen enligt figur 5. 26