Pour consultez cet article avec les schémas(.Pdf), cliquez ici.

Parmi les langages de programmation pour circuits intégrés, SystemVerilog est celui qui bénéficie de l'héritage le plus riche. En effet, tenant compte de l'expérience de milliers de conception en Verilog et VHDL et de plusieurs années de support de la part des industriels, SystemVerilog innove sur de nombreux points par rapport à ses devanciers. Il incorpore par exemple des mécanismes de génération de test, autrefois propriétaires et naguère réservés aux langages de définition de fichiers de test (les « test-benchs » ) comme Vera ou Temporal. Il fait un bond en avant en incluant les capacités de détection de réponses propres aux assertions des langages Temporal OVA et PSL. De nouvelles instructions d'agrégation de données, telles que « struct » et ses semblables, rendent le débogage bien plus efficace. Il apporte enfin une abstraction accrue du niveau de la conception, la notion d'encapsulation des données, une syntaxe et une sémantique modernisées et de nombreux mécanismes améliorant la productivité.

Ainsi, la modélisation abstraite et les types étendus du langage SystemVerilog ouvrent la voie à la conception comportementale de niveau système, faisant passer la conception HDL (Hardware design langage) du niveau de l'implémentation RTL à celui de l'algorithmique. Cette élévation du niveau d'abstraction se traduit notamment par une productivité plus grande pour le concepteur, tout en n'ayant qu'un effet minimal sur l'efficacité de la synthèse. Par ailleurs, la modélisation au niveau transactions, introduite dans SystemVerilog, permet non seulement de mieux adapter le débogueur à la taille de la conception, grâce au regroupement et à l'organisation des données, mais également de mieux comprendre cette conception grâce à une représentation abstraite et à une visualisation claire de celle-ci.

SystemVerilog ajoute par ailleurs une multitude d'instructions au sein des blocs de processus qui rendent l'inférence des intentions du programmeur plus précise. Une avancée utile pour les outils externes à la conception, notamment les débogueurs, qui doivent présenter les données de conception de manière efficace. Pour ce faire, la variété des abstractions proposées par SystemVerilog rend l'organisation des données, leur exploration et leur présentation plus abordables pour les utilisateurs.

La séparation du comportement et de la communication est une autre philosophie clé de ce nouveau langage. Il autorise des gains importants en termes de productivité grâce à la possibilité de réutiliser le design, que ce soit au sein d'une implémentation, à travers plusieurs versions ciblant divers marchés avec différents compromis ou à travers les générations successives d'un même design.

Dans les pratiques courantes de conception, on observe souvent que les ingénieurs conservent scrupuleusement des traces de ce qui marche et de ce qui ne marche pas. Ainsi, les conceptions en Verilog ou VHDL ont accumulé au fil des ans une longue liste de souhaits de la part des utilisateurs sur ce qu'il faut ou ne faut pas faire, sur les corrections, les fonctions qui manquent, les opérations redondantes, etc. La communauté des développeurs a oeuvré pour répondre à ces desideratas afin de les inclure au sein du langage SystemVerilog. Grâce à cet apport, SystemVerilog peut être considéré comme un Verilog perfectionné car il est bâti au-dessus de Verilog-2001.

Dans le même temps, la productivité et la lisibilité du langage ont été améliorées grâce à l'ajout de plusieurs instructions issues du langage C et du monde logiciel. Ces constructions incluent notamment les instructions « typedef » , « enum » , et « struct » . « Typedef » permet la création et l'utilisation ultérieure de types redéfinis par le concepteur. « Enum » facilite l'encodage de valeurs et permet de manipuler des noms simples en lieu et place de ces valeurs. Quant à l'instruction « struct » , elle encapsule les données et permet de les déplacer en groupe de manière aisée et transparente. Ces nouvelles fonctions ont notamment pour avantage de faciliter grandement le débogage au cours de la conception (figure 1).

Un code Verilog mal écrit induit parfois des problèmes d'incohérence au moment des opérations de simulation ou de synthèse, ceci en raison de l'ambiguïté de la description. Un exemple frappant est fourni par l'instruction « always » utilisée dans Verilog pour modéliser de la logique combinatoire, de la logique à verrouillage (latched logic), de la logique séquentielle ou de la logique de test (figure 2). Les outils logiciels qui lisent ce code doivent alors inférer (c'est-à-dire deviner) quelle était l'intention de l'ingénieur concernant le type de matériel, en se basant sur le contenu de la procédure et sur son contexte. Ainsi, un simulateur traitera le bloc « always » (et sa sortie) comme une bascule à verrouillage (latch) parce que la liste de sensibilité est incomplète ; tandis qu'un outil de synthèse le traitera en tant que logique combinatoire, comme si la liste était complète avec le signal de sélection « sel » . Un débogueur comportemental pourrait, de son côté, analyser cette situation en considérant les consignes de synthèse. Il signalerait alors cette incohérence en marquant par exemple la sortie du bloc d'un commentaire « bascule non voulue » . En général, cependant, ces scénarios peuvent porter à confusion et, même en suivant des règles strictes, il arrive aux outils de mal interpréter l'intention du concepteur, que ce soit à cause d'un signal manquant dans la liste de sensibilité, d'un front montant non attendu ou même d'une affectation mal ordonnée.

