DE69522608T2

DE69522608T2 - Mehreinrichtungskopplung

Info

Publication number: DE69522608T2
Application number: DE69522608T
Authority: DE
Inventors: James M. Avery; William D. Isenberg
Original assignee: Hyundai Electronics America Inc
Current assignee: MagnaChip Semiconductor Ltd
Priority date: 1994-06-03
Filing date: 1995-05-31
Publication date: 2002-04-18
Anticipated expiration: 2015-06-01
Also published as: US5577213A; DE69522608D1; EP0685799B1; EP0685799A1

Description

Die vorliegende Erfindung betrifft eine Mehrgerätesteckervorrichtung und insbesondere, aber nicht ausschließlich, einen konfigurierbaren Geräteadapter, um ungleiche Bauelement- (Geräte-) Typen mit einem Datenverarbeitungssystembus zu verbinden.
In der vorliegenden Erörterung wird zunächst ein stark vereinfachter Datenbus erläutert und anschließend gezeigt, wie sich der vereinfachte Bus zu einer riesigen Anordnung verschiedener Typen von Datenbussen entwickelt hat.
Es ist bekannt, dass verschiedene Typen von Bauelementen im Allgemeinen über verschiedene Geräteadaptertypen mit einem Bus verbunden werden können. Geräteadapter führen jedoch nicht unbedingt zu einer optimalen Anpassung an ein bestimmtes Bauelement, wie nachfolgend unter besonderer Bezugnahme auf Fig. 1 unten erläutert wird.
Die besonderen Datenhandlingerfordernisse verschiedener Bauelemente, sowie die Art und Weise, in der ein unverfälschter Datentransfer von einem ersten Bauelement erfolgen kann, das zum Senden von Daten bereit ist und weiß, dass ein zweites Bauelement zum Empfangen dieser Daten bereit ist, stellen besondere Anforderungen an Geräteadapter, die nachteiligerweise nicht unbedingt erfüllt werden.
Es ist offensichtlich, dass es zahlreiche Bauartbeschränkungen gibt und Kompromisse geschlossen werden müssen, wenn ein Bauelement mit einem Bus verbunden wird. Beim Planen eines Adapters für einen solchen Anschluss, d. h. eines Geräteadapters, erfordern solche Bauartbeschränkungen und Kompromisse zeitaufwendige Planungsbemühungen für einen bestimmten Typ oder eine bestimmte Klasse von Bauelementen. Wenn ein nachfolgender Typ oder eine nachfolgende Klasse von Bauelementen mit diesem Bus verbunden werden soll, sind ähnliche intensive Planungsbemühungen notwendig, um einen Geräteadapter für dieses neue Bauelement zu schaffen. Es besteht Bedarf an einem System, das es zulässt, dass Parameter wie z. B. Pufferspezifikationen für einen bestimmten Typ oder eine bestimmte Klasse von Bauelementen einem bestimmten Universal-Design-Macro kenntlich gemacht wird, wobei automatisch ein Geräteadapterdesign erzeugt wird, das solchen vom Benutzer vorgegebenen Anforderungen entspricht. Dieses Geräteadapterdesign würde somit für ein bestimmtes Bauelement optimiert, das an einen Bus angeschlossen werden soll.
Die Erfindung beabsichtigt, einen Mehrgerätestecker bereitzustellen, der gegenüber bekannten Steckern Vorteile hat.
Die US-A-4,313,160 offenbart einen Mehrgerätestecker mit einer Busschnittstelle, einem Puffer und einem Steuermittel zum Steuern von Datenübertragungen darin, und die EP-A-0,403,117 offenbart eine Stecktafel für ein Computersystem, die eine anwenderspezifische Anpassung ermöglicht und im Hinblick auf den Steckplatz in dem Computer ausgestaltet ist, in dem die Tafel aufgenommen wird.
Gemäß der vorliegenden Erfindung wird ein Mehrgerätestecker bereitgestellt, umfassend eine Busschnittstelle für einen Computer zum Anpassen einer Mehrzahl von Geräten an einen Computerbus, mit einem Puffer für jedes Gerät zum Speichern von Daten, gekennzeichnet durch einen Datenmanager für jeden Puffer zum Steuern von Datenübertragungen über Datenpfade sowie zwischen dem genannten Puffer und dem genannten Bus, und ein Zyklussteuermittel für jeden Puffer und in Verbindung mit Steuerpfaden zum Steuern von Datenübertragungen über Datenpfade sowie zwischen dem genannten Puffer und dem jeweiligen Gerät, wobei der Stecker ferner eine Mehrzahl von Gerätesubadaptern beinhaltet, umfassend einen jeweiligen einen Puffer aus der genannten Mehrzahl von Puffern und zugehörigen Datenmanagern und Zyklussteuermitteln, wobei jeder genannte Subadapter so gestaltet ist, dass Zyklussteuermittel und Datenmanager in einer paarweisen Beziehung arbeiten, so dass der genannte Datenpfad so gestaltet werden kann, dass er unabhängig von dem genannten Steuerpfad vorgegeben werden kann, so dass der genannte Datenpfad selektiv und unabhängig breitenkonfiguriert werden kann.
Die Erfindung kann für die Herstellung eines verbesserten Geräteadapters vorteilhaft sein.
Darüber hinaus kann die Erfindung auch einen Geräteadapter bereitstellen, der für eine bestimmte Umgebung optimiert oder abgestimmt werden kann.
Vorteilhafterweise kann die Erfindung einen Bus optimal auf eine Mehrzahl verschiedener Geräte anpassen.
Die vorliegende Erfindung kann vorteilhafterweise auch ein Universal-Bauelement-Adapter-Macro bereitstellen, das über vom Benutzer vorgegebene Parameter für ein bestimmtes angeschlossenes Bauelement kundenspezifisch angepasst wird.
In einer Form der Erfindung werden vorzugsweise konfigurierbare Geräteadapter bereitgestellt. Die Erfindung stellt eine Schaltungsanordnung für einen bestimmten Typ oder eine bestimmte Klasse von Bauelementen bereit, mit der das Bauelement an einen Bus adaptiert wird. Die jeweilige Schaltungsanordnung für jedes Bauelement kann innerhalb bestimmter Parametergrenzen optimiert oder "abgestimmt" werden. Ein Universal-Macro wird in Verbindung mit vom Benutzer vorgegebenen Parametern für ein bestimmtes Bauelement verwendet, um ein kundenspezifisch angepasstes oder abgestimmtes Geräteadapterdesign auf der Basis solcher vom Benutzer vorgegebener Parameter zu erzeugen. Demzufolge wird ein großer Teil spezifischer Designinformationen, die sonst manuell von einem Benutzer bereitgestellt werden müssten, automatisch über die Verwendung des Universal-Macros erzeugt. Das Macro beinhaltet ein hohes Konfigurationsmaß zur Erfüllung einer Reihe verschiedener Anforderungen in Bezug auf die Unterstützung von Bauelementen. Der Benutzer kann somit das Macro auf eine solche Weise konfigurieren, dass es zur Erfüllung bestimmter Systemleistungsanforderungen abgestimmt werden kann.
Durch die abstimmbare Architektur ergibt sich ein architektonischer Grundrahmen mit vertragsgemäßen oder auf Designregeln basierenden Schnittstellen. Durch die Verwendung vertragsgemäßer Schnittstellen kann das Innere eines speziellen Blocks konfiguriert werden, ohne dass die Schnittstellendesignregeln geändert werden müssten. Mit diesem Konzept können mehrere Verhaltensmuster und Teilblock-Architekturen ausgeführt werden, ohne das konfigurierbare Macro-Grundkonzept zu ändern.
Die Erfindung wird nachfolgend, jedoch nur beispielhaft, unter Bezugnahme auf die Begleitzeichnungen näher beschrieben. Dabei zeigt:
Fig. 1 einen vereinfachten Bus für Datenübertragungen;
Fig. 2 eine einfache Art der Übertragung von Daten von einem 32-Bit- Datenbus zu einem Empfänger mit einer 8-Bit-Datenschnittstelle;
Fig. 3 die Art und Weise, in der der Ansatz von Fig. 2 mit Hilfe eines Puffers verbessert werden kann;
Fig. 4 eine Übersicht über eine Form der Erfindung;
Fig. 5 eine ausführlichere Übersicht über eine Form der Erfindung;
Fig. 6 interne Schnittstellen, bei denen Daten und Steuerung getrennt sind;
Fig. 7 einen Puffer, der als unidirektionaler Lese-/Schreib-Puffer konfiguriert ist;
Fig. 8 Puffer, die als separate Lese- und Schreibpuffer konfiguriert sind;
Fig. 9 mehrere Puffer, die als Pingpong- oder Kreispuffer konfiguriert sind;
Fig. 10 eine Systemplatine für einen Computer, die die Geräteadaptervorrichtung von Fig. 5 beinhaltet;
Fig. 11 eine Erweiterungskarte für einen Computer, die die Geräteadaptervorrichtung von Fig. 5 beinhaltet; und
Fig. 12 ein Prozessablaufdiagramm für die Planung und Herstellung integrierter Schaltungen mit dem abstimmbaren Macro.
Fig. 1 illustriert ein äußerst vereinfachtes Beispiel einer Datenübertragung über einen Bus. Die Übertragungsfolge lautet wie folgt, beginnend mit dem linken oberen Teil.
1. Der Sender setzt wie gezeigt Daten auf die Datenleitungen.
2. Der Sender zieht eine Ready- (Bereit) Leitung HOCH, wie angedeutet, und teilt so dem Empfänger mit, dass die Daten bereit sind.
3. Als Reaktion darauf erfasst der Empfänger die Daten.
4. Der Empfänger zieht die Acknowledge- (Bestätigung) Leitung HOCH und teilt so dem Sender mit, dass der Empfänger die Daten akzeptiert hat und dass weitere Daten auf die Datenleitungen gesetzt werden können.
5. Der Sender erkennt das Signal auf der Acknowledge-Leitung und zieht die Ready-Leitung TIEF.
6. Der Empfänger reagiert durch Wegnehmen des Signals von der Acknowledge-Leitung.
Jetzt befinden sich alle Leitungen in ihren ursprünglichen Zuständen. Der Sender kann den Vorgang wiederholen, indem er zum zweiten Mal Daten auf die Datenleitungen setzt.
Die oben gegebene exemplarische Transaktion ist ein äußerst vereinfachtes Beispiel. Nachfolgend werden mehrere Beispiele für Arten und Weisen gegeben, um den Bus zu verbessern und weiter zu entwickeln.
1. Der Empfänger kann einen Fehler in den Daten erkennen und verlangen, dass bestimmte Daten nochmal übertragen werden. Um dieser Forderung nachzukommen, kann eine zusätzliche Repeat- (Wiederholung) Leitung vorgesehen werden, über die der Empfänger die Übertragungswiederholung anfordert.
Wenn also der Sender ein Signal auf der Repeat-Leitung empfängt, wiederholt er die Übertragung. Umgekehrt, wenn der Sender kein solches Signal empfängt, aber statt dessen ein Bestätigungssignal empfängt, sendet er die nächsten Daten.
2. Man nehme an, der Sender setze Daten auf die Datenleitungen und ziehe die Ready-Leitung HOCH. Wie lange sollte er auf das Bestätigungssignal warten? Was tut der Sender, wenn er nicht innerhalb der vorgegebenen Zeit ein Bestätigungssignal erhält?
Ein weit verbreiteter Ansatz zu diesem Problem lautet wie folgt. Wenn der Sender nicht innerhalb einer vorgegebenen Zeit ein Bestätigungssignal erhält, bricht er den Versuch Daten zu senden ab.
Ein weiterer Ansatz basiert jedoch auf der Annahme, dass, wenn der Empfänger damit beschäftigt ist, eine andere Aufgabe auszuführen, während der Sender Daten senden möchte, der Empfänger nach Beendigung der Aufgabe trotzdem bereit ist, die Daten zu empfangen. Für diesen Ansatz kann eine Wait- (Warten) Leitung vorgesehen werden. Wenn der Sender ein Wartesignal sieht, bricht er den Versuch Daten zu senden nicht ab, sondern wartet, bis das Wartesignal verschwindet.
3. Man nehme an, dass über den Empfänger hinaus weitere Bauelemente mit dem Datenbus verbunden sind. Der Sender möchte jedoch Daten zu einem bestimmten Bauelement senden und wünscht, dass andere die Daten ignorieren. Es können Selection- (Auswahl) Leitungen hinzugefügt werden, die ein bestimmtes Bauelement anweisen, auf die Daten zu horchen.
4. Wie im Fall 3 oben, sind jedoch mehrere Bauelemente mit dem Datenbus verbunden. Im Gegensatz zu den oben gegebenen Beispielen möchten die Geräte jedoch eine Kommunikation einleiten: Jetzt werden die Geräte zu Sendern. Ferner möchten die Geräte gleichzeitig Daten senden. Wenn dies jedoch zugelassen würde, käme es zu Verwechslungen.
Eine Lösung besteht darin, Interrupt- (Unterbrechung) Leitungen hinzuzufügen. Jedes Bauelement bittet vor dem Senden von Daten über die Interrupt-Leitungen um Erlaubnis.
Es gibt zahlreiche weitere Beispiele für zusätzliche Leitungstypen, die einem Bus hinzugefügt werden können, um weitere Leistungsmerkmale zu erhalten. Es ist daher nicht überraschend, dass zahlreiche Typen von Bauelementschnittstellen existieren, die jeweils ihre eigene Kombination von Leitungen und Datenübertragungsfolgen haben.
Ferner arbeitet eine Bauelementschnittstelle zu einem Bus nicht isoliert Wenn Bauelement und Bus die höchstmögliche Geschwindigkeit zwischen sich erreichen, kann es sein, dass diese Geschwindigkeit auf Kosten anderer Komponenten oder Bauelemente geht.
Man nehme beispielsweise an, dass ein Bus einen Prozessor und einen Drucker miteinander verbindet. Es lässt sich leicht sehen, dass eine sehr schnelle Datenübertragung möglich ist, wenn der Prozessor dem Drucker seine volle Aufmerksamkeit schenkt und alle anderen Bauelemente auf dem Bus wie z. B. Plattenlaufwerke ignoriert. Bei diesem Szenario steht der Prozessor aber für andere Aufgaben nicht mehr zur Verfügung, während er sich dem Drucker widmet. Während also der Durchsatz von Druckdaten sehr hoch ist, kommen andere Aufgaben zum Stillstand.
Oder anders betrachtet, in diesem Beispiel kann der Prozessor Daten mit einer weitaus höheren Rate übertragen, als sie der Drucker drucken kann. So verbringt der Prozessor tatsächlich während des vollkommen dedizierten Druckens einige Zeit untätig, während der Drucker ausdruckt. Während dieser Zeit der Untätigkeit könnte er andere Aufgaben ausführen.
Eine Lösung zu diesem Problem ist die Verwendung von Puffern. Dies lässt sich an einem einfachen Beispiel illustrieren.
Man nehme an, der Datenbus des Senders habe eine Breite von 32 Bit, wie in Fig. 2 gezeigt wird. Man nehme an, dass der Datenbus des Empfängers kleiner ist und eine Breite von 8 Bits hat. Ein sehr grober Bauelementeadapter könnte so arbeiten, wie dies in SCHRITT 1 bis SCHRITT 4 angedeutet wird. Der Adapter überträgt Daten in Blöcken von jeweils 8 Bit. Aber ein Problem mit diesem Ansatz wird sofort offensichtlich. Während der Empfänger möglicherweise Daten mit seiner höchsten Kapazität empfängt, ist der Sender während der Aktivität des Empfängers an den Bus gebunden. Der Sender kann sonst nichts tun. Dieser Ansatz ist vom Standpunkt des Senders her ineffizient.
Wie in Fig. 3 gezeigt, kann der Adapter das gesamte 32-Bit-Wort vom Sender ergreifen und die Daten in einen Puffer setzen. Jetzt speichert der Puffer die Daten, während der Adapter sie in 8-Bit-Blöcken zum Empfänger sendet. Jetzt braucht der Sender nicht mehr darauf zu warten, dass der Empfänger die Daten empfängt.
Zum Senden von Daten in der entgegengesetzten Richtung, wobei der Empfänger Daten zum Sender sendet würde der Adapter die entgegengesetzte Folge durchführen. Der Adapter würde Daten vom Empfänger in 8-Bit-Blöcken erfassen. Wenn sich 32 Bits im Puffer angesammelt haben, sendet der Adapter die 32 Bits zum Sender.
Während der Ansatz mit Puffer eine Verbesserung gegenüber dem Ansatz ohne Puffer darstellt, kann der Ansatz mit Puffer selbst noch verbessert werden, indem Puffer der richtigen Größe für diese Umstände sowie andere Parameter gewählt werden.
Die Erfindung beinhaltet ein Verfahren zum dynamischen Konfigurieren eines Geräteadapters, um Bauelemente mit einem gemeinsamen Bus zu verbinden. Die Fig. 4 und 5 sind Ansichten der resultierenden Vorrichtung für eine solche Verbindung. Mehrere Leistungsmerkmale sind signifikant.
1. Es wird ein Bus 12 gezeigt. Der Bus ist gewöhnlich ein Systembus in einem Mikrocomputer. Die Bauelemente (Geräte) 14 kommunizieren nicht direkt mit dem Bus. Statt dessen kommunizieren die Bauelemente 14 mit einem Geräteadapter 16. Die Erfindung stellt ein Verfahren und eine Vorrichtung zum Erzeugen eines Geräteadapters 16 bereit, über den ein bestimmtes Bauelement 14 und der Bus 12 miteinander kommunizieren können. Es kann ein konfigurierbares Macro produziert werden, das die Flexibilität besitzt, einen Geräteadapter zu erzeugen, der mehrere Bauelemente unterstützt, die alle vom selben Typ oder von derselben Klasse sind, oder der Bauelemente mehrerer verschiedener Typen unterstützt. Alternativ, und als weitere Exemplifizierung der Flexibilität der vorliegenden Erfindung, kann das Macro so konfiguriert werden, dass separate Geräteadapter für jede Verbindungsvorrichtung bereitgestellt werden (ob ähnlich oder unähnlich).
2. Diese Bauelemente 14 können normale Peripheriegeräte sein, wie z. B. Plattenlaufwerke und Drucker, die normalerweise an oder in einem Computer angeschlossen werden. Außerdem können diese Bauelemente andere Vorrichtungen wie z. B. die folgenden beinhalten:
- Videoadapter
- Tastaturen und Zeigervorrichtungen
- Multimedia-Adapter
-Speicher-Controller
- Speicher- und E/A-Cache
- Kommunikationsschnittstellen und
- Schnittstellen zu anderen Bussen.
Im Prinzip gibt es keine Begrenzung für die Typen von Vorrichtungen, die als Bauelement 14 in Fig. 4 fungieren können.
3. In einer Ausgestaltung stellt der erzeugte Geräteadapter eine einzelne Last für den Bus dar. Eine Verzweigung des Einzellastkonzepts besteht darin, dass der Bus den Geräteadapter im Allgemeinen als einzelnes Bauelement behandelt. Eine Ausnahme ist die Adressierung: Zum Wählen eines der vier gezeigten Bauelemente muss der Prozessor (nicht dargestellt, aber ebenfalls mit dem Bus verbunden) eine Adresse zum Geräteadapter senden, der wiederum das entsprechende Bauelement auswählt. Würde der Geräteadapter in jeder Hinsicht vom Prozessor als einzelnes Bauelement angesehen, dann hätte der Geräteadapter lediglich eine einzige Adresse.
Als Einzellast vereinfacht der Geräteadapter einen Teil des Overheads, den der Bus sonst verursachen würde.
4. Der erzeugte Geräteadapter ist "abstimmbar". Ferner erfolgt die Abstimmung für jede Typ oder jede Klasse von Bauelementen. In der bevorzugten Ausgestaltung gibt es innerhalb des Geräteadapters Puffer (BUF), die jedem Bauelement zugeordnet sind, wie in Fig. 5 gezeigt ist. Da im Allgemeinen jedes Bauelement unterschiedliche Pufferbedürfnisse hat, wird der Geräteadapter während der Konstruktion für das beste, oder wenigstens ein gutes, Puffer-Design für jedes Bauelement optimiert.
Ferner können, auf Grund der besonderen Eigenschaften des Geräteadapters (nachfolgend erläutert) bestimmte Leistungsmerkmale der Puffer geändert werden, ohne dass andere Schaltungsteile im Geräteadapter geändert werden müssen.
5. Daten und Steuerung sind im Macro getrennt. Schnittstellensteuermechanismen werden unabhängig von den Datenpfaden im Macro vorgegeben. Durch eine unabhängige Vorgabe der Datenpfade können die Steuersignalschnittstellen zwischen Funktionsblöcken auf eine Reihe verschiedener. Datenaustauschvorgänge ohne spezielle Steuerstrukturen wirken. Zum Beispiel, der Transfer von Daten zu/von einer Schnittstelle kann auf ähnliche Weise gesteuert werden, unabhängig von der Länge des Datentransfers. Die vertragsgemäß arbeitenden Steuerschnittstellen können die Mechanismen bereitstellen, um den Datenaustausch ohne Rücksicht auf den Dateninhalt einzuleiten, zu beenden und zu überwachen.
Es kann eine Computerliste für die Software (d. h. Macro) erstellt werden, die zur Erstellung und Erzeugung eines konfigurierbaren Geräteadapters verwendet wird. Das Macro erfordert einen VHDL-Kompilierer. VHDL- Kompilierer sind im Handel erhältlich. VHDL ist eine Abkürzung, die sich auf die VHSIC-Hardware-Beschreibungssprache bezieht. VHSIC ist eine Abkürzung, die Very High Speed Integrated Circuit (äußerst schnelle integrierte Schaltung) bedeutet.
Für diesen Zweck wird ein kommerziell erhältlicher VHDL-Kompilierer eingesetzt, der als V-System VHDL Simulator and Compiler Platform Revision 2.5 bezeichnet wird und von Model Technology aus Beaverton, Oregon, erhältlich ist.
Bei der Konstruktion eines kundenspezifisch angepassten Geräteadapters wird das Macro auf zweierlei Weise verwendet, nämlich (1) beim Synthetisieren eines Logikdiagramms auf Gate-Ebene, und (2) beim Simulieren der Schaltung.

