VERIFICATION DE SOC SOUS VELOCE

Fabrice Muller(1), Gilles Jacquemod(1), Rachid Bouchakour(2)

Pôle CNFM PACA Polytech’Nice-Sophia(1), Polytech’Marseille(2)

1.1 Introduction La vérification des SoC devient difficile à cause, en autre, à la complexité des modules matériels à

tester. La conséquence immédiate est l’allongement du temps de simulation qui croit de manière exponentielle. Pour diminuer les temps de vérification, plusieurs solutions sont actuellement proposées :

• Simuler l’IP (Intellectual Property) en injectant des stimuli générés de manière pseudo-aléatoire et à comparer les sorties de l’IP avec le résultat attendu. Cette solution ne résout que partiellement le problème de vérification en proposant d’explorer des cas de stimulus mieux réparti dans l’espace des solutions.

• Mixer un modèle de haut niveau de type transactionnel et un module matériel. L’exemple typique est un module décrit en VHDL ou Verilog et le reste de l’architecture en SystemC (IEEE 1666) ou SystemVerilog (IEEE 1800).

• Utiliser le logiciel Virtuoso (Cadence) qui est aussi une solution pour accélérer la vérification, • Faire appel à un émulateur qui exécute le code de l’IP de manière efficace. Plusieurs

techniques d’émulation sont proposées : − l’émulateur est un ensemble de processeurs logiciels connectés en réseau, qui simule le

comportement de l’IP. L’émulateur qui se rapproche de cette technique est le Palladium (Cadence) composés de RCC (ReConfigurable Computing).

− l’émulateur est composé d’un réseau de modules matériels configurables. Ces modules peuvent être propriétaires, c'est-à-dire conçus uniquement pour l’émulateur (Veloce) ou alors utiliser des circuits programmables standards (solution EVE par exemple).

L’avantage de l’émulation est de pouvoir tirer partie des deux premières solutions tout en accélérant la simulation de l’IP.

Dans le cadre de la plateforme Conception de recherche CIM-PACA1 (Centre Intégré de Microélectronique en région PACA), nous proposons d’utiliser un émulateur Veloce SOLO, actuellement opérationnel pour une utilisation de recherche en partenariat avec le monde industriel, pour mettre en place une série de travaux pratiques « ludiques » au sein du pôle CNFM PACA. A terme, l’objectif est d’élargir son utilisation en proposant aux différents pôles CNFM un accès à distance pour réaliser ces travaux pratiques. Les premières maquettes de TP, permettant d’étudier les différentes possibilités pour vérifier un module IP ou un SoC à l’aide de l’émulateur Veloce, sont développées dans ce papier et seront présentées sous forme de démonstrations à distance lors des journées pédagogiques de Saint-Malo.

1 Association ARCSIS : www.arcsis.org

PACA

O9

Ces TPs permettent d’étudier les différentes possibilités pour vérifier un module IP (Intellectual Property) ou un SoC à l’aide de l’émulateur Veloce. Il s’agit de prendre en main l’outil à partir d’un exemple simple. Les trois études sont les suivantes :

• Emulation d’un IP (VHDL) en utilisant uniquement des stimulus embarqués dans l’émulateur, • Emulation d’un IP (VHDL) sur l’émulateur et du test bench (VHDL) s’exécutant sur un

simulateur de la machine, • Emulation d’un IP (VHDL), du transacteur (Verilog) sur l’émulateur et du testbench décrit en

langage de niveau système (SystemC, SystemVerilog) sur la machine hôte. Le papier commence par présenter les caractéristiques et l’environnement autour de l’émulateur

Veloce. La seconde partie résume les travaux pratiques proposés pour illustrer simplement le fonctionnement et le flot de l’émulateur.

1.2 Présentation de l’émulateur Veloce

1.2.1 L’architecture interne de Veloce L’émulateur Veloce se décline en 3 versions dont le Veloce Solo (Figure 1) qui est hébergé au

département Electronique de Polytech’Nice-Sophia. L’émulateur Veloce Solo permet d’émuler jusqu’à 19 MGates, à une capacité de stokage mémoire de 1GB et une fréquence d’horloge pouvant atteindre 1,5MHz. Le principal inconvénient de cette version Veloce Solo est le fonctionnement mono utilisateur qui implique une organisation spécifique en travaux pratiques.

Figure 1 : Famille Veloce.

