Utveckling av ingångsinterface till tändstyrenheter för naturgas- och biogasmotorer

Development of an Input Interface for Ignition Control Units for Natural Gas and Biogas Engines

Alexander Gramner

Fakulteten för hälsa, natur- och teknikvetenskap

Högskoleingenjör i elektroteknik

C-nivå 22,5 hp

Extern handledare: Styrbjörn Gren, SEM AB

Intern handledare: Peter Röjder

Examinator: Arild Moldsvor

2013-06-12

SAMMANFATTNING

SEM AB utvecklar och tillverkar tändstyrenheter för förbränningsmotorer, bland annatnaturgas- och biogasmotorer. Tändstyrenheterna styr själva tändförloppet när de fåren triggsignal från motorstyrsystemet (ECU). På grund av att enheterna används till-sammans med era olika motorstyrsystem måste de anpassas for olika signaltyper ochcylinderantal. Anpassningar av både mjukvaran och hårdvaran måste göras och dettakräver tid och resurser för utvecklarna på SEM.Syftet med detta arbete är att utveckla ett ingångsinterface till tändstyrenheterna som

möjliggör att de kan anpassas på ett enklare sätt. För att minimera antalet komponenteri tändstyrenheterna ska även funktioner som realiseras med diskreta komponenter, ommöjligt, integreras i ingångsinterfacet.En lämplig programmerbar krets för detta ändamål har valts. Valet blev en MAX V

CPLD (Complex Programmable Logic Device) från Altera. Ingångsinterfacets funktionerhar skapats i form av programkod i Verilog. Slutligen har simuleringar av programmetgjorts och dess funktion har verierats med hjälp av ett utvecklingskort.

i

ABSTRACT

SEM AB develops and manufactures ignition control units for internal combustion engi-nes, including natural gas and biogas engines. The ignition control units control theignition process, when they receive a trigger signal from the engine control unit (ECU).Because these units are used with several dierent ECUs, they must be adapted for dif-ferent signaltypes and number of cylinders. Adaptations of both the software and thehardware must be done and this requires time and resources for the developers at SEM.The purpose of this work is to develop an input interface for the ignition control units

that allow them to be adapted more easily. Also, to minimize the number of componentsin the ignition control units, functions that are realized with discrete components shall,if possible, be integrated in the input interface.A suitable programmable circuit, for the application, has been selected. The selected

circuit was a MAX V CPLD (Complex Programmable Logic Device) from Altera. Thefunctions of the input interface have been created, in the form of Verilog programmingcode. Finally, simulations of the program have been made and its function has beenveried using a development board.

ii

FÖRORD

Jag vill tacka Styrbjörn Gren och Jörgen Bengtsson på SEM AB för den handledning jaghar fått genom hela arbetsprocessen.

iii

FÖRKORTNINGAR

• ASIC Application Specic Integrated Circuit

• CAN Controller Area Network

• CPLD Complex Programmable Logic Device

• ECU Engine Control Unit

• EEPROM Electrically Erasable Programmable Read-Only Memory

• FIR Finite Impulse Response

• FPGA Field-Programmable Gate Array

• HDL Hardware Description Language

• IDE Integrated Drive Electronics

• IIR Innite Impulse Response

• ISP In-System Programming

• ISR Interrupt Service Routine

• MCU Micro Controller Unit

• PWM Pulse-Width Modulation

• RISC Reduced Instruction Set Computer

• SPI Serial Peripheral Interface Bus

• TQFP Thin Quad Flat Package

• UFM User Flash Memory

• VHDL Very-high-speed integrated circuits Hardware Description Language

iv

INNEHÅLL

Kapitel 1 Introduktion 1

1.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Grundidé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Kapitel 2 Teori 4

2.1 Signaltyper för triggning . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Bentliga digitala funktioner . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2.1 Funktion för val av tändspole . . . . . . . . . . . . . . . . . . . . 62.2.2 Funktion för addition av triggsignaler . . . . . . . . . . . . . . . . 6

2.3 Nya digitala funktioner . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4 Arkitekturtyper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.2 CPLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.3 MCU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.4 Mixed signal FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . 9

Kapitel 3 Genomförande 10

3.1 Val av krets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Programspråk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Designverktyg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.4 Material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.5 Programmering av MAX V . . . . . . . . . . . . . . . . . . . . . . . . . . 133.6 Simuleringar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.7 Laborationer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.7.1 Generering av triggsignaler . . . . . . . . . . . . . . . . . . . . . . 143.7.2 Veriering av funktioner . . . . . . . . . . . . . . . . . . . . . . . 16

Kapitel 4 Resultat 18

4.1 Program . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.1 Toppnivå . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.1.2 Modul: inputFilterX6 . . . . . . . . . . . . . . . . . . . . . . . . . 194.1.3 Modul: triggSel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.1.4 Modul: counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.1.5 Modul: moduleSelector . . . . . . . . . . . . . . . . . . . . . . . . 214.1.6 Modul: signalSelectorOutput . . . . . . . . . . . . . . . . . . . . . 224.1.7 Modul: demux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.2 Simuleringar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.2.1 Simuleringar med multitrigg . . . . . . . . . . . . . . . . . . . . . 234.2.2 Simuleringar med referens- och timingsignal . . . . . . . . . . . . 26

4.3 Laborationer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Kapitel 5 Slutsats och diskussion 35

Referenser 37

Bilaga 1 Programkod i Verilog för MAX V CPLD 38

B1.1 Toppnivå . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38B1.2 inputFilterX6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39B1.3 inputFilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40B1.4 triggSel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40B1.5 counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B1.6 moduleSelector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41B1.7 signalSelectorOutput . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44B1.8 demux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Bilaga 2 Blockschema över toppnivå till program för MAX V CPLD 46

Bilaga 3 Funktionssimuleringar av program till MAX V CPLD utan

ingångsfilter 48

vi

KAPITEL 1

Introduktion

1.1 BakgrundSEM AB (hädanefter kallat SEM) utvecklar och tillverkar tändstyrenheter till förbrän-ningsmotorer, bland annat naturgas- och biogasmotorer. Främst används dessa enhetertill motorer i tunga fordon samt stationära motorer för t.ex. generering av elektricitet.Företagets tändstyrenheter styr själva tändförloppet när de får en triggsignal från mo-

torstyrsystemet (ECU). Tändning sker i princip genom att en kondensator först laddasupp till ca. 400 V. Vid tändningstillfället sker en urladdningen från kondensatorn tillen tändspole som genererar en så hög spänning (upp till 40 kV) att en gnista bildas itändstiftet. En tändstyrenhet från SEM kan ses i gur 1.1.SEMs produkter utför avancerade mätningar och beräkningar kontinuerligt för att op-

timera tändförloppet. Ett exempel är ion current sensing där själva tändstiften användssom sensor. Principen är att en spänning appliceras över tändstiftet, efter att gnistan ge-nererats, och strömmen genom det mäts. Magnituden på denna ström är beroende av ettertal parametrar och dess variation ger viktig information om förbränningsprocessen.SEMs tändstyrenheter kan användas tillsammans med era olika motorstyrsystem och

till motorer med upp till 18 cylindrar. Dessa motorstyrsystem använder sig av olikametoder för att signalera att en viss tändspole ska aktiveras. På grund av detta har SEMidag era snarlika produkter där största skillnaden är att de hanterar olika triggsignalerfrån motorstyrsystemet. Varje tändstyrenhet kan hantera upp till 6 tändspolar vilket göratt på motorer med er än 6 cylindrar måste era tändstyrenheter användas.Det skulle vara en stor vinst för SEM om denna mångfald av fysiska produkter kan

minimeras. Idealet är att de endast har en produkt som fungerar till alla olika typer avmotorstyrsystem och motorer. Detta skulle underlätta bl.a. administrering och lagerhåll-ning.

1

1.2. Grundidé 2

Figur 1.1: En tändstyrenhet för gasmotorer från SEM AB.

1.2 GrundidéSEM använder en mikrokontroller (MCU) i sina tändstyrenheter för att styra självatändförloppet och göra mätningar. På grund av att triggsignalerna till MCUn i principkommer direkt från ECUn måste programmet i MCUn anpassas för signaltyp och antalettändspolar. Även kretskorten måste anpassas. Detta kräver tid för utvecklarna på SEMoch de olika produkterna blir svåra att administrera.Grundidén med examensarbetet är att utreda om det är tekniskt möjligt att konstru-

era ett ingångsinterface till produkterna som minimerar skillnaden mellan dem. Dettaingångsinterface ska omvandla olika typer av triggsignaler till en standardsignal. Detskulle medföra att mjukvaran i MCUn inte behöver specialanpassas för de olika produk-terna och det skulle kunna innebära att en enda fysisk produkt kan tillverkas.Det ska även utredas om det skulle vara möjligt att få era tändstyrenheter att arbeta

tillsammans för motorer med er än 6 cylindrar. Idealet skulle vara om detta var möjligtutan att ändra i någon mjukvara. En idé är att kablaget till tändspolarna skiljer sig åt såatt ingångsinterfacet kan identiera till vilka tändspolar den är ansluten (t.ex. tändspole1-6, 7-12 osv).Det ska även utredas om det är möjligt att implementera funktioner som idag rea-

liseras med diskreta komponenter i detta ingångsinterface. Om detta är möjligt skulleantalet komponenter, som måste köpas in och lagerhållas, minskas. Fler komponenteroch lödningar på kretskortet innebär även er potentiella felkällor.

1.3. Metod 3

