DE10318812A1

DE10318812A1 - Chipentwicklungssystem und Chipentwicklungsverfahren

Info

Publication number: DE10318812A1
Application number: DE10318812A
Authority: DE
Inventors: Hwang-Kyu Lim
Original assignee: Samsung Electronics Co Ltd
Current assignee: Samsung Electronics Co Ltd
Priority date: 2002-05-20
Filing date: 2003-04-17
Publication date: 2003-12-24
Also published as: FR2839798A1; KR100448897B1; US20030216902A1; KR20030089843A

Abstract

Die Erfindung bezieht sich auf ein Chipentwicklungssystem und ein zugehöriges Chipentwicklungsverfahren. DOLLAR A Erfindungsgemäß umfasst das Chipentwicklungssystem Softwarekomponenten (210) zur Chipbetriebssimulierung sowie eine Funktionsbibliothek (220), die Chipfunktionen verarbeitet und von den Softwarekomponenten angesteuert wird. DOLLAR A Verwendung z. B. zur Entwicklung von Smartcards.

Description

Die Erfindung bezieht sich auf ein Chipentwicklungssystem und auf ein zugehöriges Verfahren zur Chipentwicklung.

Intelligente Karten in Form sogenannter Smartcards werden für immer mehr Anwendungen benutzt. Eine derartige Anwendung ist die Nutzung von Smartcards zur Bereitstellung der Fähigkeit zur Gutschrift-/Lastschriftzahlung für Massenüberweisungsnutzer. Smartcards haben außerdem Anwendungen auf vielen anderen Gebieten gefunden, wie Bezahl-Telefonen, Gesundheitswesen, Identifizierungs- und Zugriffsvorgänge im Bankverkehr, Bezahl-Fernsehen, Messinstrumente und im Verkauf. Im Einzelhandel werden Smartcards dazu verwendet, wiederholte Geschäfte zu unterstützen, wie z. B. der Gebrauch von Smartcards, um einen Rabatt auf Waren oder Punkte zu erhalten, die in Bargeld oder Waren eingetauscht werden können.

Smartcards beinhalten im allgemeinen einen oder mehrere integrierte Schaltkreise (ICs), die innerhalb des Kartenkörpers angeordnet sind, um Informationen zu empfangen und zu speichern. Die ICs können vom Nur-Lese-Typ sein oder Schreib/Lese-Fähigkeit haben. Wiederverwendbare Smartcards mit Schreib/Lese-Fähigkeit erlauben Benutzern einen Zugewinn an Zeit oder Wert zu Smartcards vom Bezahltyp, womit vermieden werden kann, dass Währung mitgeführt oder im Fall von Massentransfers jedes Mal exakt gewechselt werden muss. Die Smartcard kann zudem eine Schnittstelle beinhalten, die davon abhängt, ob die Smartcard vom Kontakttyp oder vom kontaktlosen Typ ist. Kontaktlose Karten können eine Antennenstruktur zur Kommunikation mit einer HF- Quelle aufweisen sowie einen Schaltungsaufbau, der dafür ausgelegt ist, Betriebsenergie aus einem HF-Signal der HF-Quelle zu gewinnen.

Bekannte Bausteine der Smartcard-Entwicklung umfassen typischerweise die Verwendung eines Emulationsbauteils. Im allgemeinen umfasst ein solches Emulationsbauteil Hardware mit einem Mikrocomputer- Entwicklungssystem (MDS) und einer Emulationsplatine. Typischerweise ist eine Anwendungsumgebung über eine Schnittstelle mit dem Emulationsbauteil verbunden. Das MDS entspricht einem CPU-Kern und funktioniert wie ein solcher. Ein zur Evaluierung bestimmter Chip kann in die Emulationsplatine eingesetzt werden. Die Anwendungsumgebung ist mit verschiedenen Softwareprogrammen implementiert, welche die Nutzung des Emulationsbauteils stützen und für das Testen eines betrachteten Chips benutzt werden können.

