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

(1)

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

(2)

S AMMANFATTNING

SEM AB utvecklar och tillverkar tändstyrenheter för förbränningsmotorer, bland annat naturgas- och biogasmotorer. Tändstyrenheterna styr själva tändförloppet när de får en triggsignal från motorstyrsystemet (ECU). På grund av att enheterna används tillsammans med era olika motorstyrsystem måste de anpassas for olika signaltyper och cylinderantal. Anpassningar av både mjukvaran och hårdvaran måste göras och detta krä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 komponenter i tändstyrenheterna ska även funktioner som realiseras med diskreta komponenter, om mö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 funktioner har skapats i form av programkod i Verilog. Slutligen har simuleringar av programmet gjorts och dess funktion har verierats med hjälp av ett utvecklingskort.

i

(3)

A ^BSTRACT

SEM AB develops and manufactures ignition control units for internal combustion engines, including natural gas and biogas engines. The ignition control units control the ignition 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 the hardware 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 components in 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. The functions of the input interface have been created, in the form of Verilog programming code. Finally, simulations of the program have been made and its function has been veried using a development board.

ii

(4)

F ^ÖRORD

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

iii

(5)

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

(6)

I ^NNEHÅLL

Kapitel 1 Introduktion 1

1.1 Bakgrund . . . 1

1.2 Grundidé . . . 2

1.3 Metod . . . 3

Kapitel 2 Teori 4 2.1 Signaltyper för triggning . . . 4

2.2 Bentliga digitala funktioner . . . 5

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

2.2.2 Funktion för addition av triggsignaler . . . 6

2.3 Nya digitala funktioner . . . 7

2.4 Arkitekturtyper . . . 7

2.4.1 FPGA . . . 7

2.4.2 CPLD . . . 7

2.4.3 MCU . . . 8

2.4.4 Mixed signal FPGA . . . 9

Kapitel 3 Genomförande 10 3.1 Val av krets . . . 10

3.2 Programspråk . . . 12

3.3 Designverktyg . . . 12

3.4 Material . . . 12

3.5 Programmering av MAX V . . . 13

3.6 Simuleringar . . . 13

3.7 Laborationer . . . 14

3.7.1 Generering av triggsignaler . . . 14

3.7.2 Veriering av funktioner . . . 16

Kapitel 4 Resultat 18 4.1 Program . . . 18

4.1.1 Toppnivå . . . 18

4.1.2 Modul: inputFilterX6 . . . 19

4.1.3 Modul: triggSel . . . 20

4.1.4 Modul: counter . . . 20

(7)

4.1.5 Modul: moduleSelector . . . 21

4.1.6 Modul: signalSelectorOutput . . . 22

4.1.7 Modul: demux . . . 22

4.2 Simuleringar . . . 23

4.2.1 Simuleringar med multitrigg . . . 23

4.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å . . . 38

B1.2 inputFilterX6 . . . 39

B1.3 inputFilter . . . 40

B1.4 triggSel . . . 40

B1.5 counter . . . 41

B1.6 moduleSelector . . . 41

B1.7 signalSelectorOutput . . . 44

B1.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

(8)

K ^APITEL 1 Introduktion

1.1 Bakgrund

SEM 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 enheter till 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 motorstyrsystemet (ECU). Tändning sker i princip genom att en kondensator först laddas upp till ca. 400 V. Vid tändningstillfället sker en urladdningen från kondensatorn till en tändspole som genererar en så hög spänning (upp till 40 kV) att en gnista bildas i tä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änds som 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 ett

ertal 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 olika metoder för att signalera att en viss tändspole ska aktiveras. På grund av detta har SEM idag era snarlika produkter där största skillnaden är att de hanterar olika triggsignaler från motorstyrsystemet. Varje tändstyrenhet kan hantera upp till 6 tändspolar vilket gör att 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 av motorstyrsystem och motorer. Detta skulle underlätta bl.a. administrering och lagerhåll- ning.

1