1.3 MetodMetoden för arbetet är att först utreda vilka nya och bentliga funktioner som är aktu-ella i SEMs framtida produkter. Sedan ska en lämplig arkitektur och krets, som klararav att hantera dessa funktioner, väljas. Valet begränsas av era faktorer t.ex. pris ochtemperaturtålighet. Ett koncept ska tas fram i form av programkod och simuleringar somvisar kretsens funktioner. Funktionerna ska sedan verieras genom att de realiseras på ettutvecklingskort och mätningar ska göras som visar att kretsen fungerar som simulerat.

KAPITEL 2

Teori

2.1 Signaltyper för triggningOlika motorstyrsystem använder sig av olika typer av triggsignaler för att signalera atten viss tändspole ska tändas. Idag behandlar SEMs produkter ICD4 och ICD5 två olikatyper av triggsignaler.Triggsignalen till ICD4 består av en referens- och en timingsignal. Timingsignalen anger

när tändning ska ske på nästa tändspole och referenssignalen indikerar att nästa tänd-ning ska ske på första tändspolen. Figur 2.1 visar ett principiellt tidsdiagram för dennatriggsignal.

Figur 2.1: Ett principiellt tidsdiagram för en referens- och timingsignal.

ICD5 får sju insignaler, en triggsignal för varje tändspole samt en signal från en givarepå kamaxeln. Vad gäller triggsignalerna så ska tändstyrenheten aktivera den tändspolesom motsvaras av respektive triggsignal. Jag har valt att kalla denna signal för mul-titrigg. Figur 2.2 visar ett principiellt tidsdiagram för denna triggsignal.

4

2.2. Befintliga digitala funktioner 5

Figur 2.2: Ett principiellt tidsdiagram för en multitriggsignal.

Signalen från givaren på kamaxeln används för tillfället inte för triggning. Det kanvara möjligt att även använda denna signal som triggsignal, men då behövs någon ti-merfunktion för att detektera tidsluckan i första pulsen. Figur 2.3 visar ett principiellttidsdiagram för denna signal.

Figur 2.3: Ett principiellt tidsdiagram för en signal från kamaxelgivare.

2.2 Befintliga digitala funktionerPå grund av den elektriskt krävande miljön där SEMs produkter används behövs det enmängd skyddselektronik som klarar höga spänningar och eekter. De funktioner dennaelektronik har går inte att realisera i någon programmerbar krets och måste därför nnaskvar i produkterna i form av diskreta komponenter. De funktioner som är möjliga attrealisera i en programmerbar krets är framför allt de som är helt digitala och behandlarsignaler med en logisk spänningsnivå. I produkten ICD4 nns det en funktion med dessaegenskaper och i ICD5 nns det två.

2.2. Befintliga digitala funktioner 6

2.2.1 Funktion för val av tändspole

På grund av ett begränsat antal utgångar från den bentliga MCUn används idag en de-multiplexer och transistorer för att välja vilken tändspole som ska aktiveras. En timing-signal samt en binär kod på tre bitar skickas från MCUn till signalingången respektiveselect-ingångarna på demultiplexern. Den binära koden avgör vilken utgång som väljsför insignalen (timingsignalen). Eftersom timingsignalen är en digital signal skulle dennafunktion vara möjlig att implementera i en programmerbar krets.Det nns dock en multiplexer i produkterna idag som styrs av samma binära kod men

hanterar analoga signaler. Därför går den inte att implementera i en programmerbar kretsoch måste nnas kvar i produkterna och ställas i rätt läge med 3 digitala signaler.Implementationen av den digitala demultiplexern är identisk i båda produkterna och

kräver idag:

• 1 st. demultiplexer.

• 3 st. BJT.

• 10 st. kondensatorer.

• 3 st. resistorer.

• Ca 35 st. lödningar.

2.2.2 Funktion för addition av triggsignaler

Triggsignalen till ICD5 består, som tidigare nämnts, av sex signaler, en för varje tändspo-le, se avsnitt 2.1. Idag skapas en sjunde signal av dessa sex och alla signalerna användssedan av MCUn för att aktivera rätt tändspole vid rätt tidpunkt. Denna sjunde signalskapas i princip genom en addition, eller logiskt sett snarare en eller-grind, mellan allatriggsignalerna. Funktionen implementeras idag med diskreta komponenter men den ärmöjlig att skapa i en programmerbar krets.Implementationen av funktionen med diskreta komponenter kräver idag:

• 3 st. dubbeldioder.

• 2 st. BJT.

• 3 st. resistorer.

• 1 st. kondensator.

• Ca 22 st. lödningar.

2.3. Nya digitala funktioner 7

2.3 Nya digitala funktionerDe nya funktionerna är inte lika väldenierade som de bentliga men det nns någragrundläggande funktioner kretsen ska klara av. Val av signaltyp för triggsignalerna ska gåatt göra genom en digital ingång. När referens- och timingsignal används som triggsignalerska det gå att tilldela kretsen ett modul id med ett antal digitala ingångar. Detta modulid ska ge möjligheten för era tändsstyrenheter att arbeta tillsammans genom att detilldelas olika modul id. T.ex. ska två enheter med modul id 1 av 2 och 2 av 2fungera tillsammans även om triggsignalen till dem är identisk.En timingsignal, d.v.s. en signal med en puls för varje tändningstillfälle, ska även bildas

och skickas till MCUn. Timingsignalen ska bildas oavsett vilken signaltyp som är vald.En intern demultiplexer ska kunna styras med båda signaltyperna och en signal frånMCUn ska demultiplexas ut på någon av utgångarna. Filtrering av insignalerna ska ocksåimplementeras för att eliminera störningar.

2.4 Arkitekturtyper

2.4.1 FPGA

FPGA (Field-programmable gate array) är en integrerad krets som används inom digi-talteknik. Kretsen kan programmeras om på plats, därav namnet Field-programmable.Namnet Gate array beskriver dess uppbyggnad, vilket kan liknas med en matris avenkla logiska block. Vid programmering kopplas dessa logiska block ihop för att bildadigitala funktioner. Hur dessa kopplingar ska ske beskrivs oftast i ett HDL (Hardwaredescription language) som VHDL eller Verilog.Eftersom inget program körs sekventiellt som i en microprocessor kan en FPGA utföra

mängder av parallella processer. En eller era microprocessorer kan däremot implemen-teras i en FPGA med hjälp av en så kallad softcore microprocessor [1]. En FPGA pro-grammeras när den spänningssätts från någon typ av minne (RAM, ROM eller Flash) [2].Det kan antingen vara ett externt minne eller ett inbyggt minne. En FPGA är lämpadför produktion av förhållandevis mindre volymer än en ASIC [2].

2.4.2 CPLD

En CPLD (Complex programmable logic device) är likt en FPGA en programmerbardigital integrerad krets. Det är framförallt uppbyggnaden som skiljer dem åt. En CPLDinnehåller så kallade macroceller som programmeras för olika funktioner [3]. En macrocellär mer komplex än ett av de logiska blocken i en FPGA och kan t.ex. innehålla vippor(ip-ops). Dessa macroceller kopplas sedan ihop och bildar mer avancerade funktioner.En CPLD kan likt en FPGA utföra mänger av parallella processer men uppbyggnadengör att en CPLD har en mer förutsägbar timing än en FPGA [3].

2.4. Arkitekturtyper 8

Generellt sett är en CPLD, trots namnet, mindre komplex än en FPGA och är in-te lika exibel. En CPLD är lämpad för mindre och enklare konstruktioner som t.ex.kombinatorisk logik [4]. Om mer avancerade funktioner ska skapas, t.ex. en komplextillståndsmaskin som en softcore microprocessor, är en FPGA bättre lämpad.En CPLD har sällan heller lika många komponenter som är dedikerade till speciella

uppgifter som t.ex. DSP (Digital Signal Processing). De har oftast inbyggt minne föratt lagra program medan FPGA sällan har det. Det är också vanligt att en CPLD harinbyggd oscillator och bättre drivförmåga än en FPGA [3]. En CPLD är idag generelltsett billigare än en FPGA.

2.4.3 MCU

En mikrokontroller (även kallad MCU) är en dator med processor, minne och kringutrust-ning för in- och utgångar integrerat i en enda komponent. Mikrokontrollers nns i mångaolika modeller och arkitekturer med varierande ordlängd, t.ex. 8, 16 och 32-bit. Någravanliga arkitekturer är PIC, AVR, ARM och MIPS. Det är vanligt med mixed signalMCUs d.v.s. mikrokontrollers med inbyggd ADC och DAC för analoga applikationer [5].Programmeringen av en MCU sker oftast i ett lågnivåspråk som t.ex. C. Programkoden

konverteras till assemblerkod anpassat till den aktuella processorarkitekturen. Assembler-koden konverteras i sin tur till maskinkod som direkt kan tolkas av processorn. Dennamaskinkod består av en sekvens av binära ord som av processorn tolkas som en följd avinstruktioner [6].En MCU har ett begränsat antal instruktioner som används för att t.ex. ytta data

och göra matematiska operationer. Det är vanligt att en MCU är baserad på en såkallad RISC-processor vilket innebär att antalet instruktioner är minimerat till ett fåtalförhållandevis enkla sådana. Detta gör att varje instruktion kan exekveras snabbare ochprestandan ökar [7].Eftersom ett program exekveras sekventiellt av processorn i mikrokontrollern blir de

oförutsägbara i tidskritiska processer. Avbrottshantering är ett sätt komma runt dettaproblem då ett avbrott avbryter aktuell exekvering, kör en så kallad avbrottsrutin (ISR)och sedan återgår till exekveringen som pågick innan avbrottet kom. Ett avbrott kanstartas av t.ex. en stigande ank på en digital ingång, en timer som har nått någotförbestämt värde eller att en analog till digital konvertering är klar [8].Vilka inbyggda funktioner en MCU har varierar beroende på arkitektur och modell