Synthese

Zur Durchführung der Synthese führt ein Benutzer folgende Tätigkeiten aus:
1. Der Benutzer gibt die folgenden Parameter vor:
- die Breite der Bauelementschnittstelle (z. B. 8, 16 oder 32 Bit);
- die Adressgröße (d. h. die Anzahl der Bits) der Bauelementschnittstelle;
- die Tiefe des Puffers im Geräteadapter (Anzahl der Bits). Die Puffer werden nachfolgend ausführlicher erläutert.
- Pufferpackung.
Diese Parameter werden vorgegeben, indem sie in die Datei des Macros mit der Bezeichnung PCIMACRO_USER_PARAMS.VHD eingefügt werden.
2. Der Benutzer kann das Design mit Hilfe einer im Handel erhältlichen Synthesemaschine kompilieren, wie z. B. dem Design Analyzer 3.0c, der von Synopsis Incorporated, Mountain View, Kalifornien, erhältlich ist. Für die Kompilierung muss der Benutzer die Macro-Dateien, die später in Tabelle 2 beschrieben werden, in der folgenden Reihenfolge laden:
pcimacro_user_params.vhd, macro_pkg.vhd,
configurable_bit_reg.vhd, configurable_dword_reg.vhd,
clktree.vhd, signaltree.vhd, burst_size_entr.vhd,
next_addr_cmpr.vhd, new_transfer_counter.vhd,
control_reg.vhd, dm_bk_sm.vhd, dm_fe_sm.vhd,
data_manager.vhd, address_counter.vhd, devsel_timer.vhd,
master_latency_timer.vhd, parity36.vhd,
target_latency_timer.vhd, master_state_machine.vhd,
slave_state_machine.vhd, pci_fsm.vhd, cycler.vhd,
cc_bk_sm.vhd, cc_bypass_sm.vhd, cc_fe_sm.vhd,
cycle_controller.vhd, dpr_gen.vhd, pipeline_block.vhd,
valid_data_counter.vhd, address_pointer.vhd,
buffer_element.vhd, memory_element.vhd, output_latch.vhd,
new_fifo.vhd, fifo.vhd, byte_steering_logic.vhd,
bist_reg.vhd, class_code_reg.vhd, command_reg.vhd,
device_id_reg.vhd, header_reg.vhd, interrupt_line_reg.vhd,
interrupt_pin_reg.vhd, max_lat_reg.vhd, min_gnt_reg.vhd,
revision_id_reg.vhd, status_reg.vhd, vendor_id_reg.vhd,
high_bit_reg.vhd, base_address_reg.vhd,
rom_base_address_reg.vhd,
miscelaneous_configuration_regs.vhd, config.vhd,
bk_end.vhd, pci_macro.vhd, nan2.vhd, dffpq.vhd, dffrpq.vhd,
or2.vhd, hbuf.vhd, sbuf.vhd, inbuf.vhd, inpd.vhd, inv.vhd,
iobuf.vhd, iobufpci.vhd, iopd16.vhd, iopd12sl.vhd,
iobuf_iopd12sl.vhd, opd16.vhd, otpd16.vhd, bus_hbuf.vhd,
bus_inbuf.vhd, iopdpci.vhd, bus_inv.vhd, bus_opd16.vhd,
iobuf_iopd16.vhd, configured_pci_macro.vhd
Das Syntheseprodukt ist ein Diagramm auf Gate-Ebene oder eine Netzliste. Eine Netzliste ist eine Beschreibung der Art und Weise, in der Gate- Zellen miteinander verbunden sind. Eine beispielhafte Netzliste lautet wie folgt:
AND1 2 4 10
OR1 10 12 14
Diese Liste zeigt, dass das AND-Gate 1 zwei Eingänge hat; einer ist mit dem Knoten 2, der andere mit dem Knoten 4 verbunden. Der Ausgang ist mit dem Knoten 10 verbunden. Die Liste zeigt, dass das OR-Gate 1 zwei Eingänge hat, einen, der mit dem Knoten 10 verbunden ist (der der Ausgang des AND- Gates ist), und einen, der mit dem Knoten 12 verbunden ist. Der Ausgang ist mit dem Knoten 14 verbunden.
Somit entsteht mit Hilfe der Synthesemaschine zusammen mit dem Macro und den vorgegebenen Parametern ein Diagramm auf Gate-Ebene. Synthese erfordert eine Zellenbibliothek, die die Bausteine für die Schaltung auf Gate-Ebene enthält. Eine gewählte Zellenbibliothek wird für eine bestimmte Technologie verwendet (z. B. CMOS, bipolar usw.). Zellenbibliotheken sind im Handel erhältlich und in der Technik bekannt. Die bevorzugte Zellenbibliothek ist die gemäß Standard NCR VS500, die von AT&T Global Information Solutions Company in Dayton, Ohio, erhältlich ist.
Dieses Diagramm auf Gate-Ebene wird letztendlich in ein oder mehrere integrierte Schaltungen und/oder Karten umgesetzt, die den Geräteadapter ausführen.
Vor dem Herstellen der integrierten Schaltungen müssen zwei Simulationstypen durchgeführt werden. Eine Funktionssimulation wird vor und eine Simulation auf Gate-Ebene nach der Synthese durchgeführt. Zur Durchführung der Funktionssimulation gibt der Benutzer die Parameter vor, wie im obigen Syntheseschritt, und kompiliert und simuliert dann das Macro mit einem Kompilierer/Simulator wie der V-System VHDL Simulator and Compiler Platform, die von Model Technology, Beaverton, Oregon, erhältlich ist. Die Simulation auf Gate-Ebene wird nach der Synthese durchgeführt, um Testvektoren zu erzeugen, die beim Prüfen der Schaltung nach der Herstellung verwendet werden. Zum Durchführen einer Simulation auf Gate-Ebene wird ein Diagramm auf Gate-Ebene oder eine Netzliste (wie im Syntheseschritt erzeugt) in einen physikalischen Design-Simulator wie z. B. den Verilog Simulator eingegeben, der von Cadence Design Systems Inc., San Jose, Kalifornien, erhältlich ist (deren eingetragene Dienststelle sich in Lowell, Massachusetts befindet).
Nach Synthese und Simulation wird die im Syntheseschritt erzeugte Netzliste von einem Routing-Programm wie z. B. Tancell Version 2.4.0 verarbeitet, das ebenfalls von Cadence Design Systems erhältlich ist. Das Routing-Programm erzeugt eine Repräsentation in Maschinensprache von jeder Schicht der herzustellenden integrierten Schaltung. In der Tat erzeugt der Routing-Schritt mehrere Layout-Diagramme, die jeweils eine unterschiedliche Topologieebene der herzustellenden integrierten Schaltung beschreiben.
Das Ergebnis des Routing-Schrittes ist eine Datenbank. Diese Datenbank wird dann verwendet, um die bei der Herstellung der integrierten Schaltungen verwendeten Masken mit in der Technik bekannten Methoden zu erzeugen.
Nach dem Erzeugen der Masken werden eine oder mehrere integrierte Schaltungen mit in der Technik weit verbreiteten Methoden hergestellt. Der allgemeine Prozessablauf ist wie in Fig. 12 illustriert. Es ist zu bemerken, dass auch Adapterkarten mit ähnlichen physikalischen Layout-Design-Tools und in der Technik allgemein bekannten Methoden hergestellt werden können.
Fig. 5 zeigt eine Übersicht über das resultierende Schema auf Gate- Ebene, bei dem die Gates nach Aufgaben oder Funktionen gruppiert sind. Das heißt für jeden untergeordneten Geräteadapter:
- eine Gruppe von Gates arbeitet als Datenmanager (DATA MGR);
- eine Gruppe von Gates arbeitet als Puffer (BUFFER);
- eine Gruppe von Gates arbeitet als Zyklussteuerlogik (CYCLE CONTROL); und
- eine Gruppe arbeitet (bei Bedarf) als Benutzerlogik (USER LOGIC). Wie Fig. 5 zeigt, hat jeder untergeordnete Geräteadapter 18 seinen eigenen Datenmanager 20, Puffer 22 und Zyklus-Controller 24, die alle im Syntheseschritt erzeugt wurden. Die optionale Benutzerlogik 26 wird vom Benutzer unabhängig vom Macro definiert, um ein bestimmtes Bauelement 14 an die Back-End-Schnittstelle 28 des untergeordneten Geräteadapters 18 anzupassen. Die Benutzerlogik umfasst Dinge wie einfache Gattersteuerung, bauelementspezifische Logik oder andere besondere Anforderungen wie z. B. die Synchronisierung aller Signale, die an die Back-End-Schnittstelle angelegt oder von dieser empfangen werden (wenn für ein bestimmtes Bauelement notwendig). Darüber hinaus erzeugt das Macro eine einzelne Finite-State- Machine (FSM = Maschine endlicher Zustände) 30, die sich mit allen Datenmanagern für eine integrierte Schaltung oder Karte 16 eines bestimmten Geräteadapters befasst.
Die Blöcke von Fig. 5 arbeiten im Allgemeinen wie folgt (einige Ausnahmen werden später angeführt).
Der Datenmanager 20 steuert die Datenübertragungen zwischen dem Bus 12 und dem Puffer 22. Das heißt, der Bus 12 befasst sich (über die Finite- State-Machine) mit dem Datenmanager. Der Datenmanager hat drei Steuerzeilen (Request (= Anforderung), Acknowledge (= Bestätigung) und Interrupt (= Unterbrechung)), die über die Busschnittstelle 13 mit dem Bus verbunden sind, sowie einen internen Bus 15, der mit der Finite-State-Machine 30 gekoppelt ist.
Der Puffer 22 speichert die Daten vorübergehend. Der Puffer ist vorzugsweise ein FIFO-Puffer.
Die Zyklus-Steuerlogik 24 steuert die Datenübertragungen zwischen dem Back-End-Bauelement 14 und dem Puffer. Das heißt, das Bauelement befasst sich (möglicherweise über die Benutzerlogik) mit der Zyklus-Steuerlogik. In einem Sinne wirken der Datenmanager und die Zyklus-Steuerlogik zur Durchführung von Datenübertragungen zusammen: Der Erstere befasst sich mit dem Bus, die Letztere befasst sich mit dem Back-End-Bauelement.
Eine einzelne Finite-State-Machine 30 steuert alle Datenmanager 20 für eine bestimmte IC oder Karte 16. Die Primärfunktion der Finite-State-Machine besteht darin, über Konflikte zwischen Bauelementen 14 zu entscheiden. Das heißt, wenn zwei Bauelemente 14 versuchen, gleichzeitig mit dem Bus 12 zu kommunizieren, dann befiehlt die Finite-State-Machine einem von ihnen zu warten.
Das Macro setzt sich aus einem Satz von Funktionsblöcken zusammen (z. B. Finite-State-Manager, Datenmanager, Puffer, Zyklus-Controller), die an sich erweiterbar sind. Die Schnittstellen zwischen diesen Funktionsblöcken sind vertragsgemäße oder regelbasierende Schnittstellen mit veränderlichem/n Timing und Wortbreitenspezifikationen. So könnte beispielsweise ein Pufferblock so konfiguriert werden, dass er entweder ein 1 Byte tiefes FIFO oder ein 4 KB tiefes FIFO hat, ohne die Schnittstellenverträge/-regeln zu ändern. So kann ein veränderlicher Datenbreitenpfad für Puffer konfiguriert werden, ohne dass der Zyklus-Controller-Schnittstellenvertrag geändert werden müsste. Auf diese Weise könnte der Zyklus-Controller seine Funktionen weiter auf datenunabhängige Weise ausführen.
Daten und Steuerung sind innerhalb des Macros getrennt. Schnittstellensteuermechanismen werden unabhängig von den Datenpfaden im Macro vorgegeben. Durch eine unabhängige Vorgabe der Datenpfade können die Steuersignalschnittstellen zwischen Funktionsblöcken auf eine Reihe verschiedener Datenaustauschvorgänge ohne spezielle Steuerstrukturen wirken. Zum Beispiel: Der Transfer von Daten zu/von einer Schnittstelle kann auf ähnliche Weise unabhängig von der Länge des Datentransfers gesteuert werden. Die vertragsgemäß arbeitenden Steuerschnittstellen stellen die Mechanismen bereit, um den Datenaustausch ohne Rücksicht auf den Dateninhalt einzuleiten, zu beenden und zu überwachen. Das heißt, der Datenstrom enthält keinerlei Steuervorgänge. Alle Steuervorgänge, die mitwirkende Funktionsblöcke beinhalten, sind in den Steuerschnittstellen enthalten.
Der separate Daten- 25 und Steuerpfade 27 aufweisende interne Bus ist in Fig. 6 dargestellt. Der interne Bus 32 ist mit internen Schnittstellen (I/F) für die Funktionsblöcke Finite-State-Machine 30, Datenmanager 20, Puffer 22 und Zyklus-Controller 24 gekoppelt. Die externe Busschnittstelle 13 wurde ebenfalls im Hinblick auf Daten und Steuerung getrennt, wie durch die dünnen (Steuerung) und dicken (Daten) Linien zwischen FSM 30 und Bus 12 angedeutet ist. Die exportierte I/F 29 entspricht der Konglomeration aller Back- End-Schnittstellen 28 von Fig. 5. Fig. 6 zeigt auch mehrere Instanziierungen für die verschiedenen Funktionsblöcke (mit Ausnahme von FSM, wovon nur eine für einen bestimmten Geräteadapter existiert, wie zuvor beschrieben wurde). Jede Instanziierung eines Funktionsblocks hat auch eine Schnittstelle I/F, die den jeweiligen Funktionsblock mit dem internen Geräteadapterbus verbindet.
Es folgt eine ausführliche Beschreibung jedes Funktionsblocks von Fig. 5.

