![]()
Notation eines Hardware-Entwurfsmusters
In der Entwurfsmusterbewegung der Softwaretechnik hat sich eine Redewendung im Verlauf der Jahre zum Leitsatz entwickelt: Das Rad nicht neu erfinden!" Und auch ich möchte dieser Versuchung nicht unterliegen und zurück in die Steinzeit verfallen. Die wachsende Bedeutung der Gamma-Muster" in der Softwaretechnik veranlaßte mich, die Notation der Hardware-Entwurfsmuster eng an die Notation von Gamma et al. anzulehnen. Doch da Software nicht gleich Hardware ist, müssen folgende zwei Fragen beantwortet werden:
Zur Klärung der ersten Frage werfen wir einen Blick zurück (vgl. Unterkapitel: Notation eines Design Patterns, S. 43). Sicherlich können viele Beschreibungspunkte der Gamma-Muster" einfach übernommen oder weggelassen werden; andere sinnvoller zusammengefaßt werden. Meiner Meinung nach kommt jedoch der Implementierung (10. Beschreibungspunkt) eines Hardware-Entwurfsmusters eine besondere Bedeutung zu. Sie zeigt konkret, wie das Entwurfsmuster in der Praxis umgesetzt wird. Die Implementierung eines Musters spiegelt sich jedoch in den unterschiedlichsten Entwurfsschritten eines Entwicklungsprozesses wider, so daß eine Strukturierung der Implementierung sinnvoll ist. Betrachten wir dazu das weit verbreitete Y-Diagramm von Daniel Gajski und Robert Kuhn (Abbildung 17). Mit Hilfe dieses sichtenorientierten Entwurfsmodells versuchten die beiden Autoren, die Werkzeuge in der Chipkonstruktion der 80er Jahre übersichtlicher zu erfassen.

Abbildung 17: Y-Diagramm nach Gajski und Kuhn [Gajski&Kuhn, 1983]
Der Entwurfsprozeß wird schematisch als Achsen-Modell dargestellt: Die Achsen spannen den Entwurfsraum in drei komplementäre Entwurfsbereiche auf, als Sichten oder Domänen bezeichnet. Die Verhaltenssicht ist auf die Funktionalität, die Struktursicht auf die logische Struktur und die physikalische [geometrische] Sicht auf die physikalische Implementierung gerichtet. [...] Entlang der Raumachsen er-folgt von außen nach innen die Entwurfsverfeinerung auf Ebenen zunehmender Detaillierung." [Quibeldey-Cirkel, 1994b, S. 127]
Schnell hatte sich das Y-Diagramm Mitte der achtziger Jahre etabliert. Donald Thomas und Robert Walker verfeinerten es und zeigten anschaulich, wie innerhalb des Modells der Ent-wurfsprozeß nachvollzogen werden kann. Analyse- und Synthese-Schritte sind eindeutig identifizierbar. Abbildung 18 zeigt das von Thomas und Walker aufgeführte Beispiel einer automatischen Datenpfad-Synthese.

