| 24 | | [[Image(soclib_tp1_fig1_archi.png)]] |
| 25 | | |
| 26 | | Conformément aux principes CFSM, ces deux composants sont donc modélisés par deux automates synchrones (c'est à dire cadencés par la même horloge CK). L'écriture dans les tous les registres du système se fait sur le front montant de CK. Ils sont initialisés par le même signal RESETN, actif à l'état bas. |
| 27 | | |
| 28 | | == 2.1 Canal de communication FIFO == |
| 29 | | |
| 30 | | Le canal de communication FIFO implante un protocole de communication très simple supportant le contrôle de flux. |
| 31 | | |
| 32 | | [[Image(soclib_tp1_fig2_fifo.png)]] |
| 33 | | |
| 34 | | Chacune des deux entités communicantes considère que son interlocuteur est une simple FIFO. Une FIFO est une mémoire double accès de type First-In-First-Out sans adressage explicite. Le producteur peut écrire dans la FIFO en activant le signal W. L'écriture est effective lorsque la FIFO n'est pas pleine (WOK peut être considéré comme un signal d'état signifiant FIFO non pleine). Le producteur peut lire une donnée dans la FIFO en activant le signal R. La lecture est effective lorsque la FIFO n'est pas vide |
| 35 | | (ROK peut être considéré comme un signal d'état signifiant FIFO non vide). |
| 36 | | |
| 37 | | Attention : Il n'y a donc pas de mécanisme de ''handshacking'' : le producteur n'a pas besoin de consulter la consommateur |
| 38 | | pour envoyer un ordre d'écriture (c'est à dire W = true). De même, le consommateur n'a pas besoin de consulter le producteur pour envoyer un ordre de lecture (c'est à dire R = true). Simplement, une donnée est effectivement transmise à chaque cycle où les deux signaux WOK et ROK ont simultanément la valeur true. |
| 39 | | Ce protocole supporte un débit maximal d'une donnée par cycle, et permet à chacun des interlocuteurs d'interrompre la transmission quand il n'est pas prêt. |
| 40 | | |
| 41 | | Un des avantages de ce protocole est que les deux composants communicants se comportent tous les deux comme des automates de Moore : |
| 42 | | Il n'y a évidemment qu'un seul émetteur par signal, et la valeur des signaux échangés ne dépend que de l'état interne de l'émetteur. |
| 43 | | |
| 44 | | == 2.2 Composant ''fifo_lcd_coprocessor'' == |
| | 24 | [[Image(soclib_tp2_fig1_archi.png)]] |
| | 25 | |
| | 26 | == 2.1 Canal de communication VCI == |
| | 27 | |
| | 28 | Le protocol de communication VCI permet de construire des architectures multi-processeurs implante un protocole de communication très simple supportant le contrôle de flux. |
| | 29 | |
| | 30 | La figure ci-dessous détaille les signaux utilisés par le protocole VCI. |
| | 31 | |
| | 32 | [[Image(soclib_tp2_fig2_fifo.png)]] |
| | 33 | |
| | 34 | La plupart des champs VCI on des largeurs paramètrables (en nombre de bits) : |
| | 35 | * le paramètre X définit le nombre de bits du champs ADDRESS. Les adresses VCI sont des adresses octets, |
| | 36 | mails elles doivent être alignées sur des frontières de mot. |
| | 37 | * le paramètre '''B''' définit le nombre d'octets d'un mot de donnée VCI. Ce paramètre définit le largeur des trois |
| | 38 | champs WDATA, RDATA et BE. |
| | 39 | * le paramètre '''K''' définit le nombres de bits termettant de coder la longueur PLEN d'un paquet (en nombre d'octets). |
| | 40 | La valeur PLEN doit également être un multiple du paramètre B. |
| | 41 | * le paramètre '''S''' définit le nombre de bits du champs SRCID, qui permet de coder le numéro de l'initiateur |
| | 42 | VCI qui a démarré la transaction. Ce paramètre définit donc le nombre maximum d'initiateurs dans le système. |
| | 43 | * Le paramètre '''E''' définit le nombre de bits permettant de coder le type d'erreur dans le champs RERROR |
| | 44 | du paquet commande. La valeur 0 signifie "pas d'erreur". |
| | 45 | * Les deux paramètres '''T''' et '''P''' définissent le nombre de bits des deux champs TRDID et PKTID. Ces deux champs permettent d'étiqueter une commande VCI par une numéro de thread et/ou par un numéro de transaction. Ceci |
| | 46 | permet à un même initiateur d'envoyer une commande ''n+1'' sans attendre d'avoir reçu la réponse à la commande ''n''. |
| | 47 | |
| | 48 | Bien sûr les valeurs de ces paramètres VCI doivent être les mêmes pour tous les composants matériels d'une même architecture. |
| | 49 | |
| | 50 | === Modélisation === |
| | 51 | |
| | 52 | Cette généricité des interfaces de communication VCI est évidemment une souplesse très utile, |
| | 53 | mais elle crée une difficulté pour la modélisation des composants matériels, puisqu'ilfaut écrire des modèles de |
| | 54 | simulation génériques, capable de s'adapter à différentes largeurs d'adresse ou de donnée. |
| | 55 | On utilise pour cela la techique des ''templates'' du langage C++ : on regroupe toutes les valeurs de ces paramêtres dans un oblet C++ de type ''VciParams'', qui est utilisé comme paramètre ''template'' par tous les composants matériels |
| | 56 | qui possèdent des ports de communication VCI. |
| | 57 | |
| | 58 | On définit également trois autres objets, qui facilitent l'écriture des modèles de simulation CABA : |
| | 59 | * l'objet ''VciSignals'' regroupe tous les signaux (commande et réponse) d'un canal VCI. |
| | 60 | * l'objet ''VciInitiator'' regroupe tous les ports utilisés par un initiateur VCI pour émettre une commande, |
| | 61 | et recevoir la réponse. |
| | 62 | * l'objet ''VciTarget'' regroupe tous les ports utilisés par une cible VCI pour émettre une réponsee, |
| | 63 | et recevoir une commande. |
| | 64 | Ces trois objets utilisent évidemment un paramètre template de type ''VciParams''. |
| | 65 | |
| | 66 | == 2.2 Composant ''VciLcdCoprocessor'' == |
| | 67 | |
| | 68 | Le composant ''!VciLcdCoprocessor'' se comporte comme un périphérique adressable qui doit être |
| | 69 | modélisé comme une cible VCI. Il possède donc un seul port de type ''!VciTarget'', et 4 registres |
| | 70 | (ou pseudo-registres) implantés dans l'espace addressable, qui peuvent donc - en principe - être |
| | 71 | lus ou écrits par n'importe quel initiateur. |
| | 72 | du sytème. Chacun de ces registres a une largeur de 4 octets. Par conséquent, le occupé par le périphérique |
| | 73 | segment de |