men några vanligt förekommande är [5]:

• RAM för datalagring.

• ROM, EEPROM eller Flash för lagring av program.

• Seriella kommunikationsgränssnitt t.ex. SPI, I2C och CAN.

• PWM generator.

2.4. Arkitekturtyper 9

• Timer.

• Klockkrets.

• ADC och DAC.

• Avbrottshantering.

2.4.4 Mixed signal FPGA

Begreppet mixed signal används för integrerade kretsar som kan hantera både analogaoch digitala signaler. Generellt sett innehåller en sådan krets många olika delar för olikaändamål och kan betraktas som ett SoC [9]. Det är inte ovanligt att de innehåller proces-sor, FPGA, analoga programmerbara in-/utgångar, klockkrets, ashminne m.m. Utbudetav mixed signal FPGAs på marknaden idag är inte speciellt stort och funktionerna skiljersig kraftigt mellan de olika tillverkarnas kretsar. Två av de ledande aktörerna är LatticeSemiconductors och Microsemi. Dessa kretsar är relativt dyra och kostar era hundrakronor styck.

KAPITEL 3

Genomförande

3.1 Val av kretsDet nns för- och nackdelar med alla olika typer av arkitekturer (se avsnitt 2.4) och detberor på applikationen vilken typ som är lämpligast. Mixed signal FPGA har jag valt bortp.g.a. det höga priset och för att de är onödigt komplexa för den aktuella applikationen.De resterande arkitekturerna kan delas upp i två större grenar, MCU och FPGA/CPLD.Grenarna skiljer sig helt och hållet från varandra vad gäller uppbyggnad och funktion.Därför bör först och främst en av dessa grenar väljas. Nedan följer en lista av någraanledningar att använda respektive gren istället för dess motpart.

Anledningar att välja FPGA/CPLD:

+ Generellt sett er in- och utgångar.

+ Kräver ingen klockfrekvens.

+ Går oftast att använda signaler av olika spänningsnivåer.

+ Kan hantera parallella processer.

+ Mer förutsägbar signalfördröjning.

+ Snabbare för kombinatorisk logik.

+ Tillägg eller borttagning av en funktion påverkar inte resten av funktionerna.

Anledningar att välja MCU:

+ Bättre för många matematiska beräkningar.

+ Inbyggda dedikerade funktioner t.ex. ADC, SPI och timer.

10

3.1. Val av krets 11

+ Kräver generellt sett kortare utvecklingstid.

+ Bättre för att skapa många fördröjningar.

+ Mer exibel.

+ Billigare.

De esta funktioner ingångsinterfacet ska klara av att hantera går att realisera med kom-binatorisk logik. FPGA/CPLD lämpar sig därför utmärkt för detta ändamål eftersomdessa inte är beroende av en klockfrekvens. På detta sätt skapas minsta möjliga fördröj-ning från ingång till utgång. Eftersom en demultiplexer också ska realiseras (se avsnitt2.2.1), där insignalen tas från MCUn, ska denna insignal ej påverkas av övriga funktioneri kretsen. Detta kräver att kretsen klarar av att hantera parallella processer och därförlämpar sig en FPGA/CPLD bäst även för detta ändamål.Det rör sig inte om speciellt avancerade funktioner eller matematiska beräkningar i

detta fall och därför är en FPGA onödigt komplex. En CPLD är inte lika komplex ochidag generellt sett billigare än en FPGA. Detta är avgörande vid valet av krets då måletär att välja en så billig krets som möjligt som kan hantera de funktioner och klarar dekrav som ställs.Den fysiska omgivningen ställer också två grundläggande krav på kretsen, tempera-

turtålighet och kapseltyp. SEMs krav på temperaturtålighet är minst -40 +125 C.Kapseln måste vara av en typ som de klarar av att löda med bentlig utrustning.Det nns två stora tillverkare av CPLD, Xilinx och Altera. Altera har en CPLD serie

som heter MAX V som jag anser uppfyller de krav som ställs. Den har även en inbyggdoscillator vilket är en stor fördel då SEM helst vill unvika en extern oscillator. Kretsennns i olika prisklasser beroende på kapacitet, temperaturtålighet och antal in-/utgångar.Komponenten med modellnummer 5M160ZE64A5N anser jag skulle passa bra och härföljer några av dess specikationer:

• Kapsel: 64-TQFP (Thin Quad Flat Package).

• Temperatur (Junction): -40 +125 C.

• Kapacitet: 160 LE (Logical elements).

• Matningsspänning: 1,8 V.

• In-/utgångar: 54 st. De klarar logiska spänningsnivåerna 3,3 V, 2,5 V, 1,8 V, 1,5V, 1,2 V.

• Inbyggd oscillator: 3,9 - 5,3 MHz (varierar för varje enskild komponent).

• Valbar schmitt-trigger och pull-up resistor för varje ingång.

• Valbar open-drain inställning för varje utgång.

3.2. Programspråk 12

• UFM (User Flash Memory): 1 block med 8192 bits.

• Pris: ca. 5,1 USD (33 SEK).

3.2 ProgramspråkFör att beskriva funktionerna av en digital krets används vanligtvis ett programspråk avtypen HDL. De två mest använda programspråken i denna kategori är idag VHDL ochVerilog. Jag har valt att använda Verilog eftersom jag tycker att det har den mest logiskauppbyggnaden och dels för att många syntaxer liknar C som är ett programspråk jag harerfarenhet av.Programmering i ett HDL skiljer sig tankemässigt en del från programmering av mikro-

processorer. Någon som är van att programmera mikroprocessorer har oftast ett sekven-tiellt tankesätt. Vid programmering i HDL skapas istället moduler som i sin tur kankopplas ihop för att skapa större moduler. Detta kan göras i många olika nivåer d.v.s.moduler kan skapas inuti andra moduler. Den översta av dessa nivåer kallas för toppnivå.Vid programmering i HDL bör ett sekventiellt tankesätt ändras till ett parallellt då

programmet inte exekveras av någon processor. Programmet är istället en beskrivningav kretsen funktioner och uppbyggnad.

3.3 DesignverktygAltera har ett designverktyg som heter Quartus II och är anpassat för utveckling avprogram till deras kretsar. Quartus II används även för kompilering och programmering.I Quartus II kan programmeringen ske helt textbaserat, genom att skapa blockschemaneller genom att blanda dessa metoder. En modul kan skapas med hjälp av programkod(Verilog eller VHDL). Av denna modul kan en symboll genereras som sedan kan an-vändas i ett blockschema. Jag har använt programmet Qsim med tillhörande waveformeditor för att simulera de funktioner jag skapat i Quartus II.

3.4 MaterialJag har använt mig av följande material för programmering, simuleringar och laboratio-ner.

• Quartus II Web edition.

• Qsim and Waveform editor.

• MAX V CPLD Development kit.

• Arduino Uno.

3.5. Programmering av MAX V 13

• Oscilloskop, HP 54600A.

• Oscilloskop, Agilent 54622D (Mixed signal)

• Laborationskort (Stripboard).

• Potentiomenter 10 kΩ.

• Tryckknapp.

• 7 st. 2,2 kΩ resistorer.

• 7 st. 3,3 kΩ resistorer.

• 1,2 kΩ resistor.

• 2 st. DIP-switchar med 5 strömbrytare.

• IDE-kablar och kontakter.

• Stiftlister 2,54 mm mellanrum.

• Diverse kopplingstrådar.

3.5 Programmering av MAX VEftersom jag inte hade något att utgå från vad gäller programkod när projektet startadebörjade jag med att skissa på toppnivån. Jag skissade först på två blockscheman medmoduler, ett för varje signaltyp. I detta stadiet hade jag enbart en idé om vad de olikamodulerna skulle genomföra men inte hur de skulle genomföra det.Efter att jag var nöjd med skisserna och ansåg att programmen skulle fungera, när jag

lyckats skapa moduler med de uttänkta funktionerna, började jag fundera på hur dessaskulle realiseras i Verilog. Jag skapade till att börja med ett program för varje signaltyp.När jag ansåg att de båda programmen fungerade korrekt sammanfogade jag dessa tillett.

3.6 SimuleringarFör att simulera programmets funktioner har jag, som nämnts i avsnitt 3.3, använt Qsimmed tillhörande Waveform Editor. Genom att kompilera programmet i Quartus II kanprojektet öppnas i Qsim och simuleras med insignaler som är specicerade i en l som ärskapad i Waveform Editor. En motsvarande l med utsignaler skapas då.Jag började med att göra separata simuleringar för programmen jag hade skapat för

de båda signaltyperna. Till en början hade jag inte med något ingångslter i något av

3.7. Laborationer 14

programmen och därför var ingen klockfrekvens nödvändig. På grund av detta var minaprogram rent kombinatoriska och jag kunde göra simuleringar utan att ta hänsyn tillverkliga tidsramar. När jag var nöjd med simuleringarna för respektive program gjordejag simuleringar för det sammanfogade programmet. Först efter att jag var nöjd meddenna simulering införde jag oscillator och lter på ingångarna.

3.7 LaborationerFör att veriera att programmet fungerar som simulerat använde jag mig av ett utveck-lingskort med en MAX V krets från Altera. Kortet kan ses i gur 3.1. Den MAX V kretssom är integrerad på utvecklingskortet har mer kapacitet och er in- och utgångar änden krets jag rekommenderat i avsnitt 3.1. I övrigt är de båda kretsarna identiska ochdärför påverkas inte resultatet av denna skillnad.

