Écritures internes pour créer un environnement de vérification (commencer à créer un environnement à partir de 0)

1. Quatre éléments de construction environnementale

Avant d'envoyer la séquence de test, vous devez d'abord créer un environnement structuré et démonter les éléments centraux de l'établissement de l'environnement, qui peuvent être divisés en quatre parties :

• Propriétés de fermeture automatique des composants de l'unité
• création de régression
• Connexion du port de communication
• configuration de niveau supérieur

2. Fermeture automatique des composants de l'unité

La fermeture automatique signifie que les composants unitaires (tels que uvm_agent ou uvm_env) peuvent devenir des comportements indépendants et ne dépendent pas d'autres composants parallèles. Par exemple, entre le pilote et le séquenceur, bien que le pilote ait besoin d'obtenir l'élément de transaction du séquenceur, il peut s'instancier indépendamment, et la communication entre eux est également réalisée sur la base de la connexion de bout en bout TLM. La nature à fermeture automatique de ce composant d'unité constitue une bonne base pour la réutilisation ultérieure des composants, et chaque sous-environnement peut également être intégré indépendamment dans l'environnement de niveau supérieur sans nécessiter de connexions de communication supplémentaires.

3. Création de régression

De cette manière de création de régression, une fois que le composant de niveau supérieur s'est instancié (exécuté la fonction new()), il exécutera chaque étape de phase. Grâce à build_phase, les sous-composants peuvent être créés davantage, et ces sous-composants sont également créés par le même processus.composants de niveau supérieur.

La raison pour laquelle la création de régression peut être réalisée dépend de la build_phase de l'ordre d'exécution descendant. La séquence d'exécution structurée de build_phase peut garantir que le composant parent doit être créé avant le composant enfant, et le processus de création comprend également :

• Attribuez une valeur par défaut lors de la définition d'une variable membre ou attribuez une valeur initiale dans la fonction new().
• Les variables de configuration structurelles sont utilisées pour déterminer la génération conditionnelle des composants. Par exemple, uvm_agent s'appuie sur la variable is_active pour déterminer si uvm_sequencer et uvm_driver doivent être instanciés.
• Les variables de configuration de mode sont utilisées pour déterminer le mode de fonctionnement de chaque sous-composant.
• Les sous-composants sont générés séquentiellement de haut en bas et d'avant en arrière.

4. Connexion du port de communication

Une fois l'ensemble de l'environnement créé, chaque composant effectuera la communication de données via la connexion du port de communication. Les utilisations courantes de la communication par port incluent :

• Le port du pilote est connecté au séquenceur, et l'élément de transaction est acquis sous forme de pull bloquant pour le séquenceur.
• Le port du moniteur est connecté au fifo d'analyse à l'intérieur du tableau de bord et les données surveillées y sont écrites.

5. Configuration de niveau supérieur

Formellement, en raison de la nature à fermeture automatique des composants de l'unité, la structure UVM ne recommande pas de se référer aux descripteurs de sous-environnement, puis d'indexer des variables plus profondes pour la configuration de niveau supérieur. Cela augmenterait la rigidité de l'environnement de niveau supérieur et des sous-environnements. , et ne peut pas obtenir une meilleure séparation.

Une meilleure méthode consiste donc à transmettre l'objet de configuration au sous-environnement en tant que partie liée à l'environnement de niveau supérieur, et chaque composant du sous-environnement peut obtenir ses propres paramètres de configuration à partir de l'objet de configuration structuré, de manière à build_phase , connect_phase et run_phase pour déterminer leur structure et leur mode de fonctionnement.

L'objet de configuration de niveau supérieur peut être configuré dans le sous-environnement qui sera créé ultérieurement lorsque le sous-environnement n'est pas instancié, sans considérer que l'objet de configuration de niveau supérieur sera généré avant le sous-environnement, ce qui également fournit une méthode de configuration sécurisée pour la structure de vérification UVM :

