Forum: FPGA, VHDL & Co. Pseudorandom-Generator mit einstellbarem Maximum


von M. Н. (Gast)


Lesenswert?

Hallo,

ich habe ein VHDL Design geschrieben, dass über einen PRSQ (pseudo 
random sequence generator) "Zufallszahlen" erzeugt (4 bit).

Das Ganze ist ein billiges Schieberegister mit ein paar ge-XODERten 
Rückkopplungen.

Ich benötige nun einen synthetisierbaren Weg, wie ich während der 
Laufzeit das Maximum der Zufallszahlen einstellen kann. Sagen wir, die 
Maximale auflösung bleibt bei 4 bit.

ein einfacher Weg, der mir eingefallen ist: Nur eine bestimmte Anzahl an 
bits als Ausgang verwenden. Dies ermöglicht die Zahlenbereiche:

0-1
0-3
0-7
0-15

Gibt es einen Weg, eine Pseudo-Zufallszahl mit präziser konfigurierbarem 
Maximum zu generieren?

Das Ganze sollte nicht allzu kompliziert sein. Wenn es keinen einfachen 
Weg gibt, werde ich auch mit meiner Version leben können.

Vielen Dank

von Duke Scarring (Gast)


Lesenswert?

Ein Komparator? Wenn der Wert zu groß ist, wegwerfen und den nächsten 
nehmen. Solange bis es passt.

Duke

von Zufallsschieber (Gast)


Lesenswert?

Eine andere Rückkopplung wählen die nicht zu einem maximal length 
sequence führt.

BTW, check mal ob dein Register tatsächlich 4 bit Auflösung hat. Wenn 
ich mich recht an die graue Theorie entsinne, darf "0000" nicht als 
Zustand vorkommen weil dann schluss mit sequence ist. Dein Generator hat 
also womöglich nur 15 Zustände.

von U.G. L. (dlchnr)


Lesenswert?

Zufallsschieber schrieb:
> BTW, check mal ob dein Register tatsächlich 4 bit Auflösung hat. Wenn
> ich mich recht an die graue Theorie entsinne, darf "0000" nicht als
> Zustand vorkommen weil dann schluss mit sequence ist. Dein Generator hat
> also womöglich nur 15 Zustände.

Das läßt sich mittels eins zusätzlichen NANDs beheben (De-Bruijn-Code):
https://asicdigitaldesign.files.wordpress.com/2008/02/4-bit_debruijn.png
https://asicdigitaldesign.wordpress.com/2008/02/15/de-bruijn-and-maximum-length-lfsr-sequences/

: Bearbeitet durch User
von gleichschenkliger Dünnwandtroll (Gast)


Lesenswert?

Man kann die Feedbacks und XOR Stellen dynamisch neu stecken..

von M. Н. (Gast)


Lesenswert?

Zufallsschieber schrieb:
> BTW, check mal ob dein Register tatsächlich 4 bit Auflösung hat. Wenn
> ich mich recht an die graue Theorie entsinne, darf "0000" nicht als
> Zustand vorkommen weil dann schluss mit sequence ist. Dein Generator hat
> also womöglich nur 15 Zustände.

Ja. Das habe ich vergessen zu erwähnen. "0000" ist die triviale Lösung 
von allen Polynomen und planzt sich nicht fort. Der Wert soll tatächlich 
auch erst bei 1 losgehen. Also kein Problem :D

Duke Scarring schrieb:
> Ein Komparator? Wenn der Wert zu groß ist, wegwerfen und den
> nächsten
> nehmen. Solange bis es passt.

Das ist leider nicht möglich. Das könnte zu lange dauern.

Mit dem PRSG werden auf der Hardware dynamisch auftretende Latenzen 
simuliert. Diese kommen im späteren ASIC durch einige Arbiter zustande. 
Da das ganze Design nicht in einen FPGA passt und auch nicht muss, 
sollen einfach, um ein wenig realistischere Verhältnisse vorzutäuschen, 
Zugriffe auf Busse dynamisch verzögert werden.

Aber ich dneke ich werde damit leben, dass ich ein breiteres 
Schieberegister nehme und dann nur x bit davon betrachte.

von Duke Scarring (Gast)


Lesenswert?