Figur 3.1: Ett MAX V utvecklingskort från Altera.

3.7.1 Generering av triggsignaler

För att generera de olika triggsignalerna använde jag mig av ett mikrokontrollerkort somheter Arduino Uno. Jag valde att använda detta kort eftersom jag redan hade erfarenhetav det. Detta gjorde att jag kunde lägga mer tid på programmet till MAX V utveck-lingskortet och mindre tid på programmering av mikrokontrollern. Enda problemet med

3.7. Laborationer 15

Arduino-kortet var att det använder sig av en 5 V TTL spänningsnivå. MAX V kortetkunde maximalt hantera en spänningsnivå på 3,3 V och detta gjorde att jag var tvungenatt skapa någon slags spänningsnivåkonvertering. På grund av att endast envägskom-munikation från Arduino-kortet till MAX V-kortet var aktuellt blev inte detta någotstörre problem. Den enklaste lösningen var att använda en vanlig spänningsdelning medresistorer för att sänka spänningsnivån.Jag valde att tillverka ett laborationskort till Arduino-kortet, främst för att göra spän-

ningskonverteringen men även för att kunna förändra utsignalen på ett enkelt sätt. Föratt ändra frekvens på utsignalen använde jag en potentiometer och för att ändra signal-typ användes en tryckknapp. Jag använde även en DIP-switch, som egentligen inte harnågot att göra med mikrokontrollern utan används till att ställa några ingångar på MAXV kortet i olika tillstånd. Alla komponenter och kontakter lödde jag på ett laborations-kort. En Arduino Uno med laborationskort kan ses i gur 3.3 och kopplingschema förlaborationskortet kan ses i gur 3.2.

Figur 3.2: Kopplingsschema för laborationskortet för generering av triggsignaler.

3.7. Laborationer 16

Figur 3.3: En Arduino Uno med laborationskort för generering av triggsignaler.

3.7.2 Verifiering av funktioner

MAX V utvecklingskortet har två stycken integrerade lysdioder. Jag började med attanvända dessa dioder för att veriera att insignalerna från mikrokontrollern hanteradespå rätt sätt och att en timingsignal kunde skapas. Genom detta test kunde jag ävendra slutsatsen att ingångsltren och den interna oscillatorn fungerade eftersom ltreninte släpper igenom några signaler utan en klockfrekvens. När jag hade bekräftat attprogrammet fungerade som planerat tillverkade jag ett kretskort för mätning som jagkopplade in på utgångarna på utvecklingskortet.Jag mätte sedan utsignalerna med hjälp av era oscilloskop. För att kunna mäta med

era oscilloskop samtidigt använde jag en extra timingsignal från mikrokontrollern somextern trigger till samtliga oscilloskop. Eftersom jag behövde mäta på ca. 16 signalersamtidigt blev denna metod besvärlig då jag endast hade tillgång till oscilloskop med2 kanaler. Jag ck därför låna ett Agilent 54622D mixed signal oscilloskop av SEMsom har 16 digitala samt 2 analoga kanaler. Detta oscilloskop underlättade mätningarnaavsevärt då jag kunde se alla signaler på en och samma oscilloskopbild. Figur 3.4 visar enuppkoppling av mikrokontrollern, MAX V utvecklingskortet och laborationskorten medmätprober till Agilent-oscilloskopet.

3.7. Laborationer 17

Figur 3.4: Uppkoppling av mätutrustning för veriering av programfunktioner.

KAPITEL 4

Resultat

4.1 Program

4.1.1 Toppnivå

Grundtanken med programmet är att det enkelt ska gå att anpassa för olika insignalstyperoch antal tändstyrenheter. Denna anpassning ska gå att göra genom att ställa ett antalingångar höga eller låga. Jag har valt att använda en bit för att beskriva signaltypenoch fyra bitar för att beskriva modul id. Med modul id menar jag, i fallet där eratändstyrenheter arbetar tillsammans, det totala antalet tändsstyrenheter samt vilkentändstyrenhet interfaceenheten i fråga sitter i. Detta är nödvändig information för attkunna hantera en referens- och timingsignal (se gur 2.1 på sidan 4) för fallet då antalettändspolar överstiger sex. Sex är det maximala antalet tändspolar en tändstyrenhet kanhantera.Toppnivån är delad i två huvuddelar, en för varje signaltyp. Se bilaga 2 för ett komplett

blockschema över toppnivån och bilaga 1 för programkod i Verilog för samtliga moduler.Figur 4.1 visar endast alla ingångar och utgångar till toppnivån. Notationen [A..0]betyder en vektor med A+1 bitar där nummer A är den mest signikanta biten ochnummer 0 den minst signikanta biten. Nedan följer en förklaring av samtliga in- ochutsignaler.

• triggIn (6 bitar) - Triggsignalerna från motorstyrsystemet. Om alla 6 kanaler an-vänds beror på signaltyp.

• signalType (1 bit) - Med denna bit bestäms signaltypen.

• moduleId (4 bitar) - De första två bitarna anger vilken tändstyrenhet ingångsin-terfacet sitter i och de två sista det totala antalet tändstyrenheter. T.ex. betyder1011 tändstyrenhet 2 av 3.

18

4.1. Program 19

• timingInFromMCU (1 bit) - Timingsignalen från MCUn som anger när tändningska ske. Denna signal är insignal till den interna demultiplexern.

• enableMux (1 bit) - Via denna bit kan den interna demultiplexern helt stängas avoch därmed stänga av alla utgångar (triggOut) oberoende av timingInFromMCU.Meningen med denna signal är att MCUn ska kunna stänga av alla ingångsinterfa-cets utgångar med hjälp av en digital utgång.

• triggOut (6 bitar) - Utsignalerna från den interna demultiplexern.

• timingOutToMCU (1 bit) - Via denna utgång skickas timingsignalen till MCUn.

• analogMux (3 bitar) - Idag används en analog demultiplexer för att styra olikamätsignaler till MCUn beroende på vilken tändspole som är aktiv. På grund avatt den hanterar analoga signaler kan den ej realiseras i ingångsinterfacet. Därförbehövs dessa tre bitar för att ställa den i rätt läge.

Figur 4.1: Alla ingångar och utgångar för toppnivån av programmet.

4.1.2 Modul: inputFilterX6

Denna modul tar 6 insignaler samt en klocksignal och bildar 6 utsignaler. Modulen l-trerar alla insignalerna från eventuella spikar men skapar dock en viss fördröjning. Dettaåstadkoms genom att en räknare räknar ner från ett förbestämt värde och sparar in-signalernas senaste tillstånd. Dessa tillstånd jämförs kontinuerligt med de nuvarandetillstånden. Om något tillstånd har ändrats börjar räknaren om. Om tillstånden inte harändrats och räknaren kommit till noll skickas insignalerna till respektive utgång. Medandra ord så ltreras snabba variationer av insignalerna bort. Detta sätt att ltrera ensignal kräver inga avancerade matematiska beräkningar och är därför mycket mindreresurskrävande för en CPLD än DSP algoritmer som FIR eller IIR.

4.1. Program 20

Modulen inputFilter fungerar på samma sätt som denna modul men hanterar endasten signal. Figur 4.2 visar alla ingångar och utgångar för modulen.

Figur 4.2: Alla ingångar och utgångar för modulen inputFilterX6.

4.1.3 Modul: triggSel

Modulen används endast när multitrigg används. Denna modul har 6 ingångar för trigg-signalerna och 1 ingång för en klocksignal. Det binära talet på de 3 utgångarna motsvararnumret på den ingången som senast ck en triggsignal. Sirorna 0 5 motsvarar ingång-arna 1 6. Modulen har en minnesfunktion i form av att utgångarna endast ändrartillstånd vid positiv ank på klocksignalen om ingångarna stämmer överens med någraförutbestämda bitmönster. I alla andra fall behåller utgångarna sina tillstånd. Med andraord så sparar modulen numret på den senast aktiva ingången på utgångarna i form avett binärt tal. Figur 4.3 visar alla ingångar och utgångar för modulen.

Figur 4.3: Alla ingångar och utgångar för modulen triggSel.

4.1.4 Modul: counter

Denna modul är en vanlig binär räknare med reset- och klockingång. Den ändrar tillståndendast vid positiv ank på någon av ingångarna. De 5 utgångarna symboliserar ett binärt

4.1. Program 21

tal på 5 bitar med utgångsvärdet 0. Vid positiv ank på klockingången ökar räknarenmed ett och utgångarna uppdateras. När reset-ingången får en positiv ank nollställsräknaren. Figur 4.4 visar alla ingångar och utgångar för modulen.

Figur 4.4: Alla ingångar och utgångar för modulen counter.

4.1.5 Modul: moduleSelector

Om referens- och en timing är vald som signaltyp används denna modul. Modulen är rentkombinatorisk och har 10 st. ingångar varav 5 st. för insignaler i form av ett binärt tal. FörmoduleId har den 4 ingångar och den sista ingången är för timingsignalen. Utsignalernafrån modulen är ett binärt tal på 3 bitar samt en timingsignal. Dess funktion är att ltrerabort vissa pulser av timingsignalen beroende på moduleId ingångarnas tillstånd.I programmet åstadkoms detta genom att jämföra insignalerna samt moduleId med

förbestämda fall. Resultatet i form av utsignalerna och timingsignalen är också förbe-stämda för samtliga fall. Om bitmönstret på moduleId ingången inte stämmer överensmed något av fallen som är specicerade sätts utgångarna till ett tillstånd som i slutändanresulterar i att alla utgångar från ingångsinterfacet stängs av.Alla möjliga fall är täckta och det resulterar i en rent kombinatorisk modul. Modulen

