DE10231930A1

DE10231930A1 - Verfahren zum Zugreifen auf Abtastketten und zum Aktualisieren eines EEPROM-residenten FPGA-Codes durch einen Systemverwaltungsprozessor und einen JTAG-Bus

Info

Publication number: DE10231930A1
Application number: DE10231930A
Authority: DE
Inventors: Michael John Erickson; Edward A Cross; David Maciorowski
Original assignee: Hewlett Packard Co
Current assignee: Hewlett Packard Development Co LP
Priority date: 2001-07-30
Filing date: 2002-07-15
Publication date: 2003-05-15
Also published as: JP2003058385A; US6883109B2; US20030023771A1

Abstract

Ein Verfahren zum Aktualisieren eines programmierbaren Bauelementkonfigurationscodes, der in EEPROMs eines Systems gespeichert ist, ist auf komplexen Systemen mit separaten Verwaltungs- und Systemprozessoren betreibbar. Das Verfahren umfaßt das Ausführen einer Sequenz zum Aktualisieren eines programmierbaren Bauelementkonfigurationscodes auf einem Verwaltungsprozessor des Systems einschließlich der Schritte des Löschens der EEPROMs, des Schreibens von zumindest einem Block eines Konfigurationscodes an die EEPROMS und des Überprüfens nach Fehlern nach dem Schreiben. Die Fehler, nach denen in der Prüfung gesucht wurde, umfassen einen Ausfall eines FIFO bezüglich einer Leere. Nach dem Erfassen der Fehler umfaßt das Verfahren einen automatischen Wiederversuch des Schreibvorgangs. Die Ausführungsbeispiele des Verfahrens sind auf Systemen betreibbar, die mehrere serielle Busse aufweisen, die die EEPROMs mit einer gemeinsamen Konfigurationslogik verbinden, und auf Systemen, die mehrere Verwaltungsprozessoren aufweisen, die jeweils auf die gemeinsame Konfigurationslogik zugreifen können.

Description

Ein zu dieser Anmeldung verwandter Gegenstand ist in den ebenfalls anhängigen, am gleichen Tag wie die vorliegende Anmeldung eingereichten deutschen Anmeldungen "VERFAHREN ZUM ZEITGERECHTEN AKTUALISIEREN VON PROGRAMMIERTEILEN", "VERFAHREN UND VORRICHTUNG FÜR EINE SERIELLE-BUS-ZU-JTAG- BUSBRÜCKE", "VERFAHREN UND VORRICHTUNG ZUR SYSTEMINTERNEN PROGRAMMIERUNG DURCH EINEN GEMEINSAMEN VERBINDUNGSPUNKT VON PROGRAMMIERBAREN LOGISCHEN BAUELEMENTEN AUF MEHREREN SCHALTUNGSPLATINEN EINES SYSTEMS", die alle hiermit durch Bezugnahme aufgenommen werden, beschrieben.
Diese Erfindung bezieht sich auf die Technik des systeminternen Programmierens von programmierbaren logischen Bauelementen. Speziell bezieht sich die Erfindung auf ein Verfahren mit einem speziellen Dienstprogramm zur systeminternen Programmierung von EEPROMs, die einen Konfigurationscode FPGAs (field programmable gate arrays = feldprogrammierbare Gatterarrays) liefern, wobei das Verfahren in einer Firmware eines Systemverwaltungsprozessors betreibbar ist und eine IIC-JTAG-Busbrücke verwendet.
Serielle Kommunikationsbusse des Separat-Takt-und-Daten- Typs werden immer häufiger zur Kommunikation zwischen integrierten Schaltungskomponenten eines Systems verwendet. Serielle Verbindungen diesen Typs umfassen die IIC- (die anfänglich als Inter-IC-Bus und nun in weiten Kreisen als I2C bekannt sind) und SPI-Busse. Verbindungen diesen Typs können ohne das Erfordernis von Präzisionszeitgebungskomponenten an jeder integrierten Schaltung auf dem Bus implementiert sein und arbeiten typischerweise unter der Steuerung von zumindest einem Bus-Master. Serielle EEPROM-Bauelemente (EEPROM = Electrically Erasable Programmable Read-Only Memory = elektrisch löschbarer programmierbarer Nur-Lese- Speicher), die mit seriellen Kommunikationsbussen des SPI- und IIC-Typs schnittstellenmäßig verbunden sind, sind überall erhältlich.
Obgleich die I2C- und SPI-Busse typischerweise für Kommunikationen in Systemen während des Normalbetriebs verwendet werden, sollte der serielle IEEE-1149.1-Bus, der als JTAG- Bus bekannt ist, zum Testen von inaktiven Systemen verwendet werden, indem ein Zugriff von einem Tester ermöglicht wurde, um eine Randerfassung auf jeder integrierten Schaltung auszuführen. Der Tester kann dabei die Konnektivität der integrierten Schaltungen verifizieren und verifizieren, daß sie richtig installiert und verbunden sind. Der JTAG- Bus sorgt für eine Zwischenverbindung von einer oder mehreren integrierten Schaltungen in einer Kette, wobei jede derselben durch den Tester adressiert werden kann. Typischerweise sind mehrere Bauelemente auf einer Schaltungsplatine in einem JTAG-Bus, der auch als eine JTAG-Kette bekannt ist, verbunden.
Der JTAG-Bus ist ein serieller Bus mit vier Verbindungen zu jedem Bauelement. Diese umfassen eine serielle Daten-Ein- Leitung, eine serielle Daten-Aus-Leitung, eine Taktleitung und eine Testmodus-Auswahlleitung. Typischerweise ist die Daten-Aus-Leitung eines ersten Chips in einer Kette mit der Daten-Ein-Leitung eines zweiten Chips der Kette gekoppelt, und die Daten-Aus-Leitung des zweiten Chips ist mit der Daten-Ein-Leitung eines dritten gekoppelt. Die Daten-Ein- und die Daten-Aus-Leitungen von mehreren Chips sind daher in einer Prioritätsverkettungskonfiguration gekoppelt.
Der IEEE-1152-Bus ist eine neuere, verbesserte Version des 1149.1-JTAG-Busses. Hierin erfolgende Bezugnahmen auf einen JTAG-Bus sowohl die 1149.1-er als auch die 1152-er Variationen umfassen.
Programmierbare Logikbausteine, die hierin als PLDs (programmable Loggia devices) bezeichnet werden, werden im allgemeinen als Komponenten von Computersystemen verwendet. Diese Bauelemente umfassen PAL-Bausteine (PAL = programmable array logic devices), PLAs (programmable logic arrays = programmierbare Logikarrays), komplexe programmierbare Logikanordnungen (PLDs = complex PLDs) und feldprogrammierbare Logikarrays (FPGAs). Die PLDs sind typischerweise Allzweckbausteine, die eine systemspezifische Funktion annehmen, wenn ein funktionsbestimmender Code oder Konfigurationscode innerhalb derselben eingebaut ist. Die PLDs können den funktionsbestimmenden Code in Schmelzverbindungen, Antischmelzverbindungen (Antifuses), EPROM-Zellen, EEPROM- Zellen einschließlich FLASH-Zellen oder statischen RAM- Zellen speichern.
Diese PLD-Bausteine, die statische RAM-Zellen nutzen, um ihren funktionsbestimmenden Code zu halten, können konzipiert sein, um diesen Code aus einem EEPROM auf derselben oder einer anderen integrierten Schaltung beim Hochfahren des Systems automatisch wiederzugewinnen. Viele übliche FPGA-Bauelemente, die bei Xilinx, Altera, Lucent und Atmel erhältlich sind als SRAM-basierte FPGAs bekannt, weil sie ihre Codes in statischen RAM-Zellen speichern.
Die FPGAs dieses Typs sind bekannt, die den Konfigurationscode von einem externen EEPROM entweder in einem seriellen oder parallelen Modus beim Hochfahren des Systems wiedergewinnen können. Diese Bauelemente sind typischerweise konfiguriert, um ihren Konfigurationscode beim Hochfahren des Systems automatisch wiederzugewinnen. Die FPGAs, die den Konfigurationscode in einem seriellen Modus wiedergewinnen, können konzipiert sein, um einen kundenspezifischen seriellen Bus, der zum Laden des Codes in ein FPGA konzipiert ist, zu verwenden, und können konzipiert sein, um einen seriellen Standardbus, wie die IIC- und SPI-Busse, zu verwenden, obwohl viele solche Bauelemente kundenspezifische serielle Busse verwenden. Der Begriff, serieller Bus, der hierin verwendet wird, umschließt daher die IIC-, SPI- und kundenspezifischen seriellen Busse.
Es sind auch FPGAs bekannt, die einen Quersummenverifizierung an ihrem Konfigurationscode ausführen können, wenn sie denselben von einem EEPROM empfangen. Diese FPGAs erzeugen ein Fehlersignal, wenn die Quersummenverifikation scheitert, was anzeigt, daß ihr Konfigurationscode nicht richtig sein könnte.
Es ist bekannt, daß einige EEPROM-Bausteine, einschließlich jedoch nicht beschränkt auf die Xilinx-XC18V00- Serienbausteine, mit dem JTAG-Bus verbunden sein können und mit einem Konfigurationscode über dem JTAG-Bus gelöscht und programmiert werden können. Ferner ist bekannt, daß diese Bauelemente mit einem FPGA verbunden sein können, um den Konfigurationscode an die FPGA zu liefern. Es ist ebenfalls bekannt, daß einige FPGA-Bauelemente zu Test- oder Konfigurationszwecken auch mit einem JTAG-Bus verbunden sein können.
Es ist bekannt, daß ein tragbarer Programmierbaustein mit einem JTAG-Bus einer Platine durch einen systeminternen Konfigurationsanfangsblock auf der Platine verbunden sein kann. Der JTAG-Bus ist mit zumindest einem JTAGkonfigurierbaren EEPROM auf der Platine gekoppelt, die wiederum gekoppelt sind, um die FPGAs auf der Platine zu konfigurieren. Ein Konfigurationssystem ist mit dem JTAG-Bus durch den Anfangsblock gekoppelt, und das System ist in einem Konfigurationsmodus angeordnet. Der Konfigurationscode wird dann vom Konfigurationssystem durch den Anfangsblock und über den JTAG-Bus in den EEPROM geschrieben. Sobald sich der Code im EEPROM befindet, kann die Systemleistung ein- und ausgesteuert werden, wobei der Konfigurationscode zu diesem Zeitpunkt in das zugeordnete FPGA übertragen wird. Dieser Prozeß ist im XILINX-Datenblatt DSO26 und anderen von XILINX erhältlichen Dokumenten in wenigen Worten umschrieben.
Das Konfigurationssystem ist typischerweise ein Notebook- Computer mit einem Konfigurationscode für die FPGAs der Platine. Das Konfigurationssystem weist auch eine geeignete Software und Hardware zum Treiben des JTAG-Busses der Platine zusammen mit dem Wissen um die JTAG-Buskonfiguration der Platine auf.
Obgleich ein Laden des FPGA-Konfigurationscodes in die EEROMs einer Platine bei kleinen Systemen gut funktioniert, können bei großen Systemen Schwierigkeiten entstehen. Große Systeme weisen evtl. mehrere Platinen auf, von denen nicht alle mit dem gleichen JTAG-Bus verbunden sind. Separate Ketten werden häufig verwendet, weil:

