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

Transkript

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

2 SAMMANFATTNING 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 ABSTRACT 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 different 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 INNEHÅLL Kapitel 1 Introduktion Bakgrund Grundidé Metod Kapitel 2 Teori Signaltyper för triggning Bentliga digitala funktioner Funktion för val av tändspole Funktion för addition av triggsignaler Nya digitala funktioner Arkitekturtyper FPGA CPLD MCU Mixed signal FPGA Kapitel 3 Genomförande Val av krets Programspråk Designverktyg Material Programmering av MAX V Simuleringar Laborationer Generering av triggsignaler Veriering av funktioner Kapitel 4 Resultat Program Toppnivå Modul: inputfilterx Modul: triggsel Modul: counter

7 4.1.5 Modul: moduleselector Modul: signalselectoroutput Modul: demux Simuleringar Simuleringar med multitrigg Simuleringar med referens- och timingsignal Laborationer Kapitel 5 Slutsats och diskussion 35 Referenser 37 Bilaga 1 Programkod i Verilog för MAX V CPLD 38 B1.1 Toppnivå B1.2 inputfilterx B1.3 inputfilter B1.4 triggsel B1.5 counter B1.6 moduleselector B1.7 signalselectoroutput B1.8 demux 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 KAPITEL 1 Introduktion 1.1 Bakgrund SEM AB (hädanefter kallat SEM) utvecklar och tillverkar tändstyrenheter till förbränningsmotorer, 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 optimera 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 genererats, 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ållning. 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 konstruera 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 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 KAPITEL 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ändning 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 timerfunktion 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 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 Funktion för addition av triggsignaler Triggsignalen till ICD5 består, som tidigare nämnts, av sex signaler, en för varje tändspole, 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 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 FPGA FPGA (Field-programmable gate array) är en integrerad krets som används inom digitalteknik. 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] 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 MCU En mikrokontroller (även kallad MCU) är en dator med processor, minne och kringutrustning 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. Assemblerkoden 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 2 C och CAN. PWM generator.

16 2.4. Arkitekturtyper 9 Timer. Klockkrets. ADC och DAC. Avbrottshantering 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 KAPITEL 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öjning 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, temperaturtålighet och kapseltyp. SEMs krav på temperaturtålighet är minst 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): 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 anvä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 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 3.7. Laborationer 15 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ägskommunikation 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änningskonverteringen 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 3.7. Laborationer 16 Figur 3.3: En Arduino Uno med laborationskort för generering av triggsignaler 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 3.7. Laborationer Figur 3.4: Uppkoppling av mätutrustning för veri ering av programfunktioner. 17

25 KAPITEL 4 Resultat 4.1 Program 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 anvä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ångsinterfacet 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ångsinterfacets 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 Modul: inputfilterx6 Denna modul tar 6 insignaler samt en klocksignal och bildar 6 utsignaler. Modulen ltrerar 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 insignalernas 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 inputfilterx 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ångarna 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 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 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örbestä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 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 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ångslter 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 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 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 timinginfrommcusignalen.

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

33 4.2. Simuleringar 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 På grund av detta hanterar enheten endast varannan puls av timingsignalen och första pulsen efter referenspulsen är en av dem.

34 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). 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 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 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).

36 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).

37 4.3. Laborationer Laborationer För att göra resultatet från laborationerna lättöverskådligt har jag försökt få oscilloskopskä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 4.3. Laborationer 31 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 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 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.22 och I samtliga fall är signaltype ställd till 1 men moduleid inställningen skiljer sig.

40 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 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).

41 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).

42 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ö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 databuss. 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 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. Programmet 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. 36

44 REFERENSER [1] S. Åke Andersson, Four soft-core processors for embedded systems. Four-soft-core-processors-for-embedded-systems, [Online; ]. [2] Wikipedia, Field-programmable gate array. Field-programmable_gate_array, [Online; ]. [3] Wikipedia, Complex programmable logic device. wiki/complex_programmable_logic_device, [Online; ]. [4] Wikipedia, Programmable logic device. Programmable_logic_device, [Online; ]. [5] Wikipedia, Microcontroller [Online; ]. [6] Wikipedia, Maskinkod [Online; ]. [7] Wikipedia, Reduced instruction set computing. Reduced_instruction_set_computing, [Online; ]. [8] Basic understanding of microcontroller interrupts. http: // [Online; ]. [9] Wikipedia, Field-programmable gate array. Field-programmable_gate_array, [Online; ]. 37

45 BILAGA 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 naltype pattern 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 naltype pattern 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 8 parameter BP1_2 = 4 ' b0110 ; // Module 1/2 9 parameter BP1_3 = 4 ' b0111 ; // Module 1/3 10 parameter BP2_2 = 4 ' b1010 ; // Module 2/2 11 parameter BP2_3 = 4 ' b1011 ; // Module 2/3 12 parameter BP3_3 = 4 ' b1111 ; // Module 3/ 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 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 ; 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 ; 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