är den mest resurskrävande av samtliga som ingår i ingångsinterfacet. Figur 4.5 visar allaingångar och utgångar för modulen.

4.1. Program 22

Figur 4.5: Alla ingångar och utgångar för modulen moduleSelector.

4.1.6 Modul: signalSelectorOutput

Denna modul fungerar som en slags multiplexer med två grupper av insignaler, en gruppvardera för de båda signaltyperna. Antalet ingångar är 9 varav 8 för insignalsgrupperna(4 st. per grupp). Den sista ingången används för val av signaltyp, antingen multitriggeller referens- och timingsignal. Modulens funktion är att koppla en av de två gruppernatill utgångarna beroende på om ingången för signaltyp är ställd till 0 eller 1. Figur 4.6visar alla ingångar och utgångar för modulen.

Figur 4.6: Alla ingångar och utgångar för modulen signalSelectorOutput.

4.1.7 Modul: demux

Denna modul är, som namnet antyder, en demultiplexer. En insignal från MCUn demul-tiplexas ut på någon av utgångarna beroende av bitmönstret på select ingångarna. Denbinära representationen av talet 0 motsvarar utgång 0, talet 1 motsvarar utgång 1 o.s.v.Figur 4.7 visar alla ingångar och utgångar för modulen.

4.2. Simuleringar 23

Figur 4.7: Alla ingångar och utgångar för modulen demux.

4.2 SimuleringarJag har gjort simuleringar med och utan ingångslter. I simuleringarna med ingångsl-ter har jag lagt till störningar i form av korta pulser för att veriera att ingångsltrenfungerar. Jag har enbart gjort funktionssimuleringar och därför är simuleringarna inteanpassade till verkliga tidsförhållanden. Detta medför att klocksignalen i simuleringarnamåste ha en mycket högre frekvens än den verkliga oscillatorn på ca. 5 MHz. Resultatethar dock ej påverkats av detta. Nedan följer resultaten av simuleringar med ingångslter.Se bilaga 3 för simuleringar utan ingångslter.

4.2.1 Simuleringar med multitrigg

Figur 4.8 visar en simulering med multitrigg-signaler. Timingsignalerna är fördröjda pågrund av ingångsltret men fördröjningen är överdriven för att visa ltrets funktion.Fördröjningen är så påtaglig för att störningspulserna är långa relativt triggpulserna.TriggOut signalerna är pulser som betecknas med U vilket betyder att signalerna kan

vara antingen 0 eller 1 vid dessa tidpunkter. Det är på detta vis eftersom triggOut signa-lerna är beroende av timingInFromMCU signalen och denna är odenierad. Med andraord betyder detta att timingInFromMCU signalen demultiplexas ut på någon av triggOututgångarna. Signalen analogMux visas som en decimal representation av bitmönstret pådess tre utgångar.

4.2. Simuleringar 24

Figur 4.8: Simulering med multitrigg som insignal.

Figur 4.9 visar enbart att det är möjligt att hoppa över vissa pulser. T.ex. kanske det,av någon anledning, är önskat att endast tända varannan tändspole.I gur 4.10 demonstreras enableMux-signalens funktion. När denna signal sätts till

0 resulterar det i att alla triggOut utgångar blir 0 oberoende av timingInFromMCU-signalen.

4.2. Simuleringar 25

Figur 4.9: Simulering med multitrigg, men med överhoppade pulser, som insignal.

Figur 4.10: Simulering för demonstrering av enableMux-signalens funktion.

4.2. Simuleringar 26

4.2.2 Simuleringar med referens- och timingsignal

Figur 4.11 visar en simulering med en referens- och timingsignal i fallet med 6 tändspolar,d.v.s. en enda tändstyrenhet. Signalen signalType är satt till 1 vilket innebär att enhetenär inställd för att hantera just en referens- och timingsignal. Några störningspulser ärtillagda för att demonstrera ingångsltrens funktion även i detta fall. Signalen moduleIdär satt till 0101 vilket betyder att enheten agerar modul 1 av 1 (se avsnitt 4.1).

Figur 4.11: Simulering med referens- och timingsignal för 6 tändspolar.

Figur 4.12 visar också en simulering med en referens- och timingsignal men dennagång för fallet med 12 tändspolar. Enheten är inställd att agera modul 1 av 2 eftersommoduleId är ställd till 0110. På grund av detta hanterar enheten endast varannan pulsav timingsignalen och första pulsen efter referenspulsen är en av dem.

4.2. Simuleringar 27

Figur 4.12: Simulering med referens- och timingsignal för 12 tändspolar och modulId ställd till

0110 (1 av 2).

OmmoduleId istället ställs till 1010 d.v.s. enheten är inställd att agera modul 2 av 2 blirresultatet motsatt. Detta kan ses i gur 4.13. På detta sätt kan två enheter med moduleId0110 och 1010 arbeta tillsammans eftersom alla pulser i timingsignalen behandlas menav två olika enheter.Figur 4.14, 4.15 och 4.16 visar de tre motsvarande fallen för 18 tändspolar med de olika

moduleId inställningarna 0111 (1 av 3), 1011 (2 av 3) och 1111 (3 av 3).

4.2. Simuleringar 28

Figur 4.13: Simulering med referens- och timingsignal för 12 tändspolar och modulId ställd till

1010 (2 av 2).

Figur 4.14: Simulering med referens- och timingsignal för 18 tändspolar och modulId ställd till

0111 (1 av 3).

4.2. Simuleringar 29

Figur 4.15: Simulering med referens- och timingsignal för 18 tändspolar och modulId ställd till

1011 (2 av 3).

Figur 4.16: Simulering med referens- och timingsignal för 18 tändspolar och modulId ställd till

1111 (3 av 3).

4.3. Laborationer 30

4.3 LaborationerFör att göra resultatet från laborationerna lättöverskådligt har jag försökt få oscillo-skopskärmen att likna gurerna från avsnitt 4.2 så mycket som möjligt. Det gör detlättare att jämföra resultatet från de verkliga mätningarna och simuleringarna.Figurerna i detta avsnitt är direkta skärmdumpar från Agilent 54622D oscilloskopet.

Jag hade dock bara 16 kanaler till mitt förfogande och kunde därför inte mäta på samtligasignaler som jag har med i simuleringarna. Därför valde jag bort moduleId, signalTypeoch enableMux eftersom dessa är signaler som ställs in manuellt med DIP-switchar.Första mätningarna med multitrigg gav ett resultat som inte stämde överens med si-

muleringarna. Utsignalerna från demultiplexern, betecknade med OUT i samtliga gurer,var endast höga när respektive ingång var hög. Jag drog slutsatsen att det måste varaproblem med triggSel modulen. Utgångarna från modulen uppdaterades på stigande ankför någon av ingångarna men det visade sig att detta inte var optimalt, mest troligt p.g.a.att det resulterade i att en latch skapades i hårdvaran. Jag skrev om programkoden förmodulen så att den istället använde sig av den inbyggda oscillatorn för att uppdaterautgångarna. Detta löste problemet och programmet fungerade som simulerat.Signalen timingInFromMCU tas från mikrokontrollern och är konsekvent hög i alla

mätningar för att visa när triggOut utgångarna är aktiva. Figur 4.17 visar en mätningmed multitrigg som signaltyp.

Figur 4.17: Laboration med multitrigg som insignal.

I gur 4.18 används en referens- och timingsignal för 6 tändspolar som triggsignal.Signalen signalType är ställd till 1 och moduleId till 0101 d.v.s. modul 1 av 1. Signalerna

4.3. Laborationer 31

AMUX02, där AMUX0 är den minst signikanta biten, är signalerna till den analogamultiplexern. Dessa signaler motsvarar numret på den för tillfället aktiva utgången omde tolkas som ett binärt tal.

Figur 4.18: Laboration med referens- och timingsignal för 6 tändspolar.

Figur 4.19 och 4.20 visar mätningar med en referens- och timingsignal för 12 tändspolar.I båda gurerna är signalType ställd till 1 men i gur 4.19 är moduleId ställd till 0110och i gur 4.20 till 1010.Det uppkom några mycket korta pulser på några av kanalerna under mätning med

Agilent oscilloskopet. Dessa var så pass korta att jag inte kunde bestämma längden pådem trots att jag zoomade in oscilloskopbilden kraftigt. När jag mätte på kanalerna medett annat oscilloskop med analoga kanaler fanns det inga spår av pulserna. Jag märkteäven att er pulser uppstod om jag rörde på kablarna till mätproberna. På grund av dettadrog jag slutsatsen att det var störningar eller överhörning i kablaget som genereradedessa pulser.

4.3. Laborationer 32

Figur 4.19: Laboration med referens- och timingsignal för 12 tändspolar och modulId ställd till

0110 (1 av 2).

Figur 4.20: Laboration med referens- och timingsignal för 12 tändspolar och modulId ställd till

1010 (2 av 2).

De tre fallen med referens- och timingssignal för 18 tändspolar visas i gur 4.21, 4.22och 4.23. I samtliga fall är signalType ställd till 1 men moduleId inställningen skiljer sig.

4.3. Laborationer 33

I gur 4.21 är moduleId ställd till 0111, i gur 4.22 till 1011 och i gur 4.23 till 1111.

Figur 4.21: Laboration med referens- och timingsignal för 18 tändspolar och modulId ställd till

0111 (1 av 3).

Figur 4.22: Laboration med referens- och timingsignal för 18 tändspolar och modulId ställd till