(9)

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älva tändförloppet och göra mätningar. På grund av att triggsignalerna till MCUn i princip kommer direkt från ECUn måste programmet i MCUn anpassas för signaltyp och antalet tändspolar. Även kretskorten måste anpassas. Detta kräver tid för utvecklarna på SEM och 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. Detta ingångsinterface ska omvandla olika typer av triggsignaler till en standardsignal. Det skulle medföra att mjukvaran i MCUn inte behöver specialanpassas för de olika produkterna 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öjligt utan 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ändspole 1-6, 7-12 osv).

Det ska även utredas om det är möjligt att implementera funktioner som idag realiseras med diskreta komponenter i detta ingångsinterface. Om detta är möjligt skulle antalet komponenter, som måste köpas in och lagerhållas, minskas. Fler komponenter och lödningar på kretskortet innebär även er potentiella felkällor.

(10)

1.3. Metod 3

1.3 Metod

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

(11)

K ^APITEL 2 Teori

2.1 Signaltyper för triggning

Olika motorstyrsystem använder sig av olika typer av triggsignaler för att signalera att en viss tändspole ska tändas. Idag behandlar SEMs produkter ICD4 och ICD5 två olika typer 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 denna triggsignal.

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 givare på kamaxeln. Vad gäller triggsignalerna så ska tändstyrenheten aktivera den tändspole som motsvaras av respektive triggsignal. Jag har valt att kalla denna signal för multitrigg. Figur 2.2 visar ett principiellt tidsdiagram för denna triggsignal.

4

(12)

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 kan vara 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 principiellt tidsdiagram för denna signal.

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

2.2 Befintliga digitala funktioner

På grund av den elektriskt krävande miljön där SEMs produkter används behövs det en mängd skyddselektronik som klarar höga spänningar och eekter. De funktioner denna elektronik har går inte att realisera i någon programmerbar krets och måste därför nnas kvar i produkterna i form av diskreta komponenter. De funktioner som är möjliga att realisera i en programmerbar krets är framför allt de som är helt digitala och behandlar signaler med en logisk spänningsnivå. I produkten ICD4 nns det en funktion med dessa egenskaper och i ICD5 nns det två.

(13)

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 demultiplexer och transistorer för att välja vilken tändspole som ska aktiveras. En timingsignal samt en binär kod på tre bitar skickas från MCUn till signalingången respektive select-ingångarna på demultiplexern. Den binära koden avgör vilken utgång som väljs för insignalen (timingsignalen). Eftersom timingsignalen är en digital signal skulle denna funktion 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 krets och 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änds sedan av MCUn för att aktivera rätt tändspole vid rätt tidpunkt. Denna sjunde signal skapas i princip genom en addition, eller logiskt sett snarare en eller-grind, mellan alla triggsignalerna. Funktionen implementeras idag med diskreta komponenter men den är mö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.

(14)

2.3. Nya digitala funktioner 7

2.3 Nya digitala funktioner

De nya funktionerna är inte lika väldenierade som de bentliga men det nns några grundlä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 triggsignaler ska det gå att tilldela kretsen ett modul id med ett antal digitala ingångar. Detta modul id ska ge möjligheten för era tändsstyrenheter att arbeta tillsammans genom att de tilldelas olika modul id. T.ex. ska två enheter med modul id 1 av 2 och 2 av 2

