INF8500 – Système embarqués: conception et vérification

     

INF8500 Systèmes

 

embarqués

 

:

 

conception

 

et

 

vérification

 

Laboratoire

 

#

 

2

 

:

   

Conception

 

d’un

 

encodeur

 

Reed

‐

Solomon

 

en

 

SystemC

 

et

 

validation

 

à

 

l’aide

 

d’un

 

banc

 

de

 

test

 

 

SystemVerilog.

  

 

Automne

 

2014

 

1 Objectifs

 

L’objectif de ce second laboratoire est d’introduire la conception haut niveau à l’aide de la librairie

SystemC

et de poursuivre sur les notions de bancs d’essai (

testbench

) avec le langage

SystemVerilog

méthodologie « . Il sera donc question de démontrer l’interopérabilité des deux langages afin de faciliter la conception de module indépendamment du niveau d’abstraction. Ceci s’inscrit dans la

Electronic system level

»

(ESL).

Figure 1 - banc d'essai indépendant du niveau d’abstraction

Laboratoire 1 – Automne 2014 Page 1

INF8500 – Système embarqués: conception et vérification Pour ce faire, vous devrez : 1.

Vous familiariser avec l’encodeur

Reed-Solomon

du standard

WiMAX

, qui est une 2.

3.

application concrète pour un système embarqué. Vous familiariser avec

SystemC

et les communications par signaux. Adapter à l’encodeur votre banc d’essai maison selon le modèle

UVM

développé au 4.

premier laboratoire. Utiliser des métriques de couverture afin de diriger la génération de tests et concevoir des assertions simples en

SystemVerilog

(SVA). 5.

Maîtriser les outils de vérification

Questa Sim

de la compagnie

Mentor Graphics

. Ce travail pratique s’échelonnera sur deux séances. La première séance sera consacrée à la conception du module alors que la seconde sera consacrée à la vérification de celui-ci.

2 Contexte

Le standard

WiMax

«

Worldwide Interoperability for Microwave Access

est présentement un concurrent direct avec les réseaux cellulaires

LTE

» est un standard de communication sans fil pouvant transmettre de l’information à haut débit sur une zone étendue. Il s’agit d’une stratégie de connexion pour les zones éloignées où l’infrastructure pour les lignes de transmission haute vitesse est inexistante, telle que les régions rurales. Il s’inscrit dans les projets d’évolution des télécommunications sans fil appelées à remplacer les réseaux filaires. Il (4G). L’algorithme

Reed-Solomon

