RSS
Twitter
ARM Call for Papers
Die große Konferenz für ARM-Systementwicklung am 11. und 12. Juli 2012 in München bietet Entwicklern die Gelegenheit, sich detailliertes Wissen über die aktuellen Cortex-Architekturen anzueignen, die mittlerweile zum Industriestandard avanciert sind.
Ausführliche Informationen:
www.arm-entwicklerkonferenz.de
iPad 3 Teardown & Light+Building
Mit dem Lava Xolo X900 gibt es erstmals ein Smartphone, das auf einem Atom-Prozessor von Intel basiert. Kann das mit ARM mithalten? Wir haben das untersucht.
Mit dem Cortex-M0+ hat ARM im März den kleinsten 32-bit-Core der Welt vorgestellt. Wir haben ihn uns einmal genauer angeschaut.
Der Tegra-3 von Nvidia ist der erste Quad-Core-Prozessor für Smartphones und Handys - ganz aktuell im neuen Galaxy S3. Doch bringen vier Kerne im Smartphone überhaupt etwas?
Ein Blick in dass Innenleben des gemeinsam von Google und Samsung entwickelten Smartphones.
Zahlreiche Hersteller bieten im Netz Online-Tools, zeitlich begrenzte Testversionen oder ganze Programmme zum Download an. Wir haben eine kleine Auswahl davon zusammengestellt.
Produkte des Jahres 2012
Events
Marktübersichten Bauelemente
Wer bietet was?
Schnelle Information auf einen Klick!
Electronic WebLessons
Die Electronic WebLessons vermitteln multimedial aufbereitet Basiswissen zum Thema Elektronik. Hier können Sie ihr Praxiswissen auffrischen oder sich die Grundlagen der Elektronik neu aneignen.
Brüche im Umbruch
Entwurf von Signalverarbeitungssystemen
Diskontinuitäten im Designflow stellen ein zunehmendes Problem für die Entwicklung komplexer Signalverarbeitungs- und Kommunikationsverfahren dar, weil sie die Entwicklungskosten erhöhen. Durch immer kürzere Entwicklungszyklen verstärken sich die Folgen dieser Diskontinuitäten noch. Die geschickte Kombination vorhandener Entwurfsverfahren kann dabei helfen, HF- und Basisband-Systeme, aber auch vollwertige Mehrfrequenz-Architekturen »bruchlos« zu entwickeln.
Anzeige
Recht häufig beginnt die Entwicklung von Signalverarbeitungs- und Kommunikationsalgorithmen mit einer Fließkomma-Darstellung in »Matlab«.
Im Anschluss erfolgt häufig der Bruch im Designflow: Oft setzen die Entwickler diese Algorithmen komplett neu in C-Code um, um sie etwa für die Implementierung zu verfeinern, in Festkomma- oder Ganzzahl-Arithmetik umzuwandeln oder mit anderen Systemelementen zu integrieren.
Über eine Matlab-Erweiterung namens »System Objects« können Entwickler Modelle von Signalverarbeitungssystemen für Streaming-Anwendungen direkt in Matlab entwerfen.
Diese stellt mehrere hundert Bibliothekskomponenten für die Signalverarbeitung, die Bild- und Videoverarbeitung und die Kommunikation zur Verfügung. Beispielhaft sei ein übliches Kommunikationssystem mit Sender-, Kanal- und Empfängerkomponenten (Bild 1) angeführt. Zur Modellierung und Simulation eines solchen Systems schreiben viele Entwickler mehrere tausend Zeilen C-Code und suchen dann nach Wegen, ihren Entwurf mit ihrer Testausrüstung zu inte-grieren oder die Simulationsergebnisse zu analysieren.
Für die Lösung der gleichen Aufgabe bedient sich Matlab-Code, wie in Bild 2 gezeigt, verschiedener vorgefertigter System-Objects aus dem »Signal Processing Blockset« (SPB) sowie dem »Communications Blockset« (CB). Zur Modellierung des Senders wählt der Entwickler hier aus dem CB die System-Objects für den Reed-Solomon-Encoder, den Faltungs-Encoder, den Block-Interleaver, den Rectangular-QAM-Modulator und den Orthogonal-Space-Time-Blockcodierer aus, die nacheinander instanziiert und aufgerufen werden.
Im Gegensatz zu konventionellen funktionalen Programmierstilen stellen die System-Objects objektorientierte Implementierungen von Algorithmen dar. Sie übernehmen implizit die gesamte Indizierung, Pufferung und Zustandsverwaltung und vereinfachen dadurch erheblich das Schreiben, Debuggen und Pflegen des Codes. Aufgrund seiner Struktur lässt sich solcher Code problemlos mit der ursprünglichen Spezifikation oder dem Blockdiagramm vergleichen.
Algorithmenentwickler können diesen Code mit wenig Zeitaufwand mit bereits vorhandenem Matlab-Code verbinden und dann ihre Algorithmen mit Live-Daten von Messinstrumenten testen. Mit System-Objects programmierte Algorithmen können die Wiederverwendbarkeit von Code während des Entwicklungsprozesses verbessern. So lässt sich etwa Fließkomma- oder Festkomma-Matlab-Code direkt in »Simulink«-Modelle einbauen und damit zum Architekturentwurf sowie zur Modellierung und Entwicklung von Systemen nutzen. Aus Matlab-Code, der System-Objects enthält, lässt sich automatisch C-Code generieren und dieser nach geeigneter Verifikation zur gemeinsamen Simulation oder Integration mit anderen in C/C++ geschriebenen Systemelementen einsetzen.
HF- und digitale Architekturen
Ein typischer erster Schritt auf dem Weg zur Entwicklung von HF-Entwürfen nach LTE-, Bluetooth-, ZigBee-, WLAN- und anderen technischen Spezifikationen ist die Berechnung des statischen Kanalgewinns. Diese Berechnungen sind zwar ein guter Anhaltspunkt, lassen aber die Modulation der Eingangssignale, Spiegeleffekte und andere unter Realbedingungen auftretende Phänomene völlig außer Acht.
Um die Einflüsse realistischer HF-Störungen auf Kommunikationssysteme effektiv modellieren und simulieren zu können, müssen Systemarchitekten momentan mit vielen unzusammenhängenden Tools arbeiten, die entweder digitale Entwürfe oder Analog/HF-Entwürfe unterstützen, nicht aber beides.
»SimRF« ist ein neues Werkzeug für Circuit-Envelope-Simulationen, mit dem sich die Mehrfrequenzdynamik von HF-Empfängern oder Dreitor-Komponenten, etwa Mischern, simulieren lässt. SimRF und Simulink bieten somit eine Umgebung, in der man HF- und Basisband-Subsysteme in einem einzigen Entwurf gemeinsam modellieren und simulieren kann.
In dieser Umgebung können Systemarchitekten bereits zu Beginn des Entwicklungsprozesses realistische Simulationen durchführen und erhalten Hilfe bei Trade-off-Entscheidungen für Entwürfe, die digitale und analoge/HF-Komponenten nebeneinander enthalten. Bild 3 zeigt ein Systemmodell eines ISM-Empfängers (Industrial, Scientific and Medical) mit niedriger Zwischenfrequenz, das sowohl die Komponenten zur digitalen Signalverarbeitung als auch die für das HF-Empfänger-Subsystem enthält.
Zusätzlich hervorgehoben sind die Details des Subsystems mit einem Hartley-IF-Empfänger (Intermediate Frequency; Zwischenfrequenz).
Anders als bei konventionellen Methoden zur Modellierung von IF-Empfängern, bei denen Kaskaden aus Zweitor-Elementen sowie Einzelfrequenz-Näherungen eingesetzt werden, vereinfacht hier die Nutzung von Dreitor-Komponenten das Empfängermodell.
Das Modell nutzt außerdem die Simulation mit Circuit-Envelope-Methoden und unterstützt die Mehrfrequenz-Modellierung. Darüber hinaus können Systemarchitekten die Realisierbarkeit und die relativen Vorteile alternativer Methoden zur Unterdrückung von Spiegelfrequenzen wie etwa Superheterodyn- oder Direktmisch-Architekturen studieren (Bild 4).
Außer zur Simulation der Einflüsse von HF-Störungen lassen sich dieselben Systemmodelle zudem dazu einsetzen, Verifikationsaufgaben im Rahmen von Simulation vorzunehmen, die sonst typischerweise im Labor stattfinden würden.
Hardwareentwurf
Nach der Fertigstellung der Algorithmen und der Systemarchitektur bestehen in vielen Entwicklungszyklen die nächsten Schritte in der FPGA-Implementierung und der Verifikation der digitalen Anteile.
Die zentrale Schwachstelle beim Prototyping und der Implementierung in FPGAs sind die zeitaufwändigen Entwurfsiterationen, die notwendig sind, um die richtige Balance zwischen Leistungsaufnahme, Systemleistung und Chipfläche zu ermitteln.
Bild 5 zeigt ein mit Festkomma-Arithmetik implementiertes symmetrisches FIR-Filter (Finite Impulse Response).
Um ein solches Filter in Hardware zu realisieren, müssen die Entwickler dessen Durchsatz und Latenz sorgfältig gegeneinander ausbalancieren und dabei immer die jeweils benötigten Hardware-Ressourcen im Auge behalten.
Die automatische Hervorhebung des kritischen Pfades ist eine neue Fähigkeit, mit der sich Information zu potenziellen Systemengpässen gewinnen und direkt in Lösungswege übersetzen lässt.
Der »Simulink HDL Coder« nutzt die vom Synthesetool »ISE« von Xilinx erzeugte Information im Anschluss an die Synthese dazu, alle kritischen Pfade mit deren individuellen Latenzen zu kennzeichnen. Verknüpft man diese Information mit Pipelining-Methoden, lassen sich der Entwurf und damit die Latenzzeiten seiner kritischen Pfade partitionieren.
Bild 6 zeigt das Filter aus Bild 5, nur sind hier die kritischen Pfade automatisch hervorgehoben und mit den geschätzten Latenzen für jedes Pfadsegment versehen.
Wie bereits erwähnt ist das Pipelining eine der wichtigsten Methoden, um die Latenzproblematik in kritischen Pfaden zu lösen.
Eine bekannte Schwierigkeit beim Pipelining ist allerdings, dass parallele Pfade nicht unbedingt auch gleiche Latenzen besitzen, was unerwartetes oder unerwünschtes Systemverhalten verursachen kann.
Eine häufig genutzte Lösung hierfür ist das verteilte Pipelining. Diese Methode lässt sich nun auch automatisieren. Durch die Auswahl dieser Option können Ingenieure ein Modell automatisch resynchronisieren und alle Latenzen austarieren, die von den Pipeline-Registern über sämtliche relevanten parallelen Pfade erzeugt worden sind.
Früher waren diese Arten von Entwurfsiterationen und Trade-off-Abschätzungen mit viel Zeitaufwand und Mühe verbunden.
Bild 7 zeigt einen neuen »Workflow Advisor«, mit dessen Hilfe Iterationen schneller und intuitiver vorgenommen werden können.
Von besonderem Wert ist er für Entwickler, die keine Experten für die Programmierung in HDLs (Hardware Description Language, Hardware-Beschreibungssprache) sind, aber FPGAs als Prozessoren einsetzen müssen.
Über das »Critical Path Highlighting« und das verteilte Pipelining hinaus lässt sich zur Auswertung außerdem automatisch ein Bericht über die genutzten Ressourcen generieren (Bild 8).
Mit diesem Bericht lassen sich Art und Anzahl der im jeweiligen Entwurf benötigten kritischen Hardwarekomponenten überwachen und die beste Architekturwahl für eine gegebene Situation ermitteln.
Dies geschieht dadurch, dass Iterationen rasch hintereinander für verschiedene in Frage kommende Entwurfsoptionen vorgenommen werden können.
Über den Autor:
Dr. Arun Mulpur ist Industry Marketing Manager Communications, Electronics, Semiconductors bei The MathWorks.