Fig. 1 veranschaulicht ein herkömmliches Smartcard-Entwicklungssystem, das sowohl Softwarekomponenten (SIW) 100 als auch Hardwarekomponenten (H/W) 110 beinhaltet. Die Softwarekomponenten 100 beinhalten einen Assembler 120, einen Compiler 130, einen Linker 140, einen Debugger 150 und einen Simulator 160. Die Hardwarekomponenten 110 umfassen ein MDS 170 und eine Emulationsplatine 180, in die ein ausgewählter Chip 190 eingesetzt werden kann. Die Emulationsplatine 180 ist über eine RS-232C-Schnittstellenkarte 202 mit einem Endgerät 200 verbunden. Das MDS 170 besteht aus einem Mikroprozessor, der den Betrieb des gewählten Chips 190 steuert bzw. verifiziert.

Da die Betriebsweise der meisten herkömmlichen Smartcards spezifisch festgelegt ist und durch Halbleiterfertigungsprozesse nicht modifiziert werden kann, die zum Entwickeln der Chips implementiert werden, die auf den Karten zum Einsatz kommen, können herkömmliche Entwicklungssysteme, die mit einer Kombination von Software- und Hardwarekomponenten, wie gezeigt, ausgelegt sind, die einmalige Programmierung und Prüfung in ausreichender Weise handhaben, die benötigt wird, um Smartcards betriebsmäßig zu aktivieren. Mit fortschreitender Verbesserung und Entwicklung der Smartcard-Technologie ist jedoch eine oftmalige Neuentwicklung und Herstellung der Hardwarekomponenten der herkömmlichen Entwicklungssysteme mit entsprechendem Kostenaufwand erforderlich.

Der Erfindung liegt als technisches Problem die Bereitstellung eines . Chipentwicklungssystems und eines zugehörigen Chipentwicklungsverfahren zugrunde, die eine gegenüber den erwähnten herkömmlichen Chipentwicklungssystemen und -verfahren verbesserte Chipentwicklungsfunktionalität aufweisen.

Die Erfindung löst dieses Problem durch die Bereitstellung eines Chipentwicklungssystems mit den Merkmalen des Anspruchs 1 und eines Chipentwicklungsverfahrens mit den Merkmalen des Anspruchs 9.

Vorteilhafte Weiterbildungen der Erfindung sind in den Unteransprüchen angegeben.