1011 (2 av 3).

4.3. Laborationer 34

Figur 4.23: Laboration med referens- och timingsignal för 18 tändspolar och modulId ställd till

1111 (3 av 3).

KAPITEL 5

Slutsats och diskussion

Detta arbete visar att och hur det är möjligt att skapa en krets som, på ett enkelt sätt,går att anpassa för olika signaltyper. Det är självfallet möjligt att utöka programmet förer typer av signaler om det är önskat. På grund av en CPLDs uppbyggnad skulle dessatillägg inte påverka de bentliga funktionerna.Det visas även att och hur det är möjligt att få era tändstyrenheter att arbeta till-

sammans, genom att tilldela varje enhet ett id, trots att de får samma insignal. Hur dettaid ska tilldelas är då nästa fråga. En idé är att använda kablaget till tändspolarna, vianågon bygling, för att utföra detta. Ett annat alternativ är att göra det med byglingar,lödningar eller strömställare på kretskortet. Det skulle även vara möjligt att användamikrokontrollern för detta, antingen via några digitala utgångar eller via en seriell data-buss. En SPI-controller skulle t.ex. kunna implementeras i CPLDn för att kommuniceramed MCUn.Det smidigaste sättet skulle nog vara att kablaget till tändspolarna bestämmer id,

då skulle inte tändstyrenheterna behöva kongureras innan de kopplas in. På liknandesätt skulle det gå att låta kablaget till motorstyrsystemet, via någon bygling, bestämmasignaltypen. Vinsten med detta skulle vara att identiska tändstyrenheter kan levererastill kunder med olika motorer och så länge kablaget till tändspolarna är korrekt tillverkatskulle enheterna fungera direkt vid inkoppling.Det skulle vara önskvärt att minska antalet diskreta komponenter på kretskorten i och

med införandet av ingångsinterfacet. Om detta är möjligt är svårt att förutsäga utan attskapa ett fungerande kretsschema men en grov uppskattning kan göras. De komponen-ter som skulle kunna plockas bort från kretskortet är framförallt de som används för debentliga digitala funktionerna (se avsnitt 2.2). Till dessa funktioner används 17 kompo-nenter och 35 lödningar för ICD4 och 26 komponenter och 57 lödningar för ICD5. Antalkomponenter som tillkommer vid införandet av ingångsinterfacet är svårare att uppskattamen det som är säkert är, en MAX V CPLD (5M160ZE64A5N) som kräver 64 lödningarsamt någon 1,8 V spänningsregulatorkrets för att driva CPLDn. En sådan krets skullet.ex. kunna bestå av 2 kondensatorer och en spänningsregulator d.v.s. 3 komponenter

35

36

och 7 lödningar.Största vinsten med ingångsinterfacet är inte att antalet komponenter kan minskas utan

att en enda typ av modul skulle kunna användas för ett stort antal tillämpningar. MCUnskulle enbart behöva styra tändförloppet när den får en timingpuls från ingångsinterfacetoch behöver inte hålla reda på vilken tändspole som ska tändas vid nästa puls. Program-met i MCUn kan vara mer eller mindre identiskt i produkterna och kan därmed optimerasför att styra själva tändförloppet istället. In- och utgångar på MCUn skulle även frigörasoch istället kunna användas för andra funktioner. Om endast en programvara till MCUnbehöver administreras och utvecklas skulle tid och pengar kunna sparas.

REFERENSER

[1] S. Åke Andersson, Four soft-core processors for embedded systems.http://www.eetimes.com/design/microcontroller-mcu/4404578/

Four-soft-core-processors-for-embedded-systems, 2013. [Online; 2013-03-01].

[2] Wikipedia, Field-programmable gate array. http://sv.wikipedia.org/wiki/

Field-programmable_gate_array, 2013. [Online; 2013-02-06].

[3] Wikipedia, Complex programmable logic device. http://sv.wikipedia.org/

wiki/Complex_programmable_logic_device, 2013. [Online; 2013-02-06].

[4] Wikipedia, Programmable logic device. http://en.wikipedia.org/wiki/

Programmable_logic_device, 2013. [Online; 2013-03-01].

[5] Wikipedia, Microcontroller. http://en.wikipedia.org/wiki/Microcontroller,2013. [Online; 2013-02-09].

[6] Wikipedia, Maskinkod. http://sv.wikipedia.org/wiki/Maskinkod, 2013. [Onli-ne; 2013-02-09].

[7] Wikipedia, Reduced instruction set computing. http://en.wikipedia.org/wiki/Reduced_instruction_set_computing, 2013. [Online; 2013-02-09].

[8] www.embedds.com, Basic understanding of microcontroller interrupts. http:

//www.embedds.com/basic-understanding-of-microcontroller-interrupts,2010. [Online; 2013-02-09].

[9] Wikipedia, Field-programmable gate array. http://en.wikipedia.org/wiki/

Field-programmable_gate_array, 2013. [Online; 2013-02-06].

37

BILAGA 1

Programkod i Verilog för MAX VCPLD

B1.1 Toppnivå

1 module Inpu t In t e r f a c e3 ( t r i gg In , s ignalType , moduleId , tr iggOut , timingOutToMCUinverted ,timingOutToMCU , timingInFromMCU , enableMux , enableMuxOut , analogMux ) ;

2

3 parameter ST1 = 1 ' b0 ; // S igna l type pattern to s e l e c t "Mu l t i t r i g g " .4 parameter ST2 = 1 ' b1 ; // S igna l type pattern to s e l e c t "Reference and timing " .5

6 /∗ Bi tpa t t e rn s f o r i d e n t i f y i n g d i f f e r e n t module IDs ∗/7 parameter BP1_1 = 4 ' b0101 ; //Module 1/18 parameter BP1_2 = 4 ' b0110 ; //Module 1/29 parameter BP1_3 = 4 ' b0111 ; //Module 1/3

10 parameter BP2_2 = 4 ' b1010 ; //Module 2/211 parameter BP2_3 = 4 ' b1011 ; //Module 2/312 parameter BP3_3 = 4 ' b1111 ; //Module 3/313

14 parameter FILTER_BITS_TIMING = 6 ; //Number o f b i t s f o r the input f i l t e r i n g o f thetimingInFromMCU s i g n a l .

15 parameter FILTER_LENGTH_TIMING = 63 ; //Max: 2^FILTER_BITS_TIMING − 116 parameter FILTER_BITS_TRIGG = 6 ; //Number o f b i t s f o r the input f i l t e r i n g o f the t r i g g I n

s i g n a l s .17 parameter FILTER_LENGTH_TRIGG = 63 ; //Max: 2^FILTER_BITS_TRIGG − 118

19 input [ 5 : 0 ] t r i g g I n ;20 input signalType , timingInFromMCU , enableMux ;21 input [ 3 : 0 ] moduleId ;22 output [ 5 : 0 ] tr iggOut ;23 output timingOutToMCUinverted , timingOutToMCU , enableMuxOut ;24 output [ 2 : 0 ] analogMux ;25

26 wire timingMulti , timingRefTim , timingInFromMCUFiltered ;27 wire [ 5 : 0 ] t r i g g I nF i l t e r e d ;28 wire [ 2 : 0 ] co i lNrMult i , coilNrRefTim , co i lNr ;29 wire [ 4 : 0 ] counterValue ;30 wire osc_sig ;31