La technologie d’émulation (Figure 2) est basée sur un réseau de systèmes sur puces propriétaires (Custom SoC) en technologie 90nm avec 8 couches de cuivre, contenant chacune 500KGates et possédant un module VirtualWires intégré pour la communication inter SoC. Une mémoire de 1Mo est intégrée dans chaque « Custom SoC » pour le design. De plus, un module pour le debug et un module de contrôleur de trace est inclus et permet de capturer les signaux.

Figure 2 : Technologie d’émulation.

1.2.2 L’environnement autour de Veloce Comme nous l’annoncions dans l’introduction, l’objectif est de fournir un accès à distance pour

cet émulateur et son logiciel associé.

PACA

O9

L’émulateur Veloce est connecté à une machine hôte sous Linux derrière un serveur d’accès (Figure 3). La machine hôte est une machine PowerEdge 2900 (Quadri processeur Intel Xeon à 2,3GHz) possédant 16Go de mémoire vive et utilisant comme système d’exploitation Linux RedHat Entreprise 4. La connexion à l’hôte se fait à travers un tunnel ssh crypté en utilisant une connexion VNC (Virtual Network Computing). L’ensemble des étudiants lance l’application Veloce en « Remote Display » sous Windows ou Linux. La procédure, par exemple sous Windows, est simple :

• Lancement d’une connexion tunnel ssh (logiciel Putty), • Lancement d’un VPN (logiciel VNCviewer).

Veloce Solo

Etudiants

Machine Hôte

Serveur d’accès

Câble propriétaire

Ethernet100Mbit

Figure 3 : Architecture Réseaux simplifiée.

Le logiciel Veloce s’exécute sur la machine hôte. Ce logiciel accepte en entrée de nombreux langages : VHDL, Verilog pour la conception de l’IP et SystemVerilog, SystemC pour le testbench. La première partie du flot est faite hors-ligne et le reste en-ligne (un utilisateur à la fois). Les principales étapes (Figure 4) sont :

• La préparation de l’IP et de son environnement (Hors-ligne) : La première étape est d’écrire le module et son testbench en langage HDL (VHDL, Verilog, SystemVerilog) ou bien à l’aide de fichiers de stimuli qui seront chargés dans des mémoires ou des registres.

• La compilation (Hors-ligne) : Cette étape consiste à analyser la description, à compiler le code (RTLC), à synthétiser (velsyn) sous forme de netlist optimiser pour l’architecture Veloce et de nombreux rapports permettant de connaitre les performances d’émulation ainsi que les erreurs éventuelles de synthèse. De plus, RTLC peut inférer des mémoires. Ainsi, il est possible de charger des mémoires en utilisant des fichiers de différents formats (hexadécimal, binaire). C’est aussi à cette étape que les spécifications de temps seront définies (horloges).

• La préparation de l’émulateur (En-ligne) : Cette étape permet de se connecter à l’émulateur pour charger la netlist, les triggers et les mémoires précédemment spécifiés.

• L’exécution de l’émulation (En-ligne) : Cette étape va donner l’ordre de lancer l’émulation comme une simulation en spécifiant un nombre de cycles ou d’unités de temps.

• L’analyse de trace (Hors-ligne ou En-Ligne) : Cette dernière étape permet de récupérer à l’intérieur de l’émulateur le contenu des mémoires, les traces des signaux pour ensuite être affichés sous forme de « waveform » comme sous le logiciel de simulation ModelSim.

PACA

O9

Etapes détailléesHors-ligne

Etapes principalesen-ligne

Analyse des résultats

Figure 4 : Logiciel Veloce.

1.3 Proposition de Travaux Pratiques L’objectif est de proposer des TP « ludiques » d’une durée de 3 heures qui illustrent au mieux les

possibilités d’un émulateur tel que Veloce. Nous proposons un module simple, un module MACC-FIR (Multiply-ACCumulate Finite Impulse Response), qui illustre à la fois du contrôle, des blocs de mémoire RAM (stockage des échantillons) et ROM (stockage des coefficients).

1.3.1 Présentation du module MACC-FIR Ce FIR est un filtre numérique utilisé dans de nombreuses applications. L’architecture proposée

est une implémentation séquentielle, c'est-à-dire une multiplication et une somme d’un coefficient à chaque période d’horloge. Cela signifie que la latence du résultat est de N périodes d’horloge.

Figure 5 : Architecture du FIR.

PACA

O9

La Figure 5 illustre l’architecture du module FIR composé d’une machine à état qui sélectionne un à un les échantillons et les coefficients, qui lance l’exécution de l’opérateur MAC, et qui génère un signal « output_valid » afin de prévenir que le résultat est disponible en sortie du module FIR. Un résultat de simulation (Figure 6) illustre un cycle de calcul complet.