1. Ein Konfigurationssystem das Wissen über alle Bauelemente in der Kette aufweisen muß, um jedes Bauelement auf der Kette ordnungsgemäß zu adressieren; wenn eine einzelne Kette verwendet wird, muß das Konfigurationssystem ein detailliertes Wissen über jede Platine in dem System aufweisen.
2. Große Systeme können Schlitze aufweisen, und tun dies auch häufig, die ein späteres Hinzufügen oder Aktualisieren von Peripheriegeräten, Speicher-Teilsystemen, Prozessoren und anderen Teilsystemen erlauben; ein zusätzlicher Schaltungsaufbau wäre erforderlich, um ein Brechen einer einzelnen Kette an einem beliebigen leeren Schlitz zu verhindern.
3. Große Systeme werden vor dem Versand häufig mit einem spezifischen Satz von Peripheriegeräten, Speicher- Teilsystemen, Prozessoren und anderen Bauelementen kundenspezifisch gefertigt; eine einzelne Kette könnte eine kundenspezifische JTAG-Schnittstellen-Software für jede Systemkonfiguration erfordern.
4. Ein Zugriff auf Bauelemente in kurzen Ketten erfolgt schneller als auf Bauelemente in langen Ketten. Eine einzelne Platine kann daher, muß aber nicht, mehr als eine Kette in der Platine verkörpern.

