EP1250645A1 - Systeme de gestion de peripheriques dans un circuit integre - Google Patents

Systeme de gestion de peripheriques dans un circuit integre

Info

Publication number
EP1250645A1
EP1250645A1 EP01903978A EP01903978A EP1250645A1 EP 1250645 A1 EP1250645 A1 EP 1250645A1 EP 01903978 A EP01903978 A EP 01903978A EP 01903978 A EP01903978 A EP 01903978A EP 1250645 A1 EP1250645 A1 EP 1250645A1
Authority
EP
European Patent Office
Prior art keywords
software layer
hardware
management system
layer
integrated circuit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP01903978A
Other languages
German (de)
English (en)
Other versions
EP1250645B1 (fr
Inventor
Myriam Chabaud
Thierry Les Toits de Méjanes ALBARET
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
STMicroelectronics SA
Original Assignee
STMicroelectronics SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by STMicroelectronics SA filed Critical STMicroelectronics SA
Publication of EP1250645A1 publication Critical patent/EP1250645A1/fr
Application granted granted Critical
Publication of EP1250645B1 publication Critical patent/EP1250645B1/fr
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements

Definitions

  • the present invention relates to a device management system in an integrated circuit with microprocessor. It relates more particularly to applications of the smart card type.
  • An integrated circuit for a smart card type application commonly called microcircuit, or even electronic micromodule, comprises, in addition to a microprocessor, a certain number of other hardware resources, generally called peripherals, such as counters, circuits serial interface, random number generators, clock signals, etc.
  • peripherals such as counters, circuits serial interface, random number generators, clock signals, etc.
  • memories including a program memory ROM, reprogrammable memories to contain application data (EEPROM) or another working memory (RAM), and a peripheral access controller, which manages in particular the address and data buses.
  • Such an integrated circuit is usually delivered to a client, who is not necessarily the end user of the circuit, for which at least one application has been implemented in this integrated circuit according to its final destination.
  • the current trend is towards the implementation of several applications, one of which is activated by an external application, at a given time.
  • These applications can be of different types. They may for example consist of a smart card operating system (opera ting system), a cryptographic library, which may allow calculations or verification of signature, encryption, or even on-board test software, this list of applications is not exhaustive. These applications are implemented in the integrated circuit in the form of software processes in an application software layer. These processes are executed by the microprocessor of the integrated circuit.
  • a smart card operating system operating system
  • a cryptographic library which may allow calculations or verification of signature, encryption, or even on-board test software
  • the application software layer must call processes on peripherals, called hardware processes in the following (as opposed to software processes).
  • An object of the invention is to secure the device management system in an integrated circuit of smart card.
  • this intermediate software layer manages all the peripherals on behalf of the application software layer.
  • this call is managed by the intermediate software layer.
  • a software interrupt instruction is used, by which a function of the intermediate software layer is called.
  • the intermediate software layer When the intermediate software layer has completed the processing linked to the called function, it returns to the application software layer, by an interrupt return instruction.
  • the application software layer no longer has to know the hardware specificities of the product, such as the address of the table of vectors of hardware interrupts, the address of the peripherals. We thus create a barrier of security between the hardware resources of the integrated circuit and the application.
  • execution time of a particular hardware process on a peripheral can be quite long (for example, the programming of one or more words in EEPROM memory).
  • the intermediate software layer to immediately release the application software layer which has called a hardware process.
  • the intermediate software layer itself manages the devices in interrupt mode. This allows the application software layer to continue working and the intermediate software layer to process other hardware process calls, if necessary.
  • a device when a device has finished executing a hardware process, it emits a hardware interrupt, which stops the current execution in the microprocessor and returns it to the management of hardware interrupts in the intermediate software layer.
  • the intermediate software layer ensuring its security barrier function by performing the processing of the interruption corresponding to the hardware aspect proper, in particular the reading and writing registers to identify the source of the hardware interrupt, while the application software layer performs the rest of the processing of the interrupt, related to the application.
  • the invention relates to a device management system in a microprocessor integrated circuit, comprising an application software layer comprising at least one process requiring the execution of hardware processes on at least one peripheral of the integrated circuit, characterized in that that it comprises an intermediate software layer for managing the hardware processes called by a process of the application software layer.
  • FIG. 1 schematically represents the device management system according to the invention. invention
  • FIG. 2 illustrates an example of processing of a function call of the application software layer by the intermediate software layer
  • FIG. 3 illustrates an example of implementation of the invention using macro-instructions for ensure calls between the application software layer and the intermediate software layer.
  • the device management system generally applies to an integrated circuit CI comprising a microprocessor ⁇ p and peripherals P. It applies more particularly to integrated circuits for applications of the smart card type.
  • the peripherals of such integrated circuits usually include at least one program memory ROM containing the software processes of the application layer APPLI and the program corresponding to the intermediate software layer LI according to the invention.
  • the processes or programs of the application layers APPLI and intermediate LI are executed by the microprocessor. This is why we have chosen to represent them in FIG. 1, inside a logic box representing the microprocessor ⁇ p.
  • the microprocessor executes a given process or program from the application layer APPLI. In practice, it can be interrupted in this execution by a hardware or software interruption.
  • the microprocessor when the processing of the APPLI application layer carried out by the ⁇ p microprocessor requires the execution of a hardware process in a peripheral, it uses the DIL software interrupt to call a corresponding function of the LI layer.
  • This DIL software interrupt start instruction is executed by the microprocessor ⁇ p.
  • the processing of this software interruption includes the launch of the corresponding PMI hardware process on the device concerned PI.
  • the result of this hardware process R (PM1) which can simply be a flag to signify that the process is carried out, is returned to the application layer with the software interrupt return instruction, RIL. More precisely, and as shown in FIG. 2, the microprocessor executes (1) a PLI process of the application software layer. In this Fold process, it needs to run a PMI hardware process.
  • the PI device concerned emits (6) a hardware interrupt IT, which stops (7) the processing in progress in the microprocessor ⁇ p, in the example a processing of the application software layer ( it could be a processing of another function LI), to send it back to the management of the interrupt (8), by the intermediate software layer LI.
  • This management includes reading and writing the table of hardware interrupt vectors, making it possible to identify the source of the hardware interrupt, PI in the example, then the return (9) of this interruption to the application software layer APPLI, to allow the treatment (10) of the interruption by the calling software process.
  • This reference is made by a DIL software interrupt sent this time by the intermediate software layer LI.
  • the concerned process PLI of the application software layer has completed its processing of the interrupt, it releases (11) the intermediate software layer LI, which in turn releases (12) the peripheral PI.
  • the microprocessor can then resume (13) the processing in progress, where it had been stopped.
  • step (4) of the figure 2 in which the intermediate software layer LI releases the application software layer includes the return of corresponding information, signifying that the device is unavailable.
  • the possibilities offered by the software interrupt mode of the microprocessor ⁇ p are used to create a security barrier between the application software layer and the peripherals.
  • the application software layer no longer needs to know the addresses of the peripherals, of the table of hardware interrupt vectors and of other information which is information which is particularly important from the security point of view. It must only implement the software interrupt mode, by which mode it transmits its function calls on the intermediate software layer that manages devices in its place.
  • the program compilers in source code generally do not integrate the instruction assembler of departure in software interruption DIL and 1 instruction assembler of return associated RIL interrupt.
  • the intermediate software layer LI contains macro-instructions for each function call.
  • the application software layer must therefore only call a macro instruction of the intermediate software layer LI.
  • This macro-instruction includes the transfer of the parameters linked to the LI function to be executed and the execution of the DIL assembler instruction.
  • it is the intermediate software layer LI which emits the software interruption DIL.
  • the processing of this DIL interrupt by the intermediate software layer LI in turn refers to a function LI.
  • the application software layer and the functions of the intermediate software layer LI are they developed in advanced language, typically in C language.
  • a corresponding block diagram is shown in FIG. 3. The invention which has just been described makes it possible to create a security barrier between the application layer and the peripherals of the integrated circuit.
  • the communication between these two layers is optimized, by allowing the application concerned to carry out the processing of the hardware interrupt itself. linked to the application, while allowing the intermediate software layer LI to act as a barrier, leaving it with all the aspects of the processing linked to the hardware, in particular, identifying the source of the interruption.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Microcomputers (AREA)
  • Storage Device Security (AREA)
  • Semiconductor Integrated Circuits (AREA)

Abstract

Dans un circuit intégré à microprocesseur mu P pour carte à puce comprenant un couche logicielle d'application APPLI, un système de gestion de périphériques comprend une couche logicielle intermiédiaire LI pour gérer les processus matériels sur des périphériques du circuit intégré, appelés par un ou des processus de la couche logicielle d'application.

Description

SYSTEME DE GESTION DE PERIPHERIQUES DANS UN CIRCUIT
INTEGRE
La présente invention concerne un système de gestion de périphériques dans un circuit intégré à microprocesseur. Elle concerne plus particulièrement les applications du type carte à puce. Un circuit intégré pour une application de type carte à puce, appelé couramment microcircuit, ou encore micromodule électronique, comprend, en plus d'un microprocesseur, un certain nombre d'autres ressources matérielles, appelées généralement périphériques, tel que des compteurs, des circuits d'interface série, des générateurs de nombre aléatoires, de signaux d'horloge... On a habituellement, associées à ces périphériques, des mémoires dont une mémoire programme ROM, des mémoires reprogrammables pour contenir des données d'application (EEPROM) ou encore une mémoire de travail (RAM), et un contrôleur d'accès aux périphériques, qui gère notamment les bus d'adresse et de données.
Un tel circuit intégré est habituellement livré à un client, qui n'est pas nécessairement l'utilisateur final du circuit, pour lequel on a implémenté dans ce circuit intégré selon sa destination finale, au moins une application. La tendance actuelle serait à 1 ' implémentation de plusieurs applications, dont une est activée par une application externe, à un moment donné .
Ces applications peuvent être de différents types. Elles peuvent par exemple consister en un système d'exploitation de carte à puce { opera ting system) , une librairie cryptographique, qui pourra permettre des calculs ou vérification de signature, du chiffrement, ou encore un logiciel de test embarqué, cette liste d'applications n'étant pas exhaustive. Ces applications sont implémentées dans le circuit intégré sous forme de processus logiciels dans une couche logicielle d'application. Ces processus sont exécutés par le microprocesseur du circuit intégré.
Pour réaliser certains traitements d'un processus logiciel donné, la couche logicielle d'application doit appeler des processus sur des périphériques, appelées processus matériels dans la suite (par opposition aux processus logiciels).
Habituellement, elle le fait directement, c'est à dire qu'elle gère directement les périphériques du circuit intégré. Le fabricant du circuit intégré fournit à cet effet toutes les informations nécessaires, dont les adresses des différents périphériques du circuit intégré, les adresses en mémoire programme ROM des tables des vecteurs d'interruption matérielle,.... Ces informations sont spécifiques du circuit intégré. Elles permettent à la couche logicielle d'application d'appeler directement un processus matériel sur un périphérique. Elles permettent aussi à la couche logicielle de gérer ces périphériques en mode interruption, ce qui lui permet de continuer à travailler tant que le périphérique n'a pas terminé d'exécuter un processus matériel demandé
(par exemple, la programmation d'une page mémoire EEPROM). Dans ce cas, c'est la couche logicielle d'application qui gère directement les interruptions matérielles émises par les périphériques, ce qui implique qu'elle doit lire et écrire des registres et accéder à la table des vecteurs d'interruption matérielle, en mémoire programme ROM, pour identifier une source d'interruption et engager les actions nécessaires.
Or, on cherche à améliorer toujours et encore la sécurité des cartes à puce, pour empêcher toute utilisation de ces cartes à des fins frauduleuses.
Un objet de l'invention est de sécuriser le système de gestion des périphériques dans un circuit intégré de carte à puce.
Une solution à ce problème technique a été trouvée dans l'invention, dans l'utilisation d'une couche logicielle intermédiaire agissant comme une barrière de sécurité entre la couche logicielle d'application et les ressources matérielles du circuit intégré, c'est à dire le microprocesseur et les périphériques.
Selon l'invention, cette couche logicielle intermédiaire assure la gestion de tous les périphériques pour le compte de la couche logicielle d'application. Ainsi, lorsqu'un processus de la couche logicielle d'application appelle un processus matériel sur un périphérique, cet appel est géré par la couche logicielle intermédiaire. Pour cela, on utilise une instruction d'interruption logicielle, par laquelle on appelle une fonction de la couche logicielle intermédiaire .
Lorsque la couche logicielle intermédiaire a terminé le traitement lié à la fonction appelée, elle fait un retour à la couche logicielle d'application, par une instruction de retour d'interruption. Par ce mécanisme, la couche logicielle d'application n'a plus à connaître les spécificités matérielles du produit, comme l'adresse de la table des vecteurs d'interruptions matérielles, l'adresse des périphériques .... On crée ainsi une barrière de sécurité entre les ressources matérielles du circuit intégré et 1 ' application.
Par ailleurs, le temps d'exécution d'un processus matériel particulier sur un périphérique peut-être assez long (par exemple, la programmation d'un ou plusieurs mots en mémoire EEPROM) .
De préférence, pour améliorer les performances de la carte, on prévoit que la couche logicielle intermédiaire libère tout de suite la couche logicielle d'application qui a appelé un processus matériel. Dans ce cas, la couche logicielle intermédiaire elle-même gère les périphériques en mode interruption. Ceci permet à la couche logicielle d'application de continuer à travailler et à la couche logicielle intermédiaire de traiter d'autres appels de processus matériels, le cas échéant.
Dans ce cas, lorsqu'un périphérique a terminé l'exécution d'un processus matériel, il émet une interruption matérielle, qui stoppe l'exécution en cours dans le microprocesseur et le renvoie à la gestion des interruptions matérielles dans la couche logicielle intermédiaire.
Selon l'invention, on prévoit alors que le traitement de l'interruption matérielle dans la couche logicielle intermédiaire comprend l'interruption de la couche logicielle d'application pour permettre à cette dernière de terminer le processus correspondant. Ainsi, selon l'invention, l'on a un partage du traitement de l'interruption matérielle, la couche logicielle intermédiaire assurant sa fonction de barrière de sécurité en effectuant le traitement de l'interruption correspondant à l'aspect matériel proprement dit, notamment la lecture et l'écriture de registres pour identifier la source de l'interruption matérielle, tandis que la couche logicielle d'application assure le reste du traitement de l'interruption, lié à l'application.
Ainsi, l'invention concerne un système de gestion de périphériques dans un circuit intégré à microprocesseur, comprenant une couche logicielle d'application comprenant au moins un processus nécessitant l'exécution de processus matériels sur au moins un périphérique du circuit intégré, caractérisé en ce qu'il comprend une couche logicielle intermédiaire pour gérer les processus matériels appelés par un processus de la couche logicielle d'application.
D'autres caractéristiques et avantages de l'invention sont indiqués dans la description suivante faite à titre indicatif et non limitatif de l'invention, et en référence aux dessins annexés dans lesquels : la figure 1 représente schématiquement le système de gestion des périphériques selon l'invention ; la figure 2 illustre un exemple de traitement d'un appel de fonction de la couche logicielle d'application par la couche logicielle intermédiaire; et la figure 3 illustre un exemple de mise en œuvre de l'invention utilisant des macro-instructions pour assurer les appels entre la couche logicielle d'application et la couche logicielle intermédiaire.
Le système de gestion de périphériques selon l'invention s'applique de manière générale à un circuit intégré CI comprenant un microprocesseur μp et des périphériques P. Il s'applique plus particulièrement à des circuits intégrés pour des applications de type carte à puce. Les périphériques de tels circuits intégrés comprennent habituellement au moins une mémoire programme ROM contenant les processus logiciels de la couche d'application APPLI et le programme correspondant à la couche logicielle intermédiaire LI selon l'invention. Les processus ou programmes des couches d'application APPLI et intermédiaire LI sont exécutés par le microprocesseur. C'est pourquoi on a choisi de les représenter sur la figure 1, à l'intérieur d'une boite logique représentant le microprocesseur μp . A un moment donné, le microprocesseur exécute un processus ou programme donné de la couche application APPLI. Il peut être en pratique interrompu dans cette exécution par une interruption matérielle ou logicielle.
Dans l'invention, lorsque le traitement de la couche d'application APPLI effectué par le microprocesseur μp nécessite l'exécution d'un processus matériel dans un périphérique, il utilise l'interruption logicielle DIL pour appeler une fonction correspondante de la couche LI . Cette instruction de départ en interruption logicielle DIL est exécutée par le microprocesseur μp. Le traitement de cette interruption logicielle comprend le lancement du processus matériel correspondant PMI sur le périphérique concerné PI. Le résultat de ce processus matériel R(PM1), qui peut tout simplement être un indicateur pour signifier que le processus est effectué, est retourné à la couche d'application avec l'instruction de retour d'interruption logicielle, RIL. Plus précisément, et comme représenté sur la figure 2, le microprocesseur exécute (1) un processus PLI de la couche logicielle d'application. Dans ce processus Pli, il a besoin d'exécuter un processus matériel PMI. II émet donc une interruption logicielle DIL (2) pour appeler une fonction correspondante F(PM1) de la couche logicielle intermédiaire. Cette interruption logicielle est traitée par la couche logicielle intermédiaire LI, qui appelle (3) le processus matériel PMI correspondant sur le périphérique PI concerné, en mode interruption. La couche logicielle intermédiaire LI rend alors la main (4) à la couche logicielle d'application qui peut continuer (5) d'autres traitements. Notamment, elle peut appeler d'autres fonctions différentes de la couche logicielle intermédiaire, pour lancer d'autres processus matériels.
Lorsque le processus matériel PMI est terminé, le périphérique PI concerné émet (6) une interruption matérielle IT, ce qui stoppe (7) le traitement en cours dans le microprocesseur μp, dans l'exemple un traitement de la couche logicielle d'application (ce pourrait être un traitement d'une autre fonction LI), pour le renvoyer vers la gestion de l'interruption (8), par la couche logicielle intermédiaire LI . Cette gestion comprend la lecture et 1 ' écriture de la table des vecteurs d'interruption matérielle, permettant d'identifier la source de l'interruption matérielle, PI dans l'exemple, puis le renvoi (9) de cette interruption vers la couche logicielle d'application APPLI, pour permettre le traitement (10) de l'interruption par le processus logiciel appelant. Ce renvoi se fait par une interruption logicielle DIL émise cette fois par la couche logicielle intermédiaire LI . Lorsque le processus concerné PLI de la couche logicielle d'application a terminé son traitement de l'interruption, il libère (11) la couche logicielle intermédiaire LI, qui a son tour, libère (12) le périphérique PI.
Le microprocesseur peut alors reprendre (13) le traitement en cours, là où il avait été arrêté.
Les considérations liées au mode interruption ne vont pas être rappelées en détail. Il s'agit d'un mode de communication avec des périphériques habituel, bien connu de l'homme du métier. On pourra simplement noter que dans le système de gestion selon l'invention qui utilise l'instruction assembleur de départ en interruption logicielle DIL, on associe en pratique un domaine à chacun des processus PLI de la couche logicielle d'application et un domaine à la couche logicielle intermédiaire LI, en sorte que l'on a un vecteur d'interruption logicielle associé à chacun de ces domaines. Ainsi, lorsqu'une interruption logicielle DIL est émise, la table des vecteurs d'interruption permet d'identifier l'émetteur et de lancer le traitement d'interruption correspondant. Cette table se trouve dans la couche logicielle intermédiaire. Par ailleurs, si un périphérique sur laquelle la couche logicielle intermédiaire LI doit lancer un processus matériel est occupé, l'étape (4) de la figure 2 dans laquelle _ a couche logicielle intermédiaire LI libère la couche logicielle d'application comprend le renvoi d'une information correspondante, lui signifiant que le périphérique est indisponible. On peut aussi prévoir que pour chaque domaine, on définit les fonctions de la couche logicielle intermédiaire LI qui peuvent être appelées. Dans ce cas, si la fonction de la couche logicielle intermédiaire LI appelée par un processus donné ne fait pas partie de la définition du domaine associé à ce processus, on prévoit que la couche logicielle intermédiaire LI renvoie avec l'instruction de retour d'interruption RIL une information indiquant que la fonction n'est pas accessible . Si au contraire, le périphérique est disponible, il libère la couche logicielle d'application en lui renvoyant une information correspondante, lui indiquant que sa demande est en cours de traitement dans le périphérique concerné. Dans l'invention, on utilise donc les possibilités offertes par le mode d'interruption logicielle du microprocesseur μp pour créer une barrière de sécurité entre la couche logicielle d'application et les périphériques. En particulier, la couche logicielle d'application n'a plus besoin de connaître les adresses des périphériques, de la tables des vecteurs d'interruption matérielle et autres informations qui sont des informations particulièrement importantes sur le plan sécuritaire. Elle doit seulement mettre en oeuvre le mode d'interruption logicielle, mode par lequel elle transmet ses appels de fonctions sur la couche logicielle intermédiaire qui gère les périphériques à sa place.
En pratique, dans le cas des circuits intégrés pour des applications de type carte à puce, les compilateurs de programme en code source (assembleur) n'intègrent généralement pas l'instruction assembleur de départ en interruption logicielle DIL et 1 ' instruction assembleur de retour d'interruption RIL associée.
De préférence, pour éviter aux développeurs des processus de la couche d'application et aux développeurs de la couche logicielle intermédiaire LI d'avoir à programmer en assembleur, on prévoit selon l'invention que la couche logicielle intermédiaire LI contient des macro-instructions pour chaque appel de fonction.
La couche logicielle d'application doit donc seulement appeler une macro-instruction de la couche logicielle intermédiaire LI . Cette macro-instruction comprend le transfert des paramètres liés à la fonction LI à exécuter et l'exécution de l'instruction assembleur DIL. Par ce mécanisme, c'est la couche logicielle intermédiaire LI qui émet 1 ' interruption logicielle DIL. Le traitement de cette interruption DIL par la couche logicielle intermédiaire LI renvoie à son tour vers une fonction LI . De cette façon, seule la partie de la couche logicielle intermédiaire LI qui contient les macro-instructions doit être développée en langage assembleur. La couche logicielle d'application et les fonctions de la couche logicielle intermédiaire LI sont elles développées en langage évolué, typiquement en langage C. Un synoptique correspondant est représenté sur la figure 3. L'invention qui vient d'être décrite permet de créer une barrière de sécurité entre la couche d'application et les périphériques du circuit intégré.
En outre, par le partage du traitement des interruptions matérielles entre les couches logicielles intermédiaire et d'application, on optimise la communication entre ces deux couches, en permettant à l'application concernée d'effectuer elle-même le traitement de l'interruption matérielle lié à l'application, tout en laissant la couche logicielle intermédiaire LI assurer son rôle de barrière, en lui laissant tous les aspects du traitement liés au matériel, notamment, l'identification de la source de 1 ' interruption .

Claims

REVENDICATIONS
1. Système de gestion de périphériques dans un circuit intégré a microprocesseur (μp) , comprenant une couche logicielle d'application (APPLI) comprenant au moins un processus (Pli) nécessitant l'exécution de processus matériels sur au moins un périphérique (PI) du circuit intègre, caractérise en ce qu'il comprend une couche logicielle intermédiaire (LI) pour gérer les processus matériels appelés par un processus de la couche logicielle d'application.
2. Système de gestion de périphériques selon la revendication 1, caractérise en ce que la couche logicielle d'application (APPLI) appelle une fonction (F(PM1)) de la couche logicielle intermédiaire (LI) correspondant au processus matériel (PMI) a exécuter.
3. Système de gestion de périphériques selon la revendication 2, caractérise en ce que cet appel de fonction (F(PM1)) est effectue par l'émission par la couche logicielle d'application (APPLI) d'une interruption logicielle (DIL) .
. Système de gestion de périphériques selon la revendication 2, caractérise en ce que cet appel de fonction (F(PM1)) est effectue par l'appel par la couche logicielle d'application (APPLI) d'une macroinstruction de la couche logicielle intermédiaire (LI), ladite macro-instruction comprenant l'émission par la couche logicielle intermédiaire (LI) d'une interruption lcgicielle (DIL) par laquelle ladite fonction (F(PM1)) est appelée.
5. Système de gestion de périphériques selon la revendication 3 ou 4, caractérisé en ce que le traitement de l'interruption logicielle (DIL) par la couche logicielle intermédiaire (LI) comprend la vérification de la disponibilité de la fonction appelée pour le processus appelant de la couche logicielle d'application.
6. Système de gestion de périphériques selon l'une quelconque des revendications 3 à 5, caractérisé en ce que la couche intermédiaire (LI) gère les périphériques en mode interruption.
7. Système de gestion de périphériques selon la revendication 6, caractérisé en ce que le traitement des interruptions matérielles (IT) des périphériques est effectué par la couche logicielle intermédiaire
(LI), le traitement d'une interruption matérielle
(IT) comprenant l'interruption logicielle (DIL) de la couche logicielle d'application (APPLI) pour permettre un traitement correspondant à ladite interruption matérielle dans cette couche, le périphérique étant libéré après la fin des traitements des dites interruptions matérielle et logicielle .
8. Carte à puce comprenant un circuit intégré muni d'un système de gestion de périphériques selon l'une quelconque des revendications précédentes.
EP01903978A 2000-01-27 2001-01-26 Systeme de gestion de peripheriques dans un circuit integre Expired - Lifetime EP1250645B1 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0001062 2000-01-27
FR0001062A FR2804525A1 (fr) 2000-01-27 2000-01-27 Systeme de gestion de peripheriques dans un circuit integre
PCT/FR2001/000258 WO2001055849A1 (fr) 2000-01-27 2001-01-26 Systeme de gestion de peripheriques dans un circuit integre

Publications (2)

Publication Number Publication Date
EP1250645A1 true EP1250645A1 (fr) 2002-10-23
EP1250645B1 EP1250645B1 (fr) 2003-09-17

Family

ID=8846382

Family Applications (1)

Application Number Title Priority Date Filing Date
EP01903978A Expired - Lifetime EP1250645B1 (fr) 2000-01-27 2001-01-26 Systeme de gestion de peripheriques dans un circuit integre

Country Status (6)

Country Link
US (1) US7398340B2 (fr)
EP (1) EP1250645B1 (fr)
JP (1) JP2003521064A (fr)
DE (1) DE60100792T2 (fr)
FR (1) FR2804525A1 (fr)
WO (1) WO2001055849A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1768028A1 (fr) * 2005-09-22 2007-03-28 STMicroelectronics (Research & Development) Limited Périphériques d'adressage dans un circuit intégré

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2212574C (fr) * 1995-02-13 2010-02-02 Electronic Publishing Resources, Inc. Systemes et procedes de gestion securisee de transactions et de protection electronique des droits
US6179489B1 (en) * 1997-04-04 2001-01-30 Texas Instruments Incorporated Devices, methods, systems and software products for coordination of computer main microprocessor and second microprocessor coupled thereto
US5754762A (en) * 1997-01-13 1998-05-19 Kuo; Chih-Cheng Secure multiple application IC card using interrupt instruction issued by operating system or application program to control operation flag that determines the operational mode of bi-modal CPU
US6105119A (en) * 1997-04-04 2000-08-15 Texas Instruments Incorporated Data transfer circuitry, DSP wrapper circuitry and improved processor devices, methods and systems
US6298370B1 (en) * 1997-04-04 2001-10-02 Texas Instruments Incorporated Computer operating process allocating tasks between first and second processors at run time based upon current processor load

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO0155849A1 *

Also Published As

Publication number Publication date
US20050021991A1 (en) 2005-01-27
DE60100792T2 (de) 2004-07-15
US7398340B2 (en) 2008-07-08
FR2804525A1 (fr) 2001-08-03
JP2003521064A (ja) 2003-07-08
WO2001055849A1 (fr) 2001-08-02
EP1250645B1 (fr) 2003-09-17
DE60100792D1 (de) 2003-10-23

Similar Documents

Publication Publication Date Title
AU2020202180B2 (en) Memory allocation techniques at partially-offloaded virtualization managers
EP0733245B1 (fr) Carte a memoire et procede de fonctionnement
US10318737B2 (en) Secure booting of virtualization managers
AU2017290267B2 (en) Performance variability reduction using an opportunistic hypervisor
US6220510B1 (en) Multi-application IC card with delegation feature
EP2466470B1 (fr) Module matériel de sécurité et procédé de traitement dans un tel module
EP2480969A1 (fr) Systeme et procede de gestion de l'execution entrelacee de fils d'instructions
FR3103585A1 (fr) Procédé de gestion de la configuration d’accès à des périphériques et à leurs ressources associées d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
FR2808359A1 (fr) Carte a puce multi-applicatives
EP4187393A1 (fr) Gestion dynamique d'un pare-feu de mémoire
FR3103584A1 (fr) Procédé de gestion du débogage d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
EP1158405A1 (fr) Système et méthode de gestion d'une architecture multi-ressources
EP2124153A1 (fr) Procédés et dispositif de mise en oeuvre de périphériques multifonction avec un gestionnaire de périphérique standard unique
EP1250645B1 (fr) Systeme de gestion de peripheriques dans un circuit integre
FR3057081B1 (fr) Processeur comprenant une pluralite de coeurs de calcul
CN110852139A (zh) 生物特征识别方法、装置、设备以及存储介质
FR2674647A1 (fr) Appareil formant chequier electronique pour transactions financieres et procede d'utilisation d'un tel appareil.
WO2000051087A1 (fr) Dispositif d'acces securise a des applications d'une carte a puce
WO2002008897A1 (fr) Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant
US20240036868A1 (en) Schedulable Asynchronous Methods with Semi-Reactive Completion Stages
EP3244340A1 (fr) Procede pour executer une application de façon securisee
FR2829847A1 (fr) Procede de controle d'acces a des ressources partagees dans un systeme embarque et systeme embarque pour la mise en oeuvre d'un tel procede
EP1235140A1 (fr) Procédé de gestion d'instructions de branchement au sein d'un processeur
FR2721468A1 (fr) Procédé de partage de ressources physiques et dispositif d'interface pour la mise en Óoeuvre du procédé.

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20020718

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: ALBARET, THIERRY

Inventor name: CHABAUD, MYRIAM

GRAH Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOS IGRA

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): DE FR GB IT

REG Reference to a national code

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

GBT Gb: translation of ep patent filed (gb section 77(6)(a)/1977)
REF Corresponds to:

Ref document number: 60100792

Country of ref document: DE

Date of ref document: 20031023

Kind code of ref document: P

REG Reference to a national code

Ref country code: IE

Ref legal event code: FG4D

Free format text: FRENCH

REG Reference to a national code

Ref country code: IE

Ref legal event code: FD4D

PLBE No opposition filed within time limit

Free format text: ORIGINAL CODE: 0009261

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: NO OPPOSITION FILED WITHIN TIME LIMIT

26N No opposition filed

Effective date: 20040618

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: GB

Payment date: 20101230

Year of fee payment: 11

PGFP Annual fee paid to national office [announced via postgrant information from national office to epo]

Ref country code: FR

Payment date: 20110216

Year of fee payment: 11

Ref country code: IT

Payment date: 20101228

Year of fee payment: 11

Ref country code: DE

Payment date: 20110103

Year of fee payment: 11

GBPC Gb: european patent ceased through non-payment of renewal fee

Effective date: 20120126

REG Reference to a national code

Ref country code: FR

Ref legal event code: ST

Effective date: 20120928

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: GB

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20120126

Ref country code: DE

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20120801

REG Reference to a national code

Ref country code: DE

Ref legal event code: R119

Ref document number: 60100792

Country of ref document: DE

Effective date: 20120801

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: IT

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20120126

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: FR

Free format text: LAPSE BECAUSE OF NON-PAYMENT OF DUE FEES

Effective date: 20120131