Åge Stien Gunnar Tufte Pauline Haddow Jarl Thore Larsen

Transkript

1 Åge Stien Gunnar Tufte Pauline Haddow Jarl Thore Larsen

2 Innledning... 3 Beskrivelse av DSP-kort... 4 DSP...5 OnCE grensesnitt...5 Codec...5 AES/EBU...5 RAM...5 FPGA...5 XChecker kabeltilkobling....5 SPROM...5 Diverse logikk...6 Beskrivelse av Terminal kort... 7 AVR mikrokontroller...7 FPGA...7 XChecker kabeltilkobling og SPROM...7 LED...7 Diverse logikk...8 Bussprotokoll... 9 Signaler...10 Timing...11 Implementasjon Kretskort...13 DSP...13 AVR mikrokontroller...14 FPGA...14 CODEC...14 Trykknapper...14 Tastatur...14 Display...14 Vedlegg Key encoder...a RS232 driver...b 20-bit Codec...C 24-bit DSP...D Digital AudioInterface...E System skisse...f Terminal kort skisse...g DSP kort skisse...h Komponentliste...I Tidsplan for prosjektet...j

3 I tidligere årskurs er det utviklet et kretskort som er tenkt brukt mot en bakplansbuss. Etter litt tankearbeid er det kommet fram til at det skal bygges videre på dette konseptet (se vedlegg F). Det vil i høst være ca. 15 studenter som tar dette faget og ideen er da at disse deles inn i to hovedgrupper som skal utvikle ett kort hver til denne bakplansbussen. Det vil da være i alt 3 forskjellige kort som er bygd i DM-gruppen som kan kobles sammen og kommunisere på samme buss. Det ene av de to kortene som er tenkt utviklet i høst skal brukes som et lydbehandlingskort (figur 1). Dette kortet vil i hovedsak bestå av en DSP (Digital Signal Prosessor) til bearbeiding av lyden og en FPGA (Field Programable Gate Array) som kobling mot bakplansbussen. Dvs. at bussprotokollen må implementeres i denne. Det andre kortet vil være et terminalkort (figur 2). Dvs. at det har påmontert komponenter som tastatur og LCD-display m.m. og brukes som interface mot andre kort på bakplansbussen. Dette kortet skal monteres i fronten på kassetten med bakplansbussen og være tilkoblet bussen med en flatkabel. Dette kortet vil også ha en FPGA som kobling mot bussen. AD/DA 6 x Aodio ut, 2x audio inn Xchech RS232 DSP Debug I/O Xilinx FPGA Div Logikk Bakplan tilkopling Figur 1: DSP kort LED LCD Display AVR $ % Æ & ' Xilinx FPGA Div Logikk Bakplan tilkopling Xchech RS232 Figur 2: Terminal kort Side 3

