Solution Final automne 2009 - Moodle

INF8500 Examen final Automne 2009
Question 1 (4 points) Algorithmes de partitionnement
a) (1 pt) Effectuez un partitionnement de la spécification de la figure 1.1 en utilisant la
méthode clustering vue en classe. Les arcs représentent le temps estimé des
communications entre chaque objet fonctionnel oN (N variant de 1 à 5). Ciblez 1
partition de 2 objets fonctionnels et 1 partition de 3 objets fonctionnels.
10
22
10
14
6
10
0
0
5
7.5
6.25
Figure 1.1 Système à partitionner
b) (3 pts) Soit l’algorithme de recherche par Tabu des pages 2 et 3 adapté au problème du
partitionnement logiciel/matériel. Expliquez le fonctionnement de cet algorithme en
détaillant le rôle des 3 branches A, B et C de la figure 1.2 qui permettent l’implémentation
d’une stratégie de diversification et d’intensification. La figure 1.3 peut aussi vous être
utile.
Page 1 de 14

INF8500 Examen final Automne 2009
Figure 1.2 Algorithme de recherche Tabu pour le partitionnement logiciel/matériel
Page 2 de 14

INF8500 Examen final Automne 2009
Figure 1.3 Structure de données pour l’algorithme de recherche Tabu
La méthode Tabu se classe dans la catégorie des algorithmes hill climb.
Contrairement à l’approche de recuit simulé, la recherche Tabu contrôle les déplacements de
blocs de manière intelligente plutôt qu’avec le hasard comme c’est le cas du recuit simulé.
Plus précisément, on garde une liste des voisinages visités récemment dans une liste Tabu. Il
s’agit en fait d’une queue de profondeur (degree) de 7 à 20 ou encore de .5N1/2 à 21/2 où N
est fonction de la dimension du problème.
Avec le test de A, deux situations peuvent survenir :
1) À partir de la solution courante, on va tout d’abord explorer des solutions voisines (par
exemple en déplaçant un objet du logiciel au matériel ou vide versa). Pour ces solutions
voisines (k = 1 à M), on calcule un coût dcost(k). Si ce dcost(k) est plus petit que le
meilleur dcost obtenu à ce jour et que k n’est pas dans la liste Tabu on conserve la
solution (permet la diversification).
2) Si dcost(k) est plus grand que le meilleur dcost obtenu à ce jour ou si k est pas dans la
liste Tabu on va donner une pénalité à k (penalty(k)) qui est ajouté à dcost(k). Cette
pénalité est fonction de la fréquence d’apparition d’un certain sous-voisinage de k (k bits
LSB). Plus ce sous-voisinage est apparu souvent plus la pénalité est grande (permet la
diversification). Par contre cette dernière est moins grande si k est apparu au cours des
Page 3 de 14

INF8500 Examen final Automne 2009
Kq dernières itérations, ce qu’on appelle promising region et qui permet l’intensification.
Finalement, on sélectionne le plus petit dcost(k) pour les k qui ne sont pas dans la liste
Tabu et pour ceux qui le sont on choisi le k le plus profond dans la queue.
Finalement, on détermine le meilleur dcost parmi 1) et 2) qui devient alors Snow.
Page 4 de 14

INF8500 Examen final Automne 2009
Question 2 (4 points) Partitionnement vs ordonnancement
La figure 2.1 représente un résultat de partitionnement logiciel/matériel sur 8 tâches (objets
fonctionnels). On souhaite maintenant ordonnancer ce résultat. Les contraintes au niveau
ressource sont les suivantes : 1 processeur pour l’exécution du logiciel, 2 coprocesseurs pour
l’exécution du matériel, 1 bus pour le processeur, 1 bus partagé entre le logiciel et le matériel et 1
bus pour le matériel. Également, considérez qu’une tâche ne peut écrire et lire au même moment
sur un bus.
À partir de ce résultat, complétez l’ordonnancement de la figure 2.2 en vous inspirant de
l’algorithme vu en classe qui se base sur le list scheduling (voir Annexe)
Figure 2.1 Résultat de partitionnement. Chaque nœud est étiqueté d’un numéro entre 1 et 8, suivi
d’une valeur en parenthèse qui représente le temps d’exécution de ce nœud. La valeur associée à
chaque arc représente le temps de communication.
Page 5 de 14

INF8500 Examen final Automne 2009
Figure 2.2 Ordonnancement logiciel/matériel. À compléter.
Page 6 de 14

