NEWS 2010 DÉBUGGEUR, TRACE TEMPS-RÉEL, ANALYSEUR LOGIQUE Stephan Lauterbach lors de la conférence IP/ESC à Grenoble, France La communication, clé de la réussite La clé de notre réussite réside dans l établissement de relations fortes et durables avec nos partenaires et nos clients. En restant informé en priorité de leurs innovations techniques et en étant pro-actif sur leurs besoins, cela nous permet de leur fournir les outils de développement appropriés au moment où ils en ont besoin. Une communication réussie nécessite donc un engagement sans faille de notre part et cela continuera à être notre philosophie en 2010. Comités de standardisation En plus d un dialogue direct avec nos partenaires de l industrie embarquée, notre participation active dans les comités de standardisation représente pour nous à la fois une extraordinaire possibilité d échange d informations et de nouer de nouveaux contacts. Au fils des années nous avons intégré dans nos produits plusieurs résultats issus directement de ces comités. Dans ce bulletin d information, nous reviendrons plus en détail sur notre participation à ces comités. Rencontres lors des conférences Les rencontres effectuées lors des conférences sur les salons professionnels représentent des opportunités supplémentaires pour faire le point avec l ensemble de nos partenaires et clients, sur les exigences actuelles et futures du marché. Monsieur Stephan Lauterbach a participé, à titre d exemple, à la conférence IP/ESC à Grenoble en novembre 2009. Parrainée par la société ARM cette conférence s est intéressée sur le futur des technologies de débugge et de trace. Communiqué Lauterbach vient d ouvrir un nouveau bureau à Paris. Vous trouverez plus d information sur la dernière page de ce bulletin d information. SOMMAIRE Logiciel d installation pour Windows 7 2 Programmation de modules FLASH série 2 Débuggeur Intel Atom TM / Chargement différentiel 3 Nouvelles architectures supportées 4 Débugge des systèmes AMP et SMP 5 Nouveaux RTOS supportés 7 Activités de standardisation 8 High-Speed Serial pour QorIQ 9 cjtag/ieee 1149.7 10 Notre nouveau bureau à Paris 12
Nouveau logiciel d installation TRACE32 pour Windows 7 Afin de simplifier l installation des pilotes USB de TRACE32 sous Windows 7, la procédure d installation de TRACE32 a été révisée. Cela a été nécessaire car l installation de pilotes sous Windows 7 ne fonctionne qu à partir du serveur de mise à jour de Windows Windows Update Server ou bien d un pack de pilotes Driver Package préinstallé. Si vous ne disposez pas du nouveau DVD, vous pouvez télécharger le nouveau TRACE32 USB driver installer for Windows XP / Vista / 7 (32-bit and 64-bit) en cliquant sur le lien suivant: http:///faq/t32usb_setup.exe Avec le nouveau DVD TRACE32 de décembre 2009 (Build 20817 / Release), Lauterbach fournit le support officiel pour Windows 7. L utilisation ainsi que l aspect et la convivialité de TRACE32 ne changent pas sous Windows 7. Afin de mieux prendre en charge le modèle de sécurité de Windows et de simplifier les installations automatiques, les exécutables se trouvant sur le DVD de décembre 2009 possèdent désormais une signature. Ce type de signature est utilisé depuis 2007 sur les pilotes USB. Programmation des modules FLASH série Le support des FLASH série par TRACE32 inclut la programmation ainsi que la lecture et l affichage du contenu. Cet Affichage se fait sous la forme classique d un binaire hexa ce qui permet une vérification rapide des données programmées (voir figure 2). Fig. 1: FLASH série avec interface SPI Aujourd hui, de plus en plus de designs embarqués intègrent des FLASH série. Lauterbach a saisi cette tendance très rapidement et depuis mi-2009, les débuggeurs TRACE32 supportent la programmation des FLASH série. Nous prévoyons d élargir ce support de façon importante en 2010. Pour découvrir si TRACE32 inclut déjà votre FLASH série, veuillez consulter les listes suivantes sur notre site web: Supported NAND/SERIAL FLASH Controller http:///ylistnand.html Supported NOR/NAND/SERIAL FLASH Devices http:///ylist.html Leurs boitiers à faible brochage, à encombrement et consommation réduit, font des FLASH série une alternative bas coût par rapport au FLASH NOR/NAND. Le concept de design des FLASH série est très simple: Un contrôleur d interface est placé en amont d un FLASH NOR/NAND, permettant de programmer et de lire le composant à travers un bus SPI ou MMC (voir figure 1). Fig. 2: Affichage du contenu d un FLASH série 2 NEWS 2010
Débuggeur pour Microarchitecture Intel Atom Depuis Octobre 2009, Lauterbach offre les outils de développement pour processeurs Intel Atom TM. Le débugge Linux et Windows CE est déjà intégré. Dérivées supportées Intel LA-3776 (Atom) 230 330 D410 D510 N270 N280 N450 Z5XX D autres dérivées sont prévues. Chargement différentiel Atom 1 sec 20 sec version du programme, un tableau différentiel est crée. Celui ci contient l information nécessaire, sous forme compressée, permettant de mettre à jour le programme initial. MIPS32 MIPS64 Fig. 3: 2 sec 0,9 sec 4 sec 11 sec normal differential Le chargement différentiel permet de charger un fichier de 4 MBytes beaucoup plus rapidement Un cycle de débugge typique comprend les étapes suivantes: débugger le programme - localiser l erreur - corriger l erreur - recompiler le programme - recharger le programme. L outil de débugge doit effectuer chaque étape rapidement et sans temps additionnel. Cependant, le chargement de programmes de taille importante sur la RAM du système cible à travers une connexion JTAG lente peut engendrer des temps d attente importants. Le chargement différentiel constitue une solution à ce problème. Les temps de chargement peuvent être considérablement réduit, surtout si le programme nouvellement compilé ne diffère que légèrement du programme déjà chargé. Le concept de base du chargement différentiel est que le débuggeur préserve une copie du programme qui a été chargé sur la carte. Lors du chargement de la nouvelle Le débuggeur télécharge alors uniquement le tableau différentiel sur la carte. Étant donné que le tableau différentiel est généralement de 30 jusqu à 100 fois plus petit que le programme nouvellement compilé, le téléchargement se réduit considérablement. Un agent sur la carte décompresse les données différentielles et veille à ce que le nouveau programme soit enregistré correctement en mémoire. Les mesures sur la figure 3 ont été effectuées pour un fichier test pour lequel 1% du programme avait changé. 1. Architecture Atom CPU: Z530P Intel Fréquence du processeur: 1,6 GHz Fréquence JTAG: 20 Mhz Téléchargement normal: 204 KByte/s 2. Architecture MIPS32 CPU: BCM7325 Broadcom Fréquence du processeur: 167 MHz Fréquence JTAG: 20 MHz Téléchargement normal en Mode Turbo: 370 KByte/s 3. Architecture MIPS64 CPU: OCTEON Plus CN58XX de Cavium Fréquence du processeur: 950 MHz Fréquence JTAG: 50 MHz Téléchargement normal en Mode Turbo: 1 MByte/s 3
Nouvelles Architectures Supportées Nouvelles dérivées ARC LA-3750 (ARC) ARC 601 / ARC 630 ARM LA-7843 (Cortex-A / R) Cortex-A5 / Cortex-A5MPCore Cortex-A9 / Cortex-A9MPCore ATMEL Broadcom CEVA Cavium Cortus Energy Micro Freescale Infineon LA-7844 (Cortex-M) Cortex-M0 / Cortex-M1 LA-3779 (AVR32) AVR32 (Q2 / 2010) LA-7844 (Cortex-M) AT91SAM3U LA-7760 (MIPS32) BCM3380 BCM56xxx / 5836 BCM6362 / 6368 / 6550 BCM7401 / 7402 / 7403 LA-3711 (CEVA-X) CEVA-X1641 CEVA-XC (Q2/ 2010) LA-3774 (TeakLite-III) TeakLite-III LA-7761 (MIPS64) Octeon CN54xx / CN56xx Octeon CN63xx LA-7765 (ARM11) ECONA CNS3XXX LA-3778 (APS) APS-IP LA-7844 (Cortex-M) EFM32 LA-7736 (MCS12X) MC9S12G LA-7742 (ARM9) i.mx23 / i.mx25 LA-7732 (ColdFire) V1 ColdFire Core LA-7753 (MPC55xx)/ LA-7630 (NEXUS MPC55xx) MPC5643L LA-7764 (PowerQUICC III) QorIQ P1013 / P1022 / P4080 LA-7756 (TriCore) TC1167 / TC1197 / TC1337 TC1367 / TC1387 / TC1387ED TC1782 / TC1782ED Infineon (cont.) LSI Marvell MIPS NEC NXP LA-7759 (XC2000 / C166S V2) XC2000ED XC2200 / XC2300 Family XC2700 Family XE166 / XGOLD110 LA-7834 (StarCore) StarPro25xx / 26xx LA-7742 (ARM9) 88AP128 / 162 / 166 / 168 MV76100 / 78100 / 78200 LA-7765 (ARM11) 88SV581X-V6 LA-7843 (Cortex-A / R) 88SV581X-V7 LA-7762 (XScale) PXA93x / PXA950 LA-7760 (MIPS32) MIPS32 1004K / 1004KF MIPS32 1004K CPS MIPS32 M14K / M14Kc LA-3777 (78K0R) 78K0R / Fx3, 78K0R / Kx3 LA-7835 (V850) V850E2 / Px4 70F3502 / 70F3504 / 70F3506 LA-7844 (Cortex-M) LPC13xx LA-7742 (ARM9) LPC29xx ST Microelectronics LA-7753 (MPC55xx) / LA-7630 (NEXUS MPC55xx) SPC56EL60 LA-7844 (Cortex-M) STM32F105 / STM32F107 Tensilica Texas Instruments LA-3760 (Xtensa) Xtensa 8 LA-7847 (TMS320C28X) TMS320F28232 TMS320F28234 / F28235 LA-7838 (TMS320C6400) TMS320TC6424 TMS320TCI6482 / I6488 LA-7843 (Cortex-A / R) / LA-7838 (TMS320C6400) AM3505 / AM3517 (Sitara) OMAP4430 / OMAP4440 LA-7742 (ARM9) / LA-7841 (TMS320C6700) OMAP-L137 / OMAP-L138 4 NEWS 2010
Débugge des systèmes AMP et SMP Désormais, de nombreux processeurs multi-cœur peuvent être utilisés en mode AMP ou SMP. En fonction du mode d opération utilisé, différents concepts de débugge et de trace sont appliqués. Dans le paragraphe suivant nous allons expliquer, comment ces concepts peuvent être appliqués en utilisant TRACE32 sur des processeurs du type ARM Cortex- A9 MPCore. Concepts de débugge Nous avons constaté, suite à de nombreuses discussions avec nos clients, qu il y avait plusieurs interprétations de ces deux concepts: AMP asymmetrical multiprocessing SMP symmetrical multiprocessing C est pour cette raison que nous souhaitons expliquer, comment ces termes sont intégrés par Lauterbach et quels effets ont ils sur la configuration et l utilisation du débuggeur TRACE32. Le terme multiprocessing implique que plusieurs cœurs opèrent ensemble dans un système embarqué. Ce qui est crucial pour le débugge c est de comprendre comment les différentes tâches du système sont distribuées sur les divers cœurs. Concept de débugge pour les systèmes AMP contrôleurs standards (habituellement sur architecture RISC), des accélérateurs spécifiques sont choisis. Lors du débugge d un système AMP, une instance de TRACE32 est démarrée pour chaque cœur (figure 4). Il y a deux raisons pour cela: 1. Un système AMP peut inclure différentes architectures. 2. Chaque processeur exécute une partie séparée de l application. Ce qui veut dire que la majorité des symboles et des informations de débugge sont assignées exclusivement au processeur correspondant. Cependant, et par le fait que les processeurs ne travaillent pas indépendamment l un de l autre mais exécutent bien les différentes tâches de l application ensemble et en parallèle, il doit être possible de démarrer et d arrêter tous les processeurs simultanément. C est la seule possibilité qui nous permet de tester l interaction entre les différents processeurs ainsi que de surveiller et de contrôler toute l application. Il existe plusieurs techniques pour démarrer et arrêter tous les processeurs de façon synchrone. Idéalement, l architecture multi-cœur intègre cette fonctionnalité grâce à une logique de synchronisation interne. Si cette logique n est pas disponible, TRACE32 se charge du processus de synchronisation. Un algorithme spécial calcule la séquence de commandes JTAG permettant de contrôler tous les processeurs aussi synchrone que possible. Dans les systèmes AMP, chaque cœur a une ou plusieurs tâches prédéfinies. De quelle manière ces tâches sont distribuées est déterminé lors de la phase du design du système. Il est assez fréquent qu en complément des Fig. 4: Lors du débugge d un système AMP, une instance de TRACE32 est démarrée pour chaque cœur. Fig. 5: Lors du débugge d un système SMP, une seule instance de TRACE32 est démarrée pour tous les cœurs. 5
Concept de débugge pour les systèmes SMP Contrairement aux systèmes AMP, où l exécution des tâches est attribuée de manière prédéfinie, les systèmes SMP sont plus flexibles. L attribution ne se fait plus lors de la conception du système mais elle est gérée par le système d exploitation SMP. Tous les cœurs doivent être du même type pour que les tâches puissent être librement exécutées sur n importe quel processeur. L attribution des tâches s effectue dynamiquement selon l état actuel du système. Une unité de tâches qui peut être attribuée par le système d exploitation est désignée par task ou thread. En termes simples, une task qui doit être traitée est assignée au processeur libre. Lors du débugge d un système SMP, seulement une instance de TRACE32 est démarrée. Tous les processeurs peuvent être contrôlés à partir de ce moment là (figure 5 sur la page précédente). Puisque le développeur est géneralement concerné par le débugge d une task spécifique, l interface utilisateur de TRACE32 visualise l état de tout le système du point de vue de cette task ou plutôt du point de vue du cœur sur lequel cette task s exécute à ce moment là. Bien sûr, l utilisateur peut basculer vers d autres tasks / d autres cœurs à tout moment. TRACE32 adopte une fonction similaire à celle du système d exploitation SMP en organisant le débugge de tous les processeurs sans que le développeur ne se préoccupe des détails du système SMP. Si par exemple l utilisateur positionne un point d arrêt, TRACE32 assure que ce point d arrêt soit placé sur tous les processeurs. Débugger des systèmes SMP avec TRACE32 est simple. Après qu une instance de TRACE32 ait été démarrée et configurée pour le débugge SMP, vous l utilisez comme si vous n aviez qu un seul processeur à débugger. Concepts de Trace TRACE32 analyse et affiche les informations de la trace de manières différentes selon qu elle ait été généré par un système AMP ou bien un système SMP. Pour les systèmes AMP, l analyse de la trace est effectuée indépendamment pour chaque processeur. En revanche, il est possible d analyser spécifiquement l information de la trace générée par un système SMP pour une task, un processeur ou bien pour le système entier, selon les besoins. Concept de Trace pour les systèmes AMP Débugger individuellement chaque processeurs d un système AMP nécessite d avoir des instances séparées de TRACE32. L information de trace est aussi affichée individuellement dans chaque interface utilisateur TRACE32. Les systèmes AMP peuvent être constitués de différents types de processeurs, donc différents protocoles de trace sont utilisés. Les informations de trace étant donc affichées dans l interface utilisateur correspondant, elles peuvent être décodées et analysées séparément. Pour tester l interaction entre les processeurs afin de localiser rapidement des erreurs complexes du sys- Ceci est nécessaire car lors du placement du point d arrêt, on ne sait pas exactement, quel processeur va exécuter le code correspondant. Si un processeur s arrête sur le point d arrêt, les autres sont aussi automatiquement suspendus. L affichage de TRACE32 bascule alors vers le processeur ou la task que le point d arrêt a interrompu. Si l utilisateur redémarre l application, tous les processeurs repartent ensemble. Fig. 6: Lors de la trace d un système AMP, les informations provenant de chaque processeur sont affichées dans des interfaces utilisateur séparées. Une synchronisation temporelle entre les interfaces utilisateur est possible. tème, il est possible d afficher des vues individuelles de la trace et d étudier leur relation en fonction du temps. Pour effectuer cette tâche, TRACE32- PowerTrace fournit une base de temps commune. Ceci permet au développeur de choisir une coordonnée temporelle dans la trace d un interface TRACE32 et de voir exactement quelle commande a été exécutée par un autre processeur au même instant (voir figure 6). 6 NEWS 2010
Fig. 8: L analyse de la trace montre quel processeur a exécuté les différentes sections du programme. Fig. 9: L analyse de la trace examine le système SMP dans son ensemble. Fig. 7: Lors de la trace d un système SMP, l information provenant de tous les processeurs est enregistrée dans une mémoire de trace commune. Concept de Trace pour les systèmes SMP Toutes les informations sur le déroulement du programme d un système SMP sont enregistrées dans une mémoire de trace commune (figure 7). Un des avantages de TRACE32 est qu il permet différentes visualisations de ces informations. Pour localiser une erreur dans une tâche ou bien pour effectuer des mesures des temps d exécutions d une tâche, l information de la trace peut être affichée individuellement pour cette tâche. Si vous avez besoin d informations du type quel processeur a exécuté ma tâche? ou bien quels sont les taux de charge de mes processeurs?, il peut être utile d afficher l information de la trace de tous les processeurs en même temps. La figure 8 montre un exemple de ce mode d affichage. Le numéro affiché (0 ou 1) indique par quel processeur les différentes parties du programme ont été exécutées. Dans le but d examiner le système SMP dans son ensemble, il n est pas nécessairement intéressant de savoir quel processeur a exécuté quelle tâche ou section de programme. TRACE32 offre aussi un affichage de la trace pour ce type d approche (voir figure 9). En 2010, Lauterbach va continuer d améliorer l évaluation et la présentation des données de trace pour les systèmes SMP. Ceci va inclure de nouvelles fonctions d analyse basées sur le retour d expérience de nos clients ainsi que de nouveaux concepts actuellement en développement. Nouveaux RTOS supportés Nouveaux RTOS FAMOS pour ARM Linux pour Atom SMP Linux pour MIPS64 OKL4 pour ARM disponible disponible disponible disponible Mise à jour de nouvelles versions RTOS LynxOS 5.0 pour PowerPC MQX 3.x pour ColdFire OSE 5.4 QNX 6.4 VxWorks 6.4 µc/os-iii OS21 pour ARM disponible SMP Symbian OS pour ARM disponible Windows CE pour Atom Q1/2010 Extensions Support des partitions et de la MPU/MMU pour µc/os-ii Points d arrêt paginés pour Symbian OS Support RTP pour VxWorks 7
Activités de standardisation AUTomotive Open System ARchitecture Beaucoup de nos clients souhaiteraient avoir un plus haut niveau de standardisation des technologies de débugge et de trace. Afin d avoir un rôle actif dans le développement des standards appropriés, Lauterbach a participé durant plusieurs années à divers comités internationaux de standardisation. Notre participation active nous permet d inclure dans TRACE32 un support complet des nouveaux standards directement après leur approbation officielle. Le standard ORTI Un des premiers standards au développement duquel Lauterbach a activement participé est le standard ORTI. Ce standard définit un langage qui décrit la structure et l organisation de la mémoire des objets du système d exploitation OSEK permettant un débugge RTOS- Aware. Ces informations sont par la suite enregistrées dans un fichier. Ce standard a été développé au sein du consortium AUTOSAR et a été appliqué depuis 2003 par tous les fournisseurs du système d exploitation OSEK entre autres ETAS Group et Vector. L utilisation d un fichier ORTI peut être décrite de la façon suivante: un utilitaire de configuration RTOS (OSEK System Builder) génère le fichier ORTI à partir de la configuration utilisateur d un système d exploitation OSEK. Ce fichier est alors chargé par le débuggeur TRACE32 pour assurer un débugge OSEK-Aware (voir figure 10). www.autosar.org Groupe de travail OSEK/VDX Debug Interface Working Group Standard OSEK Run Time Interface Version 2.2, Novembre 2005 http://portal.osek-vdx.org/files/pdf/specs/orti-a-22.pdf http://portal.osek-vdx.org/files/pdf/specs/orti-b-22.pdf TRACE32 peut alors offrir au développeur les fonctions suivantes (a condition que l utilitaire de configuration du système OSEK ait enregistré les informations nécessaires dans le fichier ORTI): Affichage intuitif des ressources OSEK (la figure 11 montre la liste des alarmes à titre d exemple) Des points d arrêt spécifiques aux tâches Analyse de la pile de chaque tâche Affichage du contexte de chaque tâche Analyse des temps d exécution des tâches (voir fig. 13) Analyse des temps d exécution des services Fig. 11: La liste des alarmes d un système d exploitation OSEK affichée par TRACE32 Le standard NEXUS Retour en 1998, dans le cadre du forum NEXUS 5001, un premier pas avait été entrepris dans le but de normaliser les interfaces de débugge et de trace pour les processeurs embarqués. Le standard NEXUS a été approuvé en 2003. Ce standard inclut: Fig. 10: TRACE32 charge le fichier ORTI généré par le OSEK System Builder et assure par la suite un débugge OSEK-Aware. une interface JTAG, généralement IEEE1149.1 un mécanisme qui permet au débuggeur de lire et d écrire dans la mémoire, même si le processeur est en train d exécuter le programme un protocole de trace basé sur les messages (trace de programme et de données) débugge et trace des processeurs multi-cœur une couche matérielle standard des connecteurs standards NEXUS 8 NEWS 2010
Fig. 12: Message NEXUS enregistrant le basculement des tâches Fig. 13: Analyse des temps d exécution d un système d exploitation OSEK Fig. 14: TRACE32 High-Speed Serial Trace pour QorIQ Lauterbach supporte le standard NEXUS depuis 2001 dans ces produits sur plusieurs architectures. Une des dernières et plus importantes familles de processeurs pour laquelle ce standard a été inclus est sur MPC55xx/ MPC56xx de Freescale et STMicroelectronics qui est largement utilisée dans l industrie automobile. Les figures 12 et 13 montrent comment le protocole de trace NEXUS est utilisé pour mesurer les temps d exécution des tâche du système OSEK. Puisque le standard NEXUS permet un haut niveau de liberté dans l implémentation, Lauterbach a entièrement révisé en 2008 le design de sa sonde NEXUS. Le nouveau design basé sur un FPGA est maintenant flexible et peut être adapté à toutes les nouvelles implémentations NEXUS. De nouvelles fonctions incluent une optimisation de l échantillonnage des signaux de trace ainsi que le nouveau protocole de JTAG IEEE1149.7. Vous pouvez trouver plus d informations sur l IEEE1149.7 en page 10. Le standard NEXUS de 2003 est actuellement en cours de révision. Bien que la nouvelle version du standard n ait pas encore été approuvée, elle est déjà utilisée par un certain nombre de processeurs de la famille MPC56xx. TRACE32 prend en compte depuis début 2010 le nouveau protocole NEXUS. Ce support est disponible via software-update. Nexus 5001 www.nexus5001.org Standard Standard pour une interface universelle de débugge des processeurs embarqués, Version 2, Décembre 03 http://www.nexus5001.org/st/ieee_isto_5001_2003.pdf Trace série pour QorIQ Lauterbach offre depuis début 2010 un nouveau produit, le High-Speed Serial Trace pour QorIQ. La technologie de trace pour QorIQ P4xxx se base sur un protocole NEXUS, une couche matérielle basée sur AURORA et un connecteur qui a été approuvé par un groupe de travail de l organisation Power.org. Le premier processeur qui supportera cette trace est le QorIQ P4080 de Freescale. Le P4080 intègre huit processeurs de l architecture Power e500mc pouvant être utilisés dans les deux mode SMP et AMP. Des configurations qui combinent des groupes de processeurs en mode SMP et AMP sont aussi possibles. Plus de détails sur le sujet débugger des système AMP et SMP en page 5. En comparaison des interfaces de trace parallèles, les interfaces de trace série possèdent comme avantages une réduction du nombre de broches grâce à la transmission série et un haut débit de données grâce à des signaux différentiels. Le large volume de données de trace produite nécessite naturellement une grande capacité de mémoire de trace. Celle ci est assurée par le PowerTrace II de Lauterbach qui dispose d une capacité de mémoire pouvant aller jusqu à 4 GBytes. La sonde de trace High-Speed Serial pour QorIQ est conçue pour un maximum de 4 canaux haut débit. Les débits suivants sont disponibles: 6,25 Gbit/s max par canal jusqu à 3 canaux 3,125 GBits/s max par canal jusqu à 4 canaux La capture des données de trace est réalisée via un système de connecteurs de l entreprise Samtec. Lauterbach fournit des adaptateurs pour les différentes variantes de ces connecteurs. 9
Power.org IEEE Standards Association www.power.org Groupe de travail Common Debug Interface Technical Subcommittee Standard Power.org Standard for Physical Connection for High-Speed Serial Trace, Juillet 2008 http://www.power.org/resources/downloads/ Power_CDI_Physical_Connection_for_HSST_ APPROVED_v1.0.pdf cjtag/ieee 1149.7 Connue sous le nom de cjtag (compact JTAG), l IEEE1149.7 ajourne le traditionnel standard JTAG IEEE1149.1 pour atteindre les besoins techniques actuels. Étant leader dans la fabrication de débuggeurs, Lauterbach s est fortement impliqué dans la définition de cette nouvelle interface de débugge deux broches. Selon l IEEE 1149.7, toute la communication entre le débuggeur et le processeur est assurée par les deux broches TCK et TMS. En comparaison avec la communication JTAG standard, les nouvelles fonctionnalités peuvent être décrites comme cela: IEEE1149.7 possède un connecteur à deux broches. Dans le composant, le contrôleur 1149.7 reconvertit la communication vers le protocole JTAG (voir figure 15). www.standards.ieee.org Groupe de travail: 1149.7 Standard Approbation officielle du standards prévu pour Q1/2010 Étant donné que le signal TMS est un signal unidirectionnel dans le protocole JTAG, Lauterbach a du adapter ses câbles de débugge pour supporter un TMS bidirectionnel: Tous les câbles de débugge des architectures ARM/ Cortex ont déjà été adaptés en début 2008 (Debug Cable v4). Le câble de débugge pour l architecture MPC55xx est livré depuis Septembre 2009 dans une version actualisée (câble de debug OnCE avec JTAG série). Les nouveaux câbles vont bien sûr continuer à supporter le protocole JTAG standard. TRACE32 a testé avec succès le dialogue cjtag en Octobre 2009. Cependant, elle ne pourra être finalisée que lorsque le standard 1149.7 sera officiellement approuvé. En termes simples, l IEEE1149.7 est une version série du protocole JTAG (voir figure 16). Fig. 16: Diagramme simplifié du protocole 1149.7 Fig. 15: Le protocole IEEE1149.7 reconvertit la communication vers le protocole JTAG. 10 NEWS 2010
Open SoC Design Platform for Reuse and Integration of IPs www.sprint-project.net Groupe de travail: Débugge et analyse Standard: Multi-Core Debug API v1.0, Avril 2009 http:///sprint_mcd_api_v1_0.zip L API MCD L API MCD définit une interface C pour le débugge de systèmes multi-cœur. Elle ne fait pas la différence entre un système cible multi-coeur matériel réel ou bien une simulation purement logicielle. Actuellement, Lauterbach distingue deux utilisations de L API MCD: 1. L API MCD peut être utilisée comme une interface standard pour TRACE32 et remplacera l interface existante (TRACE32 Remote API). La MCD-API est appelée dans ce cas MCD-Remote-API. 2. L API MCD peut être utilisée comme une interface standard pour les prototypes virtuels 1. Mise à jour de la TRACE32 Remote API L interface de programmation TARCE32 Remote API permet à une application externe de piloter TRACE32. Cette interface aide par exemple à automatiser les tests de non-régression. Au fil des années, la Remote API a été sujet à un développement continu piloté par de nombreux nouveaux besoins émanant de nos clients. Actuellement, le nombre croissant de systèmes multi-cœur exige beaucoup de modifications compréhensibles. Au lieu de modifier la Remote API, Lauterbach a pris la Fig. 18: Le débugge des prototypes virtuels via l API MCD. décision de reconstruire son interface de programmation en se basant sur le standard MCD. Il est probable que l API MCD n offre pas toutes les fonctionnalités de TRACE32. Dans ce cas, des fonctions spécifiques à TRACE32 vont y être intégrées (figure 17) La nouvelle version de la MCD Remote API est prévue pour la mi-2010. Cela implique que tous les développements sur l ancienne version Remote API vont être arrêtés. Pour nos clients cela veut dire, que malgré le fait que nous allons continuer le support de la Remote API, aucune nouvelle fonctionnalité ne sera plus implémentée. 2. Interface standard pour les prototypes virtuels Depuis les cinq dernières années, TRACE32 a été capable de débugger les prototypes virtuels. Les fabricants de prototypes virtuels fournissent généralement leurs propres API. Toutefois, l utilisation de l API MCD comme interface standard entre le débuggeur et les prototypes virtuels a les avantages suivants: Adaptation rapide aux nouveaux prototypes virtuels Une large étendue de fonctions performantes et testées Fig. 17: TRACE32 peut être contrôlé par une application extérieure en utilisant la Remote API. 11
Notre nouveau bureau à Paris charge des démonstrations et du support technique puis par la suite comme responsable du support et des ventes avec la tâche de suivie des contrats et fidélisation des partenaires commerciaux. Cela au sein de plusieurs distributeurs d outils de développement embraqué et d outils de test et production en France. Cette expérience lui a permis d intégrer Lauterbach France en 2009. Fig. 19: Lauterbach S.A.R.L., Paris Fig. 20: Jean-Pierre Paradiso Lauterbach vient d ouvrir son nouveau bureau en France, situé prêt de Paris à Créteil (94) dans la zone Europarc, nous sommes désormais au cœur de l activité proche de Valeo. Notre nouvelle filiale nous permettra de pouvoir répondre à l attente de nos clients. L une des premières missions que Lauterbach France devra remplir est la mise en place d un support technique de très haute qualité qui va de pair avec le niveau atteint aujourd hui sur les outils Lauterbach. Votre contact en France Monsieur Jean-Pierre Paradiso est issu d une formation BTS électronique, qu il a complété par un diplôme d ingénieur informatique systèmes d information suivie au CNAM à Paris en cour du soir. Il a démarré sa carrière professionnelle en tant qu ingénieur d application en CONTACT Lauterbach S.A.R.L. Jean-Pierre Paradiso 135 Chemin des Bassins Europarc Le Hameau B 94000 Créteil, France téléphone + 33-1 49 56 20 30 téléfax + 33-1 49 56 20 39 jean-pierre.paradiso@lauterbach.com sales_fr@lauterbach.com support_fr@lauterbach.com FILIALES À TRAVERS LE MONDE INSCRIPTION BULLETIN D INFORMATION France Allemagne Grande-Bretagne Italie États-Unis Chine Japon Représentés par nos partenaires dans tous les autres pays Si vous souhaitez dorénavant recevoir notre bulletin d information par voie postale, veuillez nous envoyer vos coordonnées sur l adresse e-mail suivante. Une désinscription est possible à tout moment. info@lauterbach.com 12