4 Dette er et audiokort som skal prosessere lyd. Komponentene på dette kortet (figur 3) er: DSP (Digital Sgnal Prosessor) fra Motorola. OnCE grensesnitt (mikrokontroller til debugging av DSP og nedlasting av kode til DSP. Den er koblet til OnCE-porten på DSP). RAM (16 bit adr. 8 bit data). CODEC (AD/DA-konvertere pluss filter på inn- og ut-gang). FPGA (rekonfigurerbar logikk) av type Xilinx 4044XL. XChecker kabeltilkobling og SPROM (konfigurering av FPGA). AES/EBU for sending og mottak av digital lyd. Eventuell annen logikk. $(6(%8 5; $(6(%8 7; SDI1 SDO0 SDO0 SSI OnCE 68HC705 OnCE grensesnitt RS232 Nivå konverter RS 232 Codec SDO1 SDO2 SDI0 CCLK DSP MEM Data[7:0] Adr[15:0] CS CDin GPIO CDout RESET HOST Host port Xchecer HOST ;,/,1; ;/ +4 Bus kontroller Adr/Data Kontroll Bakplan kontakt Figur 3: DSP-kort i detalj (se også vedlegg H) Side 4

5 En DSP (vedlegg D) er en mikroprosessor som er designet med tanke på signalbehandling. Vi skal bruke DSP56007 fra Motorola. I prosjektet skal vi bruke seriesynkron porten til digital audio. Den har to inngangskanaler og seks utgangskanaler (1 stereo inngangskanal og 3 stereo utgangskanaler). Data som kommer fra en inn-kanal kommer på seriell form og skiftes inn bit for bit i et register. Når dette registeret er fullt, må DSPen ta hånd om dette dataordet (8,12,16 eller 20 bit). På utgangskanalen fungerer det på motsatt måte. DSPen må skrive til et register, og bitene blir deretter skiftet ut. Det er totalt åtte registre for inn- og ut-skifting. DPSen har i tillegg et stort antall forskjellige registre, akkurat som en liten mikrokontroller. Nedlasting av program skjer via OnCE-porten. RAM aksesseres via en 16 bit adressebuss og en 24 bit databuss. DSPen kommuniserer med FPGAen via host-porten. DSPen har en OnCE-port. Det er en 4-bit port hvor man ved å koble til en liten mikrokontroller kan gjøre to ting. Den ene er å laste ned programmet som skal kjøres på DSPen via en RS232 serieport. Den andre er å debugge programmet som kjører på DSP. Til denne lille mikrokontrolleren finnes det et eget program hvor man kan gi kommandoer og få lest av innholdet i alle registre i DSP for hver klokkeperiode. Dvs. helt vanlige debuggingsmuligheter. CODECen (vedlegg C) er en enhet som består av en AD-konverter til hver inn-kanal og en DA-konverter til hver UT-kanal. I tillegg har den filter på alle inn- og ut-ganger for å filtrere bort all uønsket lyd utenfor det hørbare frekvensområdet. CODECen er koblet til seriesynkronportene på DSP. AES/EBUen er en digital inn-/ut-port som er koblet til SSI-porten på DSPen (vedlegg E). I tillegg til intern RAM på DSPen, skal det også være en ekstern RAM med 16 bit adresse og 8 bit data. Denne kobles til den ordinære adresse og databussen på DSPen. Logikk for at DSP-kortet skal kunne kommunisere via bakplansbussen (se kapitlet om bussprotokoll) må implementeres i FPGAen. DSP-kortet skal kun fungere som en slave på bussen. I tillegg må host-grensesnittet mot DPSen lages. Når FPGAen skal konfigureres, kan det gjøres på flere forskjellige måter. En måte er å bruke en spesiell kabel som kobles til parallellporten på en PC. Den andre enden kobles til kortet med en egen kontakt. FPGAen kan også programmeres vha en SPROM. SPROMen blir først programmert i en spesiell programmerer før den settes på kortet med FPGAen. Når strøm kobles til, kan så FPGAen selv klokke konfigurasjonsdata ut av SPROMen. Kortet med FPGAen vil dermed Side 5

6 være uavhengig av en PC i ettertid for konfigurering. Bruk av en SPROM er i tillegg mye raskere enn XChecker. For å kunne gi kortet en adresse skal det kobles en 4 bits HEX bryter til FPGAen, denne gir kortet en adresse fra 0 til 15. Det skal også kobles en reset knapp til DSPen. På FPGAens DONE pinne, er det også ønskelig med en lysdiode for å indikere om kretsen er konfigurert. For å ha mulighet til å koble en logikanalysator til kortet, skal det plaseres en/flere 20 pins kontakt(er) for alle signal som vurderes som viktige ved måling/feilsøking. Side 6

7 Dette kortet (figur 4) er tenkt som et mellomledd mellom brukeren og alle andre kort koblet til bakplansbussen. Komponentene på dette kortet er: AVR mikrokontroller fra ATMEL. FPGA fra Xilinx (4044). XChecker kabeltilkobling og SPROM (konfigurering av FPGA). LCD-display Key-dekoder Telefontastatur Fire trykknapper Dioderekker RS232 serieport 4 stk. HP-pod er til hardware debugging. Eventuell annen logikk. Mikrokontrolleren, AVR 90AT8515, er en mikroprosessor med forskjellig IO-enheter. Det er en kraftig 8 bits RISC-prosessor som kjører de fleste instruksjoner på en klokkeperiode. Den kan laste ned programmet som skal kjøres serielt via en egen kontakt og lagre det i en FLASH (8 Kbyte) eller en EEPROM (512 byte). I tillegg har den en SRAM (512 byte) til lagring av data under kjøring. Den har fire generelle 8-bits porter (til) hvorav er tidsmultiplekset mellom adresse og data ved bruk av ekstern RAM. Ved bruk av intern RAM er det en ren data port. I dette prosjektet benyttes ingen eksterne RAM-brikker men ekstra RAM kan implementeres i FPGAen hvis det er behov for det. Mikrokontrolleren har videre 32 generelle 8-bits registre koblet sammen til en 16x16bit register-blokk. Den kan ha 12 forskjellige interruptkilder hvorav to er ekstern. De andre er interrupt fra IO-blokker og andre kilder inne i mikrokontrolleren. AVR mikrokontroller skal brukes til tastaturkontroll, displaykontroll, kommunikasjon på RS232 port og til å formidle data mellom tastatur og andre kort (bl.a. DSP-kortet). Akkurat som på DSP-kortet, skal FPGAen implementere bussgrensesnittet. I motsetning til DPS-kortet som er slave, skal terminalkortet være master på bussen. Dvs at det må lages ekstra logikk som styrer arbitreringen (se kapitlet om bussprotokoll) på bussen. Det må også være en kobling mellom grensesnittet til bakplansbussen og resten av kortet. Alle enheter på kortet skal være adresse-mappet, og det må defor lages en adressedekoder i FPGAen. Dette er akkurat som for DSP-kortet. Disse, i farger :-), kobles til IO-pinner på FPGAen. De kan f.eks. brukes for å indikere volum. Side 7

8 RS 232 Trykk knappar RESET RS232 Nivå konverter Port C Data [3:0] Port A INT Adresse[15:8] Adresse[7:0]/data[7:0] Data [7:0].H\ÃGHNRGHU Key prest Enable D[7:0] R/W RS E INT Adr dekoder Xchecer ;,/,1; ;/ +4 Bus kontroller LED Adr/Data Kontroll Bakplan kontakt Figur 4: Detaljer i Terminalkort (se også vedlegg G) Mye av den ekstra logikken på terminalkortet er lik som på DSP-kortet. Det skal være en adressevelger (HEX switch), resetknapp for mikrokontrolleren og en DONE -diode på FPGAen. I tillegg skal terminalkortet ha en klokkegenerator som skal sørge for klokkesignal via bakplansbussen til de andre kortene. Side 8

9 Bakplansbussen som skal brukes i dette prosjektet har en protokoll for overføring av data som er omfattende og streng. Ved overføring av data definerer protokollen 32 linjer som er tidsmultiplekset mellom adresse og data. De andre signalene er spenning, jord og kontrollsignaler. Bakplansbussen som skal brukes i dette prosjektet har 8 kortplasser med mulighet for utvidelse til 16 kortplasser. Disse kortene kan ha forskjellige eller like funksjoner. Uansett vil det være ønskelig å adressere hvert enkelt kort. I andre tilfeller kan det være ønskelig å sende data til alle kortene (broadcast). For å muliggjøre dette, er de fire minst signifikante bit i adresseordet satt av til kortadressering (figur 5). Når alle disse fire bit er satt, indikerer det. Dette medfører at det kun kan adresseres 15 individuelle kort. Mode Intern adressering på kortet Ubrukt Kort adr. 24 bit 3 bit 1 4 bit Figur 5: Adresseord i bussprotokoll Et -bit (bit 4) er satt av for å velge om det sendes ett eller flere dataord til samme adresse. Når dette bitet er aktivt (dvs. logisk 1), signaliserer det mode (figur 6). Ellers er det -mode (figur 7)Videre er det satt av 3 bit til framtidig bruk. Disse skal ikke brukes i dette prosjektet. De resterende 24 bit er brukt for å adressere innen hvert enkelt kort. I -mode, hvor det sendes flere dataord etter hverandre, må det kunne detekteres når siste ord kommer. For dette skal det brukes en kontrollinje i bakplansbussen som indikerer når siste ord i data-overføringen ligger klar. Side 9

10 Mode Intern adressering på kortet Ubrukt Kort adr. Adresse xxx xxx xxx 1 xxxx Data Data Siste Data Figur 6: Protokoll til bakplansbuss i MODE 1 (burst). Mode Intern adressering på kortet Ubrukt Kort adr. Adresse xxx xxx xxx 0 xxxx Data Figur 7: Bussprotokoll i MODE 0 (ikke burst) Da bakplansbussen ikke har noe logikk, må et av kortene være master på bussen. Dette kortet har da ansvar for arbitreringen på bussen, dvs. bestemme hvem som til en hver tid skal få lov til å bruke bakplansbussen. Terminalkortet skal fungere som master i vårt prosjekt, og må derfor ha noe ekstra logikk i forbindelse med bussgrensesnittet. Protokollen som skal brukes på bakplansbussen er beskrevet under. Signaler på bakplansbussen som skal brukes: 32 (DATA0 - DATA31) linjer for dataoverføring mellom kortene. Den som til en hver tid har fått lov av master til å bruke bussen driver linjene. Alle andre kort leser dem 7 (REQ0 - REQ6) linjer for request. Hvert kort på bussen, unntagen master, har kontroll over en egen linje. Denne brukes for å signalisere til masterkortet at en ønsker å bruke bussen. Adressen til hvert kort bestemmer hvilken av requestlinjene et kort har kontroll over 4 (GRT0 - GRT3) linjer for buss grant. Disse linjene er styrt av master og brukes for å angi hvilket kort som skal få bruke bussen Side 10

11 1 (START) linje for å signalisere at et kort starter å overføre data. Dette signalet må leses av alle kort for at de skal kunne vite når en adresseblokk er på databussen slik at de skal kunne finne ut når data sendes til dem 1 (STOP) linje for å signalisere at siste datablokk sendes. Denne brukes for å signalisere til master at en dataoverføring er i ferd med å bli avsluttet Som nevnt er det nødvendig at et kort fungerer som bussmaster og holder styr på bruken av bussen. Figur 8 viser et timingdiagram for hvordan dette skal fungere. Diagrammet tar utgangspunkt i en prioritetsutvelging (se punkt 5 under) for å velge neste bussbruker. Forklaring til diagrammet (antar at kun kort med adresse 0, 3, 4 og 6 er koblet til): CLK Data DATA DATA DATA ADR DATA DATA DATA ADR DATA DATA START STOP REQ4 3 REQ6 2 GRT3 GRT2 6 GRT1 GRT0 Figur 8: Timingdiagram for bakplansbus 1. Kort 3 holder på å overføre data 2. Kort med adresse 6 setter ut en request for bussen 3. Kort med adresse 4 setter ut en request for bussen 4. Kort 3 setter ut sin siste datablokk og setter samtidig STOP høy 5. Masterkortet (har adresse 0) detekterer at en dataoverføring er ferdig og gjør et valg for hvem som nå skal få overta bussen. Dette gjøres ved at det kortet med lavest adresse som har satt sin requestlinje høy velges 6. Busskontroll gis til kort 4 ved at grantlinjene settes i en periode 7. Kort 4 starter sin overføring ved å legge ut adressepakken, sette START høy og sette sin requestlinje lav igjen 8. Kort 4 setter ut sin siste datablokk og signaliserer dette på STOP-linjen 9. Master gjør et nytt valg av neste bussbruker og velger nå kort Kort 6 starter sin overføring Side 11

12 Alle kort som ikke er tildelt bussen, må monitorere START-linjen for å finne ut om andre kort starter å overføre data. Dersom linjen detekteres høy, må alle kortene lese adresse-datablokken (som da ligger på databussen) for å finne ut om overføringen er til seg. Hvis så, går kortet over i mottak-modus. Da mottas de(n) påfølgende datablokken(e) inntil STOP-linjen går høy. Da er overføringen ferdig. Hvis overføringen ikke er til seg, ignoreres databussen til neste STARTsignal. All skriving til bakplansbussen skal skje på stigende klokkeflanke, mens lesing fra bussen må skje på fallende klokkeflanke. Dette er nødvendig for å unngå timingproblemer. I denne protokollen er det fare for at et kort med lav prioritet (tilknyttet f.eks. request linje R7) må vente en stund før den får bruke bussen. Dette kan f.eks. skyldes at de andre kortene, som alle har høyere prioritet, hele tiden tar bussen. En mulig løsning på dette er å bruke en annen algoritme når master skal velge neste bussbruker (punkt 5 over). Side 12

13 I disse prosjektene må følgende gjøres. For begge kort: Lage kretskort Designe bussprotokoll og annen logikk i FPGAen Simulering og testing på alle plan Spesielt for terminalkort Skrive program til AVR mikrokontroller. Spesielt for DSP-kort Skrive program til DSP Til å lage kretskort skal det brukes et verktøy som heter VeriBest PCB. Dette programmet vil det bli gitt en introduksjon til. Oppgavene vil bli å lage, plassere og koble sammen komponenter på skjema. Deretter skal dette over til et foot-print hvor den fysiske plassering og utlegg av komponentene må gjøres. Deretter alle nett av VeriBest. Ferdig design sendes til produksjon i Bergen, og 14 dager senere står man fohåpentligvis med et kretskort i hånden. I mellomtiden skal såkalt før produksjons testing utføres. Det må skrives en programbit som tar seg av data som kommer inn på inngangene og en programbit som tar seg av data som skal ut. Data som kommer inn skal som regel gjennom et filter på en eller annen måte før det blir sendt ut igjen (figur 9). Denne filterdelen er det fritt fram å gjøre hva man vil med, men den må uansett implementeres i FPGAen. Mottak- og senderprosedyren må være slik at de kan gjenbrukes i et senere prosjekt. Ved oppstart må programmet dessuten initialisere CODECen (se CODEC databok). Det vil være mulig å teste ut disse programmene på et tilgjengelig DSP-testkort før de testes ut i hele systemet med bakplansbuss. DSP AD Data 6HULDOÃ6\QFURQ,QWHUIDFH Prosedyre som leser innregister. Ev. DMA. Prosedyre for Volum eller Filter (Bass, diskant ev. annet). 6HULDOÃ6\QFURQ,QWHUIDFH Prosedyre som skriver til utregister. Ev. DMA. Data DA Figur 9: Datavei i DSP. Side 13

14 Det vil bli gitt en innføring i virkemåte til denne mikrokontrolleren i en forelesing. Program skrives, testes og debugges i AVR-studio (software levert av ATMEL). Det kan skrives enten i assembly-kode eller i C-kode. AVR-studio ligger installert på de fleste maskinene på DMlabben. For de som ønsker å sitte hjemme å utvikle program er software fritt tilgjengelig på ATMEL s hjemmeside 1. Det må skrives rutiner for å lese av tastatur, skrive til display, kommunisere eksternt via RS232-porten og for kommunikasjon med andre kort. Fra ATMEL har DM-gruppa fått to testkort til AVR mikrokontrollere. Man plugger da inn mikrokontrolleren, kobler til en PC og tester ut programmet som er skrevet på den fysiske brikken. Design og testing foregår alt sammen med AVR-studio. AVR-programmene vil være mulige å teste på et eget testkort. For å lage design i FPGAen benyttes Foundation fra Xilinx. Dette er et verktøy det vil bli gitt en innføring i. En tutorial skal også gjennomgåes av studentene. Man lager hardware med skjemategning og/eller HDL-koding. Man syntetiserer designet mot den fysiske brikken som skal brukes og man får generert en bitfil som inneholder konfigurasjonen til FPGAen. Denne bitfilen kan så lastes ned via XChecker kabel eller en SPROM kan programmeres og brukes. Denne enheten konverterer analoge signaler til en seriell digital bitstrøm og motsatt. Den kan sample analoge signaler med maks samplingsrate på 48 khz. For eksakt virkemåte og funksjonalitet se dokumentasjon. CODECen må ha filter på alle utganger for å filtrere bort alle frekvenser over det hørbare området til øret. Dette må tas hensyn til ved utlegg av kretskort. Se dokumentasjon for kretsen. På de to inngangskanalene er det et innebygget filter som kan brukes. Det er fire trykknapper som kobles til FPGA og/eller mikrokontrolleren. Til fri bruk. Når det trykkes en tast, vil den tilhørende 4 bits binære verdien for tasten bli lagret i en egen brikke. Brikken genererer et interrupt til AVR-prosessoren slik at AVRen lese dette registeret og finne ut hvilken tast som ble trykket. I tillegg bør den trykkede tast vises som ekko i displayet. Alle tastene er nummerert fra 0 til 15 og presenteres som fire bits data. Displayet har en egen innebygd kontroller som gjør at man kan både lese og skrive til det. Tegn til displayet skrives med 8 bits bredde. Alle ASCII-tegn pluss mange fler kan skrives ut på displayet. Når systemet kjører bør det vises en form for meny slik at en kan velge hva en vil taste inn. Hvis man f.eks vil endre volum på en inn- eller utgangskanal på DSP-kortet må man via menyen i displayet og tastatur/trykknapper velge kort, kanal og volum for så å taste inn de nye parametrene (bare et forslag) Side 14