Une m´ethode d’extraction d’information de programmes SystemC et son impl´ementation, PINAPA. Nous verrons en quoi SystemC est diff´erent des langages de programmation traditionnels et les cons´equences que cela entraˆıne sur la mani`ere d’´ecrire un analyseur de code SystemC. A notre connaissance, aucune des publications traitant de l’analyse de code SystemC ne suit une approche
´equivalente `a celle de PINAPA;
Une s´emantique ex´ecutable de SystemC et des constructions TLM avec un outil de traduction. La sor-tie de cet outil pourra ˆetre r´eutilis´ee dans d’autres contextes ;
Une fac¸on d’exprimer des propri´et´es sans langage d´edi´e en SystemC ;
Un formalisme interm´ediaire, HPIOM (Heterogeneous Parallel Input/Output Machines, ou machines d’entr´ees/sorties h´et´erog`enes), avec une boˆıte `a outils de transformations et d’optimisations. Cette repr´esentation interm´ediaire int´eresse d´ej`a d’autres projets du laboratoire et sera probablement r´eutilis´ee en tant que formalisme d’automates g´en´erique dans d’autres outils ;
Une connexion `a plusieurs outils de preuve, qui nous a permis de prouver des propri´et´es sur des plates-formes de petite taille, et a fourni un test de performance int´eressant entre les diff´erents outils de preuve.
L’outil LUSSYest encore au stade de prototype, certaines constructions SystemC ou C++ n’ont pas encore ´et´e prises en compte faute de temps, mais pourraient ˆetre ajout´ees sans r´eels probl`emes sur le plan th´eorique. En revanche, l’approche suivie pr´esente un certain nombre de limitations th´eorique plus difficiles
`a contourner :
L’extraction d’information de SystemC est un probl`eme difficile non seulement `a r´esoudre, mais aussi `a d´efinir dans le cas g´en´eral. Nous verrons en quoi, dans le cas d’un programme utilisant des structures de donn´ees dynamiques pour repr´esenter des objets SystemC, cela n’a pas r´eellement de sens de chercher `a savoir quel objet SystemC est repr´esent´e par une variable donn´ee. PINAPAs’affranchi d’un certain nombre de limitations pr´esents dans les outils similaires, mais ne peut pas faire le lien entre les variables du programme et les objets SystemC dans ce cas.
La structure de donn´eeHPIOM est limit´ee en expressivit´e. Nous avons dˆu faire des choix entre l’expres-sivit´e et les possibilit´es en terme de preuve formelle automatique de ce formalisme. Nous avons choisi un formalisme d’automates simples. La structure de contrˆole est fig´ee, la cr´eation dynamique de processus est impossible, et les variables de l’automate ne peuvent pas contenir de structures de donn´ees complexes. Si le programme source utilise des structures dynamiques, des appels de fonc-tion r´ecursifs, etc, la traducfonc-tion perdra n´ecessairement de l’informafonc-tion. Cette perte d’informafonc-tion est une approximation qui conserve les propri´et´es de sˆuret´e, sauf dans le cas des appels de fonction avec effets de bord.
La traduction de SystemC versHPIOM fait ´egalement, de mani`ere optionnelle, un certain nombre d’ap-proximations pr´eservant les propri´et´es de sˆuret´e qui am´eliorent les performances de l’outil de preuve.
Certaines propri´et´es ne peuvent ˆetre prouv´ees lorsque ces approximations sont utilis´ees.
L’explosion d’´etats dans l’outil de preuve est en fait la principale limitation. Sur des plates-formes de taille moyenne, comme notre ´etude de cas sur la plate-forme EASY, l’outil LUSSYlui-mˆeme est capable de faire la traduction compl`ete, mais les outils de preuves ne sont pas capables de prouver des propri´et´es sur le code g´en´er´e.
1.6 Plan du document
Ce document se divise en trois parties :
I. Une approche pour la v´erification des syst`emes sur puce : Cette premi`ere partie donne une vision g´en´erale de la notion de mod`eles transactionnels, et des approches formelles possibles pour leur v´erification. Le chapitre2,«Mod´elisation de syst`emes sur puces au niveau transactionnel en Sys-temC » introduit le niveau transactionnel, et l’impl´ementation en SystemC `a laquelle nous nous int´eressons par la suite. Le chapitre3,«Vue d’ensemble deLUSSY: une boˆıte `a outils pour l’ana-lyse de syst`emes sur puce au niveau transactionnel»pr´esente notre approche de v´erification et les
Matthieu Moy Ph.D Thesis 17/190
Chapitre 1. Introduction
approches alternatives. On y trouve ´egalement une pr´esentation rapide de l’outil LUSSY, de ses composants et de la mani`ere dont ils s’articulent.
II. Extraction automatique de la s´emantique de mod`eles SystemC : Dans cette seconde partie, les techniques d’extraction que nous avons utilis´ees sont pr´esent´ees. Le chapitre4,«PINAPA: extrac-tion des informaextrac-tions d’architecture et de comportement d’un mod`ele SystemC»pr´esente le premier composant, qui s’apparente `a la partie frontale d’un compilateur, pour des programmes SystemC. Le chapitre5,«HPIOM: machines `a entr´ees/sorties parall`eles et h´et´erog`enes», pr´esente la structure in-term´ediaire que nous utilisons pour repr´esenter la s´emantique de SystemC. La traduction elle-mˆeme est d´etaill´ee dans le chapitre6,«BISE: s´emantique de SystemC et des constructions TLM en terme d’automates», qui transforme la sortie de PINAPAenHPIOM.
III. Utilisation deHPIOMpour la v´erification formelle : Cette partie pr´esente l’utilisation des donn´ees extraites pour la v´erification formelle. Dans un premier temps, une s´erie de transformations est appliqu´ee aux automates g´en´er´es, comme pr´esent´e dans le chapitre7,« BIRTH : transformations de HPIOM ind´ependantes du g´en´erateur de code». Enfin, le chapitre8,«G´en´erateurs de code : connexion deHPIOMaux outils de preuve»pr´esente la g´en´eration de LUSTREetSMV, qui permet d’utiliser des model-checkers, interpr´eteurs abstraits et solveurs SAT pour prouver des propri´et´es sur les mod`eles. Une comparaison entre ces diff´erents outils est pr´esent´ee.
Conclusion : La derni`ere partie conclut, et pr´esente les perspectives.
Le lecteur attentif remarquera qu’aucun chapitre n’est consacr´e `a la bibliographie. En effet, les th`emes abord´es dans les diff´erents chapitres sont assez vari´es, et nous avons pr´ef´er´e r´epartir les r´ef´erences biblio-graphiques et les travaux connexes dans les diff´erentes parties. De la mˆeme mani`ere, l’impl´ementation de l’outil LUSSYest d´ecrite au fil du document, et non dans une partie d´edi´ee.
18/190 Verimag/STMicroelectronics — 9 d´ecembre 2005 Matthieu Moy
Chapter 2
Modeling Systems-on-a-Chip at the Transaction Level in SystemC
Contents
2.1 Introduction . . . 19
2.2 The Systems-on-a-Chip Design Flow . . . 20
2.2.1 Hardware – Software Partitioning . . . 20
2.2.2 Different Levels of Abstraction . . . 21
2.2.3 Verification, Validation, Test . . . 23
2.3 The Transaction Level Model . . . 24
2.3.1 Example of a TLM platform . . . 24
2.3.2 TLM Concepts and Terminology . . . 24
2.3.3 Importance of TLM in the Design Flow. . . 25
2.4 SystemC and the TLM API . . . 26
2.4.1 Need for a new “language” . . . 26
2.4.2 The SystemC Library . . . 27
2.4.3 TLM in SystemC . . . 32
2.5 A Larger Example: The EASY Platform . . . 35
2.5.1 Description of the Platform . . . 35
2.5.2 A TLM model for EASY . . . 36
2.1 Introduction
Quality and productivity constraints in the development tools for the design of embedded systems are increasing quickly. The physical capacity of chips can usually grow fast enough to satisfy those needs: The evolution of the number of transistors on a chip has been following Moore’s law (growth of 50% per year) for decades, and should keep on following it for at least 10 years. But one of the design flow bottlenecks is the design productivity: with traditional techniques, it grows only by around 30% per year, leaving a gap, increasing by 20% per year between the capacity of the chips, and the amount of code the designers are able to write. This problem is often referred to as thedesign gap. New techniques have to be settled continuously to be able to fill in this gap.
This chapter will first present today’s design flow, with the different levels of abstraction used to de-scribe a chip (section2.2). Then, we will detail theTransaction Level Modelinglevel of abstraction that will be studied in this document (section2.3), and present the way it is implemented in SystemC (section2.4.3).
The chapter ends with a small case study: The EASY platform, in section2.5.
19
Chapter 2. Modeling Systems-on-a-Chip at the Transaction Level in SystemC