Home

Digitales Diktiergerät als System-on-a

1. kann von der Software nur mit O beschrieben werden 31 0 31 14 0 a 32 Bit Adresse en ee unbenutzt scalerup 31 98 0 31 0 EE unbenutzt 32 Bit Adresse Anzeige 1 an 0 aus Hexdisplay links Hexdisplay rechts Abbildung 4 9 Belegung und Adressen der Speicher abgebildeten Register In Abb 4 9 kann die Belegung und Funktion der Register die ab Adresse 0x800000200 im Speicher liegen abgelesen werden 4 5 2 Die Funktionen der Software Die Software enth lt die Testbench f r die Hardware und die eigentliche Anwen dung des Diktierger ts Zur Ansteuerung der Hardwarefunktionen sind die Zu griffe der Register in einzelne Funktionen verpackt worden Diese und einige weiterer Hilfsfunktionen werden nachfolgend erkl rt get_block Wegen der fehlenden dynamischen Speicherverwaltung wurde eine eigene vereinfachte Speicherverwaltung geschrieben Diese arbeitet KAPITEL 4 DIKTIERGER T ALS SOC 57 auf einem statischen Array Zur Initialisierung muss am Anfang des Programms die Funktion init aufgerufen werden Mit get_block kann ein 8 kByte gro er Speicherblock des Arrays angefordert wer den free_block Sie gibt einen mit get_block reservierten Speicherbereich wieder frei startrec Sie startet eine Aufnahme auf der Audiohardware Der Funktion muss die Anfangs und Endadresse der Aufnahme und ein Wert zur Konfiguration des Loopmodes bergeben werden s
2. synthesis gt syn_none iu gt iu_std fpu gt fpu_none cp gt cp_none cache gt cache_2k2k ahb gt ahb_std apb gt apb_std mctrl gt mctrl_std boot gt boot_mem debug gt debug_disas pci gt pci_none peri gt peri_std simulatiom with Insilicon PCI core constant sim_insilicon_pci config_type synthesis gt syn_none iu gt iu_std fpu gt fpu_none cp gt cp_none cache gt cache_2k2k ahb gt ahb_insilicon_pci apb gt apb_pci mctrl gt mctrl_std boot gt boot mem debug gt debug_disas pci gt pci_insilicon peri gt peri_std use AHB test module constant sim_ahb_test config_type synthesis gt syn_none iu gt iu_std fpu gt fpu_none cp gt cp_none cache gt cache_2k2k ahb gt ahb_test apb gt apb_pci mctrl gt mctrl_std boot gt boot_mem debug gt debug_disas pci gt pci_ahb_test peri gt peri_std synthesis using synplify 2 2 Kbyte cache constant synplify_2k2 config_type synthesis gt syn_synplify iu gt iu_fpga fpu gt fpu_none cp gt cp_none cache gt cache_2k2k ahb gt ahb_fpga apb gt apb_std mctrl gt mctrl_fpga boot gt boot_mem debug gt debug_disas pci gt pci_none peri gt peri_fpga synthesis using synplify internal boot prom soft constant synplify_2k2k_softprom config_type synthesis gt syn_synplify iu gt iu_fpga fpu gt fpu_none cp gt
3. Abbildung 4 3 Das Zeitverhalten der Taktsignale des AK4520A 4 3 2 APB Slave ber den APB Slave kommuniziert die CPU mit der Schaltung Die Konfigurati onsregister des Cores sind in den Speicherbereich des Systems gelegt und k nnen von der Software gelesen und geschrieben werden Uber diese wird der DDM Core gesteuert In der Zeichnung 4 4 ist zu sehen dass nicht alle Register gelesen und geschrieben werden k nnen Die Register werden in den weiteren Modulen des Cores verwendet und sind in den folgenden Abschnitten beschrieben Der APB arbeitet nach dem in Abschnitt 2 10 I beschriebenen Protokoll Y controlreg i Y gt startaddr Y _ PWDATA gt stopaddr i PSEL PENABLE PWRITE PADDR Y gt displaycontr Adressdecoder ALLA 1 j Y s PRDATA gt scalerup eo buttons L gt act_mem_adr i Core Ausgang Abbildung 4 4 Schaltung des APB Slave KAPITEL 4 DIKTIERGER T ALS SOC 51 4 3 3 Mikrotaster und Hexdisplay 7 Segment Encoder displaycontr Digit 1 7 8 7 4 3 0 _ Y 7 Segment Encoder Digit2 7 W Dispen Mikrotaster Y 8 0 buttons Core Ausgang Abbildung 4 5 Sc
4. CVSROOT memory mapped register Datencache ee mkprom 27 damo pi ModelSIM DDM Register ddm c ngd2vhdl ddm h ngdanno ddm_play ngdbuild ddm_record Designflow OpenRISC dispoff 57 GE 0 PAL B5 sgnmgr 22 par 22 eingebettetes System 7 Personalisierung 35 ERC32 I PLA exo Datei PLD 9 80 INDEX Programmierung promgen Registerwindows S Record Scalable Processor Architecture serielle Schnittstelle set_sample_freq seyon Simulation Gatterebene Simulation Registertransferebene SIS sis SoC Softcore SPARC sparc rtems gcc sparc rtems objcopy sparc rtems objdump Speicher abgebildete Register startplay startrec aen structure ddmregs syn Synthese System on a Chip target vhd tbench Tensilica tenv tenv32_back test Testbench trans trans_back tsource vcom Verzeichnisse 81 Virtual Socket Interface Alliance vlib vlog volatile VSIA f wait_for_audiofinish XC95108 XCheckeranschluss XCV800 XESS xsload xsport XSTOOLS_BIN_DIR XSV 800 XSV 800 Peripherie Ich versichere dass ich diese Arbeit selbst ndig verfasst und nur die angegebenen Hilfsmittel verwendet habe Daniel Bretz
5. Die Entity der neuen Schaltung wird in der Datei mcore vhd an das System angeschlossen In dieser Datei wird auch der In terruptcontroller mit dem Core verbunden Alle Leitungen die aus dem System herausf hren werden an die leon Entity weitergeben Die leon Entity wird da zu in leon vhd entsprechend ver ndert Um es auf dem XSV 800 betreiben zu k nnen muss auch die H lle um die LEON Plattform ver ndert werden Da das Design auch standalone betrieben wird und dazu das FlashRAM benutzt gibt es eine spezielle Ansteuerung f r die LEDs das ROM und das RAM Die Leitungen auf dem XSV 800 Board zum Flash und zu den LEDs der 7 Segementanzeigen sind dieselben Am Anfang muss ber diese der ROM Code geladen werden Nachdem das Programm im RAM ausgef hrt wird k nnen ber die Leitungen die LED Anzeigen angesteuert werden Dazu gibt es in dem ddm vhd Design das Ausgangssignal dispen ber diese Leitung kann die Software zwischen ROM Betrieb und Anzeige Betrieb umschalten In dem H lldesign ist die Entity se lector2 eine Weiterentwicklung von der Entity selector f r die Umschaltung zwischen ROM und Anzeige verantwortlich Damit das System korrekt bersetzt und synthetisiert wird sind die Build skripte entsprechend angepasst Die AMBA Konfiguration ist f r den AHB Ma ster und den APB Slave in der Datei target vhd entsprechend ge ndert Die AHB Master ist auf die Anzahl 2 erh ht worden In der Liste der APB Slaves wurde ein neuer Eintrag e
6. Hauptverzeichnis gestartet werden Nur durch Aufruf aus dem Hauptverzeichnis findet es das Verzeichnis tsource und die darin befindlichen Programmdateien In dem Hauptverzeichnis befindet sich ebenfalls ein Makefile welches die Makefiles in den Unterverzeichnissen ausf hrt Damit k nnen mit einem Aufruf alle Quellen bersetzt werden Durch Auswahl einer Testbench Konfiguration tbdef tb_32_0_32_0 usw wird das Design geladen und kann mit run gestartet werden 67 Anhang C Portierung der XESS Software nach LINUX XESS liefert mit dem XSV 800 Board nur Software f r Microsoft Windows F r die Abteilung Rechnerarchitektur die in ihren Rechnerpools nur Unix Maschinen betreibt h tte dies die Installation eines Windowsrechners bedeutet Gl cklicher weise liefert XESS den Quelltext f r ihre Software mit Dadurch wurde es m g lich sie nach Linux zu portieren Die Umsetzung erfolgte nur f r die Eingabeauf forderung basierten Werkzeuge also nicht f r die mit grafischer Benutzungsober fl che Mit ihnen ist aber der volle Betriebsumfang des Boards m glich Der Quelltext lag in der Version 3 0 vor Auf Grund der guten Portierbarkeit von C und C so wie Vermeidung von Verwendung der MFCin dem Quelltext musste nur wenig angepasst werden Der gr te Teil bezieht sich dabei auf die nderung der Verz gerungsschleifen f r das Zeitverhalten der Programmierung der parallelen Schnittstelle und nderung des Programms xsload so dass
7. SS 3 1 XSV 800 Board bersicht 4 1 Entwicklungszyklus einer Anwendung auf der Plattform 4 2 bersicht ber den DDM Core en ee a e 4 5 Schaltung Mikrotaster und Hexdisplay cam e e EE EE 4 7 Schaltung der Audio Ansteuerung Moa eee air ai EE Kapitel 1 Einleitung Menschen haben heute im Alltag an vielen Stellen mit elektronischen Schaltkrei sen zu tun ob bewusst oder unbewusst Meist sind dies eingebettete Systeme also Schaltungen die in einem Gesamtsystem eingebettet sind und die Aufgaben der Steuerung oder Signalverarbeitung bernehmen Man findet sie zum Beispiel bei Kraftfahrzeugen im Antiblockiersystem ABS der Motorsteuerung dem Ra dio der Klimaanlage und vielem mehr Gerade in der Signalverarbeitung werden dabei spezielle Funktionen in die Schaltung integriert Die Umsetzung der Sy steml sungen erfolgt in eingebetteten Systemen oft als Mischung von Hardware und Software 1 1 System on a Chip Entwicklung Die heutigen Integrationsdichten erm glichen es viele verschiedene Funktionen auf einem Chip unterzubringen Damit kann ein System das fr her in mehreren Chips auf einer Platine untergebracht war in einem einzigen Chip integriert wer den Dies erh ht die Geschwindigkeit der Kommunikation der Schaltungen un tereinander und senkt den Energieverbrauch Das System braucht weniger Platz und die Herstellung eines einzigen Chips ist preisg nst
8. 1 First last index split enable function HADDR 31 28 0000 OLLI 0 false true memory controller 0x0 0x7 1000 1000 17 false true APB bridge 128 MB 0x8 0x8 others gt ahb_slv_config_void AHB test slave config constant ahbslvcfg_test ahb_slv_config_vector 0 to AHB_SLV_MAX 1 first last index split enable function HADDR 31 28 0 000 SOLES 0 false true memory controller 0x0 0x7 ANHANG D DATEI AUSZ GE 74 1000 1000 1 false true APB bridge 128 MB 0x8 0x8 TLOLO LOTO 025 true true AHB test module OxA OxA 21100 TLELI 3 false true PCI initiator 0xC OxF others gt ahb_slv_config_void PCI slave config constant ahbslvcfg_pci ahb_slv_config_vector 0 to AHB_SLV_MAX 1 First last index split enable function HADDR 31 28 C0000 TOLLE 0 false true memory controller 0x0 0x7 1000 1000 gt hy false true APB bridge 128 MB 0x8 0x8 OTON ATIII 22 false true PCI initiator OxA OxF others gt ahb_slv_config_void standard cacheability config constant ahbcachecfg_std ahb_cache_config_vector 0 to AHB_CACHE_MAX 1 first last function HADDR 31 29 000 000 PROM area 0x0 0x0 COLO WOLLT RAM area 0x2 0x3 others gt ahb_cache_config_void standard config record constant ahb_std ahb_config_type masters gt 1 defmst gt 0 split gt false slv
9. Audiobausteins im Bereich der Samplefrequenz also im kHz Bereich zu erzeugen wurde der Timer mit einem KAPITEL 4 DIKTIERGER T ALS SOC 52 scalerup 1 scaler tick mstelk gt melk 1 E Y i gt rscaler ek sclk e scik sclk_old I sclk_old Abbildung 4 6 Schaltung des Timers 14 Bit breiten Z hler ausgelegt Da der Takt des mclk des Audiobausteins aber den 256 fachen Takt der Samplefrequenz ben tigt liegt dieser im MHz Bereich Der AK4520A ist f r Frequenzen von 4096 bis 13824 kHz f r den mclk spezifi ziert Das bedeutet bei einem Systemtakt von 20 MHz dass nur die Werte 0 10 MHz und 1 5 MHz f r das Register scalerup sinnvoll sind Es ist daher f r diese Aufgabe etwas gro z gig ausgelegt W hrend der Tests wurde aber auch ein Wert von 2 erfolgreich eingesetzt Aus den Ticks des Z hlers wird auch der Schiebetakt generiert Dazu z hlt ein 2 Bit breiter Z hler rscaler die Ticks vom Z hler scaler Steht der rscaler auf 0 wird ein Tick mit dem der Inhalt des Flipflop sc k negiert wird ausgel st Der sclk hat dadurch genau die ben tigte ein Viertel so schnelle Frequenz des Mastertakts Damit die Logik im Prozess ddmtop auf die steigende Flanke des sclk reagieren kann wird es durch ein weiteres FlipFlop gesteuert An diesem sclk_old liegt d
10. Bereiche IU FPU CP Coprozessor Cache Speicherschnittstelle Boot PCI Peripherie Debug und AMBA einge teilt Die meisten Parameter sprechen mit ihren Namen dabei f r sich selbst Es werden kurz die wichtigsten daraus erkl rt In dem Bereich Boot werden die verschiedenen M glichkeiten des Systemstart konfiguriert Dieser kann durch Setzen der Variable boot auf e memory Boot vom ROM e prom Boot vom internen BPROM 3die Datei ist ab dort im Anhang aufgef hrt KAPITEL 2 DIE LEON PLATTFORM 26 e icache Boot aus vorinitialisiertem Cache ausgew hlt werden Die restlichen Einstellungen sind nur f r das interne BPROM relevant Im Abschnitt Debug k nnen fiir die Simulation Debugoutputs eingeschaltet werden Interessant ist der Parameter uart der erm glicht dass die UARTs auf der Standardausgabe ausgegeben werden So kann unter ModelSIM die Text ausgabe der Programme verfolgt werden Eine Texteingabe ist nicht m glich Diese ist zwar mit VHDL realisierbar Ash96 doch ist es problematisch den Zeitpunkt f r die Eingabe zu finden Die Simulation w rde dazu stehen bleiben m ssen Eingaben w hrend der Simulation machen ohnehin wenig Sinn da diese bei einem realen Takt von ungef hr 75 Herz viel zu langsam l uft um gr ere Programme darauf auszuf hren Im restlichen Teil der Datei target vhd stehen die zur Auswahl stehenden Syn thesemodelle die mit dem Eintrag in device vhd ausgew hlt werden 2 9 Programmierun
11. Daten aus dem FlashRAM personalisiert Ein so programmiertes Board kann bei Stromzu fuhr sich selbst konfigurieren und damit standalone betrieben werden In Abb ist eine bersicht ber das Board zu sehen Sie ist stark vereinfacht und enth lt nur die Komponenten die in der Arbeit verwendet wurden 3 6 CPLD Synthese Bei der mitgelieferten Software des XSV 800 Board waren die drei n tigen Desi gns f r das CPLD um das FPGA zu programmieren enthalten Diese em glichen aber nicht die ben tigte Kommunikation der LEON Designs auf dem FPGA ber die serielle Schnittstelle Die Schnittstelle ist nur an dem CPLD angeschlossen und ist in den mitgelieferten Designs nicht durch das CPLD durchgef hrt Des wegen wurden die urspr nglichen Designs von Xess welche in und beschrieben werden ge ndert Die nderung sind nur bei den zweien die den FPGA personalisieren von den dreien n tig da bei der Programmierung des FlashRAMs keine Verbindung vom FPGA zur seriellen Schnittstelle ben tigt wird F r den Zweck der nderung an dem Design welches das FPGA direkt ber die parallele Schnittstelle programmiert konnte auf eine fertige Arbeit im Internet zur ckgegriffen werden Sie musste noch synthetisiert werden Der Designflow f r das CPLD unterscheidet sich zu dem vom FPGA SynopsysDC ben tigt ledig lich andere Bibliotheken Nach Benutzung des Xilinx Werkzeugs ngdbuild l uft der Designflow aber einen komplett anderen Weg Es werden dazu die X
12. Erkl rung mit erforderlicher Belegung KAPITEL 2 DIE LEON PLATTFORM 31 Ti T2 T3 T4 T5 T6 T7 HoLK AAA HBUSREQx J i i HGRANTx Ir i i HREADY f f HADDRI 31 0 X Adresse Control Control HWDATA 31 0 Data HRDATA 31 0 Data Adressbus Owner _Datenbus Owner ben SE a gt u E Bus request Grant Adresse Daten Daten Daten warten und transfer anlegen transfer auf Control Start fertig HREADY data im n chsten wegen 1 Takt Takt HREADY wegen HREADY Abbildung 2 6 Simpler Datentransfer auf AHB f r einen einzelnen Transfer in eckingen Klammern HTRANS 1 0 Gibt den Zustand und die Art der Daten bertragung an IDLE BUSY NONSEQ SEQ Es kann passieren dass der Arbiter dem Master em GRANT signalisiert obwohl dieser kenen REQUEST ge startet hat In diesem Fall muss der Master nach AHB Spezifikation mit IDLE antworten NONSEQ HBURST 2 0 Gibt die Art des Burst an SINGLE INCR WRAP4 INCR4 WRAPS INCR8 WRAP16 INCR16 SINGLE HSIZE 2 0 Gibt die Datenl nge des Transfers an 8 16 32 Word 64 128 256 512 1024 Bits Word Bei Zugriffsfehlern Zugriffsverz gerungen oder sonstigen Ereignissen gibt der Slave entsprechende Meldung ber die Leitung HRESP 1 0 Normalerweise legt der Slave bei erfolgreichem Zugriff ein OKAY darauf an In dem einzelnen Zugriff des hier verwendeten Masters wird dieses Signal nicht ausgewert
13. Tech nologie Sie stammt noch aus den lteren LEON Versionen ohne BPROM und wurde in dieser Arbeit nicht benutzt KAPITEL 2 DIE LEON PLATTFORM 27 Von dem internen BPROM zu starten ist die zweite M glichkeit In dem 1 kByte gro en ROM steht ein Programm dass systematisch den Speicher unter sucht und danach die Speicherkonfigurationsregister von LEON setzt Nach dem Initialisieren wartet es auf die bertragung eines Programms auf der seriellen Schnittstelle Das Programm muss dazu im S Record Format vorliegen Ein vom Compiler erzeugtes Binary kann mit sparc rtems objcopy O srec adjust vma 0x40000000 set start 0 lt binary gt lt binary srec gt in die ben tigte Form gebracht werden Am Ende der erzeugten Datei steht auch eine Startanweisung die das Programm nach Ubertragung startet S Records sind ASCII Strings die mit einem S beginnen Gefolgt wird dies von der Typenkennung des S Records der Anzahl enthaltener Datenbytes und der Zieladresse im Speicher Danch kom men die eigentlichen Daten gefolgt von einer Pr fsumme Alle Zahlenwerte sind dabei Hexadezimalwerte in ASCII Darstellung Als letzte Methode das System zu starten wird ein herk mmliches externes ROM verwendet Da dies viel gr er sein kann als das BPROM kann die gan ze Anwendung in diesem untergebracht werden Dazu muss das Programm mit einem Bootheader versehen werden Dieser wird mit dem Werkzeug mkprom er zeugt Die Benutzung des Werkzeugs ist in e
14. ausgef hrt F r eigene Hardwareentwick lungen ist es jedoch interessant eigene Programme im normalen Betriebsumfeld auszuf hren Damit l sst sich diese Software in sehr realen Bedingungen testen und bietet vor allem die M glichkeit dazugef gte Hardware zu testen Mit Simu lation ist z B sehr gut die Validierung der Kommunikation der LEON Plattform mit der UDF ber den AMBA Bus m glich Um die Simulation unter norma len Betriebsbedingungen auszuf hren wurde die urspr ngliche Testbench abge ndert Die Speichermodelle f r RAM und ROM wurden bernommen die Ansteue rung f r den Testbenchablauf jedoch entfernt Die seriellen Schnittstellen sind nicht mehr gegenseitig miteinander verbunden Es entstehen keine f r die Test bench ben tigten Ereignisse von au en an dem System Das System wird nur mit den RAM und ROM Zellen verbunden und bekommt den Takt und das Reset signal vorgegeben Damit die CPU andere Programme ausf hrt muss der Inhalt der Datei rom dat in tsource ge ndert werden Wie dies zu erfolgen hat wird in Abschnitt 9 beschrieben Die ver nderte Testumgebung befindet sich in dem Verzeichnis tenv In ihr ist wie auch bei der Testbench ein Makefile f r die bersetzung vorhanden In dem Verzeichnis tenv32_back befindet sich eine leicht abge nderte Version der Testumgebung Diese ist f r die Simulation des LEON Designs f r das XSV 800 Board auf Gatterebene erforderlich und wird im Kapitel B n her beschriebe
15. bekommen muss das Xilinx Design flas hprg svf im Verzeichnis xsvsoft auf das CPLD geladen werden Dies geschieht allerdings automatisch wenn xsload eine exo Datei zum Laden bergeben be kommt Hierf r ist der richtig gesetzte Pfad in XSTOOLS_BIN_DIR wichtig In der exo Datei k nnen die mit promgen erzeugten Daten des FPGA Designs ste hen siehe 2 6 Sind die Designdaten der exo Datei auf dem Flash gespeichert muss auf das CPLD die Datei flash_to_fpga svf aus dem Verzeichnis cpld gela den werden Es enth lt die zum Design flashcfg svf von Xilinx ge nderte serielle Verbindung und l dt nach Stromzufuhr das Design aus dem Flash in das FPGA F r die serielle Verbindung wurden die letzten vier freien Leitungen vom CPLD zum FPGA verwendet da alle anderen Leitungen f r den Bootvorgang der CPU aus dem Flash ben tigt werden Nach dem Laden des Designs auf das FPGA beginnt die CPU zu starten Ist sie mit integriertem BPROM synthetisiert f hrt sie den 1 kByte gro en Bootloader darin aus Dieser initialisiert die beiden Speicherkonfigurationsregister und gibt eine Bootmeldung auf der seriellen Schnittstelle aus Um diese auf dem Rech ner auszugeben muss ein Nullmodemkabel vom XSV 800 Board mit dem Linux PC verbunden werden Mit einem Terminalprogramm wie seyon oder minicom werden diese auf dem Bildschirm dargestellt Die Standardeinstellungen f r die serielle Schnittstelle sind 38400 Baud mit acht Datenbits keine Pr fsumme und ein Stopbit 8N
16. cp_none cache gt cache_2k2k ahb gt ahb_fpga apb gt apb_std mctrl gt mctrl_fpga boot gt boot_prom debug gt debug_disas pci gt pci_none peri gt peri_fpga synthesis using synplify internal boot prom virtex only constant synplify_2k2k_virtexprom config_type synthesis gt syn_synplify_vprom iu gt iu_fpga fpu gt fpu_none cp gt cp_none cache gt cache_2k2k ahb gt ahb_fpga apb gt apb_std mctrl gt mctrl_fpga boot gt boot_prom debug gt debug_disas pci gt pci_none peri gt peri_fpga synthesis using leonardo 2 2 Kbyte cache constant leonardo_2k2 config_type synthesis gt syn_leonardo iu gt iu_fpga fpu gt fpu_none cp gt cp_none ANHANG D DATEI AUSZ GE Cache gt cache_2k2k boot gt boot_mem ahb gt ahb_fpga apb gt debug gt debug_disas synthesis using leonardo constant leonardo_2k2k_softprom config_type synthesis gt syn_leonardo iu gt iu_fpga cache gt cache_2k2k ahb gt ahb_fpga apb gt boot gt boot_prom debug gt debug_disas pci synthesis for VIRTEX constant gen_virtex_2k2k config_type synthesis gt syn_virtex iu gt iu_fpga cache gt cache_2k2k ahb gt ahb_fpga apb gt boot gt boot_mem debug gt debug_disas any syntool synthesis for VIRTEX any syntool xess16 constant gen_virtex_2k2k_xess16 config_type synthesis gt syn_virtex iu gt
17. der Peripherie und zeitkritische Aufgaben sollte aber m glichst vielseitig nutzbar ausgelegt sein Die Software implemen tiert auf der Hardware die eigentliche Funktion des Systems in diesem Fall das Diktierger t Die Hardware und Softwareentwicklung K nnen nach der Spezifi kation parallel erfolgen In der Arbeit liefen diese aber nacheinander ab Als erstes sollte bei der Hardwareumsetzung ein Probedesign zur Ansteuerung der Peripherie entworfen werden F r das Diktierger t ist dies ein Testdesign zur 45 KAPITEL 4 DIKTIERGER T ALS SOC 46 Audioansteuerung Dieses ist in der Datei soundtest vhd zu finden Es kann direkt ohne das restliche System auf der Hardware getestet werden Dadurch k nnen schneller Fehler im Zeitverhalten der Signale aufgedeckt werden wodurch der Entwicklungszyklus viel schneller abl uft Nach erfolgreicher Ansteuerung wird die eigentliche Schaltung des Cores entworfen Um die grundlegenden Funk tionen der Hardware testen zu k nnen wird eine eigene Testumgebung daf r geschrieben Damit wird die zeitaufwendige Simulation des gesamten Systems umgangen Zu den Grundfunktionen z hlt beim Diktieriger t die Generierung der Taktsignale f r den Audiobaustein und das korrekte Schieben der Audiodaten Die Schaltung enthielt bei diesem Test aber alle ben tigten Komponenten und konn te jederzeit mit dem gesamten System bersetzt werden Zur Simulation werden aus diesem Grund auch die Dateien target vhd config vd
18. die Leitungen mit an deren zum FPGA teilen m ssen kommt auf dem Board mehrfach vor was an der begrenzten Anzahl von Anschl sse am FPGA liegt KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD 33 3 2 PLDs Um gr ere Schaltungen auf einem Chip unterzubringen ohne ASICs zu verwen den gibt es die programmierbaren Bausteine PLD programmable logic device Beim klassischen PLD kann dabei eine in disjunktiver Normalform vorliegende Funktion in den Chip programmiert werden Dabei laufen die Eingangssignale ber programmierbare Verbindungsstellen zuerst durch eine UND Matrix Das Ergebnis der UND Matrix wird danach entweder ODER Verkn pft oder an eine programmierbare ODER Matrix weitergeleitet wobei die Ausgabesignale entste hen Wie genau die ODER Verarbeitung aussieht unterscheidet die Bausteine in programmable array logic PAL programmable logic array PLA und generic array logic GAL Bei letzterem kann durch Zur cksteuern der Ausg nge auf die Eing nge und Hinzuf gen einer Speicherzelle an den Ausg ngen mehrstufige und sequentielle Logik umgesetzt werden PALs und PLAs sind auf zweistufige Logik begrenzt Um weitaus komplexere Schaltungen auf einem Chip zu programmieren gibt es Complex Programmable Logic Devices CPLD und die Field Programmable Gate Arrays FPGA Jen94 Beide beruhen auf den sogenannten Configurable Logic Blocks CLBs Diese Bl cke k nnen vergleichbar mit den klassischen PLDs logische Funktionen mi
19. die wahlweise f r Solaris oder Linux angeboten wird Im Detail enthalten die Pakete folgende Bestandteile Quelltext KAPITEL 2 DIE LEON PLATTFORM 15 e VHDL Code f r die LEON Plattform e Makefiles und Buildskripte f r die Synthese und Simulation e Eine Testbench mit Quelltext und die dazugeh rige Simulationsumgebung f r Speicher und Datenauswertung e bprom Generator Quelltext f r ein internes BootROM und ein Programm dass eine VHDL Beschreibung aus dem ROM erzeugt Softwareentwicklung e GNU C C Ada Crosscompiler Gai99 Sta98 e GNU Binutils e Cygnus Newlib standalone C Bibliothek e RTEMS Kernel mit LEON Unterst tzung e mkprom Werkzeug erzeugt aus den vom Compiler erzeugten Binaries ein ROM e SIS LEON Instruktionslevelemulator e DDD als Graphische Benutzungsoberfl che f r gdb 2 3 Struktur der Quelltexte und Verzeichnisse In diesem Abschnitt wird der Aufbau der Verzeichnisse und Dateien des LEON Projekts beschrieben Zu dem von der ESA bezogenen Quelltext sind noch wei tere bei der Arbeit entstandene Verzeichnisse dazugekommen Nach dem Ent packen des LEON Quelltext Archivs von der ESA oder dem Aushecken der Sour cen aus dem CVS Projekt Leon 1 siehe Anhang A 2 bekommt man ein Verzeich nis mit folgenden Unterverzeichnissen leon die VHDL Quelltexte von LEON doc in diesem ist das LEON Handbuch Gai00a zu finden tbench die Testbenchumgebung f r ModelSIM in VHDL syn das Syntheseverzeichnis
20. false constant cache_8k8k cache config type icachesize gt 8 ilinesize gt 8 dcachesize gt 8 dlinesize gt 4 bootcache gt false constant mctrl_std mctrl_config_type bus8en gt true busl6en gt true rawaddr gt false constant mctrl_fpga mctrl_config_type bus8en gt true busl6en gt true rawaddr gt false constant mctrl_mem32 mctrl config type bus8en gt false busl6en gt false rawaddr gt false constant mctrl_bprom mctrl_config_type bus8en gt false busl6en gt false rawaddr gt false constant mctrl_xess16 mctrl config type bus8en gt false busl6en gt true rawaddr gt false ANHANG D DATEI AUSZ GE 73 boot configurations constant boot mem boot _ config type boot gt memory promabits gt 1 ramrws gt 0 ramwws gt 0 sysclk gt 20000000 baud gt 38400 extbaud gt false constant boot_prom boot_confiq type boot gt prom promabits gt 8 ramrws gt 0 ramwws gt 0 sysclk gt 20000000 baud gt 38400 extbaud gt false constant boot_cache boot_config_type boot gt icache promabits gt 8 ramrws gt 0 ramwws gt 0 sysclk gt 20000000 baud gt 38400 extbaud gt false constant boot_prom_xessl6 boot_confiq type boot gt prom promabits gt 8 ramrws gt 0 ramwws gt 0 sysclk gt 20000000 baud gt 38400 ext
21. gt true constant syn_synplify syn_config_type syntool gt synplify targettech gt gen infer_pads gt true infer_ram gt true infer_regf gt true infer_rom gt true gatedclk gt false rfsyncrd gt true rfsyncwr gt true constant syn_synplify_vprom syn_config_type syntool gt synplify targettech gt gen infer_pads gt true infer_ram gt true infer_regf gt true infer_rom gt false gatedclk gt false rfsyncrd gt true rfsyncwr gt true constant syn_leonardo syn_config_type syntool gt leonardo targettech gt gen infer_pads gt true infer_ram gt true infer_regf gt true infer_rom gt true gatedclk gt false rfsyncrd gt true rfsyncwr gt true constant syn_virtex syn_config_type syntool gt synplify targettech gt virtex infer_pads gt true infer_ram gt false infer_regf gt false infer_rom gt true gatedclk gt false rfsyncrd gt true rfsyncwr gt true constant syn_virtex_vprom syn_config_type syntool gt synplify targettech gt virtex infer_pads gt true infer_ram gt false infer_regf gt false infer_rom gt false gatedclk gt false rfsyncrd gt true rfsyncwr gt true constant iu_std iu_config_type nwindows gt 8 multiplier gt iterative fpuen gt 0 cpen gt false 71 ANHANG D DATEI AUSZ GE 72 fastjump gt false icc
22. iu_fpga pci gt pci_none internal boot prom fpu gt fpu_none fpu gt fpu_none pci gt pci_none fpu gt fpu_none 76 apb_std mctrl gt mctrl_fpga peri gt peri_fpga soft cp gt cp_none apb_std mctrl gt mctrl_fpga gt pci_none peri gt peri_fpga cp gt cp_none mctrl gt mctrl_std peri gt peri_fpga apb_std cp gt cp_none cache gt cache_2k2k ahb gt ahb_fpga apb gt apb_std mctrl gt mctrl_xess16 boot gt boot_mem debug gt debug_disas pci gt pci_none peri gt peri_fpga synthesis for VIRTEX any syntool soft boot prom constant gen_virtex_2k2k_bprom config_type synthesis gt syn_virtex iu gt iu_fpga fpu gt fpu_none cp gt cp_none cache gt cache_2k2k ahb gt ahb_fpga apb gt apb_std mctrl gt mctrl_bprom boot gt boot_prom debug gt debug_disas pci gt pci_none peri gt peri_fpga synthesis for VIRTEX any syntool soft boot prom xess16 constant gen_virtex_2k2k_bprom_xess16 config_type synthesis gt syn_virtex iu gt iu_fpga fpu gt fpu_none Cp gt cp_none cache gt cache_2k2k ahb gt ahb_fpga apb gt apb_std mctrl gt mctrl_xess16 boot gt boot_prom_xess16 debug gt debug_disas pci gt pci_none peri gt peri_fpga synthesis for VIRTEX any syntool hard boot constant gen_virtex_2k2k_vprom config_type synthesis gt syn_virte
23. nderungen der Cachearchitektur als teil oder vollassoziativen Ausf hrung sind angek ndigt worden Varianten mit niedriger Leistungsaufnahme werden diskutiert Die Im plementierung einer FPU und MMU werden auch in ferner Zukunft kommen Dank der SPARC Kompatibilit t ist es leicht Software auf das System umzuset zen So ist nach Berichten neben dem mitgelieferten RTEMS Betriebssystem 4 CLinux zum gr ten Teil auf der Plattform einsatzbereit Neben den freien Entwicklern haben aber auch kommerzielle Firmen Produkte mit LEON ange k ndigt LEON steht damit eine gro e Zukunft offen Ob LEON jedoch eine Konkurrenz zu kommerziellen Systemen wie ARM MIPS usw sein kann wird sich erst zeigen m ssen Um im Bereich der eingebetteten Systeme konkurrie ren zu k nnen muss LEON f r ASIC Prozesse synthetisiert werden F r die Technologie Atmel ATC35 ist das Design vorbereitet Durch die Offenheit des 61 KAPITEL 3 ZUSAMMENFASSUNG UND AUSBLICK 62 Systems neue Technologien zu integrieren kann es aber auch leicht an neue an gepasst werden Firmen wie Metaflow haben schon Produkte mit LEON angek ndigt Doch ist LEON den aktuellen von Firmen entwickelten Systemen noch um einige Schritte hinterher Anhang A CVS CVS Concurrent Versions System ist ein Verwaltungssystem f r Quell texte Es erm glicht verschiedene Versionen der Quelltextdateien zu archivieren und verwalten Dazu gibt es einen CVS Server auf dem die Daten gelagert wer de
24. r Virtex ist verbessert in die Datei tech_virtex vhd bernom men worden Das Einf gen der Pads in das Design funktioniert ab LEON 2 2 mit Synopsys automatisch weswegen Padmodelle in der Datei nicht mehr ben tigt werden Dies hat gro e Vorteile f r das sp ter in der Arbeit verwendete H ll design siehe Abschnitt 3 7 fiir das XSV 800 Board welches um das LEON Design gelegt werden musste Waren dabei die Pads fest eingebunden miissten diese entfernt und in dem neuen Design eingebaut werden Bei der LEON Version 2 2 liegt ein Prototyp des Buildskriptes fiir die Synthese mit SynopsysDC bei und musste an die Zieltechnologie angepasst werden Dies sind vor allem Eintr ge f r das Einf gen der Pads dem richtigen Zeitverhalten und dem Laden der richtigen Xilinx Bibliotheken Am Ende der Arbeit lagen drei verschiedene Designs f r das XSV 800 Board vor Sie unterscheiden sich in der Speicheransteuerung und im Bootvorgang F r jedes von ihnen existiert in dem Verzeichnis syn ein entsprechendes Skript Die Erweiterung der Dateien ist de dc Datei Mit dem Aufruf von dc_shell f lt skriptname gt wird ein Syntheselauf gestartet Am Ende der Synthese steht eine edif Datei des entsprechenden Designs in dem Verzeichnis 2 6 Xilinx Designflow Nachdem ein Design synthetisiert ist liegt es in einer Beschreibung auf Gattere bene vor Die zieltechnologischen Abh ngigkeiten sind dabei nur auf ein paar spe zielle Zellen begrenzt Damit es auf eine
25. te Leistung erreichen doch ist sie f r einige Schaltungsentw rfe wegen des gro en Entwicklungsaufwandes zu unrentabel Um die Entwicklungskosten der ASICs zu senken werden neue Wege in der Entwicklung gegangen Dabei werden vor allem die hohen Kosten der Maskenerstellung f r die Prototypen um gangen indem man die Schaltung auf andere Art validiert Um Schaltungen auf einem Chip unterzubringen ohne einen ASIC Entwurf zu benutzen gibt es die programmierbaren Bausteine programmable logic devi ce PLD Mit der Zeit hat sich ein ganzes Spektrum von diesen Bausteinen ent wickelt Die h chste Entwicklungsstufe sind die FPGAs Auf ihnen k nnen sehr komplexe Schaltungen wie z B ein Mikroprozessor abgebildet werden Gr te Verwendung finden die FPGAs in der Hardwarevalidierung die auf zwei Arten erfolgen kann Zum einen werden die FPGAs in Simulationsumgebungen zur schnellen Berechnung von logischen Funktionen verwendet Dazu werden meh rere FPGAs in einem System parallel betrieben Die andere M glichkeit ist eine Schaltung komplett als Prototyp auf ein einziges FPGA abzubilden was durch die heute sehr komplexen Bausteine m glich ist Die abgebildete Schaltung kann im Gegensatz zur reinen Simulation mit hohen Geschwindigkeiten betrieben werden Wenn die Funktionalit t der Schaltung validiert ist wird sie auf die eigentlichen Zieltechnologie abgebildet Die Entwicklungszeit wird dadurch reduziert und die Entwicklung kostet weniger Geld r
26. 1 Nach der Bootmeldung wartet der Bootloader auf die ber tragung eines auszuf hrenden Programms im S Record Format siehe 2 9p Das Programm kann mit cat lt Programm srec gt dev ttyS0 bertragen werden Es kann ebenfalls mit einem ASCII upload aus den Terminalprogrammen geschehen An schlie end wird das Programm auf LEON ausgef hrt Nach jedem Reset muss das Programm erneut bertragen werden Um das System aus dem FlashRAM zu booten m ssen die ROM Daten in das obere MB des Flashs geschrieben werden Ein entsprechendes ROM wird mit mkprom erzeugt F r das RAM sind dabei keine 0 Waitstates n tig da die KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD 44 Zugriffszeit des RAMs 19 ns kleiner als ein Takt 50 ns ist Da das Flash eine wesentlich gr ere Zugriffszeit 85 ns hat m ssen bei diesem 2 Waitstates ver wendet werden Das erzeugte ROM kann anschlie end mit sparc rtems objcopy in das S Record Format gewandelt werden welches von den exo Dateien ver wendet wird Die Zieladresse muss dabei auf 0x100000 ge ndert werden damit die Daten in das oberer MB des Flashs geschrieben werden Zus tzlich muss die Initialisierungs und Startanweisung aus dem S Record entfernt werden Ein fer tiges Makefile zur Erzeugung einer solchen exo Datei steht in ddm software Da mkprom in der derzeitigen Version noch nicht alle Features der Speicherschnitt stelle unterst tzt wird auch der ROM Code von dem Makefile angepasst In dem RO
27. 32 welcher die Version 7 implementiert LEON ist eine komplette Neu entwicklung der ESA und wurde als eingebettete Plattform ausgelegt worin sie sich haupts chlich von dem ERC32 unterscheidet Bemerkbar macht sich dies an den integrierten Schnittstellen wie UARTs parallele I O Schnittstelle PCI und vor allem an der Schnittstelle f r Coprozessoren und dem Systembus an dem UDF Cores angeschlossen werden k nnen Der Quelltext der Hardware des LEON stehen unter der LGPL d h dass alle nderungen die die urspr ngliche Plattform betreffen ver ffentlicht werden m ssen Eigene entwickelte Cores die an dem System angeschlossen werden m ssen aber nicht ver ffentlicht werden Der restliche Quelltext von LEON wie z B der der Testbench stehen unter der GPIP oder sind wie die des Instruktionslevelemulators nicht erh ltlich 2 1 1 Aufbau der LEON Plattform Im Februar 2000 wurde LEON in einer ersten Version der ffentlichkeit vorge stellt und zum Herunterladen von dem ESA Server angeboten Es war die LEON 1 Version 2 0 Auf diese folgte eine vor allem Fehler korrigierte und leicht verbesserte Version 2 1 Die Diplomarbeit beruht auf der LEON 1 Version 2 2 welche seit Okt Nov 2000 erh ltlich ist Seither wird die von ARM spezifizierte Advanced Microcontroller Bus Architecture AMBA benutzt LEON ist mit der Scalable Processor ARChitecture SPARC in der Version 8 kompatibel Diese als IEEE P1754 definierte Spezifikation ist eine frei be
28. DATA Y 32 f j audiobuffer ji HWDATA l l I l 1 Core Ausgang Abbildung 4 8 Schaltung des AHB Master Der AMBA Master ist f r das Schreiben und Lesen der Audiodaten in oder aus dem Speicher verantwortlich Bei jeder DMA Transferanfrage durch die Au dioansteuerung fordert er die Kontrolle ber den AMBA Bus vom Arbiter an Nachfolgend wird das Protokoll aus Abschnitt 2 10 2 benutzt Als Speicheradres se wird der Wert aus dem Register act_mem_adr benutzt Nach erfolgtem Daten transfer ber den Bus wird die Adresse um 4 erh ht und mit dem Wert in dem Speicher abgebildeten Register stopaddr verglichen Ist die Stopadresse erreicht wird das audioen Bit in controlreg gel scht und damit die Audioaktion beendet Ist aber das loopen Bit in controlreg gesetzt wird aus dem Speicher abgebildeten Register startaddr das Register act_mem_adr neu geladen Dies geschieht auch beim Aktivieren des Audiocores durch Setzen des Bit audioen in controlreg KAPITEL 4 DIKTIERGER T ALS SOC 55 4 4 Integration in die LEON Plattform Zur Integration des fertigen DDM Cores wird die LEON Plattform folgenderma Ben angepasst Die Ein und Ausgangsleitungen des Cores aus dem Gesamtsystem werden in einem Record zusammen gefasst und in der Datei iface vhd eingetra gen Die Typen und Leitungsnamen f r die Einbindung der AMBA Komponenten sind in amba vhd zu finden Die neuen AMBA Module des Busses werden in die Datei ambacomp vhd eingetragen
29. Datein als Parameter erweitert Zur Handhabung der S Records in den exo Datein mus ste die Klasse XSV95 aus XSV95 CPP in das Programm aufgenommen werden und entsprechend verwendet werden Zur korrekten bertragung von svf Dateien musste in der Klasse XC95 in XC95 CPP die Ausgabe der Strings die Methode data zu c_str gewechselt werden Da die C Funktion sscanf verwendet wird m ssen die String Daten unter Linux in richtige C Strings mit abschlie endem 0 Zeichen transformiert 2Standardadresse des Parallelport 0 ANHANG C PORTIERUNG DER XESS SOFTWARE NACH LINUX 70 werden In der Klasse XSError in Xserror CPP wurde der Aufruf ostream_withassign in den von Linux ben tigten Aufruf _ O_ostream_withassign ge ndert Die restlichen nderungen betreffen haupts chlich das Verschieben der De klaration von Variablen im Programmtext oder hnliche kleinere Anpassungen Diese werden nicht n her erl utert Anhang D Datei Ausz ge D 1 target vhd constant syn_none syn_config_type syntool gt synplify targettech gt gen infer_pads gt true infer_ram gt false infer_regf gt false infer_rom gt false gatedclk gt false rfsyncrd gt true rfsyncwr gt true constant syn_atc35 syn_config_type syntool gt synplify targettech gt atc35 infer_pads gt false infer_ram gt false infer_regf gt false infer_rom gt true gatedclk gt false rfsyncrd gt true rfsyncwr
30. Definition mit einer Breite von 32 Bit Die Pipeline ist 5 stufig ausgelegt und besteht aus der Standardabfolge instruction fetch in struction decode execute memory write back mit 1 delay slot gem SPARC Norm Zum Multiplizieren steht ein iterativer Multiplizierer zur Verf gung der mit in das Design synthetisiert werden kann Wegen des hohen Platzverbrauchs ist er in FPGA Designs normalerweise nicht integriert Ein Dividierer gibt es in der bisherigen Version noch nicht F r Flie kommaanwendungen gibt es eine FPU Schnittstelle zum FPU Meiko CORE welcher kommerziell bezogen werden kann Der Prozessor bietet die M glichkeit Coprozessoren anzuschlie en Damit k nnen hinzugef gte Cores mit eigenen Befehlen gesteuert werden Die CPU besitzt einen Daten und einen Befehlscache Beide sind direkt ab bildend ausgelegt und ihre Gr e ist von 1 64 kByte konfigurierbar Das Regi sterfile enth lt alle notwendigen und die von SPARC typischen Registerwindows Registerwindows erm glichen bei Funktionsaufrufen berlappende Bereiche von Registern in denen die Parameter der Funktionen stehen Sie sind n her in Kapitel 4 von beschrieben Die Anzahl der Windows ist von 2 32 konfigurierbar und bei den Designs f r FPGAs auf 8 gesetzt 2 2 Paketumfang von LEON Bei der ESA sind f r das LEON Projekt zwei Pakete f r die Entwicklung erh lt lich Erstens der Quelltext f r die LEON Plattform in VHDL und zweitens eine Softwareentwicklungsumgebung
31. Die Anwendung die das Diktierger t implementiert baut sich aus weiteren drei Funktionen auf ddm enth lt die Hauptschleife Diese Endlosschleife ent h lt die Steuerung der einzelnen Aktionsm glichkeiten des Diktierger ts Am Anfang der Funktion wird die Plattform initialisiert Der Funktion steht zur Spei cherung der Aufnahmen ein Array mit fester Anzahl Eintr ge zur Verf gung In diesem werden die Zeiger auf die einzelnen Aufnahmen gespeichert In der Hauptschleife werden die Tastenzust nde ausgewertet und die entsprechende Ak tion gestartet Eine Aufnahme des Diktierger ts besteht aus einer verketteten Liste von 8 kByte gro en Speicherbl cken In dem letzten 4 Byte eines Blocks wird der Zei ger auf den n chsten Block gespeichert Mit ddm_record wird eine solche Liste als Aufnahme angelegt Dazu benutzt die Funktion zwei feste Puffer zur Auf nahme Diese werden abwechselnd mit Daten gef llt und jeweils mit trans in einen dynamisch allokierten Speicherblock bertragen Sind keine dynamischen Bl cke mehr verf gbar oder greift der Benutzer ein wird die Aufnahme gestoppt Um eine Aufnahme oder Wiedergabe ohne Spr nge mit den Bl cken zu realisie ren wird der Loopmode der Hardware benutzt Dieser springt bei erreichen der Endadresse wieder auf die Startadresse zur ck Durch Austauschen der Start und Stopadresse w hrend des Betriebs kann so eine kontinuierliche Aufnahme erreicht werden Um die richtigen Zeitpunkte zur Aktuali
32. L 4 DIKTIERGER T ALS SOC 58 clear_buff Diese Funktion l scht eine verkettete Liste von Speicherbl cken ei ner Aufnahme und gibt den Speicher durch Aufruf von free_block wieder frei Um die Funktionsf higkeit der Hardware testen zu k nnen wurde eine Testbench in der Software implementiert Diese steht in der Funktion test Sie greift in gro en Teilen direkt also ohne Benutzung der oben genannten Funktionen auf die Register zu Die einzelnen Zust nde werden als Output auf der seriellen Schnittstelle ausgegeben Als erstes testet sie den Zugriff auf die Register ber den APB Sie schreibt dazu einige Werte in die Register und liest diese anschlie Bend wieder aus Dann gibt sie die Zahlen von 0x00 bis Oxff in 0x11 Schritten auf dem Hexdisplay aus Dies kann auch auf der realen Hardware ohne Ver bindung zu einem Computer beobachtet werden Zum Schluss berpr ft sie die Funktionst chtigkeit der Audioansteuerung und des AHB in dem sie eine Aufnah me startet Die Daten werden in den Speicher geschrieben und nach Beenden der Aufnahme wieder ausgegeben Kommt die Testbench am Ende an gibt sie auf der Hexadezimalanzeige die Ziffern Ox0c aus und endet in einer Endlosschleife Die Testbench sollte zur Benutzung mit der Simulationsumgebung oder der Hardwa re entsprechend angepasst werden Aus Zeitgr nden sollten bei der Simulation alle Verz gerungsschleifen entfernt und der Puffer f r die Aufnahme auf ein paar Sample begrenzt sein
33. M 28 BA ist in drei Bussysteme und Protokolle unterteilt Dies sind der Advanced High performance Bus AHB Advanced System Bus ASB und der Advanced Pripheral Bus APB AHB ist die Weiterentwicklung des ASB und bietet diesem gegen ber eine h here Durchsatzleistung Der APB ist f r die Ansteuerung von Peripherieger ten wie UART Timer PIO Keyboard konzipiert Er hat eine leicht zu implementierende Schnittstelle und einen geringen Stromverbrauch Der APB ist ber eine Bridge entweder an den AHB oder den ASB angeschlossen LEON besitzt einen AHB mit einem APB wie in Abb D Tou sehen Im weiteren werden nur diese beiden Bussysteme erkl rt In Abb 2 5 ist ein vereinfachtes Modell des AMBA Bus mit AHB und APB zu sehen Einige Leitungen wurden der besseren bersicht wegen weggelassen Dazu geh ren die Reset und Clockleitungen die es in beiden Bussystemen gibt In LEON wird der Systemclock und der System reset f r den AMBA Bus verwendet Ein einzelner Busreset ist nicht m glich Die Datenleitungen des AMBA Busses sind 32 Bit breit HBUSREQx Adressleitungen HADDR AHB Master HWRITE cache Datenleitungen HGRANTx 7 TE HWDATA HRDATA HREADY o HSELx AHB Arbiter PENABLE PWRITE AHB Slave AHB Slave Speicher Schnittstelle en APB Slave memory mapped register PRDATA Peripherie PWDATA PADDR Abbildung 2 5 Vereinfachte Darstellung de
34. M Code muss die ROM Breite auf 8 und Read Modify Write als aktiv in den Speicherkonfigurationsregistern von LEON gesetzt werden Kapitel 4 Diktierger t als SoC Der Entwurf eines SoCs mit der Leon Plattform wird in diesem Kapitel anhand des Beispiels digitales Diktierger t beschrieben Das System hat als Aufgabe Au diodaten aufzunehmen und zu speichern um sie zu einem sp teren Zeitpunkt wie der auszugeben Der Benutzer kann dabei w hlen ob er eine neue Aufnahme starten eine alte Aufnahme abspielen oder diese l schen will Ein Prototyp des Ger ts wurde auf das XSV 800 Board abgebildet Es benutzt den auf dem Board befindlichen Audiobaustein siehe Abschnitt 3 1 Dieser Bau stein vom Typ AKM AK4520A kann Stereo Audiosignale A D und D A wandeln Die Audiodaten werden als serieller bin rer Bitstrom zum FPGA trans portiert Zur Steuerung des Diktierger ts werden die Mikrotaster des Boards be nutzt wodurch das System standalone betrieben werden kann Als Statusausgabe dienen die beiden 7 Segmentanzeigen Auf ihnen wird die Anzahl der vorhande nen Aufnahmen als auch bei Aufnahme und Wiedergabe der aktuelle Index der Aufnahme wiedergegeben 4 1 Entwicklungszyklus Die Abfolge der Entwicklung eines Cores f r das System ist in Abbildung dargestellt und wird folgend anhand des Beispiels Diktierger t diskutiert Die Sy stemfunktionalit t wird als erstes in Hardware und der Software aufgeteilt Die Hardware bernimmt die Ansteuerung
35. Menge Standardschnittstellen und im Verh ltnis zu vergleichbaren Boards den gr ten Speicher besitzt Au erdem ar beiten einige Entwickler die den LEON implementieren mit diesem und es war vom Preis Leistungsverh ltnis eines der besten 3 1 Funktionalit t des Boards Das Board besteht aus einer 152mmX152mm gro en Platine In der Mitte be findet sich das Herzst ck das Xilinx Virtex FPGA XCV800 Auf dieses werden die synthetisierten Schaltungen abgebildet ber ein Xilinx XC95108 CPLD wird das Board konfiguriert Die XESS Konfigurationssoftware spricht das CPLD di rekt an Auf dem Board befinden sich 2MB SRAM aufgeteilt in 2 unabh ngige B nke mit jeweils 16 Bit Datenbreite Dabei besteht eine Bank jeweils aus zwei 8 Bit SRAM Bausteinen Zus tzlich zu diesem fl chtigen Speicher gibt es noch einen 8 Bit 2MB FlashRAM Baustein Dieser kann zur Speicherung von FPGA 33 KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD 34 Personalisierungsdatenstr men aber auch zur generellen Benutzung z B als Sy stemROM benutzt werden Zur Stromversorgung stehen eine 9VC Buchse oder eine ATX Steckverbindung zur Verf gung Das Board besitzt au erdem wie oben erw hnt viele Standardschnittstellen F r die meisten von ihnen befindet sich zus tzlich noch ein jeweils dazu passender IC mit auf dem Board Die ICs werden zur Umwandlung von analogen Signale in digitale und umgekehrt ben tigt da das FPGA ein rein digitaler Baustein ist Au er
36. UNS Do TURC N EN EE E Re Ra DOUCE y gt Se rl Do HSS ord a in De Prototyping von LEON mit XS V 800 Board 3 1 Funktionalit t des Boards Rei E E E te or aia dead Ghee a er ate ie EE EE 3 5 Kommunikation und Konfiguration 360 CPLD SYNtNESE si tale dis ss in rau INHALTS VERZEICHNIS 3 7 Synthese von LEON f r XSV 800 3 8 Betrieb des XSV 800 Board 4 Diktierger t als SoC 4 1 Entwicklungszyklus EEN EES 20 220 108 04 4 2 Funktionsbeschreibung da LES ba Re EE S 4 3 1 Die Signale des AKM AK4520A 4 3 2 APB Slavel E ass abs be ee 4 3 3 Mikrotaster und Hexdisplay 434 Timer ss 42 28 ee eh eee HAH SES Fee TS 4 3 5 Audio Ansteuerung 4 3 6 AHB Master A BEE 4 5 Aufbau und Benutzung der Software 4 5 1 Zugriff auf die Register und ihre Funktion 4 5 2 Die Funktionen der Software 4 5 3 Benutzung der Software 5 Zusammenfassung und Ausblick A CNS ANA zer 2 02 ae ae AN ae A 2 Die Projekte der Entwicklungsumgebung B__ModelSIM C Portierung der XESS Software nach LINUX C l Verzeichnisstrukturl C 2 nderungen des Quelltextes im Detail D Datei Ausz ge D 2 LEON Top Entity Abbildungsverzeichnis 2 1 bersicht ber das Gesamtsystem von LEON WE EE nn re RE
37. Universit t Stuttgart Fakult t Informatik Pr fer Prof Dr Hans Joachim Wunderlich Betreuer Dipl Phys Rainer Dorsch Beginn am 18 09 2000 Beendet am 23 02 2001 CR Klassifikation C 3 C 5 4 Diplomarbeit Nr 1871 Digitales Diktierger t als System on a Chip mit FPGA Evaluierungsboard Daniel Bretz Institut f r Informatik Breitwiesenstr 20 22 D 70565 Stuttgart Kurzfassung Ziel der Arbeit war es eine System on a Chip Entwicklungsplattform f r die Ab teilung Rechnerarchitektur f r Forschung und Lehre bereitzustellen und exempla risch ein digitales Diktierger t als Demonstrator mit der Plattform zu implemen tieren F r die Arbeit wurde als Grundsystem die von der European Space Agency ESA entwickelte LEON Plattform fiir eingebettete Systeme ausgew hlt Kern des Open Source Systems ist ein SPARC V8 kompatibler Prozessor der ber einen AMBA Bus mit den brigen Komponenten kommuniziert LEON wurde an die Entwicklungswerkzeuge der Abteilung und an ein ausgew hltes Prototypen Evaluierungsboard angepasst Auf der fertigen Plattform wurde das digitale Dik tierger t implementiert und erfolgreich auf der Hardware in Betrieb genommen Danksagung Die vorliegende Diplomarbeit ist im Zeitraum Herbst Winter 2000 2001 entstan den Ich m chte mich an dieser Stelle bei allen bedanken die mir dabei geholfen haben Namentlich erw hnen m chte ich Student Jens Kiinzer und Dipl Phys Stefan Gerstend rfer die mir be
38. XES00 xes01 X1198 X1100a X1100b X1100c xil01 Metajlow Homepage 2001 MICHAEL KEATING Pierre B Reuse Methology Manual Kluwer Academic Publishers 1998 ISBN 0 7923 8175 0 On Line Applications Research Corporation RTEMS C User s Guide 4 0 0 October 1998 ROLAND H PESCH Jeffrey M O The GNU Binary Utilities 2 9 1 Cygnus May 1993 RICHARD M STALLMAN Roland H P Debugging with GDB 5 0 Free Software Foundation Inc April 1998 SPARC International Inc The SPARC Architecture Manual Version 8 1992 STALLMAN Richard M Using and Porting GNU CC for egcs 1 1 Free Software Foundation Inc March 1998 VSI Alliance VSI Alliance Architecture Document 1 0 1997 XESS Corporation XSV Board Manual 1 0 March 2000 Xess Homepage 2001 Xilinx XC95108 In System Programmable CPLD 3 0 December 1998 Xilinx Alliance Series 3 1i Quick Start Guide 2000 Seite 1 5 Xilinx Using the Virtex Block SelectRAM Features 1 3 March 2000 Xilinx Virtex 2 5 V Field Programmable Gate Arrays 2 3 September 2000 Xilinx Homepage 2001 Index AHB Firmcore AHB Master FPGA 9 AK4520A free_block AMBA Freedom APB APB Slave 50 GAL B5 Arbiter gdb 26 ARC geistiges Eigentum 8 ARM get_block ASB get_buttons 57 Befehlscache Har dcore bit Datei hexddisp bitgen intellectual property CLB IP 8 clear_buff LEON I1 CPLD 35 36 CVS 63 map 22
39. Zugriff auf die 1 O Schnitt stellen der Hardware unter Windows zu bekommen benutzt Xess Software eines Drittanbieters Dieses Modul wurde durch eigene Software ersetzt und beschr nkt sich auf ein paar Zeilen Code welcher in der Datei DLPORTIO C steht IOMO0 Die VO Adresse wurde fest auf den Bereich 0x3 8 gesetzt Durch den Aufruf der Funktion init wird der I O Bereich vom Betriebssystem freigeschaltet Dazu muss der ausf hrende Prozess Rootrechte haben Dies kann durch Ausf hren des Programms als root oder durch Setzen des Besitzers der Datei auf root plus ge setztem S Bit geschehen Nachdem der I O Bereich freigeschaltet ist werden die Rechte des Prozesses auf die userid des ausf hrenden Benutzers gesetzt F r das richtige Zeitverhalten musste die Methode InsertDelay der Klasse XCPort in XCPORT CPP an Linux angepasst werden Unter Microsoft Windows liefert der Funktionsaufruf clock die vergangene Zeit in Millisekunden seit dem Start des Programms Unter Linux liefert clock die vergangene Zeit seit dem letzten clock Aufruf W hrend unter Windows die Differenz ben tigt wird kann unter Linux direkt der zur ckgegebene Wert verwendet werden In dem Kommandozeilenprogentsprechendenramm xsload wurde die Unter st tzung von exo Dateien eingebaut Diese k nnen von der Windows Version nur von den Programmen mit grafischer Oberfl che gehandhabt werden Das Pro gramm xsload in xstools xsload wurde auf den Aufruf mit entsprechenden
40. apid Prototyping Auf dem Markt befinden sich heute eine gro e Anzahl verschiedener Produkte zur Hardwareverifikation mit FPAGs 1 3 Die Arbeit In der vorliegenden Arbeit wurde eine Plattform zur System on a Chip Entwick lung f r die Abteilung Rechnerarchitektur zusammengestellt Diese soll der Ab teilung als Lehrobjekt und als Forschungsumgebung an welcher theoretische For schungsergebnisse an praxisnahen Schaltungen verifiziert werden k nnen die KAPITEL 1 EINLEITUNG 10 nen F r die Arbeit wurden verwendbare Komponenten gesucht und ausgew hlt Als Beispielanwendung wurde ein digitales Diktierger t implementiert Um eine schnelle Entwicklung zu erm glichen und die Schaltung in Echtzeit betreiben zu k nnen wurde ein FPGA basiertes Hardware Evaluierungsboard ausgew hlt und in die Entwicklungsumgebung integriert Als Grundsystem dient die in dem European Space research and TEchno logy Centre ESTEC der European Space Agency ESA entwickelte LEON Plattform Die Plattform enth lt einen eingebetteten Prozessor mit Programmier umgebung Es entstand folgende Entwicklungsumgebung die sich grob in vier Bereiche einteilen l sst der Quelltext der LEON Plattform mit Syntheseskripten die Softwareentwicklungsumgebung die Test und Simulationsumgebung und das Evaluierungsboard Eine klare Trennung ist allerdings nicht m glich da alle Be reiche ineinander bergreifen In Kapitel 2 wird die Grundplattform beschrieben Zu dem Qu
41. auf das Referrenzhandbuch verwiesen Der Arbiter ist die Kontrollinstanz um mehrere Master die alle Aktionen auf dem Bus ausl sen k nnen zu verwalten An ihn richten sich die Anfragen der Master wenn sie den Bus benutzen wollen Er gibt an welcher Master den ak tuellen Zugriff auf den Bus hat In Abb sind die wichtigsten Leitungen f r einen simplen Transfer zu sehen der Signalverlauf dazu in Abb Der Ma ster signalisiert ber die ABUSREOx dem Arbiter dass er eine Aktion auf dem Bus ausf hren m chte Ob er Zugriff auf den Bus hat wird dem Master ber die HGRANTx Leitung gemeldet Bevor der Master jedoch einen Zugriff auf den Bus machen darf muss er die Bereitschaft des Slave abwarten der gerade arbei tet Die Slaves melden ihre Bereitschaft ber die AREADY Leitung Diese ist an allen Mastern und Slaves auf dem Bus angeschlossen Ein Slave bekommt da durch auch das Ende der Arbeit eines anderen Slaves mit Nach dem Takt bei dem HGRANTx und HREADY auf 1 waren ist der Master Besitzer der Adress und Steuerleitungen und legt diese sp testens jetzt auf dem Bus an Diese Phase dauert wie oben erw hnt genau einen Takt lang Will der Master noch weitere Daten transportieren kann er die Adresse des n chsten Transfers im nachfolgen den Takt anlegen Bei einem einzelnen Zugriff muss er die Kontrolle ber den Bus durch L schen der HBUSREQx Leitung abgeben Ein erneutes AREADY von den Slaves signalisiert dass nun auch die Datenle
42. baud gt false constant pci none pci config type pcicore gt none cfgclk gt mainclk ahbmasters gt 0 ahbslaves gt 0 constant pci test pci config type pcicore gt ahbtst cfgclk gt mainclk ahbmasters gt 2 ahbslaves gt 1 constant pci_insilicon pci config type pcicore gt insilicon cfgclk gt both ahbmasters gt 2 ahbslaves gt 1 constant pci_estec pci config type pcicore gt estec cfgclk gt mainclk ahbmasters gt 1 ahbslaves gt 1 constant pci_ahb_test pci config type pcicore gt ahbtst cfgclk gt mainclk ahbmasters gt 0 ahbslaves gt 1 constant peri_std peri_config_type c greg gt true ahbstat gt true wprot gt true wdog gt true constant peri_fpga peri_config_type cfgreg gt true ahbstat gt false wprot gt false wdog gt false constant debug_none debug_config_type enable gt false uart gt false iureg gt false fpureg gt false nohalt gt false pclow gt 2 constant debug_disas debug_config_type enable gt true uart gt false iureg gt false fpureg gt false nohalt gt false pclow gt 2 constant debug_all debug_config_type enable gt true uart gt true iureg gt true fpureg gt true nohalt gt false pclow gt 0 standard slave config constant ahbslvcfg_std ahb_slv_config_vector 0 to AHB_SLV_MAX
43. ben tigt mehr Zeit wobei aber gerade die Produktlebenszyklen immer k rzer werden Um die Time to Market zu verk rzen oder zumindest konstant zu halten wer den bei SoCs neue Entwicklungsverfahren angewandt Die einzelnen Komponen ten des Systems werden getrennt entwickelt und bleiben in mehrere funktionale Einheiten Cores oder Macros genannt unterteilt Diese werden wiederverwend bar ausgelegt Die Entwickler k nnen so bei einem neuen System auf alte Cores zur ckgreifen Dazu wird eine schon vorhandene Grundplattform verwendet an die ein speziell f r die Aufgabe entwickelter Core abgebunden wird Um die Nor men und Entwicklungsvorschriften der Cores k mmert sich die Virtual Socket Interface Alliance VSI97 die VSIA Bei den Entwicklern muss zwischen den Core Designern welche die Schaltung f r den Core entwerfen und den System Integratoren die ein System aus einzelnen Cores zusammenstellen unterschieden werden Bei den Cores unterscheidet man zwischen Hard Soft und Firmcores Hardcores sind Macros die als komplett verdrahtetes Layout vorliegen und an eine Herstellungstechnik gebunden sind F r sie gibt es die genauen physikali schen Eigenschaften und sie sind vollst ndig verifiziert Der Integrator erh lt bei diesem Typ eine Spezifikation ein Simulationsmodell und die Schnittstellenbe schreibung Auf h heren Abstraktionsebenen ist die Implementierung des Cores nur dem Hersteller bekannt Die Anbieter von Hardcores sind deswe
44. dat in dem Verzeichnis tsource Das Laden der Software in die RAM und die ROM Zellen geschieht automatisch durch die Testbench Die Testbench beinhaltet verschiedene Testbenchkonfigurationen die sich in Einstellungen wie Speichergr e Speicherzugriffszeit und Betriebsfrequenz un terscheiden Die vorhandenen Konfigurationen stehen im Verzeichnis tbench in der Datei tbleon vhd Von der Testbenchumgebung wird die Breite der verwende ten ROMs an der parallelen Schnittstelle angelegt Die Software gibt die einzelnen Etappen und Zust nde der Testbench auf dem Datenbus als I O Ausgabe aus Die beiden UARTS sind als Nullmodemverbindung miteinander verbunden Bei der Simulation auf Register Transferebene wird der gr te Teil des Quell textes der auch bei der Synthese verwendet wird benutzt Es gibt jedoch f r manche Module reine Verhaltensmodelle die nur bei der Simulation zum Einsatz kommen Bei der Synthese wird f r diese ein anderer Quelltext verwendet der in der Simulation nicht ausgef hrt wird Dies sind vor allem die RAM Zellen f r Cache und das Registerfile und die Pads des Systems Um eine m glichst ho he Abdeckung des Quelltextes bei einer Simulation auf Registertransferebene zu haben gibt es die M glichkeit die Technologie abh ngigen RAM Zellen bei der Verhaltenssimulation mit zu simulieren Es k nnen dazu die Verhaltensmodelle KAPITEL 2 DIE LEON PLATTFORM 19 der Zellen in der Datei tech_virtex vhd verwendet werden Besser
45. dem verhindern diese ICs dass die f r die Benutzung der Schnittstellen n tigen Schaltungen immer mit auf das FPGA abgebildet werden Auf dem Board sind folgende Schnittstellen vorhanden e ein Videodecoder der NTSC PAL SECAM Signale digitalisiert mit einem S VHS und einem Composite Eingang e ein RAMDAC der die Ausgabe von Videodaten auf eine VGA Buchse er m glicht e ein Digital Analog D A und Analog Digital A D Konverter der Stereo Audiosignale bearbeiten kann er besitzt zwei Stereo 1 5 mm Klinkenbuch sen e ein Ethernet Adapter der 10 100Mbps Signale bearbeiten kann mit einer Standard RJ45 Buchse e eine PS 2 Buchse e eine serielle Schnittstelle mit einem 9 Pin D Sub Stecker e eine parallele Schnittstelle mit einer 25 Pin D Sub Buchse sie wird stan dardm ig von XESS zur Programmierung des Boards verwendet e ein USB Anschluss e Ein XChecker Anschluss der Standardanschluss von Xilinx um FPGAs zu programmieren und zu steuern mit diesem kann das CPLD auf dem Board nicht angesprochen werden Zus tzlich gibt es auf dem Board noch zwei 7 Segmentanzeigen und eine zehn stellige LED Strichanzeige mit denen Statusinformationen ausgegeben werden k nnen Dazu kommen noch vier Mikrotaster und ein achtstufiger DIP Schalter und schlie lich noch zwei allgemein benutzbare Erweiterungsschnittstellen mit insgesamt 76 Leitungen zum FPGA die sich aber dieselben Leitungen wie das SRAM zum FPGA teilen Dass sich manche Komponenten
46. device vhd sparcv8 vhd amba vhd iface vhd ambacomp vhd aus der LEON Plattform von der Schaltung ben tigt In dem Verzeichnis ddm design sind alle Dateien mit Ausnahme des H lldesigns die an der Plattform ge ndert werden mussten zu finden Nachdem die grundlegende Funktionalit t des Cores mit der eigenen Testbench gepr ft ist wird die Schaltung mit der gesamten Plattform getestet Mit der Software wird die eigentliche Funktion des Systems als Anwendung implementiert Neben der An wendung sollte aber auch eine Software basierte Testbench geschrieben werden Diese testet die Grundfunktionen der Hardware und das Zusammenspiel des Co res mit der Plattform Mit der Systemsimulation k nnen auf diese Weise Fehler in der Kommunikation zwischen System und integriertem Core untersucht werden Dies betrifft vor allem den AHB Master da dessen Funktionsf higkeit bei der Testsimulation des einzelnen Cores nicht hervorgeht Nachdem das System in der Simulation befriedigend l uft wird das Design synthetisiert und auf der Hardware mit der Softwaretestbench getestet Zuletzt wird die eigentliche Anwendung auf der Hardware in Betrieb genommen Dabei werden vorallem Fehler der Softwa re auftreten da die Software auf Simulatorbasis nur unzureichend getestet werden kann Es k nnen aber auch noch Hardwarefehler auftreten die erst auf dem realen System zur Geltung kommen KAPITEL 4 DIKTIERGER T ALS SOC Aufteilung der Systemfunktionalit t in Softwar
47. die Software Zugriff auf den Oszillator hat muss die von Xess daf r mitgelieferte svf Datei oscxsv svf auf das CPLD geladen werden Bei xsload kann speziell f r die Taktprogrammierung die Option D V mit dem Teiler angegeben werden Der Aufruf um das Board mit einem Takt von 20 MHZ zu programmieren ist xsload oscxsv svf DIV 5 Je nach dem mit welcher Methode das FPGA personalisiert werden soll muss ein anderes CPLD Design geladen werden Um das FPGA mit einer bit Datei KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD 43 zu initialisieren muss die Datei downpar svf aus dem cpld Verzeichnis benutzt werden Dieses CPLD Design hat zu der von Xess mitgelieferten Version in der Datei dwnldpar svf die serielle Schnittstelle zum FPGA durchgef hrt Nach erfolgreichem Laden des Designs auf das CPLD leuchten zwei Statusausgaben auf der LED Strichanzeige Die Daten die an der parallelen Schnittstelle anliegen werden auf einer der beiden 7 Segmentanzeige des Boards angezeigt In der Abb 3 Uist dies die linke Anzeige Nachgepr ft werden kann dies mit xsport Ist das Design geladen kann mit einer bit Datei das FPGA personalisiert werden Nach dem Laden wird das Design sofort ausgef hrt Soll das FPGA aus Daten von dem FlashRAM personalisiert werden so miis sen diese zuerst in das FlashRAM geschrieben werden Mit dieser Konfigurati onsmethode bleibt das Design nach einer Stromunterbrechung auf dem Board er halten Um Daten in das FlashRAM zu
48. e und Hardware Hardware zeitkritische Aufgaben sollte vielseitig nutzbar sein Ansteuerung der Peripherie Software bernimmt Steuerung Vorteil leichter anpassbar und korrigierbar bernimmt individuelle Aufgaben Umsetzung der Hardware Probedesign f r Ansteuerung der verwendeten Peripherie eigentliche Hardware mit eigener Simulation und Testumgebung Standardhardwareentwurf Umsetzung der Software enth lt Testbench f r die Hardware eigentliche Anwendung Diktierger t eventuell Ausf hrung mit Instruktionslevelemulator Simulation des Gesamtsystems komplette Funktionalit t testbar AMBA sehr zeitaufwendig f hrt Testbench der Software aus Umsetzung auf die Hardware Echizeit manche Fehler treten erst in Echtzeit und mit Anwendung auf Korrektur vor allem der Software aber auch der Hardware Abbildung 4 1 Entwicklungszyklus einer Anwendung auf der Plattform KAPITEL 4 DIKTIERGER T ALS SOC 48 4 2 Funktionsbeschreibung In dem Core des Diktierger ts bernimmt die Hardware die Aufgabe der Audio Ein und Ausgabe das Auslesen der Mikrotaster und die Ansteuerung der beiden 7 Segmentanzeigen Der Audiobereich teilt sich in die Ansteuerung des AKM AK4520A und dem Schreiben und Lesen der Audiodaten in oder aus dem Spei cher auf Zur Speicheransteuerung wurde ein AHB Master integriert Die Audio ans
49. ebungen bei denen die CPUs aus Softcores bestehen Der Entwickler kann die CPU in vielen Parametern konfigu rieren Nach Auswahl erzeugen die Entwicklungswerkzeuge eine Beschreibung der Schaltung mit dem dazugeh rigen Compiler 2 1 LEON ein Open Source Projekt Die verwendete LEON SoC Plattform Gai00a ist ein Open Source Projekt der ESA ESTEC Das bedeutet dass der gesamte VHDL Quelltext des Systems er 1 european space agency european space research and technology centre 11 KAPITEL 2 DIE LEON PLATTFORM 12 h ltlich ist und frei benutzt und ver ndert werden darf Die ESA ESTEC ent wickelt Prozessoren f r den Einsatz in Satelliten F r den Einsatz in dieser Pro zessor unfreundlichen Umgebung gibt es eine Fehler tolerante Version von LEON Diese wird von der ESA kommerziell vertrieben In der freien Version von LEON ist der Fehler tolerante Teil entfernt Die Open Source Entwicklung bringt f r die ESA drei wesentliche Vorteile Durch die h here Benutzung werden die Funk tionen der CPU besser validiert Der Funktionsumfang und die Leistung wer den ohne eigene Entwicklungsbem hungen vergr ert F r die Entwicklung der Plattform entstehen neue meist freie Werkzeuge und lauff hige Software Ein Beispiel hierf r ist 4CLinux welches schon auf die Plattform portiert wird LEON als auch der Vorg nger ERC32 implementieren den SPARC Befehls satz Jedoch unterst tzt LEON die etwas neuere Version 8 im Gegensatz zum ERC
50. elltext des Pro zessors geh ren neben den eigentlichen Codedateien auch die Syntheseskripte und die Konfigurationsdateien Eng damit verbunden sind Dateien f r die Simulation und die Testbench Als Synthesewerkzeug wird der Sysnopsys Design Compiler verwendet Als Softwareentwicklungsumgebung wird der von der ESA ESTEC gelieferte C C ADA Compiler benutzt Dazu geh rt auch ein SPARC LEON Instruktionslevelemulator und einige zus tzliche Werkzeuge f r die Softwareent wicklung des LEON Die Test und Simulationsumgebung enth lt haupts chlich die Testbench f r die CPU aber auch die M glichkeit die CPU mit selbst ber setzten Programmen zu simulieren Zur Simulation wird Mentor ModelSIM ver wendet Als Hardwareevaluierungsboard dient das XSV 800 Board der Firma Xess Die Integration der Plattform darauf und die Benutzung wird in Kapitel 3 be schrieben Auf ihm befinden sich ein Xilinx Virtex XCV800 FPGA ein Xilinx XC95108 CPLD 2 MB SRAM 1 MB FlashRAM und viele Peripherieschnittstel len Zu dem Board geh rt auch die fiir seine Programmierung zust ndige Softwa re In Kapitel 4 wird die Umsetzung des Diktierger ts auf die Plattform beschrie ben Dazu geh rt die Entwicklung eines eigenen Cores welcher ber den AMBA Bus mit dem System verbunden ist Das System ist zu seiner Anbindung entspre chend angepasst Spezielle Software integriert die Funktionen des Diktierger ts darauf Am Ende des Kapitels wird der Umgang mit dem Di
51. en Diese generiert die Pads f r jeweils 8 Bit des Busses und entscheidet ob die interne Datenleitung mit der RAM oder ROM Leitung verbunden wird und ob dies Eingabe oder Ausgabesignale sind Um nicht die Designdaten aus dem FlashRAM beim Systemstart zu lesen wird die oberste ROM Adressleitung auf logisch 1 gesetzt Damit kann das ROM Programm in dem oberen MB des FlashRAMs stehen Da das Design mehrere Adress und Da tenbusse nach au en f hrt kann es nicht mit der normalen Simulationsumgebung tenv simuliert werden Eine speziell f r dieses Design angepasste Simulationsum KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD 42 gebung steht in tenv23_back Die RAM Gr e ist bei dieser auf 1 MB begrenzt da die Verhaltensmodelle der RAMs nicht mehr zulassen Bei der derzeitigen Simulationsgeschwindigkeit macht ein gr eres RAM aber auch keinen Sinn 3 8 Betrieb des XSV 800 Board Die Ansteuerung zur Programmierung und dem Betrieb des Boards erfolgt von ei nem externen Rechner aus In der Abteilung wird dazu ein PC mit Linux benutzt Da die Software von Xess nur f r Microsoft Windows mitgeliefert wird aber der Quelltext erh ltlich ist konnte diese nach Linux portiert werden Weiteres dazu ist im Anhang C zu finden Die Software besteht aus zwei Programmen xsload und xsport Beide sind von der Kommandozeile aus aufzurufen xsport erwartet als Parameter einen 8 Bit Bin rwert in den ASCII Zeichen 0 oder 1 Der Wert
52. er Wert aus sc k immer einen Systemtakt sp ter an 4 3 5 Audio Ansteuerung In Abb 14 7 ist die vereinfachte Schaltung zur Audioansteuerung zu sehen Die Audiodaten werden in das oder aus dem 20 Bit breiten Schieberegister gescho ben ber die Steuerlogik wird entschieden wann Daten geschoben werden und ob diese in das Schieberegister hinein oder aus ihm heraus geschoben werden KAPITEL 4 DIKTIERGERAT ALS SOC 53 controlreg E 1 0 audioin cacon Zen audioout a shiftregister 20 1 0 i Steuerlogik e sclk 7 sclk_old o tick A 20 gt DMAREQ 19 0 Y audiobuffer 32 re shiftcounter 5 1 Ir sel La sclk ia mclk q mclk Core Ausgang zeitsynchron Abbildung 4 7 Schaltung der Audio Ansteuerung Geschoben wird jeweils an der steigenden Flanke des Schiebetakts was ber die Leitungen sclk und sclk_old ausgewertet wird Die Anzahl der Schiebevorg nge wird in dem 5 Bit breiten Register shiftcounter gez hlt Dieses z hlt genau die 32 Schiebevorg nge eines Samples pro Kanal Beim Durchlauf des Z hlers wird der Kanal ber r_sel gewechselt Daten werden nur aus oder in das Schieberegi ster geschoben wenn die entsprechenden Bits audioen und recorden im Speicher abgebildeten Register controlreg gesetzt sind Mit diesen kann eine Wiedergabe oder Aufnahme gestartet werden Nach 20 Schiebevorg ngen eine
53. er lo kalen und der auf dem Server befindlichen Datei ermittelt Alle An derungen auf Serverseite seit dem letzten Auschecken der Datei auf den lokalen Rechner werden dann automatisch in die lokale Version bernommen Entstehen dabei Konflikte die das System nicht l sen kann wird der Benutzer darauf aufmerksam gemacht und aufgefor dert dies zu tun cvs add lt file name gt Hiermit wird dem CVS Server eine neue Datei Verzeichnis bekannt gemacht Dies ist n tig damit CVS beim Einchecken nicht alle in einem Verzeichnis befindlichen Dateien einchecked sondern nur die vom Entwickler als zum Projekt dazugeh rend angegebenen So wird verhindert dass sich in den Verzeichnissen befindliche Binaries Ob jektfiles und sonstige Dateien auf dem Server landen cvs commit file name Hiermit wird eine lokale Datei auf den Server eingechecked Dazu wird die Datei mit einem diff auf Ver nderungen zum Server unter sucht und gegebenenfalls die neue Version auf den Server gelegt Ist zwischenzeitlich auch die Datei auf dem Server ge ndert worden so wird die lokale Version vorher mit einem update entsprechend ange passt Bei diesem Kommando muss auch ein Kommentar angegeben werden welcher entweder mit der Option m oder mit dem Standar deditor eingegeben wird A 2 Die Projekte der Entwicklungsumgebung Als CVS Server dient in der Abteilung Rechnerarchitektur der Rechner rai16 Als Useridentifikation wird der eigene Loginname benutzt i
54. ers 0x40 0x6C 0001110000 0001111100 6 true uartl 0x70 Ox7C 0010000000 0010001100 7 true uart2 0x80 0x8C 0010010000 0010011100 8 true interrupt ctrl 0x90 0x9C 0010100000 0010101100 9 true I O port OxA0 OxAC others gt apb_slv_config_void PCT config constant apbslvcfg_pci apb_slv_config_vector 0 to APB_SLV_MAX 1 ANHANG D DATEI AUSZ GE 75 first last index enable function PADDR 9 0 0000000000 0000001000 0 true memory controller 0x00 0x08 0000001100 0000010000 1 true AHB status reg 0x0C 0x10 0000010100 0000011000 2 true cache controller 0x14 0x18 0000011100 0000100000 3 true write protection 0x1C 0x20 0000100100 0000100100 4 true config register 0x24 0x24 0001000000 0001101100 5 true timers 0x40 0x6C 0001110000 0001111100 6 true Uartl 0x70 Ox7C 0010000000 0010001100 7 true uart2 0x80 0x8C 0010010000 0010011100 8 true interrupt ctrl 0x90 0x9C 0010100000 0010101100 9 true IZO port OxA0 OxAC 0100000000 O111111100 10 true PCI configuration 0x100 Ox1FC others gt apb_slv_config_void constant apb_std apb_config_type table gt apbslvcfg_std constant apb_pci apb_config_type table gt apbslvcfg_pci standard simulation constant sim_std config_type
55. et Bei einem Fehlerfall muss der Master den Zustand IDLE auf der HTRANS Leitung anlegen Dieser wird von der Schaltung aber ohnehin bei nicht aktivem Master KAPITEL 2 DIE LEON PLATTFORM 32 auf der Leitung angelegt Dadurch ist auch die korrekte Antwort bei einem Grant bei nicht angefordertem Bus garantiert T3 T4 T5 T6 T7 HCLK HBUSREQx HGRANTx We HREADY HADDRI31 0 X Adresse Control Control HWDATA 31 0 Data HRDATA 31 0 A Data T Abbildung 2 7 Simpler Datentransfer mit optimalem Zeitverhalten Kapitel 3 Prototyping von LEON mit XSV 800 Board F r die Entwicklungsumgebung wurde ein Evaluierungsboard beschafft um die erzeugten Schaltungen in Echtzeit testen zu k nnen Dazu wurde ein zur Auf gabe passendes FPGA basiertes Entwicklungsboard aus der auf dem Markt er h ltlichen Hardware ausgesucht Das Board besitzt einen FPGA vom Typ Virtex der Firma Xilinx xi101 Dadurch k nnen die in der Abteilung schon vorhande nen Entwicklungswerkzeuge von Xilinx verwendet werden Das Board kann als alleinstehendes System betrieben werden Im Gegensatz zu PCI basierten Rech nereinstecksystemen bringt dies die Unabh ngigkeit und eigenst ndige Funkti onsf higkeit des darauf zu implementierenden SoC zum Ausdruck Es wurde das XSV 800 Board der Firma X Engineering Software System Corp XESS xes01 ausgew hlt da dies eine
56. g und Ausf hrung C Programme k nnen mit dem Crosscompiler wie mit einem gew hnlichen Com piler bersetzt werden Der Compileraufruf hei t sparc rtems gcc Es gibt dabei jedoch Einschr nkungen bei der Verwendung von Bibliotheken da nur eine stan dalone C Bibliothek vorhanden ist Viele Programme nutzen aber Bibliotheken die zum Betriebssystem geh ren Die Standardausgabe der Programme wird auf UARTI ausgegeben Die vom Compiler erzeugten Binaries k nnen mit dem In struktionslevelemulator SIS emuliert werden Der Aufruf lautet sparc rtems sis Gai00c Da der Compiler normalen SPARC Code erzeugt k nnen die Pro gramme auch mit dem gdb ausgef hrt werden SIS bietet jedoch Einstellungen der Speicherkonfiguration der Systemfrequenz der UARTs und einigem mehr Damit wird das Zeitverhalten kontrollierbar und die Ausgaben des Programms auf die UARTs werden auf der Standardausgabe sichtbar SIS kann auch vom edb RMS98 eingebunden werden womit komplette Funktionalit t f r das De bugging gegeben ist Eine genauere Erkl rung des Crosscompilers findet sich in Gai99 Um die Programme auf der simulierten oder synthetisierten Plattform auszu f hren ben tigen diese einen Bootloader Dabei gibt es drei Varianten auf welche Weise dieser geladen wird also drei Methoden das System zu starten Die eine Art ist den Instruktionscache des LEON vor dem Start mit einem Programm zu initialisieren Diese Variante gibt es nur f r die Xilinx Virtex
57. gen meist Chipproduzenten bei denen das komplette SoC gefertigt wird Bei einem Softcore bekommt der SoC Integrator den kompletten Quelltext der Schaltung und die dazugeh rigen Testbenches Dadurch kann er die Schaltung besser in sein Design integrieren und eventuell daran anpassen Im Gegensatz zum Hardcore muss die Schaltung den kompletten Designflow durchlaufen was im Zusammenspiel mit den verwendeten Synthesewerkzeugen und dem Zeitver halten Probleme bereiten kann Ein Softcore sollte deswegen m glichst ein breites Spektrum an Synthesewerkzeugen und m glichst die beiden Hardwarebeschrei bungssprachen VHDL und Verilog unterst tzen Ein Problem der Softcores ist der Schutz des Intellectual Property IP des geistigen Eigentums Firmcores sind zwischen Soft und Hardcores einzuordnen Der Integrator er h lt nicht die kompletten Quelltexte kann aber bestimmte Designparameter vor KAPITEL 1 EINLEITUNG 9 geben Dies k nnen z B verschiedene Bus oder Registerbreite optionale Funk tionalit t oder unterschiedliche Speicherausstattung sein Firmcores werden mei stens in Registertransferlevel RTL oder als Netzliste auf Gatterebene ausgelie fert dabei eine gute Vorhersage ber die physikalischen Eigenschaften gemacht werden MK98 1 2 Evaluierungshardware Ein Application Specific Integrated Circuit ASIC also eine anwendungsspezifi sche Schaltung kostet in der Entwicklung sehr viel Geld Zwar l sst sich damit die gr
58. haltung Mikrotaster und Hexdisplay Das Schaltbild zur Ansteuerung der Mikrotaster und der 7 Segmentanzeigen ist in Abb 4 5 zu sehen Der Zustand der vier Taster wird auf das vier Bit gro e Register buttons abgebildet das ber den APB von der Software ausgelesen wer den kann Von den vier m glichen Tastern des Boards um das Diktierger t zu steuern wird der TasterO als Resetknopf f r das System verwendet Es sind des wegen nur Bit 0 bis 2 mit Tasten verbunden Bit 3 wird vom H lldesign konstant auf 0 gesetzt Auf den beiden LED Anzeigen wird der Inhalt aus den unteren 8 Bit des Registers displaycontr ber zwei 7 Segmentencoder ausgegeben Bit 9 des Registers wird von dem H lldesign zum Ein und Ausschalten der Anzeigen ben tigt und wird sp ter genauer beschrieben 4 3 4 Timer Der Timer ist f r die Erzeugung der Taktsignale des Audiobausteins zust ndig Mit ihm wird der Mastertakt mclk und der Schiebetakt sc k erzeugt Um unter schiedliche Samplefrequenzen mit dem Design benutzen zu k nnen wurde ein Z hler verwendet Dieser z hlt den Wert aus scalerup herunter und l st beim Null Durchlauf des Z hlers einen Tick aus Bei jedem Tick des Z hlers wird der Wert im Register mstclk negiert Der Ausgang des Registers mstclk ist der Mastertakt mclk Ist der Wert in scalerup auf O gesetzt wird die Systemfrequenz halbiert Die Frequenz des Mastertakt kann ber die Formel mclk Dien be stimmt werden Um eine Taktansteuerung des
59. haltung wurde wie die LEON Plattform in VHDL implementiert Sie ist in einer einzelnen Datei mit Namen ddm vhd im Verzeichnis ddm design unterge bracht Der Entwurf teilt sich in drei Prozesse auf Dem Timer Prozess timerpr der die Taktsignale zur Audioansteuerung erzeugt und dem ddmtop in dem je de andere Logik enthalten ist Der Prozess regs ist f r die Ansteuerung des Sy stemtakts an den Registern verantwortlich Um die Funktionsweise der Schaltung zu erkl ren ist sie in die Bereiche der Abb 4 2 aufgeteilt In der realen Schal tung sind diese jedoch nicht so klar getrennt und die Trennung dient lediglich der bersichtlichkeit Im Folgenden werden zuerst die erforderlichen Signale zur Ansteuerung des Audiobausteins AKM AK4520A erkl rt 4 3 1 Die Signale des AKM AK4520A Der AKM AK4520A kann ein Stereo Audiosignal mit einer Samplefre quenz von max 48 kHz und einer Aufl sung von 20 Bit simultan aufnehmen und abspielen Die digitalen Audiodaten werden dazu seriell in den Baustein hinein oder aus ihm heraus bef rdert Zur Synchronisation ben tigt er einen Mastertakt MCLK ein Shifttakt SCLK und einen Takt der zwischen rechtem und linken Ka nal umschaltet LRCK Von diesen Takten h ngt die benutzte Samplefrequenz ab Wenn der Takt LRCK nicht durchgehend anliegt wird ein Reset auf dem Baustein ausgef hrt Von der Schaltung werden deshalb alle Takte durchgehend ausgege ben damit das System immer zu Audioaktionen bereit steht Der Audi
60. hl bei Stop ra i 3 2 1 0 3 2 1 0 Mikrotaster Mikrotaster l scht gew hlten Titel l scht alle Aufnahmen Y y Y i Y 3 2 1 0 3 2 1 0 Mikrotaster Mikrotaster Abbildung 4 10 Bedienung des Diktierger ts Kapitel 5 Zusammenfassung und Ausblick In der Arbeit wurde eine System on a Chip Entwicklungsplattform f r die Abtei lung Rechnerarchitektur zusammengestellt LEON wurde aus den auf dem Markt erh ltlichen eingebetteten Systeme als Plattform ausgesucht Sie wurde an die Designwerkzeuge der Abteilung angepasst Die LEON Plattform wurde auf dem ausgew hlten XSV 800 Hardware Prototypenboard in Betrieb genommen Um die Entwicklung eines SoC mit der Plattform zu demonstrieren wurde ein digi tales Diktierger t darauf implementiert Dazu wurde ein eigener Core entwickelt und ber den AMBA Bus mit dem System verbunden Mit der daf r geschrie benen Software wurde das Diktierger t auf dem Board erfolgreich umgesetzt Es kann ohne einen externen Rechner als eigenst ndiges System betrieben werden Die Arbeit zeigt neben der Umsetzung auch einen interessanten Einblick in den neuen Zweig der freien Hardwareentwicklung LEON als die erste Open Source CPU steht erst am Anfang ihrer M glichkeiten So kann durch hohe Ver breitung und der billigen Umsetzung auf FPGA basierter Hardware eine sehr schnelle Entwicklung erreicht werden Leistungsstarke Umsetzungen f r Divi dierer und Multiplizierer sind schon in naher Zukunft zu erwarten
61. hold gt false lddelay gt 1 fastdecode gt false impl gt 0 version gt 0 constant iu_fpga iu_ config type nwindows gt 8 multiplier gt none fpuen gt 0 cpen gt false fastjump gt true icchold gt true lddelay gt 1 fastdecode gt true impl gt 0 version gt 0 constant fpu_none fpu_config_type fpu gt none fregs gt 0 version gt 0 constant fpu_meiko fpu_ config _ type fpu gt meiko fregs gt 32 version gt 0 constant fpu_fpc fpu_config_type fpu gt fpc fregs gt 0 version gt 0 constant cp_none cp_config_type cp gt none version gt 0 constant cp_cpc cp_config_type cp gt cpc version gt 0 constant cache_2klk cache_config_type icachesize gt 2 ilinesize gt 4 dcachesize gt 1 dlinesize gt 4 bootcache gt false constant cache_2k2k cache_config_type icachesize gt 2 ilinesize gt 4 dcachesize gt 2 dlinesize gt 4 bootcache gt false constant cache_2k18_2k14 cache_config_type icachesize gt 2 ilinesize gt 8 dcachesize gt 2 dlinesize gt 4 bootcache gt false constant cache_4k2k cache config type icachesize gt 4 ilinesize gt 8 dcachesize gt 2 dlinesize gt 4 bootcache gt false constant cache Ak k cache config type icachesize gt 4 ilinesize gt 4 dcachesize gt 4 dlinesize gt 4 bootcache gt
62. i vielen technischen Fragen helfend zur Seite standen Besonderen Dank geht an meinen Betreuer Dipl Phys Rainer Dorsch f r das Kor rekturlesen und der zu jeder Zeit moralische Unterst tzung und gute Ratschl ge gab Bei Prof Dr Wunderlich bedanke ich mich f r die Erm glichung dieser Arbeit zu welcher auch die Anschaffung der Hardware z hlt Dank auch an Jiri Gaisler Hauptentwickler von LEON bei der ESA und Dr Vanden Bout bei Xess f r den guten Service bei allen Fragen die das Board betrafen Zuletzt Dank an meine Eltern die mir ber die stressige Zeit der Diplomarbeit geholfen und das Studium erm glicht haben Inhaltsverzeichnis 1 Einleitung 1 1 System on a Chip Entwicklung 1 2 Evaluierungshardware 1 3 Die Arbeit 2 Die LEON Plattform 3 2 1 LEON ein Open Source Projekt 2 1 1 Aufbau der LEON Plattform 2 1 2 Struktur des Gesamtsystems 2 1 3 Der Prozessorkern Pres a NN 2 3 Struktur der Quelltexte und Verzeichnisse 2 4 Simulation auf Registertransferebene 2 4 1 Inhalt der Testbench 2 4 2 Simulation von Standardsoftwarel 2 5 Synthese mitSynopsysDC Re E A ne td Be Peg Ad Ne Le 2 7 Simulation auf Gatterebene Aa AR AS A da 2 9 Programmierung und Ausf hrung
63. iger Ein solches auf einem Chip integriertes System ist ein System on a Chip SoC MK98 Um den Soft wareteil des Systems auszuf hren wird ein Prozessor ben tigt der meist auch die Kontrolle des Gesamtsystems bernimmt Prozessoren die in SoC oder ein gebetteten Systemen zum Einsatz kommen unterscheiden sich gegen ber den in Computern blich verwendeten CPUs in einigen Dingen So spielt bei ihnen die Leistung nur eine untergeordnete Rolle da die eigentlichen Aufgaben von den an deren Cores ausgef hrt werden Sie haben einen geringen Energieverbrauch was in mobilen Ger ten unerl sslich ist Zur Kommunikation mit den anderen Cores und der Au enwelt ben tigen sie einen on Chip Bus und beinhalten meist eine KAPITEL 1 EINLEITUNG 8 gr ere Anzahl an Standardschnittstellen wie UART und parallele Schnittstel le Viele bieten zur besseren Programmierung die M glichkeit der Instruktions erweiterung um selbst definierte Coprozessorbefehle und die Unterst tzung von komprimierten Befehlssatz Die Entwicklung eines kompletten Systems auf einem Chip wurde erst durch die immer besseren Fertigungsverfahren in der Chiptechnik und der dadurch im mer gr eren Anzahl von Transistoren pro Chip m glich Die immer gr ere Funktionalit t der Schaltungen bringt aber auch Probleme mit sich Die Anzahl der Fehlerm glichkeiten auf einem Chip steigt mit der Zahl der auf ihm aufge brachten Bauelemente Der Entwurf immer gr erer Schaltungen
64. ilinx Werkzeuge hitop hprep6 und jtagprog ben tigt F r beide Designs sind Build skripte in dem Verzeichnis cpld vorhanden Die Synthese ist ebenso mit dem Werkzeug dsgnmgr m glich Der genaue Designflow ist in dem mitgelieferten Handbuch des Xilinx Alliance Paket zu finden KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD 40 3 7 Synthese von LEON f r XSV 800 Fiir das XSV 800 Board wurden drei verschiedene Designs als Grundplattform erstellt Zwei davon benutzen das interne BPROM von LEON Sie unterscheiden sich in der Speicherbreite Das erste benutzt lediglich eine 16 Bit Speicherbank des Boards Diese Konfiguration war ohne nderungen des LEON Designs m g lich Das zweite unterscheidet sich von diesem durch ein H lldesign das LEON auf 32 Bit Speicherbreite f r die Benutzung beider Speicherb nke erweitert Das dritte Design benutzt zum Booten das FlashRAM auf dem Board LEON bietet verschiedene Konfiguration der Datenbreite an An der Anzahl der Anschl sse nach au en ndert sich dabei nichts Es werden einfach nicht alle Leitungen benutzt Die Top Entity von LEON ist im Anhang D 2Jaufgef hrt Die se besitzt einen 32 Bit Datenbus 28 Adressleitungen und die Unterst tzung von vier RAM B nken und zwei ROM B nken Bei Benutzung eines ASICs wiirden auf der fiir das Gesamtsystem entworfenen Platine die RAM und ROM Chips entsprechend mit den Bussen verbunden Bei einem FPGA System bei dem das Platinenlayout schon vorher festlieg
65. inx entwickelten Software die Programmierung m g lich Xess liefert mit dem Board Software die einen anderen Weg geht Hauptver bindung vom Board zu einem externen Rechner ist die parallele Schnittstelle des Boards ber diesen sind mit der Xess Software alle M glichkeiten das Board zu konfigurieren gegeben Dazu ist die parallele und die serielle Schnittstelle nicht an das FPGA sondern an das CPLD angeschlossen Eine direkte Ansteuerung dieser Schnittstelle ist vom FPGA aus nicht m glich Ein gro er Teil der Lei tungen von der parallelen Schnittstelle sind mit den Konfigurationsleitungen des CPLD verbunden Damit kann ber entsprechende Software das CPLD persona lisiert werden Um das FPGA das FlashRAM oder den Taktgeber des Boards zu programmieren wird jeweils ein entsprechendes Design in das CPLD gela den Die Leitungen die vom CPLD zum FPGA gehen sind daher auch an diesen Komponenten angeschlossen Zus tzlich ist dies noch bei den Leitungen zum DIP Switch zu einem Mikrotaster zam XCheckeranschluss und zu allen Leucht dioden der Fall Die Leitungen zu den Leuchtdioden sind ein gro er Teil derer die auch mit dem FlashRAM verbunden sind Diese Leitungen sind mit vier Kompo nenten verbunden Dies bringt Vor und Nachteile mit sich Statusinformationen k nnen vom FPGA und CPLD ausgegeben werden und bei FlashRAM Zugriffen geschieht dies automatisch CPLD und FPGA k nnen beide das FlashRAM be nutzen Die Ansteuerung der 7 Segmentan
66. ird das in der Umgebungsvariable CVS_RSH gesetzte Loginprogramm benutzt In der Umgebung der Abteilung Rechnerarchitektur ist dies die ssh secure shell Kommandos von CVS werden mit cvs lt command gt ausgef hrt Eine ber sicht der Befehle in CVS kann mit der Eingabe cvs commands ausgegeben wer den Die wichtigsten Befehle zur Arbeit mit CVS sind cvs import lt project name gt lt vendortag gt lt releasetag gt Beginnt ein neues Projekt mit Namen project name Der vendortag gibt dabei den Ersteller des Quelltextes an Die Version wird mit dem releasetag angegeben Mit der Option m kann ein Kommentar in Anf hrungszeichen angegeben werden welcher sonst mit dem Stan dardeditor eingegeben werden soll In dem neu er ffneten Projekt werden alle Dateien und Verzeichnisse des aktuellen Pfades gespei chert cvs checkout lt project name gt L dt die zu einem Projekt geh renden Dateien und Verzeichnisse in der aktuellsten Version vom Server in den aktuellen Pfad cvs diff file name Gibt die Unterschiede zwischen der optional angegebenen Datei en und der aktuellen Version dieser Datei en auf dem CVS Server an Wird keine Datei angegeben werden alle in dem aktuellen und in den Verzeichnis darunter befindlichen Dateien untersucht Statt einer Da tei kann auch ein Verzeichnis oder auch mehrere Dateien angegeben werden ANHANG A CVS 65 cvs update file name Dabei werden mit Hilfe eines diff die Unterschiede zwischen d
67. ist aber die Ver haltensmodelle von Xilinx daf r zu verwenden Diese sind in den Xilinx unisim Bibliotheken enthalten Sollen diese verwendet werden muss das mitgelieferte Verhaltensmodell der RAM Zellen in der Datei tech_virtex vhd auskommentiert werden Damit die Datei daf r nicht st ndig ge ndert werden muss wurde eine eigene Datei mit dem Namen tech_virtex_unisim vhd f r die Simulation mit den unisim Bibliotheken angelegt Das Makefile in leon wurde daf r entsprechend angepasst Mit make unisim wird LEON mit den unisim Bibliotheken bersetzt Eine nderung in der Datei target vhd ist dazu aber noch n tig und wird im Ab schnitt 8Jerkl rt 2 4 1 Inhalt der Testbench Die mitgelieferte Testbench pr ft die Funktionalit t der einzelnen Komponenten von LEON Dazu wird ein spezielles Testprogramm auf der CPU ausgef hrt Der Quelltext des Programms befindet sich in dem Verzeichnis tsource Mit dem Ma kefile kann mit dem von der ESA bezogenen C Compiler der Quelltext bersetzt werden Das Ergebnis wird in den Dateien ram dat und rom dat gespeichert In ihnen stehen die Programme als Speicherauszug im Hexdump Format und werden vom Simulationsmodell der Testbench verwendet Dieses liest deren Inhalt in die simulierten RAM und ROM Zellen Die Erweiterungen der Namen deuten an f r welche Speichermodelle sie benutzt werden Ein gro er Teil der Testbench ist in Assembler geschrieben Nur damit ist es m glich alle Funktionen der CPU a
68. itungen f r den Transport bereit stehen Im n chsten Takt muss der Master seine Daten auf den Bus legen Mit einem erneuten HREADY Signal signalisiert der Slave dass die Daten eines Lese zugriffs an dem Bus anliegen Ist es ein Schreibzugriff singlisiert er damit dass die Daten bernommen wurden In Abb 2 7 ist derselbe Transfer mit optimalem Zeitverhalten zum Vergleich zu sehen Die Signale werden beim AHB jeweils in der positiven Flanke des Bustakts angelegt und liegen mindestens bis nach Beginn der n chsten positiven Flanke an In den Diagrammen wird zwischen Signalen die auf einer und denen die auf mehreren Leitungen bertragen werden unterschieden Bei den Signalen auf einer Leitung wurde ein grau eingef rbter bergangsbereich zur bersichtli cheren Darstellung eingezeichnet Ist das Signal HREADY als logisch 0 und eingezeichnet kann einer der beiden Werte anliegen was von der vorherge henden Aktion auf dem Bus abh ngt Bei Signalen auf meheren Leitungen kann keine genaue Zuordnung zwischen 1 oder 0 gemacht werden weswegen nur die bergangszeitpunkte mit einem kurzen Zusammenlaufen der Signale markiert sind Der beschriftete Bereich gibt dabei an wann die Daten f r den Transfer auf dem Bus anliegen m ssen Der AHB unterst tzt im Gegensatz zum ASB Bursttransfers F r deren Steue rung sind einige Leitungen n tig die bisher unter dem Namen Control zusam mengefasst wurden Es folgt eine kurze
69. ktierger t erkl rt lberuhend auf dem GNU Compiler und den GNU Binutils Kapitel 2 Die LEON Plattform Die Steuerung von eingebetteten Systemen kann durch eine CPU erfolgen Dabei ist der Zugriff auf den Quelltext des Prozessors f r die Abteilung Rechnerarchi tektur von gro em Interesse und sollte deswegen als Softcore vorliegen Dank des geringen Kostenaufwandes einer FPGA Entwicklung und den Vorbildern aus der Softwareentwicklung gibt es mittlerweile drei ernst zu nehmende Open Source Projekte f r CPUs Diese sind die Freedom die OpenRISC und die LEON CPU Zur Zeit dieser Arbeit befinden sich die Freedom und die OpenRISC CPU noch am Anfang ihrer Entwicklung weswegen hier der von der ESA entwickel te LEON Prozessor verwendet wird Der Vorg nger von LEON ist die ERC32 CPU von welcher ebenfalls die Quelltexte bei der ESA frei erh ltlich sind Diese ist aber eine eigenst ndige CPU die sich nicht sehr gut f r eingebettete Systeme eignet Kommerzielle Alternativen wurden nicht ber cksichtigt da der Kosten aufwand f r ein solches System mit Zugriff auf den Quelltext zu gro w re Die Kosten w rden neben der Beschaffung des Systems auch einen eigenen Rechner cluster beinhalten Es w rde zudem zu lizenzrechtlichen Problemen bei Lehrver anstaltungen und bei der Ver ffentlichung von Forschungsergebnissen kommen Kommerzielle Alternativen sind der ARM der Tensilica oder ARC Prozessor Die beiden letzteren sind Entwicklungsumg
70. lt die Einstellungen der target vhd in Parameter mit der Form wie sie im Quelltext verwendet werden Im ersten Teil der target vhd stehen die Typen und Recorddefinitionen der zu setzenden Parameter Danach folgen ab Zeild 196 die eigentlichen Parameterzu weisungen Als erstes kommen dabei die Synthesewerkzeug abh ngigen Einstellungen Dabei wird f r den Parameter syntool der Wert synplify f r alle Synthesewerk zeuge au er f r Leonardo leonardo verwendet Mit targettech wird die ver wendete Zieltechnologie angegeben und damit welche tech_ vhd Datei benutzt wird F r die Synthese mit SynopsysDC muss dieser Parameter auf virtex ge setzt sein Bei der Simulation kann dieser auf generic reines Verhaltensmodell oder virtex Simulation mit zieltechnologieabh ngigem Verhalten stehen Die nachfolgenden Einstellungen geben an ob die Pads der Speicher das Registerfi le und das BPROM automatisch vom Synthesewerkzeug auf die Zieltechnologie abgebildet werden sollen oder ob die Modelle in den Dateien tech_ vhd daf r verwendet werden Die restliche Parameter geben an ob der Systemtakt als gated Clock gatedclk und das Registerfile synchron f r Schreiben und Lesen rfsyn crd rfsyncwr in der Schaltung ausgelegt werden sollen Die Parameter f r die Simulation stehen in der Konstanten syn_none f r SynopsysDC in syn_virtex Nach den allgemeinen Syntheseeinstellungen folgen die Konfigurationsein stellungen f r LEON Diese sind in die
71. m FPGA betrieben werden kann muss es KAPITEL 2 DIE LEON PLATTFORM 22 in passende Funktionen fiir die CLBs und deren Verdrahtung gewandelt werden Dazu durchl uft es den Xilinx Designflow Als erstes wird die edif Datei mit dem Werkzeug ngdbuild in ein Xilinx internes Format gewandelt Dabei werden die f r die RAM Bl cke ben tigten Zell Makros gewandelt ngdbuild stellt auch in dem Design das richtige Zeitverhalten und das Layout der Anschlusspads f r das FPGA ein Die Informationen hierf r stehen in der ucf Datei Das map Werkzeug wandelt die Gatebeschreibung in die ben tigten Funktionen um Diese werden mit dem placer and router par auf dem FPGA platziert und miteinander ver drahtet Mit bitgen wird das Design in den vom XChecker Anschluss ben tigten seriellen Datenstrom gewandelt Ein XChecker Anschluss ist die Standardpro grammierschnittstelle f r Xilinx FPGAs Wird das FPGA ber ein FlashRAM personaliersiert m ssen die Daten in einem weiteren Schritt mit promgen in eine exo Datei gewandelt werden Dieses besteht aus S Records F r den kompletten Xilinx Designflow kann auch das Werkzeug dsgnmgr das eine grafische Benut zungsoberfl che hat benutzt werden F r die kompletten Synthesevorg nge und den Xilinx Designflow gibt es in dem Verzeichnis syn Shellskripte f r die ver schiedenen Designs des XSV 800 Board Der komplette Designflow ist in Abb 2 4 zu sehen 2 7 Simulation auf Gatterebene Die Xilinx Werkzeuge la
72. mit Skripten f r die verschiedenen Synthe sewerkzeuge KAPITEL 2 DIE LEON PLATTFORM 16 tsource die Quellen f r die Software der Testbench der Quelltext des BPROM und ein ROM Generator welcher eine VHDL Beschreibung aus dem ROM erzeugt bprom Im CVS Projekt sind noch folgende bei dieser Arbeit dazugekommenen Verzeich nisse zu finden tenv eine von der Testbench abgeleitete Simulationsumgebung um Stan dardprogramme auszuf hren tenv32_back spezielle Simulationsumgebung f r die Simulation der XSV 800 Designs auf Gatterebene amba vhd iface vhd Schnittstellen Schnittstellen config vhd LEON Konfigu rationdefinitionen f r Synthese und Compilierung deklaration deklartion AMBA Bus der Module macro vhd debug vhd Einige Hilfsfunk tionen als Macros Debugging Schnittstelle f r gdb bei der Simulation sparcv8 vhd amabacomp vhd e device vhd Auswahl einer bestimmten Kon figuration aus target vhd SPARC Version 8 Befehlssatz Decodierung Schnittstellen deklaration von Entities mit AMBA Anbindung target vhd LEON Konfiguration Abbildung 2 2 bersicht ber die Schnittstellen und Konfigurationsdateien Die Funktion und die Abh ngigkeiten der Quelldateien im Verzeichnis leon k n nen den Abb P 2 Jund Abb 2 3Jentnommen werden Die Dateien in Abb P 2 ent halten haupts chlich Konfigu
73. mit den Pads des FPGA verbunden Diese werden zwar von dem Synopsys Skript nicht als Pads eingef gt geschieht von den Xilinx Werkzeugen nachtr glich In der ucf Datei gibt keine M glichkeit Pads explizit nicht anschlie en zu lassen Wel che Auswirkungen dies genau auf das Board den FPGA und die Funktionalit t des Designs hat kann nicht gesagt werden In der Zeit dieser Arbeit sind beim Be KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD 41 trieb keine Auswirkungen aufgetreten und das Verhalten wurde deswegen nicht weiter untersucht F r das zweite und dritte Design wurde die Top Entity von LEON ver ndert und eine H lle darum gelegt In dem zweiten Desgin wurden beide Speicher b nke des Boards benutzt und somit die Datenbreite auf 32 Bit erh ht Dazu wird der Adressbus in dem H lldesign doppelt nach au en gef hrt Die Chipse lect Writeenable und Outputenable Leitungen beider B nke sind dazu mit den entsprechenden Leitungen der Bank O von LEON angeschlossen Wegen der Wri teenable Leitung musste zum ersten mal die leon Entity ver ndert werden Das Signal ist bidirektional ausgelegt Der Grund dafiir ist nicht genau bekannt Dies k nnte im Zusammenhang mit der Fehler toleranten Version von LEON und de ren Benutzung in Satellitensystemen stehen Da auf eine Eingangsleitung nicht zwei Signale gegeben werden k nnen musste das Signal in eine unidirektionale Leitung ge ndert werden Alle bidirektionalen Leitungen der Jeon En
74. mit die sem auch exo Datein in das FlashRAM geladen werden k nnen C 1 Verzeichnisstruktur Der Quelltext des Programms ist in dem Projekt xstools im CVS abgelegt Der gr te Teil befindet sich in dem Verzeichnis xstools XSTOOLS Die meisten Da teien sind nach der Klasse benannt die sie beinhalten In den Unterverzeichnissen befinden sich jeweils die Hauptprogrammdateien die die Objekte aus dem ober liegenden Verzeichnis benutzen Die Unterverzeichnisse tragen dabei den Namen der Anwendung die in ihnen steht Alle Verzeichnisse und Dateien die mit gxs beginnen haben eine grafische Oberfl che Diese wurden nicht angepasst Es Microsoft Foundation Classes 68 ANHANG C PORTIERUNG DER XESS SOFTWARE NACH LINUX 69 wurden lediglich die Dateien xs oad und xsport in den Unterverzeichnissen ver n dert und bersetzt Nach dem bersetzen des Quelltextes stehen in diesen beiden Unterverzeichnissen auch die beiden ausf hrbaren Programme Zur bersetzung steht ein Makefile in dem Verzeichnis des Quelltextes zur Verf gung C 2 nderungen des Quelltextes im Detail Damit die parallele Schnittstelle unter Linux benutzt werden kann musste das Modul zur Ansteuerung der Hardware angepasst werden Die Xess Software greift zur Ubertragung der Daten direkt auf die Konfigurationsregister der Hardware zu Da unter Linux dieselbe Hardware verwendet wird konnte der Teil der Software der die Steuersignale erzeugt beibehalten werden Um
75. n 2 5 Synthese mit SynopsysDC LEON ist als SoC Plattform darauf ausgelegt mit vielen verschiedenen Synthese programmen synthetisiert zu werden F r die Programme Synplicity Synplify KAPITEL 2 DIE LEON PLATTFORM 21 Mentor Leonardo Synopsys Design Compiler und Synopsys FPGA Compiler werden Skripte oder Projektdateien mitgeliefert Zudem unterst tzt LEON meh rere Zieltechnologien und ist leicht an neue anpassbar In der Arbeit wird f r die Synthese SynopsysDC in der Version 1999 10 verwendet Die Zieltechnologie ist Xilinx Virtex mit der meisten LEON Entwickler arbeiten In der Version 2 1 von LEON war nur Unterst tzung f r Synplify im Zusam menspiel mit Xilinx vorhanden Das liegt an der M glichkeit Synplifys RAM Zellen automatisch an die Zieltechnologien anzupassen automatically inferred Dies bietet SynopsysDC welches haupts chlich f r ASIC Designs verwendet wird nicht In der Datei ramlib vhd im Verzeichnis leon sind die Technologie abh ngigen Module zu finden Zur Synthese mit Synopsys wurde die Datei um die reale Ansteuerung der RAM Zellen und der Pads erweitert Zus tzlich musste ein Buildskript f r die Verwendung von Virtex mit Synopsys erstellt werden Am Ende konnte die Funktionalit t des Designs mit einer Backannotation validiert werden Bei LEON Version 2 2 wurde die Struktur der Dateien ge ndert Die technolo gischen Abh ngigkeiten sind in einzelne Dateien verpackt Die feste Einbindung der RAM Zellen f
76. n Der Benutzer meist ein Softwareentwickler kann von diesem Dateien bezie hen check out oder solche auf ihm archivieren check in Die Versionskontrolle wird dabei vollst ndig von dem Server bernommen Dies erleichtert die Arbeit eines aber vor allem die mehrerer Entwickler erheblich Die Programmcodeda teien eines zusammengeh rigen Systems werden dabei immer in dem dazugeh rigen Projekt gespeichert welches am Anfang der Entwicklung erstellt werden muss A 1 Umgang mit CVS Um mit CVS arbeiten zu k nnen muss das CVS Programm wissen woher und wie die Daten bezogen werden Dies wird entweder direkt beim Ausf hren des Befehls cvs mit der Option d oder durch Setzen der Umgebungsvariable CVS ROOT angegeben Die Syntax ist dabei lt logintype gt lt username gt lt host gt lt path gt wobei lt logintype gt den Typ des Login angibt lt username gt der Username des Benutzers auf dem Host lt host gt der Rechnername auf dem der CVS Server l uft lt path gt der Pfad zu den Repository auf dem Server 63 ANHANG A CVS 64 ist Der logintype gibt dabei die Art der Verbindung vom Benutzerrechner zum Host an Wird pserver password authenticated server angegeben wird ein login ausgefiihrt Das angegebene Passwort wird dabei im Home Verzeichnis in der Datei cvspass gespeichert und muss beim n chsten Ausf hren von cvs nicht mehr angegeben werden Ein anderer Typ ist ext external connection program Dabei w
77. n Es besteht aus einer 56x84 Configurable Logic Block CLB Matrix Jeder CLB besitzt 2 Sli ces Eine Slice besteht wiederum aus 2 Logic Cells LC Somit hat das FPGA 56 x84 x 2x2 18816 LCs Xilinx gibt hier 21168 an Der Unterschied entsteht da Xilinx die Anzahl der CLBs mal 4 5 rechnet da sich in den CLBs noch weitere Logik befindet und sich damit die Anzahl der abbildbaren Logik erh ht Jeder LC kann eine logische Funktion mit 4 Eingangsparametern berechnen Zus tz lich ist noch Carry Logik und ein Speicherelement darin enthalten Das FPGA besitzt au erdem 28 RAM Bl cke auf denen 14 kByte an Daten gespeichert wer den k nnen Bei diesen ist die Datenbreite und die Anzahl der Ports verschie den konfigurierbar Um die Speicherbl cke in LEON zu nutzen wird die Datei tech_virtex vhd zur Synthese mit Synopsys ben tigt Die Ansteuerung der RAM Bl cke steht in Xil00b Das XCV800 ist in der Geh useform HQ240 auf dem Board montiert Diese besitzt 166 I O Pins Das genaue Pinlayout und eine genauere Spezifikation des FPGA kann in gefunden werden Die Zuordnung der Pins mit den XSV 800 Board Leitungen steht in XES00 3 4 CPLD Neben dem XCV800 FPGA befindet sich ein Xilinx XC95108 CPLD auf dem Board Dieses bernimmt die Aufgabe das FPGA zu personalisieren Das FPGA kann entweder ber die Leitungen des XCheckeranschlusses oder ber Da ten aus dem FlashRAM konfiguriert werden Mit dem CPLD ist beides m glich da die Leitungen de
78. n diesem Fall bretzdl Das Verzeichnis Repository in dem die Projekte liegen hei t usr local cvs bretzdl Zur Verbindung wird die ssh verwendet Somit m ssen die Umgebungsvariablen entsprechend nachfolgend gesetzt werden ANHANG A CVS 66 CVSROOT ext bretzdl rail6 usr local cvs bretzdl CVS_RSH ssh Es existieren folgende Projekte Leon 1 der Quelltext von LEON mit Buildskripten cpld die beiden CPLD Designs mit serieller Schnittstellen Unterst tzung xstools der Quelltext der Linux Portierung der Xess Software ddm das digitale Diktierger t als Beispieldesign xsvsoft das Arbeitsverzeichnis der Xess Software manuals bei der Arbeit verwendeten Dokumente und Handb cher designs synthetisierte Designs downloads Original Quelltexte und Programme Anhang B ModelSIM Der Compiler von Mentor wird mit vcom f r VHDL und vlog f r Verilog Pro grammcode aufgerufen Er ben tigt f r die Arbeit ein Verzeichnis in dem er die Daten ablegen kann Dieses wird mit dem Aufruf vlib lt Verzeichnisname gt erstellt Zus tzlich existiert eine Datei modelsim ini in der die Pfade der Biblio theken und sonstige Konfigurationsparameter f r Mentor ModelSIM stehen Um den Quelltext von LEON zu bersetzen gibt es ein speziell f r ModelSIM ausge legtes Makefile Durch den Aufruf von make in dem Verzeichnis leon entsteht in dem Unterverzeichnis work das Simulationsmodell Um LEON zu simulieren muss ModelSIM durch den Aufruf vsim in dem
79. nd damit der gesamte Quelltext der dabei verwendet wird Jedoch nimmt die bersichtlichkeit der Struktur des Designs bei der Simulation mit tiefer reichen dem Designflow ab Manche Signale die zu einem Register geh ren k nnen nicht mehr als zusammenh ngende Struktur erkannt werden Zudem ist die De bugausgabe der UARTs nach der Synthese nicht mehr m glich KAPITEL 2 DIE LEON PLATTFORM 24 LEON SOURCEN VHDL LEON VHDL Gatelevelbeschreibung ucf edif omg Padlayout Zeitverhalten ngdbuild ngo Timing Informationen vsim bit XSV 800 EX0 Abbildung 2 4 Designflow der Plattform KAPITEL 2 DIE LEON PLATTFORM 25 2 8 Konfiguration der Plattform LEON ist eine stark parametrisierbare Plattform Alle wichtigen Konfigurations parameter sind in der Datei target vhd zusammengefasst Diese gibt die enthalte nen Komponenten der Plattform die Einstellungen der Cachegr e des AMBA Bus die Anzahl der Registerwindos usw an Die Datei ist im Anhang D zu finden Sie bestimmt was bersetzt oder synthetisiert wird Damit sie nicht st n dig f r verschiedene Designs ge ndert werden muss gibt es in ihr mehrere Stan darddesigns mit vordefinierten Einstellungen Welches von diesen benutzt wird steht in der Datei device vhd Die Datei config vhd wande
80. nutzbare 32 Bit Ar chitektur welche in Bezug auf Registeranzahl und CPU Umfang skalierbar ist Das bedeutet dass Einheiten wie MMU FPU Co Prozessoren Caches optional integriert werden k nnen aber deren Ansteuerung im Falle einer Implementie rung klar definiert ist 2general public license KAPITEL 2 DIE LEON PLATTFORM 13 2 1 2 Struktur des Gesamtsystems FPU PCI gt LEON SPARC Integereinheit Co proc i cache d cache AHB a cache AMBA Master Arbiter Benutzer definierter lp AMBA AHB 1 Core Speicher Schnittstelle UART 1 0 Port AHB APB AMBA Slave Br cke Timers IrqCtrl BPROM 1K AMBA ARB LEON Plattform 8 16 32 bit Datenbus ROM SRAM VO Abbildung 2 1 bersicht ber das Gesamtsystem von LEON Abb 2 1 zeigt eine bersicht ber den Aufbau der LEON Plattform Oben links befindet sich der eingebettete Prozessor welcher im n chsten Abschnitt n her beschrieben wird Der Prozessor ist ber den Befehls und den Datencache mit dem AMBA Bus verbunden und ber diesen auch mit den anderen Modulen oder Cores des Systems Die Plattform besitzt von Haus aus eigene Peripherie Dies sind zwei UARTs eine parallele Schnittstelle ein Interruptcontroller zwei Timer und ein Watchdog Sie sind in der Mitte der Zeichnung ersichtlich Gesteu er
81. nzusteuern spart aber auch Platz Durch die kompakte Form der Software wurde die Ausf hrungszeit des Tests kurz gehalten Die Testbench besteht auf den folgenden Teilkomponenten welche in dieser Reihenfolge nacheinander auf der CPU ausgef hrt werden e Test der Speicherschnittstelle e Cachetest e Registerfiletest e Test des Interrupt Controllers e Test der Timer des Watchdog und der power down Funktion e Test der parallelen Schnittstelle e Test der seriellen Schnittstellen KAPITEL 2 DIE LEON PLATTFORM 20 Die Testbench enth lt noch Tests f r die FPU und den EDAC Speicher Error Detection And Correction der Fehler toleranten LEON Version Diese Kompo nenten sind in der Plattform der Arbeit nicht enthalten und werden nicht getestet Die Testbench merkt dies automatisch Bei den Tests der Peripherie muss jedoch darauf geachtet werden ob diese auch vorhanden sind So wird z B der Watch dog f r die FPGAs Designs nicht mitsynthetisiert und ist in der Simulation auf Gatterebene nicht vorhanden Die Testbench w rde unver ndert mit einem Fehler beenden Um die Testbench im Umfang anzupassen kann die Datei leon_test c in tsource bearbeitet werden Eine Ausf hrung der Testbench auf realer Hardware ist nicht m glich da die Auswertung und Ansteuerung der u eren Signale fehlt 2 4 2 Simulation von Standardsoftware Die bisherige Simulation dient vor allem zum funktionalen Test der Plattform Dazu wird die mitgelieferte Testbench
82. obaustein kann in verschiedenen Modi betrieben werden die durch die Eingangssignalen DIFO DIF und CMODE ausgew hlt werden DIFO und DIF sind auf dem XSV 800 Board fest mit 10 angesteuert Dies entspricht Modus zwei und be deutet dass die Audiodaten mit 20 Bit hochwertigstem Bit zuerst bei der Ein und Ausgabe geschoben werden CMODE steht fest auf 1 und hei t dass der MCLK das 256 fache der Samplefrequenz betragen muss Die Audiodaten wer den ber die Leitungen SDTI und SDTO in und aus dem Baustein geschoben Das genaue Zeitverhalten der Signale ist in der Abbildung 4 3 aus der AK4520A Spe zifikation zu sehen Das Verh ltnis vom SCLK zur Samplefrequenz ist nicht fest vorgegeben und muss lediglich tiber das 40 fache zur Samplefrequenz betragen Um den Takt gut mit dem MCLK synchronisieren zu k nnen wurde der SCLK ein Viertel so schnell wie dieser gew hlt Somit betr gt der SCLK das 64 fache der Samplefrequenz Da nur 20 Bit an Audiodaten pro Kanal anfallen wer den jeweils 12 Bit don t cares nach den eigentlichen Daten geschoben Dadurch erzeugt die Schaltung die 32 Bit pro Kanal 2 x 32 64 KAPITEL 4 DIKTIERGER T ALS SOC 50 LRCK p 01 2 3 7 17 18 19 20 21 E 18 19 20 21 7 SI TTT T tr r soroe _lielelilie ZTeT2TiTo elle 3 2 1 0 ele INN SDTI 19 18 17 16 2 3 2 0 Dont Care a AL a 2 o Dont Care oc 19 MSB 0 LSB ee MS D Lch Data Rch Data
83. rationseinstellungen und Schnittstellendefinitionen Da diese mit mehreren Dateien in Abh ngigkeit stehen sind sie in einem eigenen KAPITEL 2 DIE LEON PLATTFORM leon vhd pa mcore vhd uart vhd irqctrl vhd ioport vhd clkgen vhd rstgen vhd Iconf vhd d ahbtest vhd proc vhd moriva ahbstat vhd 11 apbmst vhd ahbarb vhd padlib vhd D bprom acache vhd cache vhd iu vhd regfile vhd Li cachemem vhd ramlib vhd techlibs technolgie spezifische S Bibliotheken dcache vhd icache vhd tech_atc35 vhd tech_generic vhd tech_leonardo vhd tech_synplify vhd Abbildung 2 3 bersicht der LEON Quelldateien 17 Schaubild untergebracht Die Datei target vhd verdient von diesen besondere Be achtung da in ihr alle konfigurierbaren Parameter der LEON Plattform zu finden und bei Bedarf zu ndern sind Siehe dazu Abschnitt 2 8 In AbbP 3 sind die Abh ngigkeiten der restlichen Quelldateien zu erkennen Die Funktionen die sich hinter jeder Datei verstecken lassen sich meistens an deren Namen erkennen Die etwas schwerer verst ndlichen sind Iconf vhd LEON Konfigurationsregister in ihm steht mit welchen Parametern die CPU synthetisiert wurde ahbtest vhd AHB Testslave reagiert mit festen Verhalten ahba
84. rb vhd der AHB Arbiter apbmst vhd die AHB APB Br cke KAPITEL 2 DIE LEON PLATTFORM 18 ahbstat vhd Statusregister des AHB bei einem Fehler im AHB werden wichtige Daten ber Adresse und Daten darin abgelegt acache vhd die AMBA Schnittstelle f r die Caches 2 4 Simulation auf Registertransferebene Um die Hardware und Softwareentw rfe zu validieren gibt es verschiedene Si mulationsmodelle Neben dem reinen Instruktionslevelemulator SIS der in Ab schnitt 2 9 erl utert wird gibt es die M glichkeit die Hardwarebeschreibung auf Registertransferebene RTL oder auf Gatterebene zu simulieren Diese Simula tionen dienen vor allem zur berpr fung der Funktionalit t der Hardware Si muliert wurde mit Mentor ModelSIM in der Version 5 4e In diesem Abschnitt wird die Simulation auf Registertransferebene beschrieben und sp ter nach der Synthese die Simulation auf Gatterebene Damit die Schaltung simuliert werden kann muss der Quelltext der Hardware mit einem VHDL 87 kompatiblen Compiler bersetzt werden siehe Anhang B Die Schaltung kann f r sich alleine nicht simuliert werden Dazu fehlen noch ein RAM und ein ROM Modell und Software die auf dem System ausgef hrt wird Sie befinden sich in den Verzeichnissen tbench und tsource In tbench liegt die mitgelieferte Testbench von LEON Diese kann mit dem darin befindlichen Ma kefile bersetzt werden Die Software fiir die Testbench liegt fertig in den Dateien ram dat und rom
85. rd durch Setzen der Leitung PENABLE auf logisch 1 si gnalisiert Dieser Zustand dauert ebenfalls einen Takt In ihm muss bei einem Lesezugriff der Slave die Daten auf der Leitung PRDATA bergeben Im n chsten Takt ist der Zugriff zu Ende und alle Signale werden gel scht Der Zustand idle wird eingenommen 2 10 2 AHB Der AHB ist wesentlich komplizierter aufgebaut als der APB Er ist f r hohen Durchsatz konzipiert Wie der ASB unterst tzt er im Unterschied zum APB mehrere Busmaster Nach AMBA Spezifikation sind bis zu 16 Master m g lich Zus tzlich kann ein AHB Bursttransfers ausf hren bei denen Daten die im Adressbereich aufeinander folgen in einem sequentiellen Transfer transportiert werden Um einen hohen Durchsatz zu erzielen ist der Bus als Pipline ausgelegt Dabei werden die Adress und Steuerdaten eines Transfers einen Takt lang auf den Bus gelegt Die dazugeh rigen Daten werden in den darauffolgenden Tak ten transportiert W hrend dieser Takte werden schon die n chsten Adress und Steuerdaten angelegt Zur Handhabung des Busses sind einige Leitungen mehr erforderlich als beim APB und das Protokoll ist aufwendiger In dieser Arbeit wurde ein Master f r den AHB entwickelt Er benutzt nur einen einfachen nicht sequentiellen Transfer Die Erl uterungen zum AHB beziehen sich nur auf die KAPITEL 2 DIE LEON PLATTFORM 30 Grundlagen um einen Master mit einem solchen Transfer zu entwickeln F r weitere Details sei
86. rkl rt Bei der Erzeugung der ROM Daten f r die Simulation mit ModelSIM sind dabei folgende Dinge zu beachten Das ROM sollte die Programmdaten nicht komprimiert enthalten Dies kann mit der Option nocomp beim Aufruf von mkprom verhindert werden Das so erzeugte ROM kann anschlieBend mit sparc rtems objdump und den Optionen d oder s als die f r die Simulation ben tigte ROM Datei als Hexdump oder als Assembler Code ausgegeben werden In dem ROM Code sollte die Abschnit te lt memclr gt und lt _clean gt mit nops hexcode 01000000 deaktiviert werden An welchen Adressen diese stehen kann in dem Assembler Output nachgesehen werden Dieses Vorgehen ist f r eine akzeptable Ausf hrungszeit der Simulation wichtig Ohne die nderungen wird erst der komplette Speicher gel scht Vor der bertragung der Software in das RAM ein zweites Mal Zum Schluss w r de die Anwendung zeitaufwendig entpackt Die Datenbreite des ROM wird beim Systemstart an den beiden unteren Bit PIO 0 1 der leon Entity der parallelen Schnittstelle angelegt 00 8 Bit 01 16 Bit 1x 32 Bit Bei der mitgelieferten Softwareentwicklungsumgebung ist auch das Realtime Betriebssystem RTEMS dabei Dies wurde nicht verwendet und wird daher nicht weiter diskutiert 2 10 AMBA AMBA Advanced Microcontroller Bus Architecture ist ein offener Busstandard von ARM Seit der LEON Version 2 2 wird diese als Systembus verwendet AM KAPITEL 2 DIE LEON PLATTFOR
87. rstellt und der Adressbereich der Register eingetragen 0x200 0x208 4 5 Aufbau und Benutzung der Software Die Software f r das Diktierger t ist ausschlie lich in C geschrieben und besteht aus zwei Dateien In der Programmdatei ddm c befinden sich das eigentliche Pro gramm das in einige Funktionen aufgeteilt ist Die Headerdatei ddm h enth lt die Definition der C Struktur ddmregs siehe Anhang D die f r den Zugriff auf die Speicher abgebildeten Register zust ndig ist KAPITEL 4 DIKTIERGER T ALS SOC 56 4 5 1 Zugriff auf die Register und ihre Funktion Die Variablen der C Struktur ddmregs spiegeln die Register in der Hardware wie der Die Variablen sind alle vom Typ unsigned int welcher wie der AMBA Bus 32 Bit breit ist Damit die einzelnen Variablen in der structure nicht vom Com piler in der Reihenfolge ge ndert werden k nnen muss die Anweisung volatile davor gestellt werden Diese verhindert das Optimieren der nachfolgenden Va riablen durch den Compiler Durch das Schreiben des Wertes REGSTART wel cher die Anfangsadresse der Register im Speicher enth lt in einen Zeiger auf die structure werden Zugriffe auf die Variablen dieser structure in Zugriffe auf die dazugeh rigen Hardwareregister 31 543210 31 0 0x80000200 inbenutzi 0x80000204 32 Bit Adresse controlreg startaddr irq 1 aktiv irgen 1 an 0 aus Loopmode 1 an 0 aus Aufnahme 1 rec 0 play Audiocore 1 an 0 aus
88. s AMBA Bus KAPITEL 2 DIE LEON PLATTFORM 29 2 10 1 APB ber den APB werden die Speicher abgebildeten Register der Peripherie ange sprochen Dies sind normalerweise Konfigurationsregister zu denen nur geringer Datendurchsatz ben tigt wird Jedes Peripheriemodul h ngt als Slave an dem APB Sie erhalten ber den einzigen Master der APB AHB Br cke Datenzugrif fe Die Br cke ist wiederum ein Slave auf dem AHB In Abb 2 5 unten rechts sind die einzelnen Leitungen des APB zu sehen Der Einfachheit halber ist nur ein APB Slave in der Zeichnung eingezeichnet Ein weiterer Slave muss wie der erste mit allen Leitungen an der Br cke angeschlossen werden Als Systembus in einem eingebetteten System ist der Bus nicht als Tristate Bus ausgelegt Es sind also f r jeden Slave eigene Leitungen vorhanden Bekommt die Br cke einen Zugriff auf einen ihrer Slaves als Auftrag ber den AHB kann sie ber die Adresse decodieren welcher Slave angesprochen ist ber die Leitung PSELx wird diesem Slave signalisiert dass auf ihn ein Zugriff erfolgt Das x in dem Leitungsnamen bedeutet dass f r jeden Slave eine eige ne ihm zugeordnete Leitung existieren muss Zeitgleich mit dem Signal PSELx wird auch ber die Leitungen PADDR PWDATA und PWRITE die Adresse die Schreibdaten und die Richtung des Datenzugriffs bergeben Dieser Zustand wird setup genannt und dauert genau einen Takt auf dem APB Der n chste Zustand hei t enable und wi
89. s Kanals wird ein Schiebestop gesetzt In diesem Fall wird konstant eine 0 am Audioausgang angelegt Erst beim Wechsel von Jr sel auf den linken Wiedergabe Kanal wird der Schiebestop wieder gel scht Der Core arbeitet nur mit einem Audiokanal ist also Mono Bei der Wiedergabe auf dem linken Kanal liegen die Daten zur Aufnahme aus dem rechten Kanal AK4520A arbeitet simultan an Der Core hat dadurch das Verhalten auf dem rechten Kanal aufzunehmen und auf dem linken abzuspielen Dieses Verhalten wurde f r eine leichtere Implementierung in Kauf genommen Nach dem Schieben der eigentlichen Audiodaten werden die Daten bei einer Aufnahme in das 32 Bit Register audiobuffer kopiert Bei der Wiederga be werden diese von dort in das Schieberegister gelesen Anschlie end wird ein DMA Transfer mit DMAREQ ausgel st Diese Anfrage wird vom AHB Master KAPITEL 4 DIKTIERGER T ALS SOC 54 ausgefiihrt Alle Signale zum Audiobaustein werden zeitgleich auf den Ausg ngen ange legt Dazu werden die Signale zum Teil noch einmal zwischengespeichert 4 3 6 AHB Master DMAREQ stopaddr controlreg 32 loopen audioen ES startaddr 8 Komperator 2 32 Y i o gt HBUSREQx y 32 Y E Pe Control act_mem_adr Steuer AHB La HGRANT logik me HREADY rt Controller 4 gt gt HADDR i HR
90. s extern zug nglichen XCheckeranschlusses auch an ihm an geschlossen sind Die M glichkeiten der Programmierung und der Betrieb des Boards wird in den nachfolgenden Abschnitten erkl rt Das CPLD besitzt sechs Bl cke mit jeweils 36 Eingangssignalen In ihnen wird von 18 Makrobl cken aus den Eingaben jeweils ein Ausgabesignal erzeugt Die Ausgaben k nnen wiederum als Eingabe f r andere Bl cke dienen oder aus dem Chip ausgegeben werden Somit k nnen maximal 6 18 108 Pins angesteu ert werden Das TQ100 Geh use auf dem XSV 800 Board besitzt aber nur 100 Im Unterschied zum FPGA besitzt das CPLD ein eigenes internes FlashRAM Seine Konfiguration ist bei Unterbrechung der Stromzufuhr dadurch nicht fl ch tig Deswegen ist bei dessen Programmierung Vorsicht geboten da auch die zu dessen Konfiguration notwendigen Leitungen in einem Layout benutzt werden k nnen Sind diese f r die Programmierung nicht mehr zug nglich kann der Baustein nicht mehr benutzt werden KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD 37 3 5 Kommunikation und Konfiguration Zentraler Punkt des XSV 800 Board ist das FPGA Von ihm gehen Leitungen zu fast allen anderen Komponenten und steuert die Perpheriebausteine der Schnitt stellen an Im Zusammenspiel mit der Programmierung und dem CPLD gibt es jedoch Besonderheiten die in diesem Abschnitt beschrieben werden Die Personalisierung des FPGA kann ber den XCheckeranschluss erfolgen ber es ist mit der von Xil
91. sierung der Start und KAPITEL 4 DIKTIERGER T ALS SOC 59 Stopadresse abzupassen wird aus dem Register act_mem_adr die aktuelle Spei cheradresse ausgelesen Am Ende der Aufnahme wird von der Funktion ein Zei ger auf die Aufnahme zur ckgegeben welcher in dem Array der ddm Funktion gespeichert wird Die Wiedergabe funktioniert gleich der Aufnahme nur dass die einzelnen Aufnahmebl cke mit trans_back zur ck bertragen und anschlie end abgespielt werden Dazu wird die Funktion ddm_play mit bergabe des Zeigers auf die Aufnahme aufgerufen In der Funktion main wird entweder die Testbench mit Aufruf von test oder die Anwendung mit Aufruf von ddm gestartet 4 5 3 Benutzung der Software Das Programm kann mit dem Makefile in dem Verzeichnis ddm software bersetzt werden Dabei wird auch die f r den Betrieb mit dem FlashRAM ben tigte exo Datei erzeugt Die Diktierger tanwendung gibt Kontrollausgaben auf der seriellen Schnittstelle aus Gesteuert wird sie ber die Taster des Boards Die Bedienung kann Abb 4 10 entnommen werden Der aktuelle Index der Aufnahme oder Wie dergabe wird in dem Hexdisplay angezeigt KAPITEL 4 DIKTIERGER T ALS SOC 60 Reset Wiedergabe Skip Stop bei Aufnahme 3 2 1 0 3 2 1 0 Mikrotaster Mikrotaster Aufnahme Titelwa
92. ssen den Designflow nicht nur in eine Richtung zu Zur Kontrolle kann das Design an zwei Stellen wieder in eine Beschreibung auf Gat terebene gewandelt werden Nach dem Wandeln in das Xilinx Format kann es mit ngd2vhdl in eine VHDL Beschreibung auf Gatterebene zur ckgewandelt werden Das Ergebnis kann wiederum mit ModelSIM simuliert werden Dazu miissen die Simulationsbibliotheken simprim von Xilinx verwendet werden Nach dem place and route gibt es die M glichkeit das Design mit ngdanno in ein weiteres For mat zur ckzuwandeln das ebenfalls mit ngd2vhdl in eine VHDL Beschreibung auf Gatterebene gebracht werden kann Diese kann wie die erste mit Model SIM simuliert werden Der Unterschied zwischen den beiden ist dass bei der Backannotation das Design komplett f r das FPGA abgebildet worden ist Die direkte Umwandlung spiegelt aber nur die Synthese mit SynopsysDC wieder Bei der Backannotation ist w hrend der Arbeit ein besonderes Verhalten aufgetreten Das backannotierte Design funktioniert nur wenn bei der Verwendung von dem Werkzeug map die Option u angegeben wird Die Option hat zur Folge dass in dem Design keine unbenutzte Logik entfernt werden darf Es konnte bis zum Schluss der Arbeit nicht gekl rt werden warum das backannotierte Design ohne die Option nicht funktioniert Auf der Hardware funktioniert es dagegen Mit der Simulation auf Gatterebene wird ein synthetisiertes Design getestet KAPITEL 2 DIE LEON PLATTFORM 23 u
93. t ergeben sich damit aber Probleme Das XSV 800 Board besitzt zwei getrennte RAM B nke und ein ROM FlashRAM Alle werden mit getrennten Leitungen vom FPGA angesteuert Um das RAM und das ROM zu benutzen miissen die Leitungen des Daten und Adressbus nach au en verdoppelt werden F r den bidirektionalen Datenbus ist das nicht so trivi al F r die Adressleitungen ist dies auch nicht mit entsprechender Konfiguration der ucf Datei getan da dies keine doppelte Zuordnung von Ausgangsleitungen zul sst Ohne nderung des L ON Designs ist somit der Anschluss mehrerer Speicherchips mit dem Board nicht m glich Das erste Desgin erlaubt es jedoch LEON ohne nderungen auf dem XSV 800 Board zu betreiben Mit Benutzung des internen BPROM kann auf das ex terne ROM verzichtet werden Benutzt man die 16 Bit Speicherschnittstelle reicht eine Speicherbank des Boards f r den Betrieb aus Der Adressbus wird auf diese Weise nur einmal ben tigt und der Datenbus wird nur auf den oberen 16 Bit von LEON benutzt In dem Verzeichnis syn sind die ben tigten Dateien f r die Syn these zu finden Das bash Skript build_script_bprom_16b synthetisiert und bildet das Design f r das FPGA ab Die Datei build_xsv800_bprom_16b dc ist das da zugeh rige Synopsys Skript Das Padlayout f r den FPGA ist in xsv800_16b ucf zu finden Dieses legt das Layout f r die im Betrieb ben tigten Leitungen fest Alle nicht ben tigten Anschl sse der LEON Top Entity werden zuf llig
94. t einer geringen Anzahl von Eingangsvariablen ab bilden enthalten aber auch Speicherzellen f r sequentielle Logik Der Unter schied zwischen CPLD und FPGA besteht dabei in der Komplexit t Ein CPLD ist weitaus einfacher in der Struktur als ein FPGA FPGAs besitzen eine gro e Anzahl von CLBs die auf ihnen in einer Matrix Feld angeordnet sind Bei CPLDs sind dies weitaus weniger und nur ein Dimensional angeordnet Die Ver bindungsleitungen zwischen den CLBs k nnen beim FPGA als auch beim CPLD frei programmiert werden Alle diese Bausteine gibt es in unterschiedlichen Technologien die sich in der Art der Personalisierung unterscheiden Bekannte Techniken sind SRAM EPROM EEPROM und Antifuse Diese sind wie in der Speichertechnik f r die verschiedenen Eigenschaften in der Reprogrammierbarkeit und Fl chtigkeit der Konfigurationsdaten verantwortlich Der genaue Aufbau eines CLB und die Integration zus tzlicher Bl cke z B von RAM und deren Anzahl unterscheiden sich zwischen den verschiedenen FPGA Modellen 3 3 FPGA Auf dem Board befindet sich das Xilinx Virtex XCV800 FPGA mit Speedgra de 4 Der Speedgrade gibt die Verz gerungszeiten der Bl cke auf dem Baustein KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD 36 an Je gr er der Wert ist desto schneller schalten die Bl cke Der Speedgrade w chst ungef hr linear mit der Schaltgeschwindigkeit der Bausteine Das FPGA auf dem Board kann maximal 888 439 Systemgatter abbilde
95. t werden sie ber Speicher abgebildete memory mapped Register welche ber die AHB APB Br cke des AMBA Bus mit dem Prozessor verbunden sind Der AMBA Bus und seine Komponenten werden in Abschnitt 2 10 n her beschrieben Links neben der Peripherie ist die Speicherschnittstelle zu sehen Diese erh lt als AMBA Slave von den AMBA Mastern z B den Caches Datentransferaufrufe zum Speicher Die Datenbreite des Speicherbus kann dabei wahlweise 8 16 oder KAPITEL 2 DIE LEON PLATTFORM 14 32 Bit sein Dies wird ber ein Konfigurationsregister jeweils f r RAM ROM und VO getrennt gesteuert und kann auch w hrend des Betriebs umgeschaltet werden Ab der Version 2 2 des LEON kann auch ein internes BPROM Boot PROM mit in das Design synthetisiert werden In das 1 KByte gro e ROM passt ein Bootprogramm welches die Speicherkonfiguration automatisch setzt und an schlie end ber die serielle Schnittstelle ein auszuf hrendes Programm in den Speicher laden kann Der AMBA Arbiter ist f r die Kontrolle des AMBA Bus zust ndig PCI ist kein komplettes Ger t sondern dient als Schnittstelle zu einer PCI Schnittstelle An ihr kann ein PCI Core von Phoenix angeschlossen werden Unten rechts in der Abbildung ist ein benutzerdefinierter Core zu sehen Er zeigt wie fremde Schaltungen in die LEON Plattform integriert werden k nnen 2 1 3 Der Prozessorkern Die Integereinheit zusammen mit den Caches bilden den Kern des LEON Cores Sie arbeitet nach SPARC
96. table gt ahbslvcfg_std cachetable gt ahbcachecfg_std FPGA config record constant ahb_fpga ahb_config_type masters gt 1 defmst gt 0 split gt false slvtable gt ahbslvcfg_std cachetable gt ahbcachecfg_std Phoenix PCI core config record uses two AHB master instefaces constant ahb_insilicon_pci ahb_config_type masters gt 3 defmst gt 0 split gt false slvtable gt ahbslvcfg_pci cachetable gt ahbcachecfg_std ESTEC PCI core config record uses one AHB master insteface constant ahb_estec_pci ahb_config_type masters gt 2 defmst gt 0 split gt false slvtable gt ahbslvcfg_pci cachetable gt ahbcachecfg_std AHB test config constant ahb_test ahb_config_type masters gt 3 defmst gt 0 split gt true slvtable gt ahbslvcfg_test cachetable gt ahbcachecfg_std standard config constant apbslvcfg_std apb_slv_config_vector 0 to APB_SLV_MAX 1 first last index enable function PADDR 9 0 0000000000 0000001000 0 true memory controller 0x00 0x08 0000001100 0000010000 1 true AHB status reg 0x0C 0x10 0000010100 0000011000 2 true cache controller 0x14 0x18 0000011100 0000100000 3 true write protection 0x1C 0x20 0000100100 0000100100 4 true config register 0x24 0x24 0001000000 0001101100 5 true tim
97. tartplay Sie startet die Wiedergabe einer Aufnahme auf der Hardware Die Parameter sind die gleichen wie bei der Aufnahme stop Sie h lt die Audiohardware sofort an hexddisp Sie gibt den bergebenen Wert auf dem Hexdisplay der Hardware aus dispoff Sie schaltet das Hexdisplay wieder aus Zugriffe auf das ROM sind anschlie end wieder m glich set_sample_freq Mit dieser Funktion wird der Wert des Registers scalerup ge setzt Der Wert wird dabei nicht umgerechnet Der Name der Funk tion ist deswegen etwas irref hrend wait_for_audiofinish Die Funktion wartet auf das Beenden einer Audioaktion und blockiert so lange die Ausf hrung des Programms get_buttons Sie liest den Zustand der Mikrotaster aus der Hardware aus Da es bei schnellem Programmfluss unter Umst nden zu sehr schnellem Auslesen der Taster kommen kann wird der letzte Zustand der Ta ster in einer statischen Variable gespeichert Nur bei nderung von 0 auf 1 eines Tasters wird die Aktivierung dieses Tasters von der Funktion weitergegeben trans Die Funktion kopiert den Inhalt eines 8 kByte Speicherbereichs in einen anderen Der Funktion werden dazu die Anfangsadressen der Speicher bergeben Diese Funktion dient als Schnittstelle falls die von der Hardware gelieferten Audiodaten im Speicher reduziert wer den sollen trans_back Dies ist die Umkehrfunktion von trans Sie Kopiert den Speiche rinhalt eins Puffers wieder zur ck KAPITE
98. teuerung ist wiederum in einen Timer und den Datenshifter f r den seriellen Audiostrom trennbar Die Hardware wird ber Konfigurationsregister die ber den APB gelesen oder geschrieben werden gesteuert Eine bersicht ber den Digital Dictation Machine DDM Core ist in Abb 4 2 zu sehen S Audioen Record audioin gt audioout a Audio APB APB Ir sel a a bg Ansteuerung Slave mch an SE Speicheradressen Timer Samplefreq gt o Q 2 z AHB AHB La m Master 4 Taster Display Decoder Ra 7 Segment 1 8 Mikrotaster Dispdaten Buttons 7 Segment 2 lt amp _ DDM Modul Abbildung 4 2 bersicht ber den DDM Core Die Software bernimmt die Steuerung der Hardware und die Verwaltung des vorhandenen Speichers Sie kommuniziert dabei mit der dazugef gten Hardware ber die Speicher abgebildeten Register ber die Register Dest sie den Zustand der Mikrotaster aus und wird dadurch vom Benutzer gesteuert Die Software steu ert die Audioaktionen und wohin die Audiodaten geschrieben oder woher diese gelesen werden Sie gibt an was auf den 7 Segmentanzeigen des Boards ausge geben wird Kurz gesagt ist die Hardware eine Ausf hrungsinstanz die auch f r andere Aufgaben benutzt werden kann und die Software implementiert darauf das Diktierger t KAPITEL 4 DIKTIERGER T ALS SOC 49 4 3 Schaltungsaufbau Die Sc
99. tity kom men als unidirektionale Leitungen aus den von ihr eingebundenen Modulen an Erst in der leon Entity werden diese mit Tri state Pads in bidirektionale Leitungen gewandelt F r die Writeenable Leitung wurden diese Pads entfernt Das Aus gangssignal wird direkt in die Eing nge zur ck geleitet und zus tzlich nach au en weiter gegeben Die nicht ben tigte Eingangsrichtung von au erhalb wurde da mit entfernt In dem H lldesign kann auf diese Weise das Writeenable Signal der LEON Bank 0 auf beide Speicherb nke des XSV 800 Boards gegeben werden Die ge nderte leon Entity steht in einer eigenen Datei leon32 vhd Das H llde sign mit BPROM steht in xsv800_bprom_32b vhd Damit f r das dritte H lldesign nicht eine eigene leon Entity ben tigt wird wurde die H lle f r das 32 Bit De sign mit BPROM sp ter an die gleiche leon Entity die f r die Flash Ansteuerung benutzt wird angepasst Das dritte Design f r das Board beinhaltet die Ansteuerung des FlashRAM als ROM f r den Systemstart Dazu musste der Datenbus verdoppelt werden Im Gegensatz zur Writeenable Leitung musste dabei die bidirektionale Verbindung bestehen bleiben In der leon Entity wurden dazu alle Signale der Datenleitung die von den eingebundenen Modulen kamen nach au en gelegt Dazu geh rt auch die Select Leitung die die Richtung auf dem Bus angibt In dem H lldesign xsv800_32b vhd wurde zur Ansteuerung des Datenbusses ein spezielle Entity mit Namen selector geschaff
100. unsigned unsigned unsigned unsigned unsigned int int int int int int int controlreg 0x00 startaddr stopaddrr scalerupr displechter Z 0x10 si buttonreg act_mem_adr define REGSTART 0x80000200 endif 77 Literaturverzeichnis ARM99 ARM Limited AMBA Specification 2 0 1999 ASA97 Ash96 Bou00a Bou00b Fog99 Gai99 Gai00a Gai00b Gai00c IOMO0 Jen94 leo01 ASAHI KASEI Microsystems AKM AK4520A Description March 1997 Kap 18 In ASHENDEN Peter J The Designer s Guide to VHDL Morgan Kaufmann Publishers 1996 S 511 ISBN 1 55860 270 4 BOUT D V XSV Flash Programming and Virtex Configuration 1 0 XESS Corporation April 2000 BOUT D V XSV Parallel Port Interface 1 0 XESS Corporation April 2000 FOGEL Karl Open Source Development with CVS CoriolisOpen Press 1999 GAISLER Jiri GNU Cross Compiler System 2 0 7 ESA ESTEC November 1999 GAISLER Jiri LEON 1 VHDL model description 2 2 ESA ESTEC October 2000 GAISLER Jiri MKProm 1 2 7 ESA ESTEC 2000 GAISLER Jiri SIS manual 3 0 5 ESA ESTEC 2000 1 0 Port Programming mini HOWTO November 2000 JENKINS Jesse H Designing with FPGAs and CPLDs Prentice Hall 1994 ISBN 0 13 721549 5 LEON Homepage http www estec esa nl wsmwww 2001 78 LITERATURVERZEICHNIS 79 met01 MK98 On 98 RHP93 RMS98 SPA92 Sta98 VSI97
101. wird nach Ausf h rung des Programms konstant auf der parallelen Schnittstelle ausgegeben xsport wurde in der Arbeit nicht ben tigt Beide Programme ben tigen zur Ausf hrung die Umgebungsvariable XSTOOLS_BIN_DIR auf das Xess Arbeitsverzeichnis ge setzt In ihm stehen die von Xess mitgelieferten Designs f r CPLD und FPGA Mit dem Programm xsload kann das XSV 800 Board programmiert werden Dazu wird dem Programm beim Aufruf ein Dateiname bergeben In der Datei stehen die Daten die entweder f r das CPLD das FlashRAM oder das FPGA gedacht sind Um welchen Datentyp es sich handelt wird an der Dateiendung er kannt Dateien mit der Endung svf svf Dateien sind Designfiles f r das CPLD Die bit Dateien sind Konfigurationsstr me f r das FPGA Der Inhalt von exo Dateien wird in das FlashRAM geschrieben Im Nachfolgenden wird die Konfi guration und der Betrieb mit den verschiedenen Designs beschrieben Damit auf dem FPGA die LEON Plattform betrieben werden kann muss als erstes die richtige Taktfrequenz auf dem Board programmiert werden Die richtige Jumperstellung daf r ist im Benutzerhandbuch von Xess dokumentiert Auf dem Board befindet sich ein Taktgenerator vom Typ Dallas DS1075 Dieser hat einen maximalen Takt von 100 MHz Um die Taktfrequenz herab zu setzen k nnen die 100 MHz durch einen programmierbaren ganzen Faktor geteilt wer den Die LEON Designs der Arbeit sind f r 20 MHz synthetisiert Der Teiler entspricht also f nf Damit
102. x_vprom iu gt iu_fpga cache gt cache_2k2k ahb gt ahb_fpga apb gt boot gt boot_prom debug gt debug_disas pci synthesis targetting ATC35 asic lib constant gen_atc35 config_type synthesis gt syn_atc35 iu gt iu_std fpu gt cache gt cache_4k4k ahb gt ahb_std apb gt a boot gt boot_mem debug gt debug_disas pci end any syn D 2 LEON Top Entity entity leon is port resetn in std_logic system signals clk in std_logic errorn out std_logic address out std_logic_vector 27 downto 0 data inout std_logic_vector 31 downto 0 ramsn out std_logic_vector 3 downto 0 ramoen out std_logic_vector 3 downto 0 rwen inout std_logic_vector 3 downto 0 prom fpu gt fpu_none apb_std mctrl gt gt pci_none peri cp gt cp_none mctrl_bprom gt peri_fpga tools fpu_fpc cp gt cp_none pb_std mctrl gt mctrl_std gt pci_none peri gt peri_std r memory bus ANHANG D DATEI AUSZ GE romsn iosn read brdyn pio wdogn test end out std_logic_vector 1 downto 0 out std_logic oen out std_logic out std_logic writen inout std_logic in std_logic bexcn in std_logic inout std_logic_vector 15 downto 0 I O port out std_logic watchdog output in std_logic DA ddm h ifndef __ASSEMBLER__ struct ddmregs volatile volatile volatile volatile volatile volatile volatile unsigned unsigned
103. zeige vom FPGA aus ist nur erschwert m glich Es sind fast keine Leitungen mit freier Verf gbarkeit zwischen FPGA und CPLD vorhanden KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD Serieller Paralleler Port Port 38 d EEN o O Hex Anzeige L_ II jt XILINX I_ l A XC95108 CPLD SRAM Xilinx z Virtex 16Bt FPGA XCV800 4 Mikrotaster 413 2 1 AK4520A Stereo Stereo Analog Analog Eingang Ausgang Abbildung 3 1 XSV 800 Board bersicht KAPITEL 3 PROTOTYPING VON LEON MIT XS V 800 BOARD 39 Die Programmierung des FPGA kann auf zwei Arten erfolgen Auf das CPLD wird ein Design geladen ber welches die Leitungen des XCheckeranschluss auf die parallele Schnittstelle durchgeschliffen werden Mit der Software von Xess kann so mit einem f r den XCheckeranschluss generierten Datenstrom das FPGA personalisiert werden Die andere M glichkeit ist ber das CPLD Zu griff auf das FlashRAM zu bekommen Dieses kann mit der Xess Software mit beliebigen Daten gef llt werden Mit den Xilinx Werkzeugen k nnen die Per sonalisierungsdaten des FPGA in eine f r ROM Programmierung n tige Form gebracht werden Diese werden in das FlashRAM geladen Das CPLD wird an schlie end mit einem Design programmiert das das FPGA mit den

Digitales Diktiergerät als System-on-a

Contents

Download Pdf Manuals

Related Search

Related Contents

Digitales Diktierger&auml;t als System-on-a

Contents

Download Pdf Manuals

Related Search

Related Contents

Digitales Diktiergerät als System-on-a