Pour remédier à cette situation, SystemVerilog ajoute des instructions spéciales orientées matériel :

always_ff : pour modéliser la logique séquentielle ;

always_comb : pour modéliser la logique combinatoire ;

always_latch : pour modéliser la logique à verrouillage.

Ces instructions permettent de lever l'ambiguïté de l'intention et rendent la conception et la mise au point plus simples, en minimisant les pertes de temps passées en cycles inutiles d'interprétations et réinterprétations, avec des outils comme des compilateurs et des analyseurs de code capables de signaler immédiatement toute instruction mal utilisée. Ces nouvelles instructions permettent donc de clarifier un certain nombre de situations jusque-là ambiguës (figure 3).

Dans le même esprit, d'autres erreurs d'interprétation fréquentes pour les instructions décisionnelles sont les scénarios où les pragmas « full case » et « parallel case » des outils de synthèse créent des incohérences avec les simulateurs. Pour corriger ce point, SystemVerilog ajoute les mots-clés modificateurs de décision « unique » et « priority » , compréhensibles par les simulateurs et les synthétiseurs.

L'un des principaux apports du langage SystemVerilog est l'ajout de la notion d'interfaces, qui permet de grouper des interconnexions et d'encapsuler ainsi des blocs de communication. Les « interface containers » (les classes d'interfaces) sont très similaires aux « module containers » des langages de programmation logicielle. Elles peuvent contenir des déclarations de variables, de tâches et de fonctions partagées par tous les utilisateurs de l'interface, ainsi que des procédures de modélisation et des assertions de vérification. Quel est le but de ces interfaces ? En fait, en séparant le comportement de la communication, on isole les descriptions des fonctions de la communication et de la transmission de données. Ceci représente un bénéfice direct en termes de conception et de débogage grâce à une réduction drastique des duplications inutiles et sujettes à erreurs, comme les connexions aux nombreux ports identiques des modules dans le cas des bus (figure 4).

Un autre intérêt de cet isolement est de permettre de détailler progressivement les abstractions. En effet, il arrive souvent qu'un concepteur démarre son travail à partir d'une implémentation abstraite de la communication. Ou encore d'un schéma simple qui, plus tard, ne sera plus suffisant en ne permettant pas le respect des contraintes de latence et de bande passante. Ainsi avec, d'une part, ce principe de la séparation et, d'autre part, celui d'une modélisation abstraite pouvant être détaillée ou remplacée par des descriptions plus précises ou des schémas plus réels, la conception devient alors réutilisable et facile à maintenir au fur et à mesure de son avancement. Le concepteur peut par exemple apporter des modifications à la stratégie de communication au sein de l'interface elle-même, au lieu de toucher tous les modules aux alentours (figure 5). Cette idée, avec les méthodologies et outils qui l'accompagnent, a vu le jour il y a déjà quelques années (voir référence 2) et fait désormais partie des bonnes pratiques de conception système.

La notion d'abstraction et de progression dans le détail des communications est également au centre de la notion de vérification par composition : en effet, la vérification peut être partitionnée entre comportement et communication, du niveau d'abstraction le plus haut jusqu'aux blocs individuels. Ainsi, grâce aux interfaces, le débogage à annotations (utilisé par exemple dans l'outil Debussy de Novas Software) est extensible et devient un puissant moyen de suivi des communications. La visualisation ajoute un niveau d'abstraction, grâce auquel l'occurrence « interface » regroupe la multitude de fils en un seul objet à mettre à jour ou à passer aux blocs alentours (figure 6).

L'affinage progressif de la description des communications conduit à un concept d'abstraction de données très utile, celui des transactions. Il s'agit d'un foralisme permettant de décrire quelles données sont transférées entre différents éléments du design, et comment. Les transactions peuvent servir aux débogueurs pour gérer les masses de données générées et les présenter sous une forme compréhensible par l'utilisateur. Les formalismes de transactions peuvent varier. Cela va d'un simple marquage des données à une encapsulation complexe et détaillée d'un schéma de communication ou de transmission de données.

Pour modéliser les transactions, il est possible d'emprunter des concepts, des terminologies et des notations aux travaux de recherche déjà réalisés en matière de notations graphiques et de langages à métamodèles, comme l'UML. Par exemple, on peut considérer une transaction comme un véritable objet, qui peut être représenté et manipulé avec les données de conception dans les fenêtres de débogage (par exemple dans une fenêtre de visualisation de signaux). La transaction possédera alors un label permettant de la manipuler et un jeu d'attributs, qui pourront avoir des valeurs et des types et de nombreuses associations avec d'autres transactions. Ces dernières peuvent jouer différents rôles tels que parent/enfant, successeur/prédécesseur, etc. Les associations peuvent aussi avoir une multiplicité (de 1 à beaucoup) et prendre la forme de compositions ou agrégations (figure 7).

(*) Cet article est le premier volet de la description des principales avancées offertes par SystemVerilog. La seconde partie, portant sur le caractère orienté objet du langage, l'écriture des fichiers de test et le débogage à base d'assertions, sera publiée dans le prochain numéro de la revue.