32 osc osc_inst ( . oscena (1 ' b1 ) , . osc ( osc_sig ) ) ; // I n i t i a t i o n o f i n t e r n a l o s c i l l a t o r f o rMAX V och MAX I I dev i c e s

38

B1.2. inputFilterX6 39

33

34 i nputF i l t e rX6 #(FILTER_BITS_TRIGG,FILTER_LENGTH_TRIGG) i f 1 ( . in ( t r i g g I n ) , . c l k ( osc_sig ) ,. out ( t r i g g I nF i l t e r e d ) ) ;

35

36 // a s s i gn t r i g g I nF i l t e r e d = t r i g g I n ; // I f no f i l t e r i s needed f o r t r i g g s i g n a l s .37

38 i n pu tF i l t e r #(FILTER_BITS_TIMING,FILTER_LENGTH_TIMING) i f 2 ( . in ( timingInFromMCU) , . c l k (osc_sig ) , . out ( timingInFromMCUFiltered ) ) ;

39

40 // a s s i gn timingInFromMCUFiltered = timingInFromMCU ; // I f no f i l t e r i s needed f o r t imings i g n a l .

41

42 a s s i gn t imingMult i = | t r i g g I nF i l t e r e d ; // OR−gate between mult iTr igg s i g n a l s to c r e a t e at iming s i g n a l .

43

44 t r i g g S e l t r i g g S e l ( . in ( t r i g g I nF i l t e r e d ) , . out ( co i lNrMul t i ) , . c l k ( osc_sig ) ) ;45

46 counter counter ( . c l k ( t r i g g I nF i l t e r e d [ 1 ] ) , . r e s e t ( t r i g g I nF i l t e r e d [ 0 ] ) , . count (counterValue ) ) ;

47

48 moduleSe lector #(BP1_1,BP1_2,BP1_3,BP2_2,BP2_3,BP3_3) moduleSe lector ( . in ( counterValue ) ,. t imingIn ( t r i g g I nF i l t e r e d [ 1 ] ) , . moduleId (moduleId ) , . out ( coilNrRefTim ) , . timingOut (timingRefTim ) ) ;

49

50 s i gna lSe l e c to rOutput #(ST1 , ST2) s i gna lSe l e c to rOutput ( . inNrMulti ( co i lNrMul t i ) , .inNrRefTim ( coilNrRefTim ) , . inTimMulti ( t imingMult i ) , . inTimRefTim ( timingRefTim ) , .outNr ( co i lNr ) , . outTim(timingOutToMCU) , . s ignalType ( s ignalType ) ) ;

51

52 a s s i gn timingOutToMCUinverted = ~timingOutToMCU ; //Only f o r monitor ing the t iming s i g n a lwith one o f the LEDs on the developement card .

53 a s s i gn enableMuxOut = ~enableMux ; //Only f o r monitor ing the enableMux s i g n a l with one o fthe LEDs on the developement card .

54 a s s i gn analogMux = co i lNr ; // Bi tpat te rn to s e t the ex t e rna l analog mux .55

56 demux demux ( . in ( timingInFromMCUFiltered ) , . s e l e c t ( co i lNr ) , . out ( tr iggOut ) , . enable (enableMux ) ) ;

57

58 endmodule

B1.2 inputFilterX6

1 module inputF i l t e rX6 ( in , c lk , out ) ;2

3 input [ 5 : 0 ] in ;4 input c l k ;5 output [ 5 : 0 ] out ;6

7 parameter BITSIZE = 3 ;8 parameter FILTERWIDTH = 7 ;9 reg [ BITSIZE−1:0 ] counter ;

10 reg [ 5 : 0 ] prev_sample , out ;11

12 always @ ( posedge c l k )13 begin14 i f ( in != prev_sample )15 begin16 counter <= FILTERWIDTH;17 end18 e l s e i f ( counter != 0)

B1.3. inputFilter 40

19 begin20 counter <= counter − 1 ' b1 ;21 end22 e l s e23 begin24 out <= prev_sample ;25 end26 prev_sample = in ;27 end28 endmodule

B1.3 inputFilter

1 module i n pu tF i l t e r ( in , c lk , out ) ;2

3 input in , c l k ;4 output out ;5

6 parameter BITSIZE = 3 ;7 parameter FILTERWIDTH = 7 ;8 reg [ BITSIZE−1:0 ] counter ;9 reg prev_sample , out ;

10

11 always @ ( posedge c l k )12 begin13 i f ( in != prev_sample )14 begin15 counter <= FILTERWIDTH;16 end17 e l s e i f ( counter != 0)18 begin19 counter <= counter − 1 ' b1 ;20 end21 e l s e22 begin23 out <= prev_sample ;24 end25 prev_sample = in ;26 end27 endmodule

B1.4 triggSel

1 /∗2 | This module ac t s on r i s i n g edge o f the c l k s i g n a l and3 | s e t s the output to a number cor re spond ing to the a c t i v e4 | input . I f more than one input i s a c t i v e or none o f the5 | inputs are a c t i v e the module won ' t change i t s s t a t e .6 ∗/7

8 module t r i g g S e l ( in , out , c l k ) ;9 input [ 5 : 0 ] in ;

10 input c l k ;11 output [ 2 : 0 ] out ;12 reg [ 2 : 0 ] out ;

B1.5. counter 41

13 always @ ( posedge c l k )14 begin15 case ( in )16 6 ' b000001 : out <= 3 ' b000 ;17 6 ' b000010 : out <= 3 ' b001 ;18 6 ' b000100 : out <= 3 ' b010 ;19 6 ' b001000 : out <= 3 ' b011 ;20 6 ' b010000 : out <= 3 ' b100 ;21 6 ' b100000 : out <= 3 ' b101 ;22 endcase23 end24 endmodule

B1.5 counter

1 /∗2 | This module ac t s on p o s i t i v edges on any o f the inputs ( c l k or r e s e t ) .3 | I f a the r e s e t port i s a c t i v the next p o s i t i v edge on the c l k port4 | w i l l r e s e t the counter . Otherwise the counter w i l l increment by one5 | f o r every p o s i t i v e edge on c l k port .6 ∗/7

8 module counter ( c lk , r e s e t , count ) ;9 input c lk , r e s e t ;

10 output [ 4 : 0 ] count ;11 reg [ 4 : 0 ] count ;12 reg r e s ;13 always @( posedge c l k or posedge r e s e t )14 begin15 i f ( r e s e t )16 begin17 r e s <= 1 ' b1 ;18 end19 e l s e20 begin21 i f ( r e s )22 begin23 r e s <= 1 ' b0 ;24 count <= 5 ' b00000 ;25 end26 e l s e27 begin28 count <= count + 1 ' b1 ;29 end30 end31 end32 endmodule

B1.6 moduleSelector

1 /∗2 | This module takes a 5 b i t number on the input and re tu rn s a 3 b i t3 | number on the output . The value on the output depends on the s t a t e4 | o f the moduleId b i t s . The p r e s e t pat t e rns f o r moduleId the module5 | a c t s on are s e t as parameters BPx_x. The t imingIn s i g n a l are passed

B1.6. moduleSelector 42

6 | through the module to the timingOut port in some ca s e s and blocked7 | in other ca s e s . Ex . BP1_3 (Module 1 o f 3) are read at moduleId port :8 | " out" w i l l be 1/3 o f " in " ( i n t e g e r ) and timing s i g n a l w i l l pass9 | through on 0 ,3 ,6 ,9 ,12 ,15 and blocked otherwi s e .

10 ∗/11

12 module moduleSe lector ( in , t imingIn , moduleId , out , timingOut ) ;13

14 parameter BP1_1 = 4 ' b0101 ; //Module 1/115 parameter BP1_2 = 4 ' b0110 ; //Module 1/216 parameter BP1_3 = 4 ' b0111 ; //Module 1/317 parameter BP2_2 = 4 ' b1010 ; //Module 2/218 parameter BP2_3 = 4 ' b1011 ; //Module 2/319 parameter BP3_3 = 4 ' b1111 ; //Module 3/320

21 input [ 4 : 0 ] in ;22 input t imingIn ;23 input [ 3 : 0 ] moduleId ;24 output [ 2 : 0 ] out ;25 output timingOut ;26

27 reg [ 2 : 0 ] out ;28 reg timingOut ;29

30 always @ ( in [ 0 ] or in [ 1 ] or in [ 2 ] or in [ 3 ] or in [ 4 ] or t imingIn or moduleId [ 0 ] ormoduleId [ 1 ] or moduleId [ 2 ] or moduleId [ 3 ] )

31 begin32

33 i f ( moduleId == BP1_1)34 begin35 timingOut <= timingIn ;36 case ( in )37 5 ' d0 : out <= 3 ' d0 ;38 5 ' d1 : out <= 3 ' d1 ;39 5 ' d2 : out <= 3 ' d2 ;40 5 ' d3 : out <= 3 ' d3 ;41 5 ' d4 : out <= 3 ' d4 ;42 5 ' d5 : out <= 3 ' d5 ;43 de f au l t : out <= 3 ' d6 ;44 endcase45 end46

47 e l s e i f ( moduleId == BP1_2)48 begin49 case ( in )50 5 ' d0 : begin out <= 3 ' d0 ; timingOut <= timingIn ; end51 5 ' d1 : begin out <= 3 ' d0 ; timingOut <= 1 ' b0 ; end52 5 ' d2 : begin out <= 3 ' d1 ; timingOut <= timingIn ; end53 5 ' d3 : begin out <= 3 ' d1 ; timingOut <= 1 ' b0 ; end54 5 ' d4 : begin out <= 3 ' d2 ; timingOut <= timingIn ; end55 5 ' d5 : begin out <= 3 ' d2 ; timingOut <= 1 ' b0 ; end56 5 ' d6 : begin out <= 3 ' d3 ; timingOut <= timingIn ; end57 5 ' d7 : begin out <= 3 ' d3 ; timingOut <= 1 ' b0 ; end58 5 ' d8 : begin out <= 3 ' d4 ; timingOut <= timingIn ; end59 5 ' d9 : begin out <= 3 ' d4 ; timingOut <= 1 ' b0 ; end60 5 ' d10 : begin out <= 3 ' d5 ; timingOut <= timingIn ; end61 5 ' d11 : begin out <= 3 ' d5 ; timingOut <= 1 ' b0 ; end62 de f au l t : begin out <= 3 ' d6 ; timingOut <= 1 ' b0 ; end63 endcase64 end65

66 e l s e i f ( moduleId == BP1_3)67 begin

B1.6. moduleSelector 43

68 case ( in )69 5 ' d0 : begin out <= 3 ' d0 ; timingOut <= timingIn ; end70 5 ' d1 : begin out <= 3 ' d0 ; timingOut <= 1 ' b0 ; end71 5 ' d2 : begin out <= 3 ' d0 ; timingOut <= 1 ' b0 ; end72 5 ' d3 : begin out <= 3 ' d1 ; timingOut <= timingIn ; end73 5 ' d4 : begin out <= 3 ' d1 ; timingOut <= 1 ' b0 ; end74 5 ' d5 : begin out <= 3 ' d1 ; timingOut <= 1 ' b0 ; end75 5 ' d6 : begin out <= 3 ' d2 ; timingOut <= timingIn ; end76 5 ' d7 : begin out <= 3 ' d2 ; timingOut <= 1 ' b0 ; end77 5 ' d8 : begin out <= 3 ' d2 ; timingOut <= 1 ' b0 ; end78 5 ' d9 : begin out <= 3 ' d3 ; timingOut <= timingIn ; end79 5 ' d10 : begin out <= 3 ' d3 ; timingOut <= 1 ' b0 ; end80 5 ' d11 : begin out <= 3 ' d3 ; timingOut <= 1 ' b0 ; end81 5 ' d12 : begin out <= 3 ' d4 ; timingOut <= timingIn ; end82 5 ' d13 : begin out <= 3 ' d4 ; timingOut <= 1 ' b0 ; end83 5 ' d14 : begin out <= 3 ' d4 ; timingOut <= 1 ' b0 ; end84 5 ' d15 : begin out <= 3 ' d5 ; timingOut <= timingIn ; end85 5 ' d16 : begin out <= 3 ' d5 ; timingOut <= 1 ' b0 ; end86 5 ' d17 : begin out <= 3 ' d5 ; timingOut <= 1 ' b0 ; end87 de f au l t : begin out <= 3 ' d6 ; timingOut <= 1 ' b0 ; end88 endcase89 end90

91 e l s e i f ( moduleId == BP2_2)92 begin93 case ( in )94 5 ' d0 : begin out <= 3 ' d5 ; timingOut <= 1 ' b0 ; end95 5 ' d1 : begin out <= 3 ' d0 ; timingOut <= timingIn ; end96 5 ' d2 : begin out <= 3 ' d0 ; timingOut <= 1 ' b0 ; end97 5 ' d3 : begin out <= 3 ' d1 ; timingOut <= timingIn ; end98 5 ' d4 : begin out <= 3 ' d1 ; timingOut <= 1 ' b0 ; end99 5 ' d5 : begin out <= 3 ' d2 ; timingOut <= timingIn ; end

100 5 ' d6 : begin out <= 3 ' d2 ; timingOut <= 1 ' b0 ; end101 5 ' d7 : begin out <= 3 ' d3 ; timingOut <= timingIn ; end102 5 ' d8 : begin out <= 3 ' d3 ; timingOut <= 1 ' b0 ; end103 5 ' d9 : begin out <= 3 ' d4 ; timingOut <= timingIn ; end104 5 ' d10 : begin out <= 3 ' d4 ; timingOut <= 1 ' b0 ; end105 5 ' d11 : begin out <= 3 ' d5 ; timingOut <= timingIn ; end106 de f au l t : begin out <= 3 ' d6 ; timingOut <= 1 ' b0 ; end107 endcase108 end109

110 e l s e i f ( moduleId == BP2_3)111 begin112 case ( in )113 5 ' d0 : begin out <= 3 ' d5 ; timingOut <= 1 ' b0 ; end114 5 ' d1 : begin out <= 3 ' d0 ; timingOut <= timingIn ; end115 5 ' d2 : begin out <= 3 ' d0 ; timingOut <= 1 ' b0 ; end116 5 ' d3 : begin out <= 3 ' d0 ; timingOut <= 1 ' b0 ; end117 5 ' d4 : begin out <= 3 ' d1 ; timingOut <= timingIn ; end118 5 ' d5 : begin out <= 3 ' d1 ; timingOut <= 1 ' b0 ; end119 5 ' d6 : begin out <= 3 ' d1 ; timingOut <= 1 ' b0 ; end120 5 ' d7 : begin out <= 3 ' d2 ; timingOut <= timingIn ; end121 5 ' d8 : begin out <= 3 ' d2 ; timingOut <= 1 ' b0 ; end122 5 ' d9 : begin out <= 3 ' d2 ; timingOut <= 1 ' b0 ; end123 5 ' d10 : begin out <= 3 ' d3 ; timingOut <= timingIn ; end124 5 ' d11 : begin out <= 3 ' d3 ; timingOut <= 1 ' b0 ; end125 5 ' d12 : begin out <= 3 ' d3 ; timingOut <= 1 ' b0 ; end126 5 ' d13 : begin out <= 3 ' d4 ; timingOut <= timingIn ; end127 5 ' d14 : begin out <= 3 ' d4 ; timingOut <= 1 ' b0 ; end128 5 ' d15 : begin out <= 3 ' d4 ; timingOut <= 1 ' b0 ; end129 5 ' d16 : begin out <= 3 ' d5 ; timingOut <= timingIn ; end130 5 ' d17 : begin out <= 3 ' d5 ; timingOut <= 1 ' b0 ; end

B1.7. signalSelectorOutput 44

131 de f au l t : begin out <= 3 ' d6 ; timingOut <= 1 ' b0 ; end132 endcase133 end134

135 e l s e i f ( moduleId == BP3_3)136 begin137 case ( in )138 5 ' d0 : begin out <= 3 ' d5 ; timingOut <= 1 ' b0 ; end139 5 ' d1 : begin out <= 3 ' d5 ; timingOut <= 1 ' b0 ; end140 5 ' d2 : begin out <= 3 ' d0 ; timingOut <= timingIn ; end141 5 ' d3 : begin out <= 3 ' d0 ; timingOut <= 1 ' b0 ; end142 5 ' d4 : begin out <= 3 ' d0 ; timingOut <= 1 ' b0 ; end143 5 ' d5 : begin out <= 3 ' d1 ; timingOut <= timingIn ; end144 5 ' d6 : begin out <= 3 ' d1 ; timingOut <= 1 ' b0 ; end145 5 ' d7 : begin out <= 3 ' d1 ; timingOut <= 1 ' b0 ; end146 5 ' d8 : begin out <= 3 ' d2 ; timingOut <= timingIn ; end147 5 ' d9 : begin out <= 3 ' d2 ; timingOut <= 1 ' b0 ; end148 5 ' d10 : begin out <= 3 ' d2 ; timingOut <= 1 ' b0 ; end149 5 ' d11 : begin out <= 3 ' d3 ; timingOut <= timingIn ; end150 5 ' d12 : begin out <= 3 ' d3 ; timingOut <= 1 ' b0 ; end151 5 ' d13 : begin out <= 3 ' d3 ; timingOut <= 1 ' b0 ; end152 5 ' d14 : begin out <= 3 ' d4 ; timingOut <= timingIn ; end153 5 ' d15 : begin out <= 3 ' d4 ; timingOut <= 1 ' b0 ; end154 5 ' d16 : begin out <= 3 ' d4 ; timingOut <= 1 ' b0 ; end155 5 ' d17 : begin out <= 3 ' d5 ; timingOut <= timingIn ; end156 de f au l t : begin out <= 3 ' d6 ; timingOut <= 1 ' b0 ; end157 endcase158 end159

160 e l s e161 begin162 out <= 3 ' d6 ;163 timingOut <= 1 ' b0 ;164 end165

166 end167 endmodule

B1.7 signalSelectorOutput

1 /∗2 | This module w i l l pass only one o f the pa i r o f input s i g n a l s to the output3 | depending on the value on the s ignalType port .4 ∗/5

6 module s i gna lSe l e c to rOutput ( inNrMulti , inNrRefTim , inTimMulti , inTimRefTim , outNr ,outTim , s ignalType ) ;

7

8 parameter ST1 = 1 ' b0 ;9 parameter ST2 = 1 ' b1 ;

10

11 input [ 2 : 0 ] inNrMulti , inNrRefTim ;12 input inTimMulti , inTimRefTim ;13 input s ignalType ;14 output [ 2 : 0 ] outNr ;15 output outTim ;16

17 reg [ 2 : 0 ] outNr ;18 reg outTim ;

B1.8. demux 45

19

20 always @ ( inNrMulti [ 0 ] or inNrMulti [ 1 ] or inNrMulti [ 2 ] or inNrRefTim [ 0 ] or inNrRefTim [ 1 ]or inNrRefTim [ 2 ] or inTimMulti or inTimRefTim or s ignalType )

21 begin22 case ( s ignalType )23 ST1 : begin outNr <= inNrMulti ; outTim <= inTimMulti ; end24 ST2 : begin outNr <= inNrRefTim ; outTim <= inTimRefTim ; end25 endcase26 end27

28 endmodule

B1.8 demux

1 /∗2 | This module w i l l forward the in s i g n a l to one o f the out por t s3 | depending on the number read on the s e l e c t port . Al l outputs w i l l4 | be 0 i f enable i s 0 .5 | Ex . I f s e l e c t = 2 ( and enable = 1) => out [ 2 ] = in .6 ∗/7

8 module demux ( in , s e l e c t , out , enable ) ;9 input in ;

10 input [ 2 : 0 ] s e l e c t ;11 input enable ;12 output [ 5 : 0 ] out ;13 wire temp ;14 a s s i gn temp = enable & in ;15 a s s i gn out = temp << s e l e c t ;16 endmodule

BILAGA 2

Blockschema över toppnivå tillprogram för MAX V CPLD

Den mest övergripande modulen i ett HDL-program, vars portar kopplas direkt till kret-sens I/O, kallas för toppnivå. Figur B2.1 på sida 47 visar ett blockschema över toppnivånför programmet till MAX V CPLDn.

46

47

Figur B2.1: Blockschema över toppnivå till program för MAX V CPLD.

BILAGA 3

Funktionssimuleringar avprogram till MAX V CPLD utan

ingångsfilter

Filtrering av insignalerna genom modulerna inputFilterX6 och inputFilter skapar enofrånkomlig fördröjning. Denna fördröjning blir i praktiken obetydligt kort eftersom stör-ningarna som ska ltreras bort är mycket korta relativt signalpulserna. I avsnitt 4.2 visassimuleringar med ingångslter för att demonstrera dess funktion. Simuleringar utan in-gångslter är dock mer lika verkligheten. Figur B3.1 på sidan 49 föreställer en simuleringmed multitrigg och gur B3.2 på sidan 50 visar motsvarande simulering med referens-och timingsignal. Inget ingångslter är använt i dessa simuleringar.

48

49

Figur B3.1: Simulering med multitrigg, utan ingångslter.

50

Figur B3.2: Simulering med referens- och timingsignal, utan ingångslter.