-
BEREICH DER
ERFINDUNG
-
Die
vorliegende Erfindung betrifft ein programmierbares Ein-Chip-Bauelement
und insbesondere ein programmierbares Ein-Chip-Bauelement, das Breitbandsignale
handhaben kann, die beispielsweise mit Zellulartelefonie der dritten
Generation, drahtlosen Informationsgeräten, Digitalfemsehen und drahtlosen
LANs wie Bluetooth assoziiert sind. Ein Ein-Chip-Bauelement ist
ein Bauelement, das auf einem einzigen Halbleitersubstrat ausgeführt ist.
Darüber
hinaus betrifft sie eine Entwicklungsumgebung für ein solches Bauelement.
-
BESCHREIBUNG
DES STANDES DER TECHNIK
-
Herkömmliche
lineare Digitalsignalprozessoren (DSPs) haben eine geringe Zahl
an hochpräzisen Datenpfaden.
Dieser Prozessortyp ist zwar gut für schmalbandige Signalverarbeitung
(z.B. Audio, kapazitätsarmer
Digitalfunk) geeignet, ist aber für Signale mit höherer Bandbreite,
wie beispielsweise für Zellulartelefonie
der dritten Generation, Digitalfernsehen oder für drahtlose LANs, schlechter
geeignet. Bei solchen Systemen entstehen durch die Taskgruppen Modulation
und Demodulation, Kanaldecodierung und, in gewissem Ausmaß, Source-Codierung
und -Decodierung (z.B. wenn komplexe Videokompression eingesetzt
wird) sehr hohe lineare Zyklusbelastungen. Diese Gruppen erfordern
die Verwendung von inhärent
parallelen oder 'breiten' Algorithmen (z.B.
FFT, IFFT, Viterbi, digitale dezimierende Abwärtskonvertierung mit Filterung,
Despreading usw.), und diese ,breiten' Algorithmen lassen sich nicht gut auf
den schmalen' Parallelismus
abbilden, den herkömmliche
lineare DSPs bieten. Die Folge ist, dass sehr hohe Zyklusbelastungen
auf dem DSP-Substrat erforderlich sind, wenn die bekannten Vorteile
der Softwareimplementation erzielt werden sollen, und selbst mit
der neuesten Algorithmusgeneration sind sogar die schnellsten DSPs
noch nicht schnell genug. Es ist beispielsweise im Bereich der Drahtloskommunikationen
eine hinlänglich
anerkannte Tatsache, dass die Algorithmuskomplexität schneller wächst als
das Moore'sche Gesetz.
-
Die
Alternative zu einem DSP ist die Verwendung einer Form von kundenspezifisch
angepasster Gatterimplementation, um wenigstens eine Teilmenge der 'breiten' Algorithmen zu implementieren,
so dass die Möglichkeit
besteht, eine große
Zahl von Datenpfaden parallel auszuführen, so dass das eigentliche
Bauelement mit einer weitaus geringeren Gesamtrate getaktet werden
kann. Die Implementation von Floating-Point-Datenpfaden neigt jedoch dazu, im Hinblick
auf Gatter und HDL- (Hardware Description Language) Komplexität kostspielig
zu sein. Eine Synthese von Speicherzellen ist ebenfalls ineffizient.
Ferner ist die Steuerlogik, die zum Bearbeiten von konditionellem
Code erforderlich ist (z.B. die Form IF x DO y ELSE DO z), problematisch.
Wenn wir durch das Algorithmusspektrum gehen, angefangen bei Fixpunkt,
sehr iterativ, geringe Konditionalität, bis hin zu Floating-Point,
geringe Iteration, hohe Konditionalität, dann wird es immer effizienter,
eine Universalverarbeitungsmaschine zu implementieren und diese
dann mit Anweisungen und Daten zu füttern, anstatt die parallelen
Datenpfade ,fest zu codieren'.
-
In
den meisten Kommunikations- und Broadcast-Systemen bleibt man daher
gewöhnlich
bei einem herkömmlichen
DSP (zusammen mit einem kundenspezifischen Gatterteil), um die Präzisionsrechenfunktionen
auszuführen,
die linearere Abhängigkeiten
haben und somit nicht parallel ausgeführt werden können. Um
bei der Verwaltung von Ressourcen und schnellem E/A zu assistieren,
betreibt der DSP-Teil häufig
eine Form von Echtzeit-Betriebssystem
(RTOS) wie DSP BIOS, VxWorks, OSE, usw.
-
Schließlich, und
am anderen Ende der Skala, haben wir sehr geringzyklische Tasks
(wie z.B. Mensch-Maschinen-Schnittstellensteuerung (HMI) oder Durchlaufen
einer Protokollzustandsmaschine), die zwar auf dem DSP gehandhabt
werden müssen, aber
die im Allgemeinen besser auf einem separaten Microcontroller laufen
(wobei diese Microcontroller im Allgemeinen, aber nicht immer, auf
RISC basieren, und daher werden wir sie von nun an als RISC-Kernkomponente
bezeichnen). Die dem Microcontroller zugewiesenen Tasks neigen dazu,
viel Konditionalität
zu beinhalten, und haben einen geringen inhärenten Parallelismus (d.h.
die Tasks können mehrere
Ausführungsthreads
beinhalten, die nicht aufgeteilt werden können). Sie haben auch allgemein eine
unvorhersehbare Last (aufgrund der hohen Konditionalität). Um bei
der Ausführung
von HMI und peripherem Zugriff zu assistieren, arbeitet der RISC-Controller
häufig
mit einer Form von eingebettetem Betriebssystem (EmOS) (z.B. Windows
CE, EPOC-32, PalmOS usw.). Die oben erörterte Taxonomie ist in 1 dargestellt.
-
Die
Folge ist, dass die oben erwähnten
anspruchsvollen Anwendungsbereiche, wie z.B. Digitalfernsehempfänger, drahtlose
LAN-Modeme usw., häufig
einen kundenspezifischen HDL-Teil, einen DSP-Teil und einen RISC-Microcontroller-Teil
benötigen.
Sie werden im Allgemeinen über
eine Form von Gemeinschaftsbus miteinander verbunden. Die andere
wichtige Komponente ist Memory, der Code für die DSP-, RISC- und Gate-Konfigurationen
für die FPLA
enthält
(obwohl die Gatterkonfigurationen auf internem Memory liegen), und
Arbeitsspeicher für das
System enthalten (einschließlich
E/A Pufferung, um Verarbeitungsamortisierung zu ermöglichen, wenn
Dateneingang oder -ausgang diskontinuierlich sind).
-
Für sehr hohe
Produktvolumen (gewöhnlich >1.000.000 Einheiten)
kann eine solche Architektur herkömmlicherweise in eine ASIC
(anwendungsspezifische integrierte Schaltung) gemappt werden, die HDL-vorgegebene
Module wie On-Chip-Beschleuniger beinhalten, auf die gewöhnlich über einen
internen Bus zugegriffen wird, sowie einen DSP-Kern und einen RISC-Kern,
zusammen mit geeigneten On-Chip-Memory- und E/A Modulen.
-
Für Volumen
unter denen, für
die eine kundenspezifische ASIC rentabel ist (einschließlich Prototyping-Phase,
selbst dann, wenn eine ASIC das Endziel ist), ist die einzige Möglichkeit,
die 'breiten' Algorithmen innerhalb
eines sinnvollen Zeitrahmens zu implementieren, die Verwendung einer
feldprogrammierbaren Logikanordnung, oder FPLA, in Verbindung mit
einer diskreten DSP-Komponente und einer diskreten RISC- Komponente,
die über
(einen) Board-Level-Bus(se) miteinander verbunden sind. Dies führt jedoch
zu einem insgesamt komplexen Systemdesign, das sich nicht – selbst
auf ein moderates Volumen, rentabel skalieren lässt, wie nachfolgend erläutert wird.
Eine High-Level-Darstellung
einer typischen volumenarmen Platine für eine Anwendung mit hoher
Bandbreite (wie der oben beschriebenen) ist in 2 dargestellt.
-
Für eine nieder-
bis Mittelvolumige Produktion von breitbandigen Produkten hat dann
das derzeitige Entwicklungsparadigma, das zu der Art von Systemkarte
führt,
die in 2 dargestellt ist, eine Reihe von Nachteilen,
nämlich:
- – Die
Gesamtkosten des Systems sind hoch, da es (im ungünstigsten
Fall drei separate diskrete Rechenelemente (FPLA, DSP und RISC-)
zusammen mit externem Memory enthält.
- – Da
sich der Gemeinschaftsbus außerhalb
der einzelnen Rechenelemente befindet, ist seine Gesamtgeschwindigkeit
beschränkt
und er leidet auch potentiell an erheblichen EMV-Problemen.
- – Die
Entwicklungszykluszeit ist höher,
weil zwischen diesen Prozesselementen passierende Daten in jedem
Element explizit verwaltet werden müssen (unter Verwendung der
vom Anbieter bereitgestellten Kommunikations-HDL-Makros der FPLA,
der Kommunikationseinrichtungen, die das für den DSP gewählte RTOS
bietet, und der Kommunikationseinrichtungen, die das für den RISC gewählte EmOS
bieten, z.B).
- – Mobilität (während der
Designphase) von Algorithmen zwischen den verschiedenen Verarbeitungselementen,
und 'Simulierfähigkeit' des Systems, wird
ebenso durch die Tatsache reduziert, dass die Entwicklungsumgebungen
verschiedener Anbieter ebenfalls für jedes Element verwendet werden
müssen,
und diese Umgebungen arbeiten im Allgemeinen nicht ohne Komplikationen zusammen.
- – Die
Systemplatine wird wahrscheinlich eine hohe Leistungsaufnahme haben,
in Anbetracht der Zahl der diskreten Bauelemente.
- – Die
Systemplatine wird wahrscheinlich komplexe Leistungsregelungsanforderungen
haben, da es unwahrscheinlich ist, dass jedes der Bauelemente eine
gemeinsame Eingangsspannung haben wird.
- – Die
Systemplatine wird recht groß sein,
und dies kann seine Einsatzfähigkeit
in bestimmten Anwendungen mit Raumbeschränkung begrenzen.
- – Die
Systemplatine lasst sich nicht einfach modifizieren, wenn sie im
Einsatz ist – da
heruntergeladene Algorithmen z.B. für die FPLA das (gewöhnlich externe)
Programmiertool benötigen würden, um
ein Upload in den internen nichtflüchtigen RAM des Bauelementes
zu ermöglichen.
- – Selbst
wenn das Design erfolgreich ist, ist eine Umstellung auf eine ASIC
nicht unkompliziert, da Designtools von einer Reihe verschiedener
Anbieter verwendet wurden, wobei eine Reihe von verschiedenen ,virtuellen' Maschinen verwendet wird,
um die logischen Interconnects zu assoziieren.
-
Es
ist bekannt, RISC- und FPLA-Rechenelemente zu einem einzigen Programmierbauelement zu
kombinieren (siehe z.B. Gokhale M B et al: "NAPA C: compiling for a hybrid RISC/FPGA
architecture" FPGAS
For Custom Computing Machines, 1998, Proceedings IEEE Symposium
On Napa Valley, CA, USA 15.–17.
April 1998, Los Alamitos, CA, USA, IEEE Comput. Soc., 15. April
1998, Seiten 126–135).
-
AUSSAGE DER
VORLIEGENDEN ERFINDUNG
-
Gemäß der vorliegenden
Erfindung wird ein programmierbares Ein-Chip-Bauelement bereitgestellt,
umfassend einen programmierbaren Gate-Array-Teil (PGA), einen DSP-Kern und einen RISC-Kern.
-
Die
vorliegende Erfindung eignet sich ideal für Prototyping und den Einsatz
von nieder- bis
mäßigvolumigen
Implementationen von Breitbandalgorithmen, deren Verarbeitungsanforderungen
aufgeteilt sind zwischen (a) hoher Iteration, geringer numerischer
Agilität,
,breiten' Beladungen,
(b) mäßiger Iteration,
Beladungen mit hoher numerischer Präzision und (c) geringer Iteration,
hoch konditionalen Beladungen, ohne den damit einhergehenden Problemen,
die in der kundenspezifischen ASIC inhärent sind, gemeinsame FPLA/DSP/RISC
(oder sogar direkte Kompilation von FPLA) Lösungen.
-
Die
Möglichkeit
des Kombinierens eines PGA-Teils, eines DSP-Kerns und eines RISC-Kerns auf einem programmierbaren
Ein-Chip-Bauelement wurde bisher noch nicht erkannt. Ein Hauptgrund hierfür ist, dass
PGA Design, DSP-Kerndesign und RISC-Kerndesign separate technische Disziplinen sind,
die von vollständig
unterschiedlichen Unternehmen ausgeführt werden. Ferner fehlen den
Designern von PGA, DSP und RISC gewöhnlich die Kenntnisse über die
anwendbaren Kommunikationsanwendungen; und ohne diese Kenntnisse
fehlen jegliche Motivation und Fähigkeit,
zur vorliegenden Erfindung zu kommen. Ein weiteres praktisches Hindernis,
zu der vorliegenden Erfindung zu kommen, besteht darin, dass ihre
praktische Durchführbarkeit
auf der Existenz einer effektiven integrierten Entwicklungsumgebung
und einer virtuellen Laufzeitmaschine beruht (siehe unten). Und
diese standen bisher nicht zur Verfügung. Und daher stand die Integration
aller drei Rechenentitäten
auf einem Ein-Chip-Bauelement
in der Praxis bei keinem Unternehmen zur Debatte.
-
Das
Ein-Chip-Bauelement umfasst vorzugsweise ferner einen FLASH Speicher
für die Gate-Konfiguration
sowie DSP- und RISC-Software, RAM als Arbeitsspeicher und Programmspeicher, wenn
die DSP- und RISC-Bauelemente laufen, und schnelle, DMA-gesteuerte E/A Ports
(parallel und seriell), durch die das Bauelement Daten zu und von der
Außenwelt übertragen
kann (z.B. von einem ADC oder zu einem DAC).
-
In
einer bevorzugten Ausgestaltung können die verschiedenen Rechenelemente
Daten untereinander mit einer Reihe von dedizierten Bussen zusätzlich zu
dem gemeinsamen Daten-/Adressbus übertragen.
-
Eine
gemeinsame virtuelle Maschinenplattform (VM) kann für die Verwendung über die
drei Rechenelemente vorhanden sein, so dass eine gemeinsame API
für Datenübertragungen,
Konkurrenzsignalisierung, Peripher- und Buskonkurrenzsteuerung usw.
möglich
wird.
-
In
einem anderen Aspekt wird eine Entwicklungsumgebung für das Ein-Chip-Bauelement bereitgestellt,
wobei die Umgebung Folgendes umfasst: Compiler für HDL (für den PGA-Teil) und Assembler für den DSP-
und den RISC-Kern sowie geeignete High-Level-Compiler für den DSP-
und den RISC-Kern (z.B. C++, C). Die Entwicklungsumgebung kann auch
die Verwendung von 'High-Level'-Gatterbeschreibungsentwicklungssprachen
(wie z.B. Handel-C) unterstützen.
-
Die
Entwicklungsumgebung kann auch einen Satz von systemüberspannenden
Simulations- und Timing-Tools enthalten, um eine einfache Designverifizierung
zu ermöglichen,
und kann auch einen Satz von Bibliotheken beinhalten, die gemeinsame, nützliche
Funktionen implementieren, die nicht direkt auf der Ebene der virtuellen
Maschine bereitgestellt werden. Die Entwicklungsumgebung enthält auch Treibercode
(und entsprechende Hardware (z.B. eine JTAG-Karte), um die kompilierte
Gesamtsystembeschreibung zu ermöglichen
(TSC, bestehend aus z.B. einer JDEC-Fuse-Map für die PGA, zusammen mit Maschinencode
für die
DSP- und RISC-Kerne und beliebige geeignete Lookup-Tabellen usw.),
die in das Ein-Chip-Bauelement heraufgeladen werden sollen. Eine
automatische Umstellung auf eine ASIC kann unter Verwendung der
kompilierten Gesamtsystembeschreibung erzielt werden. Die Entwicklungsumgebung
kann auch die Fähigkeit
beinhalten, einen Echtzeit-Source-Level-Debugger abzuarbeiten. Aufgrund
der einzigartigen Struktur können
Benutzer Unterbrechungen an jeder beliebigen Stelle in der Systembeschreibung
einführen,
unabhängig
davon, ob das fragliche Modul über
das PGA , DSP- oder RISC-Rechensubstrat
abläuft.
Eine gemeinsame virtuelle Maschine kann für die Entwicklung jedes der drei
Rechenelemente bereitgestellt werden, so dass Algorithmusmobilität über diese
drei Elemente ermöglicht
wird.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Die
Erfindung wird nachfolgend mit Bezug auf die Begleitzeichnungen
beschrieben. Dabei zeigt:
-
1 den
Stand der Technik – Variablen,
die die Wahl des Verarbeitungssubstrats einschränken;
-
2 den
Stand der Technik- typische niedervolumige Breitbandsystemkarte;
-
3 ein
programmierbares Ein-Chip-Bauelement gemäß der Erfindung;
-
4 eine
schematische Darstellung einer Entwicklungsumgebung gemäß der vorliegenden
Erfindung.
-
AUSFÜHRLICHE
BESCHREIBUNG
-
Die
Erfindung wird mit Bezug auf eine Implementation von RadioScape
Limited aus Großbritannien
beschrieben.
-
Das
System von RadioScape, das wir praktischerweise als Optimal Parallel
Processing Substrate (OPPS) bezeichnen, umfasst drei Hauptelemente:
- 1. Ein generisches programmierbares Ein-Chip-Bauelement,
das einen programmierbaren Gate-Array- (PGA) Teil, einen DSP-Kern
und einen RISC-Kern
zusammen mit FLASH Speicher für
die Gate-Konfiguration sowie DSP- und RISC-Software,
RAM für
Arbeitsspeicher und Programmspeicher, wenn die DSP- und RISC-Bauelemente
laufen, sowie schnelle DMA-gesteuerte E/A-Ports (parallel und seriell)
enthalten, durch die das Bauelement Daten zu und von der Außenwelt
leiten kann (z.B. von einem ADC oder zu einem DAC). In einer bevorzugten
Ausgestaltung können
die verschiedenen Rechenelemente Daten untereinander mit einer Reihe
von dedizierten Bussen zusätzlich
zum gemeinsamen Daten-/Adressbus übertragen.
- 2. Eine gemeinsame virtuelle Maschinenplattform (VM) für die Verwendung über die
drei Rechenelemente, so dass eine gemeinsame API für Datenübertragungen,
Konkurrenzsignalisierung, Peripher- und Buskonkurrenzsteuerung usw.
bereitgestellt werden. Diese gemeinsame VM-Layer lässt es auch zu, dass Module
(auf Schnittstellenebene) ihre eigenen E/A- und Konkurrenzanforderungen haben,
die ohne Referenz darauf ausgedrückt
werden, welches Rechenelement gerade als ihr Substrat verwendet
wird. In einer bevorzugten Ausgestaltung ist die VM-Layer die virtuelle
Kommunikationsmaschinenlayer, die in der PCT/GB01/00273 beschrieben
ist. Eine ,virtuelle Maschine' definiert
gewöhnlich
die Funktionalität und
die Schnittstellen der idealen Maschine zum Ausführen eines bestimmten Anwendungssatzes, der
für die
vorliegende Erfindung relevant ist. Sie präsentiert der sie benutzenden
Anwendung gewöhnlich
eine ideale Maschine, die für
die zu verrichtende Aufgabe optimiert ist, und verbirgt Unregelmäßigkeiten
und Mängel
der eigentlichen Hardware. Die 'virtuelle
Maschine' kann auch
eine oder mehrere Zustandsmaschinen verwalten und/oder warten, die
Kommunikationsprozesse modellieren oder repräsentieren. Die 'Virtual Machine Layer' ist die Software,
die es ermöglicht, dass
eine echte Maschine wie diese ideale aussieht. Diese Layer wird
gewöhnlich
für jeden
echten Maschinentyp anders implementiert, bietet jedoch eine gemeinsame
Schnittstelle zu einer Higher-Level-Software über alle Plattformen. Eine 'Virtual Machine Layer' bezieht sich gewöhnlich auf
eine Software-Layer, die einen Satz von einer oder mehreren APIs
(Application Program Interfaces) bereitstellt, die eine Task oder
einen Satz von Tasks ausführen
und die auch die kritischen Ressourcen haben, die zwischen den Elementen zugeordnet
und gemeinsam genutzt werden müssen,
die die VM-Layer
nutzen. Es ist zu bemerken, dass diese gemeinsame überspannende
VM-Layer eine zusätzliche
Verwendung eines spezifischen RTOS / EmOS nicht ausschließt. Sie
liefert einfach eine gemeinsame Daten- und Steuerebene, durch die
Module der Anwendung nahtlos unabhängig von dem verwendeten Rechenelement miteinander
kommunizieren können.
- 3. Eine einzige Entwicklungsumgebung für das Bauelement, die Compiler
für HDL
(für den
PGA Teil) und Assembler für
den DSP- und den RISC-Kern sowie geeignete High-Level Compiler auch
für den
DSP- und den RISC-Kern enthält (z.B.
C++, C). Die Entwicklungsumgebung kann auch (bei Bedarf) die Verwendung
von 'High Level' Gatterbeschreibungsentwicklungssprachen (wie
Handel-C) unterstützen.
Die Entwicklungsumgebung enthält
einen Satz von mathematischen systemüberspannenden Modellierungssimulations-
und Timing-Tools,
die eine unkomplizierte Designverifizierung ermöglichen, und kann auch einen
Satz von Bibliotheken enthalten, die gemeinsame, nützliche
Funktionen implementieren, die nicht direkt auf der Virtual Machine
Layer vorhanden sind. Die Entwicklungsumgebung enthält auch
Treibercode (und geeignete Hardware (z.B. eine JTAG-Karte)), um
das Heraufladen der kompilierten Gesamtsystembeschreibung (TSD, bestehend
aus z.B. einer JDEC-Fuse-Map für
die PGA, zusammen mit Maschinencode für die DSP- und RISC-Kerne und
beliebigen geeigneten Lookup-Tabellen usw.) in das in (1) oben beschriebene
Bauelement zu ermöglichen.
Die Entwicklungsumgebung beinhaltet auch die Fähigkeit, einen Echtzeit-Source-Level-Debugger
abzuarbeiten, wieder unter Verwendung von geeigneter Verbindungshardware
mit dem Bauelement, und aufgrund der einzigartigen Architektur können Benutzer
an jeder beliebigen Stelle in der Systembeschreibung Breakpoints
setzen, unabhängig davon,
ob das fragliche Modul über
das PGA , das DSP- oder das RISC-Rechensubstrat läuft.
-
3 zeigt
eine schematische Darstellung einer Implementation des Ein-Chip-Bauelementes. Die
Entwicklungsumgebung ist schematisch in 4 dargestellt.
-
Die
Radioscape OPPS-Implementation bietet erhebliche Vorteile für eine nieder-
bis mittelvolumige Implementation von Breitbandanwendungen im Vergleich
zum Systemplatinenansatz, wie nachfolgend beschrieben:
- – Die
Gesamtkosten des Systems sind niedrig, da es im Allgemeinen als
einzelner Chip arbeitet, mit nur wenigen externen Komponenten. Ferner
kann der Chipanbieter, da die große Zahl von Breitbandanwendungen,
bei denen nieder- bis
mittelvolumige Zahlen von Bauelementen benötigt werden (z.B. neu entstehende
Märkte
für neue
Digitalnormen), das Bauelement in sehr großen Gesamtvolumen produzieren,
wodurch die Kosten noch weiter gesenkt werden.
- – Die
Verwendung eines internen Hauptgemeinschaftsbusses für die Interkommunikation
zwischen den Rechenelementen, zusammen mit der fakultativen Verwendung
von zusätzlichen
dedizierten Bussen, erhöht
die potentielle Datenaustauschrate sehr stark, während EMV gesenkt wird.
- – Die
Entwicklungszykluszeit wird stark reduziert, weil die drei Rechenelemente
jetzt eine gemeinsame ,virtuelle Maschine' gemeinsam nutzen – so dass Daten zwischen ihnen
vom Standpunkt des Benutzers aus durch individuelle Primitive gesehen übertragen
werden.
- – Die
Mobilität
von Algorithmen zwischen den verschiedenen Verarbeitungselementen,
und 'Simulierbarkeit' des Systems, werden
ebenfalls aufgrund der Tatsache verbessert, dass eine einzelne Entwicklungsumgebung,
und ein gemeinsames API-Modul, im Einsatz sind.
- – Das
Bauelement hat eine weitaus geringere Leistungsaufnahme, da seine
Kerne mit einer (niedrigen) internen Spannung laufen und keine kapazitive
Last von einem gemeinsamen externen Memory-Bus auferlegt wird.
- – Die
Leistungsregelungsanforderungen werden vereinfacht, da der Chip
eine einzige Eingangsspannung haben kann.
- – Das
einzelne Bauelement ist recht klein und kann in verschiedenen kompakten
Pakettypen (z.B. Mikro-BGA) bereitgestellt werden, was seine Verwendung
in Designs erleichtert, bei denen der Raum beschränkt ist
(z.B. Mobiltelefone).
- – Da
das Bauelement (einschließlich
seines nichtflüchtigen
Konfigurationsspeichers für
jedes der Rechenelemente) in einer Ein-Chip-Packung (oder mit zusätzlichem
ROM für
das Programm) bereitgestellt wird, lässt es sich leicht (entsprechend
programmiert) als kundenspezifischer Teil verschiedener Anwendungen
an Fremdentwickler weiterverkaufen. So könnte z.B. ein Unternehmen einen
DVB-Decoder (Digitalfernsehen)
für das Bauelement
entwickeln und dann auf normale Weise vorprogrammierte Bauelemente
(z.B. mit einem Datenblatt) als Katalogteile zum Verkauf anbieten,
- – Das
Bauelement lässt
sich einfach modifizieren, selbst nach der Installation am Einsatzort,
da alle nichtflüchtigen
Elemente intern zugängig
sind. Somit wäre
es möglich
(z.B.), ein neues, verbessertes Equaliser-Modul 'über
den Ather' in ein
Zellulartelefon herunterzuladen, selbst dann, wenn das Modul auf
dem PGA-Rechenelement
des Bauelementes abläuft.
- – Die
Verwendung einer einzelnen virtuellen Maschine und Entwicklungsumgebung
ermöglicht es,
einfach auf eine ASIC-Implementation umzustellen, wenn sich ein
bestimmtes Design als populär
erweist. So könnte
ein Anbieter des OPPS-Chips einen großen Vorteil daraus ziehen und
einen kundenspezifischen Service mit kurzer Vorlaufzeit anbieten,
der die volle vom Design-Tool erzeugte Systembeschreibung (die definitionsgemäß die gesamten
komplexen Timing-Beziehungen zwischen den verschiedenen Rechenelementen
beinhaltet) nimmt, und diese für
die (idealerweise automatisierte) Produktion einer geeigneten ASIC
verwenden. In einer Implementation wird die ASIC auf automatisierte
Weise von der TSD bereitgestellt. Der Anbieter könnte seinem Kunden einen einmaligen
großen
Nutzen anbieten (im Hinblick einer schnellen und problemlosen ASIC-Umstellung).
Ferner könnte,
da der Vorgang der Umstellung auf ASIC ganz oder weitgehend automatisiert
werden könnte (vorausgesetzt,
dem Anbieter stehen kompatible Kerne für DSP und RISC zur Verfügung, und
unter der Annahme, dass HDL in festes Silicium kompiliert werden
kann und Elemente der ursprünglichen OPPS-Plattform,
die die Zielanwendung nicht nutzt, entfernt würden), ein weiterer Vorteil
entstehen, nämlich
Zuverlässigkeit:
die resultierende ASIC würde
korrekt in der ersten Iteration arbeiten, im Vergleich zu dem normalen
Prozess, bei dem verschiedene ,Durchläufe' erforderlich sind, um Fehler zu beheben,
die bei der Umstellung von Systemplatine auf ASIC entstanden sind.
-
Somit
ist klar, dass dieser Ansatz für
kleine bis mittlere Volumen sehr attraktiv ist und in der Tat den Übergang
vom Systemdesign zu einer ASIC bei geeigneten Volumen stark erleichtert.
Es lohnt sich jedoch zu erwähnen,
dass die OPPS-Plattform eine Reihe von Vorteilen gegenüber dem
festen ASIC-Ansatz zu bieten hat, selbst bei großen Volumen:
- – Die Flexibilität, die sich
durch die Möglichkeit
ergibt, im Einsatz befindliche Bauelemente umzuprogrammieren (z.B.
einen neuen Equaliser 'über den
Ather' in einem
Kommunikationssystem herunterzuladen), selbst dort, wo die fragliche
Logikkomponente im kundenspezifischen Gate-Rechensubstrat implementiert
wird, repräsentiert
einen erheblichen Vorzug für
viele Anwendungen, die nur mit einem umprogrammierbaren Bauelement
möglich
sind.
- – Die
Fähigkeit,
rasch neuen Code zu erzeugen, um ein anwendungsprogrammiertes Bauelement auf
einen bestimmten OEM-Einsatz ,abzustimmen' (z.B. indem nur der HMI-Code für das RISC-Bauelement
geändert
wird), bedeutet einen erheblichen potentiellen Vorteil.
-
Kurz
ausgedrückt,
OPPS repräsentiert
eine Hardware-Plattform, die für
moderne breitbandige Broadcast- und Kommunikationsaufgaben optimiert wurde,
bei denen der Bedarf an hohem Parallelismus, sehr präzisen digitalen
Berechnungen und HMI-Interaktion
mit einem einzelnen Hardware-Substrat gedeckt wird. So kann der
OPPS-Vendor Herstellungsvolumen
optimieren, Kosten reduzieren, und gleichzeitig können Anwendungsentwickler Nur-Software-Anwendungen
unter einer gemeinsamen Entwicklungsumgebung auf eine gemeinsame VM-Layer
schreiben, mit allen damit einhergehenden Produktivitätsvorteilen,
wissend, dass sie ihre IP nicht nur einfach als ,Systemplatine', sondern auch als
Katalogteil-Chip (ohne die Kosten des Spinnens einer ASIC) verkaufen
können,
und ferner in der sicheren Gewissheit, dass sie eine einfache, schnelle und
zuverlässige
(und Idealerweise automatisierte) Route zu einer ASIC haben, wenn
es die Volumen nachfolgend zulassen.
-
Es
können
noch weitere Typen von nichtflüchtigem
Speicher überall
dort verwendet werden, wo 'FLASH'-Memory erwähnt wird.
-
Es
kann die Fähigkeit
bereitgestellt werden, die heraufgeladene Systembeschreibung 'schreibzuschützen', so dass versandte 'anwendungsspezifizierte' Chips weniger diebstahlsanfällig sind.
-
Das
Bauelement kann externen FLASH, festen ROM oder jeden anderen Speicher
für seinen DSP-
und RISC-Programmspeicher bei Bedarf verwenden. Ein externer Speicherzugriffsbus
kann bei Bedarf ebenfalls unterstützt werden.