12.12.2007 | Autor / Redakteur: Mike Woodward* / Jan Vollmuth
Steigende technische Anforderungen und wachsender Wettbewerbsdruck stellen die Entwickler von Wireless-Systemen vor besondere Herausforderungen. Modellbasiertes Design hilft, typische Entwicklungsprobleme zu vermeiden und gleichzeitig die die Entwicklungszeiten und -kosten reduzieren.
Technische und wettbewerbsspezifische Zwänge erschweren die termingerechte und profitable Entwicklung von Wireless-Systemen immer mehr: Wireless-Standards sind zunehmend komplex [1], aktuelle Geräte müssen mehrere Standards gleichzeitig unterstützen. Gleichzeitig sehen sich die Hersteller mit einer verstärkten Konkurrenz durch Neueinsteiger in den Markt konfrontiert.
Die Profitabilität ist auf dem Markt für Wireless-ASICs ist daher ausschließlich eine Frage des First Mover-Vorteils [2]. Der International Technology Roadmap for Semiconductors (ITRS) zufolge stellen die Entwicklungskosten die größte Bedrohung für eine kontinuierliche Fortsetzung der Halbleiter-Roadmap dar [3].
Unglücklicherweise verschärfen einige der in der Halbleiterbranche etablierten Entwicklungsverfahren das Problem eher, als Lösungen anzubieten. Die Tabelle gibt eine Übersicht über die größten Hürden im Entwicklungsprozess sowie die wichtigsten Gründe, warum Unternehmen an deren Überwindung scheitern.
Der Einsatz eines Entwicklungsprozesses, der diese häufig auftauchenden Entwicklungsprobleme gezielt vermeidet, verbessert nicht nur die Produktqualität und Time-to-Market, sondern führt auch zu einer produktiveren Nutzung der vorhandenen Ressourcen. Die Veränderung etablierter Design-Flows birgt aber auch Risiken. Um diese Risiken im Griff zu behalten, sollten neue Ideen oder Konzepte grundsätzlich mit dem vorhandenen Design-Flow kompatibel sein (Evolution statt Revolution). Eine Hilfe dabei ist das modellbasierte Design (Model-Based Design), das sich in vorhandene Entwicklungsprozesse integrieren lässt und so die Produktqualität verbessert und zu reduzierten Entwicklungszeiten und -kosten beiträgt.
Im Mittelpunkt des modellbasierten Designs steht ein ausführbares Systemmodell, das als Grundlage für sämtliche Aktivitäten dient, die in den vier verschiedenen Stadien des Entwicklungsprozesses stattfinden (Bild 1). Dasselbe Systemmodell fungiert gleichermaßen als ausführbare Spezifikation, als Ausgangsbasis für die Systementwicklung, als Grundlage für die Codegenerierung und als Tool für kontinuierlich durchgeführte Tests und die durchgängige Design-Verifikation.
Ein Modell sollte in der immer gleichen Form durch den gesamten Entwicklungsprozess hindurch verwendet werden. Damit wird vermieden, dass die gleiche Arbeit in unterschiedlichen Phasen mehrfach durchgeführt wird. Die Entwicklungsumgebung muss dazu unbedingt eine Mehrdomänen-Simulation ermöglichen, so dass digitale, analoge und HF-Komponenten im gleichen Modell simuliert werden können.
Diese Forderung lässt sich beispielsweise mit C/C++-Modellen nur schwer erfüllen, ohne dass die Entwickler zunächst eine eigene Simulationsfähigkeit für das HF-Design aufbauen. Voraussetzung für Model-Based Design ist darum der Einsatz einer so genannten COTS-Lösung (Commercial Off The Shelf) wie etwa Simulink als Entwicklungs- und Simulationsumgebung. Die zentrale Idee dabei ist das strikte Trennen der Entwicklungs- und Simulationsumgebung vom Systemmodell. Auf diese Weise konzentriert sich die Entwicklungsarbeit ausschließlich auf das Modell und nicht auf den Aufbau einer geeigneten Tool-Umgebung.
|
| Bild 2: Modellbasiertes Design erfordert eine COTS-Lösung (Commercial Off The Shelf), die die Entwicklungs- und Simulationsumgebung strikt vom Systemmodell trennt |
Eine ausführbare Spezifikation ist eine auf der Systemebene formulierte Spezifikation – also nichts anderes als ein Systemmodell – die ausgeführt wird und dabei Ergebnisse produziert, die eine Erfüllung der Anforderungen durch die Spezifikation beweisen [5]. Anstatt die Anforderung auf Papier festzuhalten, z.B. dass die Frame-Error-Rate (FER) bei einem bestimmten Signal/Rauschverhältnis (SNR) einen bestimmten Grenzwert nicht überschreiten darf, bauen die Entwickler eine Spezifikation (ein Systemmodell) auf, die mit dem festgelegten SNR betrieben wird und eine FER unterhalb des Grenzwertes erzielt – und beweisen damit automatisch, dass die Spezifikation technisch erfüllbar ist (Bild 2). Laut Schätzungen der ITRS erhöht die Verwendung ausführbarer Spezifikationen die Produktivität von Entwicklungsprozessen um etwa 100 bis 200% [3].
Da eine ausführbare Spezifikation dem Namen nach ausführbar ist, kann ein Ingenieur an ihr eine deutlich größere Spannbreite an Eingaben, Ausgaben und Betriebsbedingungen ausprobieren, als in einer schriftlichen Spezifikation aufgeführt werden können. Dies eröffnet ihm beispielsweise die Möglichkeit, unterschiedliche Kanalmodelle auszuprobieren. Dank dieser Flexibilität lässt sich das geforderte Verhalten des Gesamtsystems deutlich umfassender beschreiben. Da die Spezifikation zudem jederzeit durch Tests prüfbar ist, werden außerdem Fehler viel früher im Entwicklungsprozess aufgedeckt [6].
Spezifikationen in Papierform durch ausführbare Modelle zu ersetzen oder zumindest zu ergänzen ist die direkte logische Folge dieser Betrachtungen; die tatsächlichen Vorteile des modellbasierten Designs kommen aber erst voll zum Tragen, wenn diese Modelle für verschiedene typische Tätigkeiten im Entwicklungsprozess eingesetzt werden.
Entwickler müssen Alternativentwürfe so schnell wie möglich miteinander vergleichen können. Will man jedoch die Architektur eines in C/C++ verfassten Systemmodells verändern, kann das sehr viel Zeit kosten, weil der Programmcode immer wieder neu kompiliert und verändert werden muss.
Im Gegensatz dazu sind COTS-Entwicklungsplattformen typischerweise grafisch orientiert, weshalb Modelle ohne Neukompilierung und ohne Veränderung an den Schnittstellen ihrer Komponenten rekonfiguriert werden können. Ein System lässt sich so sehr einfach in seine Einzelkomponenten aufspalten, die nun problemlos getrennt voneinander entwickelt werden können, was insbesondere für über räumlich getrennte Standorte verteilte Entwicklungsteams ein großer Vorteil ist.
Bei vielen COTS-Plattformen lässt sich dasselbe Modell sowohl für die Fließkomma- als auch die Festkommasimulation nutzen. Die Festkomma-Engine ist dabei die zu Grunde liegende Plattform. Schon diese Fähigkeit steigert die Produktivität erheblich, weil damit die Übersetzung des Entwurfs in die Festkommadarstellung praktisch entfällt. Die Entwickler können so die Festkommaleistung verschiedener Entwürfe eingehend testen, was bei auf C/C++ basierenden Projekten praktisch unmöglich ist.
Der vielleicht größte Nutzen des Einsatzes von Model-Based Design für die Entwickler ist die Fähigkeit, Trade-Offs domänenübergreifend zu betrachten und sofort die Auswirkung der Veränderung einer Komponente in einer Domäne auf das Gesamtsystem studieren zu können. Man könnte also beispielsweise ausprobieren, welchen Effekt der Einsatz eines preiswerteren analogen Leistungsverstärkers in Kombination mit einem digitalen Vorverzerrungsfilter hat. Mit anderen Methoden als modellbasiertem Design lässt sich ein solches Vorgehen auf der Systemebene nur schwer realisieren.
Aufgrund der genannten produktivitätssteigernden Eigenschaften lässt sich mit Model-Based Design also mehr als nur ein Entwurf ausgiebig untersuchen. Die Wahrscheinlichkeit steigt deutlich, das bestmögliche Design auszuwählen.
Eine besondere Stärke von Model-Based Design ist die Tatsache, dass eine ausführbare Spezifikation oder ein ausführbarer Entwurf zur Generierung des Codes für die Implementierung genutzt werden kann. Obwohl dieser Programmcode nicht immer so effizient ist wie manuell geschriebener Code, können die Ingenieure damit einen funktionsfähigen Prototypen erzeugen, ohne für das System nach jeder Änderung erneut Programmcode per Hand schreiben zu müssen. Außerdem verringert automatisch generierter Programmcode im Vergleich zu handgeschriebenem erheblich das Fehlerrisiko [7].
Natürlich kann man auch handgeschriebenen und automatisch generierten Programmcode gemeinsam einsetzen und so die Stärken beider Code-Typen kombinieren. Die bei Wireless-Projekten immer noch gängige Konvention, eine automatische Codegenerierung wegen Bedenken bezüglich der damit erzielbaren Geräteleistung möglichst zu vermeiden, verliert heute mehr und mehr an Bedeutung, weil die Codegenerierungs-Methoden ständig verbessert werden. Zudem werden die geforderten Designs immer komplexer, was die manuelle Programmierung eines kompletten Projekts zunehmend erschwert.
Beim modellbasierten Design werden Entwürfe auf einer hohen Abstraktionsebene formuliert, was sowohl das Testen als auch die Verifikation deutlich vereinfacht [8]. Genau genommen kann die hierbei verwendete ausführbare Spezifikation sogar schon erstmalig getestet werden, bevor sie vollständig fertiggestellt ist. Test und Verifikation ist also eigentlich keine abgesetzte Phase mehr, sondern eine begleitende Aufgabe während des gesamten Entwicklungsprozesses.
Model-Based Design bietet zudem Vorteile für die Verifikation. In der Industrie werden Modelle in großem Umfang als Prüfstand für Software, Hardware oder Processor-in-the-Loop-Tests eingesetzt [9]. Modelle lassen sich auch zur Erzeugung von Testvektoren nutzen und können sogar als so genannter Goldener Standard dienen, mit dem am Ende die Implementierung verglichen wird [8].
Verschiedene Hersteller von Testausrüstung wie etwa Agilent, Anritsu und LeCroy profitieren bereits von Model-Based Design, indem sie Entwicklungs- und Simulationssoftware in ihre Geräte mit einbauen.
Da Wireless-Projekte typischerweise viele gemeinsame Designelemente besitzen, kann das Wiederverwenden geistigen Eigentums (Intellectual Property, IP) einen erheblichen Beitrag zur Produktivitäts- und Qualitätsverbesserung leisten. Bislang standen dem Austausch von IP vor allem zwei Faktoren entgegen: Das Abstraktionsniveau des IP und die Art und Weise des Austausches. Auf der niedrigsten Abstraktionsstufe – etwa HDL-Code – kann IP zu spezifisch für die jeweilige Target-Plattform bzw. das Projekt sein, um an anderer Stelle wiederverwendet werden zu können.
Der Austausch von stark abstrahiertem IP (beispielsweise in Form von C/C++-Code) ist zwar deutlich geeigneter, wird aber durch Schnittstellenprobleme kompliziert. Verschiedene C/C++-Modelle können ganz verschiedene Schnittstellen besitzen, was den Austausch von IP zwischen ihnen erschwert. Und selbst dort, wo gemeinsame Schnittstellen und Entwurfsprinzipien fest vorgeschrieben sind, können Probleme durch eine unterschiedliche Interpretation der Vorschriften auftreten.
Um Modellkomponenten projekt-, team- oder sogar unternehmensübergreifend nutzen zu können, ist eine gemeinsame Simulationsplattform erforderlich. Diese gemeinsame Plattform stellt sicher, dass die für ein bestimmtes Modell entwickelten Bauteile sich in anderen Modellen wiederverwenden lassen. Modellbasiertes Design fordert die Entwickler explizit dazu auf, eine gemeinsame Entwicklungsplattform zu nutzen, woraus die grundsätzliche Wiederverwendbarkeit von IP die logische Folge ist.
Die profitable Entwicklung von Wireless-Systemen wird durch technologische und marktspezifische Trends zunehmend erschwert. Der dadurch entstehende Druck ist in den zurzeit etablierten Entwicklungsprozessen deutlich spürbar. Model-Based Design bietet hier eine Lösung in Form qualitativ hochwertigerer Produkte, kürzerer Entwicklungszeiten und niedrigerer Gesamtkosten an. Diese Vorteile werden mit einem geringen Risiko erkauft, da modellbasiertes Design problemlos zunächst in eine einzige Entwicklungsphase eingeführt werden und später schrittweise auf den weiteren Entwicklungsprozess ausgedehnt werden kann.
Literaturverzeichnis
[1] The Evolution of Hardware Platforms for Mobile „Software Defined Radio“ Terminals, Greifendorf D., Stammen J. und Jung P., PIMRC, 2002
[2] Return on Investment in Simulink for Electronic System Design, International Business Strategies, Inc., 2005
[3] International Technology Roadmap for Semiconductors-Design, 2005
[4] Return on Investment for Independent Verification & Validation – Phase 2B Final Report, Dabney J., NASA, 2004
[5] Executable Specs: What Makes One, and How Are They Used?, Schubert P.J. und Vitkin L., Winters F., SAE 2006
[6] Executable Specifications: Creating Testable, Enforceable Designs, Microsoft Research, 2001
[7] Caterpillar Automatic Code Generation, Thate J.M., Kendrick L.E. und Nadarajah S., SAE, 2004
[8] International Technology Roadmap for Semiconductors—Design, 2006 Update
[9] Cracking the Code Automatically, Ledin J. und Dickens M., EDN Europe, Juni 2005
*Mike Woodward ist Mitarbeiter von The MathWorks
Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 232477)