Der Konfigurationsprozeß des Stands der Technik wirft auch Probleme auf, wenn separate JTAG-Busse verwendet werden, um den FPGA-Konfigurationscode in die EEPROMs von jeder Platine eines großen Systems zu laden. Zum Beispiel kann auf die mehreren Schaltungsplatinen von großen Systemen häufig nicht ohne weiteres zum Koppeln eines Konfigurationssystems mit einem Konfigurationsanfangsblock zugegriffen werden, ohne dieselben aus dem System zu entfernen. Es kann auf bestimmte Platinen zugegriffen werden, jedoch nur, wenn eine oder mehrere zusätzliche Platinen zuerst aus dem System entfernt worden sind. Durch den physischen Zugriff auf ein System durch einen Techniker können auch Anfahrtskosten anfallen. In jedem Fall fällt eine beträchtliche Arbeits- und Systemausfallzeit an, um die FPGA-Konfigurationscodes von allen Platinen eines großen Systems zu aktualisieren.
Es ist bekannt, daß Computersysteme mehr als einen Datenkommunikationsbus für unterschiedliche Zwecke aufweisen können. Zum Beispiel weisen im Handel allgemein erhältliche Computer einen PCI-Bus für Kommunikationen mit Peripherieschnittstellenkarten, wobei ein oder mehrere Prozessorbusse mit jedem Prozessor schnittstellenmäßig verbunden sind, und Busse von anderen Typen auf. Komplexe Systeme können für spezielle Zwecke auch serielle Busse nutzen. Zum Beispiel kann ein komplexes Computersystem einen IIC- oder SPI-Bus als einen Systemverwaltungsbus verwenden.
Eine Busbrücke ist ein Bauelement zum Verbinden von Bussen von unterschiedlichen Typen. Zum Beispiel nutzt ein typischer Personalcomputer zumindest eine Busbrücke zwischen parallelen Bussen, wobei ein Prozessorbus mit einem PCI-Bus gekoppelt ist. Typische Personalcomputer nutzten auch eine Busbrücke zwischen dem parallelen PCI-Bus und einem ISA- Bus.
Ein Systemverwaltungsbus kann eine Schnittstelle mit den Systemfunktionen liefern, einschließlich, jedoch nicht beschränkt auf Leistungsversorgungsspannungs- Überwachungseinrichtungen, Temperatursensoren, Lüftersteuerungen und Lüftergeschwindigkeits-Überwachungseinrichtungen für einen reservierten Systemverwaltungsprozessor. Der Systemverwaltungsprozessor kann wiederum durch eine geeignete Hardware, die ein oder mehrere Busbrücken umfassen kann, mit anderen Prozessoren des Systems schnittstellenmäßig verbunden sein.
Bei einem solchen System kann der Systemverwaltungsprozessor die Systemfunktionen überwachen und bestimmen, ob eine beliebige Systemfunktion einen Grenzwert überschreitet. Wenn Grenzwerte überschritten worden ist, kann der Systemverwaltungsprozessor das System schützen, indem er die Lüftergeschwindigkeiten durch Anweisen des Systems, in einem speziellen Modus zu arbeiten, was das Herunterfahren des Systems umfaßt, oder durch eine andere Möglichkeit, die in der Technik bekannt ist, ändert.
Komplexe Computersysteme können mehrere FPGAs und andere PLDs verkörpern. Die FPGAs können für kundenspezifische I/O- Funktionen, die die CPUs mit anderen Bauelementen für Kommunikationen zwischen den CPUs schnittstellenmäßig verbinden, und zum schnittstellenmäßigen Verbinden von Bauelementen, wie z. B. Lüftern und Temperatursensoren, mit einem Systemverwaltungsbus, verwendet werden.
Es ist eine Aufgabe der vorliegenden Erfindung ein Verfahren zum Zugreifen auf Abtastketten und zum Aktualisieren eines EEPROM-residenten FPGA Code durch einen Systemverwaltungsprozessor und einen JTAG-Bus zu schaffen.
Diese Aufgabe wird durch ein Verfahren gemäß Anspruch 1 und 4 gelöst.
Die vorliegende Erfindung ist ein Verfahren zum systeminternen Programmieren von programmierbaren Bauelementen. Das Verfahren ist speziell für die Programmierung von EEPROMs mit einem Konfigurationscode für FPGAs, die denselben zugeordnet sind, verwendbar. Das Verfahren nutzt eine Busbrücke, wobei ein serieller IIC-Bus mit mehreren JTAG-Bussen überbrückt wird.
Ein spezielles Ausführungsbeispiel wird in einem System mit mehreren Platinen verwendet, wo einige Platinen mehrere EEPROMs aufweisen, die gekoppelt sind, um den Konfigurationscode an die FPGAs zu liefern. Die EEPROM-Bauelemente von jeder dieser Platinen sind in einem JTAG-Bus gekoppelt, mit einem oder mehreren separaten Bussen für jede dieser Platinen. Die JTAG-Busse von jeder Platine werden zur Busbrücke geleitet. Die Busbrücke liefert eine Schnittstelle zwischen den mehreren JTAG-Bussen und einem Systemverwaltungsprozessor des Systems sowie einen Auswählschaltungsaufbau, so daß die Prozessoren einen einzeln JTAG-Bus der mehreren JTAG- Busse auswählen können.
Das Verfahren umfaßt eine Fehler-Überprüfung- und Wiederholung. Zum Beispiel werden die FIFOs der Busbrücke überwacht, um zu bestimmen, ob die Zustandsmaschinen der Busbrücke die Informationen korrekt an die EEPROMs schrieben oder ob die Informationen von den EEPROMs durch die Busbrücke ordnungsgemäß an den Systemverwaltungsprozessor übertragen wurden. Das Verfahren sorgt für Neuversuche, wenn Operationen scheitern. Das Verfahren sieht auch eine Verifikation vor, das die Konfigurationscode-Dateien mit den Ziel-EEPROMs-, Bussen und Platinen kompatibel sind.
Bevorzugte Ausführungsbeispiel der vorliegenden Erfindung werden nachfolgend Bezug nehmend auf die beiliegenden Zeichnungen näher erläutert. Es zeigen:
Fig. 1 ein Blockdiagramm eines Computersystems des Stands der Technik mit mehreren JTAG-Bussen auf mehreren Platinen, wobei jede Platine einen separaten Konfigurationsanfangsblock aufweist;
Fig. 2 ein Blockdiagramm eines Computersystems, das die Erfindung verkörpert, die mehrere JTAG-Busse von mehreren Platinen, die zu einer gemeinsamen Konfigurationslogik gebracht wurden, aufweist und die eine Schnittstelle mit einem Prozessor des Systems zum Programmieren der EEPROMs über den mehreren JTAG-Bussen aufweist;
Fig. 3 ein detailliertes Blockdiagramm der gemeinsamen Konfigurationslogik und der Systemverwaltungs- Teilsysteme des Systems von Fig. 2, die eine JTAG-IIC-Brücke verkörpern, mit Systemverwaltungs- und Host-Prozessoren, und eine Verbindung mit einer Datenbank über ein Netzwerk;
Fig. 4 ein Flußdiagramm eines Verfahrens zum Konfigurieren von FPGAs eines Systems durch eine gemeinsame Systemkonfigurationslogik;
Fig. 5 ein ausführliches Blockdiagramm einer Platine eines Ausführungsbeispiels der Erfindung, die einen lokalen Systemverwaltungsprozessor, der gekoppelt ist, um Fehlersignale von den FPGAs zu empfangen, einen Konfigurationsanfangsblock und einen Platine-Identifikations-EEPROM aufweist, wobei die Konnektivität mit den Systemverwaltungsprozessoren und der gemeinsamen Konfigurationslogik gezeigt ist;
Fig. 6 ein ausführliches Blockdiagramm eines Abschnitts eines Systemverwaltungs-Teilsystems, das die vorliegende Erfindung verkörpert;
Fig. 7 eine Darstellung von Funktionen, die die Selbstheilung eines Systems ermöglichen, das einen korrupten FPGA-Code gemäß der Erfindung aufzeigt;
Fig. 8 ein weiteres detailliertes Blockdiagramm der gemeinsamen Konfigurationslogik eines Ausführungsbeispiels der Erfindung;
Fig. 9 ein weiteres ausführliches Blockdiagramm von Statusregistern der gemeinsamen Konfigurationslogik eines Ausführungsbeispiels der Erfindung;
Fig. 10A ein Flußdiagramm eines speziellen alternativen Ausführungsbeispiels des Verfahrens der vorliegenden Erfindung; und
Fig. 10B ein Flußdiagramm, das den Schritt des "Programmiere-EEPROMs-des-Busses" von Fig. 10A ausführlich aufführt.
Ein in der Technik bekanntes Computersystem umfaßt mehrere Schaltungsplatinen, wie eine Platine A 100 (Fig. 1) und eine Platine B 102, die die FPGAs 104, 106, 107 auf den Platinen verkörpern. In dem System können zusätzliche Platinen vorhanden sein, sowohl mit als auch ohne FPGAs, wobei die verschiedenen Platinen als Komponenten des Systems zusammengekoppelt sind 103. Auf der Platine A 100 ist das FPGA 104 mit einem Konfigurations-EEPROM 108 gekoppelt, so daß das FPGA 104 seinen Konfigurationscode vom EEPROPM 108empfängt, wenn die Platine A 100 hochgefahren wird. Desgleichen ist das FPGA 106 mit einem zweiten Konfigurations- EEPROM 110 gekoppelt. Die Konfigurations-EEPROMs 108 und 110 sind in einem JTAG-Bus 111 zusammengekettet, der zu einem Konfigurationsanfangsblock 112 herausgebracht wird.
Wenn gewünscht ist, den Konfigurationscode von einer oder mehreren der FPGAs 104 oder 106 auf der Platine A 100 zu aktualisieren, wird ein Konfigurationssystem 114 durch ein Konfigurationskabel 116 mit dem Konfigurationsanfangsblock 112 gekoppelt. Der Konfigurationscode kann von einem Speichersystem 118 des Konfigurationssystems 114 durch das Konfigurationskabel 116, den Konfigurationsanfangsblock 112, über den JTAG-Bus 111 in einen EEPROM, wie den EEPROM 108 übertragen werden. Sobald dies erreicht ist, kann die Leistung ein- und ausgesteuert werden, um zu bewirken, daß das FPGA 104 den aktualisierten Konfigurationscode vom EEPROM 108 lädt.
Wenn gewünscht ist, den Konfigurationscode der FPGAs auf einer anderen Platine, wie der Platine B 102, zu aktualisieren, wird das Konfigurationskabel 116 vom Konfigurationsanfangsblock 112 getrennt und mit einem geeigneten Konfigurationsanfangsblock 120 der Platine B entlang einer anderen Konfigurationskabelführung 122 gekoppelt. Der Prozeß wird dann wiederholt, um einen oder mehrere EEPROMs der EEPROMs 124 über einen Platine-B-JTAG-Bus 126 zu aktualisieren.
Die systeminterne FPGA-Konfigurationscode-Aktualisierungsvorrichtung des Stands der Technik, die in Fig. 1 dargestellt ist, erfordert einen physischen Zugriff auf jede Platine des Systems, die aktualisiert werden soll. Das Konfigurationskabel 116 muß mit dem geeigneten Konfigurationsanfangsblock von jeder Platine separat verbunden sein.
Bei einem System 200 (Fig. 2) gemäß der vorliegenden Erfindung gibt es mehrere Schaltungsplatinen, wie die Platine C 202 und die Platine D 204, die jeweils ein oder mehrere FPGAs 206, 208, 210 und 211 aufweisen. Die FPGAs 206, 208, 210 und 211 sind vom SRAM-basierten Typ und sind gekoppelt, um ihren Konfigurationscode von den EEPROMs, wie den EEPROMs 212, 214 und 216 zu empfangen. Die EEPROMs 212 und 214 der Platine C 202 sind in einem Platine-C-JTAG-Bus 222 verbunden, und die EEPROMs 216 der Platine D 204 sind in einem Platine-D-JTAG-Bus 224 verbunden. Die Platinen C 202 und D 204 sind ferner mit einem Systemverwaltungsbus 226 verbunden, der mit einigen der FPGAs, wie dem FPGA 208 der Platine C 202 und dem FPGA 211 der Platine D 204, verbunden sein kann, dies aber nicht muß. Die Platinen des Systems, wie die Platinen C 202 und D 204, sind mit einer zusätzlichen Systemverbindung 227 für andere Zwecke verbunden. Die zusätzliche Systemverbindung 227 kann eine Vorrichtung zum Kommunizieren zwischen mehreren Prozessoren des Systems, zwischen Prozessoren und Peripheriegeräten, und einer anderen Zwischenverbindung, die in einem Computersystem erforderlich ist, umfassen.
Der Platine-C-JTAG-Bus 222 und der Platine-D-JTAG-Bus 224 sind zu einer gemeinsamen Konfigurationslogik 224 gebracht, die sich auf einer anderen Platine, wie der Platine E 230, befinden kann. Die gemeinsame Konfigurationslogik 228 verkörpert eine serielle IIC-Schnittstelle 232, die mit dem Systemverwaltungsbus 226 verbunden ist. Der Systemverwaltungsbus 226 ist ebenfalls mit zumindest einem Systemverwaltungs-Teilsystem 234 verbunden, das zumindest einen Prozessor umfaßt, der einen zugeordneten Speicher umfaßt. Das Systemverwaltungs-Teilsystem 234 ist mit zumindest einer zentralen Verarbeitungseinheit (CPU) 236 des Computersystems verbunden, das mehrere CPUs aufweisen kann.
Ein spezielles Ausführungsbeispiel des Computersystems weist sechzehn CPUs, ein weiteres Ausführungsbeispiel vier CPUs auf. Jede CPU, wie z. B. die CPU 236, die sich auf der Platine F 245 befindet, weist einen zugeordneten Speicher 238 auf und ist Teil einer Partition, die auf einem Betriebssystem, wie z. B. Microsoft Windows, Linux, HP-Unix, oder anderen Betriebssystemen, die in der Technik bekannt sind, arbeiten kann. Die CPUs können auf einer Platine angeordnet sein, wie z. B. der Platine F 245, die ein FPGA 239 aufweisen, das gekoppelt ist, um den Konfigurationscode von einem EEPROM 240 zu empfangen, der wiederum mit einem JTAG-Bus 246 gekoppelt ist, auf den zum Programmieren von der gemeinsamen Konfigurationslogik 228 zugegriffen werden kann. Die CPU 236 ist mit einem Netzwerk 241 gekoppelt, das lokale Netze (LAN), Brandmauern, weite Netze (WAN), wie das Internet, umfassen kann. Mit dem Netzwerk 241 ist auch ein Server 242 mit einer FPGA-Konfigurationscode-Datenbank 244 gekoppelt.
Bei einem alternativen Ausführungsbeispiel weist das Systemverwaltungs-Teilssystem 234 eine direkte Verbindung mit dem Netzwerk 241 auf.
Bei einer ausführlicheren Beschreibung weist die gemeinsame Konfigurationslogik 228 (Fig. 3) ein Auswählregister 300 auf, das durch die IIC-Schnittstelle 232 adressierbar ist. Das Auswählregister 300 bezeichnet, welcher der mehreren JTAG-Ports, wie z. B. die Ports 304, 306 und 308 der gemeinsamen Konfigurationslogik 228, aktiv ist. Ein spezielles Ausführungsbeispiel weist sechzehn JTAG-Ports auf. Es gibt auch eine JTAG-Maschine 310, auf die durch die IIC- Schnittstelle 232 zugegriffen werden kann, die Befehle von der IIC-Schnittstelle 232 interpretieren und den aktiven JTAG-Port gemäß dieser Befehle manipulieren kann.
Die gemeinsame Konfigurationslogik 228 kann daher als Mehrkanal-JTAG-IIC-Busbrücke, wie in Fig. 8 dargestellt ist, operieren.
Die IIC-Schnittstelle 232 der gemeinsamen Konfigurationslogik 228 ist mit dem Systemverwaltungs-Teilsystem 234 über einen Systemverwaltungsbus 226 gekoppelt. Das Systemverwaltungs-Teilsystem 234 weist zumindest einen Prozessor auf, und bei einem Ausführungsbeispiel weist es eine Hierarchie von Prozessoren auf, die einen primären Systemverwaltungsprozessor 312 und einen oder mehrere sekundäre Systemverwaltungsprozessoren 314 umfaßt. Jeder Prozessor weist einen ihm zugeteilten Speicher, wie z. B. den Speicher 316, auf, der auf den gleichen integrierten Schaltungen wie sein ihm zugewiesener Prozessor verkörpert sein kann; und jeder Prozessor ist gekoppelt, um mit dem primären Systemverwaltungsprozessor 312 zu kommunizieren. Das Systemverwaltungs- Teilsystem 234 weist auch eine Schnittstelle 318 zum Kommunizieren mit einer CPU 236 auf. Das Netzwerk 241 weist lokale Netzkomponenten 320, Brandmauern 322 und Weitnetzkomponenten, wie das Internet 324, auf. Die CPU 236 kann über das Netzwerk 241 mit dem Server 242 in einem sicheren, verschlüsselten Modus gekoppelt sein.
Wenn gewünscht ist, daß der FPGA-Code auf einer oder mehreren Platinen des Computersystems 200 aktualisiert werden soll, führt eine CPU 236 eine Host-FPGA-Aktualisierungs- Routine aus. Die CPU 236 des Systems wird daraufhin (Fig. 4, unter Bezugnahme auf Fig. 2 und 3) in einer sicheren Weise mit dem Server 242 verbunden 400 und lädt 402 eine aktualisierte FPGA-Konfigurationscode-Datei auf den Speicher 238 herunter. Der Speicher 238 kann einen Plattenspeicher und/oder RAM-Speicher, der in der Technik der Rechensysteme bekannt ist, umfassen. Anschließend wird die FPGA- Konfigurationscode-Datei zum Speicher 316 des Systemverwaltungs-Teilssystems 234 übertragen. Diese Übertragung 404 kann als eine komplette Dateiübertragung vor dem Initiieren der EEPROM-Programmierung oder als eine Übertragung von individuellen Elementen, oder Blöcken, der FPGA- Konfigurationscode-Datei erfolgen. Ein spezielles Ausführungsbeispiel führt diese Übertragung 404 in einem Blockmodus aus. Die System-CPU 236 startet 405 dann eine FPGA- Konfigurationsroutine auf einem Prozessor, wie z. B. einem primären Prozessor 312 oder einem lokalen Prozessor 314, des Systemverwaltungs-Teilsystems 234. Bei einem speziellen Ausführungsbeispiel arbeitet sie auf einem primären Systemverwaltungsprozessor 312, wobei Befehle durch einen lokalen Prozessor 314 zur IIC-Schnittstelle 232 der gemeinsamen Konfigurationslogik 228 geleitet werden.
Bei einem alternativen Ausführungsbeispiel, wenn gewünscht ist, daß der FPGA-Code auf einer oder mehreren Platinen des Computersystems 200 aktualisiert wird, wird ein Prozessor, wie ein Prozessor 312, der Systemverwaltungs-Teilsystems 234 in einer sicheren Weise mit dem Server 242 verbunden 400 und lädt 402 eine aktualisierte FPGA- Konfigurationscode-Datei auf den Speicher 316 des Systemverwaltungs-Teilsystems 234 herunter. Der Prozessor 312 des Systemverwaltungs-Teilsystems führt dann eine FPGA- Konfigurationsroutine aus.
Bei beiden Ausführungsbeispielen überprüft 406 dann der Systemverwaltungs-Teilsystemprozessor 312, ob ein optionaler Konfigurationsanfangsblock 514 (Fig. 5, nachstehend erörtert) mit einem Konfigurationssystem verbunden ist, und erklärt einen Fehler, wenn dieser derart verbunden ist. Anschließend entscheidet der Systemverwaltungs- Teilsystemprozessor 312 nach Bedarf, um die gemeinsame Konfigurationslogik 228 zuzuweisen 407; sollte ein anderer Prozessor die gemeinsame Konfigurationslogik 228 verwenden, wartet der Systemverwaltungs-Teilssystemprozessor 312, bis die gemeinsame Konfigurationslogik 228 verfügbar ist. Die Zuteilung verhindert, daß ein beliebiger anderer Systemverwaltungs-Teilsystemprozessor, wie z. B. ein Sicherungssystem-Verwaltungsprozessor 528 (Fig. 5, nachstehend erörtert), auf den gleichen EEPROM zugreift, während dieser programmiert wird, und trägt dadurch dazu bei, eine Codekorruption zu verhindern. Die Zuteilung verhindert auch, daß alle anderen Systemverwaltungs-Teilssystemprozessoren, wie z. B. der Sicherungs-Verwaltungsprozessor 528 (Fig. 5, nachstehend erörtert), den Zustand der gemeinsamen Konfigurationslogik 228 ändert, und trägt dadurch dazu bei, eine Unterbrechung der Übertragungen über die JTAG-Busse 222 oder 224 zu verhindern.
Der Systemverwaltungs-Teilsystemprozessor 312 initialisiert dann die gemeinsame Konfigurationslogik 228, einschließlich des Löschens aller Daten, die in den FIFOs der gemeinsamen Konfigurationslogik 228 verbleiben, und stellt 409 das Auswählregister 300 einer Identität des speziellen JTAG-Busses ein, der mit den EEPROMs, die programmiert werden sollen, verbunden ist.
Der Prozessor 312 adressiert als nächstes den ausgewählten JTAG-Bus durch die gemeinsame Konfigurationslogik 228 und bestimmt 410 die JTAG-Buskonfiguration einschließlich der Anzahl und der Typen von Bauelementen auf dem Bus. Dies wird teilweise durch die Verwendung des JTAG- "GET_DEVICE_ID"-Befehls erreicht, der einen Identifikationscode zurücksendet, der den Typ von jedem Bauelement, das mit dem JTAG-Bus verbunden ist, anzeigt. Diese Buskonfiguration einschließlich der Identifikationscodes wird mit den Informationen in der FPGA-Codedatei verglichen 412, um sicher zu stellen, daß der Code mit dem Ziel-JTAG-Bus kompatibel ist. Sollte der Code mit der ausgewählten Platine und dem Ziel-JTAG-Bus inkompatibel sein, wird ein Fehler erklärt 414, und eine Fehlerhandhabungseinrichtung 424 kann versuchen, eine geeignete Codedatei automatisch zu lokalisieren und herunterzuladen. Diese Schritte verifizieren die Kompatibilität der Codedatei mit der ausgewählten Schaltungsplatine.
Bei einem alternativen Ausführungsbeispiel werden, statt eines oder neben einem Vergleich der JTAG-Buskonfiguration mit den Informationen in der Codedatei, die Platinenidentifikationsinformationen von einem EEPROM 512 (Fig. 5), der sich auf jeder Platine befindet, gelesen. Dieser EEPROM wird einem JTAG-Bus 510 auf jeder Platine hinzugefügt. Diese Identifikationsinformationen können verwendet werden, um die Kompatibilität der Codedatei mit der Platine und dem Ziel-JTAG-Bus zu verifizieren, um den geeigneten FPGA-Code aus mehreren FPGA-Codes, die in einer Codedatei enthalten sind, auszuwählen und um eine geeignete FPGA-Codedatei in der FPGA-Codedatenbank 244 auf dem Server 242 zu lokalisieren.
Nach dem Verifizieren der Kompatibilität der Codedatei löscht 416 das Systemverwaltungs-Teilsystem (Fig. 4 unter Bezugnahme auf Fig. 2 und 3) einen oder mehrere EEPROMs, wie den EEPROM 214, der Platine, die an dem ausgewählten JTAG-Bus 222 angebracht sind. Mehr als ein EEPROM kann gelöscht werden, sollte die FPGA-Codedatei einen Code von mehr als ein FPGA der Platine enthalten. Dann schreibt 418 das Konfigurationssystem neue Codeinformationen an die gelöschten EEPROMs über den JTAG-Bus 222. Schließlich überprüft 420 das Systemverwaltungs-Teilsystem im EEPROM- Schreibprozeß 418 nach Fehlern und erklärt einen Fehler 422, wenn ein beliebiger Fehler aufgetreten ist. Wenn die Codedatei nicht korrekt in die EEPROMs der Platine geschrieben wurde, kann eine Fehlerhandhabungseinrichtung 424 die Schritte 402 bis 422 wiederholen: Herunterladen einer kompatiblen FPGA-Konfigurationscode-Datei, Übertragen der Datei an das Systemverwaltungs-Teilsystem, Löschen der EEPROMs und Schreiben der EEPROMs.
Sobald die EEPROMs auf einer Platine programmiert worden sind, gibt 423 der Systemverwaltungs-Teilsystem-Prozessor die gemeinsame Konfigurationslogik 228 frei, so daß durch jeden anderen Prozessor des Systemverwaltungs-Teilsystem auf sie zugegriffen werden kann. Anschließend prüft 426 die Host-FPGA-Aktualisierungsroutine, um zu sehen, ob zusätzliche Platinen oder zusätzliche JTAG-Busse der gleichen Platine programmiert werden sollen. Es werden geeignete Schritte, einschließlich der Schritte des Herunterladens des FPGA-Codes in das Systemverwaltungs-Teilsystem, des Schritts des Löschens der EEPROMs und des Programmierens der EEPROMs nach Bedarf für diese zusätzlichen Platinen oder JTAG-Busse wiederholt.
Sobald alle EEPROMs von allen JTAG-Bussen, die eine Aktualisierung erfordern, programmiert worden sind, kann das System 200 einem Leistungszyklus 428 unterzogen werden, was bewirkt, daß jedes FPGA, wie z. B. das FPGA 208, den aktualisierten Konfigurationscode von den zuordneten EEPROMs, wie dem EEPROM 212, lädt.
Die FPGAs mit den zugeordneten EEPROMs, die auf diese Weise programmierbar sind, können FPGAs 239 auf Platinen, wie der Platine F 245 umfassen, die System-CPUs 236 aufweisen. Die FPGAs mit den zugeordneten EEPROMs, die auf diese Weise programmierbar sind, können auch die gemeinsame Konfigurationslogik 228 an sich umfassen, die bei einem Ausführungsbeispiel als ein FPGA mit einem zugeordneten Konfigurations-EEPROM 330 implementiert ist.
Als Sicherungs-Maßnahme können eine oder mehrere Platinen des Systems 200 einen Konfigurationsanfangsblock 514 aufweisen, der als zusätzliche Möglichkeit des Programmierens seiner FPGAs parallel gekoppelt ist. Auf diese Weise kann zum Programmieren durch einen Kundendienst- oder Betriebs- Techniker auf die Platine zugegriffen werden, sollte sie versehentlich mit einem falschen oder defekten FPGA- Konfigurationscode programmiert worden sein. Zum Beispiel erlaubt ein Sicherungs-Konfigurationsanfangsblock die Reparatur des Systems 200, sollte der EEPROM 330, der der gemeinsamen Konfigurationslogik 228 zugeordnet ist, durch einen Leistungsausfall während der Programmierung über JTAG D 335 verfälscht worden sein.
Bei einem speziellen Ausführungsbeispiel weist eine Platine 500 (Fig. 5) ein erstes FPGA 502 und ein zweites FPGA 504 auf. Die FPGAs 502 und 504 sind gekoppelt, um ihren Konfigurationscode von den EEPROMs 506 und 508 zu empfangen, die in einem JTAG-Bus 510 gekoppelt sind. In dem JTAG-Bus 510 ist auch ein Platinenidentifikations-EEPROM 512 und ein Konfigurationsanfangsblock 514 gekoppelt. Der JTAG-Bus 510wird aus der Platine 500 zur gemeinsamen Konfigurationslogik 516 des Systems gebracht.
Die Quersummenfehlerleitungen 518 und 520 werden von den FPGAs 502 und 504 zu einem lokalen Verwaltungsprozessor 522 gebracht, der sich auf der gleichen Platine 500 befinden kann oder nicht. Der lokale Verwaltungsprozessor 522 ist mit einem Systemverwaltungsbus 524 gekoppelt. Der Systemverwaltungsbus 524 ist mit einem primären Systemverwaltungsprozessor 526 gekoppelt. Ein Sicherungs- Verwaltungsprozessor 528 ist in einer Ersatzschaltkonfiguration (bzw. Failover-Konfiguration) mit dem primären Systemverwaltungsprozessor vorgesehen, um eine Redundanz zu liefern. Der lokale Verwaltungsprozessor ist ebenfalls mit einer FPGA-Wiederladebefehl-Leitung 530 gekoppelt, die mit jedem FPGA einschließlich der FPGAs 502 und 504 der Platine 500 verbunden ist. Die primären und Sicherungs- Systemverwaltungsprozessoren 526 und 528 sind jeweils mit zumindest einer System-CPU (nicht gezeigt) des Systems verbunden.
Bei dem Ausführungsbeispiel von Fig. 5 ist der Schritt, in dem das System einem Leistungszyklus 428 unterzogen wird (Fig. 4), nach dem Beenden des Programmierens der EEPROMs nicht notwendig. Dieser Schritt ist durch die Schritte des vorübergehenden Deaktivierens der Systemverwendung der Logik auf den FPGAs, des Softbootens der FPGAs, die den umprogrammierten EEPROMs zugeordnet sind, um ihren Konfigurationscode wiederzuladen, und des erneuten Aktivierens der Systemverwendung der Logik auf den FPGAs ersetzt worden.
Bei diesem Ausführungsbeispiel, wenn ein Quersummenfehler durch ein FPGA, wie FPGA 504, erfaßt worden ist, signalisiert 702 es (Fig. 7) das Systemverwaltungs-Teilsystem. Das Signalisieren des Systemverwaltungs-Teilsystems kann durch eine Verbindung der Quersummenfehlerleitung 520 mit einem anderen FPGA des Systemverwaltungs-Teilsystems, durch ein kundenspezifisches Logik- oder Gatterarray oder durch eine I/O-Leitung eines Systemverwaltungsprozessors, wie einem lokalen Systemverwaltungsprozessor 522, erfolgen. Der lokale Systemverwaltungsprozessor 522 signalisiert dann einem Betriebssystem, das auf einer CPU, wie z. B. der CPU 236, des Systems arbeitet, um eine Aktualisierung des EEPROMs 508 anzufordern, der dem FPGA 504, das den Fehler erfaßte, zugeordnet ist.
Sobald der Fehler erfaßt und die Aktualisierung angefordert worden ist, wird die Aktualisierung, wie vorstehend unter Bezugnahme auf Fig. 4 erörtert ist, fortgesetzt 706, außer daß bei der Beendung der Programmierung der EEPROMs das zugeordnete FPGA gesoftbootet 708 wird, anstatt das System einem Leistungszyklus zu unterziehen. Das Softbooten wird durch Herunterfahren der Treiber oder der Systemverwaltungsfunktionen, die ein spezielles FPGA verwenden, erreicht, indem ein Laden des Konfigurationscodes von dem zugeordneten EEPROM in das FPGA ausgelöst und alle Treiber oder Systemverwaltungsfunktionen, die das FPGA nutzten, erneut gestartet werden. Es ist daher möglich, den Konfigurationscode für zumindest einige der FPGAs des Systems zu aktualisieren, ohne das System vollständig herunterzufahren.
Bei einem speziellen Ausführungsbeispiel sind die FPGAs, wie das FPGA 600 (Fig. 6), eines Systemverwaltungs- Teilsystems eines komplexen Computersystems gekoppelt, um ihren Konfigurationscode von einem EEPROM 602 zu empfangen. Der EEPROM 602 ist gekoppelt, um über einen JTAG-Bus 604 von der gemeinsamen Konfigurationslogik, die vorstehend erörtert worden ist, programmierbar zu sein. Das FPGA 600 ist mit einem Sortiment von Systemverwaltungssensoren und einer Systemverwaltungs-Hardware gekoppelt, die Lüftergeschwindigkeitssensoren 606, Spannungsüberwachungseinrichtungen 608, einen CPU-Taktgeschwindigkeits-Auswählschaltungsaufbau 610, einen CPU-Spannungs-Auswählschaltungsaufbau 612, Manipulationsschalter 614 und einen Temperaturüberwachungsschaltungsaufbau 616 umfassen können, jedoch nicht auf dieselben beschränkt sind. Das FPGA 600 verkörpert die Logik zur Kommunikation zwischen diesen Systemverwaltungssensoren und der Hardware über einen IIC-Systemverwaltungsbus 620 mit einem Systemverwaltungsprozessor.
Bei einem weiteren Ausführungsbeispiel der Erfindung werden die FPGAs, die ihren Konfigurationscode von den EEPROMs empfangen, die in der hierin erörterten Weise systemintern programmiert werden können, zum Leiten von I/O- Informationen zwischen I/O-Peripheriegeräten und den speziellen System-CPUs des Systems verwendet. Bei noch einem weiteren Ausführungsbeispiel werden die FPGAs, die ihren Konfigurationscode von den EEPROMs empfangen, die in der hierin erörterten Weise systemintern programmiert werden können, für Interprozessor-Kommunikationen zwischen den System-CPUs verwendet.
Bei einer noch ausführlicheren Beschreibung weist die IIC- Schnittstelle 232 der gemeinsamen Konfigurationslogik 228 (Fig. 8) eine physische Slavemodus-Schicht 800 und Adressendekodier- und Steuerregister 802 auf. Diese verbinden den IIC-Bus 226 mit einem internen parallelen Bus 804 schnittstellenmäßig. Die gemeinsame Konfigurationslogik, oder Busbrücke, weist auch eine Vorrichtung 840 zum Koppeln der IIC-Schnittstelle 232 mit den JTAG-Ports 820 auf. Ein 256-Byte-Daten-an-JTAG-FIFO 806 und ein Daten-von-JTAG-FIFO 808 sind zum Puffern von Datenübertragungen zwischen den IIC- und JTAG-Bussen vorgesehen. Die Daten können zwischen dem IIC-Bus und den FIFOs 806 und 808 durch die physische IIC-Slave-Schicht 800 übertragen werden. Die JTAG- Zustandsmaschinen 810 ermöglichen einzelnen IIC-Befehlen, JTAG-Ziele neu einzustellen, die JTAG Konfiguration zu lesen oder bis zu 256 konsekutive Bytes zwischen den FIFOs 806 oder 808 und einem JTAG-Bauelement durch einen Parallel-Seriell-Konverter 812 oder einen Seriell-Parallel- Konverter 814 gemäß der Übertragungsrichtung zu übertragen. Ein einfacher Umgehungsport 816 ermöglicht das Umgehen der Zustandsmaschinen 810 und der FIFOs 806 und 808 im Falle eines Logikfehlers oder des Bedarfs, ungewöhnliche JTAG- Befehle auszuführen.
Das Auswählregister 818 ist durch die IIC-Schnittstelle 232 adressierbar. Das Auswählregister 818 bezeichnet einen von mehreren JTAG-Ports 820, um jederzeit aktiv zu sein. Dies erfolgt durch Anweisen eines Multiplexers 822, eine spezifische Datenleitung von einem JTAG-Port 820 mit dem Seriell-parallel-Konverter 814 zu koppeln und durch Kennzeichnen, welcher JTAG-Port 820 die JTAG-Auswahlleitungen von der Takt- und Auswählgatterlogik 824 empfangen soll.
Die gemeinsame Konfigurationslogik 228 weist auch ein Statusregister 826 auf, das Fehler-Flags, FIFO-Peilstäbe (bzw. FIFO-Dipsticks) 900 und 902 (Fig. 9), FIFO-Leer-Flags 904 und 906 umfaßt, und einen Konfigurationsanfangsblock, der mit dem Flag 908 verbunden ist. Der Konfigurationsanfangsblock, der mit dem Flag 908 verbunden ist, zeigt an, ob ein beliebiger der optionalen Konfigurationsanfangsblöcke, wie der Anfangsblock 514, mit einem Konfigurationssystem verbunden ist. Wenn ein Konfigurationssystem mit einem Anfangsblock 514 verbunden ist, identifiziert der Systemverwaltungsprozessor 526 dies, wenn er nach einem verbundenen Anfangsblock prüft 406, und lehnt es ab, die EEPROMs zu programmieren, um eine versehentliche Korruption der EEPROM-Inhalte zu verhindern.
Die FIFO-Leer-Flags 904 und 906 werden getestet, um sicherzustellen, daß alle Übertragungen vollendet sind, wenn der Systemverwaltungs-Teilprozessor 312 nach Fehlern 420 sucht, nachdem der Code 418 an die EEPROMs geschrieben worden ist.
Bei einem alternativen Ausführungsbeispiel wird die Firmware-Sequenz von Fig. 10A auf einem Systemverwaltungsprozessor, wie einem primären Systemverwaltungsprozessor 526 (Fig. 5), oder Systemverwaltungsprozessor 312 (Fig. 3) ausgeführt. Diese Sequenz wird immer dann eingegeben 1000, wenn ein dahingehender Befehl von einem Systemprozessor 236(Fig. 3) gesendet wird, durch einen Anschluß eingegeben wird, der mit dem Systemverwaltungsprozessor 312 verbunden ist, oder wenn ein programmierbares logisches Bauelement, wie z. B. das FPGA 502 (Fig. 5), einen Fehler erfaßt, während der Konfigurationscode empfangen wird.
Der Systemverwaltungsprozessor 312 überprüft 1002, ob ein beliebiger Konfigurationsanfangsblock, wie der Anfangsblock 514, mit einem Konfigurationssystem verbunden ist; wenn ein Konfigurationssystem verbunden ist, wird ein Fehler erklärt, und die Sequenz wird abgebrochen 1003. Der Prozessor 312 wird dann durch ein Netzwerk 241 mit einem Server 242 mit einer Datenbank 244 der Konfigurationscode-Dateien verbunden. Für jede Platine 500 des Systems fragt 1006 der Systemverwaltungsprozessor 312 einen Platinenidentifikations- EEPROM 512 ab, ob zumindest ein JTAG-Bus der Platine 500 derart ausgerüstet ist, und liest einen Platinenidentitätscode von diesem EEPROM 512. Wenn kein derartiger Identifikations-EEPROM 512 existiert, bestimmt der Systemverwaltungsprozessor 312 die JTAG-Buskonfiguration für jeden Bus auf der Platine 500 und leitet eine Signatur von diesen Konfigurationen ab; die Signatur wird als ein Ersatz- Platinenidentitäts-Code verwendet. Die Schritte des Lesens des Platinenidentifikations-EEPROMs und des Bestimmens der JTAG-Buskonfiguration sind vor einer Störung durch andere Systemverwaltungsprozessoren geschützt, die versuchen könnten, auf die gemeinsame Konfigurationslogik 516 oder 228 durch Zuordnen oder Aufheben der Zuordnung (nicht gezeigt) der gemeinsamen Konfigurationslogik zuzugreifen.
Der Platinenidentitätscode wird als ein Index auf die Datenbank 244 verwendet, um die Konfigurationscode-Dateien, die für die Platine 500 geeignet sind, zu lokalisieren 1008. Jeder EEPROM von jedem Bus der Platine 500 wird ebenfalls getestet, um zu bestimmen, ob der EEPROM einen gültigen Code enthält, indem eine Quersumme verifiziert wird, die dem Konfigurationscode im EEPROM zugeordnet ist. Für EEPROMs mit einem gültigen Code werden die Versionsinformationen, die diesen Konfigurationsdateien zugeordnet sind, mit den Versionsinformationen in den Konfigurationsdateien der Datenbank 244 verglichen. Wenn die EEPROMs einen Code enthalten, der sowohl gültig als auch aktuell 1010 ist, kann die Programmierung dieses EEPROMs umgangen 1012 werden; die EEPROMs, die den Code enthalten, der entweder ungültig oder nicht aktuell ist, werden programmiert 1014.
Wenn ein beliebiger EEPROM von einem beliebigen JTAG-Bus der Platine den Code enthält, der entweder ungültig oder nicht aktuell ist, wird der entsprechende FPGA-Code von der Datenbank 244 heruntergeladen 1016 (Fig. 10B). Anschließend wird der gemeinsamen Konfigurationslogik 516 zugeordnet 1018, und alle übrig gebliebenen Daten werden von den FIFOs 806 und 808 gelöscht 1020. Das Auswählregister wird auf einen JTAG-Bus mit EEPROMs, die programmiert werden sollen, eingestellt 1022, und die Konfiguration dieses Busses wird bestimmt 1024. Die bestimmte Konfiguration wird mit den erwarteten Konfigurationsinformationen in der heruntergeladenen Codedatei verglichen 1026, um sicher zu stellen, daß eine inkorrekte Codedatei nicht zum Programmieren verwendet wird, und ein Fehler wird erklärt, wenn 1028 der Code für die Konfiguration nicht korrekt ist.
Wenn der Code für die Konfiguration nicht korrekt ist, kann eine Fehlerhandhabungseinrichtung 1030 einen Versuch unternehmen, den korrekten Code basierend auf einer Signatur, die von der bestimmten Buskonfiguration abgeleitet wurde, zu lokalisieren. Wenn 1032 der Code gefunden worden ist, startet die Sequenz erneut durch Herunterladen 1016 dieses Codes; wenn er nicht gefunden wird, wird die Programmierung abgebrochen 1034.
Wenn 1028 die bestimmte Buskonfiguration mit der Konfiguration des ausgewählten JTAG-Busses übereinstimmt, werden die EEPROMs der ausgewählten JTAG-Busses gelöscht 1036, und die Blöcke des Codes der heruntergeladenen Codedatei werden in die EEPROMs geschrieben 1038. Am Ende von jedem Block werden die FIFOs 806 und 808 geprüft, ob sie leer 1040 sind, wenn sie nicht leer sind, wartet die Sequenz 1042, bis die Übertragung vom FIFO zum EEPROM vollendet ist, und überprüft erneut 1044, ob die FIFOs 806 und 808 leer sind. Wenn die FIFOs immer noch nicht leer sind, oder ein anderer Fehler aufgetreten ist, wird eine Überprüfung eines Durchlaufzählwert 1046 vorgenommen, um zu bestimmen, ob der Block bereits erneut versucht worden ist, und wenn dies nicht der Fall ist, werden die FIFOs gelöscht und die Programmierung des Blocks wird erneut versucht 1050. Wenn 1046 der Block erneut versucht worden ist, wird ein Fehler erklärt 1052. Eine Fehlersequenz kann weitere Versuche unternehmen, die EEPROMs mit dem Block vor dem Abbrechen zu schreiben.
Wenn 1044 die FIFOs korrekt geleert worden sind, wird eine Überprüfung 1054 vorgenommen, ob der Block, der geschrieben wurde, der letzte Block des Codes war; ist dies nicht der Fall, wird der nächste Block an die EEPROMs geschrieben 1038. Wenn 1054 alle Blöcke geschrieben worden sind, wird der JTAG-Bus deselektiert 1056, und die gemeinsame Konfigurationslogik wird freigegeben 1058.
Anschließend wird ein Test ausgeführt, um zu bestimmen, ob alle JTAG-Busse der Platine programmiert 1060 worden sind (Fig. 10A). Wenn 1062 mehr Busse der Platine eine Programmierung anfordern, wird ein Buszählwert inkrementiert, wobei der nächste JTAG-Bus der Platine gewählt wird, und die EEPROMs dieses nächsten Busses werden getestet 1010, um zu bestimmen, ob ihr Code gültig und aktuell ist; dem folgt nach Bedarf ein Schreiben 1014 jener EEPROMs, die keinen gültigen und aktuellen Code enthalten.
Wenn 1062 keine Busse der Platine mehr eine Programmierung erfordern, wird eine Prüfung 1064 nach zusätzlichen Platinen des Systems mit JTAG-Bussen mit EEPROMs vorgenommen, die eine Programmierung benötigen. Wenn 1066 zusätzliche Platinen eine Programmierung erfordern, wird ein beliebiger Identifikations-EEPROM der nächsten Platine abgefragt 1006, und die Sequenz fährt mit dem Lokalisieren 1008 der Konfigurationscode-Dateien für die EEPROMs dieser Platine fort.
Wenn 1064 keine Platinen mehr programmiert werden müssen, wird die Systemfunktion der FPGAs, für die der neue Konfigurationscode geschrieben 1014 wurde, deaktiviert 1066. Diese FPGAs werden dann gesoftgebootet 1068, um ihren Konfigurationscode erneut zu laden, und ihre Systemfunktion wird erneut aktiviert 1070. Schließlich wird der Verwaltungsprozessor vom Server 242 getrennt 1072, und eine System-CPU wird über Maßnahmen informiert, die durch den Verwaltungsprozessor vorgenommen wurden, so daß die System-CPU ein Systeminstandhaltungs-Protokoll aktualisieren kann.
Die Erfindung ist unter Bezugnahme auf eine spezielle Partitionierung von funktionalen Elementen auf Schaltungsplatinen eines Computersystems, das die Erfindung verkörpert, beschrieben worden. Die Erfindung ist auf alternative Partitionierungen des Systems anwendbar. Es kann zusätzliche Platinen oder einen Schaltungsaufbau geben, die als separate Platinen dargestellt sind, die nach Bedarf für ein spezielles Ausführungsbeispiel kombiniert werden können. Zum Beispiel könnte die gemeinsame Konfigurationslogik, die auf der Platine E 230 dargestellt ist, auf einer Schaltungsplatine mit dem Schaltungsaufbau von Platine D 204 kombiniert werden könnte, ist jedoch nicht auf diese Kombination beschränkt.