INF8500 Examen final Automne 2009
QUESTION 3 (4 points) Architecture d’un testbench
a) (2 pts) Donnez le schéma général d’un testbench (banc d’essai) qui doit contenir les
éléments suivants : agent, scoreboard, checker, driver, monitor et generator. Puis,
expliquez pourquoi dans le laboratoire no 3 vous n’avez pas eu recours au Driver et au
Receiver Indiquez brièvement à quoi servent ces 2 éléments.
b) (.5 pt) À quel endroit retrouve-t-on généralement les assertions dans un banc d’essai
Justifiez.
Avec le DUT, surtout si on a besoin de variable locale (en boîte blanche).
Page 7 de 14

INF8500 Examen final Automne 2009
c) (1.5 pts) Soit l’interface System Verilog de la figure 3.1, le programme test (testbench) de
la figure 3.2a et finalement un arbitre (DUT) de la figure 3.2b. Complétez le diagramme
temporel de la figure 3.3.
interface arb_if (input bit clk);
logic [1:0] grant, request;
logic reset;
clocking cb @(posedge clk);
output request
input grant
endclocking
modport TEST(clocking cb, output reset);
modport DUT(input request, reset, output grant);
endinterface
Figure 3.1 Interface du système
‘timescale 1ns/1ns
program test(arb_if.TEST arbif)
initial begin
//petit testbench artisanal…
#7 arbif.cb.request

INF8500 Examen final Automne 2009
Question 4 (4 points) Assertions avec System Verilog
a) (1 pt) Quelle différence faites-vous entre une assertion de type assert et un point de
couverture Expliquez.
Les assertions permettent de détecter les comportements non-souhaitables alors que les points de
couverture (couverture fonctionnelle) permettent de répertorier les comportements désirés.
b) (3 pts) Soit l’interface d’un module Verilog qui réalise l’arbitration sur un bus tel que
présenté à la figure 4.1 (page suivante). Décrivez le rôle joué de chacune des assertions
ci-après (no 1 à 3) et proposez à l’aide d’un diagramme temporel une situation qui la fait
échouer.
Assertion no 1 :
property property1;
(@(posedge clk) roundORpriority && $rose (req[0]) |-> ##[1:4] gnt[0]);
endproperty
assert_property1: assert property (property1);
L’assertion no 1 permet de s’assurer que la réponse à la requête i se fait entre 1 et 4 cycles en
mode RR
Assertion no 2 :
property property2(i);
(@(posedge clk) disable iff (rst)
gnt[i] |=> (~gnt[i] throughout (req[i]) [-> 1]);
endproperty
generate
begin
genvar i;
for (i=0; i

INF8500 Examen final Automne 2009
Assertion no 3 :
property property3(i, j);
@(posedge clk) disable iff (rst)
!roundORpriority && (i > j) && $rose(req[i])
##1 (~gnt[i] throughout (gnt[j]) [-> 1]) |-> 0;
endproperty
generate
begin
genvar i, j;
for (i=0; i

INF8500 Examen final Automne 2009
Question 5 (4 points) Génération aléatoire et vérification fonctionnelle
Soit le DUT (Design Under Test) et son testbench de l’unité arithmétique et logique (présenté en
classe lors du dernier cours) que nous souhaitons vérifier. La figure 5.1 présente les contraintes
que l’on donne lors de la génération aléatoire d’un stimulis. La figure 5.2 présente des points de
couverture que l’on souhaite couvrir pour tenter d’obtenir 100% de couverture fonctionnelle.
a) (1 pt) Décrivez textuellement les contraintes de notre stimulis (Figure 5.1)
b) (1.5 pt) Décrivez textuellement la couverture que l’on souhaite faire ici (Figure 5.2)
c) (1 pts) À partir de cette information (figure 5.1 et 5.2) set de la spécification de l’unité
arithmétique et logique donné en Annexe, croyez-vous que l’on puisse obtenir (ou tendre
vers) 100% de couverture fonctionnelle en supposant que l’on simule durant 5ms.
Justifiez clairement votre réponse.
d) (.5 pt) Si vous avez bien compris le lien entre les figures 5.1 et 5.2 et en sachant que
plusieurs générateurs peuvent être définis pour un même testbench, vous devriez
maintenant être en mesure de répondre à la question suivante : À quel endroit devrait
retrouver les groupes de couverture dans un testbench Justifiez.
class Packet;
rand reg [`REGISTER_WIDTH-1:0] src1;
rand reg [`REGISTER_WIDTH-1:0] src2;
rand reg [`REGISTER_WIDTH-1:0] imm;
rand reg [`REGISTER_WIDTH-1:0] mem_data;
rand reg immp_regn_op_gen;
rand reg [2:0] operation_gen;
rand reg [2:0] opselect_gen;
reg
enable;
string
name;
constraint Limit {
src1 inside {[-10:10],0,32'hffffffff,32'h55555555,32'haaaaaaaa};
src2 inside {[-10:10],0,32'hffffffff,32'h55555555,32'haaaaaaaa};
imm inside {[0:65534]};
mem_data inside {[0:65534]};
//payload_size inside {[9:12]};
opselect_gen inside {[0:1]};
if ((opselect_gen == `ARITH_LOGIC)){
operation_gen inside {[0:7]}; }
else if ((opselect_gen == `SHIFT_REG)) {
immp_regn_op_gen inside {0};
operation_gen inside {[0:3]}; }
}
extern function new(string name = "Packet");
endclass
Page 11 de 14

INF8500 Examen final Automne 2009
Figure 5.1 Contraites System Verilog lors de la génération aléatoire d’un stimulis
a) Comme on peut le voir, la plage des registres src1 et src2 est redéfinie pour tenir compte
des négatifs et des points particuliers désirés, ce qui n’était pas le cas de l’exemple
présenté au dernier cours. Également, on se concentre ici sur les opérations
arithmétiques et sur le décalage. On suppose que l’opération de mémoire est OK.
b) En ce qui concerne les points de couverture, nous avons avons défini des points de
couverture très spécifiques pour que les couvertures croisées soient réalisées uniquement
sur l'ensemble de possibilitées voulues (toutes les fonctions arithmétiques et toutes les
fonctions de déplacement (« shift »). Pour ce faire, nous avons défini les points de
couverture opselect_cov_arithm, opselect_cov_shift, arithm_cov et shift_opn_cov. Ces
points de couverture servent à réaliser une sélection (intersect) uniquement sur ce qui est
désiré : le premier pour le sélecteur d'opération arithmétique, le deuxième pour les
déplacement. Ensuite, les deux suivants sont remplis pour toutes les opérations
arithmétiques (ADD, ADDU, SUB, …) et le dernier pour les opérations de déplacement.
Ainsi, les couvertures croisées définies arith_cov2 et shift_cov2 permettent de faire
automatiquement pour la première les couvertures de toutes les opérations arithmétiques
et pour la deuxième toutes les opérations de déplacement
c) La couverture fonctionnelle pourrait tendre vers 100% car les limitations de a) et de b)
permettent une intersection fini (e.g. -10 à 10 pour les entrées, 8 opération arithmétiques
et 4 opérations de décalage). Il faut bien comprendre que cette couverture représente
l'ensemble des cas spécifiques définis dans les contraintes du générateur de paquet.
Page 12 de 14

