DE102004044963A1

DE102004044963A1 - Protokollverfahren für wiederverwendbare Hardware-IP bei einer System-on-Chip-Vorrichtung

Info

Publication number: DE102004044963A1
Application number: DE102004044963A
Authority: DE
Inventors: Fu-Chiung Cheng
Original assignee: Tatung Co Ltd
Current assignee: Tatung Co Ltd
Priority date: 2004-09-16
Filing date: 2004-09-16
Publication date: 2006-04-06

Abstract

Es wird ein Protokollverfahren für wiederverwendbare Hardware-IP (Intellectual Property) bei einem System-on-Chip offenbart, das eine Softwarefunktion verwendet, um das Verhalten einer Hardware zu beschreiben. Das Aufrufen der Software entspricht der Ausführung der Hardware-IP-Komponente, und der Ablauf der Softwarefunktion entspricht dem Verhalten der Hardware-IP. Somit kann die Hardware-IP als Softwarefunktion wiederverwendet werden.

Description

HINTERGRUND DER ERFINDUNG
1. Gebiet der Erfindung
Die vorliegende Erfindung betrifft ein Protokollverfahren für eine System-on-Chip-Vorrichtung, insbesondere ein Protokollverfahren für wiederverwendbare Hardware-IP bei einer System-on-Chip-Vorrichtung.

System-on-Chip-Konstruktionen sind zu einem wichtigen Trend bei derzeitigen Schaltungskonstruktionen geworden, wobei hier mehrere in ihrer Funktion zusammenhängende Schaltungsblocks in einem Chip integriert sind. Wenn man einen System-on-Chip-Mikroprozessor auf dem Gebiet der Datenverarbeitung als Beispiel nimmt, so werden in den internen Schaltungen des System-on-Chip die Schaltungsblocks einer Zentraleinheit, eines Chipsatzes und eines Grafikchips integriert, so dass der System-on-Chip-Mikroprozessor die Funktionsweise all dieser drei Schaltungsblocks enthält. Die System-on-Chip-Konstruktion verringert nicht nur die Herstellungskosten, sondern auch die Gesamtfläche der Schaltung, wodurch wiederum die Gesamtgröße der Schaltung reduziert wird. Jeder Schaltungsblock setzt sich aus mehreren unterschiedlichen Schaltungsmodulen zusammen, zu welchen Zähler, Addierer, Codierer, Decodierer, etc. zählen können, die als Hardware-IP (Intellectual Property) bekannt sind. Die System-on-Chip-Konstruktion verwendet Hardware-IPs, um die erforderlichen Schaltungsblocks zu bilden und integriert dann die Schaltungsblocks zusammen in einem einzigen Chip.

Bei der System-on-Chip-Konstruktion bestehen jedoch auch einige Probleme. Das wichtigste Problem ist die Taktfrequenzsteuerung zwischen den unterschiedlichen Hardware-IP-Komponenten. Ein Taktfrequenzsignal wird verwendet, um eine Arbeitsgeschwindigkeit jeder Hardware-IP-Komponente in dem System-on-Chip zu steuern. Wenn das Taktfrequenzsignal an jeden Schaltungsblock in dem System-on-Chip übermittelt wird, arbeiten alle Hardware-IP-Komponenten in dem Schaltungsblock mit der gleichen Frequenz. Da jedes Hardware-IP-Komponente seine eigene Arbeitsfrequenz hat, muss das Taktfrequenzsignal – um zu ermöglichen, dass mehrere Hardware-IP-Komponenten mit einer einzigen Taktfrequenz arbeiten – der niedrigsten Taktfrequenz genügen, um eine falsche zeitliche Steuerung zu vermeiden. Hierdurch wird jedoch die Wirksamkeit des Gesamtsystems verringert.

Es ist deshalb wünschenswert, ein Protokollverfahren für wiederverwendbare Hardware-IP-Komponenten bei einem System-on-Chip zu schaffen, um die vorgenannten Probleme zu mildern und/oder zu beseitigen.

ZUSAMMENFASSUNG DER ERFINDUNG

Der vorliegenden Erfindung liegt hauptsächlich die Aufgabe zu Grunde, ein Protokollverfahren für wiederverwendbare Hardware-IP-Komponenten bei einem System-on-Chip zu schaffen, mit dem das Hardware-Verhalten durch Software-Funktionen beschrieben werden kann.