Busschnittstelle/Finite-State-Machine

Das Macro erzeugt eine einzelne Busschnittstelle für einen bestimmten Geräteadapter. Diese Busschnittstelle ist die elektrische Schnittstelle zwischen dem Bus 12 und der Geräteadapter-IC oder -Karte 16. Die Busschnittstelle verbindet den Bus mit einer Finite-State-Machine 30, die den Datenfluss zwischen dem Bus und dem/den Datenmanager(n) verwaltet. Die Hauptkomponente der Busschnittstellenfunktion befindet sich in dem Modul mit der Bezeichnung PCI_FSM (oder Front-End-Bus-Finite-State-Machine). Es gibt zwei unabhängige Zustandsmaschinen in der Finite-State-Machine 30, die für Busschnittstellenvorgänge verantwortlich sind, eine für Slave-Vorgänge und eine für Master-Vorgänge. Jede Master/Slave-State-Machine führt Busschnittstellenfunktionen aus.
Ein Beispiel für die Slave-State-Machine: Wenn sich der Bus 12 in einer Adressierphase befindet, zeigt die Konfigurationslogik (wie durch die config.vhd Macro-Datei erzeugt) an, dass auf ein Back-End-Bauelement zugegriffen wird. Sobald ermittelt wurde, dass der Zugriff auf eine der Back-End- Bauelementschnittstellen zum Macro gehört, wird die Adresse auf dem Bus in ein internes Adressregister in der Finite-State-Machine geladen. Die Buszyklen werden dann in interne Steuersignale für den internen Bus 32 von Fig. 6 umgesetzt. Für jede nachfolgende Datenphase muss die Konfigurationslogik weiterhin die interne Adresse validieren.
Wenn ein Back-End-Bauelement 14 den Bus anfordert und erhält, gibt die Master-State-Machine die interne Adresse auf den Busdatenpins aus und drückt die richtigen Bussignale zum Starten eines Bustransfers auf. Wenn die Finite-State-Machine einen gültigen Buszyklus erfasst, beginnt die Finite-State- Machine mit der Ausgabe von Datenphasen zum Bus 12.
Die einzige Macro-Ressource, die mehrere Datenmanager und Zyklus- Controller-Schnittstellen gemeinsam nutzen, ist die Finite-State-Machine 30. Dadurch wird gewährleistet, dass nur eine Back-End-Ressource zum entsprechenden Zeitpunkt Buszugang erhält. Wenn die Busressource belegt ist, werden Rücksetzsignale zu Back-End-Bauelementen ausgegeben.

