Couverture ElectroniqueS n°127

Ce sont les annonces des organismes Spirit, pour la manipulation des blocs IP au niveau des transactions, et OCSI, pour le standard TLM 2.0, qui ont marqué l'édition 2008 de Date. Des annonces qui ont alimenté les conversations sur les progrès actuels de la conception au niveau système. L'annonce majeure de l'édition 2008 du salon Date, qui s'est tenu à Munich du 10 au 14 mars dernier, était à mettre à l'actif de Magma et de son environnement Titan dédié à la conception de circuits mixtes (Electronique n° 190, p. 14). Ce n'est pas un hasard si la société avait choisi cette manifestation comme caisse de résonance, car c'est en Europe que l'on trouve le plus fort contingent de concepteurs de circuits analogiques, une cible d'utilisateurs clairement visée par Magma, à moyen terme. L'autre spécificité de l'Europe est le nombre d'initiatives et de compétences dans tout ce qui touche à la conception au niveau système (ou ESL, Elecronic system level). C'est donc tout naturellement que l'organisme OSCI (Open SystemC initiative) et le consortium Spirit ont profité de l'occasion pour annoncer les avancées respectives de leurs travaux.Du côté de l'OSCI, ce sont les retours des utilisateurs concernant la seconde révision du standard TLM 2.0 (Transaction level modeling), rendus publics fin 2008, qui ont été présentés. Une partie de ces remarques devrait être intégrée à la version finale qui sera publiée en juin prochain. L'avènement de ce standard était attendu, car la spécification TLM 1.0 ne portait que sur les API pour les communications au niveau des transactions, entre blocs IP, sans en préciser le contenu. Bien que cette brique de base soit essentielle, elle ne règle en rien les problèmes d'interopérabilité entre blocs IP pour la gestion des communications à l'aide de transactions. Cette version 2.0 décrit, cette fois-ci, le contenu des transactions, c'est-à-dire la structure des données nécessaires aux opérations de transmission d'adresses et de données. Ainsi, si ce standard est accepté et utilisé par la communauté, il devrait être plus aisé d'échanger des modèles d'IP au niveau transaction au sein d'un flot de conception, et aussi d'obtenir une meilleure interopérabilité entre outils de CAO.D'un point de vue technique, cette seconde version du standard TLM 2.0, discutée lors de Date, intègre un style de modélisation dit PV (Programmer view), donc sans références temporelles, un style dit LT (Loosely timed), plutôt dédié aux programmeurs logiciels et qui offre la possibilité de spécifier des points de timing à différents endroits du code, et enfin un mode dit AT (Approximed time) avec lequel on peut bâtir des modèles comportementaux grâce à un contrôle temporel plus fin (codage du début et de la fin de requêtes et de leurs réponses). Cette approche, nouvelle par rapport aux premières versions du TLM 2.0, devrait permettre, d'une part, de mixer plusieurs modèles dans une seule simulation et, d'autre part, de dériver d'un type de modèle à un autre plus facilement qu'avec les représentations PV et PV + T (Programmer view + Timing) initialement prévues.Dans le même temps, le Consortium Spirit, dont le travail porte sur la standardisation de la description des blocs IP (la manière dont ils « montrent » leurs caractéristiques vers l'extérieur), dévoilait la version 1.4 de la spécification IP-XACT. Basée sur le métalangage XML, cette version, qui porte sur une description de haut niveau des IP, était très attendue : elle a pris plus d'un an de retard par rapport au calendrier initial. Car c'est en 2006 que le Consortium Spirit avait délivré la première version de ses spécifications pour la description d'un bloc IP, mais au niveau RTL, c'est-à-dire centrée sur l'implantation, à un stade où les décisions sur l'architecture matérielle sont figées. Il a donc fallu attendre deux ans pour voir apparaître la version au niveau système, qui intéresse un public beaucoup plus vaste. Une des raisons avancées pour ce retard par les membres du consortium est qu'il fallait s'aligner sur les travaux de l'OSCI concernant les modèles transactionnels. En effet, le standard IP-XACT supporte la modélisation au niveau transaction et suit le standard TLM 2.0 défini par l'OSCI.Enfin, troisième annonce liée à la conception au niveau système, l'OCP-IP (Open core protocol international partnership), qui travaille sur la standardisation d'une interface entre blocs IP issus de différents fournisseurs (l'interface OCP), annonçait une initiative concernant une interface de débogage dédiée en particulier aux plates-formes de prototypage virtuelle (des sociétés comme CoWare, Vast, Virtio, récemment rachetée par Synopsys, ou Virtutech proposent de telles approches). Cette interface de connexion, conforme au bus standardisé OCP, se présente sous la forme d'un port OCP optionnel qui définit diverses couches de fonctionnalités pour répondre aux besoins de débogage et d'analyse de c&oelig;urs de processeurs, ou de systèmes multic&oelig;urs intégrés au sein de plates-formes virtuelles.On le voit, à travers ces annonces, le concept de programmation au niveau système revêt des aspects multiformes et avance relativement lentement, par touches successives. Car l'adoption de cette approche ne va pas de soi. Par exemple, pour l'instant, les fournisseurs de blocs IP qui délivrent leurs produits avec une description conforme à la norme IP-XACT sont encore une minorité. De même, l'utilisation de plates-formes virtuelles et l'adoption de modes de programmation au niveau transaction sont loin d'être une généralité. Enfin, concernant SystemC, son emploi pour la programmation au niveau système fait encore débat.Malgré ces difficultés, les sociétés qui appartiennent à la galaxie ESL et qui délivrent des produits se portent bien. C'est le cas, par exemple, du français CoFluent, qui, sur le salon, présentait l'évolution de son produit CoFluent Studio version 2.2, dédié à l'exploration d'architecture et à l'analyse de performances d'un système, avant d'entrer dans les détails d'implantations déjà bel et bien présentes au sein des plates-formes de prototypage virtuelle. Dans cette version, l'outil est capable de réaliser une gestion dynamique de fonctions au sein d'un modèle, ce qui permet, entre autres, de modéliser des cas d'utilisation multiples, qui peuvent être activés et arrêtés selon divers scénarios. Pour y parvenir, la société va au-delà des possibilités actuelles offertes par le langage SystemC, afin de représenter le comportement dynamique des threads et process couramment rencontrés dans les systèmes électroniques. Ces avancées ouvrent la porte à la modélisation à haut niveau de systèmes de communication sans fil (avec les problématiques de commutation entre standards) et des systèmes de radio logicielle.CoFluent, créée en 2003 et qui a bouclé un tour de table d'investisseurs à hauteur de 2,6 M d'euros en 2007, annonçait dans le même temps une augmentation de 71 % de son chiffre d'affaires pour l'année passée.De son côté, la société américaine Synfora exposait son outil de synthèse algorithmique Pico Extreme, basé sur sa technologie Pico Express de création d'un sous-système matériel (un encodeur vidéo, par exemple), à partir d'un algorithme de haut niveau écrit en C. Avec Pico Extreme, Synfora va plus loin en proposant un système de compilation de haut niveau capable de prendre en compte un assemblage de blocs fonctionnels, eux-mêmes synthétisés à partir d'un algorithme en C. La technologie mise en &oelig;uvre ici offre en outre le support de la technologie de « clock gating » (déclenchements optimisés des signaux d'horloge) pour le système créé, la vérification statique (equivalent checking) entre le code C et le RTL créé, et la possibilité d'implanter une ou plusieurs interfaces OCP au sein du circuit. Avec Pico Extreme, Synfora montre ainsi que la synthèse algorithmique à partir de code C sans indication temporelle peut aller bien au-delà de la « simple » création de sous-blocs spécifiques, en donnant la possibilité de concevoir des sous-systèmes complexes, intégrant une arborescence de blocs fonctionnels dédiés.Pour finir, mentionnons la présence, sur le salon, de la jeune société britannique Axilica, émanation de l'université de Loughborough, qui présentait pour la première fois une solution de synthèse de haut niveau à partir de la description d'un circuit avec le langage UML, plus communément utilisé par les développeurs de logiciels que par les concepteurs de circuits. Sa solution, baptisée FalconML, assure une gestion du partionnement matériel/logiciel au niveau des spécifications écrites en UML et génère des fichiers en SystemC.

Sur le salon Date, la conception au niveau système montre des avancées

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

Sur le salon Date, la conception au niveau système montre des avancées

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure