urandom_range(), urandom(), random() en verilog

Je suis confus entre ces trois fonctions et je me demandais pour quelques explications. Si j'ai mis de la gamme comment puis-je faire la gamme exclusive ou inclusive? Sont les plages de inclusif ou exclusif si je n'ai pas de spécifier la plage?

Ceux-ci sont complètement spécifié dans la gratuit de la norme IEEE Std 1800-2012. Reportez-vous à la section 18.13 nombre Aléatoire des fonctions du système et des méthodes.
$urandom_range() et $urandom() sont de SystemVerilog IEEE Std 1800-2012. Verilog est son prédécesseur

OriginalL'auteur Syed Rumman | 2016-04-18

  1. 8

    En plus de la réponse de @dave_59, il y a d'autres différences importantes:

    i) $random retourne un entier signé de 32 bits; $urandom et $urandom_range retour entiers 32 bits non signés.

    ii) Le générateur de nombre aléatoire pour $random est spécifié dans La norme IEEE Std 1800-2012. Avec la même graine, vous obtiendrez exactement la même séquence de nombres aléatoires dans toute SystemVerilog simulateur. Ce n'est pas le cas pour $urandom et $urandom_range, où la conception du générateur de nombre aléatoire est à l'EDA vendeur.

    iii) Chaque thread a son propre générateur de nombre aléatoire pour $urandom et $urandom_range, alors qu'il n'est un générateur de nombre aléatoire pour $random partagé entre tous les threads (c'est à dire un seul pour l'ensemble de la simulation). Ce qui est vraiment important, parce que la séparation des générateurs de nombres aléatoires pour chaque thread vous aide à la simulation d'améliorer une propriété appelée aléatoire stabilité. Supposons que vous utilisez un générateur de nombre aléatoire pour générer des mesures de relance. Supposons que vous trouvez un bug et le corriger. Cela pourrait facilement changer l'ordre dans lequel les fils (c'est à dire initial et always blocs) sont exécutées. Si ce changement changé l'ordre dans lequel les nombres aléatoires ont été générés ensuite, vous ne savez jamais si le bug avait disparu parce que vous auriez fixe ou parce que la stimulation de l'économie a changé. Si vous avez un générateur de nombre aléatoire pour chaque thread, alors votre testbench est beaucoup moins vulnérable à cet effet, vous pouvez être beaucoup plus sûr que le bug a disparu, parce que vous avez fixé. Cette propriété est appelée aléatoire stabilité.

    Donc, Comme @dave_59 dit, vous ne devriez utiliser $urandom et $urandom_range.

    Merci pour votre perspicacité!
    Taylor - mais si il y a un problème avec un certain nombre que vous ne savez pas la graine (dans le cas de $urandom et $urandom_rang), de sorte qu'il sera diificult à repreduce le bug.
    vous pouvez définir la valeur initiale pour chaque thread.

    OriginalL'auteur Matthew Taylor

  2. 5

    Vous ne devriez utiliser $urandom et $urandom_range. Ces deux fonctions offrent une meilleure qualité de nombres aléatoires et de meilleures semences de l'initialisation et de la stabilité que $random. La plage définie par $urandom_range est toujours compris.

    Bien que $random génère exactement la même séquence de nombres aléatoires pour chaque appel, il est extrêmement difficile de garder le même appel de la commande dès qu'une modification est apportée à la conception ou le testbench. Encore plus difficile lorsque plusieurs threads simultanément la génération de nombres aléatoires.

    OriginalL'auteur dave_59