Datenmanager/Zyklus-Controller-Paare

Der untergeordnete Geräteadapter 18 ist so strukturiert, dass Zyklussteuer- und Datenmanagementeinrichtungen paarweise arbeiten. Somit erfordert jede Back-End-Schnittstelle 28, die für einen bestimmten untergeordneten Geräteadapter 18 realisiert wurde, die Parametrisierung und Einbeziehung eines Blockpaares aus Datenmanager 20 und Zyklus-Controller 24 (zusammen mit Pufferblock/Pufferblöcken). Datenübertragungen zu/von mit untergeordneten Geräteadaptern konfigurierten Puffern und den Front- und Back-End-Bussen erfolgen über Datenmanager und Zyklus-Controller durch vertragsgemäße Schnittstellen.
Jeder im Macro konfigurierte Puffer erfordert einen separaten Datenmanager. Wenn eine Konfiguration gewünscht wird, bei der die LESE/SCHREIB-Puffer getrennt und unabhängig sein sollen, sind zwei Datenmanager notwendig, einer für die LESE-Richtung und ein anderer für die SCHREIB-Richtung. Die Zyklus-Controller-Einrichtung übernimmt alle Datenübertragungen zu/von internen Puffern und der Back-End-Schnittstelle durch ihre vertragsgemäßen Schnittstellen mit anderen zusammenwirkenden Funktionsblöcken oder exportierten Schnittstellen. Auf diese Weise können die Datenpfade unabhängig von den Steuerpfaden vorgegeben werden, so dass die Datenpfade breitenmäßig so konfiguriert werden können, dass sie Bauelemente mit vielen Breiten unterstützen, ohne dass Steuerschnittstellen geändert werden müssten. Ebenso kann auch die Pufferung für solche Datenpfade konfiguriert werden, ohne dass Steuerschnittstellen geändert werden.

PUFFER

