Je dirais qu'il y a plusieurs façons de faire valoir cela. Je ne sais pas quelle est la `` meilleure '' méthode en général, cela dépendra de ce que vous essayez d'accomplir. Il est facile de tout initialiser sur le FPGA en HDL de sorte que lorsqu'il sort de la routine de configuration, tout commence à partir d'un état connu. Cependant, des réinitialisations sont généralement nécessaires, même sur un FPGA, en raison de diverses configurations de synchronisation. Dans ce cas, NE PAS initialiser les choses peut avoir plus de sens car la propagation X peut être vérifiée en simulation pour s'assurer que les réinitialisations font leur travail correctement en réinitialisant les registres appropriés.

En termes de routage, il est logique de déterminer ce qui a VRAIMENT besoin d'être réinitialisé, puis d'omettre les réinitialisations sur les choses où la configuration initiale n'a pas d'importance. Cela économisera des ressources de routage sur les FPGA et les ASIC. Par exemple, des choses comme les bus de données avec des signaux valides n'ont besoin d'aucun bus de données pour être réinitialisé, seulement les signaux valides. Si votre bus de données a une largeur de 32 ou 64 bits, seule la réinitialisation des signaux valides réduira considérablement la complexité du circuit de réinitialisation. La complexité de routage réduite peut conduire à une moindre utilisation des ressources et à une fermeture de synchronisation plus facile. Cela permet également au synthétiseur d'utiliser les entrées de réinitialisation des bascules à d'autres fins, ce qui pourrait simplifier la logique et améliorer à nouveau la zone et la synchronisation.

De plus, ce que vous réinitialisez et comment vous le faites (synchronisation vs asynchrone, réinitialisation à 0 vs remise à zéro) peut affecter la façon dont le synthétiseur peut déduire des choses comme les RAM. Les registres de pipeline dans la RAM de bloc n'ont pas nécessairement de capacités de réinitialisation ou de préchargement, donc si votre logique de réinitialisation est en conflit avec ce dont la RAM de bloc sur votre puce cible est capable, alors vos registres de pipeline ne seront pas fusionnés et vos performances de synchronisation et l'utilisation des ressources va souffrir.

Pour aucune des technologies (FPGA ou ASIC), vous ne devez vous fier à l'initialisation du signal. Si vous avez besoin de vos portes et signaux pour démarrer dans un état connu - use réinitialise.

J'ai lu que les valeurs initiales d'un signal peuvent être définies dans un FPGA car la conception y est "chargée" après la mise sous tension.

Pas nécessairement. Ce n'est pas une fonction du standard VHDL lui-même, et dépend donc du synthétiseur / FPGA. Les FPGA Xilinx et Altera prennent en charge cela, mais ce n'est pas une donnée industrielle. Par conséquent, vous devez être conscient que les conceptions qui reposent sur des initialisations sacrifient dans une certaine mesure la portabilité.

En fait, Pedroni dans Circuit Design with VHDL déclare à plat "la valeur initiale [des signaux] n'est pas synthétisable, étant uniquement prise en compte dans les simulations." réf Section 7.2

De plus, les initialisations réellement réalisées dans les configurations de fabric doivent être considérées comme asynchrones et (selon votre conception) peuvent entraîner des violations de synchronisation. Pour référence, voir page 89 de Xilinx UG470 - 7 Series FPGAs Configuration, où le document traite du séquenceur de démarrage. Plus précisément, voir la note 3:

• GWE est affirmé de manière synchrone à l'horloge de configuration (CCLK) et présente un biais significatif dans la pièce. Par conséquent, les éléments séquentiels ne sont pas libérés de manière synchrone avec l'horloge système de l'utilisateur et des violations de synchronisation peuvent se produire au démarrage. Il est recommandé de réinitialiser la conception après le démarrage et / ou d'appliquer une autre technique de synchronisation.

Cependant, dans les ASIC, nous ne pouvons compter que sur un signal de réinitialisation pour mettre tous les signaux dans un état connu.

C'est exact. Donc, si votre conception doit être portée en fabrication ASIC, vous aurez beaucoup de retouches à faire si votre conception n'utilise pas de réinitialisation.

Est-ce une bonne pratique de trouver des moyens de réduire l'utilisation du signal de réinitialisation dans la conception synchrone en ne l'utilisant pas dans certaines parties de la conception mais en l'utilisant dans d'autres?

Je dirais que cela constituerait une mauvaise pratique.Une bonne pratique serait de toujours concevoir les réinitialisations dans vos modules.Si vous décidez que vous n'avez pas besoin de les implémenter, ne les connectez pas et ils ne seront pas utilisés - mais, si vous trouvez plus tard que vos réinitialisations non connectées sont la source du bogue que vous avez recherché (pasun scénario tiré par les cheveux), il sera trivial de les connecter.