Eine vorteilhafte, nachfolgend beschriebene Ausführungsform der Erfindung sowie das zu deren besserem Verständnis oben erläuterte herkömmliche Smartcard-Entwicklungssystem sind in den Zeichnungen dargestellt, in denen zeigen:
Fig. 1 ein Blockdiagramm eines herkömmlichen Smartcard-Entwicklungssystems und
Fig. 2 ein Blockdiagramm eines erfindungsgemäßen Smartcard-Entwicklu ngssystems.
Fig. 2 veranschaulicht ein herkömmliches Smartcard-Entwicklungssystem mit einer Diagnose("Debugger")-Softwarekomponente 210 zur Simulation eines Betriebs einer Smartcard, einer Funktionsbibliothek 220, in der Smartcardfunktionen softwaremäßig verarbeitet werden, einem Bauelementtreiber 230 zur Ansteuerung der Funktionsbibliothek 220, einer seriellen I/O-Kommunikationsbibliothek 240 zur Bereitstellung eines Kommunikationsprotokollalgorithmus zwischen der Diagnosesoftware 210 und der Funktionsbibliothek 220 sowie einer Kartenadapterplatine 250 zur Unterstützung einer Kommunikation mit einem Endgerät 260, das die Smartcard handhabt.
Die Diagnosesoftware 210 umfasst einen Assembler 211, einen Compiler 213, einen Linker 214, einen Debugger 215 und einen Simulator 216 zum Ausführen von unter Verwendung der Diagnosesoftware 210 entwickeltem Programmcode. Die Diagnosesoftware 210 wird zur Compilierung und zum Austesten von Dokumenten der Funktionsbibliothek 220 benutzt.
Der Assembler 211 hat die Aufgabe, ein Assemblersprachenprogramm in binären Maschinencode zu übersetzen. Er macht hierzu wiederholten Gebrauch von Symbol- und Adresswerten von Datenelementen. Im Gegensatz zu einer höheren Sprache entspricht jedem Assemblersprachenbefehl ein Maschinenbefehl.
Der Compiler 213 kann als Computerprogramm realisiert sein, das Quellendokumente eines anderen Programms liest, um ein binäres Dokument zu erzeugen, das von einem Computer zur Ausführung benötigt wird. Die Quellendokumente beschreiben das Programm unter Verwendung einer Rechnersprache, wie C, C++, COBOL oder dergleichen. Das vom Compiler 213 erzeugte, binäre Dokument beinhaltet eine Serie binärer Maschinenbefehle für einen bestimmten Rechnertyp. Außerdem erzeugt der Compiler 213 Diagnosemeldungen, wenn er Fehler in den Quellendokumenten detektiert. Der Compiler 213 unterscheidet sich vom Assembler 211 dadurch, dass jede Eingabeanweisung im allgemeinen nicht einem einzelnen Maschinenbefehl oder einer festen Abfolge von Befehlen entspricht. Ein Compiler unterstützt typischerweise Eigenschaften wie automatische Variablenzuweisung, beliebige arithmetische Ausdrücke, Steuerungsstrukturen für "FOR" und "WHILE"-Schleifen oder dergleichen, variabler Umfang, Eingabe/Ausgabe-Operationen, Funktionen höherer Ordnung und Portabilität von Quellcode.
Ein Quellendokument kann Compiler-Anweisungen enthalten, welche die Einbeziehung anderer Quellendokumente veranlassen. Eine nicht gezeigte Kompilierungseinheit kann von einem einzigen Quellprogrammdokument, das einem Compiler zur Verfügung gestellt wird, zuzüglich aller direkt oder indirekt durch dieses Dokument einbezogener Quellprogrammdokumente gebildet sein. Ein binäres Dokument kann Maschinenbefehle von einer oder mehreren Kompilierungseinheiten umfassen, und eine Kompilierungseinheit kann von mehreren Quellendokumenten stammen. In manchen Fällen sind die Maschinenbefehle einer einzelnen Kompilierungseinheit in einem separaten Binärdokument gespeichert, das als Objektdokument bezeichnet wird. Objektdokumente werden dann durch den Linker 214 miteinander verknüpft, um ein endgültiges Binärdokument zu erzeugen.
Sobald ein Programm kompiliert und verbunden wurde, kann es ausgeführt und dann ausgetestet werden. Da es sein kann, dass durch Programmierer logische Fehler, sogenannte "bugs", verursacht werden, sollten Fehler unter Verwendung des Debuggers 215 detektiert und verstanden werden. Nach Korrektur jeglicher entdeckter Fehler und erneuter Kompilierung wird der Debugger 215 dazu verwendet, zu bestätigen, dass die Fehler eliminiert worden sind. Weitere Nutzungen des Debuggers 215 umfassen eine Inspektion ausführender Programme, um deren Betriebsweise zu verstehen, eine Überwachung der Speichernutzung, ein Instrumentalisieren und Testen von Programmen, eine Verifizierung der Fehlerfreiheit der Programmübersetzung durch den Compiler 213 und eine Verifizierung der Fehlerfreiheit des Betriebs anderer abhängiger Programme.
Die Funktionsbibliothek 220 beinhaltet einen Verschlüsselungskern 222, in dem Informationsdaten zur Verwendung mit einer Smartcard gespeichert werden können, einen Zufallszahlengenerator 224 zur Bereitstellung einer Zufallsverteilung für einen zur Benutzung einer Smartcard verwendeten Schlüssel sowie einen Zufallstaktgenerator 226 zur Erzeugung eines Taktes für die Synchronisation der Informationsdaten zur Verwendung mit einer Smartcard.
Der Verschlüsselungskern 222 kann eine Krypto-Bibliothek mit einem Algorithmus zur Verschlüsselung von Dokumenten oder Dokumentinformation beinhalten und einen symmetrischen oder asymmetrischen Schlüssel erzeugen. Dies umfasst die Erzeugung von Schlüsseln zur Verschlüsselung gemäß dem Datenverschlüsselungsstandard DES, dem RSA-Verschlüsselungsstandard, der Elliptikkurvenkryptologie (ECC) etc., wie sie dem Fachmann geläufig sind. Der Verschlüsselungskern 222 ist jedoch nicht auf die angegebenen Verschlüsselungstechniken beschränkt. Der Zufallszahlengenerator 224 und der Zufallstaktgenerator 226 können zufallsverteilt betrieben werden, um auf nicht vorhersagbare Weise Informationsdaten zu verschlüsseln.
In einer vorteilhaften Realisierung der Erfindung ersetzt die Funktionsbibliothek 220 im wesentlichen die Hardwarekomponenten des herkömmlichen MDS und die Emulationsplatine. Bei auftretenden Änderungen und Verbesserungen in der Smartcardtechnologie kann daher das erfindungsgemäße Entwicklungssystem bei Bedarf relativ einfach aktualisiert werden. Da außerdem eine Reihe von Prozessen eliminiert ist, die zum Anbringen und Entfernen einer Smartcard herkömmlicherweise benötigt werden, kann die Smartcardemulation in einer beschleunigten Weise erfolgen.
In vorteilhaften Realisierungen der Erfindung kann der Chipbetrieb unter Verwendung der Funktionsbibliothek 220 verifiziert werden. Insbesondere kann die Funktionsbibliothek 220 Chipfunktionen softwaremäßig verarbeiten. Dadurch ist es möglich, den Chipbetrieb ohne die Beschränkungen, wie sie mit den hardwarebasierten herkömmlichen Entwicklungssystemen verknüpft sind, frei und in einfacher Weise zu verifizieren und zu entwickeln. Dies schafft außerdem die Voraussetzung für eine Verringerung der zur Chipbetriebsentwicklung benötigten Zeitdauer.