Da die Macro-Architektur konfiguriert und umfangreich ist, können die Puffermanagementeinrichtungen des Macros für mehrere Pufferungsoptionen parametrisiert werden. Im Allgemeinen muss die Tiefe interner Pufferung auf der Basis von Systembeschränkungen, Buslatenz, Interrupt-Service-Overhead, Cache-Line-Größe, Geräte-Kompliment und allgemeinen Systemleistungszielen entschieden werden. Somit implementiert das Macro Mechanismen zum Abstimmen der Pufferung, um Systemziele zu erreichen. Puffer sind FIFO-Organisationen und nicht direkt adressierbar. "Fast voll" und "Fast leer" Flags können programmiert werden. Puffer haben zwei Ports. Die folgenden Regeln gelten für die Pufferdimensionierung:
1. Puffer können Breiten von 8, 16 und 32 Bits haben. Wird Pufferpackung gewünscht, muss die Pufferbreite 32 Bit betragen.
2. Wenn geteilte Sende- und Empfangsdatenpfade (d. h. unidirektionale Puffer) gewünscht werden, muss die Zahl der Puffer in jedem Pfad gleich sein (d. h. die Zahl der Lese- und Schreib-Puffer muss gleich sein).
3. Jede individuelle Puffertiefe muss den Exponenten 2 haben, und alle Puffer für jeden unidirektionalen Pfad müssen gleich groß sein.
4. Die Puffertiefe muss größer als die oder gleich der im Datenmanager programmierte(n) Bustransfergröße sein.
5. Die "Fast voll" und "Fast leer" Flags müssen gleich sein, jeweils gleich beurteilt für jeden unidirektionalen Puffer, und müssen in ganzzahligen Vielfachen der Bustransfergröße bemessen sein (d. h. Cache-Line-Größe als Beispiel). Pufferbreiten sind erweiterbar in 8, 16 und 32 Bits. Direktzugriffe auf Back-End-Bauelemente müssen mit der Datenbreite des Back-End- Bauelementes im Einklang stehen.
Für Fälle, bei denen separate Lese- und Schreibpuffer gewünscht werden, müssen die Adressen für Lese- und Schreibvorgänge von den Back- End-Schnittstellen (gewöhnlich von Back-End-Bauelementen ausgegeben) parallel zu den Daten für dieselben Zyklen gepuffert werden. So kann der Datenmanager sich von Neuversuchen und Abbrüchen erholen, die auf dem Bus von anderen Masters oder Zielen ausgegeben werden.
Der Datenmanager steuert die Bewegung von Daten zu/von dem PCI- Bus zu/von Puffern unabhängig von der Datenbreite. Größenfehlübereinstimmungen zwischen Busbreite und Back-End werden nicht toleriert, ausgenommen bei Pufferpackung. Auch Byte-Freigaben werden in Puffern zum Leiten gespeichert.
Die Pufferpackung erfolgt auf Byte-Basis, um den 32-Bit-Bus zu nutzen. Der Puffer wird wie folgt gepackt:
2 Bytes pro 16-Bit-Datenfeld mit 2-16-Bit-Datenfeldern pro 32-Bit-PCI- Wort
4 Bytes pro Doppelwort mit 32-Bit Busbreite
Es werden keine anderen Byte-Packungsoptionen unterstützt. Pufferpackung erfolgt vor dem Pufferfüllen, so dass sich die Daten im Puffer in der gepackten Reihenfolge für die Übertragung zum Bus befinden oder sich im Puffer zum Auspacken und Leiten zur Back-End-Schnittstelle befinden. An der Back-End-Schnittstelle wird keine Pufferpackung unterstützt.
Es werden mehrere Pufferungskonfigurationen für den FIFO unterstützt, die Konfiguration geschieht wie folgt:
1. Wie in Fig. 7 gezeigt, können Puffer als unidirektionales Lesen/Schreiben (d. h. ein Puffer) konfiguriert werden.
2. Wie in Fig. 8 gezeigt, können Puffer als separate Lese- und Schreibpuffer konfiguriert werden (d. h. 2 separate Puffer).
3. Wie in Fig. 9 gezeigt, können mehrere Puffer (Puffer 0-n) als Pingpong- oder Kreispuffer konfiguriert werden (d. h. 2 oder mehr Puffer für Lesen und 2 oder mehr Puffer für Schreiben).

Back-End-Schnittstellen

Jede Back-End-Schnittstelle ist eine generische Adress- und Datenschnittstelle. Das Konzept der "generischen" Adress- und Datenschnittstellen ist als ein Satz von Signalen definiert, die notwendig sind, um Back-End-Verbindungen zu Bauelementen herzustellen. Es gibt mehrere Arten von generischen Schnittstellen, die konfiguriert werden können. Dazu gehören Mastering-Schnittstellen, die Anforderungs-/Gewährungs-Protokolle benutzen, Mastering-Schnittstellen, die Halte- und Halten-Bestätigen-Protokolle benutzen, DMA-Slave-Schnittstellen, die Anforderung/Gewährung für Slave- Operation-Protokolle verwenden, und einfache Slave-Schnittstellen, die Direktzugriffsprotokolle verwenden. Jede Back-End-Schnittstelle kann mit einem beliebigen Typ der oben beschriebenen "generischen" Schnittstellenmechanismen konfiguriert werden. Außerdem können auch die datenspezifischen Charakteristiken eines Bauelementes konfiguriert werden, wie z. B. Datenbreite, Adressbreite, Byte-Freigabe-Breite usw. Dies erfolgt durch eine entsprechende Einstellung der vom Benutzer vorgegebenen Parameter in der Datei PCIMACRO_USER_PARAMS.
Die exportierten Back-End-Schnittstellen sind generische Adress- und Datenbusse, wie oben beschrieben. Es werden separate Ein- und Ausgangsadress- und -datenbusse bereitgestellt. Diese Busse sind geteilt und völlig synchron und werden in der bevorzugten Ausgestaltung ständig angesteuert. Asynchrone Schnittstellen müssen im Benutzeroberflächenlogikblock extern zum Macro untergebracht werden. Es werden keine Tristate-Busse vom Macro exportiert. Dies bedeutet, dass die Signalzustände ständig auf einen bekannten Logikwert angesteuert werden (entweder 0 oder 1).
Ein geteilter Bus bedeutet, dass der Dateneingangsanschluss und der Datenausgangsanschluss separate Signalpfadsätze benötigen. Dies steht im Gegensatz zu einem Tristate-Bus. Bei einem Tristate-Bus gibt es nur eine einzige Datenpfadverbindung, bei der die Richtung einwärts oder auswärts sein kann. Der geteilte Bus gilt auch für die Adresspfadverbindungen und die Byte- Freigabe-Pfadverbindungen.
Der Zyklus-Controller ist für alle Back-End-Schnittstellenvorgänge verantwortlich. Die vom Zyklus-Controller unterstützten Zyklustypen sind nachfolgend identifiziert und beinhalten Slave-Back-End, Slave-DMA (Einzelzyklus), Slave-DMA (Mehrfachzyklus), Master-Back-End-Schnittstelle, DMA (Einzelzyklus) und DMA (Mehrfachzyklus).
Slave-Zyklen werden vom Macro für 8, 16 und 32 Bit Schnittstellen unterstützt. Slave-Zyklen sollen von abwechselnden Mastern auf dem Bus ausgegeben werden. Es werden keine anderen Peer-to-Peer-Slave-Zyklen unterstützt als diejenigen, die für den Bus bestimmt sind. Es werden keine Back-End-Peer-to-Peer-Slave-Zyklen unterstützt. Lese- und Schreibzyklen, ob DMA-gerichtet oder nicht, werden an der Back-End-Schnittstelle unterstützt. Direkte Slave-Zyklen werden so konfiguriert, dass sie bei Bedarf den internen FIFO umgehen. Bei der Ausführung ist in diesem Fall Vorsicht geboten, da das Macro kein Datenintegritätsmanagement übernimmt, ausgenommen für Daten, die zu den internen Puffern übertragen werden, und keine Übertragungen zu Back-End-Schnittstellen außer der Reihe unterstützt.
Back-End-Einzelzyklus-DMA-Slave-Zugriffe werden vom Zyklus- Controller unterstützt. Der Zyklus-Controller überwacht Back-End- Busumkehrungen und DMA-Slave-Zyklusabbrüche beim Übertragen von Daten in besondere FIFO-Organisationen. Es werden DMA-gerichtete LESE- und SCHREIB-Vorgänge unterstützt.
Slave-gerichteter Mehrzyklus-DMA wird vom Zyklus-Controller für Back- End-Schnittstellen unterstützt. Mehrzyklus-DMA erfordert, dass die Back-End- Schnittstelle die Eigentümerschaft über den Bus für die Dauer der Übertragung behält. Wann immer die Kontrolle über die Back-End-Schnittstelle aufgegeben wird, wird davon ausgegangen, dass der aktuelle DMA-Zyklus beendet wurde. Der nächste Neustart eines Mehrzyklus-DMA erfordert eine erneute Entscheidung für den Bus sowie eine mögliche Neuprogrammierung der Datenmanager-DMA-Register.
Master-Bauelemente werden als Back-End-Schnittstelle unterstützt. Master können mit voller Pufferunterstützung oder mit minimaler Unterstützung oder ohne Pufferung konfiguriert werden. Hochentwickelte Master, die integrierte DMA-Fähigkeit besitzen, sollen möglicherweise einen einfachen Datenmanager verwenden, der in einem Pufferumgehungsmodus laufen könnte, so dass er einen geringeren Einfluss auf den Betrieb hat. Ein Datenmanager/Zykluscontroller-Paar wird weiterhin benötigt, aber die Master- DMA-Einzelzyklen bewirken eine PCI-Entscheidung für jeden Back-End Schnittstellen-DMA-Einzelzyklus. Dies gilt sowohl für Lese- als auch für Schreib-DMA-Zyklen.
Es werden Mehrzyklus-DMA-Back-End-Zyklen unterstützt, bei denen sowohl Adressen als auch Daten in den internen Puffern gespeichert sind.
Die Back-End-Schnittstelle hat einen Datenpfad, dessen Breite konfigurierbar ist, so dass Bauelemente mit 8, 16 und 32 Bit Datenpfaden unterstützt werden können. Interne Datenpfade reflektieren die Datenbreite des Back-End-Bauelementes in allen Fällen, ausgenommen dort, wo Pufferpackung freigegeben ist.
Es ist auch möglich, die Datenpfade so zu konfigurieren, dass sie Pufferung einschließen. Dies erfolgt dadurch, dass der Benutzer in der Datei PCIMACRO_USER_PARAMS die Zahl der gewünschten Puffer und die Tiefe jedes Puffers vorgibt.
Auch die Breite des Back-End-Adressbusses wird für das Bauelement konfiguriert, mit dem eine Verbindung hergestellt werden soll. Es werden address_in und address_out Busse bereitgestellt.
Es werden sowohl Master- als auch Slave-Bündelübertragungen unterstützt, und zwar wie folgt:
Für eine Master-Bündelübertragung werden Schreibvorgänge auf den Bus von Back-End-Masters auf zweierlei Weise präsentiert:
1) Für nicht aufeinanderfolgende Adressen (Adresse und Daten in internen Puffern gespeichert) stellt sich jeder Schreibvorgang als Einzelzyklus dar.
2) Für aufeinanderfolgende Adressen ist der Schreibvorgang ein Bündel über den Bus in einer Bündelübertragung.
Für eine Slave-Bündelübertragung benötigen Übertragungen zu Back- End-Schnittstellen lediglich Datenpufferung, es sei denn, das Back-End hat auch Adressierungsanforderungen. Direktzugriffe umgehen die internen Puffer. Direktzugriffe haben Priorität gegenüber gepufferten Zugriffen.
Das folgende Beispiel illustriert wichtige Grundsätze der vorliegenden Erfindung. Man nehme an, das Bauelement sei ein Drehpositionsgeber, der ein Acht-Bit-Wort erzeugt, das die Drehposition einer Welle angibt. Ein Mikrocomputer, der einen Bus beinhaltet, möchte die Acht-Bit-Nummer zu verschiedenen Zeitpunkten feststellen.
Ein Geräteadapter wird unter Verwendung des oben erläuterten Macros hergestellt und installiert. Um die Acht-Bit-Nummer zu erhalten, setzt der Mikrocomputer die Adresse des Bauelementes (d. h. des Drehpositionsgebers) auf den Bus. Die Finite-State-Machine im Geräteadapter wählt das Datenmanager/Zykluscontroller-Paar entsprechend dem Bauelement aus.
Der Zyklus-Controller weist die Benutzerlogik an, das Acht-Bit-Wort im Positionsgeber zu lesen (die für dieses Ereignis jeweils nötige Signalsequenz ist abhängig vom verwendeten Geber). Die Benutzerlogik spricht an, liest den Positionsgeber und lädt das Acht-Bit-Wort in den Puffer. Der Datenmanager sieht das Acht-Bit-Wort im Puffer und fragt an, ob sich weitere Bauelemente um den Bus bewerben. Gibt es keinen Konflikt, dann setzt der Datenmanager das Acht-Bit-Wort auf den Bus. Der Prozessor des Mikrocomputers hat jetzt Zugang zur Drehposition. Wenn der Mikrocomputer ein Update der Positionsinformationen wünscht, dann wiederholt er diese Folge.