Abbildung 18: Verfeinerung des Y-Diagramms durch Thomas und Walker (zitiert in [Quibeldey-Cirkel, 1994b, S. 127])
Die Numerierung der Pfeile verdeutlicht die Reihenfolge der Entwurfsschritte. Alle Pfeile des Beispiels symbolisieren ausschließlich Syntheseschritte. Bei umgekehrter Pfeilrichtung auch Extraktion genannt oder Auftreten von Schleifen (Anfangs- und Endpunkt fallen zusammen) gemeint ist die Simulation handelt es sich um Analyseschritte.
Darüber hinaus erlauben Einstiegs- und Zielpunkt der Verfahrenskette das Identifizieren der ursprünglichen Entwurfsspezifikation (hier die algorithmische Verhaltensbeschreibung) und der erreichten Implementierungshilfe (Maskenlayout)." [Quibeldey-Cirkel, 1994b, S. 128]
Gajski und Kuhn verfolgten mit dem Y-Diagramm das Ziel, die unterschiedlichen Strömungen des Hardware-Entwurfs übersichtlich in einem Modell zusammenzufassen. Und genau diese Absicht benutzen wir zur Strukturierung. Mit Hilfe dieses Modells kann die Existenz und die Anwendung eines Hardware-Entwurfsmusters im Entwicklungsprozeß anschaulich beschrieben werden. Ein Hardware-Entwurfsmuster hat seinen Ursprung bzw. Einstiegspunkt auf möglichst hoher Abstraktionsebene. Durch weitere Synthese- bzw. Analyseschritte kann das Muster sowohl aus anderen Sichtweisen betrachtet als auch in unterschiedlichen Abstraktionsebenen beobachtet werden; ein Muster hat Einfluß auf die unterschiedlichsten Entwurfsschritte.
Ein Entwurfsmuster stellt somit eine Pfeilkette durch das Y-Diagramm dar, d. h. spiegelt eine Entwurfsstrategie wider. Das Muster beschreibt, welche Gesichtspunkte auf der Kette" zum Tragen kommen; insbesondere welche Analyse- und Synthesewerkzeuge zum Einsatz kommen können. Hardware-Entwurfsmuster können so bequem als Dokumentationsmittel in den Entwurfsprozeß eingebettet werden. Der Entwickler kann eindeutig nachvollziehen, auf welcher Entwicklungsstufe er sich befindet.
Doch welchen Darstellungsformen bedient sich ein Hardware-Entwurfsmuster in seiner Notation? Kommen wir also zur Beantwortung der zweiten Frage.
In der Softwaretechnik ist für den Entwickler die Auswahl an Beschreibungsmöglichkeiten eines Entwurfs begrenzt. Er spezifiziert einen objektorientierten Entwurf meist durch ein Objektmodell in OMT-, Booch- oder Coad-Notation. Neben Flußdiagrammen und Pseudo-Code steht ihm meist nur der Text zur Spezifikation des Entwurfs zur Verfügung. Pflichtenhefte sind durch die Verwendung langer Textpassagen oft ein abschreckendes Beispiel dafür, wie eine Software-Produktdefinition unübersichtlich und interpretierbar wird. Auch die Notation der Gamma-Muster" hat gezeigt, wie durch Text eine Beschreibung aufgebläht und mehrdeutig wird. Text ist ungenau und auslegbar Zahlen und Symbole sind dagegen meist klar und deutlich definiert, Mißverständnisse nahezu ausgeschlossen.
Die Hardware hat gegenüber der Software einen großen Vorteil: Es gibt viele standardisierte Beschreibungsmöglichkeiten eines Entwurfs; zur Spezifikation einer Schaltung stehen dem Entwickler viele Hilfsmittel zur Verfügung: Programm-Code (VHDL), Schaltbilder, Zustandsdiagramme, Daten- und Steuerflußdiagramme, Funktionstabellen, Impulsdiagramme, Kennlinien, Stick-Diagramme, ... ergänzt jeweils durch kommentierenden Text. Das Beispiel der Motorola-Bausteinbibliothek (Abbildung 16) deutete diese Vielfalt bereits an. Es gibt also genügend Möglichkeiten, ein Hardware-Entwurfsmuster mit Hilfe standardisierter Beschreibungsformen zu charakterisieren. Die Notation dieser Muster wird folgendermaßen definiert:
1. Name
An erster Stelle der Musterbeschreibung steht der Name. Er muß die gleiche Voraussetzung erfüllen wie die Namen der Gamma-Muster": Er muß aussagekräftig sein, d. h. er muß Absicht und Essenz des Musters widerspiegeln. Darüber hinaus kann mit Hilfe eines kurzen Textes die Intention des Entwurfsmusters für die der Name Repräsentant ist beschrieben werden.
2. Synonyme
Viele Entwurfsstrategien bzw. Entwurfsmuster werden heutzutage unter verschiedenen Namen angewendet. Entwickler erfinden immer neue Bezeichnungen für an sich gleichartige Muster, da die meisten noch nicht standardisiert oder firmenspezifisch sind. Existieren mehrere Synonyme des Musters, so listet sie dieser 2. Unterpunkt auf.
3. Klassifizierung
Eine übergeordnete Klassifizierung ordnet das Muster in den Entwurfsprozeß ein. Es wird veranschaulicht, welche weiteren Muster es gibt und welche Beziehungen untereinander bestehen.
Welche Klassen - oder sagen wir besser Kategorien - von Entwurfsstrategien könnte es geben? Analog: In welche Bestandteile wird eine Schaltung zerlegt, um den Entwurf zu strukturieren und damit zu vereinfachen? Eine Unterteilung der Schaltung in einzelne Komponenten klassifiziert gleichzeitig die Entwurfsmuster, die beim Entwurf dieser Komponenten zum Einsatz kommen. Wie wird also eine Schaltung zerlegt? Eine allgemeine Organisation und damit eine mögliche Klassifizierung der Hardware-Entwurfsmuster beschreibt Abbildung 19:
Abbildung 19: Mögliche Klassifizierung von Hardware-Entwurfsmustern
Boundary-Scan könnte z. B. ein Repräsentant aus der Klasse Testbarkeitserhöhende Maßnahmen" sein einer Unterkategorie der Kategorie Testumgebung". Ad-hoc-Ansätze, wie z. B. Dip-Sockel, Multiplexer/Demultiplexer, Schieberegister, Degating Logic oder LSSD-Verfahren, wären weitere Mitglieder dieser Unterkategorie und damit auch Hard-wareEntwurfsmuster.
Es wäre jedoch auch denkbar, daß es sich bei Testbarkeitserhöhende Maßnahmen" um ein übergeordnetes Entwurfsmuster handelt, so daß Boundary-Scan und alle anderen Maßnahmen jeweils eine Verfeinerung des Musters darstellen. Es gibt genügend Möglichkeiten, Kategorien oder neue" Entwurfsmuster für bestehende Entwurfsstrategien zu definieren. Eine vernünftige" Klassifizierung kann aber erst erfolgen, wenn mehrere Hardware-Entwurfsmuster identifiziert, definiert und in einem Musterbuch zusammengefaßt worden sind.
4. Kontext
Der Kontext erläutert die Umgebung, in der das Muster angewendet wird. Meist handelt es sich um Technologieparameter, d. h. Informationen, die beachtet werden müssen, wenn das Muster eine Schaltungsrealisierung bestimmter Technologie beschreibt. Neben Entwurfsvoraussetzungen werden Konsequenzen (Flächenausnutzung, Laufzeitverhalten, Verlustleistung etc.) erläutert, die durch Anwendung des Musters entstehen.
5. Problem
In meist textueller Form wird das Problem beschrieben, daß zur Anwendung des Musters führt.
6. Lösung
Der Unterpunkt gibt Einblick, wie das oben dargestellte Problem gelöst werden kann. Meist wird ein vereinfachtes Schaltbild evtl. ergänzt durch einfache Modellkomponen-ten zur Lösungsbeschreibung verwendet.
7. Implementierung
Die Implementierung eines Musters folgt der Beschreibung eines Entwurfsprozesses gemäß des Y-Diagramms nach Gajski und Kuhn. Für jede Abstraktionsebene und entsprechende Sichtweise zeigt das Muster eine anschauliche Implementierung mit Hilfe geeigneter Darstellungsformen.
8. Praxiseinsätze
Hardware-Entwurfsmuster repräsentieren bewährtes Entwurfswissen. Viele Muster sind in der Praxis mit Erfolg eingesetzt worden. Eine Auflistung zeigt, in welchen Entwürfen das Muster bereits eingesetzt wurde.
9. Korrelierte Muster
Muster stehen miteinander in Verbindung. Sie treten fast nie isoliert für sich im Entwurfsprozeß auf, sondern sind die Schlußfolgerung aus anderen Mustern bzw. bilden selbst Ausgangspunkt für weitere Muster. Der 9. Unterpunkt beschreibt, welche verwandte Muster es gibt.
10. Literatur
Eine Literaturliste hilft dem Entwerfer, nach weiteren Informationen zu recherchieren.
Die Konzeption eines Musterbuchs kann durch die Identifizierung neuer" Hardware-Entwurfsmuster weitere Beschreibungspunkte nach sich ziehen. Genauso kann die Notation eines Musters einzelne Unterpunkte weglassen, wenn sie für die Anwendung irrelevant sind. Der Evolutionsprozeß der Entwurfsmusterbewegung verlangt daher, daß auch die Notation der Hardware-Entwurfsmuster ständig überdacht wird.
Nach so viel Theorie wenden wir uns der Praxis zu. Befriedigen möchten wir nun die Neugier der Ungeduldigen, die im Verlaufe dieser Arbeit nur eine Frage beschäftigte: Wie sieht ein Beispiel eines Hardware-Entwurfsmusters aus? Genau wie in der Softwaretechnik müssen wir zur Identifizierung von Hardware-Entwurfsmustern praktische Entwurfsstrategien untersuchen; Entwurfsmuster nicht neu erfinden, sondern nach Bekanntem forschen. Welche bewährte Strategie kann also als Hardware-Entwurfsmuster definiert werden und somit die Mutter" einer ganzen Nachkommenschaft werden? Die Auswahl ist groß. Beschränken wir uns daher auf Strategien, die beim Test einer Schaltung Anwendung finden.
![]()