Claims

1. Verfahren zum Aktualisieren eines Konfigurationscodes eines Bausteins, der in EEPROMs (212, 214, 216) eines Systems gespeichert ist, das das Ausführen einer Sequenz zum Aktualisieren des Konfigurationscodes des programmierbaren Bausteins auf einem Verwaltungsprozessor (526) des Systems aufweist, wobei die Sequenz zum Aktualisieren des Konfigurationscodes des programmierbaren Bausteins ferner folgende Schritte aufweist:
Löschen (1036) zumindest eines (212) der EEPROMs (212, 214, 216);
Schreiben (1038) von zumindest einem Block des Konfigurationscodes in die gelöschten EEPROMS (212); und
Überprüfen bezüglich Fehlern (1046) nach dem Schreiben des zumindest einen Blocks, wobei die Fehler einen Mißerfolg beim Leeren eines FIFOs (806, 808) umfassen, und wiederholtes Versuchen (1050) des Schritts des Schreibens (1038) von zumindest einem Block auf einen Fehler hin.

2. Verfahren gemäß Anspruch 1, das ferner den Schritt des Verifizierens (1028) aufweist, daß eine Datei einen Konfigurationscode aufweist, der mit dem System kompatibel ist.

3. Verfahren gemäß Anspruch 2, bei dem der Schritt des Verifizierens (1024, 1026, 1028), daß eine Datei einen Konfigurationscode enthält, der mit dem System kompatibel ist, den Schritt des Abrufens (1024) eines JTAG- Busses (222) des Systems, um die Konfiguration des JTAG-Busses (222) zu bestimmen, und den Schritt des Vergleichens (1026) der Konfiguration mit einer Konfiguration, die in der Datei gespeichert ist, aufweist.