Weitere Überlegungen

1. Der im gestrichelten Kasten 16 von Fig. 5 angedeutete Geräteadapter kann auf einer Erweiterungskarte wie in Fig. 10 gezeigt konstruiert werden. Diese Erweiterungskarte kann dann in einen Erweiterungssteckplatz in einem Mikrocomputer eingesteckt werden, wie in Fig. 11 gezeigt wird. Wie in der Technik bekannt ist, handelt es sich bei dem Erweiterungssteckplatz tatsächlich um einen Randstecker, der zum Systembus des Computers führt. Die Erweiterungskarte enthält mehrere C-Stecker 34, wie in Fig. 10 gezeigt ist, einen für jedes anzuschließende Bauelement. Wenn sich die Benutzerlogik in Fig. 5 auf der Erweiterungskarte selbst befindet, bietet die Erweiterungskarte unterschiedliche Schnittstellen für jedes Bauelement. Jede Schnittstelle wird durch einen der in Fig. 10 gezeigten C-Stecker repräsentiert.
Alternativ kann der Geräteadapter 16 von Fig. 5 auf der Systemplatine des Computers installiert werden, wie in Fig. 11 gezeigt ist. Die Geräteadapteranschlüsse erfolgen direkt mit dem Systembus (d. h. Bus 12 von Fig. 5). Bauelemente werden mit traditionellen Verbindungstechniken wie beispielsweise einem Flachbandkabel an der Systemplatine angeschlossen.
Der im gestrichelten Kasten 16 von Fig. 5 gezeigte Geräteadapter kann auf einer einzelnen integrierten Schaltung (IC) oder einem Mehrchipmodul (MCM) konstruiert werden, wenn die angeschlossenen Bauelemente auf eine relativ geringe Zahl begrenzt werden, so dass die verfügbaren E/A-Pins einer solchen IC oder eines solchen MCM nicht überschritten werden. Diese(s) IC oder MCM könnte dann wie oben beschrieben installiert werden (z. B. auf der Systemplatine oder der Erweiterungskarte).
2. Fig. 5 illustriert Benutzerlogik, die zum Anpassen eines bestimmten Bauelementes an die Back-End-Schnittstelle verwendet wird. Existierende Bauelemente können wie folgt mit dem Macro verbunden werden:
A. Ersetzen der existierenden Spezifikationen für den Bus durch solche für die Back-End-Schnittstelle.
B. Ersetzen der existierenden Spezifikationen für die Back-End- Schnittstelle durch diejenigen für die Bauelementschnittstelle.
Nach dem Austauschen dieser Spezifikationen, was die Modifikation der Dateien cycle_controller-vhd und bk_end.vhd beinhaltet, entspricht die Back- End-Schnittstelle den Eigenschaften des Bauelementes.
3. Der Geräteadapter verbindet die Bauelemente von Fig. 5 mit dem Bus. Der Bus kommuniziert mit den jeweiligen Puffern (über die jeweiligen Datenmanager der Puffer) zu unterschiedlichen Zeiten.
4. Eine bestimmte Charakteristik des Macros ist wichtig. Das Macro erzeugt Designs, damit Datenmanager, Puffer und Zyklussteuerlogik mit der Back-End-Schnittstelle kompatibel sind. Diese Kompatibilität besteht auch dann noch, wenn die Parameter für die Puffer verändert werden und das Macro ein zweites Mal abgearbeitet wird, sodass eine zweite Funktionsblock- Logikschaltung entsteht. Die zweite Schaltung ist weiter mit der Back-End- Schnittstelle und mit der vorherigen Zyklussteuerlogik kompatibel.
5. Das Macro ermöglicht die Spezifikation der folgenden Datenmanagertypen:
0 Back-End-Slave-Bauelement, ungepuffert (praktisch keine DATA MANAGER Funktionalität).
1 Bidirektionale Slave-DMA-Maschine (einschließlich Peer-to-Peer)
2 Slave-DMA-Maschine zum Schreiben auf den Bus 12
3 Slave-DMA-Maschine zum Lesen vom Bus 12
4 Ungepufferter Master, Lesen und Schreiben (einfache Datenmanager- Funktionalität)
5 Gepufferter Lese-Master, Direktzugriff
6 Gepufferter Lese-Master, sequenzieller Zugriff
7 Gepufferter Schreib-Master, Direktzugriff
8 Gepufferter Schreib-Master, sequenzieller Zugriff
9 Gepufferter bidirektionaler Master, sequenzieller Zugriff.
6. In der bevorzugten Ausgestaltung ist der Bus 12 ein PCI-Bus, der die folgenden Signale trägt, wie ausführlicher in Peripheral Component Interconnect Specification Rev 2.0 - 30. April 1993, und in PCI IDE Addendum Rev 0.6 (in Überarbeitung durch das PCI SIG Committee) vom 12. Januar 1994 (beide von PCI Special Interest Group, 5200 N. E. Elam Young Parkway, Hillsboro, Oregon 97124 erhältlich) beschrieben ist, die beide hiermit durch Bezugnahme als Hintergrundmaterial eingeschlossen sind.
CLK:
PCI-Systemtakteingang
RST#:
PCI Reset. Alle PCI-Bauelementausgangssignale werden asynchron auf drei Zustände angesteuert.
AD(31 : 0):
PCI-Adresse und Daten multiplexiert
C_BE(3 : 0):
PCI-Busbefehl und Byte-Freigaben multiplexiert
PAR:
PCI-Parität
FRAME#:
Zyklusrahmen, der vom aktuellen Bus-Master angesteuert wird und Beginn und Dauer eines Buszugriffs vorgibt.
IRDY#:
Initiator bereit, was die Fähigkeit des einleitenden Bus-Masters anzeigt, die aktuelle Transaktionsdatenphase zu beenden. Damit eine Datenphase beendet werden kann, müssen IRDY# und TRDY# beide an einer Taktflanke aktiv sein.
TRDY#:
Ziel bereit, was die Fähigkeit eines Zielagenten anzeigt, eine Transaktionsdatenphase zu beenden. Damit eine Datenphase beendet werden kann, müssen IRDY# und TRDY# auf einem gültigen Takt aktiv sein. Für einen Lesevorgang gibt TRDY# gültige Daten auf AD(31 : 0) an. Für einen Schreibvorgang gibt TRDY# an, dass das Ziel die Daten akzeptieren kann.
STOP#:
Stop, d. h. eine Anforderung an den aktuellen Transaktionsinitiator, die Transaktion zu stoppen.
IDSEL:
Initialisierungsbauelementauswahl, dient als Chipauswahl für Konfigurationstransaktionen.
DEVSEL#:
Bauelementauswahl, gibt an, dass ein Zielbauelement die Adresse decodiert hat und das Ziel für die aktuelle Transaktion ist.
PERR#:
Paritätsfehler, dient lediglich zum Melden von DATEN-Paritätsfehlern. PERR# kann erst dann angesteuert werden, wenn ein Agent eine Transaktion durch Aufdrücken von DEVSEL für sich beansprucht hat.
SERR#:
Systemfehler, dient zum Melden von ADRESS-Paritätsfehlern. Da Sonderzyklen vom Macro nicht unterstützt werden, wird Datenparität mit diesem Signal auf Sonderzyklen nicht gemeldet.
7. Es folgt eine Liste der Signalschnittstellen für das PCI_FSM (Finite- State-Machine) Modul:
PCI_CLK Der Systemtakt (PCI-Bus erscheint synchron)
PCI_RST System-Reset vom Front-End-Bus
PCI_AD_IN Adressleitungen
PCI_AD_OUT
PCI_AD_OEb
PCI_CNTL_BEb_IN Steuerleitungen
PCI_CNTL_BEb_OUT
PCI_CNTL_BE_OEb
PCI_FRAMEb_IN Gültiger Zyklus
PCI_FRAMEb_OUT
PCI_FRAMEb_OEb
PCI_TRDYb_IN Ziel bereit
PCI_TRDYb_OUT
PCI_TRDYb_OEb
PCI_IRDVb_IN Initiator bereit
PCI_IRDYb_OUT
PCI_IRDYb_OEb
PCI_STOP_IN Ziel Beendigung
PCI_STOP_OUT
PCI_STOP_OEb
PCI_DEVSELb_IN Bauelementauswahl
PCI_DEVSELb_OUT
PCI_DEVSELb_OEb
PCI_IDSELb_ID-Auswahl
PCI_LOCKb Exklusive Zugriffssperre
PCI_PERRb_IN Paritätsfehler
PCI_PERRb_OUT
PCI_PERRb_OEb
PCI_SERRb_IN Systemfehler
PCI_SERRb_OUT
PCI_SERRb_OEb
PCI_PAR_IN Parität
PCI_PAR_OUT
PCI_PAR_OEb
8. Die Back-End-Schnittstelle trägt die folgenden Signale:
BK_ADDR_IN Adressleitungen
BK_ADDR_OUT
BK_ADDR_OUT_EN
BK_DATA_IN Datenleitungen
BK_DATA_OUT
BK_DATA_OUT_EN
BK_BEb_IN Byte-Freigabe-Leitungen
BK_BEb_OUT
BK_BYTE_OUT_EN Freigabe für Byte-Leitungen
BK_AS_IN Adress-Strobe
BK_AS_OUT
BK_DS_IN Daten-Strobe
BK_DS_OUT
BK_RD_WRb_IN Lese-/Schreib-Richtung
BK_RD_WRb_OUT
BK_MEM_IOb_IN Speicher/E/A
BK_MEM_IOb_OUT
BK_C_Db_IN Befehl/Daten
BK_C_Db_OUT
BK_SLAVE_CS Slave-Chipauswahl
BK_DRQ Datenanforderung
BK_DACK Datenbestätigung
BK_TC Übertragungszahl komplett
BK_REQ Busanforderung
BK_GNT Busgewährung
BK_RDY_IN Bereit
BK_RDY_OUT
BK_HOLD Halten
BK_HLDA Halten bestätigen
BK_MASTER_REQ Master-Anforderung
BK_MASTER_GNT Master-Gewährung
BK_RESTART Neustart Bauelement
BK_IRQ_HOLD_OFF Interrupt halten aus
9. Die folgende TABELLE 1 beschreibt die Dateihierarchie für die Macro- Dateien, die später in TABELLE 2 aufgeführt werden. Hierarchie von Macro-Modulen
10. Die folgende TABELLE 2 beschreibt kurz den Betrieb der Macromodule.