communication). L’ajout de caractéristiques suivantes 1 : 2 est un code de correction basé sur les corps de Galois. Il utilise les propriétés des polynômes premiers afin de produire de l’information suréchantillonnée. Si une erreur se présente, il est possible de reconstruire ces polynômes et ainsi corrigé l’erreur introduite. Un encodeur Reed-Solomon se charge donc d’ajouter de la redondance aux données transmises afin de permettre au récepteur de corriger des erreurs qui auraient pu se produire lors de la communication (par exemple une inversion de bit causée par le bruit dans le canal de octets redondants permet de corriger jusqu’à octets erronés. La sortie d’un encodeur Reed-Solomon est constituée d’abord des données fournies en entrée, qui ne sont pas modifiées par l’encodage, puis des 2 octets redondants. En théorie, l’encodage Reed Solomon peut s’appliquer à des paquets de données arbitrairement longs et permettre la correction d’un nombre arbitrairement élevé d’erreurs. En pratique, on utilise un encodeur Reed Solomon dont on a fixé la taille des paquets et le nombre d’erreurs pouvant être corrigées. Par exemple, dans le cas du standard WiMAX, l’encodeur Reed-Solomon utilisé a les

Taille des paquets en entrée Redondance par paquet

239 octets 2 16 octets → 8 octets corrigé

Taille des paquets en sortie Capacité de correction

255 octets (239 données + 16 redondants) 1 La configuration de l’encodeur Reed-Solomon pour le standard WiMAX comprend quelques subtilités supplémentaires qui ne sont pas pertinentes au présent laboratoire. Laboratoire 1 – Automne 2014 Page 2

INF8500 – Système embarqués: conception et vérification

3 Partie1 : Conception de l’encodeur

3.1 Spécification de l’algorithme

La spécification exécutable en C de l’encodeur Reed-Solomon se trouve dans le répertoire dossier

src

à l’intérieur du dossier

spec

communications (jusqu'à 8 erreurs dans ce cas-ci).

spec

standard WiMAX. Ce fichier contient également un décodeur Reed-Solomon et un banc d’essai du laboratoire. Cette spécification exécutable se trouve dans le fichier general_RS.c sous le . Notez que cet encodeur a déjà été configuré selon le qui vérifie le bon fonctionnement de l’encodeur Reed-Solomon. Notamment, le banc d’essai vérifie que le résultat de l’encodage est bel et bien capable de résister aux erreurs de Pour compiler cette implémentation et ce banc d’essai en C, lancer cette spécification à l’aide du projet Visual C++ et appuyez sur Ctrl+F5.

3.2 Modèle SystemC de l’encodeur Reed-Solomon

La spécification exécutable de l’encodeur Reed-Solomon ne peut pas être utilisée directement afin d’en produire un module éventuellement synthétisable, car cette spécification se trouve dans le même fichier que le décodeur Reed-Solomon et le banc d’essai. En effet, vous voulez définir un module d’encodage. Vous devrez donc les séparer en deux modules SystemC distincts tels qu’illustrés à la figure 1 :

Figure 2 - Schéma sommaire du système à réaliser

Le premier module contiendra seulement l’encodeur Reed-Solomon alors que le deuxième module contiendra le décodeur Reed-Solomon et le banc d’essai. Chaque module sera implémenté à l’aide d’un ou plusieurs SC_THREAD. Chaque module aura en entrée un signal d’horloge sc_in_clk

clockPort

et un signal de réinitialisation sc_in communications suivants :

resetPort

. De plus, ces deux modules devront communiquer selon le protocole de communication décrit ci-dessous. Tout d’abord, l’encodeur aura les ports de Laboratoire 1 – Automne 2014 Page 3

INF8500 – Système embarqués: conception et vérification

Signal

encoderReadyPort encoderInputPort encoderValidPort encoderOutputPort

Direction

[SORTIE] [ENTRÉE] [SORTIE] [SORTIE]

Largeur

1 bit 8 bits [x16] 1 bit 8 bits [x16]

Type SystemC

sc_out sc_in > [x16] sc_out sc_out > [x16]

Tableau 1 - Ports de communications Figure 3 - Schéma bloc de l'encodeur

Le banc d’essai aura les mêmes ports de communication, avec pour seule différence que les entrées de l’encodeur sont les sorties du banc d’essai et vice versa. Lorsque l’encodeur est prêt à recevoir un nouveau paquet en entrée, il met la sortie

encoderReadyPort

à « true ». Dès qu’il reçoit la valeur « true » sur son entrée

encoderReadyPort

, le banc d’essai doit commencer à envoyer à l’encodeur le contenu du paquet sur ses 16 ports de sortie

encoderInputPort

, à raison d’un octet par port par cycle d’horloge (pour un total de 16 octets par cycle d’horloge). L’encodeur doit donc recevoir le paquet à une vitesse de 16 octets par seconde, au fur et à mesure que celui-ci est envoyé par le banc d’essai. L’encodeur doit remettre

encoderReadyPort

à « false » après avoir terminé de recevoir le paquet d’entrée. Lorsque l’encodeur est prêt à envoyer un nouveau paquet sur sa sortie, il met la sortie

encoderValidPort

à « true ». Au même cycle d’horloge, l’encodeur commence à envoyer au banc d’essai le contenu du paquet de sortie (d’abord les données du paquet d’entrée puis les octets redondants) sur ses 16 portes de sortie l’encodeur. L’encodeur doit remettre

encoderOutputPort encoderValidPort

, à raison d’un octet par port par cycle d’horloge (pour un total de 16 octets par cycle d’horloge). Le banc d’essai doit donc recevoir le paquet à une vitesse de 16 octets par seconde, au fur et à mesure que celui-ci est envoyé par à « false » après avoir terminé d’écrire le paquet de sortie. Laboratoire 1 – Automne 2014 Page 4

INF8500 – Système embarqués: conception et vérification Notez bien qu’il y a un délai d’un cycle d’horloge entre le moment où un module écrit une valeur sur son port de sortie et le moment où l’autre module voit cette valeur apparaître sur son port d’entrée. Comme point de départ, nous fournissons un squelette de modèle SystemC qui se trouve dans le répertoire

impl

du fichier de ressources du laboratoire. En vous inspirant de la spécification exécutable en C, vous créerez un modèle SystemC de l’encodeur dans le fichier RSEncoder.h/.cpp, puis vous créerez un banc d’essai SystemC dans le fichier RSEncoderTB.h/.cpp. Le fichier MainTopLevel.cpp instancie un encodeur et un banc d’essai et les connecte ensemble; vous ne devriez pas avoir à modifier ce fichier. Pour compiler le modèle SystemC et l’exécuter, simplement appuyer sur Ctrl+F5 ou sélectionner « Start Without debugging » du menu Debug de Visual Studio.

Important

: Assurez-vous d’appeler la fonction sc_stop() à la fin de votre banc d’essai afin de mettre fin à la simulation après que tous les vecteurs de tests aient été traités. De plus, assurez vous d’utiliser uniquement les types SC_METHOD et SC_CTHREAD pour décrire vos processus. Le type SC_THREAD n’est malheureusement pas synthétisable et introduira des difficulté lors des prochains laboratoires. Laboratoire 1 – Automne 2014 Page 5

INF8500 – Système embarqués: conception et vérification

4 Partie 2 : Adaptation du banc d’essai SystemVerilog

Bien que notre module ait été développé en SystemC, il est possible, à l’aide de Questa sim, de le simuler et le tester sous un banc d’essai SystemVerilog. Ceci est grandement avantageux lors du développement d’un module. En effet, il est possible de faire aussi bien la validation fonctionnelle (SystemC) que la validation RTL (VHDL, Verilog) avec le même banc d’essai. Maintenant que vous êtes familier avec le langage SystemVerilog, on vous demande d’adapter le banc d’essai développé au premier laboratoire pour votre nouveau module. Afin d’accélérer l’adaptation du banc d’essai, nous fournissons le fichier

pkg_reed_solomon.sv

contenant le décodeur en format SystemVerilog. La couverture du banc d’essai devra se limiter à l’analyse de la capacité de correction de l’algorithme et nous vous demandons d’intégrer au moniteur de votre module les assertions suivantes qui devront bien sûr remplacer celles du module arbitre:  Le signal

encoderValidPort

s’active bien 16 cycles après que le signal

encoderReadyPort s’est activé

.  Le signal

encoderReadyPort

s’active bien 16 cycles après que le signal

encoderValidPort s’est activé

.  Le signal

encoderReadyPort

se désactive bien après avoir terminé de recevoir le paquet d’entrée.  Le signal

encoderValidPort

se désactive bien après avoir terminé d’écrire le paquet de sortie.  Les signaux

encoderReadyPort

et

encoderValidPort

sont mutuellement exclusifs.

NOTE

: Un exemple de cosimulation Verilog/SystemC provenant de MentorGraphic est fourni dans le dossier

exemple

. Laboratoire 1 – Automne 2014 Page 6

INF8500 – Système embarqués: conception et vérification

5 Remise

Vous devrez écrire un rapport, de maximum 10 pages, qui décrira le travail effectué et répondra aux questions de l’énoncé. RAPPORT Qualité de la présentation et du français

Conception de l’encodeur

Résumez le travail que vous avez fait dans cette partie, en mettant en évidence les décisions techniques que vous avez prises et leur justification.  Conception du module RSEncoder (Explications, problèmes rencontrés, discutez)  Conception du test bench SystemC (Explications, problèmes rencontrés, discutez)  Bon fonctionnement de l’encodeur, valeurs produites conformes aux valeurs attendues   Respect du protocole de communication Bon affichage à la console des résultats par le banc d’essai

Adaptation du banc d’essai

Résumez le travail que vous avez fait dans cette partie, en mettant en évidence les décisions techniques que vous avez prises et leur justification.  Modification du banc d’essai SystemVerilog (Explications, problèmes rencontrés, discutez  Quelles modifications ou stratégies de développement auraient pu simplifier le port de votre banc d’essai pour ce nouveau module ?

PÉNALITÉ ( -2 pts/jour ouvrable, plus de 4 jours entraîne la note 0, si problème consultez le professeur) NOTE GLOBALE /20

6 Références

IEEE Std 802.16-2004. IEEE Standard for Local and Metropolitan Area Networks Part 16: Air Interface for Fixed Broadband Wireless Access Systems. http://standards.ieee.org/getieee802/download/802.16-2004.pdf

Irving S. Reed et Gustave Solomon. Polynomial codes over certain finite fields. Journal of the SIAM, 8 : 300–304, 1960. Bryan Bailey, Grant Martin et Andrew Piziali, ESL Design and Verification: A Prescription for Electronic System-Level Methodology, San Francisco, CA: Morgan Kaufmann, 2007. Laboratoire 1 – Automne 2014 Page 7