Enfin, je ferai remarquer que la conception de toutes vos réinitialisations (au lieu des initialisations) empêche les réinitialisations progressives!Comment revenir par défaut à votre état de démarrage sur les réinitialisations logicielles sans un bon modèle de réinitialisation?(vous ne le faites pas)

Analogie: est-ce une bonne pratique pour les développeurs de jeux de lancer l'état du jeu lorsqu'un utilisateur y joue? Utilisateur 1: "Woaw, j'ai commencé le jeu vers la fin et je l'ai fini ... euh ... kay", utilisateur 2: "J'ai commencé au début et j'avais tout un jeu à jouer, sympa!".

Dans ce cas, c'est very important, car cela compte beaucoup.

Si vous travaillez avec des filtres numériques, alors ce avec quoi vous initialisez les registres n'a pas vraiment d'importance parce que c'est de la merde de toute façon.

Dans ce cas, il s'agit d'not important.

En d'autres termes, it dépend d' de ce que vous faites réellement, si vous avez un système de menus ou des machines à états finis, cela généralement compte beaucoup. Cela dépend à 100% de vous ou des erreurs que vous recevez (je sais que Quartus peut générer des erreurs si vous n'initiez pas correctement les signaux).

Je vous recommande de toujours lancer lorsque le système se réinitialise, c'est une bonne conception à mon avis, je détesterais appuyer sur "reset" qui ne fait rien quand / si un système tombe en panne.

Si je vois qu'une grande partie des ressources de routage sont juste pour initier des états, alors j'acquérirais un FPGA avec plus de ressources, mais ce n'est que ma vision personnelle. Mais en fin de compte, cela dépend de vous et de votre future entreprise et de la manière dont vous allez l'utiliser. Si vous aviez été plus précis concernant votre utilisation, ma réponse n'aurait pas été aussi générale.

Aviez-vous présenté quelque chose de plus dans ce sens:

Je peux lancer chaque état de mon menu sur mon FPGA si j'achète du FPGA avec plus de ressources, cela coûtera 10 dollars de plus par unité, je vais en vendre 1000. Cela fait donc 10 000 dollars, une somme d'argent relativement importante.

Ou bien, vous n'initiez pas tous les états du menu et chaque fois que quelqu'un ouvre le menu, des choix aléatoires apparaissent et vous n'avez pas à acheter un autre FPGA. Vous économisez une somme d'argent relativement importante .

"Que dois-je faire?", alors je dirais de mettre à niveau votre FPGA car quiconque utilise votre appareil ne reviendra pas pour la prochaine version que vous vendez.Vous pouvez donc gagner beaucoup d'argent maintenant, mais perdre 99% de vos clients.

Je dis partout "FPGA" comme synonyme de FPGA et ASIC, les problèmes sont similaires sinon identiques.

Excellent message et tout le monde a donné d'excellentes réponses ici. Une réinitialisation sync / async pour initialiser les valeurs est toujours fournie pour être du côté le plus sûr, lors de la mise sous tension. Cela est particulièrement vrai dans le cas des ASIC. C'est pourquoi tous les processeurs, contrôleurs, démarrent avec une réinitialisation à la mise sous tension. Ils fournissent également un moyen d'amener le système à son état initial, à n'importe quel point de fonctionnement. Dans le cas des FPGA, la plupart des synthétiseurs synthétisent désormais les valeurs initiales, même si aucune réinitialisation n'est présente. Dans Altera, si un signal de réinitialisation asynchrone est présent, le synthétiseur est intelligent pour le trouver et initialiser les valeurs en conséquence (pas en cas de réinitialisation de la synchronisation). Si le bloc de réinitialisation et les valeurs initiales sont donnés, altera affiche un avertissement en cas de discordance entre les valeurs sous réinitialisation et les valeurs initiales. Enfin, les ressources de routage, la puissance et les performances de l'ensemble de la conception dépendent du fait que votre réinitialisation est synchrone ou asynchrone. Vous pouvez le trouver ici: http://only-vlsi.blogspot.in/2009/05/synchronous-reset-vs-asynchronous-reset.html?m=1

Pedroni aurait tort dans le contexte des FPGA basés sur SRAM, dans le contexte de l'ASIC, il aurait raison.Cependant, si vous écoutez Harry Svensson, "FPGA partout comme synonyme de FPGA et ASIC, les problèmes sont similaires sinon identiques.", Alors maintenant il a tort.

La meilleure pratique consiste à comprendre votre architecture cible, à comprendre l'utilisation à plus long terme du code que vous écrivez, à comprendre ce que le synthétiseur et le processus de configuration (dans le cas du FPGA) implémenteront avec votre RTL.Écrivez le code approprié à votre application.