Home

Mustertitel titel Muster - Embedded System Software Group

1. 54 67
2. 15 Beispiel f r einen einfachen Constraint ooo a 16 Beispiel f r eine workflow Datei 17 Ein einfaches Generics Beispiel Links die entity Deklaration rechts die tat e Lia o a a ee ts ls os he feed 18 Die Syntax des generate Statements in VHDL 18 Merkmalmodell f r einen UART o 25 Subdiagramm f r kommunikationsbezogene Merkmale 26 Subdiagramm f r Interrupt bezogene Mermale 27 Klassendiagramm des Ecore Metamodells 32 Blockdiasramm des UART 4 4 2 42 4 043 As war man ne 36 Timing Schema nach RS 232 Quelle 28 39 Der erste Constraint des Modellierungsprojekts 43 Der zweite Constraint des Modellierungsprojekts 44 Der dritte Constraint des Modellierungsprojekts 44 Grobstruktur der Templatedateien 2 22 22 Comm 45 Rekursive Extension zeroes er u dh YO Nek Hane S 46 Unterscheidung der Testsysteme 52 Gegen berstellung der Ergebnisse e 55 65 Tabellenverzeichnis 5 1 Zuordnung der Konfipurationspunkt rer ra a Es 31 5 2 Mapping des Format Konfigurationsregisters 33 5 3 Wapping der Interrupt Register a e Ai oes 34 5 4 Mapping der Speicheradressen des UART 35 7 1 Ressourcenbedarf der minimalen UART Variante 53 7 2 Ressourcenbedarf der mittelgro en UART Variante 54 7 3 Ressourcenbedarf der kompletten UART Variante
3. Framegr e 5 6 7 oder 8 Datenbits Parit tsmodus odd even e Je 16 Byte FIFO f r Receiver und Transmitter nicht deaktivierbar e Trigger Level f r Receiver FIFO bei 1 4 8 und 14 Byte e Interrupts Alle Interrupts sind einzeln aktivierbar F nf Interrupt Typen mit Detailinformationen in Statusregister e Besondere Features Interrupt Priorit ten in Hardware fest Unterst tzt 8 Bit und 32 Bit Wishbone Bus Zus tzliche Register mit Debuginformationen im 32 Bit Modus 2Angabe der Projektbetreuer 23 Analyse 4 3 4 3 Zusammenfassung und Merkmalmodell Nach Betrachtung der verschiedenen UARTS zeigen sich zun chst viele Gemeinsamkei ten Darunter fallen besonders die konfigurierbare Baudrate und die Formatierungsoptio nen bez glich der seriellen Kommunikation Fast alle betrachteten UARTS unterst tzen eine Datenwortbreite von 5 bis 8 oder 9 bit Dazu kommen die Wahl von unterschied lichen Parit tsmodi sowie die Option ein bzw zwei oder 1 5 Stoppbits zu verwenden Unterschiede gab es besonders im Bereich der Pufferung von eingehenden Daten Verwal tung und Priorisierung von Interrupts sowie im Bereich der unterst tzten Schnittstellen Auch die M glichkeit einzelne Komponenten auszuschalten bzw Interrupts einzeln zu aktivieren war nicht immer gegeben Insgesamt sind aus den Ergebnissen der Betrach tung die nun folgenden Merkmaldiagramme entstanden Die Darstellung gliedert sich aus Plat
4. CPUType ConnType Simulation Boolean CikDiv Boolean ReqMHz Integer 0 ConnList 1 1 FPGA Name String Capacity Integer id Integer Type ConnType Width Integer MessageQueue Integer OutBuffer Integer 1 SOCList id Integer 1 1 Connection SOVUN 1 pn po 1 1 CPU 0 UARTList 0 Timerlist 0 OutPortList BaseAddr Long Type CPUType BaseAddr Long BaseAddr Long BaseAddr Long IRQ Boolean Freq Integer IRQ Boolean IRQ Boolean Pins Integer BEE RAM Integer Baud Integer Bit Integer Abbildung 2 2 Das Hardware Metamodell in LavA 2 4 Grundlagen aus einer gewissen Anzahl von SoCs und entsprechenden Connections zwischen diesen Ein SoC wiederum besteht aus einem Prozessor CPU und weiteren Peripherieger ten wie UARTs Timern und Interprozesskommunikationsger ten Des Weiteren gibt es zu jedem MPSoC auch schon ein Ziel FPGA Zus tzlich zu den in der Abbildung ersicht lichen Abh ngigkeiten und Zusammenh ngen gibt es noch weitere Constraints die mit Check 15 formuliert sind Bei Check handelt es sich um eine Constraintsprache hn lich wie OCL mit der man zus tzliche Beschr nkungen und Abh ngigkeiten in einem konkreten Modell annotieren kann Sie unterst tzt die automatische Validierung eines Modells bez glich der Constraints Auf der Basis dieses Metamodells muss um ein Sys MPSoC Model I
5. Um die einzelnen Varianten zu testen m ssen sie zun chst synthetisiert und auf ein FPGA gebracht werden In diesem Fall handelte es sich um ein FPGA Board der Fir ma Digilent mit einem Xilinx Virtex 5 XC5VLX110T FPGA 29 Zur Ansteuerung des UART ber die parallele Schnittstelle wurden die im vorigen Kapitel beschriebenen An steuerungsfunktionen verwendet zur Ansteuerung ber die serielle Schnittstelle wurde dahingegen auf einem mit dem Board verbundenen Rechner das serielle Terminal H Term verwendet Bei allen Testsystemen wurden zun chst die einfachen Funktionalit ten Sen den und Empfangen ber programmierte Ausgaben bzw manuelle Eingaben ber das Terminal berpr ft Dabei wurde zun chst die Standardeinstellung von 8 Datenbits ohne Parit t bei einer Baudrate von 115200 Bit pro Sekunde verwendet Im Anschluss wurden die immer vorhandenen Konfigurationsoptionen wie Stoppbitanzahl Datenwortbreite und Baudrate ber ein entsprechendes Programm f r das MPSoC variiert und wieder um die Aus und Eingaben am Terminal verifiziert Das Testen der Interrupts wurde 52 7 2 Evaluation f r jeden Interrupt individuell durchgef hrt Der Interrupt RXREADY wurde durch manuelle Eingabe der je nach System n tigen Menge von Zeichen und Ausgabe einer Testsequenz manuell verifiziert F r den Interrupt TXREADY wurde eine Testsequenz ausgegeben und bei Eintreten des Interrupts eine weitere erzeugt Parit tsfehler konnten manuell ber Send
6. dung 3 6 zu sehen Verwendet man als Obergrenze des Intervalls des iterativen generate generate label for identifier in discrete range generate concurrent_ statements end generate generate_label generate label if boolean expression generate concurrent statements end generate generate label Abbildung 3 6 Die Syntax des generate Statements in VHDL Statements eine Generic Konstante lassen sich auf einfache Weise bei der Instanziierung interne Strukturen wie z B Registerbreiten festlegen 18 4 Analyse Dieses Kapitel beschreibt die Recherche und Dom nenanalyse die die Grundlage f r den Entwurf der UART Komponente darstellen Da es eines der Hauptziele dieser Arbeit ist eine hochkonfigurierbare Hardwarekomponente zu entwickeln ist die Anforderungsana lyse gerade bez glich der Konfigurationsoptionen ein wichtiger Teil des Entwicklungs prozesses Um ein hohes Ma an Konfigurierbarkeit zu erreichen ist es erforderlich eine m glichst gro e Menge von Anwendungsf llen abzudecken Um dies zu erreichen wird in diesem Kapitel zun chst der Funktionsumfang von UARTs aus Mikrocontrollern ver schiedener Hersteller und Modellreihen betrachtet Des Weiteren wird zur Erg nzung der Ergebnisse dieser Analyse eine Auswahl von Projekten betrachtet die sich ebenfalls mit der Entwicklung von UARTs in Hardwarebeschreibungssprachen besch ftigen 4 1 UARTs g ngiger Mikrocontroller Um festzustellen welchen
7. Codegenerierung verwendet wurde bildet den Abschluss des Kapitels ein Vergleich der Templatesprachen XVCL und Xpand in Verbindung mit einer Beurteilung der Eignung von Xpand f r diese Anwendungszweck 7 1 Methodik des UART Tests Das Testen von hochkonfigurierbaren Systemen wird durch die gro e Anzahl verschiede ner Testkonfigurationen erheblich erschwert F r einen ersch pfenden Test der UART Familie m sste man zuerst alle denkbaren Varianten des UART generieren syntheti sieren und anschlie end auf dem FPGA alle Konfigurationsm glichkeiten testen Dieser Aufwand kann allerdings stark minimiert werden wenn man die Zusammensetzung der einzelnen UART Varianten genauer betrachtet und ausnutzt dass viele Teile aus densel ben Codebausteinen aufgebaut sind oder unabh ngig voneinander arbeiten und daher nicht mehrfach getestet werden m ssen Darunter fallen zum einen die RX und TX Einheiten und deren Teilmodule die als solches nicht miteinander interagieren sondern nur individuell von der Steuereinheit angesprochen werden Ebenfalls kann es umgangen werden Systeme mit verschiedenen FIFO Grofen zu berpr fen da sich die Schnittstel len nach au en nicht unterscheiden und die unterschiedlichen Gr en des Puffers nur durch Mehrfachinstanziierung gleicher Elemente realisiert werden Statt also alle m gli chen Zusammensetzungen zu testen kann beim UART Test das Ziel verfolgt werden eine Auswahl von Testsystemen aufzubauen die gemeins
8. gt lt workflow gt lt set up EMF for standalone execution gt lt bean class org eclipse emf mwe utils StandaloneSetup gt lt platformUri value gt lt bean gt lt Standard Metamodell ausw hlen gt lt bean id mm_emf class org eclipse xtend typesystem emf EmfRegistryMetaModel gt lt Konkretes Modell laden und in Slot model ablegen gt lt component class org eclipse emf mwe utils Reader gt lt uri value platform resource MyModel xmi gt lt modelSlot value model gt lt component gt lt check model gt lt component class org eclipse xtend check CheckComponent gt lt metaModel idRef mm_emf gt lt checkFile value metamodel Checks gt lt emfAllChildrenSlot value model gt lt component gt lt generate code gt lt component class org eclipse xpand2 Generator gt lt metaModel idRef mm_emf gt lt expand value templates root main FOR model gt lt outlet path src gen gt lt component gt lt workflow gt Abbildung 3 4 Beispiel f r eine workflow Datei 17 Verwendete Technologien 3 2 3 2 Konfigurationsmittel in VHDL Abgesehen von Werkzeugen zur Codegenerierung bietet VHDL auch von sich aus schon einige Mittel zur Parametrisierung und Konfiguration von Quellcode Im Wesentlichen eignen sich dazu zwei Elemente der Sprache Auf der einen Seite sind das die sogenann ten Generics andererseits das generate Kon
9. Abfrage oder ber Hardwareunterbrechungen realisiert werden Die Merk male eines UARTs mit Interrupt Unterst tzung sind im entsprechenden Subdiagramm in Abbildung 4 3 dargestellt Die Verwaltung von Interrupts variiert stark von Ger t Interrupts O O O Global Separat aktivierbar aktivierbar Q Abbildung 4 3 Subdiagramm f r Interrupt bezogene Mermale zu Ger t Welche Arten von Interrupts ein Ger t unterst tzt ist sehr verschieden Man kann sie jedoch in drei wesentliche Gruppen zusammenfassen Zum einen gibt es Inter rupts die den Empfang von Daten bzw den F llstand des Empf ngerpuffers anzeigen des Weiteren solche die sich mit dem F llstand und Status des Senders besch ftigen 27 Analyse 4 3 und zuletzt eine Reihe von Fehlerzust nden Letztere lassen sich dabei in die Gruppen Frame und Formatfehler Parit tsfehler und Puffer berl ufe einordnen Letztendlich ist jede Kombination von Interrupts m glich solange die entsprechenden Voraussetzungen im UART gegeben sind Ein Interrupt f r Puffer berl ufe w re Beispielsweise ohne einen entsprechenden Puffer nicht sinnvoll Im Allgemeinen gibt es aber die M glichkeit In terrupts wenn sie vorgesehen sind global einzuschalten Oft ist es au erdem m glich ber das Setzen von einzelnen Bits in einem Konfigurationsregister einzelne Interrupts zu aktivieren oder zu deaktivieren Es ist weiterhin m glich Interrupts bestimmte Prio rit ten zuzuordnen diese k
10. Dateien verkn pfen kann Zu diesem Zweck werden Elemente der Eclip se MWE verwendet Die MWE beinhaltet neben den eigentlichen Codegeneratoren die aus einem konkreten Modell und gegebenen Templates die letztendlichen Ausgabedateien erzeugen viele weitere Treiberklassen beispielsweise zur Validierung von Modellen an hand von Constraint Dateien aber auch Hilfsmodule wie zum Beispiel Code Beautifier zur Verbesserung der Lesbarkeit von erzeugtem Quellcode Der Ablaufplan mit dem die einzelnen Module der Laufzeitumgebung zusammenarbeiten wird in Form von workflow Dateien festgelegt Eine workflow Datei ist ein XML Dokument in dem die ben tigten Komponenten in der Reihenfolge des gew nschten Aufrufs instanziiert und konfiguriert werden Ein einfaches Beispiel ist in Abbildung 3 4 dargestellt Hier wird zun chst das Metamodell ausgew hlt das die Struktur des konkreten Modells vorgibt Danach wird das erstellte Modell geladen geparst und mit Hilfe eines entsprechenden Moduls und gegebener Check Constraints validiert Zuletzt wird ein Standard Codegenerator instan ziert der die Templates auf das geladene Modell anwendet und die Ausgabe im Ordner src gen ablegt Statt der blichen Endung xml verwenden workflow Dateien zur Ab grenzung die Endung mwe Solche Dateien sind dann in einer entsprechend konfigurier ten Eclipse Umgebung ausf hrbar 2Modeling Workflow Engine 16 32 Verwendete Technologien lt xml version 1 0
11. Funktionsumfang durchschnittliche Mikrocontroller UARTs bieten liegt es nahe zun chst verbreitete industrielle L sungen zu betrachten Zu diesem Zweck wird im folgenden ein berblick ber verschiedene solcher Ger te vermittelt 4 1 1 Atmel ATmega8 16 32 Bei der ersten betrachteten Familie von Mikrocontrollern handelt es sich um Varianten des ATmega Mikrocontrollers der Firma Atmel mit jeweils 8 16 bzw 32 KB Programm speicher Diese Modelle basieren auf der verbreiteten AVR Architektur Der USART dieser Modelle hat gem dem offiziellen Datenblatt 22 folgende F higkeiten e Synchrone und asynchrone Kommunikation Receiver Transmitter einzeln aktivier bzw deaktivierbar konfigurierbare Baudrate e Kommunikationsformat 1 oder 2 Stoppbits Framegr e 5 6 7 8 oder 9 Datenbits Parit tsmodus odd even Fehlererkennung 19 Analyse 4 1 Parit tskontrolle berlauferkennung Erkennung von Formatfehlern falsche Startbit und Stoppbitpegel e Interrupts TX Eingabe leer bertragung abgeschlossen Empfang abgeschlossen e Pufferung von empfangenen Daten durch 2 stufigen Ringpuffer e Besondere Features Modus f r doppelte Geschwindigkeit nur asynchron Tiefpassfilter Rauschfilter zur Erkennung falscher Startbits 4 1 2 NXP LPC2377 78 Die LPC2377 und LPC2378 Mikrocontroller der Firma NXP Semiconductors sind auf Anwendungen mit hohen Anforderungen an
12. M glichkeiten der Hardwareflusskontrolle RTS CTS DTR DSR RI DCD e Kommunikationsformat 1 1 5 oder 2 Stoppbits Framegr e 5 6 7 oder 8 Datenbits Parit tsmodus odd even e wahlweise keine 16 oder 64 Byte FIFOs e zahlreiche Trigger Level f r Receiver FIFO e Interrupts Daten empfangen Transmitterregister leer bertragungsfehler e Besondere Features synchrone Kommunikation Verwaltung von Interruptpriorit ten in Hardware fest Das vollst ndige Projekt ist bei der opencores org Community zu finden siehe 26 22 4 3 Analyse 4 2 2 UART 16550 core Das Projekt UART 16550 core 27 von Jacob Gorban Igor Mohor und Tadej Marko vic besch ftigt sich mit der Entwicklung eines UART in Verilog Es handelt sich hier um ein lteres Projekt als beim UART16750 Das Projekt exisiert seit 2001 und ist zum Zeitpunkt dieser Arbeit im Entwicklungsstatus stable wobei letzte nderungen am Repository im Dezember 2010 stattfanden Anhand der Statusberichte auf der Projekt seite ist jedoch anzunehmen dass der Quellcode im Jahr 2002 nahezu finalisiert wurde hnlich wie das Projekt von Sebastian Witt ist es hier eines der Ziele kompatibel zur NS16550 A Spezifikation zu sein Merkmale dieser IP Komponente e Pins und Register fast kompatibel mit NS16550 e RTS CTS und DTR DTS Kontrollleitungen e konfigurierbare Baudrate e Kommunikationsformat 1 1 5 oder 2 Stoppbits
13. Programmierer ein intuitiverer Entwurf m glich ist als mit dem deklarativen Stil von XVCL Ein deutlicher Vorteil von XVCL gegen ber Xpand ist jedoch die Kontrolle ber Generierung von Whitespace Diese ist in Xpand schwieriger da hier explizit nach jeder Steueranweisung die Erzeugung einer Freizei le durch Anh ngen eines Minuszeichens unterdr ckt werden muss Diese umst ndliche Handhabung r hrt daher dass zur Formatierung der Ausgabedateien die Verwendung eines entsprechenden Code Beautifiers angedacht ist Ein solcher existiert leider bisher f r VHDL noch nicht weshalb bei der Verwendung von Xpand ein Kompromiss zwischen der Qualit t der Templates und der Ausgabedateien getroffen werden muss 7 3 1 2 M chtigkeit der Sprachelemente Im Vergleich zu XVCL bietet Xpand wesentlich m chtigere Sprachkonstrukte an W h rend der Grundumfang beider Sprachen nur Variablenzuweisungen und auswertungen sowie while und foreach Schleifen umfasst verf gt Xpand mithilfe von Expressions und Extensions ber eine hnliche M chtigkeit wie Java Dar berhinaus kann Xpand ohne weiteren Aufwand auf grafisch erstellten Modellen arbeiten und leicht auf dort vorhan dene Attribute zugreifen ohne diese vorher in Textform zu bringen was insgesamt zu einer wesentlich geringeren Zahl lokaler Variablen f hrt und die bersichtlichkeit der Templates positiv beeinflusst Domain specific language 56 7 3 Evaluation 7 3 1 3 Werkzeugunterst t
14. die Einzelbetrachtungen in Beziehung so ergibt sich das in Abbildung 7 2 dargestellte Ergebnis Insgesamt ist zu erkennen dass die Ressourcenanforderungen des 1600 1400 1200 1000 800 600 400 200 o ui Variante 1 Variante 2 Variante 3 E Slices E Slice Reg E LUTS Abbildung 7 2 Gegen berstellung der Ergebnisse UART in Abh ngigkeit vom gew hlten Funktionsumfang ber ein breites Spektrum ska lieren Bei genauerer Betrachtung der Einzelergebnisse zeigt sich dass die Ressourcenbe legung haupts chlich in Relation zur gew hlten FIFO Gr e steht Dies war zu erwarten da es sich beim FIFO Puffer sowohl um die gr te Speicherstruktur als auch um eine der schaltungstechnisch komplexeren Komponenten handelt Die brigen Komponenten skalieren weniger stark aber ebenfalls erwartungsgem mit der Anzahl vorhandener Module im UART 7 3 Evaluation der Codegenerierung Nachdem die Implementierung des UART analysiert wurde soll nun das Generierungs projekt als der zweite gro e Implementationsabschnitt dieser Arbeit evaluiert werden Dazu wird ein Vergleich zwischen Xpand und der im LavA Projekt bisher verwendeten Sprache XVCL angestellt auf dem dann die Einsch tzung der Eignung von Xpand als alleiniges Codegenerierungswerkzeug aufbaut 7 3 1 Vergleich von Xpand und XVCL F r den Vergleich der beiden Templatesprachen werden hier als Vergleichskriterien Struk tur Ausdr cksst rke und angebotene Werkzeugunterst tzung
15. die mit Produktfamilien oder im Allgemeinen mit Variationen von Software arbeiten Die Grundelemente von XVCL sind die sogenannten x frames Ein x frame ist eine XML Datei die beliebigen Text im Kontext von LavA handelt es sich dabei um VHDL Code und Anweisungs Tags enth lt Bez glich der Anwei sungen unterst tzt XVCL eine Reihe von Konstrukten die aus den meisten Program miersprachen bekannt sind Es gibt Variablendeklarationen ftir skalare Variablen und Listen von Werten eine select Anweisung und while Schleifen Mithilfe dieser Werk zeuge lassen sich komplexeste Konstrukte erzeugen Innerhalb eines x frames k nnen 2 4 Grundlagen durch Verwendung des lt adapt gt Tags andere x frames eingebunden werden Dies bie tet die M glichkeit der Einkapselung und Wiederverwendung von Komponenten Durch lt adapt gt entsteht bei Verflechtung mehrerer x frames eine baumartige Hierarchie Die Wurzel dieser Hierarchie und damit den Einstiegspunkt des XVCL Prozessors stellt der Specification Frame kurz SPC dar Eine zusammenh ngende Menge von x frames wird als x framework bezeichnet Um Daten in einen adaptierten x frame einzubringen gibt es zwei M glichkeiten Zum einen sind Variablen eines bergeordneten x frames auch im untergeordneten sichtbar zum anderen k nnen mit lt break gt Breakpoints definiert werden an denen dann Text aus dem bergeordneten x frame eingef gt werden kann Dies geschieht ber lt insert gt Ein Beisp
16. f r den konfigurier baren LavA UART abgesteckt und eine Spezifikation erstellt auf deren Grundlage der UART dann in VHDL implementiert werden soll Der zweite Teil der Arbeit behan delt die letztendliche Implementation der entworfenen Komponenten in VHDL und das Einbringen von Konfigurationsm glichkeiten durch den Einsatz von Xpand Des Wei teren wird eine Bibliothek von Ansteuerungsfunktionen entwickelt um den UART an das Betriebssystem zu binden und somit in LavA zu integrieren Im letzten Teil wird die Arbeit mit einer Evaluation der Umsetzung abgeschlossen Zum einen soll der umge setzte UART bez glich seiner Ressourceneffizienz analysiert werden Dazu wird in erster Linie untersucht inwiefern der Umfang der gew hlten Konfigurationsm glichkeiten mit der Ressourcenausnutzung auf dem Ziel FPGA skaliert Zum anderen soll untersucht werden wie gut sich Xpand als Alternative zu XVCL eignet Es wird betrachtet wo Probleme aufgetreten sind und an welchen Stellen klare Vorteile zu XVCL bestehen Inhaltsverzeichnis 1 Einleitung ES Wee e ons A rd W2 Ziele der Arbeit 2 a as A ne Boa nee 1 3 Gliederung der Arbeit e a 2684 San ae God 2 Grundlagen 2 1 Hardwareproduktlinien 28 2208 5 ek u E Moe RE dels IE a E 2 2 Funktionsweise und Anwendung eines UART 2 3 XVCL XML based Variant Configuration Language 2A Das ay A Prolekis ve wi nase a ae RP 2 4 1 Hardwarekonfiguration in Lach 2 4 2 Der LavA UART 2 2 2 a
17. ist Die Dateien ctrlunit xpt rrunit zpt und teunit xcpt sind hnlich aufgebaut und umfassen die Implementation der jeweiligen 45 Implementation 6 2 UART Komponenten Die Struktur jeder dieser Komponenten ist abh ngig von der Kon figuration des UART und ben tigt entsprechend viele Verzweigungen im Kontrollfluss Um ein ausreichendes Ma an bersicht und Lesbarkeit zu behalten ist es daher n tig sie in eigene Dateien zu kapseln Da die Schnittstellendeklarationen port maps der einzel nen Komponenten ebenfalls sehr variabel sind gibt es auch hierf r eigene Templates Da Xpand es m glich macht Templatedefinitionen aus anderen Dateien aufzurufen hat dies zudem den Vorteil dass diese auch innerhalb des Package Templates package xpt wie derverwendet werden k nnen Die brigen internen Komponenten des UART Register Taktteiler FIFO Speicher und Parit tsmodule sind statisch und ihre Implementation ist unabh ngig von der Konfiguration des UART nahezu immer identisch Aus diesem Grund sind die entsprechenden Templates nicht komplex und beinhalten kaum Steuer anweisungen Die Templates dieser brigen Komponenten sind in der Datei misc xpt zu finden 6 2 3 Extensions Bei der Auswertung des Modells zur Anpassung des Quellcodes an die Konfiguration kommt es h ufig vor dass Zugriffe auf Modellparameter und Auswertung von Varia blen sich an verschiedenen Stellen wiederholen Zur Verbesserung der Lesbarkeit und Vermeidung vo
18. php The Eclipse Foundation Eclipse Modeling Framework http www eclipse org modeling emf open ArchitectureWare org Check Language reference http www openarchitectureware org pub documentation 4 3 1 html contents core_ reference html Check_language opencores org Specification for the WISHBONE System on Chip SoC Inter connection Architecture for Portable IP Cores Revision B3 cdn opencores org downloads wbspec_b3 pdf Version September 2002 KANG K COHEN S HESS J NOWAK W PETERSON S Feature oriented Domain Analysis FODA Feasibility Study Pittsburgh PA Carnegie Mellon University Software Engineering Institute 1990 Forschungsbericht SPINCZYK Olaf Software Produktlinien http ess cs tu dortmund de Teaching SS2010 SuS Downloads 03 3 SW Produktlinien pdf Version 2010 The Eclipse Foundation Xpand Documentation Expressions http help eclipse org galileo index jsp topic org eclipse xpand doc help ch01s06 html Version 2011 Object Management Group Object Constraint Language Version 2 3 http www omg org spec 0CL 2 3 Beta2 PDF Version 2010 The Eclipse Foundation Xpand Documentation Xtend http help eclipse org galileo index jsp topic org eclipse xpand doc help ch01s06 html Version 2011 Atmel Corporation ATMEL ATmega32 L complete datasheet http www atmel com dyn resources prod_documents doc2503 pdf Version 2011 NXP Semiconductors LPC2377 78 product da
19. Die Codegenerierung In Kapitel 5 wurde bereits die Struktur des Metamodells des UART erl utert Um nun VHDL Dateien zu erzeugen muss zun chst ein konkretes Modell auf Basis dieses Me tamodells erstellt werden Da nicht alle Zusammenh nge und Einschr nkungen die ein Modell erf llen muss allein durch die Struktur des Metamodells abgedeckt werden k n nen ist es erforderlich die brigen Bedingungen in Form von Check Constraints zu for mulieren 6 2 1 Constraints Wie bereits angedeutet werden viele Grundregeln f r ein konkretes Modell bereits durch die Struktur des Metamodells bestimmt Beispielsweise sorgt die Modellierung der FIFO Speicher als Untereinheit von RX bzw TX Einheit daf r dass keine Modelle mit sinn loser Struktur wie zum Beispiel f r einen UART mit FIFO Speicher aber ohne eine Empf nger oder Sendeeinheit erstellt werden k nnen Auch die Begrenzung auf maxi mal eine RX oder TX Einheit ist bereits durch die Verwendung entsprechender Multi plizit ten im Metamodell fest vorgegeben Es gibt aber auch Einschr nkungen die nicht allein durch das Metamodell ausreichend repr sentiert werden k nnen Insgesamt gibt es im UART Modellierungsprojekt drei Constraints Der erste soll dabei verhindern dass ein UART weder mit einer TX noch einer RX Einheit modelliert werden kann Der entsprechende Constraint ist in Abbildung 6 2 dargestellt context UART ERROR The UART has to contain at least one of the following RXU
20. Kommunikationsphase nie vom UART selbst ausgeht Der UART muss lediglich die eingehenden Wishbone Steuersignale berwachen und bei Beginn eines Kommunikationszyklus abh ngig von der gegebenen Adresse und dem Pegel des WE Signals eine entsprechende Aktion ausf hren Die Aktionen die ber den Bus ablaufen sind dabei e Lesen von empfangenen Daten Auslesen des Interruptsstatus e Schreiben von zu bertragenden Daten e Schreiben und ggfs Lesen der Konfigurationsregister Dementsprechend verwendet der UART die Adresszuordnung die in Tabelle 5 4 darge stellt ist Das erste Zeichen der Adresse hier immer die 8 gibt an dass es sich um einen Wishbone Zugriff handelt Die folgenden zwei Zeichen der Adresse sind Platzhalter f r den Ger tetyp wobei ein UART durch die Bitfolge 01 kodiert wird Das vierte und f nfte Zeichen X muss durch die jeweilige Instanz des UART im MPSoC beginnend bei 1 ersetzt werden Eine vollst ndige Adressierung f r das Baudratenregister der zweiten UART Instanz eines Ger tes w rde dementsprechend 0x80102000 lauten Write Enable 34 5 4 Entwurf des UART Adresse Bedeutung 0x801XX000 Baudratenregister 0x801XX004 RX Daten 0x801XX008 TX Daten 0x801XX00C Formatierungsregister 0x801XX010 Interruptkontrollregister 0x801XX014 Interruptsstatusregister Tabelle 5 4 Mapping der Speicheradressen des UART 5 4 4 Blockdiagramm des UART Abbildung 5 2 zeigt das Blockdiagr
21. PC adaptiert und parametrisiert werden So entsteht ein zusammen h ngendes System aus VHDL Dateien welches dann auf ein FPGA synthetisiert werden kann Eine Visualisierung dieses Ablaufs ist in Abbildung 2 3 zu sehen 2 4 2 Der LavA UART Dieser Abschnitt soll einen kurzen berblick bieten wie der Ausgangszustand der UART Komponente im LavA Projekt ist Die Architektur des UART ist schematisch in Abbil dung 2 4 zu sehen Die drei wesentlichen Komponenten des UART sind die Steuerein Wishbone Clock Reset Signale Interrupt Abbildung 2 4 Der Aufbau der urspr nglichen LavA UART Komponente heit in der Abbildung blau die Empf ngereinheit gelb und die Sendeeinheit gr n Die Zeitgebung der Sende und Empfangseinheiten werden durch zwei Timer gere gelt die Baudrate ist dabei allerdings statisch und nur zur Erzeugungszeit der VHDL Komponente w hlbar Die parallele Dateneingabe und das Auslesen der empfangenen Daten werden ber ein Wishbone Interface 16 durchgef hrt Die interne Speicherung der Daten erfolgt ber zwei Register mit einer Breite von je 9 Bit darunter 8 Daten bits und 1 Statusbit Da es keine Pufferregister zum Senden und Empfangen gibt kann es passieren dass Daten schneller in die Register geschrieben werden als sie verarbei tet werden wodurch es leicht zu Datenverlusten kommt Der UART verf gt ber eine Interrupt Leitung ber die signalisiert wird wenn Daten zur Abholung bereit sind 10 2 0 Gr
22. SyeyspueH MH 3un4913eu1J04 uolreylunwwoy auoJyou s uoljeylunWWOY Abbildung 4 2 Subdiagramm fiir kommunikationsbezogene Merkmale 26 4 3 Analyse Einige der Ger te unterst tzten dar berhinaus auch die automatische Erkennung der Symbolrate anhand eines eingehenden Zeichenstroms Autobaud oder ABR Bez glich der Richtungsabh ngigkeiten ist bei neueren UARTs fast nur noch ein Vollduplexbetrieb also gleichzeitiges Senden und Empfangen von Daten vorgesehen Gerade ltere Ger te konnten aber oft auch nur im Halbduplex Modus betrieben werden Die Formatierungs merkmale eines UART stellen sich wie folgt dar Die Breite des Datenwortes und damit die Framegr e liegen bei allen betrachteten Ger ten zwischen 5 und 9 bit Das neunte Datenbit dient dabei nur zur Abgrenzung von Daten und Adressinformation bei Kon figurationen mit Multiprozessorkommunikation Es gibt weiterhin die M glichkeit ein Parit tsbit zur Validierung der bertragenen Daten mitzusenden welches entweder als gerade oder ungerade Parit t bez glich der Anzahl der Einsen im Datenwort berechnet werden kann Die Anzahl der Stoppbits ist variabel zwischen 1 1 5 und 2 Die Angabe von 1 5 Stoppbits meint dabei dass der Pegel des Signals 1 5 mal so lange gehalten wird wie bei einem Stoppbit Die Kommunikation mit dem UART von Seiten der parallelen Schnittstelle insbe sondere die Abholung empfangener Daten kann entweder im Polling Betrieb also mit wiederholter
23. a er a ra an 2 5 Nerkmalmodeller na e ee e deg eg 3 Verwendete Technologien 3 1 Entwicklung von Templates mit Xpand 3 1 1 Die Expressions Subsprache 2 2 2 2 nn nn nn 3 1 2 Struktur von Xpand Dateien aa ana an a eats a Base ob te 3 1 3 Erweiterungen durch Xtend 20 kaya cias rien er 3 1 4 Formulierung von Modellconstraints mit Check 3 1 5 Workflowdateien als Verkn pfung der Sprachen 3 2 Konfigurationsmittel in VHDL 222 22 dee oe Pa eke PES 4 Analyse 4 1 UARTs g ngiger Mikrocontroller 22 2 Corn 4 1 1 Atmel ATmega8 16 32 Wace ds Uw ante Oe ae nun And De NR DR EN en a ee he ar AS ACEON ePIC EE aa Ore Ries 407 AP Gore EE EENEG 4 2 1 ARTIO duos is sd rt dp re de 422 UVARTE Lee 4 3 Zusammenfassung und Merkmalmodell e 5 Entwurf des UART 5 1 Funktionsumfang des UYARI Bee EA 5 1 1 Formatierung und Kommunikation 13 13 13 14 15 15 16 18 19 19 19 20 21 22 22 23 24 29 29 30 Inhaltsverzeichnis SL o wen dar Rte ate Ae ae See ee A E b 30 e A A E 30 5 2 Umsetzung der Konfigurationspunkte sr as een SESS 31 5 3 Eclipse Metamodell 31 5 4 Entwurf einzelner Komponenten 32 5 4 1 RX und TX Einheit 22 Sans Du sh Dre ua 33 5 4 2 Steuereinheit o res Ee e ah are ra 33 5 4 3 Anbindung an den Wishbone Bus 34 5 4 4 Blockdiagramm des WAR Tu e Bar re 35 Implementation 37 6 1 Implementation einzelner K
24. am eine vollst ndige Codeabdeckung liefern Die Laufzeitkonfiguration der UART Funktionen kann dann auf diesen repr sen tativen Testsystemen verifiziert werden Um das Auffinden von Fehlern zu vereinfachen wurden die einzelnen Komponenten mithilfe entsprechender Testbenches im Simulator verifiziert sodass der Abschlusstest letztendlich nur noch darauf abzielt Fehler bei der Interaktion der Einzelmodule zu finden Nach au en abgeschlossene VHDL Entities mit internen Stimuli 51 Evaluation 7 1 7 1 1 Auswahl der Testsysteme Da ein UART als Einzelkomponente nicht in einer Realumgebung testbar ist muss zu n chst ein MPSoC erstellt werden in das der UART eingebettet werden kann F r diese Testserie wurde ein funktionierendes MPSoC aus einem anderen Projekt ausgew hlt in dem der urspr ngliche rudiment re LavA UART verwendet wurde Das MPSoC besteht aus vier Untersystemen von denen das erste ber den UART verf gt Zum Test wur den auf der Grundlage dieses Systems acht Varianten von UARTS generiert und in die Systemstruktur eingebunden Diese Varianten unterscheiden sich wie in Abbildung 7 1 dargestellt durch die Merkmale FIFO Puffer Interrupts und Parit ten Abbildung 7 1 Unterscheidung der Testsysteme Eine weitere Zusammenlegung der Testf lle ist aufgrund der jeweils unterschiedlichen Kompositionsstruktur in diesem Fall nicht mehr ohne Einbu en in der Codeabdeckung m glich 7 1 2 Ablauf des Laufzeittests
25. amm des UART gem des Entwurfs der einzelnen Komponenten Optionale Teile der Architektur sind dabei mit Ausnahme der komplet ten RX und TX Einheiten in gr n dargestellt Die Auslassung zwischen den einzelnen FIFO Slots spiegelt die variable Gr e wieder Aus Gr nden der bersichtlichkeit sind besonders einzelne Leitungen wie zum Beispiel die Steuereing nge der Multiplexer nicht mit eingezeichnet 39 Entwurf des UART 5 4 Wishbone Interface RxD TxD Abbildung 5 2 Blockdiagramm des UART 36 6 Implementation Ausgehend von den Uberlegungen und Modellierungen aus dem vorigen Kapitel be schreibt dieses Kapitel die Entwicklung des UART und der zur Codeerzeugung ben tigten Dateien Zu diesem Zweck wird zun chst die Umsetzung der komplexeren Teile der Implementation in VHDL betrachtet Im folgenden wird erl utert wie die entspre chenden Code Artefakte durch Einsatz der Eclipse Modeling Tools erzeugt werden Zum Abschluss des Kapitels wird schlie lich die Treibersoftware zur Ansteuerung des UART dargestellt 6 1 Implementation einzelner Komponenten in VHDL Die Konzeption einer Hardwareproduktlinie erfordert die Entwicklung modularer Kom ponenten aus denen sich ein anwendungsspezifisches Produkt ma schneidern l sst Um ein gutes Bild zu vermitteln wie dies im Falle der UART Familie geschehen ist soll an dieser Stelle die Implementation der wesentlichen Entit ten vorgestellt werden Zur Ver
26. analog zum globalen Interrupt Handler die Priorit t der einzelnen Interrupts bestimmt indem ein Interrupt auf den fr her ge pr ft wird alle unter ihm verdeckt Je nach aufgetretenem Interrupt wird dann eine der folgenden Funktionen aufgerufen e uart_handle_rx_ready e uart_handle_tx_ready e uart_handle_rx_of e uart_handle_tx_of e uart_handle_par_err e uart_handle_frm_err W hrend f r die Funktion uart_handle_rx_ready das Auslesen der empfangenen Daten naheliegt h ngen die Aktionen der anderen Handler im wesentlichen vom konkreten An wendungsfall und vom Benutzer ab Dementsprechend ist diese Funktion im Gegensatz zu den brigen bereits vorimplementiert F r die Funktionen uart_handle_par_err und 48 6 3 Implementation uart_handle_frm_err ist weiterhin wichtig dass das von einem Fehler betroffene Zei chen ausgelesen wird da diese Interrupt Signale im UART nur durch einen Lesezugriff unterbunden werden 49 Evaluation Dieses Kapitel umfasst die Evaluation des entwickelten UART und der Codeerzeugung mithilfe des Xpand Frameworks Im ersten Teil des Kapitels wird zun chst thematisiert wie der Test der entwickelten Komponenten angesichts der vielen verschiedenen Kon figurationen umgesetzt wurde Im zweiten Teil wird anschlie end eine Auswertung der Ressourcenausnutzung des UARTs in Abh ngigkeit von verschiedenen Konfigurationen vorgenommen Da im Verlauf dieser Arbeit zum ersten Mal ausschlie lich Xpand zur
27. aten an die richtigen Register weiterleiten Zur Interrupterzeugung bekommt sie au erdem diverse Statussignale von den RX und TX Einheiten Diese sind f r die RX Einheit Frameformatsfehler Korrektheit der Parit t des zuletzt empfangenen Zeichens FIFO Auslastung und FIFO berlauf und f r die TX Einheit FIFO berlauf und Leere des FIFO Puffers Ausgehend von diesen Signalen bestimmt die Steuereinheit in Verbindung mit dem aktuellen Zustand des Interrupt Konfigurationsregisters ob ein Interrupt ausgel st werden muss Die aktuelle Formatkonfiguration die f r die Kommu nikation in beide Richtungen entscheidend ist wird ber einen 15 Bit breiten Vektor an die Receiver und Transmittereinheiten ausgegeben Die dynamische Erzeugung der Bau drate funktioniert schlie lich ber zwei in Serie geschaltete Baudratengeneratoren Der erste der beiden bekommt den im Baudratenregister eingestellten Teilungsfaktor berge ben und erzeugt daraus die Baudrate f r die RX Einheit Da die RX Einheit ein 4 fach Sampling betreibt muss sie vier mal so schnell getaktet werden wie die TX Einheit Um nun die langsamere Taktrate f r die TX Einheit zu erzeugen wird dem zweiten Baudratengenerator die Taktrate f r die RX Einheit als enable s u eingespeist und eine konstante 4 als Teilungsfaktor angelegt 41 Implementation 6 2 6 1 6 Baudratengenerator Die Komponente zur Baudratenerzeugung ist im Grunde ein Z hler der Taktflanken z hlt und nach
28. b es sinnvoll 99 Fazit und Ausblick 8 2 ist den aktuellen LavA Workflow dahingehend zu modifizieren dass XVCL vollst ndig durch Komponenten des Xpand Frameworks ersetzt werden kann Nach Abw gung der Vor und Nachteile beider Sprachen zeigte sich dass die Abl sung von XVCL durch Xpand durchaus sinnvoll ist Dies begr ndet sich in erster Linie darin dass Xpand Vorteile bez glich bersichtlichkeit und Ausdrucksst rke besitzt und die Nutzung von XVCL wegen der zus tzlichen Transformation des grafischen Modells in ein textuel les einen Mehraufwand darstellt der nicht durch zus tzliche F higkeiten seitens XVCL gerechtfertigt wird 8 2 Ausblick Ausgehend vom Umfang der Implementation zum Ende dieser Arbeit gibt es noch ei nige denkbare Erweiterungen Eine m gliche Erweiterung f r den Funktionsumfang des UART w re dabei zun chst die Implementation eines synchronen Kommunikationsmo dus als Alternative zur asynchronen Kommunikation ber den modernere UART gr tenteils verf gen Bez glich des Generierungsprojekts w re es f r den Benutzer kom fortabel direkt passende Software zur Ansteuerung des UART zu generieren anstatt eine Bibliothek von Funktionen anzubieten Viele Funktionen insbesondere zum Le sen und Schreiben von Daten beinhalten viele Fallunterscheidungen um die verschie denen UART Varianten ber eine gleichf rmige Schnittstelle ansprechen zu k nnen W rde man ber Templates individuelle Funktione
29. beispielsweise RS 232 zu bersetzen und umgekehrt Die Bezeichnung universal soll dabei andeuten dass die eigentlichen Kommunikationspara meter wie Baudrate und Signalpegel der Ein und Ausgabe nicht festgelegt sondern konfigurierbar sind Da jeder der Kommunikationspartner im Normalfall seine eigene Taktgebung hat wird bei der seriellen Kommunikation ein Rahmen von Start und Stoppbits genutzt um Datenw rter zu kodieren H ufige Varianten des UARTs sind der sogenannte Dual UART oder DUART der zwei UARTs in einem Bauteil vereint oder auch sogenannte USARTs die neben dem klassischen asynchronen Kommunikations prinzip zus tzlich synchrone Kommunikation anbieten Im Fall der synchronen Kom munikation werden die Daten nicht in einem festen Rahmen mit Start und Stoppbits eingebettet sondern ber ein mitgeliefertes Taktsignal synchronisiert Anders als bei der asynchronen Kommunikation bei der zwischen Stoppbit eines ersten und Startbit eines n chsten Datenwortes theoretisch eine beliebig lange Pause liegen kann folgen die Datenw rter bei der synchronen Kommunikation in einem stetigen Strom aufeinander UARTS finden sich heutzutage in fast allen Mikrocontrollern Ein weit verbreitetes und de facto Standardmodell ist der 16550 UART der National Semiconductor Corporation 11 2 3 XVCL XML based Variant Configuration Language Bei XVCL 8 handelt es sich um eine XML basierte Markup Sprache die sich beson ders an Entwickler richtet
30. bermitteltes Zeichen berschrieben wird wartet die Funktion mittels einer while Schleife mit dem Registerzugriff bis der Status der TX Einheit des UART auf bereit steht Da einzelne Zeichen aber in der allermeisten F llen nicht ausreichen gibt es zus tzlich die Funktion uart_puts die mehrere Zeichen in Form eines Character Arrays bergeben bekommt und diese nacheinander mithilfe von uart_putc bertr gt 6 3 2 Auslesen empfangener Daten Die Funktionen zum Auslesen von Daten sind nach dem gleichen Prinzip aufgebaut wie die Funktionen zum Senden Die Funktion uart_getc liest ein einzelnes Zeichen aus dem Empfangsregister uart_gets liest eine bestimmte Anzahl von Zeichen wobei die Anzahl als Parameter bergeben wird Beim Auslesen von empfangenen Daten sind zwei F lle zu unterscheiden Werden Interrupts verwendet so ist bekannt dass der Treiber zum Zeitpunkt des Auftretens eines entsprechenden RXREADY Interrupts mindestens soviele Zeichen abholen kann wie der eingestellte Trigger Level angibt dabei allerdings mindestens eines Es kann also vom entsprechenden Interrupt Handler uart_gets mit dem bekannten Trigger Level als Parameter aufgerufen werden Gibt es keine Interrupts so muss der UART per Polling regelm ig auf neue Daten berpr ft werden Hierzu gibt 47 Implementation 6 3 es die Funktion uart_poll welche in Regelm igen Abst nden aufgerufen werden kann um die aktuell verf gbare Anzahl Daten abzuholen Wenn k
31. besserung der Verst ndlichkeit der Interaktion der einzelnen Komponenten wird da bei im Zweifelsfall davon ausgegangen dass ein UART mit allen m glichen optionalen Komponenten vorliegt anstatt immer eine Fallunterscheidung zu machen 6 1 1 Die Top Level Entit t Die Top Level Entit t stellt den eigentlichen UART dar und bietet nach au en die par allele und serielle Schnittstelle an Da der UART auf der parallelen Seite das Wishbone Protokoll implementiert verf gt die UART Entit t ber die hierf r erforderlichen Ein und Ausgabesignale Dazu geh ren Adress und Datenleitungen und die Steuersigna le WE write enable STB und CYC auf der Eingabeseite sowie Datenleitungen und ACK Signal auf der Ausgabeseite vgl 16 Bez glich der seriellen Kommunikation gibt es zwei Leitungen zum Senden und Empfangen sowie zwei Leitungen f r Hardware flusskontrolle RTS CTS Strukturell beinhaltet die Entit t drei Hauptkomponenten Steuereinheit RX Einheit und TX Einheit Funktional hat sie neben der Verkn pfung der Untereinheiten die Aufgabe eine bersetzung des Wishbone Protokolls auf interne Steuersignale durchzuf hren und umgekehrt die dann an die Untereinheiten weiterge geben werden k nnen Wie in Kapitel 5 dargestellt gibt es maximal sechs einzeln adres sierbare Register im UART Das sind zun chst die RX und TX Datenregister sowie die drei Konfigurationsregister f r Baudrate Kommunikationsformat Interrupts und das Interruptstatu
32. chen Funktions umfang beinhaltet 7 2 1 Minimalkonfiguration Die kleinste modellierte UART Variante lieferte nach Synthese und Implementation fol gende Ressourcenbelegung Modul Slices Slice Reg LUTs Top Level 6 0 6 Steuereinheit 40 113 91 TX Einheit 18 24 24 Gesamt 64 137 121 Tabelle 7 1 Ressourcenbedarf der minimalen UART Variante 93 Evaluation 1 2 7 2 2 Teilmenge der m glichen Komponenten Die zweite UART Variante bestand aus RX und TX Einheit mit je 16 Slot FIFO Speichern und der M glichkeit Interrupts zu verwenden Die Ergebnisse der Synthese sind in folgender Tabelle zusammengefasst Modul Slices Slice Reg LUTs Top Level 10 0 10 Steuereinheit 51 123 99 RX Top 31 26 34 RX FIFO 74 168 83 TX Top 18 25 24 TX FIFO 73 168 82 Gesamt 257 510 332 Tabelle 7 2 Ressourcenbedarf der mittelgro en UART Variante 7 2 3 Kompletter Funktionsumfang Die letzte betrachtete UART Variante verf gte ber den gr tm glichen Funktionsum fang und jeweils 64 FIFO Slots f r beide Einheiten Die Untersuchung lieferte folgende Ergebnisse Modul Slices Slice Reg LUTs Top Level 10 0 10 Steuereinheit 55 125 102 RX Top 35 28 39 RX FIFO 232 606 290 Parity Checker 3 1 3 TX Top 22 25 36 TX FIFO 236 606 290 Parity Gen 1 1 2 Gesamt 594 1392 772 Tabelle 7 3 Ressourcenbedarf der kompletten UART Variante 54 7 3 Evaluation 7 2 4 Auswertung der Ergebnisse Setzt man
33. dass die internen Daten bei einem 1 Pegel auf der load Leitung mit der aktuellen Eingabe ber schrieben werden Bei einem 1 Pegel auf der reset Leitung werden die internen Daten auf 0 zur ckgesetzt Der aktuelle interne Zustand wird permanent ber die Datenausg nge ausgegeben 6 1 8 Parit tspr fung und generierung Die Parit tspr fung und generierung funktioniert grunds tzlich nach dem blichen Prinzip der Parit tsberechnung n mlich einer XOR Verkn pfung aller Datenbits Da es in diesem Fall m glich ist zwischen gerader und ungerader Parit t odd even parity zu w hlen wird das Resultat der Berechnung wiederum per XOR mit dem Konfigura tionsbit verkn pft Da die Formel ohne Modifikation dem Prinzip der geraden Parit t folgt und das Konfigurationsbit gem des Entwurfs bei der Einstellung even parity logisch 0 ist bleibt das Resultat unver ndert Im Falle der ungeraden Parit t wird das Resultat noch einmal invertiert Weil die Pr fung eines Datenwortes nur dann Sinn er gibt wenn das Wort komplett im Speicher vorliegt besitzt die Parit tspr fungs Entit t eine enable Leitung deren Pegel logisch 0 ist solange keine pr fbaren Daten vorhanden sind Dies ist wichtig da sonst f lschlicherweise ein Interrupt ausgel st werden w rde Bei der Generierung eines Parit tsbits sind keine weiteren Vorkehrungen n tig da hier offensichtlich immer ein komplettes Datenwort vorliegt 42 6 2 Implementation 6 2
34. dass dieses Feature nicht benutzt werden sollte um Fehler im Modell abzufangen da f r solche F lle der Sprachumfang von Check besser geeignet ist und die Trennung von Modellvalidierung und Codegenerierung sonst nicht gegeben w re Zuletzt gibt es noch die M glichkeit innerhalb eines PROTECT Blocks ein Code oder Textsegment anzugeben dass bei wiederholten Generatordurchl ufen nicht mehr berschrieben bzw ver ndert werden kann Dies kann n tzlich sein um die ver 14 3 1 Verwendete Technologien sehentliche Ver nderung von handgeschriebenen Codesegmenten zu vermeiden 3 1 3 Erweiterungen durch Xtend Wie bereits angedeutet k nnen Xpand Templates neben den Standardfunktionen der Sprache auch weitere selbst definierte Operationen sogenannte Extensions beinhalten Solche selbst definierten Subroutinen werden mit Hilfe der Sprache Xtend in Extension Dateien mit der Endung ext definiert Grunds tzlich gibt es zwei M glichkeiten eine Extension zu formulieren Einerseits bietet das Framework die M glichkeit statische Java Methoden die im Modell definiert sein m ssen zu verwenden Diese Variante ist lediglich eine Abbildung von Funktionen auf der Modellierungsebene auf die Ebene des Codegenerators Andererseits ist es m glich mit Hilfe von Expressions eigene Funktionen zu erstellen und so ein hohes Ma an Dynamik in den Generierungsprozess einzubringen Eine Extension besteht aus einem R ckgabetypen einem Bezeichner ein
35. e org openArchitectureWare User Guide Xpand re ference http www openarchitectureware org pub documentation 4 3 1 html contents core_reference html xpand_reference_introduction JARZABEK Stan BASSETT Paul ZHANG Hongyu ZHANG Weishan XVCL XML based variant configuration language In Proceedings of the 25th International Conference on Software Engineering Washington DC USA IEEE Computer Society 2003 ICSE 03 ISBN 0 7695 1877 X 810 811 9 BOcKLE G KNAUBER P K POHL SCHMID K Hrsg Software Produktlimen Methoden Einf hrung und Praxis First dpunkt Verlag 2004 10 CZARNECKI Krzysztof EISENECKER Ulrich W Generative Programming Me thods Tools and Applications Addison Wesley 2000 11 National Semiconductor Corporation PC16550D Universal Asynchronous Recei ver Transmitter with FIFOs http www national com ds PC PC16550D pdf Version 1995 61 Literaturverzeichnis 8 2 12 MEIER M ENGEL M STEINKAMP M SPINCZYK O LavA An Open 13 14 15 16 17 uo 18 Zu 19 LS L E 21 22 23 24 25 Platform for Rapid Prototyping of MPSoCs In Field Programmable Logic and Applications FPL 2010 International Conference on 2010 ISSN 1946 1488 S 452 457 National University of Singapore XML based Variant Configuration Language Pro ject Site http xvcl comp nus edu sg overview_brochure
36. egenerierung Als Einstiegspunkt f r den Codegenerator wird daher zun chst ein Haupttemplate ben tigt das zuerst durchlaufen werden kann und die ben tigten Subtemplates aufruft oder einbindet Um dies zu bewerkstelligen werden im Haupttemplate der Lesbarkeit halber zun chst die konkreten Konfigurationswerte des Modells ausgelesen und lokalen Varia blen zugewiesen Die Subtemplates verf gen ber entsprechende Parameterlisten die dann beim Aufruf leicht mit diesen Variablen gef llt werden k nnen Im Haupttemplate werden zuerst Subtemplates f r Dateien aufgerufen die in jedem UART ungeachtet sei ner Konfiguration aber mit jeweils unterschiedlicher interner Struktur vorhanden sein m ssen Dazu z hlt zun chst das VHDL Package das die Deklarationen aller internen Entit ten des UART zur Instanziierung bereitstellt Weiterhin ben tigt jeder UART die 44 6 2 Implementation Top Level Entit t eine Kontrolleinheit einen Taktteiler zur Erzeugung der Baudrate so wie eine Version der generischen Konfigurationsregister Je nach Modellierung kommen infolgedessen dann die optionalen Komponenten RX Einheit TX Einheit Parit tsgene rator und pr fer sowie Interruptregister und logik hinzu 6 2 2 2 Hierarchie der Templatedateien Wie in Kapitel 3 bereits erl utert gibt es in Xpand keine eins zu eins Beziehung zwi schen Template und Ausgabedateien Durch die M glichkeit der Definition mehrerer Templates pro Datei werden die
37. eht aus folgenden drei Teilen der Angabe des Modellelementes auf das er sich bezieht einer Fehlermeldung oder Warnung die im Falle des Nichteinhal tens ausgegeben wird sowie der eigentlichen Bedingung Zur Deklaration k nnen wie Fully Qualified Domain Name 15 Verwendete Technologien 3 2 schon in Xpand und Xtend Elemente der Expressions Subsprache verwendet werden wodurch die Syntax der aus der Java Modellierung bekannten Constraintsprache OCL sehr hnlich ist Ein einfaches Beispiel k nnte so aussehen In diesem Fall wird ein Cons context ModelElement ERROR Name of element name ist too short name Length gt 1 Abbildung 3 3 Beispiel fiir einen einfachen Constraint traint f r Elemente des Typs ModelElement deklariert Die Einschr nkung ist dass das Attribut name des Elements eine Lange von mindestens zwei Zeichen haben muss Wird die Bedingung nicht erf llt so wird die Bearbeitung abgebrochen und die entsprechen de Fehlermeldung ausgegeben Neben ERROR gibt es noch das Schliisselwort WARNING welches ebenfalls eine Fehlermeldung ausgibt die Bearbeitung aber nicht unterbricht 3 1 5 Workflowdateien als Verknupfung der Sprachen Fur sich allein betrachtet sind Xpand Xtend und Check lediglich drei deklarative Spra chen Um nun das eigentliche Ziel n mlich die Erzeugung von Quellcode zu erreichen ist eine Laufzeitumgebung notwendig die das erstellte Ger st aus Templates Extensions und Constraint
38. eine Zeichen verf gbar sind gibt die Funktion einen Nullzeiger zur ck 6 3 3 Konfiguration Die Konfiguration des UART wird je nach Funktionsumfang ber bis zu drei Register geregelt Da jeder dieser Register Baudrate Format und Interrupts eine semantisch zusammengeh rige Menge an Optionen beinhaltet existieren drei entsprechende Funk tionen zum Schreiben eines Satzes von Einstellungen Namentlich sind das die Funktio nen uart_set_br uart_set_fmt und uart_set_int Die erste Funktion uart_set_br erwartet die Taktfrequenz in Hz und die gew nschte Baudrate als Parameter Sie be rechnet intern den ben tigten Teilungsfaktor und schreibt ihn in das Baudratenregister Da die anderen beiden Register im Gegensatz zum Baudratenregister mehr als nur einen logischen Wert beinhalten gibt es zwei Datenstrukturen in die die Optionen bersicht lich eingetragen werden k nnen Die mit Werten belegten Datenstrukturen werden dann den Funktionen bergeben welche die Eingabe in einen Bitvektor umwandeln und in die richtigen Register schreiben 6 3 4 Interruptbehandlung Das Interruptsystem basiert auf dem globalen UART Interrupt Handler uart_handle_irg der beim Auftreten eines UART Interrupts vom globalen Interrupt Handler aufgeru fen wird Innerhalb von uart_handle_irq wird zun chst der Interruptstatusvektor des UART gelesen und dann sequenziell auf einen Interrupt nach dem anderen gepr ft Durch die Reihenfolge der berpr fung wird hier
39. einer gegebenen Anzahl n einen Peak an der Ausgabeleitung erzeugt wodurch effektiv die Eingabetaktrate durch den gegebenen Faktor n geteilt wird Um dies zu tun hat der Baudratengenerator einen Eingabetakt eine reset Leitung einen Bitvektor zur Eingabe des Teilungsfaktors und einen enable Eingang Da die Baudrate des UART prinzipiell zu jedem beliebigen Zeitpunkt ge ndert werden kann wird der Teilungsfaktor intern in einer Variable hinterlegt die in jedem Takt aktualisiert wird Eine interne Z hlvariable z hlt dann von dieser Grenze bis 0 herunter solange der Pegel der enable Leitung logisch 1 ist Erreicht die Z hlvariable die 0 so wird ein Peak auf der Ausgabeleitung erzeugt Damit dieser Aufbau eine korrekte Baudrate erzeugt muss f r die RX Baudrate der enable Eingang konstant auf 1 bleiben Im Fall der TX Baudrate kann die Ausgabe des ersten Generators einfach als enable Signal verwendet werden 6 1 7 Konfigurationsregister Die verschiedenen Konfigurationsregister des UART basieren alle auf dergleichen gene rischen Entit t Da die Breite der Register zur Laufzeit konstant bleibt kann sie einfach als generic Parameter festgelegt werden Die Implementation des generischen Registers ist kanonisch und strukturell simpel gehalten Das Register verf gt ber eingehende und ausgehende Datenleitungen sowie die Steuersignale load und reset Intern wird ein Bit vektor verwaltet der die Daten speichert Der Prozess der Entit t sorgt daf r
40. en Templates bieziehen sollen importiert werden Dazu wird in Xpand das IMPORT Statement verwendet Neben Modellen k nnen auch Xtend Dateien in Templatedateien eingebunden werden was ber das Schl ssel wort EXTENSION geschieht Auf diese Weise k nnen Bibliotheken von selbst definierten Operationen f r die Verwendung innerhalb der jeweiligen Templatedatei sichtbar ge macht werden Die dritte Art von Statement die das eigentliche Kernst ck einer Tem platedatei ausmacht bilden sogenannte Templatedefinitionen Eine Templatedefinition wird durch das Schl sselwort DEFINE eingeleitet und besteht aus einem im jeweiligen Namensraum eindeutigen Bezeichner und einer optionalen Parameterliste sowie dem Namen des Modellelementes auf das sich das Template beziehen soll Templatedefini tionen beinhalten einfache Textelemente und eine beliebige Anzahl von Anweisungen aus dem Sprachumfang von Xpand Jeder Definitionsblock im folgenden als Template bezeichnet kann eine eigene Ausgabedatei spezifizieren Dies geschieht ber das FILE Statement Jedes Template kann weiterhin ber das EXPAND Statement andere Templa tes einbinden und somit deren Ausgabe an der jeweiligen Stelle im Template einf gen Das Expandieren von Templates bietet eine M glichkeit zur Verkapselung und Wieder verwendung von Templates in unterschiedlichen Kontexten Es ist vergleichbar mit dem lt adapt gt Tag in XVCL siehe Abschnitt 2 3 Neben diesen templatespezifischen Befeh le
41. en effektiven Datendurchsatz halbiert aber im Gegenzug keine nennenswerten Ressourcenvorteile bringt 5 1 1 Formatierung und Kommunikation Im Bereich der Formatierung der seriellen Aus und Eingabe sollen fast alle in der Dom nenanalyse aufgetretenen M glichkeiten implementiert werden Die Breite des Datenwor tes soll zwischen f nf und neun Bit variabel sein Hinzu kommen eine Stoppbit Anzahl von ein oder zwei Bit und die M glichkeit ein Parit tsbit entweder mit gerader oder ungerader Parit t zu verwenden 5 1 2 Interrupts In seinem bisherigen Zustand bietet der LavA UART eine Interrupt Leitung in Verbin dung mit zwei Zustandsbits innerhalb der Datenregister der Transmitter und Emp f ngereinheiten ber diese Architektur werden zwei verschiedene Interrupts realisiert die die Ereignisse Senden abgeschlossen und Datenwort empfangen widerspiegeln Durch die Erweiterung um Pufferspeicher und Ma nahmen der Fehlererkennung ist diese Modellierung nicht mehr ausreichend Neben den bereits vorhandenen Interrupts sollen vier neue Fehlerzust nde n mlich Parit tsfehler im aktuellen Datenwort ein Fehler im Format des Datenwortes beispielsweise ein falsches Startbit und berlauf des Empf nger bzw Sendepuffers hinzugef gt werden Zwar wird weiterhin eine einzelne Interrupt Leitung genutzt diese wird aber mit einem dedizierten Statusregister verbun den dass mit einem Bit pro Interrupt die aufgetretenen Unterbrech
42. en eingestellten Trigger Level andernfalls wird der Interrupt nach jedem Empfangszyklus erzeugt 6 1 3 TX Einheit Im Gegensatz zur RX Einheit besitzt die TX Einheit ein paralleles Dateneingabesi gnal und eine serielle Datenausgabeleitung Bez glich der restlichen Schnittstelle hneln sich beide Komponenten allerdings Die TX Einheit liefert ebenfalls Informationen ber FIFO F llstand und berlauf und zus tzlich ein Statussignal busy das angibt ob die Einheit sich aktuell in einem Sendevorgang befindet bzw nicht verlustfrei neue Daten entgegennehmen kann Als Eingabe bekommt die TX Einheit die gleichen Konfigurati onsparameter bergeben wie die RX Einheit Ihre Untereinheiten sind ein Schiebere gister zum Senden der Daten Pufferspeicher und ein Parit tsbitgenerator als Gegen st ck zum Parit tspr fer auf Empf ngerseite Da die TX Einheit das Gegenst ck zur RX Einheit bildet f hrt sie funktional in etwa dieselben T tigkeiten in umgekehrter Reihenfolge aus 39 Implementation 6 1 6 1 3 1 Ablauf des Sendevorgangs Wie schon bei der RX Einheit beschrieben verf gt auch die TX Einheit ber einen einzigen Prozess der ber eine Variable in der die Bitposition im aktuell zu bertra genden Zeichen verwaltet wird eine Zustandsmaschine simuliert Zuerst werden dabei wieder die Konfigurationsparameter in Variablen geschrieben und anschlie end die der jeweiligen Bitposition entsprechenden Aktionen ausgef hrt Die Bitp
43. en von Zeichen mit falschem Parit tsmodus also einem umgekehrten Parit tsbit ausgel st werden Auf hnliche Weise konnten auch Fehler im Frameformat ber das Senden von Zeichen mit Parit tsbit ohne Einstellung einer Parit t am UART provoziert werden Das Eintreten der Interrupts f r Puffer berl ufe der TX und RX Einheiten wurde schlie lich durch ununterbrochenes Senden von Daten an den UART bzw durch das Nichtabholen empfangener Zeichen verifiziert 7 2 Evaluation des UART Zur Beurteilung des entwickelten UARTs sollen an dieser Stelle der Ressourcenbedarf des Moduls herangezogen werden Da es eines der Ziele war durch die Option des Auslassens einzelner Komponenten Ressourcen zu sparen und somit die Ressourcen belegung des UART auf dem FPGA mit seinem Funktionsumfang skalieren zu lassen wird zun chst eine entsprechende Analyse basierend auf der Implementation f r ein Xi linx Virtex 5 FPGA pr sentiert Zur Beurteilung der Skalierung und Betrachtung der allgemeinen Ressourcenauslastung des UART wurden drei verschiedene Varianten mit unterschiedlichen Funktionsumf ngen generiert Eine minimalistische Variante die nur aus einer Sendeeinheit ohne FIFO Puffer und den brigen verpflichtenden Komponenten zur Konfiguration besteht Weiterhin eine Variante mit einer Teilmenge der m glichen Komponenten bestehend aus RX und TX Einheiten mit Interruptunterst tzung und kleinem Pufferspeicher letztlich eine Variante die den maximal m gli
44. er m glicher weise leeren Parameterliste und der Deklaration der auszuf hrenden Operationen Ex tensions k nnen insbesondere auch rekursiv sein Dies kann zum Beispiel dann n tzlich sein wenn f r ein Objekt der vollst ndig qualifizierte Name bestimmt werden soll Eine Extension die dies leistet ist in Abbildung 3 2 dargestellt String fullyQualifiedName NamedElement n n parent null n name fullyQualifiedName n parent n name Abbildung 3 2 Extension zur Bestimmung des FQDN 21 Solang das als Parameter bergebene Objekt ein Elternobjekt hat wird hier die Ex tension mit dem Elternobjekt erneut aufgerufen und der Name des aktuellen Objektes an das Resultat des Aufrufs angeh ngt Xtend bietet weiterhin auch Mittel zur Mo delltransformation M2M und zur aspektorientierten Programmierung im Kontext der Wiederverwendung von propriet ren Generatorkomponenten Da diese Teile des Spra chumfangs im weiteren Verlauf dieser Arbeit jedoch keine Anwendung finden wird an dieser Stelle nicht im Detail darauf eingegangen 3 1 4 Formulierung von Modellconstraints mit Check Die Sprache Check bietet die M glichkeit neben den impliziten Vorgaben des Meta modells explizite Einschr nkungen zu formulieren die ein Modell einhalten muss um korrekt zu sein 15 Solche Constraints werden in eigenen Dateien mit der Endung chk deklariert und k nnen bei der Codegenerierung zur Modellvalidierung verwendet wer den Ein Constraint best
45. er der ge nannten Beschreibungssprachen textuell beschrieben und dann auf einer generischen Hardwareplattform ausgef hrt Diese Technik bringt zum einen den Vorteil mit sich auf derselben physikalischen Hardware verschiedenste Hardwarel sungen realisieren zu k n nen und so Kosten zu minimieren Zum anderen wird es m glich lang bekannte Methoden und Techniken aus der Softwareentwicklung f r den Hardwareentwurf zu erschlie en da sich durch den Einsatz von rekonfigurierbaren Logikbausteinen und Hardwarebeschrei bungssprachen die Entwurfsmodelle immer mehr ann hern 1 1 Motivation Das LavA Projekt der TU Dortmund 2 das den Kontext dieser Bachelorarbeit bie tet verfolgt einen solchen Ansatz Es verwendet das Konzept der modellgetriebenen Softwareentwicklung MDSD 3 um ausgehend von einem abstrakten Modell ma ge schneiderte Hardware zu entwickeln Die LavA Plattform bietet bereits das feingranular konfigurierbare Betriebssystem CiAO 4 sowie eine Vielzahl von konfigurierbaren Hard warekomponenten geschrieben in VHDL Dazu z hlen verschiedene Prozessoren und IPC Komponenten aber auch Peripheriekomponenten wie UARTs Ein UART ist ein Bauelement das die Schnittstelle zwischen einem parallelen Datenbus und einer seriellen Leitung erm glicht sodass ein Mikrocontroller mit einem anderen Rechner oder Modem Interprozesskommunikation Einleitung 1 3 ber Standards wie RS 232 kommunizieren kann 5 Um hohe Flexibilit
46. er zweite Constraint des Modellierungsprojekts Generierung von funktionsunf higem fehlerhaften VHDL Code sorgen w rde Der letzte und nicht so offensichtliche Constraint des Projekts besagt dass im Falle des Vorhan denseins von Parit ts berpr fung und RX Einheit auf jeden Fall auch Interrupts mit eingeschlossen werden sollten Ist diese Kombination gew hlt k nnen die Parit tsbits der empfangenen Daten zwar gepr ft werden aber ein Fehler k nnte nie ausgegeben werden da dies nur ber Interrupts m glich ist In diesem Fall w re die Benutzung der Parit tspr fung eine reine Ressourcenverschwendung Da es sich dabei aber nur um einen Effizienzeinwand handelt und der generierte Code dennoch funktionsf hig w re wird im Falle eines Versto es nur eine Warnung ausgegeben Der entsprechende Constraint findet sich in Abbildung 6 4 context UART if this uartTX null amp amp this parity null WARNING Parity operation with RX should include Interrupt Support this interrupt null Abbildung 6 4 Der dritte Constraint des Modellierungsprojekts 6 2 2 Struktur der Templates Ist ein konkretes Modell fertiggestellt gilt es die Werte dieses Modells auszulesen und entsprechend der Konfiguration VHDL Dateien zu erzeugen Zu diesem Zweck gibt es eine Reihe von Xpand Templatedateien die vorgefertigte Codesegmente beinhalten wel che dann nach der gew nschten Konfiguration zusammengestellt werden 6 2 2 1 Einstiegspunkt der Cod
47. gendem Funktionsumfang vel 25 e UART komplett aktivier deaktivierbar konfigurierbare Baudrate e Kommunikationsformat 1 oder 2 Stoppbits Framegr e 5 6 7 8 oder 9 Datenbits Parit tsmodus odd even Je 8 stufiger FIFO Puffer f r Receiver und Transmitter Interrupts Daten empfangen Trasmitter Puffer leer Parit tsfehler Formatfehler Puffer berlauf Besondere Features Autobaud Unterst tzung Unterst tzung f r Hardwareflusskontrolle in jedem UART IrDA RX TX Interrupts einzeln aktivierbar 21 Analyse 4 2 4 2 IP Core UARTs Wie bereits im ersten Kapitel thematisiert wird die Entwicklung von Hardware mit Hilfe von Beschreibungssprachen immer relevanter In Erg nzung zur Betrachtung der industriellen Hardwarel sungen soll dieser Abschnitt die Ans tze zweier verschiedener Projekte pr sentieren die sich mit dem Entwurf von UARTs als IP Komponenten be fassen 4 2 1 UART16750 Das Projekt UART16750 von Sebastian Witt 26 ist zum Zeitpunkt des Entstehens die ser Arbeit abgeschlossen und wurde zuletzt im April 2011 aktualisiert Ziel des Projektes war es einen UART zu entwickeln der der Spezifikation der Modelle 16550 bzw 16750 der US amerikanischen Firma National Semiconductor unterliegt Die im Rahmen des Projekts entstandene VHDL Komponente hat folgende Merkmale e Pins und Register kompatibel mit NS16550 16750 e konfigurierbare Baudrate e reichhaltige
48. herangezogen Da der Ver 59 Evaluation 7 3 gleich dazu dienen soll zu entscheiden welche der beiden besser f r die Verwendung im LavA Workflow geeignet ist bieten sich diese Kriterien an da sie die Benutzerfreund lichkeit im t glichen Arbeitsablauf widerspiegeln 7 3 1 1 Struktur und Lesbarkeit der Templates Auf den ersten Blick unterscheiden sich Xpand Templates und x frames in ihrer Struktur nur wenig da beide Formate aus mit Steueranweisungen durchzogenem Quelltext beste hen Unter der Voraussetzung dass beide Dateitypen mit Syntax Highlighting betrachtet werden hnelt sich die grunds tzliche Lesbarkeit der einzelnen Dateien ebenfalls Die bersichtlichkeit der XML Dateien von XVCL ist dabei aufgrund des typisch gro en Anteils an spitzen Klammern und Anf hrungszeichen etwas schlechter Im Gegenzug ist man bei Xpand f r Syntax Highlighting an den schlichten Editor des Eclipse Plugins gebunden da die Templates in einer eigenen DSL verfasst werden wohingegen XVCL in jedem g ngigen XML Editor angezeigt werden kann W hrend XVCL f r gro e Da teien insgesamt relativ un bersichtlich bleibt hat der Benutzer bei der Verwendung von Xpand den Vorteil dass es mehr M glichkeiten zur Kapselung und Komplexit tsredukti on gibt Zum einen k nnen komplexe Ausdr cke in Extensions ausgelagert werden zum anderen k nnen auch mehrere Untertemplates mit beliebigen Parameterlisten erstellt werden wodurch insgesamt f r ge bte
49. hste Zeichen ein Parit tsbit sein muss und die Pr fung mit den nun kompletten Daten durchgef hrt werden kann Je nach Einstellung werden danach ein oder zwei Stoppbits erwartet Trifft dies nicht zu so wird an dieser Stelle der Interrupt f r einen Framefehler erzeugt Nach Abschluss der Verarbeitung wechselt die Bitposition wieder auf 0 also in den Zustand idle Ist ein Interrupt f r Parit tsfehler eingeschaltet wird dieser nach Abschluss des 38 6 1 Implementation Empfangs erzeugt und bleibt aktiv bis ein neues Zeichen gelesen wurde Ruhe Start Bit LSB 0 Bit 1 Bit 2 Bit 3 odd Parity Stop Bit Ruhe Start Bit Abbildung 6 1 Timing Schema nach RS 232 Quelle 28 6 1 2 2 Datenpufferung Die Realisierung der Datenpufferung h ngt von der Verwendung eines FIFO Puffers ab Wird kein Pufferspeicher verwendet so bleibt das zuletzt empfangene Datenwort im Ausgaberegister bis es entweder vom MPSoC gelesen oder durch den Empfang eines weiteren Datums berschrieben wird Bei Verwendung von Pufferspeicher sorgt der Emp fang eines Datenwortes einen Peak auf der write Leitung des FIFO und das neue Datum wird im Puffer gespeichert Ist der Puffer voll wird zyklisch das lteste Zeichen ber schrieben Der Interrupt RXREADY der darauf hinweist dass Daten abgeholt werden k nnen wird je nach Einstellung nach dem Empfang einer gewissen Anzahl von Zeichen ausgel st Bei Verwendung von Pufferspeicher handelt es sich hier um d
50. iel f r ein x framework mit zwei x frames ist in Abbildung 2 1 dargestellt In der Abbildung links oben ist der SPC des x frameworks zu lt x frame name SPC outfile MPSoC vhd gt lt set var UART value 1 gt lt x frame name MPSoC gt lt adapt x frame MPSoC gt lt insert break SIGNALS gt lt select option UART gt lt option value 1 gt entity MPSoC is port clock in std_logic reset in std_logic uart_rx in std logic lt break name SIGNALS gt uart_tx out std_logic Kr lt option gt end MPSoC lt select gt lt insert gt lt x frame gt lt adapt gt lt x frame gt entity MPSoC is port clock in std logic reset in std logic uart_rx in std logic uart_tx out std logic E end MPSoC Abbildung 2 1 Beispiel f r ein x framework 12 sehen Im SPC wird eine Variable UART definiert und mit 1 initialisiert Der x frame auf der rechten Seite wird eingebunden und das Resultat der select Anweisung an den Breakpoint SIGNALS dieses x frames gebunden Durch die Belegung der Variable mit 1 resultiert dann der im unteren Abschnitt dargestellte Quellcode W re die Variable mit 0 oder einem anderen Wert belegt so w rde innerhalb des lt select gt Kontextes kein Code ausgegeben und der Code w rde nur die ersten beiden Signaldeklarationen enthalten Eine vollst ndige Dokumentation der Funktionen und Sprachelemente ist unter 13 zu finden Grundlagen 2A 2 4 Das La
51. ipse Metamodell Anhand der im vorigen Abschnitt dargestellten Aufteilung der Konfiguration in Merk male die im Betrieb manipuliert werden k nnen und solche die nur zum Zeitpunkt der 31 Entwurf des UART 5 4 Zusammenstellung bzw Initialisierung einer UART Instanz bestimmt werden k nnen ist es nun bereits m glich das Ecore Metamodell zu bestimmen das die Grundlage des Codegenerierungsprozesses bietet Das Metamodell muss alle Konfigurierungsm glich keiten abdecken die gem Tabelle 5 1 der Modellierung zugeordnet sind Das Klassen diagramm des Metamodells ist in Abbildung 5 1 dargestellt H ile txFIFO E FIFO ai Lin size Elnt uanTX 0 1 rxFIFO 0 1 H LART aaia H RXUnit m gt parity 0 1 interrupt 0 1 H ParitySupport H InterruptSuppo Abbildung 5 1 Klassendiagramm des Ecore Metamodells Demnach besteht ein UART aus einer RX Einheit einer TX Einhei Komponenten f r die Verwaltung von Interrupts sowie zur Generierung und berpr fung von Parit tsbits Da alle diese Komponenten mit einer Multiplizit t von 0 1 gekennzeichnet und somit optional sind w re ein konkretes Modell das keine der Komponenten enth lt zun chst valide Daher ist es wichtig einen entsprechenden Constraint mittels Check siehe Ab schnitt 3 1 4 zu formulieren der sicherstellt dass gem der Intention der Modellierung zumindest eine RX ode
52. k von Grund auf neu zu entwickeln sondern auszunutzen dass Anwendungen aus einer bestimmten Problemdom ne oft viele gemeinsame Struk turen und Funktionalit ten besitzen aber nur in einzelnen Merkmalen variieren Dies kann ausgenutzt werden indem man einen gemeinsamen Kern von wiederverwendbaren Komponenten innerhalb einer Entwicklungsplattform bereitstellt Ausgehend von dieser Menge an Artefakten werden dann anwendungsspezifische Varianten der Softwarel sung produziert Einerseits bringt dies den Vorteil mit sich dass die Software Artefakte in nerhalb der Entwicklungsplattform meist ausgereifter sind als v llig neu entwickelte Grundlagen 2 3 L sungen Andererseits erhofft man sich trotz des initialen Mehraufwandes eine insge samt k rzere Entwicklungszeit pro Produkt Um einen solchen Ansatz erfolgreich um zusetzen ist es wichtig eine gute Beschreibung der gemeinsamen Eigenschaften aber auch der jeweiligen Variationspunkte einer Produktlinie zu erstellen Zu diesem Zweck wird eine Dom nenanalyse durchgef hrt deren Ergebnis in einem Dom nenmodell for muliert wird Genauere Erl uterungen zu Dom nen und Merkmalmodellen finden sich im entsprechenden Abschnitt dieses Kapitels 2 2 Funktionsweise und Anwendung eines UART Das K rzel UART steht f r Universal Asynchronous Receiver Transmitter 5 Ein UART hat die Aufgabe Daten die ber eine Bus Anbindung parallel eingegeben wer den in serielle Ausgabesignale
53. llierungs auf die Quelltextebene bertragen werden 3 1 1 Die Expressions Subsprache Die drei Hauptkomponenten des ehemaligen open ArchitectureWare Frameworks st tzen sich syntaktisch auf eine gemeinsame Grundlage Die Expressions Subsprache ist syn taktisch eine Mischung aus Java und OCL und dient dazu oft ben tigte Funktionen wie boole sche Operationen Arithmetik und Zugriffe auf Modellelemente durchzuf h ren Die grundlegenden Funktionen von Expressions orientieren sich in ersten Linie an Java was durch das Beispiel in Abb 3 1 illustriert wird Komplexere Funktionen wie myElement name Attributzugriff my name is name String Konkatenation true I false Boole sche Ausdr cke 47 11 42 Arithmetik Abbildung 3 1 Beispiel f r einfache Expressions beispielsweise die Selektion einzelner Elemente mit bestimmten Eigenschaften aus einer Liste orientieren sich hingegen stark an OCL Anweisungen wie select collect oder forAll sind identisch zu den entsprechenden OCL Versionen Die genauere Erl uterung der einzelnen Operationen ist f r das weitere Verst ndnis nicht entscheidend Deshalb sei an dieser Stelle auf die detaillierte Dokumentation der Expressions 19 bzw OCL selbst 20 verwiesen 13 Verwendete Technologien 3 1 3 1 2 Struktur von Xpand Dateien Templatedateien bestehen strukturell aus drei Arten von Ausdr cken Zun chst k nnen Modelle auf die sich die in der Datei definiert
54. n Systemtaktgeber beinhaltet Zwei Taktteiler sorgen f r die Berechnung der RX und TX Taktraten die ebenfalls an die jeweiligen Einheiten weitergegeben werden Die Steuerung der Unterbrechungen geschieht mit Hilfe zwei er weiterer Register Auf der einen Seite verwaltet die Steuereinheit ein Interrupt Konfigurationsregister durch welches einzelne Interrupts aktiviert bzw deaktiviert wer 33 Entwurf des UART 5 4 den k nnen Ein Interrupt Statusregister verwaltet die aufgetretenen Interrupts Ist aus den Ausgaben der Kommunikationseinheiten eine Situation abzulesen die eine Unterbre chung erfordert so wird das entsprechende Bit im Statusregister gesetzt Beide Register verwenden dabei die gleichen Bitzuordnungen die in Tabelle 5 3 aufgef hrt sind Bitposition Interrupt berlauf des RX FIFO berlauf des TX FIFO Formatfehler Parit ts berpr fung fehlgeschlagen TX FIFO leer keine Daten zu bertragen RX FIFO F llstand ber Trigger Level oder voll CO VG Ga H ta CH Tabelle 5 3 Mapping der Interrupt Register 5 4 3 Anbindung an den Wishbone Bus Die Spezifikation des Wishbone Busses 16 bietet verschiendene Architekturen zur Ver bindung von kommunizierenden Ger ten Es wird dabei grunds tzlich aber nur zwi schen Master und Slave Ger ten unterschieden Der UART nimmt grunds tzlich die Rolle eines Slave ein was die Anbindung an den Datenbus unkompliziert macht da die Initiierung einer
55. n der 1 3 Einleitung zu entwickelnden UART Komponente Kapitel 6 zeigt die wesentlichen Teile der fertigen Komponente und erl utert den Implementationsprozess sowie die Schnittstelle zum Be triebssystem Abschlie end wird in Kapitel 7 eine Evaluation des entstandenen UART vorgenommen Der erste Teil des Kapitels erl utert die Methodik mit der der UART nach Abschluss der Implementierung besonders bez glich der verschiedenen Konfigura tionsm glichkeiten getestet wurde Im zweiten Teil des Kapitels wird dann betrachtet wie sich der entwickelte UART bez glich der Ressourcenausnutzung auf dem Ziel FPGA verh lt Der dritte und letzte Teil des Kapitels befasst sich schlie lich mit Xpand und der Eignung als Ersatz f r die bisher verwendete XVCL L sung Kapitel 8 schlie t die Arbeit mit einem Fazit und Ausblick ab 2 Grundlagen In diesem Kapitel sollen bevor die eigentliche Entwicklung der UART Familie the matisiert wird grunds tzliche Konzepte der modellgetriebenen Hardwareentwicklung besonders mit Bezug auf das LavA Projekt n her erl utert werden um das weitere Verst ndnis zu erleichtern Zu Beginn werden das Konzept von Hardwareproduktlini en sowie die Funktionsweise und das Anwendungsfeld eines UART genauer erl utert Im Folgenden wird dann n her auf die Funktionsweise der LavA Plattform eingegan gen Zu diesem Zweck werden zun chst die wichtigsten Konzepte und Technologien die im LavA Workflow verwendet werden e
56. n dupliziertem Code bietet es sich daher an mehrfach vorkommende Subroutinen in Extensions zu schachteln Das UART Projekt kommt aufgrund der re lativ einfachen Struktur des Metamodells mit nur sieben Extensions aus Sechs dieser Extensions sind dabei einfache Wrapper f r Modellzugriffe wie Bestimmung der gew hl ten FIFO Gr e Bei der siebten Extension handelt es sich um eine rekursive Funktion zur Erzeugung einer Sequenz von Nullen mit vorgegebener L nge Diese Subroutine ist in Abbildung 6 6 dargestellt Sie wird nur an einer Stelle zur dynamischen Generierung eines Bitvektors ben tigt ist aber wesentlich kompakter als eine Formulierung mit den reinen Sprachmitteln von Xpand String zeroes UART this Integer size size 1 0 zeroes this size 1 Abbildung 6 6 Rekursive Extension zeroes 6 2 4 Der Workflow Die Workflow Definition die die Verwendung der einzelnen Komponenten des Projektes orchestriert hat eine recht einfache Struktur Da es f r die Codegenerierung in die sem Projekt nicht erforderlich war eigene Generatorklassen zu entwickeln reicht es aus Standardkomponenten ohne umfangreiche Konfiguration zu laden und zu verwenden Zu Beginn wird das Metamodell instanziiert und das jeweils gew nschte konkrete UART Modell geladen Der erste Verarbeitungsschritt besteht darin einen Check Validator mit 46 6 3 Implementation der entsprechenden Constraint Datei als Parameter zu instanziieren und da
57. n erzeugen w ren diese insgesamt kompakter Eine im Verh ltnis zum Nutzen sehr aufwendige aber nichtsdestotrotz in teressante Erweiterung w re die Entwicklung eines VHDL Code Beautifiers f r Xpand Codegeneratoren So k nnte der momentan n tige Kompromiss bez glich Lesbarkeit und Wartbarkeit zwischen Templates und generiertem Code eliminiert werden 60 Literaturverzeichnis 1 MARWEDEL Peter Embedded System Design Embedded Systems Foundations of Cyber Physical Systems Springer 2010 2 TU Dortmund Lehrstuhl 12 Arbeitsgruppe Eingebette Systemsoftware LavA Laufzeitplattform f r anwendungsspezifische verteilte Architekturen http ess cs tu dortmund de DE Research Projects LavA 3 STAHL Thomas VOLTER Markus EFFTINGE Sven HAASE Arno Modellge triebene Softwareentwicklung Techniken Engineering Management dpunkt verlag 2007 4 LOHMANN Daniel HOFER Wanja SCHRODER PREIKSCHAT Wolfgang STREI CHER Jochen SPINCZYK Olaf CiAO an aspect oriented operating system family for resource constrained embedded systems In Proceedings of the 2009 conference on USENIX Annual technical conference Berkeley CA USA USENIX Associati on 2009 USENIX 09 16 16 5 Wikipedia Universal Asynchronous Receiver Transmitter http de wikipedia org wiki UART Version Mai 2011 6 The Eclipse Foundation Xpand Project http www eclipse org modeling m2t project xpand 7 openArchitectureWar
58. n und die Ausgabe des aktuellen Datenwortes in Abh ngigkeit von den Werten der Adresszeiger Der dritte und letzte Prozess sorgt letztendlich f r die Bestimmung der Pufferauslastung indem er einen internen Z hler f r jeden Schreibzugriff inkrementiert und beim Lesen wieder dekrementiert Bei der Verwendung des Puffers ist besonders zu beachten dass die Aus f hrung der Lese und Schreiboperationen direkt an den Takt gebunden ist F r eine korrekte Funktionsweise muss daher von der bergeordneten Komponente sichergestellt werden dass die Steuersignale read bzw write pro Zugriff nur f r eine Taktperiode einen Pegel von logisch 1 haben d rfen 6 1 5 Steuereinheit Die Steuereinheit beinhaltet die gesamte Konfigurationslogik des UART In einem UART mit vollem Funktionsumfang besteht die Steuereinheit somit aus vier Registern und zwei hintereinandergeschalteten Baudratengeneratoren f r Receiver und Transmittertakt so wie entsprechender Steuersignale Die wesentlichen drei Aufgaben der Steuereineit sind die Verwaltung der Konfigurationsregister das Erzeugen von Interrupts die Weiterlei tung der Konfigurationsdaten an die RX und TX Einheiten und die Erzeugung von individuellen Taktraten f r diese Module Als Eingabesignale der Steuereinheit gibt es zun chst load Leitungen f r die einzelnen Register Da die UART Ansteuerung bereits in der Top Level Entit t bersetzt wird muss die Steuereinheit nur noch die entspre chenden Signale und D
59. n unterst tzt Xpand eine Reihe von Anweisungen die auch aus den meisten anderen Programmiersprachen bekannt sind Zum einen gibt es FOR und FOREACH Befehle die in Xpand benutzt werden um Templates auf Elemente des Modells anzuwenden Bei der Verwendung von FOREACH ist es hierbei wichtig zu beachten dass das Argument der An weisung im Modell kein skalarer Datentyp sein darf sondern ein Collection Objekt also eine Liste Menge oder hnliches sein muss Des Weiteren gibt es konditionale Anwei sungen in Form des blichen IF Blocks mit optionaler Alternativanweisung innerhalb eines ELSE Statements und beliebig vielen dazwischen angeordneten ELSEIF Bl cken Xpand erlaubt zudem lokale Variablendefinitionen Mit Hilfe des LET Statements kann ein Block deklariert werden in dem die entsprechende Variable sichtbar ist Im Sprach umfang sind weiterhin drei Metaanweisungen enthalten die nicht direkt in den Generie rungsprozess eingreifen aber dennoch bei der Entwicklung von Templates n tzlich sein k nnen Zum einen bietet Xpand die M glichkeit innerhalb eines REM Blocks Kommenta re in das Template einzubringen Dies kann gerade bei gro en und komplexen Templates n tzlich sein um die bersichtlichkeit zu verbessern Die zweite Metaanweisung ist das ERROR Statement Wird bei der Abarbeitung des Templates eine solche Anweisung er reicht dann bricht die Bearbeitung mit einer entsprechend angegebenen Fehlermeldung ab Es ist allerdings anzumerken
60. ng von Daten Die Verarbeitung von seriellen Eingaben wird innerhalb eines einzigen Prozesses erle digt Zun chst werden die Konfigurationsparameter die bisher nur als logische Werte vorliegen in Variablen geschrieben Dies geschieht zu jedem Taktzyklus da sich diese Parameter zur Laufzeit jederzeit ndern k nnen Nach diesem Initialisierungsschritt be ginnt die eigentliche Verarbeitung der Daten nach dem Schema f r asynchronen seriellen Kommunikation des RS 232 Standards vgl Abbildung 6 1 Die aktuelle Bitposition im empfangenen Datenwort wird dabei in einer Variable gespeichert Da das Verhalten der Komponenten in jedem Schritt von der Bitposition abh ngt realisiert dies eine einfache Zustandsmaschine Solange der Z hler auf Position O steht und kein Startbitpegel auf tritt bleibt die RX Einheit im Zustand dle und wartet auf Eingaben Tritt ein Startbit auf so beginnt ein neuer Verarbeitungszyklus und die Bitposition wird auf 1 gesetzt Je nach eingestellter Wortbreite werden dann bis zum letzten Datenbit die Werte an die entsprechende Stelle eines Pufferregisters das die Aufgabe des RX Schieberegisters bernimmt geschrieben Ist die Bitposition bis zum Ende des Datenbitbereichs fort geschritten dann wird das empfangene Datenwort aus dem Schieberegister in das Ausgaberegister bertragen Wenn der UART f r die Verwendung von Parit tsbits kon figuriert ist wird das enable Signal des Parit tspr fers aktiviert da das n c
61. nit TXUnit ICthis uartRX null 88 this uartTX null Abbildung 6 2 Der erste Constraint des Modellierungsprojekts Der Constraint bezieht sich auf die Gesamtstruktur des UART weshalb das ent sprechende Wurzelelement des Metamodells den Kontext bietet Bei Versto gegen den Constraint muss hier offensichtlich die Codeerzeugung durch Auftreten eines Fehler ab gebrochen werden da die Struktur der erzeugten Artefakte der eigentlichen Intention des Entwurfs widersprechen w rde Der zweite Constraint des Projekts bezieht sich auf die Gr e der einzelnen FIFO Speicher Da der Benutzer die Gr e des FIFO selbst angeben kann ist es wichtig die Eingabe entsprechend zu validieren Es ist vorgesehen dass es FIFO Speicher mit einer Gr e von 1 bis zu 64 Slots gibt Da die Gr e hier in Form des Exponenten einer Zweierpotenz angegeben wird muss der eingetragene Wert offensichtlich zwischen 1 und 6 liegen Der Constraint der genau dies sicherstellt ist in Abbildung 6 3 dargestellt Die Relevanz dieser Einschr nkung liegt nur lokal beim FIFO Speicher weshalb dieser auch den Kontext des Constraints darstellt Wie beim ersten Constraint muss auch hier eine Fehlermeldung erzeugt werden da beispielsweise eine negative FIFO Gr e f r die 43 Implementation 6 2 context FIFO ERROR FIFO size must be set and between 1 and 6 this null II Cthis size null 88 this size gt 0 88 this size lt 7 Abbildung 6 3 D
62. nnen entweder direkt in Hardware realisiert sein oder in Software durch den Ger tetreiber geregelt werden Bei Realisierung in Hardware sind die Priorit ten meist festgelegt und k nnen nicht vom Benutzer ver ndert werden Die Priorit tssteuerung in Software ist an dieser Stelle flexibler Manche Ger te unterst tzen auch die Pufferung von aufgetretenen Interrupts Dies kann zum einen ber ein Register erfolgen in dem zumindest ein Interrupt jeder Art gespeichert wird oder auch in einem FIFO Puffer 28 5 Entwurf des UART Dieses Kapitel beschreibt den Entwurf der UART Komponente Ausgehend von der im vorigen Kapitel dargestellten Dom nenanalyse wird zun chst der Umfang der umzu setzenden Funktionen hergeleitet und erl utert wie die Konfiguration der einzelnen Komponenten im Betrieb bzw bei der Instanziierung stattfinden soll Auf der Grund lage dieses Konfigurationsschemas wird dann das Metamodell f r die Generierung des UART dargestellt Im Folgenden wird die Ausarbeitung des Hardwaremodells eines um Konfigurationspunkte erweiterten Blockdiagramms erl utert welches die Basis f r die Umsetzung des UART in VHDL bietet 5 1 Funktionsumfang des UART Um einen zufriedenstellenden Konfigurationsumfang zu erreichen liegt es nahe zun chst die Merkmale die alle im Laufe der Dom nenanalyse betrachteten UARTs gemeinsam haben als obligatorisch zu betrachten und mit in den Entwurf einzubeziehen Ausge hend vom bisherigen Funktion
63. nstance soc Connection 1 SoC 2 MBLite UART IPC MIPS OutPort Timer IPC openArchitectureWare Configurable IP Components Specification of MPSoC Configuration lt x frame name mpsoc gt entity mpsoc is port clk in std_logic reset in std_logic gt lt break name signals gt A IK end mpsoc vr AMCL lt x frame gt A entity mpsoc is port clk in std mpsoc vhd td_logic reset in std_Ic C vuart_rx_1 in std_1 Hart CNL out std_ c outpins_2 out std_logic_vector 7 downto 0 end mpsoc architecture behave_mpsoc of mpsoc is end behave_mpsoc Abbildung 2 3 Die Hardware Konfiguration der LavA Plattform 2 tem zu modellieren ein konkretes Modell abgeleitet werden in das die Anforderungen des Anwendungsgebietes einflie en Dies geschieht mit Hilfe eines grafischen Editors Nachdem mit der Erstellung des konkreten Modells die Auswahl und Konfiguration der einzelnen Komponenten vorgenommen wurde m ssen die gew hlten Optionen mit zu generierenden Quellcode in Verbindung gesetzt werden LavA verwendet zur Codegene rierung XVCL Daher wird ein Xpand Template verwendet um die Werte aus dem vom Object Constraint Language Grundlagen 2 5 Benutzer erzeugten MPSoC Modell zu extrahieren und daraus einen SPC zu erzeugen Die VHDL Komponenten die als XVCL x frames bzw x frameworks vorliegen k nnen dann leicht vom S
64. omponenten in VHDL 37 6 1 1 Die Top Level Entit t ii DIE Den Ai 37 61 2 Rebinhe 2 ele aks wa aea a EE 38 6 1 3 TX Einheit ao d a e Bra a 39 BA REESEN 40 GS Steuereinh it vs eds Dd ah da 41 6 1 6 Baudratengenerator e Sn te We A e EE E Ee 42 6 1 7 Konfigurationsregister nar Seren 42 6 18 Parit tspr fung und generierung 42 6 2 Die Codegenerierung nase p taa wale ee ie 43 92 1 Constraints orbe ia la aa 43 6 2 2 Struktur der Templates uba di di e A 44 6 2 3 Extensions 4585 a ee a et Se ET ln eh ta Th 46 6 2 4 Der Workflow ds 202 8 old ee ae ee aa 46 6 3 Ansteuerung des UART so won wu dos de glue dog amp en Se Aa es eS AT 6 3 Senden von Daten ala A SAA NA 47 6 3 2 Auslesen empfangener Daten 47 0 313 Konfiguration yd AA a E EA A 48 6 3 4 Interruptbehandlung 4 2 2 de sn bean le AA AR 48 Evaluation 51 7 1 Methodik des UART Tests 30 ER Dir ias a in 51 7 1 1 Auswahl der Testeysteme pra dr Era E Ae 52 7 1 2 Ablauf des Laufzeittests 52 7 2 Evaluation des UART 9 204 aa a ada 53 7 2 1 Minimalkonfiguration EA IS 53 7 2 2 Teilmenge der m glichen Komponenten 54 7 2 3 Kompletter Funktionsumfang 54 7 2 4 Auswertung der Ergebnisse o oo a 55 7 3 Evaluation der Codegenerierung at ooo a le a 55 7 3 1 Vergleich von Xpand und XVCL o o 59 hoo Eignung v i Xpand di o LEERE NS 57 ii Inhaltsverzeichnis 8 Fazit und Au
65. osition 0 entspricht wieder dem Zustand dle in dem eine konstante logische 1 ausgegeben wird Ist im Puf ferspeicher ein neues Datum vorhanden so wird die Bitposition inkrementiert und die bertragung beginnt Bei Bitposition 1 wird zun chst ein Startbit mit einem logischen Nullpegel erzeugt danach folgen die einzelnen Datenbits beginnend mit dem LSB Bei entsprechender Konfiguration wird anschlie end das Parit tsbit und danach wiederum eine entsprechend lange Zeit ein Stoppbit erzeugt Das Parit t kann hierbei im Gegensatz zur RX Einheit jederzeit bestimmt werden da das Datum von Beginn der bertragung komplett vorliegt 6 1 3 2 Datenpufferung Ohne einen FIFO Speicher kann die TX Einheit ein Zeichen zwischenspeichern Nach dem das aktuelle Zeichen in das Schieberegister transferiert wurde kann bereits wieder ein neues Zeichen abgelegt werden Bei Verwendung eines FIFO Puffers funktioniert die Dateneingabe nach demselben Prinzip mit entsprechend mehr Speicherplatz Ist der Puf ferspeicher leer so kann der Interrupt TXREADY aktiviert werden um zu signalisieren dass der letzte Sendeauftrag abgeschlossen ist 6 1 4 FIFO Puffer Als FIFO Puffer wird eine Komponente aus dem Projekt UART16750 von Sebastian Witt 26 verwendet Das Projekt wurde im Rahmen der Dom nenanalyse f r diese Arbeit betrachtet und es stellte sich heraus dass die Komponente sich insbesondere auf grund ihrer umfassenden Statusausgaben sehr gut f r eine Wieder
66. r TX Einheit vorhanden sind 5 4 Entwurf einzelner Komponenten Aus den bisherigen berlegungen l sst sich bereits eine relativ kanonische grobgranu lare Architektur des UART abzeichnen Die zwei Hauptkomponenten des alten LavA UART n mlich Sende und Empfangseinheit k nnen als zwei Hauptkomponenten des neuen UART bernommen werden Sie m ssen lediglich intern um die neuen Funktio nalit ten erweitert werden Durch die Einbringung der neuen Funktionen kommen viele Konfigurations und Statusregister und neue Leitungen hinzu Auch die Interaktion des UART mit der parallelen Schnittstelle darunter insbesondere das Lesen und Schreiben von Daten muss beachtet werden Da diese Komponenten im Grunde das Verhalten des UART steuern k nnen sie aggregiert als Steuereinheit betrachtet werden Der UART 32 5 4 Entwurf des UART l sst sich so berschneidungsfrei in die drei Komponenten RX Einheit TX Einheit und Steuereinheit einteilen 5 4 1 RX und TX Einheit Die RX und TX Einheiten beinhalten alle Teile des UART die sich mit dem Empfang bzw im Falle der TX Einheit mit dem Senden serieller Daten besch ftigen Im Wesentli chen geh ren dazu die Serien Parallel bzw Parallel Serien Wandler die das bersetzen von seriellen auf parallele Daten bernehmen sowie die neu hinzugekommenen FIFO Speicher Beide Einheiten sind ber Steuereing nge mit der Steuereinheit verbunden um f r das Senden und Empfangen wichtige Formatkonfigu
67. rationsdaten zu erhalten Ebenfalls Teil der RX Einheit ist ein Parit tspr fer der zur Validierung von empfange nen Daten dient Entsprechend hierzu enth lt die TX Einheit einen Parit tsgenerator Beide Einheiten werden des Weiteren um neue Statusleitungen erg nzt Im Falle der RX Einheit muss beispielsweise die Information ber Korrektheit des aktuellen Daten wortes an die Steuereinheit weitergeleitet werden damit diese im negativen Fall eine entsprechende Unterbrechung ausl sen kann 5 4 2 Steuereinheit Den komplexeren Teil der Architektur stellt die Steuereinheit dar da in ihr ein Gro teil der Verhaltenslogik des UART liegt Die Steuereinheit steuert zun chst das Verhalten der RX und TX Einheit Zu diesem Zweck verf gt sie ber ein Konfigurationsregister in dem die Formatierungsoptionen des seriellen Datenstroms eingetragen sind Die Be deutung der einzelnen Bitpositionen ist dabei in Tabelle 5 2 dargestellt Die einzelnen Einstellungen werden ber entsprechende Leitungen an die Empfangs und Sendeeinheit weitergeleitet Bitposition Belegung 0 Handshake aktivieren 1 Stoppbits 0 1 Bit 1 2 Bit 2 Parit tsmodus 0 gerade 1 ungerade 3 Parit tsbit aktivieren 4 6 Framegr e 7 14 RX FIFO Trigger Level Tabelle 5 2 Mapping des Format Konfigurationsregisters Neben der Formatierung verwaltet die Steuereinheit auch ein Baudratenregister das den Taktteilungsfaktor f r de
68. rein ausgelassen werden Dies ist ebenfalls gegeben wenn keine Interrupts gew nscht werden oder ein Parit tsbit nie verwendet werden soll In diesen F llen k nnen ebenfalls Register und Module wie der Parit tsgenerator nicht erzeugt werden um eine Ressour cenersparnis zu erreichen Bei Interrupts und Parit ten ergibt sich die Besonderheit dass neben der Konfiguration zur Modellierungszeit auch Einstellungen wie das Aktivieren einzelner Interrupts oder das ndern des Parit tsmodus im Betrieb vorgenommen wer den k nnen Diese Komponenten m ssen also zu beiden Zeitpunkten manipuliert werden k nnen Parameter des UART die zur Modellierungszeit festgelegt werden m ssen sind beispielsweise die Gr e der FIFO Puffer da je nach Gr e andere Hardwarestrukturen synthetisiert werden m ssen Der Trigger Level ist wiederum eine Option die zur Lauf zeit ver nderbar sein kann Insgesamt ergibt sich damit die Aufteilung die in Tabelle 5 1 dargestellt ist Modellierung Betrieb Vorhandensein der Parit tsmodule Parit tsmodus Generator und berpr fungseinheit Aktivieren des Parit tsbits Framegr e Stoppbits Baudrate Hardwareflusskontrolle RTS CTS Vorhandensein der RX TX Einheiten RX FIFO Trigger Level FIFO Puffer ja nein Gr e der FIFOs Interrupt Unterst tzung Aktivierung von Interrupts Setzen der Priorit ten in SW ber Treiber Tabelle 5 1 Zuordnung der Konfigurationspunkte 5 3 Ecl
69. reitstellt ist die Ersetzung von XVCL durch einen vollst ndigen Xpand Workflow in meinen Augen durchaus eine praktikable Alternative 57 8 Fazit und Ausblick Dieses Kapitel bildet den Abschluss dieser Arbeit und gibt zu diesem Zweck einen letzten berblick ber die im Verlauf der Arbeit entwickelten Komponenten und gewonnenen Erkenntnisse Im zweiten Teil des Kapitels wird schlussendlich ein Ausblick bez glich eventueller Erweiterungsm glichkeiten der entwickelten UART Familie gegeben 8 1 Zusammenfassung Im Laufe dieser Bachelorarbeit wurde im Kontext des LavA Projekts ausgehend von ei ner einfachen statischen VHDL Implementierung eines UART eine dynamische UART Familie entwickelt aus welcher mithilfe des Codegenerierungsframeworks Xpand und der Eclipse Modeling Workflow Engine verschiedene zur Laufzeit konfigurierbare UART Varianten ma geschneidert werden k nnen Zu diesem Zweck wurde in Kapitel 4 hinsicht lich der m glichen Konfigurationsm glichkeiten zun chst eine Dom nenanalye durchge f hrt auf deren Grundlage der Entwurf des UART in Kapitel 5 umgesetzt werden konnte Hier wurden sowohl UARTS industriell vertriebener Mikrocontroller als auch verschiede ne Open Source Entwicklungen betrachtet um eine sinnvolle Auswahl zu realisierender Funktionen zu gewinnen In Kapitel 5 wurden die Konfigurationspunkte anschlie end Konfigurationszeitpunkten Laufzeit und Modellierungszeit zugeordnet wobei die Kon figurierung z
70. rl utert Dazu z hlen XVCL Xpand und M g lichkeiten der Konfiguration innerhalb von VHDL Detailliertere Erl uterungen zu den letzten beiden Punkten finden sich hierbei insbesondere in Kapitel 3 Abschlie end wer den Merkmalmodelle thematisiert die im Kontext der Dom nenanalyse eine wichtige Rolle spielen 2 1 Hardwareproduktlinien Der Begriff der Produktlinien stammt urspr nglich aus der Softwareentwicklung Mit der zunehmenden Verbreitung von rekonfigurierbarer Logik in Form von FPGAs und Po pularit t von Hardwarebeschreibungssprachen wie VHDL Verilog oder SystemC wird dieses Konzept allerdings auch auf Hardwareentwicklungsprozesse anwendbar B ckle et al 9 beschreiben die Produktlinienentwicklung als ein Konzept dass auf organisierter Wiederverwendung und organisierter Variabilit t basiert Die Grundlage der Produktli nien bildet die Zuordnung von Software zu bestimmten Problemdom nen Czarnecki und Eiesenecker 10 beschreiben eine Dom ne als einen abgeschlossenen Raum von Wissen Technologien und Konzepten definiert durch die Interessengruppen Stakeholder dieses Gebietes Insbesondere ist darin auch das Wissen um die Entwicklung entsprechender dom nenspezifischer Software eingeschlossen sodass eine Dom ne aus technischer Sicht auch als eine Menge von Systemen f r einen bestimmten Problembereich betrachtet werden kann Ausgehend von dieser Dom nensicht wird nun versucht Software nicht f r jeden Anwendungszwec
71. s Auto braucht ein Getriebe es kann aber nur entweder Gangschaltung oder Automatik haben Bei ei nem ausgef llten Bogen handelt es sich um eine Gruppe von kumulativen Merkmalen Es k nnen eines oder mehrere gew hlt werden Bezogen auf das Beispiel kann man also ablesen dass der Motor eines Autos mindestens ein Benzinmotor oder Elektromotor sein muss Es k nnte sich aber auch um ein Hybridfahrzeug handeln das beides unterst tzt 11 3 Verwendete Technologien 3 1 Entwicklung von Templates mit Xpand Bei Xpand 6 7 handelt es sich um eine Templatesprache die urspr nglich als Teil des MDSD Frameworks openArchitecture Ware entworfen wurde Mittlerweile sind die einzelnen Komponenten dieses Frameworks Xpand Xtend und Check gr tenteils un abh ngige Projekte innerhalb des Eclipse Modeling Frameworks geworden Die Syntax von Xpand hnelt bekannten Markup Sprachen wie XML insofern dass Anweisungen in Tags formuliert und ineinander verschachtelt werden k nnen Tags werden dabei im Gegensatz zu HTML oder XML nicht durch einfache spitze Klammern sondern durch die Zeichen bzw sogenannte Guillemets oder franz sische Anf hrungszeichen be grenzt Die Besonderheit von Xpand liegt darin dass Templates auf einem zuvor in einem grafischen Editor erstellten Modell basieren Einzelne Elemente dieses Modells k nnen und m ssen innerhalb des Templates direkt referenziert werden Auf diese Weise k nnen leicht Parameter von der Mode
72. s zuvor ge ladene Modell zu validieren Solange hier kein Fehler auftritt wird der Standard Xpand Generator geladen und bekommt das Haupttemplate mit dem konkreten Modell als Eingabe Nachbearbeitungsschritte gibt es nicht mehr da das Xpand Framework f r VHDL keine Code Beautifier anbietet 6 3 Ansteuerung des UART Die Kommunikation mit dem UART erfolgt wie bereits beschrieben durch das Schreiben und Lesen bestimmter Register ber das Wishbone Protokoll F r das Betriebssystem bzw die Treibersoftware sind diese Register ber Memory Mapped 1 O erreichbar das Schreiben und Lesen funktioniert also ber Zugriffe auf bestimmte Adressen Zur An steuerung des UART wurde daher eine Bibliothek von C Funktionen entwickelt die in erster Linie dazu dienen vom hardwarenahen manuellen Auslesen und Schreiben der Register zu abstrahieren und die Verwendung der UART Funktionen f r den Benutzer zu erleichtern Die Funktionen lassen sich dabei in die folgenden vier Gruppen einteilen bertragen von Daten Auslesen von Daten Konfiguration und Interruptbehandlung 6 3 1 Senden von Daten Die einfachste M glichkeit Daten zum Senden an den UART zu bertragen besteht darin ein einzelnes Zeichen in das Transmissionsregister zu schreiben Die Funktion uart_putc erm glicht genau dies indem sie das als Parameter bergebene Zeichen un ter der entsprechenden Adresse speichert Um zu vermeiden dass ein noch nicht ber tragenes aber schon dem UART
73. sblick E Dee un Kr A DA are dd Dr ae ca Seh 8 2 Ausbliek 382 8 eet Zr A nl a a ee Literaturverzeichnis Abbildungsverzeichnis Tabellenverzeichnis 59 99 60 63 65 67 111 1 Einleitung Eingebettete Systeme nehmen heutzutage einen Gro teil der auf dem Markt befindli chen Rechnersysteme ein In nahezu jedem elektrischen Ger t des Alltags findet man eingebettete Rechnerhardware Gerade in technisch anspruchsvollen und rechenintensi ven Anwendungen wie Multimediager ten Telekommunikation oder auch Verschl sse lungssystemen f r Netzwerke findet man dabei besonders sogenannte MPSoCs Mul tiprocessor Systems on Chip Ein MPSoC vereint mehrere Prozessoren Speicher und verschiedenste ben tigte Peripherieger te auf einem Chip mit dem Ziel die jeweilige An wendung m glichst schnell und effizient auszuf hren Um dieses Ziel zu erreichen ist es n tig die Hardware auf den Anwendungszweck ma zuschneidern Eine M glichkeit dies zu tun ist der Entwurf eines ASIC Application Specific Integrated Circuit also einer hochspezifischen aber statischen Hardware Da sich das Design eines ASIC aus Kosten gr nden oft nur f r Schaltungen lohnt die in gro en St ckzahlen produziert werden 1 werden heute viele eingebettete Systeme mithilfe von Hardwarebeschreibungssprachen wie VHDL Verilog oder SystemC und rekonfigurierbarer Logik in Form von FPGAs Field Programmable Gate Arrays entworfen Das System wird dabei in ein
74. se entkoppelt und es bietet sich dementsprechend an die Kapselung der einzelnen Templates im Hinblick auf ihre Komplexit t und Gr e vorzunehmen um eine m glichst bersichtliche und verst ndliche Templatestruktur zu erhalten Abbildung 6 5 zeigt die Grobstruktur der Aufrufe der sieben Templatedateien untereinander package xpt Abbildung 6 5 Grobstruktur der Templatedateien Ein Pfeil mit durchgezogener Linie deutet hierbei einen Aufruf an der ungeachtet der Konfiguration des UART immer auftritt ein Pfeil mit gestrichelter Linie bedeutet dass der Aufruf nur unter bestimmten Umst nden ben tigt wird Wie bereits beschrieben startet die Bearbeitung der Templates im Haupttemplate root xpt Da die einzelnen Templates jeweils voneinander unabh ngige Dateien erzeugen ist die Aufrufreihenfolge nicht von Bedeutung Die Datei uart xpt ist f r die Erzeugung der Top Level Instanz des UART zust ndig Sie besteht intern aus f nf einzelnen Templates ein Haupttemplate erzeugt die Schnittstelle nach au en sowie interne Signalzuweisungen ein weiteres die Deklarationen der internen Signale Die drei brigen Templates sind f r die Erzeugung der Instanzen von RX TX und Steuereinheit zust ndig Die Verwendung eines eigenen Templates f r die internen Signale ist hierbei dadurch begr ndet dass diese sehr stark von der Konfiguration und den anderen internen Komponenten des UART abh ngen und ihre Erzeugung somit verh ltnism ig komplex
75. serielle Kommunikationsschnittstellen aus gelegt Sie basieren auf einem ARM7TDMI S Prozessor und sind mit einer gro en Menge an Peripherieger ten ausgestattet Die Mikrocontroller besitzen vier intern baugleiche UARTs von denen einer U ARTI zus tzliche Hardware Handshake Leitungen zur Fluss kontrolle bei der Kommunikation mit Modems besitzt Ein weiterer UART UART3 be sitzt eine Infrarotschnittstelle zur Kommunikation ber IrDA Im offiziellen Datenblatt 23 und im Benutzerhandbuch 24 ist folgender Funktionsumfang aufgestellt e Transmitter deaktivierbar e 16C550 konforme Konfigurationsregister konfigurierbare Baudrate Kommunikationsformat 1 oder 2 Stoppbits Framegr e 5 6 7 8 oder 9 Datenbits Parit tsmodus odd even Je 16 Byte FIFO Puffer f r Receiver und Transmitter konfigurierbare Trigger Level f r FIFOs bei 1 4 8 sowie 14 Byte Iinfrared Data Association 20 4 2 Analyse e Interrupts Autobaud Zeit berschreitung Autobaud Detektion abgeschlossen Daten empfangen Kombinierter Interrupt f r bertragungsfehler mit Statusregister e Besondere Features optionale Software Flusskontrolle automatische Baudratenerkennung ABR autobaud 4 1 3 Microchip PIC32 Die PIC32 Serie der Firma Microchip Technology Inc besitzt eine 32 bit Architektur basierend auf einem MIPS M4K Prozessorkern Die Mikrocontroller verf gen ber sechs UARTs mit jeweils fol
76. sregister Da die Wishbone Ansteuerung des UART vom MPSoC schon in sofern gefiltert wird dass nur f r den UART relevante Anweisungen in Verbindung 37 Implementation 6 1 mit einem CYC Signal auftreten und eine Busbreite von 32 Bit vorliegt reicht es an dieser Stelle einfach die Adressbits an den Positionen 4 bis 2 zu berpr fen um das gew nschte Register zu erhalten In Verbindung mit dem Pegel der WE Leitung l sst sich so die gew nschte UART Anweisung dekodieren und ein entsprechendes internes Signal aktivieren welches die Abarbeitung der Anweisung in einer der Untereinheiten des UART anst t W hrend bei einem Schreibzugriff nichts weiter zu tun ist wird im Falle eines Lesezugriffs noch das richtige Datum an den ausgehenden Datenleitungen angelegt 6 1 2 RX Einheit Die RX Einheit stellt den seriellen Empf nger des UART dar Als Eingabesignale be kommt die Komponente einen Systemtakt und den reduzierten Baudratentakt reset und read als Steuersignale die serielle Datenleitung und die von der Steuereinheit ausgegebe nen Konfigurationsparameter f r Framegr e Parit tsverhalten und Stopbitl nge Die Ausgabe der RX Einheit besteht aus Statusinformationen zu Pufferf llstand und Auf treten eines Puffer berlaufs sowie der parallelen Datenausgabe Strukturell besteht die Einheit aus einem Schieberegister und einem Datenpuffer zum Empfangen der seriellen Eingabe sowie gegebenenfalls einem Parit tspr fer 6 1 2 1 Empfa
77. strukt Bei Generics handelt es sich um einfache Parameter die in der Entity Deklaration einer Komponente deklariert und bei der Instanziierung festgelegt werden m ssen Innerhalb der Instanz k nnen diese Para meter dann wie Konstanten verwendet werden Abbildung 3 5 zeigt ein simples Beispiel Die generate Anweisung kann benutzt werden wenn gleiche Codesegmente mehrfach entity my_device is generic my_parameter integer range to 127 architecture RTL of my_other_device is component my_device generic my_parameter integer range to 127 port clk in std_logic end component my_device 3 port clk in std_logic Ae end entity my_device begin my_instance my_device instanziiere my_device generic map my_parameter gt 64 setze Parameter auf 64 port map clk gt clk end architecture RTL Abbildung 3 5 Ein einfaches Generics Beispiel Links die entity Deklaration rechts die Instanziierung erzeugt werden sollen Beispielsweise w re dies denkbar um eine bestimmte Anzahl von D Flipflops innerhalb eines FIFO Speichers einzuf gen In diesem Fall w rde sich die iterative Variante der Anweisung anbieten die im Wesentlichen eine for Schleife reali siert Neben der iterativen Variante gibt es noch die konditionale generate Anweisung Sie entspricht grunds tzlich einer if Abfrage Diese beiden Anweisungstypen k nnen ins besondere ineinander verschachtelt werden Eine Beschreibung der Syntax ist in Abbil
78. sumfang des LavA UART vgl Kapitel 2 geh ren dazu zun chst e konfigurierbare Baudrate e verschiedene Interrupts e konfigurierbares Datenformat variable Anzahl Stoppbits Paritat variable Framegr e e Pufferung von Daten Senden und Empfang Zus tzlich zu diesen Features gilt es noch die jeweiligen Schnittstellen zu bestimmen Auf der Systemseite soll hier als parallele Schnittstelle zun chst nur der bereits verwen dete Wishbone Bus weiter unterst tzt werden Eine Implementierung weiterer Busse wie CAN oder I C ist nicht vorgesehen Bez glich der seriellen Schnittstelle soll auch wei testgehend der bisherige Funktionsumfang erhalten bleiben Diese Entscheidung liegt in der Tatsache begr ndet dass es in erster Linie Ziel dieser Arbeit ist den Funkti onsumfang des LavA UART durch Erweiterung um Konfigurationsm glichkeiten inner halb der Plattform flexibler zu machen und nicht eine m glichst hohe Kompatibilit t 29 Entwurf des UART 5 2 mit moglichst vielen verschiedenen Ger ten zu erreichen Neben der Daten bermittlung wird es allerdings die M glichkeit der einfachen Hardwareflusskontrolle ber die Signale RTS bzw CTS geben um Puffer berl ufen vorzubeugen Weitere vereinzelt aufgetre tene Features wie automatische Baudratendetektion oder spezielle Debug Register sind ebenfalls nicht geplant Die Implementation eines Halbduplexmodus ist dar berhinaus nicht vorgesehen da der Halbduplexbetrieb d
79. t im Entwurf und die gr tm gliche Spezifit t in der zur entwerfenden Hardware zu gew hrleisten ist es essentiell die jeweiligen Einzelkomponenten konfigurierbar und flexibel zu halten Da die aktuell in LavA integrierte UART Komponente diesen Anspruch noch nicht erf llen kann soll sie in dieser Arbeit erweitert werden Um mit der LavA Plattform ein MP SoC zu entwickeln muss zun chst auf der Grundlage eines Metamodells ein konkretes Modell der Hardware entworfen werden Dieses Modell wird mit Hilfe der Template sprache Xpand 6 7 in eine Spezifikation f r die XML basierte Konfigurationssprache XVCL 8 transformiert aus der dann der letztendliche Code erzeugt wird Besonders bei komplexeren Entw rfen zeigt sich hier allerdings ein Problem Die Lesbarkeit der XML Dokumente die f r die Konfiguration ber XVCL erzeugt werden m ssen ist aufgrund ihrer Gr e und Komplexit t stark eingeschr nkt Dies hat einen nachhaltig negativen Einfluss auf die Wartbarkeit des Systems Die Neuentwicklung einer Komponente bie tet sich dabei an um konzeptionell zu berpr fen inwiefern XVCL aus dem Workflow herausgel st und komplett durch Xpand ersetzt werden kann 1 2 Ziele der Arbeit Ziel dieser Arbeit ist es zun chst ausgehend von der aktuell in LavA vorhandenen stati schen UART Komponente einen hoch konfigurierbaren UART in VHDL zu entwickeln Zu diesem Zweck wird anfangs eine Dom nenanalyse durchgef hrt um den sp teren Funktions
80. tasheet http www nxp com documents data_sheet LPC2377_78 pdf Version 2010 NXP Semiconductors LPC23XX User manual http www keil com dd docs datashts philips lpc23xx_um pdf Version 2009 Microchip Technology Inc Microchip PIC32 Family Reference Manual Section 21 UART http ww1 microchip com downloads en DeviceDoc 61107F pdf Version 2010 62 8 2 Literaturverzeichnis 26 27 28 29 WITT Sebastian UART16750 http www opencores org project uart16750 Version 2011 GORBAN Jacob MOHOR Igor MARKOVIC Tadej UART 16550 core http www opencores org project uart16550 Version 2010 Wikipedia RS 232 http de wikipedia org wiki RS 232 Version August 2011 Digilent Inc Digilent Virtex 5 OpenSPARC Evaluation Platform http www digilentinc com Products Detail cfm NavTop 2 amp NavSub 599 amp Prod XUPV5 Version August 2011 63 Abbildungsverzeichnis 2 1 2 2 2 3 2 4 2 9 3 1 3 2 3 3 3 4 3 9 3 6 4 1 4 2 4 3 5 1 5 2 6 1 6 2 6 3 6 4 6 5 6 6 7 1 G2 Beispiel f r ein x framework 12 cas E A Berner 7 Das Hardware Metamodell in LavA 8 Die Hardware Konfiguration der LavA Plattform 2 9 Der Aufbau der urspr nglichen LavA UART Komponente 10 Beispiel eines Merkmaldiagramms Quelle 18 11 Beispiel f r einfache Expressions o nn nn 13 Beispiel f r eine rekursive Extension
81. technische universitat dortmund Bachelorarbeit Beispielhafte Entwicklung einer Hardwareproduktlinie anhand einer UART Familie Jan Michael Dworschak 23 August 2011 Betreuer Prof Dr Ing Olaf Spinezyk Dipl Inf Matthias Meier Technische Universit t Dortmund Fakult t f r Informatik Lehrstuhl Informatik 12 Arbeitsgruppe Eingebettete Systemsoftware http ess cs tu dortmund de Hiermit versichere ich dass ich die vorliegende Arbeit selbstst ndig verfasst keine anderen als die angegebenen Quellen und Hilfsmittel verwendet sowie Zitate kenntlich gemacht habe Dortmund den 23 August 2011 Jan Michael Dworschak Zusammenfassung Diese Arbeit besch ftigt sich mit der Entwicklung einer hoch konfigurierbaren UART Produktfamilie im Kontext des LavA Projekts der TU Dortmund Die LavA Plattform bietet einen Workflow zur anwendungsspezifischen Generierung von MPSoCs Multi processor Systems on Chip Ziel der Arbeit ist es zun chst die aktuell vorhandene statische UART Komponente um umfangreiche Konfigurationsm glichkeiten zu erwei tern Weiterhin wird exemplarisch versucht XVCL aus dem Workflow zu eliminieren und die Codegenerierung ausschlie lich mit Hilfe von Xpand Templates zu durchzuf hren Im ersten Teil der Arbeit werden im Rahmen einer Dom nenanalyse verschiedene UART L sungen im Hinblick auf ihren Funktionsumfang betrachtet Anhand der hier gewonnenen Erkenntnisse wird im Folgenden der Funktionsumfang
82. umfang des UART abzustecken Auf der Grundlage dieser Analyse soll dann ein Blockdiagramm entstehen nach dem der UART in VHDL implementiert werden kann Um den UART in LavA zu integrieren soll daraufhin eine Bibliothek von Funktio nen f r das Betriebssystem implementiert werden die es erm glicht die neuen Features haupts chlich die Konfiguration im Betrieb auszunutzen Bez glich der Konfigurations m glichkeiten wird anstelle der sonst in LavA verwendeten Konfiguration ber XVCL soweit m glich ausschlie lich Xpand verwendet Das so entstandene System soll abschlie Bend nach Skalierbarkeit der VHDL Komponente und Lesbarkeit bzw Komplexit t der Xpand Templates evaluiert werden 1 3 Gliederung der Arbeit Im zweiten Kapitel werden zun chst einige im Kontext dieser Arbeit wichtige Grund lagen der modellgetriebenen Hardwareentwicklung betrachtet Darunter finden sich das LavA Projekt der TU Dortmund aber vor allem auch das Konzept der Hardwarepro duktlinien und die Templatesprache XVCL Das dritte Kapitel befasst sich im Anschluss mit Technologien die im Laufe der Arbeit zur Entwicklung der UART Familie verwen det werden Dazu z hlen die Templatesprache Xpand und die verwandten Sprachen Xtend und Check sowie Konfigurationsmittel von VHDL Das vierte Kapitel beschreibt die grundlegende Dom nenanalyse die die Basis f r Entwurf und Implementation des UART bildet Das f nfte Kapitel erl utert den Entwurfsprozess und die Spezifikatio
83. undlagen 2 5 Merkmalmodelle Merkmalmodelle 17 stellen neben Abgrenzungen der Dom ne nach au en Definitio nen von speziellem Vokabular und Konzeptmodellen UML Klassendiagramme ER Diagramme oder hnliches einen wichtigen Bestandteil eines Dom nenmodells dar Ein Merkmalmodell selbst besteht aus einem Merkmaldiagramm in Verbindung mit textuel len Beschreibungen und weiteren Einschr nkungen oder Implikationen beispielsweise zur Erl uterung einer Widerspr chlichkeit zwischen zwei Knoten eines Diagramms Abbil dung 2 5 zeigt ein Beispiel f r ein Merkmaldiagramm Syntaktisch stellt ein Merkmaldia Car body Transmission Engine Pulls trailer Automatic Manual Electric Abbildung 2 5 Beispiel eines Merkmaldiagramms Quelle 18 gramm einen gerichteten azyklischen Graphen dar dessen Wurzel die zu beschreibende Produktfamilie oft auch als Konzept bezeichnet repr sentiert Die Kinder eines Kno tens sind seine Merkmale dabei deutet eine Kante mit ausgef lltem Kreis am Ende ein verpflichtendes Merkmal und eine Kante mit nicht ausgef lltem Kreis ein optionales Merkmal an Im Beispiel muss jedes Auto eine Karosserie ein Getriebe und einen Motor haben w hrend ein Anh nger optional bleibt B gen zwischen zwei Kanten zeigen an dass die durch den Bogen verbundenen Merkmale eine Gruppe bilden Ein einfacher Bo gen bedeutet dass die Gruppe eine Reihe von Alternativen darstellt Jede
84. ungen speichert Die Interrupts sollen sowohl global als auch separat aktiviert und deaktiviert werden k nnen Weiterhin soll es m glich sein diesen Interrupts verschiedene Priorit ten zuzu ordnen Die Verwaltung der Priorit ten und entsprechende Behandlung der Interrupts wird hierbei der Treibersoftware berlassen um m glichst einfach eine benutzerdefinierte Priorisierung zu erm glichen 5 1 3 Pufferung Bez glich der Pufferung von Daten soll der UART f r die Sender und Empf ngereinheit FIFO Puffer mit variabler Gr e unterst tzen Eine explizite Pufferung von aufgetrete nen Interrupts ist nicht vorgesehen wird aber teilweise durch den Einsatz des Interrupt Statusregisters realisiert da zumindest ein Interrupt jeder Art gleichzeitig gespeichert bleibt 30 5 3 Entwurf des UART 5 2 Umsetzung der Konfigurationspunkte Nachdem der Funktionsumfang festgelegt ist bleibt noch die Entscheidung welche der Konfigurationsm glichkeiten im Betrieb und welche nur zur Instanziierungszeit bestimmt bar sein sollen Grunds tzlich ergibt es Sinn Konfigurationspunkte die direkten Einfluss auf die Ressourcenbelegung auf dem FPGA haben zur Instanziierungszeit festzulegen Komponenten ber die Ressourcen gespart werden k nnen wenn sie nicht ben tigt werden sind auf oberster Ebene die Transmitter und Receiver Einheiten Wird eine der beiden Funktionalit ten nicht ben tigt so k nnen gro e Teile der Architektur von vorn he
85. ungen unterst tzt und diese auch aktiviert sind Da jeder UART eine Form von Kommunikation ausf hrt sei es Senden oder Emp fangen ist es obligatorisch dass die Parameter dieser Kommunikation festgelegt sind Die Details der Kommunikation sind daher im folgenden Subdiagramm dargestellt Ein UART kann zun chst einen synchronen Kommunikationsmodus bieten Dieser ist als optional markiert da nicht alle betrachteten Ger te diese F higkeit haben Eine weitere optionale F higkeit besteht im Anbieten einer Schnittstelle f r Hardwareflusskontrolle Von den meisten Ger ten wird eine einfache Flusskontrolle ber die Signale RTS ready to send und CTS clear to send angeboten Besonders f r den Betrieb in Kombination mit einem Modem w re allerdings eine weitreichendere Flusskontrolle angebracht Jeder UART muss eine bestimmte Symbolrate unterst tzen Bei allen betrachteten besonders bei NS16550 kompatiblen Ger ten war die Baudrate im Betrieb ber ein Register kon figurierbar in das ein Teilungsfaktor f r den Systemtaktgeber eingetragen werden muss 24 Analyse 4 3 997 1933 11 Q Q SD a j91s1uuyos Q uogeyiunwwoy n sa oa Va ajlaasm uyag 9 9 1848 4 Abbildung 4 1 Merkmalmodell f r einen UART 25 4 3 Analyse el Led Ld Lel ts Le Ler g ereen Laag N d V man mm v CC Le ome Dale Fre E Q V WV s19 513 usyayZ dueygesdungydiy ayeupneg
86. ur Modellierungszeit dem Zweck dient durch das Auslassen nicht ben tig ter Komponenten Ressourcen einzusparen Aus dieser Aufteilung wurde zun chst ein Metamodell f r die Ma schneiderung von UARTs innerhalb des Eclipse Projekts ent worfen Anschlie end wurden verschiedene VHDL Module abgeleitet und f r den Ver bund dieser ein Blockschaltbild als Grundlage der Implementation entworfen Die drei wesentlichen interagierenden Module des UART sind die RX Einheit Empf nger die TX Einheit Sender und die koordinierende Steuereinheit die die Konfigurationspara meter sowie Ein und Ausgaben verwaltet Die fertiggestellten VHDL Module wurden dann in Xpand Templates eingebettet und erweitert um Constraints und Extensions dem Generierungsprozess innerhalb des Eclipse Projekts zug nglich gemacht Bei der Modellierung eines UART mit dem entstandenen Projekt ist es so m glich unterschied liche Varianten mit Sender und oder Empf nger zu erstellen Au erdem k nnen bei Bedarf FIFO Puffer Interruptfunktionen oder Parit tsunterst tzung hinzukonfiguriert werden Im Betrieb k nnen die Baudrate Kommunikationsformat und Interruptakti vierung ge ndert werden Nach Abschluss der Implementierung wurde das entwickelte System in Kapitel 7 analysiert und die Ergebnisse bewertet Die Analyse des Ressour cenverbrauchs ergab dass der implementierte UART durchaus merklich mit dem jeweils gew hlten Funktionsumfang skaliert Letztlich war die Frage zu kl ren o
87. vA Projekt Das LavA Projekt zielt auf das Co Design bzw die Co Konfiguration der Hardware beschreibung eines Systems und passender Betriebssystemsoftware ab Da die im Ver lauf dieser Arbeit zu entwickelnden Komponenten Teil der Hardwareschicht der LavA Plattform sind und eine Weiterentwicklung des Hardware Konfigurationsprozesses un tersucht wird soll das Augenmerk hier haupts chlich auf diesem Teil des LavA Workflows liegen Es sei aber angemerkt dass es sich hierbei keinesfalls um den Gesamtumfang der LavA Plattform handelt Wie bereits im vorangehenden Kapitel angedeutet handelt es sich bei LavA um eine Plattform zur anwendungsspezifischen Ma schneiderung von MP SoCs Besonders im Vordergrund steht dabei die Komplexit t und Fehleranf lligkeit des typischen Entwicklungsprozesses zu reduzieren LavA erreicht dies durch Anwendung zweier zentraler Konzepte der Softwareentwicklung Das sind zum einen ein modell getriebener Entwicklungsansatz unter Verwendung diverser Elemente aus dem Eclipse Modeling Framework EMF 14 und zum anderen die gezielte Wiederverwendung von Hardware und Softwarekomponenten 12 2 4 1 Hardwarekonfiguration in LavA Der Ausgangspunkt eines neuen Entwurfs in LavA ist das Metamodell Das Metamodell ist in Abbildung 2 2 dargestellt Es beschreibt die grunds tzliche Architektur die jedem mit LavA entwickelten Hardwaresystem zugrunde liegt Ein MPSoC besteht demnach MPSOC enumeration enumeration
88. verwendung eignet Die Komponente ist unter GNU LGPL lizenziert Strukturell ist der Puffer ber zwei generic Parameter in Wortbreite und Gr e konfigurierbar F r den in dieser Arbeit entwickelten UART wird dabei allerdings nur die variable Gr e genutzt und die Breite konstant als 9 angenommen da dies die maximal ben tigte Wortbreite ist und die automatisierte Codegenerierung so erleichtert wird Intern verwaltet der Pufferspeicher eine Matrix von n mal m Bit wobei n die Gr e des Puffers und m die Wortbreite ist Zus tzlich werden zwei Variablen als Lese und Schreibadresszeiger verwendet Als Steuersignale besitzt der Puffer reset clear read und write als Ausgaben bietet er den F llstand sowie Signale f r die Ereignisse voll und leer Die Funktionalit t des Puffers ist in drei Prozesse aufgeteilt von denen der erste Prozess die Adressoperationen erledigt Beide Adress zeiger starten bei 0 und werden bei einer Lese oder Schreibanweisung entsprechend inkrementiert Da beide Adressvariablen als vorzeichenlose Bin rzahlen modelliert sind Iniedrigstwertiges Bit 40 6 1 Implementation sorgt der Uberlauf beim Inkrementieren automatisch f r eine zyklische Adresszuweisung Dieser Prozess ist auch f r die Zuweisung des empty Signals zust ndig da der Zustand leer offensichtlich genau dann gegeben ist wenn beide Adresszeiger denselben Wert haben Der zweite Prozess sorgt f r das Schreiben der Eingabedate
89. zgr nden in ein Hauptdiagramm und zwei Subdiagramme Die Subdiagramme besch ftigen sich dabei auf der einen Seite mit der Kommunikation und dem Format dieser auf der anderen Seite mit der Behandlung von Interrupts Im Hauptdiagramm ist zun chst abzulesen dass jeder UART eine parallele und serielle Schnittstelle besitzen muss Da es die Hauptaufgabe eines UART ist serielle und parallele Daten in beide Richtungen zu bersetzen w re das Modul andernfalls auf einer Seite abgetrennt und k nnte seine Arbeit nicht verrichten Insgesamt gibt es verschiedene M glichkeiten f r parallele respektive serielle Schnittstellen diese sind allerdings im Diagramm als Alternativen aufgetragen um deutlich zu machen dass zu einer Zeit nur eine aktiv sein kann Weiterhin muss jeder UART mindestens eine Receiver oder Transmittereinheit oder beides besitzen Es sind F lle denkbar in denen ein UART nur f r den Empfang oder nur zum Senden von Daten ben tigt wird weshalb nicht beide notwendig sind Keines der beiden Elemente zu haben w re aber aus naheliegenden Gr nden nicht sinnvoll Sowohl die Empf ngereinheit als auch der Sender k nnen mit FIFO Puffern ausgestattet sein die eine feste Gr e haben Im Falle des Empf ngers ist es au erdem n tig einen Trigger Level anzugeben bei dem ein Interrupt ausgel st wird um zu signalisieren dass Daten zur Abholung bereit sind Dies gilt selbstverst ndlich nur f r den Fall dass das Ger t Hardwareunterbrech
90. zung Sowohl XVCL als auch Xpand bieten ein Eclipse Plugin als Arbeitsumgebung an set zen dabei aber unterschiedliche Schwerpunkte Zwar bieten beide Editoren Quellcode Highlighting und Auto Vervollst ndigung aber w hrend die XVCL Workbench eher auf die Automatisierung der Frameentwicklung und Refactoring ausgerichtet ist bietet die Xpand Arbeitsumgebung eine Schnittstelle zu anderen Modellierungselementen der Eclipse MWE und versucht den Codegenerierungs Workflow sowie das Zusammenspiel der einzelnen Komponenten zu erleichtern 7 3 2 Eignung von Xpand Die wesentlichen Kritikpunkte an XVCL sind zum einen die schlechte Lesbarkeit der x Frames die deutlich nachteilige Auswirkungen auf die Wartbarkeit des Quellcodes hat zum anderen aber auch die eingeschr nkte Ausdrucksst rke der Sprache die dazu f hrt dass oft sehr umst ndliche Konstrukte entwickelt werden m ssen um verh ltnism ig einfache Ausdr cke zu formulieren Erschwerend kommen au erdem inh rente Probleme von Standard XML wie die fehlende Typisierung von Variablen oder auch die Kodierung von Sonderzeichen hinzu Xpand hat hier gewisse Vorteile besitzt aber bez glich der Formatierung von Templates und Ausgabedateien ebenfalls einige Nachteile Gerade angesichts der Tatsache dass die aktuelle Variante in der die Generierung eines SPC f r XVCL durch Xpand bernommen wird aber einen zus tzlichen Aufwand bedeutet und XVCL keine Funktionen bietet die Xpand nicht auch be

Mustertitel titel Muster - Embedded System Software Group

Contents

Download Pdf Manuals

Related Search

Related Contents