• Quelle que soit la couche de configuration utilisée, vous devez essayer de placer toutes les configurations avant la création des sous-composants pour vous assurer que la configuration est terminée.
• La portée de la configuration doit se concentrer uniquement sur le niveau actuel et inférieur, et ne pas impliquer de niveaux supérieurs.
• La structure de l'objet de configuration doit être aussi indépendante que possible, formant de préférence une structure arborescente comme la structure de l'environnement. De tels objets de configuration indépendants correspondront à des sous-environnements indépendants. Si les configurations indépendantes sont fusionnées dans une structure de configuration arborescente de niveau supérieur, les objets de configuration de niveau supérieur seront alors plus faciles à utiliser et à maintenir.
• En raison de la fonctionnalité de configuration de config_db, la configuration de haut niveau couvrira la configuration sous-jacente, ce qui permet également à la configuration effectuée au niveau uvm_test de contrôler la structure et le mode globaux.

Schéma fonctionnel de configuration de niveau supérieur

6. Classification des éléments environnementaux

 Dessinez la couche uvm_test à un niveau supérieur à uvm_env, car la couche uvm_test aura certaines parties de configuration transmises au sous-environnement. En incluant le composant uvm_component qui constitue l'environnement, les éléments d'environnement peuvent être divisés en les parties suivantes :

• Variables membres : variables générales, variables de structure, variables de modèle.
• Sous-composants : composants fixes, composants conditionnels, composants de référence.
• Objets enfants : objets auto-générés, objets clonés et objets référencés.

Variables membres

• Les variables générales sont utilisées pour des opérations à l'intérieur d'objets ou pour fournir des valeurs d'état pour un accès externe.
• Les variables structurelles sont utilisées pour déterminer si des sous-composants internes doivent être créés et connectés. Par exemple, la variable is_active de niveau supérieur est utilisée à cette fin.
• Les variables de mode sont utilisées pour contrôler le comportement des composants. Par exemple, les variables de pilote peuvent être configurées en mode pour créer différents comportements d'incitation dans run_phase.
• Pour les variables de structure et les variables de mode, elles sont généralement définies par des types int ou enum et peuvent être directement définies dans la couche uvm_test via la méthode de configuration de uvm_config_db, ou la configuration du système peut être effectuée via des objets de configuration structurés. Pour les environnements d'authentification complexes, l'objet de configuration sera facile à utiliser et à maintenir.

Sous-ensemble

• Les composants qui doivent être créés dans l'environnement sont appelés composants fixes. Par exemple, le moniteur dans l'agent doit être créé indépendamment du mode actif ou du mode passif, ou le tableau de bord dans l'environnement de niveau supérieur doit également être créé. pour comparer les données.
• Le composant conditionnel est déterminé par la configuration de la variable de structure si elle doit être créée. Par exemple, le séquenceur et le pilote ne peuvent être créés qu'en mode actif.
• Un composant de référence déclare un handle de type en interne et le transmet via un handle descendant afin que le handle puisse pointer vers un objet externe. Par exemple, dans la couche uvm_test, un modèle de registre rgm (composant fixe) est d'abord instancié, puis le handle du modèle est transmis au handle rgm (composant de référence) dans la couche reg_env via la configuration. En utilisant la méthode de référencement des composants, tous les niveaux de l'environnement peuvent partager un composant si nécessaire.

objet enfant

• Un objet est d'abord créé dans un certain calque, que l'on peut appeler un objet auto-généré.
• Lors du transfert d'objet, l'objet est cloné pour générer un objet avec les mêmes valeurs de membre, appelé objet cloné.
• Si l'objet est transféré via le port et atteint un autre composant, et que le composant opère directement sur lui sans clonage, on parle d'opération de référencement de l'objet. Par exemple, la séquence virtuelle générera des éléments de transaction envoyés à reg_master_agent et reg_slave_agent, qui sont respectivement mst_t et slv_t. Ceux-ci envoyés en continu mst_t et slv_t passent par uvm_sequencer et atteignent finalement uvm_driver. Une fois que uvm_driver a obtenu ces objets de transaction, c'est un moyen de les cloner d'abord, puis d'utiliser les objets de données clonés comme incitations ; uvm_driver peut également opérer directement sur ces objets (objets de référence) sans cloner les objets de données.