fungera 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ån MCUn 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 av enkla logiska block. Vid programmering kopplas dessa logiska block ihop för att bilda digitala funktioner. Hur dessa kopplingar ska ske beskrivs oftast i ett HDL (Hardware description 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 implementeras i en FPGA med hjälp av en så kallad softcore microprocessor [1]. En FPGA programmeras 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ämpad fö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 programmerbar digital integrerad krets. Det är framförallt uppbyggnaden som skiljer dem åt. En CPLD innehå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 uppbyggnaden gör att en CPLD har en mer förutsägbar timing än en FPGA [3].

(15)

2.4. Arkitekturtyper 8

Generellt sett är en CPLD, trots namnet, mindre komplex än en FPGA och är inte 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 komplex tillstå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ör att lagra program medan FPGA sällan har det. Det är också vanligt att en CPLD har inbyggd oscillator och bättre drivförmåga än en FPGA [3]. En CPLD är idag generellt sett 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ånga olika modeller och arkitekturer med varierande ordlängd, t.ex. 8, 16 och 32-bit. Några vanliga arkitekturer är PIC, AVR, ARM och MIPS. Det är vanligt med mixed signal MCUs 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. Denna maskinkod består av en sekvens av binära ord som av processorn tolkas som en följd av instruktioner [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åtal förhållandevis enkla sådana. Detta gör att varje instruktion kan exekveras snabbare och prestandan ö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 detta problem 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 kan startas av t.ex. en stigande ank på en digital ingång, en timer som har nått något fö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, I²C och CAN.

• PWM generator.

(16)

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 analoga och 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 processor, FPGA, analoga programmerbara in-/utgångar, klockkrets, ashminne m.m. Utbudet av mixed signal FPGAs på marknaden idag är inte speciellt stort och funktionerna skiljer sig kraftigt mellan de olika tillverkarnas kretsar. Två av de ledande aktörerna är Lattice Semiconductors och Microsemi. Dessa kretsar är relativt dyra och kostar era hundra kronor styck.

(17)

K ^APITEL 3 Genomförande

3.1 Val av krets

Det nns för- och nackdelar med alla olika typer av arkitekturer (se avsnitt 2.4) och det beror på applikationen vilken typ som är lämpligast. Mixed signal FPGA har jag valt bort p.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ågra anledningar 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

(18)

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 kombinatorisk logik. FPGA/CPLD lämpar sig därför utmärkt för detta ändamål eftersom dessa 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 avsnitt 2.2.1), där insignalen tas från MCUn, ska denna insignal ej påverkas av övriga funktioner i kretsen. Detta kräver att kretsen klarar av att hantera parallella processer och därför lä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 och idag 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 de krav 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 inbyggd oscillator vilket är en stor fördel då SEM helst vill unvika en extern oscillator. Kretsen

nns i olika prisklasser beroende på kapacitet, temperaturtålighet och antal in-/utgångar.

Komponenten med modellnummer 5M160ZE64A5N anser jag skulle passa bra och här fö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,5 V, 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.

(19)

3.2. Programspråk 12

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

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

3.2 Programspråk

För att beskriva funktionerna av en digital krets används vanligtvis ett programspråk av typen HDL. De två mest använda programspråken i denna kategori är idag VHDL och Verilog. Jag har valt att använda Verilog eftersom jag tycker att det har den mest logiska uppbyggnaden och dels för att många syntaxer liknar C som är ett programspråk jag har erfarenhet av.

Programmering i ett HDL skiljer sig tankemässigt en del från programmering av mikroprocessorer. Någon som är van att programmera mikroprocessorer har oftast ett sekventiellt tankesätt. Vid programmering i HDL skapas istället moduler som i sin tur kan kopplas 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 beskrivning av kretsen funktioner och uppbyggnad.

3.3 Designverktyg

Altera har ett designverktyg som heter Quartus II och är anpassat för utveckling av program till deras kretsar. Quartus II används även för kompilering och programmering.

I Quartus II kan programmeringen ske helt textbaserat, genom att skapa blockscheman eller 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 waveform editor för att simulera de funktioner jag skapat i Quartus II.

3.4 Material

Jag har använt mig av följande material för programmering, simuleringar och laborationer.

• Quartus II Web edition.

• Qsim and Waveform editor.

• MAX V CPLD Development kit.

• Arduino Uno.

(20)

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 V

Eftersom jag inte hade något att utgå från vad gäller programkod när projektet startade började jag med att skissa på toppnivån. Jag skissade först på två blockscheman med moduler, ett för varje signaltyp. I detta stadiet hade jag enbart en idé om vad de olika modulerna 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 dessa skulle 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 till ett.

3.6 Simuleringar

För att simulera programmets funktioner har jag, som nämnts i avsnitt 3.3, använt Qsim med tillhörande Waveform Editor. Genom att kompilera programmet i Quartus II kan projektet öppnas i Qsim och simuleras med insignaler som är specicerade i en l som är skapad 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

(21)

3.7. Laborationer 14

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

3.7 Laborationer

För att veriera att programmet fungerar som simulerat använde jag mig av ett utvecklingskort med en MAX V krets från Altera. Kortet kan ses i gur 3.1. Den MAX V krets som är integrerad på utvecklingskortet har mer kapacitet och er in- och utgångar än den krets jag rekommenderat i avsnitt 3.1. I övrigt är de båda kretsarna identiska och dä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 som heter Arduino Uno. Jag valde att använda detta kort eftersom jag redan hade erfarenhet av det. Detta gjorde att jag kunde lägga mer tid på programmet till MAX V utvecklingskortet och mindre tid på programmering av mikrokontrollern. Enda problemet med

(22)

Arduino-kortet var att det använder sig av en 5 V TTL spänningsnivå. MAX V kortet kunde maximalt hantera en spänningsnivå på 3,3 V och detta gjorde att jag var tvungen att 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ågot större problem. Den enklaste lösningen var att använda en vanlig spänningsdelning med resistorer 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ör att ändra frekvens på utsignalen använde jag en potentiometer och för att ändra signaltyp användes en tryckknapp. Jag använde även en DIP-switch, som egentligen inte har något att göra med mikrokontrollern utan används till att ställa några ingångar på MAX V kortet i olika tillstånd. Alla komponenter och kontakter lödde jag på ett laborationskort. En Arduino Uno med laborationskort kan ses i gur 3.3 och kopplingschema för laborationskortet kan ses i gur 3.2.

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

(23)

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 att använda dessa dioder för att veriera att insignalerna från mikrokontrollern hanterades på rätt sätt och att en timingsignal kunde skapas. Genom detta test kunde jag även dra slutsatsen att ingångsltren och den interna oscillatorn fungerade eftersom ltren inte släpper igenom några signaler utan en klockfrekvens. När jag hade bekräftat att programmet fungerade som planerat tillverkade jag ett kretskort för mätning som jag kopplade 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 som extern trigger till samtliga oscilloskop. Eftersom jag behövde mäta på ca. 16 signaler samtidigt blev denna metod besvärlig då jag endast hade tillgång till oscilloskop med 2 kanaler. Jag ck därför låna ett Agilent 54622D mixed signal oscilloskop av SEM som har 16 digitala samt 2 analoga kanaler. Detta oscilloskop underlättade mätningarna avsevärt då jag kunde se alla signaler på en och samma oscilloskopbild. Figur 3.4 visar en uppkoppling av mikrokontrollern, MAX V utvecklingskortet och laborationskorten med mätprober till Agilent-oscilloskopet.

(24)

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

(25)

K ^APITEL 4 Resultat

4.1 Program

4.1.1 Toppnivå

Grundtanken med programmet är att det enkelt ska gå att anpassa för olika insignalstyper och antal tändstyrenheter. Denna anpassning ska gå att göra genom att ställa ett antal ingångar höga eller låga. Jag har valt att använda en bit för att beskriva signaltypen och fyra bitar för att beskriva modul id. Med modul id menar jag, i fallet där era tändstyrenheter arbetar tillsammans, det totala antalet tändsstyrenheter samt vilken tändstyrenhet interfaceenheten i fråga sitter i. Detta är nödvändig information för att kunna hantera en referens- och timingsignal (se gur 2.1 på sidan 4) för fallet då antalet tändspolar överstiger sex. Sex är det maximala antalet tändspolar en tändstyrenhet kan hantera.

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 och nummer 0 den minst signikanta biten. Nedan följer en förklaring av samtliga in- och utsignaler.

• 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. betyder

1011 tändstyrenhet 2 av 3.

18

(26)

4.1. Program 19

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

• enableMux (1 bit) - Via denna bit kan den interna demultiplexern helt stängas av och 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 olika mätsignaler till MCUn beroende på vilken tändspole som är aktiv. På grund av att den hanterar analoga signaler kan den ej realiseras i ingångsinterfacet. Därför behö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 nuvarande tillstå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. Med andra ord så ltreras snabba variationer av insignalerna bort. Detta sätt att ltrera en signal kräver inga avancerade matematiska beräkningar och är därför mycket mindre resurskrävande för en CPLD än DSP algoritmer som FIR eller IIR.

(27)

4.1. Program 20

Modulen inputFilter fungerar på samma sätt som denna modul men hanterar endast en 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 triggsignalerna och 1 ingång för en klocksignal. Det binära talet på de 3 utgångarna motsvarar numret 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 ändrar tillstånd vid positiv ank på klocksignalen om ingångarna stämmer överens med några förutbestämda bitmönster. I alla andra fall behåller utgångarna sina tillstånd. Med andra ord så sparar modulen numret på den senast aktiva ingången på utgångarna i form av ett 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ånd endast vid positiv ank på någon av ingångarna. De 5 utgångarna symboliserar ett binärt

(28)

4.1. Program 21

tal på 5 bitar med utgångsvärdet 0. Vid positiv ank på klockingången ökar räknaren med ett och utgångarna uppdateras. När reset-ingången får en positiv ank nollställs rä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 rent kombinatorisk och har 10 st. ingångar varav 5 st. för insignaler i form av ett binärt tal. För

moduleId har den 4 ingångar och den sista ingången är för timingsignalen. Utsignalerna från modulen är ett binärt tal på 3 bitar samt en timingsignal. Dess funktion är att ltrera bort 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 överens med något av fallen som är specicerade sätts utgångarna till ett tillstånd som i slutändan resulterar 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 alla ingångar och utgångar för modulen.

(29)

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 grupp vardera 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 multitrigg eller referens- och timingsignal. Modulens funktion är att koppla en av de två grupperna till utgångarna beroende på om ingången för signaltyp är ställd till 0 eller 1. Figur 4.6 visar 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 demultiplexas ut på någon av utgångarna beroende av bitmönstret på select ingångarna. Den binä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.

(30)

4.2. Simuleringar 23

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

4.2 Simuleringar

Jag 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ångsltren fungerar. Jag har enbart gjort funktionssimuleringar och därför är simuleringarna inte anpassade till verkliga tidsförhållanden. Detta medför att klocksignalen i simuleringarna måste ha en mycket högre frekvens än den verkliga oscillatorn på ca. 5 MHz. Resultatet har 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 signalerna är beroende av timingInFromMCU signalen och denna är odenierad. Med andra ord betyder detta att timingInFromMCU signalen demultiplexas ut på någon av triggOut utgångarna. Signalen analogMux visas som en decimal representation av bitmönstret på dess tre utgångar.

(31)

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.

(32)

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

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

(33)

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 är tillagda 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 denna gång för fallet med 12 tändspolar. Enheten är inställd att agera modul 1 av 2 eftersom moduleId är ställd till 0110. På grund av detta hanterar enheten endast varannan puls av timingsignalen och första pulsen efter referenspulsen är en av dem.

(34)

Figur 4.12: Simulering med referens- och timingsignal för 12 tändspolar och modulId ställd till 0110 (1 av 2).

Om moduleId istället ställs till 1010 d.v.s. enheten är inställd att agera modul 2 av 2 blir resultatet motsatt. Detta kan ses i gur 4.13. På detta sätt kan två enheter med moduleId 0110 och 1010 arbeta tillsammans eftersom alla pulser i timingsignalen behandlas men av 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).