Beschreibung von Macro-Modulen

address_counter.vhd
Ein 32-Bit-Zähler. In diesen Zähler kann eine 32-Bit-Anfangsadresse geladen werden. Ist sie freigegeben, dann inkrementiert sie die Adresse um eins. Laden und Inkrementieren erfolgen nur dann, wenn die Uhr tickt.
address_pointer.vhd
Erzeugt Adresslogik für die FIFO-Speicherelemente.
base_address_reg.vhd
PCI-spezifisches Register für base_reg.
bist_reg.vhd
PCI-spezifisches Register für bist.
bk_end.vhd
Eine Beschreibung der Back-End-Schnittstelle. Alle diese Signale sind synchron.
buffer_element.vhd
Erstellt eine Logik, die mit einem FIFO-Block assoziiert wird. Es entsteht Speicherkapazität zur Aufnahme einiger Daten und einiger address_pointers zum Lesen und Schreiben.
burst_size_cntr.vhd
Dieser 8-Bit-Zähler dient zum Steuern der Länge von Bündeltransfers, die zurückgesetzt oder neu versucht werden, so dass sie mit der richtigen Zahl fortsetzen können, wenn sie den Vorgang beenden können.
bus_hbuf.vhd
Zellenbibliotheksdatei für HBUF-Zellen; wird für Simulation und Synthese benutzt.
bus_inbuf.vhd
Zellenbibliotheksdatei für INBUF-Zellen; wird für Simulation und Synthese benutzt.
bus_inpd.vhd
Zellenbibliotheksdatei für INPD-Zellen; wird für Simulation und Synthese benutzt.
bus_inv.vhd
Zellenbibliotheksdatei für INV-Zellen; wird für Simulation und Synthese benutzt.
bus_opd16.vhd
Zellenbibliotheksdatei für OPD16-Zellen; wird für Simulation und Synthese benutzt.
byte_steering_logic.vhd
Dies ist der Datenpfad für Byte-Leitung. Er leitet alle Bytes der Datenbusse.
cc_bk_sm.vhd
Dies ist die Zyklus-Controller-State-Machine für die Back-End-Schnittstelle. Je nach dem, welcher Datenmanager gewählt wird, fallen bestimmte Teile hiervon heraus.
cc_bypass_sm.vhd
Dies ist die Bypass-Modus-State-Machine des Zyklus-Controllers. Je nach dem, welcher Datenmanager gewählt wird, fallen bestimmte Teile hiervon heraus.
cc_fe_sm.vhd
Dies ist die Front-End-State-Machine des Zyklus-Controllers. Je nach dem, welcher Datenmanager gewählt wird, fallen bestimmte Teile hiervon heraus.
class_code_reg.vhd
PCI-spezifisches Register für class_code.
clktree.vhd
Referenz für das Taktstruktur-Synthesemodul.
command_reg.vhd
PCI-spezifisches Register für Befehl.
config.vhd
Dies ist ein PCI-spezifischer Konfigurationsblock für eine Back-End- Schnittstelle. Es gibt einen für jedes Bauelement. Er enthält Informationen, mit denen der Bus ermitteln kann, ob das zugehörige Bauelement das Ziel der derzeitigen Bustransaktion ist. Er enthält Informationen über Adressbereiche für das Bauelement und seinen Datenmanager, die verschiedenen ID-Register, Transfer-Bündellängen, Latenz-Timer-Werte usw.
configurable_bit_reg.vhd
Dies ist ein Universalregister mit einer konfigurierbaren Breite. Außerdem kann konfiguriert werden, ob es mit 0 Bits oder 1 Bits gefüllt wird, wenn es zurückgestellt wird.
configurable_dword_reg
Dies ist ein Universalregister mit einer konfigurierbaren Doppelwortbreite.
configured_pci_macro.vhd
Erzeugt untergeordnete Blöcke der Subteile des PCI-Macros.
control_reg.vhd
PCI-spezifisches Register
cycle_controller.vhd
Dies ist der Zyklus-Controller-Block. Er steuert Übertragungen vom Pufferblock zur Back-End-Schnittstelle.
cycler.vhd
Dies ist die Byteleitungs-Cycler-State-Machine. Sie steuert die Leitung von Daten von einem Bus zu einem anderen Bus oder zu einer Schnittstelle mit einer anderen Größe.
data_manager.vhd
Dies ist der Datenmanagerblock. Er ist verantwortlich für Übertragungen vom Pufferblock zum Front-End-Bus.
device_id_reg.vhd
PCI-spezifisches 16-Bit-Nur-Lese-Register, das die ID für dieses Bauelement enthält.
devsel_timer.vhd
PCI-spezifischer Zähler
dff_iobuf_iopd16.vhd
Zellenbibliotheksdatei für Flipflop-E/A-Pufferzellen; wird für Simulation und Synthese verwendet.
dffpq.vhd
Zellenbibliotheksdatei für Flipflop-Zellen; wird für Simulation und Synthese verwendet.
dffrpq.vhd
Zellenbibliotheksdatei für Flipflop-Zellen; wird für Simulation und Synthese verwendet.
dm_bk_sm.vhd
Dies ist die Datenmanager-Back-End-State-Machine. Je nach dem, welche Art von Datenmanager gewählt wird, kann auch eine andere Statusmaschine gebaut werden.
dm_fe_sm.vhd
Dies ist die Datenmanager-Front-End-State-Machine. Je nach dem, welche Art von Datenmanager gewählt wird, kann auch eine andere Statusmaschine gebaut werden.
dpr_gen.vhd
Dies ist ein Dualport-RAM. Er erzeugt einen RAM einer bestimmten Größe, auf den zwei Objekte gleichzeitig zugreifen können.
fifo.vhd
Dies ist der gesamte FIFO-Block einschließlich sämtlicher Steuerlogik für einzelne und mehrfache FIFO-Pufferanordnungen.
hbuf.vhd
Zellenbibliotheksdatei für Pufferzellen: wird für Simulation und Synthese verwendet.
header_reg.vhd
Ein PCI-spezifisches Bauelement-Header-Register
high_bit_reg.vhd
Erzeugt ein 8-Bit-Register, bei dem die Bits von 7 abwärts bis zu einem Bit definiert werden, die übrigen Bits sind 0.
inbuf.vhd
Zellenbibliotheksdatei für Eingangspufferzellen; wird für Simulation und Synthese verwendet.
inpd.vhd
Zellenbibliotheksdatei für Eingangskontaktstellenzellen; wird für Simulation und Synthese verwendet.
interrupt_line_reg.vhd
Ein PCI-spezifisches Interrupt-Line-Register
interrupt_pin_reg.vhd
Ein PCI-spezifisches Interrupt-Pin-Register
inv.vhd
Zellenbibliotheksdatei für Inverter-Zellen; wird für Simulation und Synthese verwendet.
iobuf.vhd
Zellenbibliotheksdatei für E/A-Pufferzellen; wird für Simulation und Synthese verwendet.
iobuf_iopd12sl.vhd
Zellenbibliotheksdatei für Puffer-E/A-Kontaktstellenzellen; wird für Simulation und Synthese verwendet.
iobuf_iopdl6.vhd
Zellenbibliotheksdatei für Puffer-E/A-Kontaktstellenzellen; wird für Simulation und Synthese verwendet.
iobufpci.vhd
Zellenbibliotheksdatei für PCI-E/A-Pufferzellen; wird für Simulation und Synthese verwendet.
iopd12sl.vhd
Zellenbibliotheksdatei für E/A-Kontaktstellenzellen; wird für Simulation und Synthese verwendet.
iopd 16.vhd
Zellenbibliotheksdatei für E/A-Kontaktstellenzellen; wird für Simulation und Synthese verwendet.
iopdpci.vhd
Zellenbibliotheksdatei für PCI-E/A-Kontaktstellenzellen; wird für Simulation und Synthese verwendet.
macro_pkg.vhd
Enthält Anordnungen möglicher Parameter-Arrays und Funktionen sowie diesen entsprechende Konstantennamen. Enthält eine Reihe von Vorgabewerten für die verschiedenen Parameter. Enthält auch eine Reihe von Logik-, Arithmetik-, Inkrementier- und Konvertierungsfunktionen, die in den übrigen Modulen verwendet werden.
master_latency_timer.vhd
Dieser PCI-spezifische Zähler beginnt bei 0, wenn er nach dem Sperren zurückgestellt oder freigegeben wird. Er zählt aufwärts, bis er eine MSTR_LAT_TIME (Master-Latenz-Zeit) erreicht, bei der es sich um einen 8-Bit- Wert handelt, der vom Benutzer dieses Timers eingestellt wird. Wenn diese Zahl erreicht ist, ist das TIME_OUT Signal aktiv und der Zählvorgang stoppt.
master_state_machine.vhd
Dies ist der Front-End-Master-Teil der Finite-State-Machine, der mit dem Bus spricht.
max_lat_reg.vhd
PCI-spezifisches Register für max_lat
memory_element.vhd
Erzeugt ein Stück Speicher, entweder durch Bauen mit Hilfe von Flipflops, wenn es klein genug ist, oder aus Dualport-RAMs, wenn nicht.
min_gnt_reg.vhd
PCI-spezifisches Register für min_gnt
miscelaneous_configuration_regs.vhd
Ermöglicht die Erzeugung zusätzlicher PCI-spezifischer Konfigurationsregister für die Verwendung durch Bauelemente. Sind keine vorgegeben, so werden auch keine erzeugt.
nan2.vhd
Zellenbibliotheksdatei für NAND-Gate-Zellen; wird für Simulation und Synthese verwendet.
new_fifo.vhd
FIFO-Schnittstelle
new_transfer_counter.vhd
Ein Zäher, der im Datenmanager für anliegende Datenübertragungen verwendet wird.
next_addr_cmpr.vhd
Enthält Strukturen zum Vergleichen der nächsten Adresse vom Eingangsbus mit einer vorhergesagten nächsten Adresse. Enthält auch die aktuelle Adresse der nächsten Busübertragung für das Back-End-Bauelement.
opd 16.vhd
Zellenbibliotheksdatei für OPD16-Zellen; wird für Simulation und Synthese verwendet.
or2.vhd
Zellenbibliotheksdatei für OR-Gate-Zellen; wird für Simulation und Synthese verwendet.
otpd 16.vhd
Zellenbibliotheksdatei für OTPD16-Zellen; wird für Simulation und Synthese verwendet.
output_latch.vhd
Ausgangs-Latch, der Daten vom FIFO-Dualport-RAM-Ausgang akzeptiert.
parity36.vhd
Akzeptiert einen 32-Bit-Dateneingang und einen 4-Bit-Befehlseingang und erzeugt auch ein einzelnes Paritätsbit davon. Dieses Bit ist 1, wenn die Gesamtzahl von 1-Bits in den Daten- und Befehlseingängen ungerade ist, 0, wenn sie gerade ist.
pci_fsm.vhd
Dies ist das PCI-Bus-Finite-State-Machine-Modul, das Master, Slave, Parity und address_counter zur Bildung der Schnittstelle zum PCI-Bus verkapselt.
pci_macro.vhd
Hier werden die internen Signale beschrieben. Dieses Primärmodul ruft alle anderen Subteile (FIFO, Zyklus-Controller, Datenmanager, Back-End- Schnittstelle, Byte-Leitung, Finite-State-Machine).
pci_macro_userparams.vhd
Enthält Definitionen der vom Benutzer wählbaren Parameter für die verschiedenen Subteile, gemäß denen der Back-End-Schnittstellentyp gewählt wird.
pipeline_block.vhd
Teil von FIFO, enthält Dualport-RAM-Pipeline-Register.
revision_id_reg.vhd
Dieses PCI-spezifische 8-Bit-Nur-Lese-Register enthält einen Kenner für diese Revision.
rom_base_address reg.vhd
Ein PCI-spezifisches 32-Bit-Register für ROM-Basisadresse
sbuf.vhd
Zellenbibliotheksdatei für Pufferzellen; wird für Simulation und Synthese verwendet.
scan_pci_macro.vhd
Wie die Datei configured_pci_macro.vhd, aber zum Scan-Testen konfiguriert. Diese Datei würde anstelle von scan_pci_macro verwendet, wenn eine Scan- Prüfschaltungsanordnung einbezogen werden soll.
signaltree.vhd
Zellenbibliotheksdatei für Signalstrukturzellen; wird für Simulation und Synthese verwendet.
slave_state_machine.vhd
Dies ist der Slave-Teil der Finite-State-Machine, der mit dem Bus spricht.
status_reg.vhd
Dieses 16-Bit-Register reflektiert abgebrochene Buszyklen, die von Bauelementen ausgegeben oder von Back-End-Slave-Bauelementen empfangen wurden. Es reflektiert auch vom Master abgebrochene Buszyklen für Back-End-Master-Bauelemente. Durch Lesen dieses Registers werden die Werte der Bits erhalten. Beim Schreiben wird jedes Bit in diesem Register, auf das eine 1 geschrieben wird, auf 0 zurückgestellt.
target_latency_timer.vhd
Dies ist ein PCI-spezifischer Zähler, der auf 8 zurückgestellt wird, wenn er nach einer Sperrung zurückgestellt oder freigegeben wird. Wenn er 0 erreicht, wird das TIME_OUT Signal aktiv.
valid_data_counter.vhd
Dies ist Teil des FIFO-Blocks. Die Funktion bezieht sich auf die Ermittlung, wo sich die nächste leere Zelle im Puffer befindet.
vendor_id_reg.vhd
Dieses PCI-spezifische 16-Bit-Nur-Lese-Register enthält eine ID für den jeweiligen Vendor für dieses Teil (z. B. Geräteadapterchip oder -karte).
Zusammenfassend sei gesagt, es wurden hierin ein Verfahren und eine Vorrichtung zum Erzeugen einer elektronischen Schaltung beschrieben, mit der ein Bauelement mit einem Bus wie z. B. einem Systembus in einem Computer verbunden werden kann. Die Erfindung akzeptiert vom Benutzer vorgegebene Parameter zum Konfigurieren eines Geräteadapters, der das Bauelement mit dem Bus verbindet, und erzeugt danach einen kundenspezifisch angepassten Geräteadapter auf der Basis solcher vom Benutzer vorgegebener Parameter. Durch Verwenden eines gemeinsamen Design-Macros, das programmierbar ist, kann ein Benutzer leicht kundenspezifische Geräteadapter für eine Mehrzahl unähnlicher Bauelemente vorgeben und erzeugen, die mit dem Bus verbunden werden sollen. Eine resultierende Adapterarchitektur ermöglicht eine Verbindung mehrerer unähnlicher Bauelemente mit einem Computerbus mit einer einzigen Geräteadapter-IC oder -Karte.

