Hallo Zusammen, ich bräuchte für ein Memory-Spiel vorerst einemal 4 verschiedene Zufallswerte. Dazu hätte ich den angehängten Code verwendet. Das Problem ist, das er mir die Werte teilweise trotzdem doppelt ausgibt, obwohl sie ja in der if-Anweisung eigentlich ausgeschlossen werden sollten. Das ganze wird auf einem Xilinx Nexys 4 Board ausgeführt. Ich hab nun schon ewig rumprobiert, aber ich finde einfach den Fehler nicht. Ich hab auch schon while-Anweisungen verwendet, aber dann schafft er die Bedingung innerhalb 2000 Versuchen nicht und bricht ab. Das ganze soll später dann eventuell noch auf 16 verschiedene Werte erhöht werden. Die Ausgabe an die LEDs ist hier nur, damit ich seh, welche Werte generiert werden.
dann solltest du zuerst versuchen zu verstehen, was eine Hardwarebeschreibung von einer Programmiersprache unterscheidet. Beispiel: in einer Programmiersprache (z.B. in C) würde folgendes Konstrukt
1 | for b in 1 to 4 loop |
2 | if ((zaehlwertIV=zaehlwertII) or (zaehlwertIII=zaehlwertII) or (zaehlwertI=zaehlwertII)) |
3 | then
|
4 | zaehlwertII(0) <= zaehlwertII(2); |
5 | zaehlwertII(1) <= zaehlwertII(3); |
6 | zaehlwertII(2) <= zaehlwertII(0); |
7 | zaehlwertII(3) <= zaehlwertII(1); |
8 | end if; |
9 | end loop; |
bewirken, dass die Inhalte von Zählwert 4 mal durchpermutiert werden. In VHDL ist die for-Loop etwas völlig anderes: du teilst deinem Synthesetool durch diese for-loop 4 mal dassselbe mit: dass die Inhalte von zaehlwert genau ein mal neu zugewiesen werden. Ob du es ihm 4 mal mitteilst oder einmal oder 100 mal ist völlig egal: die Synthese macht daraus genau eine Neuzuweisung der Inhalte von zaehlwert (die for-Schleife ist also hier ohne Wirkung und führt nur Leute in die Irre, die VHDL mit einer Programmiersprache verwechseln ;-)
Thomas G. schrieb: > Die Ausgabe an die LEDs ist hier nur, damit ich seh, welche Werte > generiert werden. Das solltest du besser in einer Simulation sehen.
Hallo Achim S danke für dein Beitrag als Gast Wusste garnicht das ich mehrmals im Netz vorkomme Achim S
Okay, ich hatte sie vorher nicht drinnen, hat dann eben nicht funktioniert, drum dachte ich, dass es mit einer for-Schleife funktionieren könnte.. Aber auf jeden Fall danke für deinen Hinweis, weil genau damit hab ich noch Probleme, dass ich wahrscheinlich zu sehr Programmiersprachenlastig denke..
Das hier ist mehrfach kritisch:
1 | if (btnC = '0') then |
1. Tasterprellen (unschön) http://www.lothar-miller.de/s9y/categories/18-Flankenerkennung http://www.lothar-miller.de/s9y/categories/5-Entprellung 2. nicht synchronisierter Eingang in einer FSM (extrem böse) http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html Achim S. schrieb: > die for-Schleife ist also hier ohne Wirkung und führt nur Leute in die > Irre, die VHDL mit einer Programmiersprache verwechseln Wenn VHDL eine Programmiersprache wäre, würde es VHPL heißen... Thomas G. schrieb: > dass ich wahrscheinlich zu sehr Programmiersprachenlastig denke.. Du musst dir eine Schaltung "vorstellen" und die dann mit der Beschreibungssprache "beschreiben". So funktionieren VHDL und Verilog. Und hinterher im RTL-Schaltplan kontrollieren, ob der Synthesizer "deine" Schaltung aus der Beschreibung gemacht hat... BTW: häng das nächste Mal eine *.vhd oder *.vhdl Datei an. Es wird dir mit bunt markierten Code gedankt werden...
:
Bearbeitet durch Moderator
Thomas G. schrieb: > weil genau damit hab ich > noch Probleme, dass ich wahrscheinlich zu sehr Programmiersprachenlastig > denke.. das Problem haben (anfangs) nicht wenige. Den einfacheren Einstieg in die Hardwarebeschreibung hat man wahrscheinlich, wenn man keine Programmiersprache kennt und gewohnt ist, Probleme mit digitaler Hardware zu lösen (also mit Multiplexern, Logikgattern, Flipflops, ...). Dann muss man "nur noch lernen", wie diese Hardwarekomponenten in VHDL beschrieben werden und vermeidet die Fallstricke, die Fallen, die sich ergeben, weil VHLD einer normalen Programmiersprache so ähnlich sieht. Ein guter Einstieg in diese Syntheseorientierte Denke ist das Buch von Reichardt/Schwarz (VHDL-Synthese). Und auf Lothars Seite findest du sehr viele Beispiele, wie man Problemstellungen mit VHDL geschickt angeht, und welche beliebten Fehler man unbedingt vermeiden sollte. Wenn ich mich richtig entsinne hatte er darauf auch eine Empfehlungsliste für Anfänger (keine Variablen verweden sondern nur Signale, nur synchrone Designs bauen, nur einen Takt verwenden, Eingänge einsynchronisieren, ....) Wenn du dich an die Liste hältst vermeidest du wahrscheinlich >95% aller Fehler, die dir ansonsten den Einstieg schwer machen.
Achim S. schrieb: > Wenn ich mich richtig entsinne hatte er darauf auch eine > Empfehlungsliste für Anfänger Ach, du meinst meine "Postulate". Ich traue mich nicht mehr, sie laufend zu wiederholen... ;-) Einfach mal die Suche anklicken: https://www.mikrocontroller.net/search?query=postulate&forums[]=9&max_age=-&sort_by_date=1
:
Bearbeitet durch Moderator
Eine kleine Suche in Google liess mich dies hier finden: http://www.technik-emden.de/~rabe/veranstaltungen/Digitaltechnik/Praktikum/PraktDigi_V5_FPGA_PRNG.pdf und auch hier ist was zu lesen Digitaler Zufallszahlengenerator in VHDL
Beschreibe doch mal, was dein Design machen soll. Da findet sich bestimmt ein grundlegend besserer Ansatz. Irgendwas soll mit einem Tastendruck passieren... aber was?
Vielen dank erstmal an alle für die Antworten. Die for-Schleife ist auch schon wieder aus dem Code verschwunden;) Das Programm soll folgendes machen: Sobald ich die Taste btnC drücke, soll mir das Programm die Zahlen "durchzählen" und sobald ich von der Taste runtergehe, sollen dann 4 VERSCHIEDENE Zufallszahlen übrig bleiben. Dadurch, dass ich ja bei 100Mhz eigentlich nie gleich viel Impulse von der Clock bekomme, ist es ja quasi mehr oder weniger zufällig. Also ich habe es vorher in einem anderen Code ausprobiert (ohne for-Schleife :P) und da ging es halt z.B. dann mit einem 16er-Bit-Vektor, dass ich eben einmal beim 12. oder beim 4. usw.. Bit stehen geblieben ist. Also da Tat das Programm genau das, was ich wollte. Also das Problem ist eben nicht eine einzelne Zufallszahl zu erzeugen. Sondern: die Zahlen werden zwar "durchgwürfelt", aber ich erhalte trotz der if-Bedingungen teilweise 2 oder 3 gleiche Zahlen. Was eben nicht sein sollte. Liegt das nun wirklich an den nicht entprellten Tasten und dem nicht synchronisierten Eingang, oder liegt der Fehler irgendwo bei den if-Bedingungen? Oder hat jemand konkret ganz andere Lösungsansätze?
1. Schaltung mit entprelltem Taster, die ein enable macht 2. Zähler, der bei Tastendruck rennt 3. Eine Pipeline aus 4 Registerwerten mit einem eigenen enable 4. Schaltung, die bei wegehendem enable1 diesen Zähler in die pipe schiebt Wenn die Zufallszahlen verschieden sein sollen, musst Du sortieren.
EINE Zufallszahl per Tastendruck zu erzeugen ist sehr einfach: Man benötigt einen Zähler, der zählt, wenn die Taste gedrückt ist und stoppt, wenn man die Taste loslässt. Da der Mensch nicht auf 10ns genau reproduzierbar drücken und loslassen kann, ist das auf jeden Fall zufällig. Entprellt werden muss dazu der Taster nicht. Ist doch völlig schnurz, ob der Zähler nach dem Loslassen noch zwei oder dreimal um ein paar Schritte weiter zählt und dann stehen bleibt. Aber SYNCHRONISIERT werden sollte der Taster schon. Für 4 Zufallszahlen, die dann auch noch untereinander zufällig sein sollen, wird das ganze komplizierter. Man könnte vier Zähler nehmen. Laufen die mit gleichem Takt, sind die Zahlen untereinander immer gleich Laufen sie mit unterschiedlichem Takt, wiederholt es sich auch irgendwann. Du hast aber nur ein unabhängiges Ereignis (Tastendruck), möchtest aber vier unabhängige Zufallszahlen erhalten. Das wird meines Erachtens nicht ganz einfach... Du könntest mit vier Tastern arbeiten (Willst du aber vermutlich nicht). Oder mit einem Taster hintereinander die vier Zahlen "erzeugen" (Willst du aber vermutlich auch nicht) Der "Zufall" entsteht durch die Kombination aus Takt und Dauer des Tastendrucks. Da aber deine Zähler alle von dem selben Takt (oder einem davon abgeleiteten) versorgt werden und alle Zähler mit der selben Tastendruckdauer "bedient" werden, sehe ich auf den ersten Blick nicht, wie da vier wirklich unabhängige Zufallszahlen rauskommen sollen. Vielleicht hat da aber jemand eine clevere Idee. Aber ich habe eh den Eindruck, dass du noch grundlegende Verständnisprobleme von HDL an sich hast. Oder weißt du, wie man einen Zähler in HDL beschreibt?
wie oben schon erwähnt, "LFSR" heißt das Zauberwort. Für so ein Memory-Spiel müssen's ja nicht unbedingt "echte" Zufallszahlen sein. Ein simples, linear rückgekoppeltes XOR-Schieberegister dürfte ausreichen.
1 | ARCHITECTURE rtl OF test IS |
2 | SIGNAL clk : std_logic := '0'; |
3 | SIGNAL lfsr : std_logic_vector(15 DOWNTO 0) := 16d"11"; |
4 | BEGIN
|
5 | p_random : PROCESS |
6 | BEGIN
|
7 | WAIT UNTIL rising_edge(clk); |
8 | |
9 | lfsr <= (lfsr(0) xor lfsr(1)) & lfsr(15 DOWNTO 1); |
10 | END PROCESS p_random; |
11 | END rtl; |
lfsr wird einmal mit dem Seed initialisiert (der kommt aus dem Tastendruck), kann jeder beliebige Wert außer 0 (sonst springt die Sache nicht an) sein. Nach 4 clocks hat man vier "Zufallszahlen", die zwar nicht wirklich zufällig, dafür aber garantiert unterschiedlich sind.
Guter Ansatz! Der Seed kommt aus der Dauer des Tastendrucks und nach Loslassen der Taste spendiert man vier Takte und schubst den Seed durch das LFSR.. Das müsste "zufällig" genug sein..
Markus F. schrieb: > aber garantiert unterschiedlich sind Aber aufpassen: Das gilt nur, wenn du alle 16 Bit gleichzeitig betrachtest. Wenn Du jetzt aber ein 4-Bit-Subset daraus verwendest, kann es durchaus sein, dass sich da was wiederholt innerhalb der 4 Worte.
Dann nimmt man halt ein vier Bit LFSR: http://inst.eecs.berkeley.edu/~cs150/sp03/handouts/15/LectureA/lec27-6up
Markus F. schrieb: > die zwar > nicht wirklich zufällig, dafür aber garantiert unterschiedlich sind ... die sind dann aber immer in derselben Reihenfolge, oder?
Markus F. schrieb: > Nach 4 clocks hat man vier "Zufallszahlen", die zwar > nicht wirklich zufällig, dafür aber garantiert unterschiedlich sind. Mal rein interessehalber: warum ist das garantiert?
Das ist das Wesensmerkmal dieser Ereugungsmethode. Es werden alle möglichen Werte geliefert und es kommt kein Wert zweimal. Allerdings ist genau das das Problem solcher Zufallsfolgen. In der Realität kommen nämlich durchaus auch einmal mehrere male dieselben Werte.
FPGA-Ingenieur schrieb im Beitrag #4344077: > ... die sind dann aber immer in derselben Reihenfolge, oder? Ein 4-Bit LFSR weiderholt seine "Zufallszahlen" nach 15 Zyklen. Nur der Wert 0000 kommt nicht vor. Das ist nicht wirklich "zufällig", sondern ganz leicht zu durchschauen. Dort beim 8-Bit LFSR sieht man schon an der Waveform wie sich die "Zufalszahlen" 2,5 zyklisch wiederholen. Ich würde daher ein 16 Bit LFSR nehmen, da wiederholt sich wahrnehmbar nichts und der Wert 0000 kommt durchaus vor, wenn nur 4 Bits aus den 16 betrachtet werden.... Thomas G. schrieb: > Das Programm soll folgendes machen: ... Weil VHDL keine VHPL ist, ist das kein Programm, sondern eine Beschreibung... Thomas G. schrieb: > Sobald ich die Taste btnC drücke, soll mir das Programm die Zahlen > "durchzählen" und sobald ich von der Taste runtergehe, sollen dann 4 > VERSCHIEDENE Zufallszahlen übrig bleiben. Dieses Konzept wiederspricht eigentlich einer "Zufallszahl", denn ganz zufällig könnten 2 Zahlen ja auch mal gleich sein... Bei 8 Bit Zufallszahlen passiert es da relativ oft, dass mindestens 2 gleiche Zahlen herauskommen. Thomas G. schrieb: > Oder hat jemand konkret ganz andere Lösungsansätze? Hast du zur Ermittlung dieser Zufallszahl ein paar Taktzyklen Zeit? Denn wenn da ein Taster mit im Speil ist, dann müssen die 4 Zahlen doch nicht in 10ns (bei einem 100MHz Takt) ermittelt werden, oder?
Hmmm.. Wenn man eine Zufällige Zahl (der Seed aus dem Counter) in das LFSR lädt und dann vier mal schiebt, dann kommen zwar unterschiedliche Zahlen raus, aber erzeugt nicht ein identischer Seed dann auch immer die identische Zahlenkombination nach der gleichen Anzahl von Shifts? Seed X erzeugt bei: erstem Shift: Z1 zweitem Shift: Z2 drittem Shift: Z3 viertem Shift: Z4 Wird das LFSR erneut mit X geladen, so erzeugt es die identischen Ergebnisse für Z1...Z4 Richtig? Somit wären nicht alle Kombinationen von Ausgangswerten möglich. Oder sehe ich da gerade was falsch?
Lothar M. schrieb: > Ich würde daher ein 16 Bit LFSR nehmen, da wiederholt sich wahrnehmbar > nichts und der Wert 0000 kommt durchaus vor, wenn nur 4 Bits aus den 16 > betrachtet werden.... Nur must Du dann das Problem der gleichen Zahlen wieder zusätzlich lösen. Angenommen, der aktuelle Stand des LFSR sei 0xAAAA und man nehme Bits [3:0]. Dann wird dort während 12 Zyklen nur 0xA wechselnd mit 0x5 zu lesen sein. Die 4 "Zufallszahlen" wären also 10,5,10,5.
P. K. schrieb: > Nur must Du dann das Problem der gleichen Zahlen wieder zusätzlich > lösen. Klar. Das bleibt unbenommen. Deshalb meine Frage, ob ich da evtl. einfach mal "weiterwürfeln" könnte. Wenn für die Reaktion 10us ausreichen, dann könnte ich bei Zahlengleichheit und 100MHz Takt einfach noch bis zu 1000 Mal weiterwürfeln. Und als Notbremse einfach Z, Z+1, Z+2 und Z+3 als "Zufallszahl" zurückgeben...
Man könnte eine rundlaufenden Zähler nehmen. Mit dem Drücken der Taste zieht man eine Kopie des aktuellen Zählerstandes. Das ist dann die erste Zufallszahl(Z1) Mit dem Loslassen der Taste zieht man wieder eine Kopie des rundlaufenden Zählers. Das ist dann die zweite Zufallszahl(Z2). Damit hätte man mal zwei wirklich zufällige Zahlen. Wie kommen wir aber auf die fehlenden zwei? Wäre es ein Ansatz, Z1 als Seed für das LFSR zu nehmen und dies so lange shiften zu lassen, bis die Taste losgelassen wird und dann in dem Moment, wo Z2 erzeugt wird, aus dem LFSR Z3 zu ziehen? Analog dazu wird beim Ziehen von Z2 das LSFR mit Z2 geladen und der Wert nach aus dem LSFR als Z4 gezogen, wenn Z1 aus dem Counter gezogen wird. Sind die Werte dann aber wirklich unabhängig? Die Anzahl der Shifts, die zur Erzeugung der Werte aus dem LFSR zufällig aufgrund der Zeiten zwischen den Flanken von BTN entstehen, sind identisch mit der Anzahl der Zählerschritte zwischen Z1 und Z2
Falls das jetzt schwer verständlich war, was ich geschrieben habe: Ich meine folgenden Ablauf: Warte auf steigende Flanke(BTN) Z1 = aktueller Timer-Wert Z4 = aktueller LFSR-Wert Lade LFSR mit aktuellem Timer-Wert Warte auf fallende Flanke(BTN) Z2 = aktueller Timer-Wert Z3 = aktueller LFSR-Wert Lade LFSR mit aktuellem Timer-Wert Gebe Z1...Z4 aus
Die Frage betrifft ein Memory-Spiel. Keine AKW-Steuerung. Man kann's auch übertreiben ;) Bei Memory geht's (jedenfalls wenn's das Memory ist, das ich kenne) darum, 32 Kartenpärchen zufällig zu verteilen, also 64 Karten zufällige, eindeutige Positionen zuzuweisen. Beim Austeilen brauche ich bei der ersten Karte eine Zahl zwischen 0 und 63, bei der zweiten eine zwischen 0 und 62, bei der dritten eine zwischen 0 und 61 u.s.w. (d.h. die schon belegten Felder werden einfach nicht mehr mitgezählt). Dann kann man auch einen 16- oder gar 32-Bit Generator verwenden, weil "doppelte" Zufallszahlen keine Rolle mehr spielen. Dabei ist die Anzahl der möglichen 6-Bit Sequenzen dann so hoch, daß man nicht mehr von einer Zufallszahl auf die nächste schließen kann.
:
Bearbeitet durch User
@Lothar Miller: Nein die muss nicht sofort nach 10ns da sein, also es wäre kein Problem wenn ich da 50ms oder 500ms warten müsste. An alle Anderen: Danke für die vielen Ratschläge und Tipps, ich werde das die nächsten Tage mal durchgehen, und versuchen dadurch zu einem Ergebnis zu kommen.
Moin, noch eine Idee: Mehrere Zähler mit unterschiedlichen "Frequenzen" zählen lassen: Z1 jeden 3ten Takt Z2 jeden 5ten Takt Z3 jeden 7ten Takt Z4 jeden 11ten Takt ggf. weitere Zähler mit anderen Vorteilern, damit Du zusätzliche Werte zum Aussortieren der Dupletten hast. Man könnte auch durch die Summe oder einer xor Verknüpfung der Zählerstände weitere "Zufallszahlen" generieren. Gruß fpga-ing
FPGA-Ingenieur schrieb im Beitrag #4344077: > Markus F. schrieb: >> die zwar >> nicht wirklich zufällig, dafür aber garantiert unterschiedlich sind > > ... die sind dann aber immer in derselben Reihenfolge, oder? Ja, aber Du weisst zu viel über wie der Zufallsgenerator "würfelt". Jetzt stell dir vor, dein Wissen beginnt bei einem unbekannten Startpunkt in der der Folge und du startest deine Beobachtung. Dann ist es für dich Zufall. Es wird hier auch von einem Pseudzufallsgenerator gesprochen. Wenn die intern XOR Rückführung nicht genau bekannt ist, praktisch eine Black box für den Betrachter ist, dann ist es ein Zufallsgenerator. Das es ein Zufallsgenerator wird, muss jede Umsetzung eine andere XOR Verknüpfung nutzen, dann "würfelt" jeder Generator eine andere Folge. Die Folge muss dann beobachtet werden und bei 32bit sind das eine Menge Zahlen und wären dann zu analysieren. Dann würde man es Herausbekommen, dass es kein wirklicher Zufall ist. Der Zufallsgenerator kann auch intern eine größere Bitbreite haben als nach Außen sichtbar sind. z.b. intern 32bit und 8 bit output. Es gibt auch andere mathematische Möglichkeiten, das XOR Register ist die einfachste Form eines Zufallsalgorithmuses, der sich mit Digitalgattern umsätzen lässt.
René D. schrieb: > > Der Zufallsgenerator kann auch intern eine größere Bitbreite haben als > nach Außen sichtbar sind. > z.b. intern 32bit und 8 bit output. > Das muß er auch, damit's einigermaßen vernünftig "zufällig" wird. Der "interne" Zahlenraum muß wesentlich größer sein als der, der nach außen gegeben wird. Bei einem 6-Bit-Register z.B. wiederholt sich - unabhängig vom Seed, der ja nur den Einstiegspunkt bestimmt - die Sequenz alle 64 Durchläufe. Wenn man sie einmal kennt, kann man von einer "Zufallszahl" auf die nächste schließen. Bei einem 16-Bit Register, von dem nur 6 Bit verwendet werden, habe ich in diesen sechs Bit alle möglichen unterschiedlichen Sequenzen, die ich mir merken müsste. Damit wird's (zumindest für ein Spiel) erst ausreichend "zufällig".
Markus F. schrieb: > Bei einem 6-Bit-Register z.B. wiederholt sich - unabhängig vom Seed, > der ja nur den Einstiegspunkt bestimmt - die Sequenz alle 64 Durchläufe. Diese Pseudo -Zufallszahl wiederholt sich sogar schon alle 63 Durchläufe, denn den Wert 0 gibt es nicht...
Ich sehe hier nicht unbedingt das Problem, einen Zufallsgenerator zu bauen, der ausreichend unvorhersehbar ist. Ich sehe eher das Problem, 4 unabhängige Zufallszahlen zu erzeugen, die auf einem GEMEINSAMEN, IDENTISCHEN Seed beruhen. WELCHES Quadrupel kommt, ist zufällig, aber die Elemente eines Quadrupels sind dann immer die gleichen. Und die generierbaren Quadrupel sind dann nur eine Teilmenge der mathematisch möglichen Qadrupel. Dazu müsste man jetzt aber mal wissen, warum überhaupt für ein Memory ein Quadrupel aus Zahlen nötig ist und nicht ein Paar. Und dann müsste man wissen, ob es nötig ist, dass alle Kombinationen innerhalb eines Quadrupels gleich wahrscheinlich sein sollten. Annahme 1: Man baut für jede Zahl ein eigenes LFSR mit unterschiedlicher Rückkopplung. Dann füttert man die 4 LFSR mit dem identischen seed. Dann kommen nach n Takten (bei allen LFSR) aus jedem LFSR immer das gleiche, reproduzierbare Ergebnis heraus. Fügt man diese vier Zahlen dann zu dem Quadrupel zusammen, so kann man sagen, dass ein (zufälliger) Seed IMMER zum identischen Quadrupel führt. Annahme 2: Man hat nur eine LFSR und taktet das vier mal.. auch hier kommt dann immer das identische, reproduzierbare Quadrupel heraus. Es gilt also auch hier: Jedem Seed ist ein fixes Quadrupel zugeordnet.. Damit sind die 4 Elemente des Quadrupels untereinander nicht zufällig kombiniert. Und ich denke, darum geht es vermutlich beim Memory.. Und das hat nix mit AKW-Technik oder nicht zu tun.. ein Spiel, wo alle Kombinationen auftreten können sollten, dies aber technisch bedingt nicht tun können, funktioniert dann einfach nicht. Wenn beim Mäxle-Würfelspiel bestimmte Würfelkombinationen nicht auftreten können, dann ist das Spiel einfach nicht spielbar. Egal, wie vorhersehbar die Zufälligkeit der Kombinationen ist, die auftreten können. Wenn es z.B. das "Mäxle" (21) nie geben kann, dann funktioniert das Spiel nicht :-(
Schlumpf schrieb: > Annahme 2: > Man hat nur eine LFSR und taktet das vier mal.. > auch hier kommt dann immer das identische, reproduzierbare Quadrupel > heraus. > Es gilt also auch hier: Jedem Seed ist ein fixes Quadrupel zugeordnet.. Wie würde man diese erzeugen? Wenn als Beispiel 16 Bits benötigt werden, einfach 16 parallele Generatoren? Oder lieber Dezimieren, wie es in einigen Artikeln beschrieben steht? Macht es Sinn, den Abgreifpunkt der Bits zu rotieren?
Schlumpf schrieb: > Man baut für jede Zahl ein eigenes LFSR mit unterschiedlicher > Rückkopplung. Eher das! und zwar mit Taktgeneratoren, die nichts miteinander zu tun haben. Trotzdem werden die Zahlen nicht völlig zufällig sein und ich bin sicher, dass sich das mathematisch auch durch ein einzige LFSR beschreiben liesse.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.