Eine weitere Aufgabe der vorliegenden Erfindung besteht darin, ein Protokollverfahren für wiederverwendbare Hardware-IP-Komponenten bei einem System-on-Chip zu schaffen, das häufig wiederverwendet werden kann.

Eine weitere Aufgabe der vorliegenden Erfindung besteht darin, ein Protokollverfahren für wiederverwendbare Hardware-IP-Komponenten bei einem System-on-Chip zu schaffen, das bei asynchronen Schaltungskonstruktionen verwendet werden kann.

Um die vorgenannten Aufgaben zu erfüllen, offenbart die vorliegende Erfindung ein Protokollverfahren für wiederverwendbare Hardware-IP-Komponenten bei einem System-on-Chip, das Folgendes umfasst: (A) Bestimmen, ob irgendwelche Parameter erforderlich sind, entsprechend einem Schritt, bei dem bestimmt wird, ob das Hardware-Modul irgendwelche Parameter benötigt, wobei mit Schritt (B) fortgefahren wird, wenn Parameter benötigt werden, und mit Schritt (C), wenn keine benötigt werden; (B) Eingabe mindestens eines Funktionsparameters, entsprechend einem Eingabeschritt des Hardware-Moduls für mindestens einen Funktionsdatenparameter; (C) Aufrufen einer Softwarefunktion, die einem Signalanforderungsschritt des Hardware-Moduls entspricht; (D) Warten auf einen Rückgabewert von der Softwarefunktion, was einem Schritt des Wartens auf ein Bestätigungssignal des Hardware-Moduls entspricht; (E) Zurücksenden des Rückgabewerts von der Softwarefunktion, was einem Schritt der Ausgabe von Ergebnisdaten des Hardware-Moduls entspricht; und (F) Beenden der Softwarefunktion, was einem Hardware-Reset-Schritt des Hardware-Moduls entspricht.

Schließlich wird die Softwarefunktion noch verwendet, um eine Hardwarebeschreibungssprache zu erzeugen, und die Hardwarebeschreibungssprache wird verwendet, um Hardware-IP-Komponenten zu erzeugen. Das System-on-Chip ist für mindestens ein Hardware-Modul konstruiert, und das Hardware-Modul arbeitet asynchron. Die Softwarefunktion gemäß der vorliegenden Erfindung kann verwendet werden, um die Performance der Hardware zu beschreiben, und kann sowohl für synchrone als auch für asynchrone Schaltungskonstruktionen verwendet werden, um die Aufgaben der vorliegenden Erfindung zu erfüllen.

Weitere Aufgaben, Vorteile und neue Merkmale der Erfindung werden nachfolgend anhand der Zeichnung näher erläutert.