(35)

(36)

(37)

4.3 Laborationer

Fö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 det lä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å samtliga signaler som jag har med i simuleringarna. Därför valde jag bort moduleId, signalType och 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 simuleringarna. 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 vara problem med triggSel modulen. Utgångarna från modulen uppdaterades på stigande ank fö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ör modulen så att den istället använde sig av den inbyggda oscillatorn för att uppdatera utgå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ätning med 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

(38)

AMUX02, där AMUX0 är den minst signikanta biten, är signalerna till den analoga multiplexern. Dessa signaler motsvarar numret på den för tillfället aktiva utgången om de 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 0110 och 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 med ett 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 detta drog jag slutsatsen att det var störningar eller överhörning i kablaget som genererade dessa pulser.

(39)

Figur 4.19: Laboration med referens- och timingsignal för 12 tändspolar och modulId ställd till 0110 (1 av 2).

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

(40)

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

(41)

(42)

K ^APITEL 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ör

er typer av signaler om det är önskat. På grund av en CPLDs uppbyggnad skulle dessa tillägg inte påverka de bentliga funktionerna.

Det visas även att och hur det är möjligt att få era tändstyrenheter att arbeta tillsammans, genom att tilldela varje enhet ett id, trots att de får samma insignal. Hur detta id ska tilldelas är då nästa fråga. En idé är att använda kablaget till tändspolarna, via nå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ända mikrokontrollern 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 kommunicera med 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å liknande sätt skulle det gå att låta kablaget till motorstyrsystemet, via någon bygling, bestämma signaltypen. Vinsten med detta skulle vara att identiska tändstyrenheter kan levereras till kunder med olika motorer och så länge kablaget till tändspolarna är korrekt tillverkat skulle 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 att skapa ett fungerande kretsschema men en grov uppskattning kan göras. De komponenter som skulle kunna plockas bort från kretskortet är framförallt de som används för de bentliga digitala funktionerna (se avsnitt 2.2). Till dessa funktioner används 17 komponenter och 35 lödningar för ICD4 och 26 komponenter och 57 lödningar för ICD5. Antal komponenter som tillkommer vid införandet av ingångsinterfacet är svårare att uppskatta men det som är säkert är, en MAX V CPLD (5M160ZE64A5N) som kräver 64 lödningar samt någon 1,8 V spänningsregulatorkrets för att driva CPLDn. En sådan krets skulle t.ex. kunna bestå av 2 kondensatorer och en spänningsregulator d.v.s. 3 komponenter

