Brevet FR2725288A3 — publié le 19960405

FR 2725288 A3 19960405 FR 9511321 A 19950927 Conception et essai de systèmes électroniques. La présente invention concerne la conception et les essais de systèmes électroniques. De nombreux développements ont été réalisés dans la conception et les essais de types particuliers de systèmes électroniques. Par exemple, le document PCT n" WO 92/1420 (DEC) décrit un procédé de simulation qui permet de tester et de mettre au point des programmes d'ordinateur simultanément. Par ailleurs, le brevet européen EP-A2-O 404 482 (Hyduke) décrit un système et un procédé pour simuler des concepts de circuits logiques en utilisant une table de données et une bibliothèque de modèles. Les procédés décrits dans ces documents sont sans aucun doute bénéfiques pour les tâches spécifiques auxquelles ils s'adressent. Par exemple, le procédé du document EP-A2-O 404 482 assure apparemment des tests efficaces et complets de modèles de circuits logiques par l'emploi de tables générées dynamiquement. Ces systèmes suivent la tendance générale qui s'oriente vers une spécialisation accrue des domaines de conception et d'essai dans lesquels les procédés sont limités aux systèmes matériels (silicium) ou, en variante, aux systèmes logiciels. De plus, il s'avère de manière générale, que le procédé ne s'applique qu'à des types particuliers de matériel ou de logiciel, par exemple à des circuits ASIC. La raison apparente de cette tendance réside dans la complexité accrue des systèmes électroniques cibles et dans la spécialisation dc la conception et des essais qui en résulte. Cela a mené à une grande dépendance commerciale des sociétés individuelles de secteurs particuliers, ce qui est naturellement risqué. En outre, le service fourni n'est souvent pas satisfaisant du fait qu'un tiers doit effectuer un travail considérable pour intégrer le système à d'autres systèmes ou sous-systèmes.Il existe donc un besoin d'un procédé qui permette de concevoir et de tester des systèmes électroniques qui sont constitués principalement de matériel, principalement de logiciel ou des deux en fonction des besoins du consommateur. L'invention vise à procurer un procédé polyvalent qui fournisse les étapes nécessaires à la conception et aux essais de différents types de systèmes électroniques sans sacrifier la qualité ou l'efficacité. L'invention vise un procédé de conception et d'essai de systèmes électroniques cibles, le procédé étant exécuté par un système de production comportant des postes de travail connectés selon un agencement de réseau distribué, le procédé comprenant les étapes suivantes un pivot central du système de production contrôlant les interfaces des postes de travail et régissant l'accès de tous les postes de travail à des programmes et des données requis; les postes de travail générant des spécifications techniques définissant les aspects suivants du système électronique cible aspects fonctionnels du système comprenant le nombre de flux de données parallèles; signalisation des formats pour les interfaces;; partage fonctionnel en composants d'exploitation principaux, et conditions de performances exigées en termes de débit de données, de fréquence de fonctionnement, de critères de défaillance et de paramètres de code, on effectue une analyse automatique des flux de données; on effectue une analyse de synchronisation automatique en fonction des retards de propagation cumulatifs et des exigences de synchronisation d'entrée; on effectue une analyse de transition d'état et de commande; on effectue une analyse détaillée du procédé; on effectue des estimations de taille et de performances sur la base des données des spécifications, lesdites estimations comprenant la taille physique des semi-conducteurs et les capacités des mémoires logiques;; on développe un code de manière distribuée dans différents postes de travail du système de production, le code étant optimisé automatiquement selon le débit de données en fonction du temps de réponse ou du cycle d'exécution de code et des estimations de taille, et on teste le système qui est développé en simulant les performances du matériel et en simulant des systèmes électroniques qui doivent être connectés au système cible en fonctionnement, la simulation étant réalisée par des simulateurs parallèles à grande vitesse connectés directement aux postes de travail du système de production et par des postes dc travail distribués à l'intérieur du système, délivrant des signaux de simulation via des câbles du réseau du système de production. De préférence, les tests du système cible comprennent les étapes d'identification des composants opératoires les plus petits du système, l'exécution de l'analyse automatique de l'historique des tests des composants et ensuite la réalisation des tests des composants par génération aléatoire d'instructions d'essai. Dans une forme de réalisation, l'étape d'analyse de l'historique des tests comprend l'étape d'identification des composants ayant des structures de synchronisation complexes. Dans une autre forme de réalisation, les tests comprennent les autres étapes d'interconnexion des composants du système cible suivies de tests au niveau système dans lesquels la simulation du système cible ou de systèmes dans l'environnement opératoire sont simulés. Dans une autre forme de réalisation encore, un poste de travail du système de production offre une retroaction de couverture d'essai automatique en contrôlant en continu la couverture de tous les tests au niveau des composants et au niveau du système. Idéalement, la couverture des tests est quantifiée par un suivi automatique du code de source lorsque le code machine associé est en cours d'exécution. Dans une autre forme de réalisation, les tests au niveau du système peuvent être répétés ou augmentés en fonction de la rétroaction de la couverture d'essai automatique. De préférence, des tests sont mis en oeuvre par inclusion d'un code d'essai à l'intérieur du code du système cible, ledit code d'essai étant effacé lors de la compilation du code. L'invention sera à présent expliquée plus en détail sur la base de la description suivante de certaines formes de réalisation, donnée à titre d'exemple uniquement, avec référence aux dessins annexés, dans lesquels la Fig. 1 est un organigramme présentant un aperçu des étapes globales du procédé de l'invention; la Fig. 2 est un schéma fonctionnel représentant un système de production de conception et d'essai susceptible d'être utilisé dans le procédé; la Fig. 3 est un diagramme de synchronisation montrant la manière dont l'étape 4 de la Fig. 1 peut être mise en oeuvre; la Fig. 4 est un schéma de transition d'état montrant la manière dont l'étape 5 de la Fig. 1 peut être mise en oeuvre;; la Fig. 5 est une description de processus détaillée montrant la manière dont l'étape 6 de la Fig. 1 peut être mis en oeuvre, et la Fig. 6 est un organigramme illustrant l'étape d'essai 9 de la Fig. 1 plus en détail. On se réfère à présent à la Fig. 1 qui présente un procédé de l'invention pour la conception et les essais d'un système électronique cible. Le procédé est désigné par la référence 1. Le procédé 1 peut être utilisé, par exemple, pour la conception et les essais de circuits intégrés sur mesure, sur demi-mesure ou mixtes. Un autre exemple est le développement d'un circuit intégré spécifique à des applications (ASIC) pour des commutateurs temporels et des structures de multiplexage temporel. De plus, le procédé 1 de l'invention peut être utilisé pour la conception et les essais de systèmes logiciels tels qu'un logiciel de commande de production pour opérer sur une plate-forme matérielle de systèmes ouverts. En variante, le procédé 1 peut être utilisé pour la conception et les essais de systèmes matériels et logiciels intégrés. L'étape 2 du procédé 1 implique la préparation d'une spécification technique pour le système électronique cible. Cette étape comprend - une description fonctionnelle du système cible. Cette description définit le nombre de flux de données parallèles et le nombre de tranches de temps par flux de données à traiter par le système cible; - une définition de l'interface de l'environnement dans lequel le système cible doit être installé. Cette définition comprend des définitions électroniques, de signaux et de formats de liaisons; - des descriptions du partage fonctionnel du système en termes de composants opératoires principaux, et - une définition des conditions exigées de performances du système cible.Débit de données, fréquence de fonctionnement, temps de latence des données, temps moyen avant défaillance (MTBF), taille des codes et efficacité sont des paramètres de performances typiques. On se référera à présent à la Fig. 2 où l'on a illustré un système de production, de conception et d'essai 10 pour mettre en oeuvre le procédé 1. Le système 10 comprend un pivot central 11 qui est connecté à un répéteur 13 par un gros câble métallique 12 du réseau. Le répéteur 13 est connecté à un réseau 14 de postes de travail de type SUN, PXTM. Le répéteur 13 est également connecté à un réseau 15 de microordinateurs. Un pont 16 connecte le répéteur 13 à un répéteur 17 qui est connecté à un groupe de mini-ordinateurs 18. Un gros câble métallique 20 connecte le pivot central 11 à un commutateur 21 qui, à son tour, est connecté à un répéteur 23 par un câble métallique mince 22. Le répéteur 23 est connecté à trois réseaux, à savoir un réseau de postes de travail 24, un réseau de postes de travail 25 et un réseau de micro-ordinateurs 26. Les postes de travail 24 sont également du type SUN PXTM, tandis que les postes de travail 25 sont du type SUN Sparc-IDTM. Un gros câble métallique 30 connecte le pivot central 11 à un commutateur 31 qui est, à son tour, connecté à un répéteur 33 par un câble métallique mince 32. Le répéteur 33 est également connecté à trois réseaux, à savoir un réseau de postes de travail 34, un réseau de micro-ordinateurs 35 et un réseau de postes de travail 36.Les postes de travail du réseau 34 sont de type SUN PXTM, tandis que les postes de travail 36 du réseau sont du type HP/APOLLOTM. Des dispositifs d'essai supplémentaires sont connectés dans le système 10 et ils seront décrits plus en détail plus loin. Les spécifications techniques qui sont générées dans l'étape 2 du procédé 1 le sont sur différents postes de travail du système 10; cependant, ces postes de travail ont des interfaces similaires et sont reliés par un code de système cible commun. Le fait que différents postes de travail soient utilisés et qu'il y ait un traitement distribué en général pour la conception et les essais du système cible permet à de nombreuses personnes différentes de travailler sur un seul projet et offre un grand degré de souplesse.Un traitement parallèle est également permis lorsqu'il y a une exigence de traitement très élevée, notamment dans certaines des opérations d'essai. Ceci est décrit plus en détail ci après. Un aspect important du système de production 10 est que l'on utilise une structure de fichiers commune avec des catégories séparées de données, notamment des données utilisateurs, des données de produits et des données d'outils automatiques. Cela permet une identification aisée et correcte des différentes catégories de données de produits et, à l'intérieur de ces catégories, une identification claire des composants. Cela permet un accès aisé de tous les postes de travail aux informations de projets concernées. Un autre aspect du système 10 est que le pivot central 11 est programmé pour contrôler en continu l'interconnexion des dispositifs du système 10 et pour régir l'accès de tous les dispositifs aux données et programmes autorisés. Cette particularité permet une reconfiguration du système 10 de manière souple selon les exigences de la production. Après génération des spécifications techniques, diverses tâches de conception sont exécutées et sont indiquées par les étapes 3 à 7 sur la Fig. 1. Ces étapes sont représentées comme étant exécutées en série, mais, comme cela ressort clairemcnt de la configuration du système 10, elles peuvent être exécutées en parallèle dans différents postes de travail. L'étape 3 comprend l'analyse des flux de données suivie de l'analyse de synchronisation dans l'étape 4. Le résultat de cette analyse est représenté sur la Fig. 3. Elle est effectuée automatiquement par un programme d'analyse de flux de données chargé dans l'un des postes de travail et fournit des informations quant à la synchronisation relative des signaux d'horloge, de lecture, d'écriture, d'adresse et de divers signaux de données.Plus en détail, l'analyse est effectuée en fonction de retards de propagation cumulatifs, d'exigences de synchronisation d'entrée d'éléments d'horloge et de disruptions opérationnelles provoquées par des imperfections éventuelles du système d'horloge. Un autre facteur important est le procédé de raccordement pour garantir des transferts de données corrects sur les systèmes cibles multihorloge. L'étape 5 implique une analyse de commande/transition d'état et une sortie d'analyse typique est représentée sur la Fig. 4. Ce schéma montre le moment auquel le circuit intégré cible est inactif et les moments auxquels il attend des accusés de réception, de nouvelles connexions doivent être réalisées et des signaux d'alarme doivent être transmis. L'étape 6 implique la génération de descriptions détaillées du procédé, également en utilisant le fonctionnement automatique d'un poste de travail sélectionné et configuré par le pivot central 11. La description générée définit des entrées, la manière dont des messages sont créés au cours du traitement, la manière dont les connexions sont créées et supprimées et la manière dont les bus d'adresses sont sélectionnés. La Fig. S illustre une description de procédé particulière en format schématique. Enfin, dans l'étape 7, la taille et les performances du système cible sont automatiquement estimées en fonction des étapes d'analyse antérieures. Cette estimation comprend une analyse de la surface de silicium, le nombre de broches, la dissipation d'énergie estimée et le puits de chaleur nécessaire. Pour un système cible logiciel, le matériel requis pour exploiter le logiciel et les exigences des mémoires mortes et vives sont spécifiés. Dans l'étape 8 du procédé 1, un code est développé pour le système électronique cible. Lorsqu'il s'agit principalement de matériel, le code qui est développé est le microcode du circuit et lorsqu'il s'agit principalement de logiciel, c'est le code complet du système logiciel cible. Le code est généré de manière à optimiser le débit de données dans le système cible. Une particularité importante est le fait qu'il est déterminé en termes de cycle d'exécution de code et de temps de réponse, et la taille en termes d'espace de code dans une aire logique physique. Un important aspect de la génération de code est le fait que des personnes différentes travaillent sur la génération de différents aspects du code en utilisant différents postes de travail du système 10. Tous les postes de travail du système 10 ont un standard de codage commun définissant la manière dont le code est écrit. Cela assure la cohérence et la clarté de la fonction codée. Cela permet naturellement un échange aisé de personnel dans le projet ainsi qu'un soutien des employés. Il y a également un mécanisme commun pour définir des interfaces à l'intérieur du système 10 et connecter le code obtenu de plusieurs postes de travail. Le standard de codage restreint l'emploi d'un langage de programme donné aux constructions qui sont aisément comprises et communes entre les divers langages. Cela permet une migration du code parmi différents outils tels que différents compilateurs C et offre la possibilité de transférer aisément le code fonctionnel à différents compilateurs de langages. Un aspect très important de la génération de codes est que le critère de base pour l'optimisation est identifié comme étant le débit de données en fonction du temps de réponse ou du cycle d'exécution de code et la taille en termes de code (RAM/ROM) ou la surface logique physique de silicium.Les outils du système 10 sont programmés pour analyser automatiquement le code afin d'assurer une optimisation selon ces critères. Enfin, des tests sont exécutés dans l'étape 9 pour obtenir le produit fini du système cible. Les sous-étapes impliquées dans les tests sont illustrées sur la Fig. 6. Dans l'étape 71 du procédé 9, chaque sous-composant du système en cours de développement est identifié. Un aspect important est que chaque composant soit la plus petite unité opérationnelle du système cible. Dans le cas d'un logiciel, il peut s'agir de deux à quatre lignes de code exécutant un sous-programme simple. Dans le cas du matériel, il peut s'agir d'un ensemble de 500 portes logiques. Cette identification est effectuée par l'emploi d'une interaction utilisateur avec les outils d'analyse du système et, de manière partiellement automatique, par la façon dont les données se rapportant à des parties du système cible sont stockées sur le système de production 10. Dans l'étape 72, il y a une analyse d'historique automatique des tests pour chaque composant du système cible afin d'aider à développer un plan d'essai.Cette étape implique l'identification des composants les plus vulnérables du système. Par exemple, pour un type de système particulier, il peut s'avérer qu'un système de messagerie est la partie la plus vulnérable et que des essais particulièrement exhaustifs de ces composants sont nécessaires. L'étape d'analyse 72 est basée sur des données stockées relatives à des projets antérieurs. On a constaté que l'étape 72 entraînait de manière générale une identification des composants ayant des structures de synchronisation complexes, des domaines d'horloge multiples ou des contraintes de temps réel très rigoureuses. Dans l'étape 73, on effectue des tests sur les composants. Dans les deux cas, les instructions d'essai sont générées de manière aléatoire pour un essai complet des composants. Par exemple, pour un système cible constitué principalement d'un logiciel, chaque ligne d'un composant est exécutée au cours d'un test. Pour un système cible constitué principalement de matériel, la section de commande est identifiée et testée de manière complète. Dans l'étape 74, les divers composants sont interconnectés et un test au niveau du Système est effectué. La simulation est une partie importante de cette étape, en particulier, la simulation de l'environnement du système cible. Pour de tels tests, le plan du système de production 10 est très important, car divers postes de travail distribués peuvent effectuer des opérations de modélisation en vue de l'obtention d'un environnement d'ensemble du système cible. Pour réaliser de tels tests, des dispositifs matériels spécialisés offrant des instructions d'essai sont connectés directement au poste de travail qui modélise le système cible.Par ailleurs, ces dispositifs matériels (couramment dénommés "accélérateurs") peuvent être connectés directement à un poste de travail pour effectuer une simulation directe du système cible, le poste de travail fournissant une simulation des interfaces avec d'autres simulateurs. L'accélérateur que l'on utilise dans le système de production 10 a des performances de simulation typiques dans la région de 2 à 5 millions d'événements par seconde. Cependant, par connexion d'unités de traitement supplémentaires pour augmenter le parallélisme, on peut simuler jusqu'à 75 millions d'événements par seconde. On a constaté que la combinaison de dispositifs accélérateurs directement connectés et de l'environnement de postes de travail distribués offrait la fonctionnalité dans le système cible et la simulation de l'environnement nécessaires pour les tests. Un important aspect des essais de code, qu'il s'agisse d'un système cible principalement logiciel ou principalement matériel, est le fait qu'une certaine partie du code du système cible comporte des codes d'essai intégrés pour fournir des sorties de statut pour différentes étapes du traitement. Dans l'étape 81, le code est compilé et le compilateur efface automatiquement les codes d'essai pour fournir le code de produit final. Les étapes 76 à 78 incluse sont mises en oeuvre ensemble pour fournir un essai complet du système et elles sont suivies de l'étape 79 qui implique une analyse de couverture d'essai automatique et une rétroaction. L'un des postes de travail du système de production 10 est configuré pour contrôler automatiquement les divers postes de travail testant un système cible particulier et pour contrôler le niveau de couverture des essais. La couverture des essais est quantifiée par le pourcentage de code qui est exécuté, mesuré par un suivi automatique du code de source au cours de son exécution. En d'autres termes, le code de source est relié en continu au code machine en cours d'exécution. Du fait qu'un matériel est simulé, la même technique s'applique à la conception et aux essais de circuits intégrés.Un signal de rétroaction est fourni à l'étape 79, formant la base de l'étape de décision 80 dans laquelle d'autres essais du système peuvent être effectués ou un essai peut être considéré comme terminé. Les signaux de rétroaction de couverture d'essai peuvent prendre la forme de graphes indiquant les composants du système qui ont été moins largement testés. On a constaté que le procédé de l'invention permettait de concevoir et de tester de manière souple des systèmes électroniques et donc des systèmes cibles que l'on peut concevoir et tester de manière efficace, qu'il s'agisse de systèmes principalement matériels ou principalement logiciels, ou d'une combinaison. La manière dont le système de production 10 est élaboré aide grandement à obtenir cette souplesse. Invention n'est pas limitée aux formes de réalisation décrites cidessus, mais peut être modifiée en structure et en détail. REVENDICATIONS: 1. Procédé de conception et d'essai de systèmes électroniques cibles, le procédé étant exécuté par un système de production comportant des postes de travail connectés selon un agencement de réseau distribué, le procédé comprenant les étapes suivantes un pivot central du système de production contrôlant les interfaces des postes de travail et régissant l'accès de tous les postes de travail à des programmes et des données requis; les postes de travail générant des spécifications techniques définissant les aspects suivants du système électronique cible aspects fonctionnels du système comprenant le nombre de flux de données parallèles; signalisation des formats pour les interfaces;; partage fonctionnel en composants d'exploitation principaux, et conditions de performances exigées en termes de débit de données, de fréquence de fonctionnement, de critères de défaillance et de paramètres de code, on effectue une analyse automatique des flux de données; on effectue une analyse de synchronisation automatique en fonction des retards de propagation cumulatifs et des exigences de synchronisation d'entrée; on effectue une analyse de transition d'état et de commande; on effectue une analyse détaillée du procédé; on effectue des estimations de taille et de performances sur la base des données des spécifications, lesdites estimations comprenant la taille physique des semi-conducteurs et les capacités des mémoires logiques;; on développe un code de manière distribuée dans différents postes de travail du système de production, le code étant optimisé automatiquement selon le débit de données en fonction du temps de réponse ou du cycle d'exécution de code et des estimations de taille, et on teste le système qui est développé en simulant les performances du matériel et en simulant des systèmes électroniques qui doivent être connectés au système cible en fonctionnement, la simulation étant réaliste des simulateurs parallèles à grande vitesse connectés directement aux postes de travail du système de production et par des postes de travail distribués à l'intérieur du système, délivrant des signaux de simulation via des câbles du réseau du système de production. 2. Procédé selon la revendication 1, dans lequel les tests du système cible comprennent les étapes d'identification des composants opératoires les plus petits du système, l'exécution de l'analyse automatique de l'historique des tests des composants et ensuite la réalisation des tests des composants par génération aléatoire d'instructions d'essai. 3. Procédé selon la revendication 2, dans lequel l'étape d'analyse de l'historique des tests comprend l'étape d'identification des composants ayant des structures de synchronisation complexes. 4. Procédé selon la revendication 3, dans lequel les tests comprennent les autres étapes d'interconnexion des composants du système cible suivies de tests au niveau du système dans lesquels la simulation du système cible ou de systèmes dans l'environnement opératoire sont simulés. 5. Procédé selon la revendication 4, dans lequel un poste de travail du système de production offre une rétroaction de couverture d'essai automatique en contrôlant en continu la couverture de tous les tests au niveau des composants et au niveau du système. 6. Procédé selon la revendication 5, dans lequel la couverture des tests est quantifiée par un suivi automatique du code de source lorsque le code machine associé est en cours d'exécution. 7. Procédé selon la revendication 6, dans lequel les essais au niveau du système peuvent être répétés ou augmentés en fonction de la rétroaction de la couverture d'essai automatique. 8. Procédé selon l'une quelconque des revendications précédentes, dans lequel des tests sont mis en oeuvre par inclusion d'un code d'essai à l'intérieur du code du système cible, ledit code d'essai étant effacé lors de la compilation du code. 9. Système cible produit par un procédé selon l'une quelconque des revendications précédentes.