KURZE BESCHREIBUNG DER ZEICHNUNG
In der Zeichnung zeigen:
1 ein Software-Ablaufdiagramm eines Protokollverfahrens für wiederverwendbare Hardware-IP-Komponenten bei einem System-on-Chip gemäß der vorliegenden Erfindung;
2 ein Ablaufdiagramm der Arbeit der Hardware-IP-Komponente entsprechend 1; und
3 eine schematische Darstellung der Arbeit der Hardware-IP-Komponente.
AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
1 zeigt ein Software-Ablaufdiagramm eines Protokollverfahrens für wiederverwendbare Hardware-IP-Komponenten bei einem System-on-Chip gemäß der vorliegenden Erfindung. Das Verfahren der vorliegenden Erfindung verwendet eine Softwarefunktion, um das Verhalten der Hardware-IP zu beschreiben, und ruft das Software-Modul auf, der Ausführung der Hardware-IP-Komponente zu entsprechen. Nachfolgend wird auf 1, 2 und 3 Bezug genommen. 2 ist ein Ablaufdiagramm des Verhaltens der Hardware-IP-Komponente entsprechend 1. 3 zeigt das Diagramm der zeitlichen Steuerung des Verhaltens der Hardware-IP-Komponente. Wie in 1 dargestellt, weist ein Ablauf des Verfahrens gemäß der vorliegenden Erfindung Folgendes auf:
Schritt 10: Bestimmen, ob die Softwarefunktion irgendwelche Parameter benötigt; falls ja, wird Schritt 12 ausgeführt; falls nein, wird Schritt 14 ausgeführt. Die Softwarefunktion kann folgende Akkumulationsfunktion (1) sein, ist jedoch nicht auf diese Funktion beschränkt:
Bevor die Funktion (1) aufgerufen wird, muss ein Funktionsparameter festgelegt und eingegeben werden, beispielsweise wird der Funktionsparameter CNT auf 5 festgelegt.
Wie bekannt ist, wird, wenn die Hardware-IP-Komponente ein Reset ausführt oder bootet, immer der Schritt 30 ausgeführt, um die Hardware für jegliche nachfolgende Ausführung zu initialisieren. Darüber hinaus ist in 3 die Arbeit der Hardware des Schritts 30 an einer ansteigenden Flanke eines CLR-Signals dargestellt, was bedeutet, dass das CLR-Signal als High State festgelegt wird, um jegliche Daten zu löschen, die vorübergehend in den Hardware-IP-Komponenten gespeichert sind.
Schritt 10 für die Softwarefunktion entspricht Schritt 32 für die Hardware-IP-Komponente, wobei Schritt 32 ausgeführt wird, um zu bestimmen, ob die Hardware-IP-Komponente irgendwelche Parameter benötigt; falls ja, wird Schritt 34 ausgeführt, um Parameterdaten einzugeben, was Schritt 12 entspricht. Wenn in Schritt 32 bestimmt wird, dass keine Hardware-IP-Komponente erforderlich ist, wird Schritt 36 ausgeführt, um ein Anforderungssignal zu ermöglichen, was Schritt 14 entspricht. In 3 ist die Arbeit der Hardware des Schrtts 34 als ansteigende Flanke 52 der Parameterdaten dargestellt, was bedeutet, dass eine externe Schaltung (die mit der Hardware-IP-Komponente verbundene Schaltung) Parameterdaten (wie z.B. den vorgenannten Para meter CNT = 5) in die Hardware-IP-Komponente eingibt. Die externe Schaltung kann auch das Bestätigungssignal empfangen, dass die Eingabedaten von der Hardware-IP-Komponente empfangen wurden.
Schritt 14 wird ausgeführt, um die Softwarefunktion aufzurufen. Für die Funktion (1) sollte nach dem Schritt 12 die Software ausgeführt werden. Schritt 14 führt folgenden Code aus:
Darüber hinaus entspricht Schritt 14 in 2 dem Schritt 36, der ausgeführt wird, um ein Anforderungssignal (REQ zu ermöglichen. Das REQ-Signal in einem High State wird von der externen Schaltung in die Hardware-IP-Komponente eingegeben, und die Hardware-IP-Komponente führt nach funktionalen Einstellungen und den Eingabeparametern einen Vorgang der internen Schaltung aus (entsprechend Schritt 14) und erzeugt eine angemessene Antwort (das Ausgabeergebnis des Schritts 14). Der Schritt 36 ist in 3 als ansteigende Flanke 54 dargestellt, was bedeutet, dass die externe Schaltung das REQ-Signal mit einem High State festlegt, und dann beginnt die interne Schaltung in der Hardware-IP-Komponente zu arbeiten.
Der Schritt 16 wird ausgeführt, um einen Rückgabewert von der Softwarefunktion abzuwarten. Wenn bei der Funktion (1) der Parameter (in Schritt 12) bereitgestellt wird und (in Schritt 16) ausgeführt worden ist, sendet die Funktion (1) einen Ergebniswert (oder einen Rückgabewert) zurück.
Darüber hinaus entspricht der Schritt 16 in 2 dem Schritt 38, der ausgeführt wird, um ein Bestätigungssignal (ACK) abzuwarten. Nachdem die Hardware-IP-Komponente ihre angemessene Arbeit ausgeführt hat, wird der Ergebniswert von der Hardware-IP-Komponente erzeugt und an die externe Schaltung abgegeben. Das ACK-Signal wird von der Hardware-IP zur externen Schaltung gesandt, was anzeigt, dass der Ergebniswert produziert wird. Dann ist die Hardware-IP-Komponente bereit, den Ergebniswert an die externe Schaltung abzugeben. Der Schritt 38 ist in 3 als ansteigende Flanke 56 des ACK-Signals dargestellt, wobei die Hardware-IP-Komponente den angeforderten Vorgang abschließt und den Ergebniswert an die externe Schaltung abgibt, wenn die Hardware-IP das ACK-Signal von einem Low State in einen High State erhebt.
Schritt 18 wird ausgeführt, um den Rückgabewert der Softwarefunktion zurückzusenden. Nachdem die Funktion (1) den Vorgang abgeschlossen hat, wird der Rückgabewert zurückgesandt. Da der CNT-Parameter 5 ist, läuft die Funktion (1) und kommt zu einem Ergebnis eines SUM-Parameters von 15 und sendet den SUM-Parameter zurück. Der Schritt 18 entspricht dem Schritt 40 in 2, der ausgeführt wird, um die Ergebnisdaten auszugeben. Wenn sowohl das REQ-Signal als auch das ACK-Signal auf den High State festgelegt werden, gibt die Hardware-IP-Komponente den Ergebniswert des Vorgangs an die externe Schaltung ab, d.h. sie gibt die Ergebnisdaten 15 aus. Der Schritt 40 ist in 3 als ansteigende Flanke 58 der Ergebnisdaten dargestellt, was die Ausgabe der Ergebnisdaten 15 anzeigt.
Der Schritt 20 wird ausgeführt, um die Softwarefunktion zu beenden. Nachdem die Funktion (1) den Rückgabewert zurückgesandt hat, hat die Funktion (1) ihre Aufgabe beendet und die Funktion kann erneut aufgerufen werden. Der Schritt 20 entspricht dem in 2 dargestellten Schritt 42, der ausgeführt wird, um ein Reset der Hardware durchzuführen. Nach dem Empfang der Ergebnisdaten legt die externe Schaltung das REQ-Signal auf den Low State fest, so dass die IP-Komponente die vorübergehend gespeicherten Daten löschen kann und für den nächsten Aufruf bereit ist. Der Schritt 42 ist in 3 als abfallende Flanke 60 des REQ-Signals dargestellt. Wenn das REQ- Signal in einem Low State ist, stoppt die Hardware-IP-Komponente die Ausgabe der Ergebnisdaten und löscht alle Ergebnisdaten in der Hardware-IP-Komponente, wie dies durch eine abfallende Flanke 62 eines Datensignals gemäß 3 angezeigt ist. Wenn das ACK-Signal im Low State ist, was bedeutet, dass die Ergebnisdaten vollständig gelöscht worden sind, wie in 3 durch eine abfallende Flanke 64 des ACK-Signals angezeigt, ist die Hardware-IP-Komponente bereit für einen nachfolgenden Vorgang.
Darüber hinaus wird bei der Eingabe der Parameter und bei der Ausgabe der Ergebnisdaten eine Doppelprüfungs-Datendarstellung verwendet, um sicherzugehen, dass die Ausgabe-/Eingabevorgänge abgeschlossen sind, ebenso wie die Ausführung eines Fehlererfassungsmittels. Wie bei dem Schritt 34 werden bei der Eingabe der Parameterdaten auch gleichzeitig Parameterdaten für die Erfassung der Vollständigkeit bzw. die Erfassung von Fehlern (CDED) eingegeben, indem beispielsweise eine Komplementärtechnik verwendet wird (wie sie auch in Schritt 40 verwendet wird), die bestimmt, ob die Summe der Parameterdaten und der CDED-Parameterdaten –1 entspricht. Es existieren jedoch noch viele andere Fehlererfassungsverfahren, die angewendet werden können. Wenn die Parameterdaten als CNT = 5 eingegeben werden, werden die CDED-Parameter als CNT' = –6 eingegeben, und die Hardware-Ausführung ist in 3 als ansteigende Flanke 53 der CDED-Parameterdaten dargestellt; wenn die Ergebnisdaten als SUM = 1 ausgegeben werden, werden die Erfassungs-/Nach-Erfassungsparameterdaten als SUM' = –16 ausgegeben, und die Hardware-Ausführung ist in 3 als ansteigende Flanke 59 der CDED-Parameterdaten dargestellt. Somit ist die Richtigkeit der Datenübertragung sichergestellt.
Die Softwarefunktion gemäß dieser Ausführungsform kann verwendet werden, um die Leistung bzw. Arbeit der Hardware-IP-Komponente anzuzeigen, und die Softwarefunktion kann wiederholt aufgerufen werden, was bedeutet, dass die Hardware-IP-Komponente den Vorgang wiederholen kann. Also kann die Softwarefunktion in eine praktische Hardwarestruktur umgewandelt werden. So kann beispielsweise die Softwarefunktion in eine bekannte VHSIC (Very High Speed Integrated Circuits) Hardware Description Language (VHDL) umgewandelt werden, und die VHDL wird dann in eine praktische Hardwarestruktur umgewandelt. Mit anderen Worten: Die Softwarefunktion kann die Leistung der Hardware beschreiben. Wenn das System-on-Chip so konstruiert ist, dass es mehr als eine Softwarefunktion hat, können außerdem die unterschiedlichen Hardware-IP-Komponenten unterschiedliche Taktfrequenzen haben, da die Hardware-IP-Komponente, die der Softwarefunktion entspricht, durch die vorgenannten Schritte implementiert wird und die Taktfrequenz hierfür irrelevant ist. Daher kann die Hardware-IP-Komponente sowohl bei synchronen als auch bei asynchronen System-on-Chip-Konstruktionen korrekt arbeiten.
Obwohl die vorliegende Erfindung in Bezug auf ihre bevorzugte Ausführungsform erläutert wurde, versteht es sich, dass noch viele andere Modifikationen und Änderungen möglich sind, ohne von der Essenz und vom Umfang der nachfolgend beanspruchten Erfindung abzuweichen.

Claims

Protokollverfahren für wiederverwendbare Hardware-IP (Intellectual Property) bei einer System-on-Chip-Vorrichtung, das in der Lage ist, das Verhalten einer Hardware über eine Softwarefunktion zu beschreiben, wobei das Verfahren Folgendes umfasst: (A) Bestimmen, ob irgendwelche Parameter erforderlich sind, entsprechend einer Bestimmung, ob die Hardware-IP irgendwelche Parameter benötigt, wobei mit Schritt (B) fortgefahren wird, wenn Parameter benötigt werden, und mit Schritt (C), wenn keine benötigt werden; (B) Eingabe mindestens eines Funktionsparameters, entsprechend einer Eingabe mindestens eines Funktionsparameters in die Hardware-IP; (C) Aufrufen der Softwarefunktion, entsprechend einer Eingabe eines Anforderungssignals in die Hardware-IP; (D) Warten auf einen Rückgabewert von der Softwarefunktion, entsprechend einer Eingabe eines Bestätigungssignals in die Hardware-IP; (E) Zurücksenden des Rückgabewerts von der Softwarefunktion, entsprechend einer Ausgabe der Ergebnisdaten aus der Hardware-IP; und (F) Beenden der Softwarefunktion, entsprechend der Durchführung eines Reset oder dem Booten der Hardware-IP.
Verfahren nach Anspruch 1, das außerdem vor dem Schritt (A) einen Hardware-Initialisierungsschritt zum Initialisieren der Hardware-IP aufweist.
Verfahren nach Anspruch 1, bei dem der Schritt (B) außerdem eine Eingabe mindestens eines Erfassungsdatums umfasst, das dem mindestens einen Funktionsparameter entspricht.
Verfahren nach Anspruch 3, bei dem das mindestens eine Erfassungsdatum eine Komplementärzahl des mindestens einen Funktionsparameters ist.
Verfahren nach Anspruch 4, bei dem das mindestens eine Erfassungsdatum verwendet wird, um zu erfassen, ob der mindestens eine Funktionsparameter inkorrekt ist, oder um zu erfassen, ob der mindestens eine Funktionsparameter vollständig eingegeben ist.
Verfahren nach Anspruch 1, bei dem der Schritt (E) außerdem die Ausgabe von mindestens einem Erfassungs-Ergebnisdatum aus der Hardware-IP umfasst, und bei dem das mindestens eine Erfassungs-Ergebnisdatum dem Ergebnisdatum entspricht.
Verfahren nach Anspruch 6, bei dem das mindestens eine Erfassungs-Ergebnisdatum eine Komplementärzahl des mindestens einen Ergebnisdatums ist.
Verfahren nach Anspruch 4, bei dem das mindestens eine Erfassungs-Ergebnisdatum verwendet wird, um zu erfassen, ob das mindestens eine Ergebnisdatum inkorrekt ist, oder um zu erfassen, ob das mindestens eine Ergebnisdatum vollständig eingegeben ist.
Verfahren nach Anspruch 1, bei dem die Softwarefunktion in eine Hardware-Beschreibungssprache umgewandelt werden kann.
Verfahren nach Anspruch 1, bei dem die System-on-Chip-Vorrichtung mindestens eine Hardware-IP aufweist und eine Interaktion jeder der mindestens einen Hardware-IP asynchron ist.