Cycle de calcul

Figure 6 : Résultat de simulation.

A partir de cet exemple, nous allons présenter les diverses solutions pour utiliser l’émulateur Veloce.

1.3.2 Prise en main de l’émulateur Veloce L’objectif de ce TP N°1 est de

découvrir le flot général de l’émulateur. Pour ce faire, nous proposons d’utiliser le mode Standalone de Veloce (Figure 7).

Le principe est de vérifier un IP, décrit en VHDL de niveau RTL (Register Transfer Level), à l’aide d’un testbench embarqué dans l’émulateur. Ce testbench envoie des échantillons périodiquement.

Pattern File(.pat)

Test Environment FilePattern generation clock

Testbench Interface(In/Out/InOuts)

Number of words

DUT Files(Verilog/

VHDL/SV)

Veloce Compiler

DUT

Pattern Data(Memory)

Pattern-basedTestbench

Veloce

FIR

testbench

Figure 7 : Emulateur en Mode Standalone.

Ce TP illustre aussi la possibilité de modifier la mémoire des coefficients en début d’émulation puis de récupérer les échantillons actuellement en RAM et de visualiser les chronogrammes des signaux internes du FIR et du testbench (Figure 5). Un autre point abordé est la possibilité de trigger à l’intérieur de l’émulateur. Les pré-requis sont uniquement le langage VHDL.

1.3.3 Usage d’un TestBench décrit en VHDL Les scripts sont habituellement utilisés pour exécuter un ensemble de commandes ou un

enchaînement d’outils. Ce TP N°2 illustre la manière de piloter l’émulateur, de la phase d’analyse à l’affichage des résultats au travers un script de type Makefile. De plus, l’objectif est d’effectuer une vérification mixte Simulation/Emulation. En effet, le test bench VHDL s’exécute sur la machine hôte sous ModelSim tandis que le module FIR est toujours émulé. Cette configuration ressemble à une simulation classique sous ModelSim.

PACA

O9

Cette solution utilise le mode HDL Link de l’émulateur. L’inconvénient de ce mode est la quantité d’informations (transaction VHDL, delta délai) qui circule entre la machine hôte et l’émulateur. La conséquence immédiate est le ralentissement global de l’émulation, mais ce dernier reste plus rapide qu’une simulation complète sous ModelSim. Les pré-requis sont comme précédemment le langage VHDL.

SimulatorRuntime DB

EmulatorRuntime DB

Mixed-LevelCommunications DB

HDL Link Compiler

HDL Source Files Configuration File

VeloceSimulator HDL Link

Hardware/SoftwareCo-Simulation Link

FIRtestbench

Figure 8 : Mode HDL-Link.

1.3.4 Du niveau RTL au niveau Transactionnel Ce TP N°3 permet de découvrir la possibilité de décrire le test bench en langage de plus haut

niveau tel que SystemVerilog ou SystemC. L’objectif est d’accélérer l’émulation en passant uniquement des transactions non temporelles entre l’émulateur et la machine hôte. Le principe est d’écrire des transacteurs en SystemVerilog qui traduisent les transactions venant de la machine hôte en signaux de niveau RTL. L’IP et les transacteurs sont émulés sur Veloce (Figure 9). Ce mode d’émulation est appelé TBX.

L’inconvénient de ce mode est l’obligation d’utiliser le langage SystemVerilog/Verilog pour décrire les transacteurs. C’est un pré-requis obligatoire pour les étudiants et ne sera pas mis en place dans la première phase d’utilisation de Veloce.

Transactors & Design(Veloce)

Design

PCIe X-actor

AGPX-actor

USB X-actor

MemoryX-actor

Testbench

HostUn-timed

Transactions

FIRTestbench

(SystemVerilog)

TransactorTransaction (untimed)

Signals (Timed, Clk)

Figure 9 : Mode TBX.

1.4 Conclusion Ces travaux pratiques permettent de comprendre le principe de fonctionnement de l’émulateur et

d’illustrer les différentes solutions pour vérifier un module décrit en langage HDL. L’objectif n’est pas de rendre les étudiants spécialistes de l’émulation mais plutôt d’aborder l’émulation simplement pour que les étudiants acquièrent une petite expérience dans le monde de l’émulation. Cette formation pourrait être complétée dans le cadre de projets pour un plus faible nombre d’étudiants. Un projet inter-pôle est également envisageable.

PACA

O9