M. H. schrieb:
>> Ein Komparator? Wenn der Wert zu groß ist, wegwerfen und den
>> nächsten
>> nehmen. Solange bis es passt.
> Das ist leider nicht möglich. Das könnte zu lange dauern.
Dann pack die gültigen Werte in ein FIFO.

Duke

von Michael W. (Gast)


Lesenswert?

Spricht etwas gegen die Möglichkeit, die Werte zu skalieren?
Du bekommst Werte von 0 ... 1023 und multiplzierst mit 0,0127 und die 
Werte laufen maximal bis 12,xxx

von J. S. (engineer) Benutzerseite


Lesenswert?

Mit einer genügend hohen Auflösung der Primärwerte würde ich in der Tat 
runtermultiplizieren.
Das geht aber nicht, wenn man z.B. 16 Werte auf 13 abbilden will.

Bevor zuviel Hirnschmalz in die Implementierung eines PRNG investiert 
wird, empfehle ich, mal nach "PCG" zu googlen. Auf Github gibt es auch 
eine Implementierung für C. Ich habe Ähnliches im FPGA drin. Random 
Numbers klappt perfekt, ist aber kein gutes Rauschen, wie ich gehofft 
hatte. LFSR mit gold code und etwas EQ geht besser und einfacher.

M. H. schrieb:
> Mit dem PRSG werden auf der Hardware dynamisch auftretende Latenzen
> simuliert. Diese kommen im späteren ASIC durch einige Arbiter zustande.
Was soll damit ereicht werden? Monte Carlo?
Latenzen haben doch ihre maximale Wirkung am Rand, daher reicht in der 
Regel eine min-max Betrachtung bei der Analyse der Produktionsstreuung. 
Diese ist zudem für jedes Exemplar statisch und damit korrigierbar.

Warum wird das (so) simulationstechnisch untersucht?

von M. Н. (Gast)


Lesenswert?

Jürgen S. schrieb:
> Was soll damit ereicht werden? Monte Carlo?
> Latenzen haben doch ihre maximale Wirkung am Rand, daher reicht in der
> Regel eine min-max Betrachtung bei der Analyse der Produktionsstreuung.
> Diese ist zudem für jedes Exemplar statisch und damit korrigierbar.
>
> Warum wird das (so) simulationstechnisch untersucht?

Die einfache Antwort: es ist kaum Mehraufwand und man kann sagen, dass 
man das ganze schonmal im FPGA live gesehen hat. Es ist leider ziemlich 
ungünstig, wenn das komplette Design nicht im FPGA möglich ist. 
Simulativ kann man natürlich die Grenzfälle, wie du sagst abdecken. Aber 
Simulation und Hardware sind immer zwei paar Stiefel. Es kann durchaus 
auch mal passieren, dass die Software auf dem Prozessor, die man 
aufgrund des aufwands nicht simulieren kann, sich an einer Stelle in 
eine komische Race-Condition manövriert und etwas komisches passiert. 
Man fühlt sich ein wenig wohler, wenn das ganze 2-3 Wochen Dauertest auf 
einem FPGA übersteht.

Die letzendliche Lösung war übrigens: man nimmt ein FIFO, das mit 
Zufallszahlen gefüllt wird vom PC. Da ist dann auch die Verteilung 
besser als bei einer Pseudorandom-Zahl. Die delay-komponenten werden 
dann mit den Daten aus diesem FIFO gefüttert.

von J. S. (engineer) Benutzerseite


Lesenswert?

Meine Frage war mehr die, warum man statistische Werte nimmt und nicht 
die Extreme. Das im FPGA live zu untersuchen ist sicher im Einzelfall 
richtig, aber praktisch geht es ja darum zu prüfen, ob bei den Extremen 
der möglichen Abweichung, die herstellerbedingt auftreten können, die 
Schaltungen noch arbeiten. Das kriege ich weder im Einzeltest einer 
Schaltung noch im Dauertest heraus. Dazu wären eher Umschaltpraktiken 
interessant, die auf den Leitungen minimale und maximale Verzögerungen 
erzeugen. Für Sensoremulationen habe ich das schon so implementiert.

Eine andere Sache wäre das Rauschen, das Einfluss auf die Signalqualität 
nimmt. Das ginge aber nur in einem virtualisierten Analogmodell.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.