Claims

1. Mehrgerätestecker (16), umfassend eine Busschnittstelle für einen Computer zum Anpassen einer Mehrzahl von Geräten (14) an einen Computerbus (12), mit einem Puffer (22) für jedes Gerät (14) zum Speichern von Daten, gekennzeichnet durch einen Datenmanager (20) für jeden Puffer (22) zum Steuern von Datenübertragungen über Datenpfade sowie zwischen dem genannten Puffer (22) und dem genannten Bus (12), und ein Zyklussteuermittel (24) für jeden Puffer (22) und in Verbindung mit Steuerpfaden zum Steuern von Datenübertragungen über Datenpfade sowie zwischen dem genannten Puffer (22) und dem jeweiligen Gerät (14), wobei der Stecker (16) ferner eine Mehrzahl von Gerätesubadaptern (18) beinhaltet, umfassend einen jeweiligen einen Puffer aus der genannten Mehrzahl von Puffern (22) und zugehörigen Datenmanagern (20) und Zyklussteuermitteln (24), wobei jeder genannte Subadapter (18) so gestaltet ist, dass Zyklussteuermittel und Datenmanager in einer paarweisen Beziehung arbeiten, so dass der genannte Datenpfad so gestaltet werden kann, dass er unabhängig von dem genannten Steuerpfad vorgegeben werden kann, so dass der genannte Datenpfad selektiv und unabhängig breitenkonfiguriert werden kann.

2. Mehrgerätestecker (16) nach Anspruch 1, wobei die genannte Busschnittstelle eine Adapterkarte für die Kommunikation mit einem Erweiterungssteckplatz eines Computers umfasst, die mit dem genannten Bus (12) verbunden werden kann, und umfassend eine Mehrzahl der genannten Puffer (22) jeweils zum Speichern von Daten für ein jeweiliges Gerät (14), und mit einem Mittel zum Multiplexieren der genannten Mehrzahl von Puffern (22) mit dem genannten Bus (12).

3. Mehrgerätestecker (16) nach Anspruch 1, umfassend eine konfigurative Adress- und Datenschnittstelle (28) mit anderen Charakteristiken als denen des Busses (12), und Schnittstellenlogik (13) zum Verbinden der genannten konfigurierbaren Adress- und Datenschnittstelle (28) mit dem genannten Bus (12), wobei die genannte Schnittstellenlogik (13) eine Mehrzahl von Gerätesubadaptern umfasst, die die genannte konfigurative Adress- und Datenschnittstelle (28) mit dem genannten Bus (12) koppeln, und wobei wenigstens einer aus der genannten Mehrzahl von Gerätesubadaptern einen oder mehrere der genannten Puffer (22), den genannten Datenmanager (20) zum Steuern von Datenübertragungen zwischen dem genannten Bus (12) und dem/den genannten ein oder mehreren Puffer(n) (22) und das genannte Zyklussteuermittel (24) zum Steuern von Datenübertragungen zwischen der genannten konfigurierbaren Adress- und Datenschnittstelle (28) und dem/den genannten ein oder mehreren Puffer(n) (22) umfasst.

4. Mehrgerätestecker nach Anspruch 1, bei dem die genannte Busschnittstelle eine Elektronikkarte zur Verwendung in einem Computer umfasst, der den genannten Bus (12) aufweist, wobei eine Mehrzahl von Gerätesubadaptern vorgesehen ist, wobei wenigstens einer der genannten Subadapter folgendes umfasst: den genannten Puffer (22), den genannten Datenmanager (20) zum Übertragen von Daten von dem genannten Bus (12) zu dem genannten Puffer (22), und das Zyklussteuermittel (24) zum Übertragen von Daten von dem jeweiligen Puffer (22) zu dei konfigurierbaren Adress- und Datenschnittstelle (28), und ferner mit einer Arbitrationsschaltung, die nur die Kommunikation eines einzigen Datenmanagers (20) mit dem genannten Bus (12) zu einem bestimmten Zeitpunkt zulässt.

5. Mehrgerätestecker (16) nach Anspruch 4, wobei die genannte Arbitrationsschaltung eine Statusmaschine umfasst.