Dans UVM, le banc d'essai n'a aucune visibilité sur les registres internes du DUT. Alors, pourquoi existe-t-il une mise en miroir et une création de modèles Register dans l'architecture UVM testbench? A quoi cela sert-il?Quel est le but du modèle de registre dans UVM?
Le banc d'essai ne viendrait pas à savoir si un bit d'état, etc. est mis à jour ou non à l'intérieur du DUT car il n'a accès qu'aux ports de sortie d'entrée.
Le DUT ne dispose pas de registres internes à accès direct via les ports, mais certains registres sont accessibles via un protocole d'interface. Le modèle de registre est principalement destiné à ces registres. Mais vous pouvez accéder à n'importe quel registre dans la conception via la porte dérobée (mais pas toujours souhaitable car cela nécessite plus de travail à installer et à maintenir).
Le miroir stocke la valeur de ce que le banc d'essai pense sont les valeurs de registre du DUT. Quand vous faites un .mirror(), le modèle de registre compare la valeur de registre (réelle) avec le miroir (attendu).
Les bits d'état sont souvent difficiles à prévoir. Pour simplifier les choses, vous pouvez désactiver la comparaison du champ (ou registre) avec .set_compare(UVM_NO_CHECK). Si vous désactivez la vérification au niveau du champ, les autres champs du même registre seront toujours comparés.
Si vos ambiances et veulent faire des prédictions/miroir comparer plus complexes sur les bits d'état, vous avez les options, telles que les callbacks de registre ou de l'extension des uvm_reg et uvm_reg_field classes pour remplacer les méthodes .predict et .mirror.
Dans le cas, aucun des registres n'est visible depuis le banc d'essai, y a-t-il alors un quelconque usage du modèle de registre UVM? –
Le modèle Register utilise-t-il toujours un accès de porte dérobée? Je peux voir à partir de ce poste https://stackoverflow.com/q/32454818/6641380 –
Les deux frontdoor et backdoor sont pris en charge, par défaut est généralement frontdoor. https://verificationacademy.com/verification-methodology-reference/uvm/docs_1.1d/html/files/reg/uvm_reg-svh.html#uvm_reg.mirror – Greg
RAL UVM offre plusieurs avantages
Lorsque vous avez mentionné ces points, faisaient-ils référence à un accès de porte d'entrée ou de porte dérobée? –
En outre, j'ai eu une idée que chaque interaction entre testbench arrive sur un DUT niveau de l'interface physique qui est la raison pour laquelle je voulais savoir comment RAL dans l'image. Mais maintenant, il semble que mon hypothèse était partiellement erronée. –
Ces avantages sont là avec un accès avant/arrière. Nous essayons d'élever le niveau d'abstraction en écrivant des bancs d'essai UVM aux transactions. Il n'y a pas beaucoup de variation à la synchronisation que vous pouvez faire à partir d'un banc d'essai car la plupart de vos signaux sont liés à des horloges particulières. –
vous avez des hypothèses erronées sur l'accessibilité. tout registre ou réseau d'un DUT est accessible depuis le banc d'essai. – Serge
Quel effet cela aura-t-il si nous n'utilisons pas de modèles de registre dans notre banc d'essai? Est-ce juste d'avoir un modèle de référence pour les registres de DUT ou y a-t-il un autre but? –
@Serge Donc, vous voulez dire que tous les registres internes écrivent et lisent la valeur accessible depuis les ports de sortie d'entrée du DUT? –