Brevet FR3134907A1 — publié le 20231027

Le procédé de surveillance d’une exécution d’une portion de code programme sélectionnée (Rst) et enregistrée dans une plage d’adresses mémoires (AddRst) entre une adresse de début (s) et une adresse de fin (e), comprend : - un démarrage d’un chronométrage (CNT) lorsqu’un compteur programme (PC) pointe l’adresse de début de ladite portion de code sélectionnée (s{Rst}) ; - une comparaison (CMP) des valeurs courantes du compteur programme (PC) avec un jeu d’adresses cibles spécifiques à ladite portion de code sélectionnée (TRGT{Rst}) comportant l’adresse de fin de ladite portion de code sélectionnée (e{Rst}) ; - un arrêt du chronométrage (CNT) lorsque le compteur programme (PC) pointe l’adresse de fin de ladite portion de code sélectionnée (e{Rst}) ; - une génération d’un signal d’erreur (Err) si la durée du chronométrage est en dehors d’une gamme de durées nominale (NmnlRng) spécifique à ladite portion de code sélectionnée (Rst). Figure pour l’abrégé : Fig 1 Procédé de surveillance d’une exécution d’une portion de code programme et système sur puce correspondant Des modes de réalisation et de mise en œuvre concernent les techniques de surveillance de l’exécution d’un code programme, par exemple une exécution d’un code contenu dans une plage d’adresse mémoire par une unité de traitement d’un système sur puce. Les techniques de surveillance de l’exécution d’un programme peuvent avoir une vocation de sécurité, afin de détecter des tentatives de violation de secrets, pouvant typiquement employer des techniques d’injection de fautes. Lorsqu’est effectuée une injection de faute dans un système, des instructions sont modifiées ou ne sont pas exécutées mais l’unité de traitement continue d’exécuter les instructions suivantes du code. Cela mène à un fonctionnement non-contrôlé, et, dans certaines conditions, permet d’accéder à des informations sensibles ou secrètes. En particulier, ces conditions peuvent être juste après le démarrage, lorsque le code n’est pas complètement initialisé et que ne sont pas mises en place les protections du système d’exploitation (telles que les mécanismes de gestion des droits accès en mémoire) ; ou lors d’une opération critique, par exemple une opération ayant un niveau de droit d’accès maximal, telles que des opérations d’ordonnancement des droits d’accès ou de changement de contexte d’exécution (par exemple entre des contextes sécurisé et non-sécurisé). Les techniques de surveillance de l’exécution d’un programme peuvent aussi avoir une vocation de sûreté, autrement dit de fiabilité, afin de détecter un dysfonctionnement dans l’exécution du programme. Classiquement, des règles de codage sont mises en place dans la conception du programme afin d’effectuer des vérifications à des étapes stratégiques. Les techniques de surveillance classiques, telles que le codage d’un contrôle de flux (usuellement « flow control » en anglais), les duplications de fonctions d’appels, les actions de vérifications décorrélées de fonctions, ou encore les introductions de boucles aléatoires pour compliquer la reproduction des injections de fautes, présentent toute l’inconvénient d’être très intrusives dans le développement du code programme, ne sont pas applicables en début de démarrage, et introduisent des latences dans l’exécution des sections critiques du programme. Par ailleurs, certaines de ces techniques peuvent être parées par des injections de fautes dans des parties inattendues du programme et par des techniques d’injections de fautes multiples (qui n’existent éventuellement qu’en théorie mais qui pourraient être mises en pratique). Ainsi il existe un besoin, sur le plan de la sécurité et sur le plan de la sûreté, de proposer des techniques de surveillance de l’exécution d’un code programme (ou au moins d’une partie sélectionnée du code), qui ne sont pas ou peu contraignantes sur le développement du code programme surveillé, qui n’introduisent pas ou peu de latence, qui sont applicables en début de démarrage, et qui ne permettent pas ou peu de parade à leurs actions. Selon un aspect, il est proposé à cet égard un procédé de surveillance, mis en œuvre par une unité de surveillance, d’une exécution d’une portion de code programme sélectionnée et enregistrée dans une plage d’adresses mémoires entre une adresse de début et une adresse de fin, mise en œuvre par une unité de traitement utilisant un compteur programme pointant l’adresse d’une instruction exécutée par l’unité de traitement (usuellement nommé « program counter » en anglais). Le procédé de surveillance comprend : - un démarrage d’un chronométrage lorsque le compteur programme pointe l’adresse de début de ladite portion de code sélectionnée ; - une comparaison des valeurs courantes du compteur programme avec un jeu d’adresses cibles spécifiques à ladite portion de code sélectionnée comportant l’adresse de fin de ladite portion de code sélectionnée ; - un arrêt du chronométrage lorsque le compteur programme pointe l’adresse de fin de ladite portion de code sélectionnée ; - une génération d’un signal d’erreur si la durée du chronométrage est en dehors d’une gamme de durées nominale spécifique à ladite portion de code sélectionnée. Le chronométrage correspond par exemple en pratique à un comptage du nombre de cycles d’un signal d’horloge entre l’exécution de l’adresse de début et l’adresse de fin. Le signal d’horloge peut par exemple, dans un cas simple, être le signal d’horloge cadençant l’exécution par l’unité de traitement. En chronométrant le nombre de cycles, il est possible de contrôler le nombre d’instructions exécutées. En effet, chaque instruction coûte un certain nombre de cycle qui peut être défini pour chaque architecture de l’unité de traitement, et par exemple aussi pour l’architecture de périphériques de l’unité de traitement au sein d’un système sur puce. Ainsi, la gamme de durées nominale spécifique à ladite portion de code sélectionnée correspond à une exécution réussie, c’est-à-dire sans dysfonctionnement ni fonctionnement non-contrôlé, des instructions associées à cette portion de code. En outre, l’unité de surveillance n’utilise qu’une lecture du compteur programme et la connaissance de la gamme de durées nominale spécifique à la portion de code sélectionnée, et agit ainsi de manière indépendante de l’exécution du code. En conséquence, le procédé selon cet aspect est parfaitement adapté, en particulier, pour une application en début de démarrage, avant l’initialisation complète du code programme et des protection logicielles correspondantes. En outre, la mise en œuvre du procédé selon cet aspect n’engendre aucune contrainte sur l’écriture du code programme surveillé, et n’introduit pas de latence dans l’exécution du code programme. L’unité de surveillance peut avantageusement être configurée de façon matérielle pour mettre en œuvre la surveillance, et donc d’une manière quasiment impossible à corrompre ou à modifier. Selon un mode de mise en œuvre, ladite portion de code sélectionnée comporte au moins une fonction d’appel de respectivement au moins une deuxième portion de code programme enregistrée dans une deuxième plage d’adresses mémoires entre une deuxième adresse de début et une deuxième adresse de fin, et le jeu d’adresses cibles spécifiques à ladite portion de code sélectionnée comporte ladite au moins une deuxième adresse de début, le procédé de surveillance comprenant en outre une procédure d’intégration d’appel lorsque le compteur programme pointe ladite deuxième adresse de début, la procédure d’intégration d’appel comprenant : -- une suspension du chronométrage ; -- une mémorisation de la valeur du chronométrage suspendu ; et -- une reprise du chronométrage suspendu, à partir de la valeur enregistrée, lorsque le compteur programme pointe ladite deuxième adresse de fin. Par conséquent, le procédé de surveillance est compatible avec des fonctions d’appels, pouvant être non-systématiques et donc pas complétement prédictibles lors du développement du programme. La procédure d’intégration d’appel permet ainsi de contrôler précisément le nombre d’instructions exécutées par ladite portion de code sélectionnée, sans être faussé par des instructions imprévues issues de l’appel. Avantageusement, la procédure d’intégration d’appel comprend en outre, avec pour portion de code sélectionnée la deuxième portion de code : - l’étape de démarrage d’un autre chronométrage ; - l’étape de comparaison des valeurs courantes du compteur programme avec un autre jeu d’adresses cibles spécifiques à ladite deuxième portion de code sélectionnée ; - l’étape d’arrêt de cet autre chronométrage ; - l’étape de génération du signal d’erreur avec une autre gamme de durées nominale spécifique à ladite deuxième portion de code sélectionnée ; et - le cas échéant, la procédure d’intégration d’un autre appel. Ainsi, le procédé de surveillance prend en compte indépendamment la durée de mise en œuvre de la première portion de code sélectionnée et la durée de mise en œuvre d’une deuxième portion de code sélectionnée appelée par l’exécution de la première portion de code, permettant un contrôle plus précis du nombre d’instructions exécutées par chacune des portions de code sélectionnées. Selon un mode de mise en œuvre, la gamme de durées nominale est définie spécifiquement pour chaque portion de code en fonction d’un nombre de cycles d’horloges d’une exécution nominale par l’unité de traitement, et d’un retard causé par des récupération d’instructions en mémoire. En effet, comme mentionné précédemment, chaque instruction de la portion de code sélectionnée prend un certain nombre de cycle pour être exécutée selon architecture du système sur puce incorporant l’unité de traitement, mais aussi en tenant compte la durée prise pour récupérer des instructions dans une mémoire contenant lesdites instruction, là aussi selon l’architecture et les performances effectives du système sur puce. Selon un mode de mise en œuvre, la gamme de durées nominale est automatiquement ajustée en fonction de l’activité de l’unité de traitement communiquée par au moins l’un des paramètres suivants : la fréquence d’un signal d’horloge cadençant l’exécution de l’unité de traitement ; un événement d’admission d’une instruction en mémoire cache ; un événement d’admission d’une donnée en mémoire cache ; un événement d’éviction d’une donnée en mémoire cache ; un état d’attente de l’unité de traitement. Ainsi, le procédé de surveillance adapte automatiques la gamme de durées nominales en fonction de la performance effective selon le contexte d’une exécution données, à partir de signaux d’information communiqués par l’unité de traitement. Selon un mode de mise en œuvre, le chronométrage est cadencé par un signal d’horloge distinct d’un signal d’horloge cadençant l’exécution de l’unité de traitement. L’unité de surveillance peut en effet être cadencé par un signal d’horloge indépendant, par exemple afin d’être toujours cadencé à une fréquence opérationnelle pour sa configuration, même si la fréquence du signal d’horloge cadençant l’unité de traitement est modifiée. Selon un mode de mise en œuvre, la portion de code programme sélectionnée appartient à une phase de démarrage de l’exécution par l’unité de traitement, avant que des mécanismes de protections par gestion de droits d’accès ne soient effectifs, ou appartient à une phase critique de l’exécution par l’unité de traitement ayant un droit d’accès le plus permissif. Selon un autre aspect, il est également proposé un procédé de fabrication d’un système sur puce adapté pour mettre en œuvre le procédé de surveillance tel que défini ci-avant, comprenant une conception du code programme comportant ladite portion de code programme sélectionnée, puis une fabrication de l’unité de traitement et de l’unité de surveillance matériellement configurée de façon adaptée au code programme conçu, puis un enregistrement du code programme dans une mémoire du système sur puce. Selon un autre aspect, il est également proposé un système sur puce comportant une unité de traitement configurée pour exécuter une portion de code programme sélectionnée et enregistrée dans une plage d’adresses d’une mémoire, entre une adresse de début et une adresse de fin, et pour générer un compteur programme pointant l’adresse d’une instruction exécutée, et une unité de surveillance configurée pour surveiller l’exécution de la portion de code programme sélectionnée, l’unité de surveillance comportant : - un circuit comparateur configuré pour comparer des valeurs courantes du compteur programme avec un jeu d’adresses cibles spécifiques à ladite portion de code sélectionnée comportant l’adresse de fin de ladite portion de code sélectionnée ; - un circuit compteur configuré pour démarrer un chronométrage lorsque le compteur programme pointe l’adresse de début de ladite portion de code sélectionnée et pour arrêter le chronométrage lorsque le compteur programme pointe l’adresse de fin de ladite portion de code sélectionnée ; - un circuit de décision configuré pour générer un signal d’erreur si la durée du chronométrage est en dehors d’une gamme de durées nominale spécifique à ladite portion de code sélectionnée. Selon un mode de réalisation, ladite portion de code sélectionnée comporte au moins une fonction d’appel de respectivement au moins une deuxième portion de code programme enregistrée dans une deuxième plage d’adresses mémoires entre une deuxième adresse de début et une deuxième adresse de fin, et le jeu d’adresses cibles spécifiques à ladite portion de code sélectionnée comporte ladite au moins une deuxième adresse de début, l’unité de surveillance, pour tenir compte de l’appel, étant configurée pour : -- suspendre ledit chronométrage avec le circuit compteur ; -- mémoriser la valeur du chronométrage suspendu ; et -- reprendre ledit chronométrage suspendu à partir de la valeur enregistrée avec le circuit compteur lorsque le compteur programme pointe ladite deuxième adresse de fin. Selon un mode de réalisation, l’unité de surveillance, pour tenir compte de l’appel, est configurée pour paramétrer le circuit comparateur, le circuit compteur et le circuit de décision, avec pour portion de code sélectionnée la deuxième portion de code, et avec un jeu d’adresses cibles et une gamme de durées nominale spécifiques à la deuxième portion de code. Selon un mode de réalisation, le circuit de décision comprend un enregistrement d’une gamme de durées nominale définie spécifiquement pour chaque portion de code en fonction d’un nombre de cycles d’horloges d’une exécution nominale par l’unité de traitement, et d’un retard causé par des récupération d’instructions en mémoire. Selon un mode de réalisation, le circuit de décision est configuré pour automatiquement ajuster la gamme de durées nominale en fonction de l’activité de l’unité de traitement communiquée par au moins l’un des paramètres suivants : la fréquence d’un signal d’horloge cadençant l’exécution de l’unité de traitement ; un événement d’admission d’une instruction dans une mémoire cache ; un événement d’admission d’une donnée dans une mémoire cache ; un événement d’éviction d’une donnée dans une mémoire cache ; un état d’attente de l’unité de traitement. Selon un mode de réalisation, un générateur d’horloge est configuré pour générer un signal d’horloge adapté pour cadencer l’exécution de l’unité de traitement, le circuit compteur étant configuré pour générer un signal d’horloge distinct pour cadencer le chronométrage. Selon un mode de réalisation, un circuit de gestion de droits d’accès est configuré pour opérer un mécanisme de protection par gestion de droits d’accès d’instructions exécutées par l’unité de traitement, l’unité de surveillance étant configurée pour surveiller la portion de code programme sélectionnée appartenant à une phase de démarrage de l’exécution par l’unité de traitement, avant que les mécanismes de protections par gestion de droits d’accès ne soient opérationnels, ou appartenant à une phase critique de l’exécution par l’unité de traitement ayant un droit d’accès le plus permissif. D’autres avantages et caractéristiques de l’invention apparaîtront à l’examen de la description détaillée de modes de réalisation et de mise en œuvre, nullement limitatifs, et des dessins annexés, sur lesquels : ; ; ; ; ; ; ; ; ; ; illustrent des modes de réalisation et de mise en œuvre de l’invention. La illustre un exemple de système sur puce SOC comportant une unité de traitement CPU configurée pour exécuter un code programme enregistré dans une mémoire MEM. L’exécution de l’unité de traitement CPU est cadencée par un signal d’horloge clk généré par un générateur d’horloge PLL, par exemple du type boucle à verrouillage de phase, dédié à l’unité de traitement. L’unité de traitement CPU est configurée pour utiliser un compteur programme PC (usuellement « program counter » en anglais, ou parfois nommé « pointeur d’instruction ») pointant l’adresse de l’instruction exécutée par l’unité de traitement CPU. Les termes « pointer » et « pointeur » sont utilisé dans leurs significations techniques habituelles, c’est-à-dire qu’un pointeur d’une information est un objet informatique contenant l’adresse de l’emplacement mémoire qui contient l’information, et que le verbe pointer signifie désigner une information par l’adresse de l’emplacement mémoire qui contient l’information. Le système sur puce SOC peut être équipé d’un périphérique de mémoire cache CCH ou non, par exemple selon les performances souhaitées pour l’unité de traitement CPU et du système sur puce SOC. Le système sur puce SOC est avantageusement muni d’un circuit de gestion de droits d’accès MMU/MPU configuré, en collaboration avec l’unité de traitement CPU, pour mettre en place un mécanisme de protection par gestion de droits d’accès des instructions exécutées par l’unité de traitement CPU. Le circuit de gestion de droits d’accès MMU/MPU peut par exemple comprendre une unité de gestion de mémoire (usuellement « memory management unit » en anglais), ou bien en alternative une unité de protection mémoire (usuellement « memory protection unit » en anglais) et éventuellement une unité d’attribution de sécurité (usuellement « secure attribution unit » en anglais). Le système sur puce comporte SOC en outre une unité de surveillance SRV configurée pour surveiller l’exécution d’au moins une portion du code programme sélectionnée (par exemple la portion Rst de la ) et enregistrée dans une plage d’adresses d’une mémoire (AddRst), c’est-à-dire entre une adresse de début et une adresse de fin. L’unité de surveillance SRV est avantageusement configurée pour surveiller une portion de code Rst appartenant à une phase de démarrage de l’unité de traitement CPU, telle que la phase de réinitialisation Rst décrite ci-après en relation avec la , notamment avant que les mécanismes de protections par gestion de droits d’accès ne soient opérationnels. Avantageusement également, l’unité de surveillance SRV est configurée pour surveiller une portion de code Rst qui appartient à une opération critique exécutée par l’unité de traitement ayant un droit d’accès le plus permissif, telle qu’une phase de configuration ou de changement de contexte sur les différents niveaux de droit d’accès, par exemples des configurations des attributions de droits d’accès à des régions mémoires (usuellement « mappages/démappages »), des opérations de vidage ou d’invalidation de la mémoire cache entre des contextes sécurisé et non-sécurisé. Par exemple, l’unité de surveillance SRV peut être matériellement configurée, c’est-à-dire configurée « en dur » (usuellement « hardware » en anglais), de façon adaptée au code programme, en particulier le code programme de la phase de démarrage du système. Ainsi, la fabrication du système sur puce SOC comprend d’une part une conception du code programme Intr, Rst, ProtSet, ProtChck, ClkSet, ClkEnLp ( ) comportant ladite portion de code programme sélectionnée Rst. Puis d’autre part la fabrication de l’unité de traitement CPU et de l’unité de surveillance SRV ainsi matériellement configurée, et puis un enregistrement du code programme conçu dans la mémoire MEM du système sur puce SOC. Cela étant, l’unité de surveillance SRV comporte avantageusement des registres d’interfaces INTF_REG, adaptés pour recevoir des commandes de configuration Config afin de reconfigurer l’unité de surveillance SRV ou bien de compléter la configuration pour de nouvelles zones de code. Pour la surveillance de ladite portion de code Rst, l’unité de surveillance SRV comporte un circuit comparateur CMP, adapté pour conditionner la mise en œuvre de la surveillance en fonction de l’adresse pointée par le compteur programme PC ; un circuit compteur CNT, adapté pour chronométrer le temps d’exécution de la portion de code programme surveillée ; et un circuit de décision DSC, adapté pour générer un signal d’erreur Err si le chronométrage ne correspond pas à une exécution normale du code programme. Le circuit comparateur CMP est configuré pour comparer des valeurs courantes du compteur programme PC, communiquées par l’unité de traitement CPU, avec un jeu d’adresses cibles TRGT spécifiques à ladite portion de code sélectionnée Rst comportant notamment l’adresse de fin de ladite portion de code sélectionnée e{Rst} ( ). Les jeux d’adresses cibles TRGT de chaque portion de code pouvant être surveillée, sont par exemple contenus dans un registre. Le circuit compteur CNT est configuré pour démarrer un chronométrage lorsque le compteur programme PC pointe l’adresse de début de ladite portion de code sélectionnée s{Rst} ( ) et pour arrêter le chronométrage lorsque le compteur programme PC pointe l’adresse de fin de ladite portion de code sélectionnée e{Rst} ( ). Le chronométrage correspond par exemple en pratique à un comptage du nombre de cycles d’un signal d’horloge entre l’exécution de l’adresse de début et l’adresse de fin. Le signal d’horloge utilisé pour cadencer le compteur CNT peut par exemple être le signal d’horloge clk destiné à l’unité de traitement CPU, ou bien être issu d’un générateur d’horloge interne ClkGen de l’unité de surveillance SRV configuré pour générer un signal d’horloge distinct. Le circuit de décision DSC est configuré pour générer le signal d’erreur Err si la durée mesurée par le chronométrage est en dehors d’une gamme de durées nominale NmnlRng spécifique à ladite portion de code sélectionnée. La gamme de durées nominale NmnlRng tient avantageusement compte de l’architecture et des performances effectives du système sur puce SOC, par exemple en fonction de la présence ou non d’un dispositif de mémoire cache CCH. En comptant le nombre de cycles d’horloge passés entre l’adresse de début et l’adresse de fin, il est ainsi possible de contrôler le nombre d’instructions exécutées dans la portion de code sélectionnée. En effet, chaque instruction est exécutée sur un certain nombre de cycles, connu lors du développement du code programme, qui peut dépendre de l’architecture du système sur puce SOC et de l’unité de traitement CPU. La gamme de durées nominale NmnlRng est ainsi définie spécifiquement pour chaque portion de code en fonction d’un nombre de cycles d’horloges d’une exécution nominale par l’unité de traitement CPU. Par « exécution nominale », on entend une exécution réussie de cette portion de code, comme prévu à la conception du code programme, c’est-à-dire sans instruction en moins ou en plus ou différente que celles prévues, par exemple en particulier sans dysfonctionnement et notamment sans injection de faute. La gamme de durées nominale NmnlRng spécifique à chaque portion de code sélectionnée peut en outre avantageusement prendre en compte des performances effectives du système sur puce SOC, en particulier un retard causé par des récupération d’instructions FTCH en mémoire MEM. En effet, la durée prise pour récupérer des instructions dans la mémoire MEM contenant lesdites instructions peut dépendre de l’architecture du système sur puce SOC, par exemple selon la taille de la mémoire MEM, du protocole de communication utilisé avec la mémoire, de la technologie de la mémoire (« EEPROM », « Flash », « mémoire résistive », etc), ou encore du fait que la mémoire soit interne ou externe à l’unité de traitement CPU voire externe au système sur puce SOC. En outre, le circuit de décision DCS est avantageusement configuré pour automatiquement ajuster la gamme de durées nominale NmnlRng en fonction de l’activité de l’unité de traitement CPU. L’activité de l’unité de traitement CPU peut dépendre d’un mode de fonctionnement, tels qu’un mode de veille, un mode visant l’économie d’énergie ou un mode visant la performance, mais aussi de la disponibilité des emplacements en mémoire cache CCH, ou encore d’un état d’attente de l’unité de traitement CPU par exemple dû à un conflit avec un autre dispositif sur un bus d’accès à une mémoire partagée. Ainsi, l’activité de l’unité de traitement CPU ne peut pas être anticipée lors du développement du code programme, mais les effets de ces différentes conditions d’activité sur la durée nominale d’exécution de la portion de code sélectionné sont connus. En outre, ces différentes conditions peuvent être communiquées à l’unité de surveillance SRV par des signaux générés par l’unité de traitement CPU, afin d’ajuster automatiquement la gamme de durées nominale NmnlRng aux conditions effectives. L’activité de l’unité de traitement CPU peut être communiquée à l’unité de surveillance SRV par au moins l’un des paramètres suivants : la fréquence FreqSel du signal d’horloge clk cadençant l’exécution de l’unité de traitement ; un événement d’admission d’une instruction dans une mémoire cache Cch_I, de sorte qu’une prochaine récupération de cette instruction sera plus rapide en terme de cycles d’horloge ; un événement d’admission d’une donnée dans une mémoire cache Cch_D, de sorte qu’une prochaine récupération de cette donnée sera plus rapide en terme de cycles d’horloge ; un événement d’éviction d’une donnée dans une mémoire cache Cch_Evct de sorte qu’une prochaine récupération de cette donnée sera plus lente en terme de cycles d’horloge ; un état d’attente STALL de l’unité de traitement, durant lequel l’instruction en cours n’est pas exécutée. En pratique, le circuit compteur CNT et le circuit de décision DCS peuvent être combiné en un même circuit du type décompteur initialisé à une valeur de départ correspondant au nombre de cycles d’horloge clk de l’unité de traitement CPU, dans le cas le plus lent (par exemple en absence de mémoire cache). Un facteur de proportionnalité peut être appliqué sur la valeur de départ pour tenir compte de la différence entre la fréquence FreqSel du signal d’horloge clk cadençant l’unité de traitement CPU et la fréquence du signal d’horloge cadençant le décompte CNT. A chaque cycle d’horloge, la valeur du décompte est décrémentée. En cas d’événement d’admission d’une instruction dans la mémoire cache Cch_I, la valeur du décompte est réduite d’une quantité correspondant au gain, en nombre de cycles d’horloge, pour la récupération de l’instruction en mémoire cache. En cas d’événement d’admission d’une donnée dans la mémoire cache Cch_D, la valeur du décompte est réduite d’une quantité correspondant au gain, en nombre de cycles d’horloge, pour la récupération de la donnée en mémoire cache. En cas d’événement d’éviction d’une donnée dans une mémoire cache Cch_Evct la valeur du décompte est augmentée d’une quantité correspondant à la perte, en nombre de cycles d’horloge, pour la récupération de la donnée dans la mémoire MEM. Lorsque que la valeur du décompte est égale à zéro, le signal d’erreur Err est généré. Lorsque le compteur programme PC pointe l’adresse de fin « e » et que la valeur du décompte est égale à zéro, le signal d’erreur Err n’est pas généré ; tandis que lorsque le compteur programme PC pointe l’adresse de fin « e », et que la valeur du décompte est supérieure à zéro, le signal d’erreur Err est généré. En alternative, lorsque le compteur programme PC pointe l’adresse de fin « e » et que la valeur du décompte est comprise entre zéro et un seuil de tolérance, le signal d’erreur Err n’est pas généré ; tandis que lorsque le compteur programme PC pointe l’adresse de fin « e », et que la valeur du décompte est supérieure audit seuil de tolérance, le signal d’erreur Err est généré. D’autre part, l’unité de surveillance peut tenir compte d’éventuelles fonctions d’appel, dans la portion de code programme sélectionnée, vers une autre portion de code programme. En effet, l’exécution d’une fonction d’appel engendre une exécution d’un code programme contenu en dehors de la plage d’adresse mémoire AddRst ( ), d’une manière qui n’est pas nécessairement prédictible, ce qui pourrait à priori fausser le compte du nombre d’instructions dans une exécution nominal NmnlRng comparé au chronométrage mesuré. Cela est également le cas pour les exécutions issues d’interruption Intr ( ), pouvant survenir à tout moment de l’exécution d’une portion de code donné, et typiquement non-prédictibles. On se réfère à cet égard aux figures 2A, 2B et 2C. La illustre schématiquement une cartographie (usuellement « mapping » en anglais, ou « mappage » selon un anglicisme usuel en français) de la mémoire MEM contenant le code programme, et contenant en particulier la portion de code programme sélectionnée Rst, ainsi que des autres portions de code pouvant être appelées par des fonctions d’appel CLL. La portion de code sélectionnée est par exemple une procédure de réinitialisation (usuellement « reset » en anglais) Rst, typiquement mise en œuvre lors des premières étapes du démarrage ou redémarrage du système sur puce SOC. La portion de code de réinitialisation Rst est enregistrée dans une plage d’adresses mémoires AddRst située entre une adresse de début « s » et une adresse de fin « e ». Dans cet exemple, la portion de code de réinitialisation Rst peut appeler CLL : une portion de code de mise en place de protections ProtSet enregistrée dans une autre plage d’adresses mémoires AddProtSet entre une adresse de début « s » et une adresse de fin « e » ; une portion de code de vérification des protections ProtChck enregistrée dans une autre plage d’adresses mémoires AddProtChck entre une adresse de début « s » et une adresse de fin « e » ; et une portion de code de modification d’horloge ClkSet, pour par exemple modifier la fréquence du signal d’horloge clk de l’unité de traitement CPU, enregistrée dans une autre plage d’adresses mémoires AddClkSet entre une adresse de début « s » et une adresse de fin « e ». La portion de code de modification d’horloge ClkSet peut quant à elle appeler CLL{ClkEnLp} une portion de code de boucle d’activation d’horloge, enregistrée dans une autre plage d’adresses mémoires AddClkEnLp entre une adresse de début « s » et une adresse de fin « e ». Enfin, toutes les portions de code Rst, ProtSet, ProtChck, ClkSet, ClkEnLp peuvent appeler une interruption Intr, par exemple une interruption « Tick » utilisée pour fournir une information de temps réel, enregistrée dans une autre plage d’adresses mémoires AddIntr entre une adresse de début « s » et une adresse de fin « e ». Par ailleurs, le traitement de l’interruption Intr peut prévoir un changement de contexte CntxSw avant et après son exécution, par exemple pour aller d’un contexte sécurisé vers un contexte non-sécurisé, puis revenir au contexte sécurisé depuis le contexte non-sécurisé. Les opérations de changements de contextes CntxSw peuvent être inclues à la surveillance effectuée par l’unité de surveillance SRV ou éventuellement non si ces opérations sont par ailleurs protégées par d’autres mécanismes fiables. Les adresses de début et de fin sont toutes référencées respectivement « s » et « e » mais sont bien entendu différentes d’une plage d’adresse à une autre. On se réfère désormais à la . Une procédure d’intégration d’appel est avantageusement mise en œuvre, afin de contrôler précisément le nombre d’instructions exécutées par la première portion de code sélectionnée Rst, sans être faussé par des instructions issues de l’appel. En outre, la procédure d’intégration d’appel permet de d’effectuer un contrôle précis du nombre d’instructions exécutées par une deuxième portion de code appelée, par exemple ClkSet, en tant que portion de code sélectionnée. Lorsque le compteur programme PC pointe l’une desdites deuxièmes adresses de début « s », la procédure d’intégration d’appel comprend une suspension du chronométrage de l’exécution de la portion de code sélectionnée ; une mémorisation de la valeur du chronométrage suspendu ; et une reprise du chronométrage suspendu à partir de la valeur enregistrée, lorsque le compteur programme PC pointe la deuxième adresse de fin « e » correspondante, c’est-à-dire lorsque l’exécution de la portion de code appelée est terminée, qu’aucune erreur n’est détectée, et que l’exécution de la portion de code sélectionnée reprend son cours. A cet égard, le jeu d’adresses cibles TRGT{Rst} spécifiques à la portion de code de réinitialisation Rst sélectionnée comporte, en outre de l’adresse de fin de la portion de code sélectionnée e{Rst}, des « deuxièmes » adresses de début s{Intr}, s{ProtSet}, s{ProtChck}, s{ClkSet} des portions de code pouvant être appelées Intr, ProtSet, ProtChck, ClkSet, lors de l’exécution de la portion de code de réinitialisation Rst. Ainsi, par exemple dans l’exécution de la portion de code d’initialisation Rst, lors de l’appel CLL{ClkSet} de la deuxième portion de code de modification d’horloge ClkSet, le compteur programme PC pointe la deuxième adresse de début s{ClkSet} de cette deuxième portion de code et le chronométrage de la portion de code de réinitialisation Rst est suspendu de sorte que sa valeur courante est maintenue dans le compteur ou enregistrée. La deuxième portion de code appelée, c’est-à-dire la portion de code de modification d’horloge ClkSet, est exécutée et peut, elle aussi, être contrôlée par le procédé de surveillance mis en œuvre par l’unité de surveillance SRV. On se réfère à cet égard à la . La deuxième portion de code de modification d’horloge ClkSet est exécutée, et, avec pour portion de code sélectionnée la portion de code de modification d’horloge ClkSet, le procédé de surveillance est mis en œuvre de la même manière que décrit précédemment en relation avec la , avec les étapes suivantes : - un démarrage d’un autre chronométrage lorsque le compteur programme PC pointe l’adresse de début de ladite portion de code de modification d’horloge s{ClkSet} ; - une comparaison en continu des valeurs courantes du compteur programme PC avec un jeu d’adresses cibles spécifiques à la deuxième portion de code de modification d’horloge TRGT{ClkSet} comportant l’adresse de fin de ladite portion de code de modification d’horloge e{ClkSet}, ainsi que les éventuelles adresses de début s{Intr}, s{ClkEnLp} des autre portions de code Intr, ClkEnLp, pouvant être appelées CLL par la portion de code de modification d’horloge ClkSet ; - une éventuelle procédure d’intégration d’appel telle que décrite en relation avec les figures 2B et 2C ; - un arrêt de cet autre chronométrage lorsque le compteur programme PC pointe l’adresse de fin de la portion de code de modification d’horloge e{ClkSet} ; et - une génération du signal d’erreur Err si la durée de cet autre chronométrage est en dehors d’une gamme de durées nominale NmnlRng spécifique à la deuxième portion de code ClkSet. Après l’adresse de fin de la portion de code de modification d’horloge e{ClkSet}, le compteur programme pointe vers l’adresse de retour de la première portion de code de réinitialisation Rst, et le procédé de surveillance reprend pour la première portion de code de réinitialisation Rst, à partir du compte du chronométrage suspendu et avec en particulier avec le jeu d’adresses cibles TRGT{Rst} et la gamme de durées nominales NmnlRng spécifiques à la portion de code de réinitialisation Rst. Par conséquent, étant donné que le procédé de surveillance est appliqué indépendamment sur la première portion de code sélectionnée Rst et sur la deuxième portion de code appelée ClkSet, le contrôle de la quantité d’instructions exécutées est plus précis pour chacune des portions de code sélectionnées Rst, ClkSet. Les figures 3A à 3G illustrent des exemples de mise en œuvre de l’exécution du code programme décrit précédemment en relation avec les figures 2A à 2C, dans une représentation temporelle où le temps avance de la gauche vers la droite. Bien que les des adresses de début et de fin de portions de code soient marquées respectivement par « s » et « e », on notera « s{X} » et « e{X} » les marques de début et de fin de l’exécution de chaque portion de code « X ». La illustre un exemple d’exécution correcte de la portion de code de réinitialisation et de ses appels. Le procédé de surveillance commence lorsqu’est exécutée l’instruction située à l’adresse de début s{Rst} de la portion de code de réinitialisation Rst. La portion de code de modification d’horloge ClkSet est appelée et commence à la marque s{ClkSet}, la surveillance du programme de réinitialisation Rst est suspendue et le procédé de surveillance est mis en œuvre pour l’exécution du code de modification d’horloge ClkSet. La portion de code de boucle d’activation d’horloge ClkEnLp est appelée et commence à la marque s{ClkEnLp}, la surveillance du programme de modification d’horloge ClkSet est suspendue et le procédé de surveillance est mis en œuvre pour la boucle d’activation d’horloge ClkEnLp. La portion de code de boucle d’activation d’horloge ClkEnLp n’a pas de fonction d’appel et se termine à la marque de fin e{ClkEnLp}. Si la durée chronométrée dans la surveillance de la portion de code de boucle d’activation d’horloge ClkEnLp est située dans la gamme de durées nominale NmnlRng respective, alors le signal d’erreur Err n’est pas généré. La surveillance reprend pour la portion de code de modification d’horloge ClkSet, exécutée jusqu’à la marque de fin e{ClkSet}, et le signal d’erreur Err n’est pas généré si la durée chronométrée est située dans la gamme de durées nominale NmnlRng respective. L’exécution et la surveillance de la portion de code de réinitialisation Rst reprennent. La portion de code de vérification des protections ProtChck est appelée et commence à la marque s{ProtChck}, la surveillance du programme de réinitialisation Rst est suspendue et le procédé de surveillance est mis en œuvre pour l’exécution de la vérification des protections ProtChck. La portion de code de vérification des protections ProtChck n’a pas de fonction d’appel et se poursuit jusqu’à la marque de fin e{ProtChck}. Le signal d’erreur Err n’est pas généré si la durée chronométrée est située dans la gamme de durées nominale NmnlRng respective. L’exécution et la surveillance de la portion de code de réinitialisation Rst reprennent. La portion de code de mise en place de protections ProtSet est appelée et commence à la marque s{ProtSet}, la surveillance du programme de réinitialisation Rst est suspendue et le procédé de surveillance est mis en œuvre pour l’exécution de la mise en place de protections ProtSet. La portion de code de mise en place de protections ProtSet n’a pas de fonction d’appel et se poursuit jusqu’à la marque de fin e{ProtSet}. Le signal d’erreur Err n’est pas généré si la durée chronométrée est située dans la gamme de durées nominale NmnlRng respective. L’exécution et la surveillance de la portion de code de réinitialisation Rst reprennent. La portion de code d’interruption Intr est appelée et commence à la marque s{Intr}, la surveillance du programme de réinitialisation Rst est suspendue et le procédé de surveillance est mis en œuvre pour l’exécution de l’interruption Intr. La portion de code d’interruption Intr n’a pas de fonction d’appel et se poursuit jusqu’à la marque de fin e{Intr}. Le signal d’erreur Err n’est pas généré si la durée chronométrée est située dans la gamme de durées nominale NmnlRng respective. L’exécution et la surveillance de la portion de code de réinitialisation Rst reprennent, jusqu’à la marque de fin e{Rst}, et le signal d’erreur Err n’est pas généré si la durée chronométrée cumulée est située dans la gamme de durées nominale NmnlRng respective. La illustre un autre exemple d’exécution correcte de la portion de code de réinitialisation et de ses appels, dans lequel la portion de code de la boucle d’activation d’horloge ClkEnLp est répétée plusieurs fois en série. Cela peut être le cas en pratique par exemple pour paramétrer une boucle à verrouillage de phase. Etant donnée que le procédé de surveillance de l’exécution du code ClkSet qui a appelé la boucle d’activation d’horloge ClkEnLp est suspendu pendant les exécutions successives de la boucle d’activation d’horloge ClkEnLp, la répétition de cette portion de code n’influence pas la surveillance des autres portions de codes. D’autre part, chaque exécution de la boucle d’activation d’horloge ClkEnLp est surveillée indépendamment des autres de la série, entre chaque marqueur s{ClkEnLp} et e{ClkEnLp}, et ainsi le nombre de répétition dans la série n’est pas contraint par avance. La illustre un exemple d’exécution incorrecte de la portion de code de réinitialisation Rst et de ses appels. Dans cet exemple, les portions de code sont exécutées correctement, dans les gammes de durées nominale NmnlRng respectives, jusqu’à la reprise de l’exécution du code de réinitialisation Rst après la fin e{ProtChck} de la portion de code de vérification des protections ProtChck. En effet, dans cet exemple l’exécution de la portion de code de réinitialisation Rst se termine e{Rst} à ce moment, ce qui arrête trop tôt le chronométrage du procédé de surveillance de cette portion de code Rst. Dans ce cas, la durée du chronométrage est inférieure à la gamme de durées nominale NmnlRng respective et le signal d’erreur Err est généré. La illustre un autre exemple d’exécution incorrecte de la portion de code de réinitialisation Rst et de ses appels. Dans cet exemple, les portions de code sont exécutées correctement, dans les gammes de durées nominale NmnlRng respectives, jusqu’à la reprise de l’exécution du code de réinitialisation Rst après la fin e{ProtChck} de la portion de code de vérification des protections ProtChck. En effet, dans cet exemple l’exécution de la portion de code de réinitialisation Rst ne se termine pas de manière normale et se poursuit plus longtemps que prévu. En conséquence le chronométrage atteint une valeur supérieure à la gamme de durées nominale NmnlRng respective, et le signal d’erreur Err est généré. La illustre un autre exemple d’exécution incorrecte de la portion de code de réinitialisation Rst et de ses appels. Dans cet exemple, c’est l’exécution de la portion de code d’interruption Intr qui ne se termine pas de manière normale et se poursuit plus longtemps que prévu. En conséquence le chronométrage atteint une valeur supérieure à la gamme de durées nominale NmnlRng respective, et le signal d’erreur Err est généré. La illustre un autre exemple d’exécution incorrecte de la portion de code de réinitialisation Rst et de ses appels. Dans cet exemple, c’est l’exécution de la portion de code de vérification des protections ProtChck qui ne se termine pas de manière normale et se poursuit plus longtemps que prévu. En conséquence le chronométrage atteint une valeur supérieure à la gamme de durées nominale NmnlRng respective, et le signal d’erreur Err est généré. La illustre un autre exemple d’exécution incorrecte de la portion de code de réinitialisation Rst et de ses appels. Dans cet exemple, c’est l’exécution de la portion de code de mise en place de protection ProtSet qui se termine e{Rst} en avance, ce qui arrête le chronométrage à une valeur inférieure à la gamme de durées nominale NmnlRng respective, et le signal d’erreur Err est généré. Procédé de surveillance, mis en œuvre par une unité de surveillance (SRV), d’une exécution d’une portion de code programme sélectionnée (Rst) et enregistrée dans une plage d’adresses mémoires (AddRst) entre une adresse de début (s) et une adresse de fin (e), mise en œuvre par une unité de traitement (CPU) utilisant un compteur programme (PC) pointant l’adresse d’une instruction exécutée par l’unité de traitement, le procédé de surveillance comprenant : - un démarrage d’un chronométrage (CNT) lorsque le compteur programme (PC) pointe l’adresse de début de ladite portion de code sélectionnée (s{Rst}) ; - une comparaison (CMP) des valeurs courantes du compteur programme (PC) avec un jeu d’adresses cibles spécifiques à ladite portion de code sélectionnée (TRGT{Rst}) comportant l’adresse de fin de ladite portion de code sélectionnée (e{Rst}) ; - un arrêt du chronométrage (CNT) lorsque le compteur programme (PC) pointe l’adresse de fin de ladite portion de code sélectionnée (e{Rst}) ; - une génération d’un signal d’erreur (Err) si la durée du chronométrage est en dehors d’une gamme de durées nominale (NmnlRng) spécifique à ladite portion de code sélectionnée (Rst). Procédé selon la revendication 1, dans lequel ladite portion de code sélectionnée (Rst) comporte au moins une fonction d’appel (CLL{ClkSet}) de respectivement au moins une deuxième portion de code programme (ClkSet) enregistrée dans une deuxième plage d’adresses mémoires (AddClkSet) entre une deuxième adresse de début (s) et une deuxième adresse de fin (e), et le jeu d’adresses cibles spécifiques à ladite portion de code sélectionnée (TRGT{Rst}) comporte ladite au moins une deuxième adresse de début (s{ClkSet}), le procédé de surveillance comprenant en outre une procédure d’intégration d’appel lorsque le compteur programme (PC) pointe ladite deuxième adresse de début (s{ClkSet}), la procédure d’intégration d’appel comprenant : -- une suspension du chronométrage (CNT) ; -- une mémorisation de la valeur du chronométrage suspendu ; et -- une reprise du chronométrage suspendu (CNT) à partir de la valeur mémorisée lorsque le compteur programme (PC) pointe ladite deuxième adresse de fin (e). Procédé selon la revendication 2, dans lequel la procédure d’intégration d’appel comprend en outre, avec pour portion de code sélectionnée la deuxième portion de code (ClkSet) : - l’étape de démarrage d’un autre chronométrage (CNT) ; - l’étape de comparaison (CMP) des valeurs courantes du compteur programme (PC) avec un autre jeu d’adresses cibles spécifiques à ladite deuxième portion de code sélectionnée (TRGT{ClkSet}) ; - l’étape d’arrêt de cet autre chronométrage (CNT) ; - l’étape de génération du signal d’erreur (Err) avec une autre gamme de durées nominale (NmnlRng) spécifique à ladite deuxième portion de code sélectionnée (ClkSet) ; et - le cas échéant, la procédure d’intégration d’un autre appel (CLL{ClkEnLp}). Procédé selon l’une des revendications précédentes, dans lequel la gamme de durées nominale (NmnlRng) est définie spécifiquement pour chaque portion de code (Rst, ClkSet) en fonction d’un nombre de cycles d’horloges d’une exécution nominale par l’unité de traitement (CPU), et d’un retard causé par des récupération d’instructions en mémoire (FTCH). Procédé selon l’une des revendications précédentes, dans lequel la gamme de durées nominale (NmnlRng) est automatiquement ajustée en fonction de l’activité de l’unité de traitement (CPU) communiquée par au moins l’un des paramètres suivants : la fréquence d’un signal d’horloge (FreqSel) cadençant l’exécution de l’unité de traitement ; un événement d’admission d’une instruction en mémoire cache (Cch_I) ; un événement d’admission d’une donnée en mémoire cache (Cch_D) ; un événement d’éviction d’une donnée en mémoire cache (Cch_Evct) ; un état d’attente de l’unité de traitement (STALL). Procédé selon l’une des revendications précédentes, dans lequel le chronométrage (CNT) est cadencé par un signal d’horloge distinct (ClkGen) d’un signal d’horloge (clk) cadençant l’exécution de l’unité de traitement (CPU). Procédé selon l’une des revendications précédentes, dans lequel la portion de code programme sélectionnée (Rst) appartient à une phase de démarrage de l’exécution par l’unité de traitement (CPU), avant que des mécanismes de protections par gestion de droits d’accès (MMU/MPU) ne soient effectifs, ou appartient à une phase critique de l’exécution par l’unité de traitement ayant un droit d’accès le plus permissif. Procédé de fabrication d’un système sur puce (SOC) adapté pour mettre en œuvre le procédé de surveillance selon l’une des revendications 1 à 7, comprenant une conception du code programme (Intr, Rst, ProtSet, ProtChck, ClkSet, ClkEnLp) comportant ladite portion de code programme sélectionnée (Rst), puis une fabrication de l’unité de traitement (CPU) et de l’unité de surveillance (SRV) matériellement configurée de façon adaptée au code programme conçu (Intr, …, ClkEnLp), puis un enregistrement du code programme dans une mémoire (MEM) du système sur puce (SOC). Système sur puce (SOC) comportant une unité de traitement (CPU) configurée pour exécuter une portion de code programme sélectionnée (Rst) et enregistrée dans une plage d’adresses d’une mémoire (AddRst), entre une adresse de début (s) et une adresse de fin (e), et pour générer un compteur programme (PC) pointant l’adresse d’une instruction exécutée, et une unité de surveillance (SRV) configurée pour surveiller l’exécution de la portion de code programme sélectionnée (Rst), l’unité de surveillance (SRV) comportant : - un circuit comparateur (CMP) configuré pour comparer des valeurs courantes du compteur programme (PC) avec un jeu d’adresses cibles (TRGT) spécifiques à ladite portion de code sélectionnée (Rst) comportant l’adresse de fin de ladite portion de code sélectionnée (e{Rst}) ; - un circuit compteur (CNT) configuré pour démarrer un chronométrage lorsque le compteur programme (PC) pointe l’adresse de début de ladite portion de code sélectionnée (s{Rst}) et pour arrêter le chronométrage lorsque le compteur programme (PC) pointe l’adresse de fin de ladite portion de code sélectionnée (e{Rst}) ; - un circuit de décision (DSC) configuré pour générer un signal d’erreur (Err) si la durée du chronométrage est en dehors d’une gamme de durées nominale (NmnlRng) spécifique à ladite portion de code sélectionnée. Système sur puce selon la revendication 9, dans lequel ladite portion de code sélectionnée (Rst) comporte au moins une fonction d’appel (CLL) de respectivement au moins une deuxième portion de code programme (ClkSet) enregistrée dans une deuxième plage d’adresses mémoires (AddClkSet) entre une deuxième adresse de début (s) et une deuxième adresse de fin (e), et le jeu d’adresses cibles (TRGT{Rst}) spécifiques à ladite portion de code sélectionnée comporte ladite au moins une deuxième adresse de début (s{ClkSet}), l’unité de surveillance (SRV), pour tenir compte de l’appel (CLL), étant configurée pour : -- suspendre ledit chronométrage avec le circuit compteur (CNT) ; -- mémoriser la valeur du chronométrage suspendu ; et -- reprendre ledit chronométrage suspendu à partir de la valeur enregistrée avec le circuit compteur (CNT) lorsque le compteur programme (PC) pointe ladite deuxième adresse de fin (e). Système sur puce selon la revendication 10, dans lequel, l’unité de surveillance (SRV), pour tenir compte de l’appel (CLL), est configurée pour paramétrer le circuit comparateur (CMP), le circuit compteur (CNT) et le circuit de décision (DCS), avec pour portion de code sélectionnée la deuxième portion de code (ClkSet), et avec un jeu d’adresses cibles (TRGT{ClkSet}) et une gamme de durées nominale (NmnlRng) spécifiques à la deuxième portion de code (ClkSet). Système sur puce selon l’une des revendications 8 à 11, dans lequel le circuit de décision (DCS) comprend un enregistrement d’une gamme de durées nominale (NmnlRng) définie spécifiquement pour chaque portion de code (Rst ; ClkSet) en fonction d’un nombre de cycles d’horloges d’une exécution nominale par l’unité de traitement (CPU), et d’un retard causé par des récupération d’instructions en mémoire (FTCH). Système sur puce selon l’une des revendications 8 à 12, dans lequel le circuit de décision (DCS) est configuré pour automatiquement ajuster la gamme de durées nominale (NmnlRng) en fonction de l’activité de l’unité de traitement (CPU) communiquée par au moins l’un des paramètres suivants : la fréquence d’un signal d’horloge (FreqSel) cadençant l’exécution de l’unité de traitement ; un événement d’admission d’une instruction dans une mémoire cache (Cch_I) ; un événement d’admission d’une donnée dans une mémoire cache (Cch_D) ; un événement d’éviction d’une donnée dans une mémoire cache (Cch_Evct) ; un état d’attente de l’unité de traitement (STALL). Système sur puce selon l’une des revendications 8 à 13, dans lequel un générateur d’horloge (PLL) est configuré pour générer un signal d’horloge adapté pour cadencer l’exécution de l’unité de traitement (CPU), le circuit compteur (CNT) étant configuré pour générer un signal d’horloge distinct pour cadencer le chronométrage (ClkGen). Système sur puce selon l’une des revendications 8 à 14, dans lequel un circuit de gestion de droits d’accès (MMU/MPU) est configuré pour opérer un mécanisme de protection par gestion de droits d’accès d’instructions exécutées par l’unité de traitement (CPU), l’unité de surveillance (SRV) étant configurée pour surveiller la portion de code programme sélectionnée (Rst) appartenant à une phase de démarrage de l’exécution par l’unité de traitement (CPU), avant que les mécanismes de protections par gestion de droits d’accès ne soient opérationnels, ou appartenant à une phase critique de l’exécution par l’unité de traitement ayant un droit d’accès le plus permissif.