INF8500 Examen final Automne 2009
Packet pkt_sent = new(); // Packet object from Driver
covergroup Arith_Cov;
src1_cov: coverpoint pkt_sent.src1 {
bins zero = {0};
bins allfs = {32'hffffffff};
bins special1 = {32'h55555555};
bins special2 = {32'haaaaaaaa};
bins positive = {[0:'1]} iff(pkt_sent.src1[31] == 1'b0);
bins negative = {[0:'1]} iff(pkt_sent.src1[31] == 1'b1);
}
src2_cov: coverpoint pkt_sent.src2 {
bins zero = {0};
bins allfs = {32'hffffffff};
bins special1 = {32'h55555555};
bins special2 = {32'haaaaaaaa};
bins positive = {[0:'1]} iff(pkt_sent.src2[31] == 1'b0);
bins negative = {[0:'1]} iff(pkt_sent.src2[31] == 1'b1);
}
opselect_cov: coverpoint pkt_sent.opselect_gen {
bins shift = {0};
bins arith = {1};
bins mem = {[4:5]};
}
opselect_cov_arith: coverpoint pkt_sent.opselect_gen {
bins arith = {1};
}
opselect_cov_shift: coverpoint pkt_sent.opselect_gen {
bins shift = {0};
}
arithm_opn_cov: coverpoint pkt_sent.operation_gen {
bins arith_logic_ops = {[0:7]} iff(pkt_sent.opselect_gen==1);
}
shift_opn_cov: coverpoint pkt_sent.operation_gen {
bins shift_ops = {[0:3]} iff(pkt_sent.opselect_gen==0);
arith_cov2: cross src1_cov, src2_cov, opselect_cov_arith, arithm_opn_cov
shift_cov2: cross src1_cov, src2_cov, opselect_cov_shift, shift_opn_cov
}
endgroup
Figure 5.2 Points de couverture demandés
Page 13 de 14

INF8500 Examen final Automne 2009
Annexe
Algorithme du list scheduling adapté au partitionnement logiciel/matériel
Assignation du matérielle
Page 14 de 14