4. Verfahren zum Aktualisieren eines programmierbaren Bauelementekonfigurationscodes, der in EEPROMs (212, 214, 216) eines Systems gespeichert ist, wobei das Verfahren folgende Schritte aufweist:
Liefern von zumindest einem seriellen Bus (222), der die EEPROMs (212, 214, 216) des Systems mit einer gemeinsamen Konfigurationslogik verbindet;
Erhalten (402) einer Datei eines Konfigurationscodes;
Verifizieren der Kompatibilität (410, 412, 414) der Datei mit dem seriellen Bus;
Löschen (416) von zumindest einem EEPROM (212) der EEPROMs (212, 214, 216);
Schreiben (418) von zumindest einem Block des Konfigurationscodes in die EEPROMs (212); und
Überprüfen (429) bezüglich Fehlern nach dem Schreiben der Blöcke, wobei die Fehler einen Mißerfolg beim Leeren eines FIFOs umfassen, und erneutes Versuchen (1050) des Schritts des Schreibens (418) von zumindest einem Block auf einen Fehler hin.

5. Verfahren gemäß Anspruch 4, das ferner den Schritt des Softbootens (1068) von zumindest einem programmierbaren logischen Bauelementstein (208) aufweist, um den Konfigurationscode von einem EEPROM (212) von dem zumindest einem EEPROM (212, 214, 216) in den programmierbaren logischen Baustein zu laden.

6. Verfahren gemäß Anspruch 5, bei dem das System mehr als einen Prozessor (236) aufweist, und das ferner den Schritt des Zuordnens der gemeinsamen Konfigurationslogik (228) aufweist, um einen gleichzeitigen Zugriff durch mehr als einen Prozessor (236) des Systems zu verhindern.

7. Verfahren gemäß Anspruch 5, bei dem zumindest ein serieller Bus (222), der die EEPROMs (212, 214, 216) des Systems mit einer gemeinsamen Konfigurationslogik verbindet, eine Mehrzahl von seriellen Busse (222, 224) darstellt, und das ferner den Schritt des Auswählens (1022) eines speziellen seriellen Busses (222) aus der Mehrzahl von seriellen Bussen (222, 224) aufweist.

8. Verfahren gemäß Anspruch 5, bei dem zumindest ein programmierbares logisches Bauelement (208) ein FPGA (208) ist und wobei das Verfahren automatisch auf einen Fehler hin aufgeführt wird, wobei ein Konfigurationscode von dem EEPROM (212) in das FPGA (208) geladen wird.