35

(43)

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. MCUn skulle enbart behöva styra tändförloppet när den får en timingpuls från ingångsinterfacet och 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 optimeras för att styra själva tändförloppet istället. In- och utgångar på MCUn skulle även frigöras och istället kunna användas för andra funktioner. Om endast en programvara till MCUn behöver administreras och utvecklas skulle tid och pengar kunna sparas.

(44)

R ^EFERENSER

[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

(45)

B ^ILAGA 1

Programkod i Verilog för MAX V CPLD

B1.1 Toppnivå

1 module I n p u t I n t e r f a c e 3 ( t r i g g I n , signalType , moduleId , triggOut , timingOutToMCUinverted , timingOutToMCU , timingInFromMCU , enableMux , enableMuxOut , analogMux ) ;

2

3 parameter ST1 = 1 ' b0 ; // S i g n a l t y p e p at t e rn to s e l e c t " M u l t i t r i g g " .

4 parameter ST2 = 1 ' b1 ; // S i g n a l t y p e p at t e rn to s e l e c t " Reference and timing " .

5

6 /∗ B i t p a t t e r n 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/1

13

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 the timingInFromMCU s i g n a l .

15 parameter FILTER_LENGTH_TIMING = 6 3 ; //Max : 2^FILTER_BITS_TIMING − 1

16 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 = 6 3 ; //Max : 2^FILTER_BITS_TRIGG − 1

18

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 ] triggOut ;

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 n F i l t e r e d ;