Claims

1. Chipentwicklungssystem, gekennzeichnet durch

- Softwarekomponenten (210) zur Chipbetriebssimulation und

- eine Funktionsbibliothek (220), die Chipfunktionen verarbeitet und durch die Softwarekomponenten angesteuert wird.

2. Chipentwicklungssystem nach Anspruch 1, weiter dadurch gekennzeichnet, dass die Softwarekomponenten wenigstens einen Assembler (211), einen Compiler (213), einen Linker (214), einen Debugger (215) und einen Simulator (216) umfassen.

3. Chipentwicklungssystem nach Anspruch 1 oder 2, weiter dadurch gekennzeichnet, dass die Funktionsbibliothek einen Verschlüsselungskern (222) zum Speichern der Chipfunktionen, einen Zufallszahlengenerator (224) zur Zufallsverteilung eines Schlüssels sowie einen Zufallstaktgenerator (226) zur Erzeugung eines Synchronisationstaktes umfasst.

4. Chipentwicklungssystem nach einem der Ansprüche 1 bis 3, weiter dadurch gekennzeichnet, dass die Funktionsbibliothek eine Schnittstellenfunktionalität zur Unterstützung von Kommunikationsvorgängen mit einem Endgerät (260) umfasst.

5. Chipentwicklungssystem nach einem der Ansprüche 1 bis 4, weiter gekennzeichnet durch ein Endgerät (260), das über eine Schnittstelle mit dem Chipentwicklungssystem verbunden ist und zur Funktionshandhabung des Systems dient.

6. Chipentwicklungssystem nach einem der Ansprüche 1 bis 5, weiter gekennzeichnet durch eine Kommunikationsbibliothek (240), die einen Kommunikationsprotokollalgorithmus zur Unterstützung von Kommunikationsvorgängen zwischen einer Diagnosesoftwarekomponente und der Funktionsbibliothek bereitstellt.

7. Chipentwicklungssystem nach einem der Ansprüche 1 bis 6, weiter gekennzeichnet durch einen Bauelementtreiber (230) zur Ansteuerung der Funktionsbibliothek.

8. Chipentwicklungssystem nach einem der Ansprüche 1 bis 7, weiter dadurch gekennzeichnet, dass die Chipfunktionen als Softwarekomponenten realisiert sind.

9. Chipentwicklungsverfahren, gekennzeichnet durch folgende Schritte:

- Simulieren der Chipfunktionalität unter Verwendung von Softwarekomponenten und

- Verarbeiten von Chipfunktionen durch Softwarekomponenten.

10. Chipentwicklungsverfahren nach Anspruch 9, weiter dadurch gekennzeichnet, dass die Softwarekomponenten einen Assembler, einen Compiler, einen Linker, einen Debugger und/oder einen Simulator umfassen.