Combler les lacunes sur Verilog/System Verilog

Question

J'ai passé en revue quelques tutoriels Verilog et passé en revue les sujets quelques fois et quelques questions me trottaient dans la tête depuis que les concepts ont été introduits et si quelqu'un pouvait les éclairer. eux, ce serait très utile.

1. Quel est le but de la force sur un filet?

2. Souvent, dans les paramètres d'exemples, les noms exacts sont utilisés pour décrire également les registres. Par exemple:

   module x (…,in1,…); 
   … 
   input in1; 
   reg [7:0] in1; 
   … 
   endmodule 
   

   Est-ce que cela déclare le port d'entrée comme un type de données ou sont-ils distincts? Si le premier est vrai, quels autres types de quantités puis-je faire avec (entiers, scalaires, etc.)? Si ce dernier est vrai, à quel article je fais référence quand je dis "in1" à l'intérieur du module?

3. Les blocs initiaux au début d'une simulation sont tous exécutés en "parallèle" mais lorsque vous êtes à l'intérieur du bloc, les instructions sont exécutées en série. Est-ce que l'outil de simulation que vous utilisez détermine dans quel ordre les instructions exécutées en série sont faites? Par exemple, vous avez 2 blocs initiaux, exécutons-nous tous en premier, ou sautons-nous d'avant en arrière?

4 .Quelles sont les valeurs initiales dans la simulation X? Si le travail de Verilog est de représenter la vie réelle, pourquoi n'a-t-il pas un moteur pseudo-aléatoire et sélectionne le même ordre aléatoire de bits pour toutes les valeurs au début? Vous rencontrez beaucoup de problèmes avec des avertissements de déclaration de cas uniques et cela semble être un défaut de conception ou au moins une incongruité entre le système Verilog et Verilog.

Answer 1

1. Vous permet d'avoir plusieurs pilotes sur un réseau et de déterminer la valeur du signal résultant; voir 7.10 dans le LRM
2. Ils sont tous les mêmes in1 - très verbeux. En V-2001, vous pouvez écrire un seul input reg[7:0] in1 dans la liste des ports à la place. Vous pouvez le faire pour tout ce que vous connectez via un port.
3. Notez que les initiales ne sont pas garanties d'être exécutées avant toujours, et il n'y a pas d'ordre d'exécution garanti entre les blocs initiaux/toujours dans votre conception. En pratique, le simulateur choisit un bloc et l'exécute jusqu'à ce qu'il atteigne un point de suspension (un contrôle de temporisation), à quel point le sim programme une autre initiale ou toujours, et l'exécute jusqu'à ce qu'il soit suspendu, et ainsi de suite.
4. C'est essentiellement de la philosophie, mais pourquoi voudriez-vous attribuer des valeurs aléatoires initiales à quoi que ce soit? C'est essentiellement ce que signifie 'inconnu' (X) (ou Z pour les filets). Si tout est X ou Z au début du temps, alors vous savez qu'il n'est pas initialisé et le restera jusqu'à ce que vous fassiez quelque chose. Si l'outil donnait toutes les valeurs initiales aléatoires initiales, vous ne le sauriez jamais.

Answer 2

1. En cas d'une force de contention aide à résoudre à une valeur connue. La dernière fois que j'ai vu quelque chose comme ça dans un design, c'était il y a 10 ans. Et même alors, il était considéré comme une mauvaise pratique de conception.

2. Comme le dit EML. Non et Non. Les instructions de tout bloc procédural tel que le bloc initial sont exécutées séquentiellement dans le même intervalle de temps. Les blocs initiaux commencent l'exécution à l'instant 0. Le simulateur exécute toutes les instructions dans l'ordre où elles apparaissent dans le bloc initial, conformément à la file d'attente des événements Verilog. Les variables sont mises à jour selon le calendrier dicté par la file d'attente des événements.Tout cela fait partie de la norme (LRM 8.10). Si vous n'êtes pas familier avec la file d'attente des événements verilog et la notion de créneaux horaires et de temps de simulation, alors Cliff Cumming's paper est une excellente référence. Cela n'a pas d'importance si le simulateur exécute les instructions de différents blocs initiaux entrelacés ou de toute autre manière. Le temps de simulation ne progresse pas et les variables sont uniquement mises à jour en fonction de la file d'attente des événements.

   Ce qui n'est pas standard est le bloc initial dans lequel le simulateur doit commencer. Cela devient important car cela crée une dépendance sur le simulateur si des variables sont affectées dans un bloc initial et utilisées dans l'autre bloc de procédure dans la même file d'attente d'événements. L'article de Cumming cité plus haut explique très bien ce scénario.

3. Il ne s'agit pas seulement de l'état non résolu du réseau. Mais aussi sur le démarrage de la simulation à partir d'un état prévisible. Par conséquent, le choix aléatoire de l'état résolu des entrées dans la conception ne fournirait pas la prévisibilité nécessaire pour démarrer le simulateur à partir du même point à chaque fois. En plus de la suggestion d'EML, vous pouvez utiliser les types de données à 2 états fournis dans SystemVerilog. Bien sûr, ceux-ci ne sont pas synthétisables. Parce que, pour modéliser avec précision le matériel, vous voulez que l'état de sortie soit inconnu si les entrées sont inconnues.