28 wire [ 2 : 0 ] coilNrMulti , coilNrRefTim , c o i l N r ;

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 r MAX V och MAX I I d e v i c e s

38

(46)

B1.2. inputFilterX6 39

33

34 i n p u t F i l t e r X 6 #(FILTER_BITS_TRIGG,FILTER_LENGTH_TRIGG) i f 1 ( . i n ( t r i g g I n ) , . c l k ( osc_sig ) , . out ( t r i g g I n F i l t e r e d ) ) ;

35

36 // a s s i g n t r i g g I n F 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 p u t F i l t e r #(FILTER_BITS_TIMING,FILTER_LENGTH_TIMING) i f 2 ( . i n ( timingInFromMCU ) , . c l k ( osc_sig ) , . out ( timingInFromMCUFiltered ) ) ;

39

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

41

42 a s s i g n timingMulti = | t r i g g I n F i l t e r e d ; // OR−gate between multiTrigg s i g n a l s to c r e a t e a timing s i g n a l .

43

44 t r i g g S e l t r i g g S e l ( . i n ( t r i g g I n F i l t e r e d ) , . out ( c o i l N r M u l t i ) , . c l k ( osc_sig ) ) ;

45

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

47

48 moduleSelector #(BP1_1, BP1_2, BP1_3, BP2_2, BP2_3, BP3_3) moduleSelector ( . in ( counterValue ) , . timingIn ( t r i g g I n F i l t e r e d [ 1 ] ) , . moduleId ( moduleId ) , . out ( coilNrRefTim ) , . timingOut ( timingRefTim ) ) ;

