Comment les LFSR sont-ils utilisés dans des applications réelles en tant que PRNG?


8

Je programme un LFSR (Linear Feedback Shift Register) dans un logiciel à des fins d'apprentissage et j'ai rencontré certaines limitations dans son utilisation en tant que générateur de nombres pseudo-aléatoires (PRNG).

  • Si la graine a peu de bits «1» et que peu de tapotements sont utilisés, elle nécessite un «temps de démarrage» important pour produire une sortie apparemment aléatoire, avec une distribution presque égale entre les «1» et les «0» ou de courts «0». Je suppose qu'avec plus de tapotements, un tel démarrage serait beaucoup plus rapide, mais tous les tableaux précalculés que je trouve donnent deux ou quatre tapotements.
  • Les nombres séquentiels sont fortement corrélés, ce qui est normal, étant donné que si le bit de sortie est 0, le nombre suivant sera la moitié du précédent. Pour un LFSR 15 bits avec prises [15, 14], le traçage d'une paire de nombres séquentiels en tant que points dans un plan donne ce qui suit. Un PRNG idéal devrait répartir ces points partout.

image

Je sais que les LFSR sont utilisés comme compteur matériel rapide, mais j'ai également vu qu'il était utilisé comme PRNG pour créer du bruit blanc. Comment est-il utilisé dans des applications du monde réel avec une si mauvaise qualité?


Comme le souligne @rawbrawb, les LFSR ne sont pas très bons pour générer des nombres pseudo-aléatoires. Si vous n'utilisez qu'une partie du contenu du registre à décalage (par exemple, 16 bits de poids faible dans un LFSR de longueur 32 bits) comme nombre aléatoire, les choses sont bien pires. Consultez ce récent Q&R sur crypto.SE pour plus d'informations à ce sujet.
Dilip Sarwate

Réponses:


4

Une excellente source pour tout ce qui concerne PRNG est "Séquences de registre à décalage" par Solomon Golomb. Il aborde les différentes classes et techniques.

Commencer par réinitialiser tous les registres est un moyen. Ou une charge parallèle d'une graine en est une autre. Mais n'oubliez pas qu'une piqûre de tous les zéros est un état valide.

Le choix des bons codes est important car tous les paramètres de rétroaction sur un registre à décalage ne garantissent pas d'obtenir une séquence PRNG maximale.

La façon dont vous utilisez un PRNG affecte ses performances.

Pour un registre de 15 bits et la recherche des codes, [15,4] est maximal tel quel [15,1] mais [15,14] n'est pas répertorié. -> Source - "Systèmes et applications à spectre étalé" - Robert Dixon 3e éd. Pg 94. Ce livre est une très bonne référence sur la mise en œuvre.

En général, les LFSR font des PRNG pauvres et la pratique générale consiste à n'utiliser que les bits inférieurs. Alternativement, vous pouvez générer deux PRNG de longueurs et codes différents et xor les bits inférieurs pour générer le nouveau code. Il faut probablement utiliser moins de la moitié de la longueur de bit. Donc un registre de longueur de 30 et 31 bits et XOR les 15 LSB.

Le NIST a un excellent code de test ici . Alors oui, ça craint, pour les PRNG.


Si vous avez l'ensemble de robinets [nbits, a, b, c], un autre ensemble maximal est [nbits, nbits-a, nbits-b, nbits-c]. De cette façon, [15,14] et [15,1] sont maximaux.
Bruno Kim

Selon la configuration de votre registre, tout à zéro ou tout-un n'est pas valide. Dans la plupart des choses que je fais, tout zéro est invalide, mais vous l'avez noté comme valide ci-dessus, donc vous vouliez vous assurer que cela était jeté là-bas. ;)
Aaron D. Marasco

Ajout des détails sur la façon d'obtenir de meilleures performances. Mais ça ne fait pas si bien. Je les ai utilisés dans SSDS - la nature auto-corrélée. J'avais oublié les duels.
espace réservé

Idée intéressante, pour XOR différents LFSR, mais je suppose que les chiffres seraient toujours corrélés. Il est probablement préférable d'utiliser la réponse de Tim et d'effectuer un cycle complet avant de choisir un autre numéro.
Bruno Kim

@BrunoKim ce n'est pas original, c'est plus de calcul ou de zone efficace. Sa longueur de répétition serait également de 2 ^ 30ème.
espace réservé

7

Les nombres séquentiels sont fortement corrélés, ce qui est normal, étant donné que si le bit de sortie est 0, le nombre suivant sera la moitié du précédent. Pour un LFSR 15 bits avec prises [15, 14], le traçage d'une paire de nombres séquentiels en tant que points dans un plan donne ce qui suit. Un PRNG idéal devrait répartir ces points partout.

Si vous souhaitez générer des nombres aléatoires avec un LFSR 15 bits, vous ne tirez pas un nouveau nombre aléatoire à chaque cycle d'horloge. Comme vous l'avez dit puisque vous n'ajoutez qu'un nouveau bit au registre à chaque cycle d'horloge, la valeur en cycle Net N+1sera très fortement corrélée. Si vous souhaitez générer des valeurs aléatoires (en supposant que vous avez des prises appropriées), vous devez uniquement extraire une nouvelle valeur toutes les 15 horloges.

Un LFSR ne vous garantit qu'un bit aléatoire à chaque cycle, pas 15 bits aléatoires.


1
Je code pour des nombres de bits arbitraires. En général, si je veux un entier aléatoire (64 bits), dois-je utiliser un LFSR 128 bits (suivant la suggestion de rawbrawb) et faire 64 itérations avant de choisir un nombre? Un certain nombre ne manquerait-il pas, et d'autres ont pris plus de temps que prévu pour une distribution "uniforme"?
Bruno Kim

2

Un exemple réel peut être trouvé dans le manuel de référence de la famille de microprocesseurs RISC MPC7450. Le 7450 a utilisé un pRNG pour le remplacement de L2 et L3 qui est composé de 16 verrous ayant trois registres à décalage simples avec les bits 0 à 4, les bits 5 à 9 et les bits 10 à 15. Le bit 0 provient d'un XOR de bits 4 et 15, le bit 5 provient d'un XOR des bits 4 et 9, et le bit 10 provient d'un XOR des bits 6 et 15. La voie de remplacement dans les caches à 8 voies est indiquée par les bits 4, 9 et 15 pour L2 et par les bits 0 , 5 et 10 pour L3. Les bits étaient décalés à chaque cycle, mais il est évident que les remplacements de cache ne se produisaient pas aussi fréquemment. (Un autre mécanisme de remplacement basé sur des compteurs a également été fourni.)

Cela a été reconnu comme potentiellement problématique:

En raison de la latence de la recherche de cache L2, il y a 3 cycles d'horloge entre un échec de lecture et l'allocation de la ligne de remplacement. Ainsi, il serait possible que la même voie puisse être choisie pour le remplacement de deux, voire trois ratés de lecture consécutifs avec l'algorithme tel que décrit ci-dessus. Afin d'éviter cela, l'algorithme réel compare une ligne de remplacement sélectionnée avec les trois lignes de remplacement précédentes. Si la ligne sélectionnée correspond à l'une des trois précédentes, une valeur de un, deux ou trois est automatiquement ajoutée à la valeur qui sélectionne le chemin de remplacement.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.