49

50 s i g n a l S e l e c t o r O u t p u t #(ST1 , ST2) s i g n a l S e l e c t o r O u t p u t ( . inNrMulti ( c o i l N r M u l t i ) , . inNrRefTim ( coilNrRefTim ) , . inTimMulti ( timingMulti ) , . inTimRefTim ( timingRefTim ) , . outNr ( c o i l N r ) , . outTim (timingOutToMCU) , . signalType ( signalType ) ) ;

51

52 a s s i g n timingOutToMCUinverted = ~timingOutToMCU ; //Only f o r monitoring the timing s i g n a l with one o f the LEDs on the developement card .

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

54 a s s i g n analogMux = c o i l N r ; // B i t p a t t e r n to s e t the e x t e r n a l analog mux .

55

56 demux demux ( . i n ( timingInFromMCUFiltered ) , . s e l e c t ( c o i l N r ) , . out ( triggOut ) , . enable ( enableMux ) ) ;

57

58 endmodule

B1.2 inputFilterX6

1 module i n p u t F i l t e r X 6 ( in , clk , 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 begin

14 i f( in != prev_sample )

15 begin

16 counter <= FILTERWIDTH;

17 end

18 e l s e i f ( counter != 0)

(47)

B1.3. inputFilter 40

19 begin

20 counter <= counter − 1 ' b1 ;

21 end

22 e l s e

23 begin

24 out <= prev_sample ;

25 end

26 prev_sample = in ;

27 end

28 endmodule

B1.3 inputFilter

1 module i n p u t F i l t e r ( in , clk , 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

12 begin

13 i f( i n != prev_sample )

14 begin

15 counter <= FILTERWIDTH;

16 end

17 e l s e i f ( counter != 0)

18 begin

19 counter <= counter − 1 ' b1 ;

20 end

21 e l s e

22 begin

23 out <= prev_sample ;

24 end

25 prev_sample = i n ;

26 end

27 endmodule

B1.4 triggSel

1 /∗

2 | This module a c t s on r i s i n g edge o f the c l k s i g n a l and

3 | s e t s the output to a number c o r r e s p o n d i n g to the a c t i v e

4 | input . I f more than one input i s a c t i v e or none o f the

5 | i n p u t s 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 ;

(48)

B1.5. counter 41

14 begin

15 c a s e ( 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 endcase

23 end

24 endmodule

B1.5 counter

1 /∗

2 | This module a c t s on p o s i t i v edges on any o f the i n p u t s ( 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 port

4 | w i l l r e s e t the counter . Otherwise the counter w i l l increment by one

5 | f o r every p o s i t i v e edge on c l k port .

6 ∗/

7

8 module counter ( clk , r e s e t , count ) ;

9 input clk , 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 begin

15 i f ( r e s e t )

16 begin

17 r e s <= 1 ' b1 ;

18 end

19 e l s e

20 begin

21 i f ( r e s )

22 begin

23 r e s <= 1 ' b0 ;

24 count <= 5 ' b00000 ;

25 end

26 e l s e

27 begin

28 count <= count + 1 ' b1 ;

29 end

30 end

31 end

32 endmodule

B1.6 moduleSelector

1 /∗

2 | This module t a k e s a 5 b i t number on the input and r e t u r n s a 3 b i t

3 | number on the output . The value on the output depends on the s t a t e

4 | o f the moduleId b i t s . The p r e s e t p a t t e r n s f o r moduleId the module

5 | a c t s on are s e t as parameters BPx_x . The timingIn s i g n a l are passed

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