Hallo, für ein FH-Projekt sollen wir einen TRNG (True Random Number Generator) auf einem FPGA-Board realisieren. Erfahrung haben wir mit VHDL und weniger mit Verilog. Vielleicht hat ja jemand in diesem Forum diesbezüglich Erfahrung und kann mir und meiner Projektgruppe zu einem Board raten oder zumindest einen Rat geben auf welche "featues" wir beim Kauf achten sollen. Unser Budget beträgt beträgt 300€. Grüße Georg
Georg Weber schrieb: > Hallo, > für ein FH-Projekt sollen wir einen TRNG (True Random Number Generator) > auf einem FPGA-Board realisieren. > Erfahrung haben wir mit VHDL und weniger mit Verilog. > Vielleicht hat ja jemand in diesem > Forum diesbezüglich Erfahrung und kann mir und meiner Projektgruppe > zu einem Board raten oder zumindest einen Rat geben auf welche > "featues" wir beim Kauf achten sollen. ?Bist Du sicher das ihre True Random und nich Pseudo-Random generieren wollt? Mit FPGA erzeugt man Pseudo-random über ein LFSR und dafür genügt ein kleiner FPGA aus dem letzten Jahrtausend. https://en.wikipedia.org/wiki/Linear-feedback_shift_register
Ja ich bin mir sicher. Es gibt verschiedene Methoden um einen True Random Number Generator auf einem FPGA zu realisieren. Hier sind ein paar Mehtoden erläutert: https://tu-dresden.de/ing/informatik/ti/vlsi/ressourcen/dateien/dateien_studium/dateien_lehstuhlseminar/vortraege_lehrstuhlseminar/folder-2012-03-21-5634987295/On-the--Fly-Evaluation.pdf?lang=de
Die Hardware (Board + verbauter FPGA) hängt von Eurer Anwendung ab. Je nach dem, welchen Effekt Ihr für die TRNG nutzen wollt, braucht das Board entsprechende Schnittstellen und der FPGA braucht abhängig von der Anzahl und der Komplexität der Berechnungen entsprechende Ressourcen (DSP-Blöcke, RAMs etc.). Dann kommt noch die Geschwindigkeit dazu. Das sind so die Mindestinfos, die man haben sollte, um über die Hardware nachzudenken. Auswahl gibts es in Eurem-Budgetrahmen mehr als genug, nur werden die kleinsten/günstigsten/leistungsschwächsten Boards bzw. FPGAs nicht unbedingt jeder Art von TRNG unterstützen. Soll es aber einfach nur eine FPGA-Schaltung sein, die Zahlen erzeugt, die in keinem offensichtlichen Zusammenhang zu einander stehen, dann reicht schon ein Zähler, der die Regeln des synchronen Schaltungsentwurfs misachtet. Dazu noch eine unzuverlässige Taktquelle, die zu schnell für das entsprechende FPGA ist (die switching Limits der Elemente sollten überfahren werden). Die Spannungsversrogung sollte auch nicht die beste sein und man könnte offene Eingänge als enable-Signale verwenden.... Schon spuckt der FPGA Zahlen aus, die wirklich zufällig sind... (Den zweiten Absatz bitte nicht zu ernst nehmen)
eddy schrieb: > Die Hardware (Board + verbauter FPGA) hängt von Eurer Anwendung ab. Je > nach dem, welchen Effekt Ihr für die TRNG nutzen wollt, braucht das > Board entsprechende Schnittstellen und der FPGA braucht abhängig von der > Anzahl und der Komplexität der Berechnungen entsprechende Ressourcen > (DSP-Blöcke, RAMs etc.). Dann kommt noch die Geschwindigkeit dazu. Das > sind so die Mindestinfos, die man haben sollte, um über die Hardware > nachzudenken. Auswahl gibts es in Eurem-Budgetrahmen mehr als genug, nur > werden die kleinsten/günstigsten/leistungsschwächsten Boards bzw. FPGAs > nicht unbedingt jeder Art von TRNG unterstützen. Naja ringoszillator aus 13 Invertern ist nun wirklich keine hohe Hürde für einen FPGA. Das Problem ist eher die Software vom FPGA-Hersteller, die Inverterketten gern wegoptimiert oder sich einfach weigert aus Sicht der synchronen Schaltungstechnik "groben Unfug" zu realisieren. Es könnte sein, das ihr "per Hand" ("direct Routing" umm xilinx-ise-fpgaeditor) verdrahten müsst. Ich bin mir nicht sicher ob solche "lowlevel Programmierung" von den modernen Tools wie vivado noch unterstützt wird.Früher konnte man noch mit dem designcompiler von cadance quasi Netzlisten nach belieben stricken. Deshalb solltet ihr die boards nicht nach FPGA-Ressourcen aussuchen sondern nach Fähigkeiten/Lernkurve der FPGA-backends.
Die Frage ist, was hier "true random" bedeutet. Weder die Mischmethoden noch LFSR-Methoden, die immer eingesetzt werden, liefern wirkliche Zufallszahlen. Es muss immer eine zufällige Wirkung von Außen miteinbezogen werden. Temperatur ist ein guter Ratgeber.
Weltbester FPGA-Pongo schrieb im Beitrag #5177401: > Die Frage ist, was hier "true random" bedeutet. Weder die Mischmethoden > noch LFSR-Methoden, die immer eingesetzt werden, liefern wirkliche > Zufallszahlen. Es muss immer eine zufällige Wirkung von Außen > miteinbezogen werden. Temperatur ist ein guter Ratgeber. Genau, entropie-quelle "entropy source" ist das Stichwort und dafür halte ich alle FPGA-Zaubereien für prinzipiell fragwürdig. Siehe auch http://www.eit.lth.se/sprapport.php?uid=498. Da nimmt man lieber eine anerkannte analoge Rauschquelle und quantisiert diese.
Bitwurschtler schrieb: > Genau, entropie-quelle "entropy source" ist das Stichwort und dafür > halte ich alle FPGA-Zaubereien für prinzipiell fragwürdig. Siehe auch > http://www.eit.lth.se/sprapport.php?uid=498. Da nimmt man lieber eine > anerkannte analoge Rauschquelle und quantisiert diese. Leider ist das nicht die Aufgabenstellung, hätte das auch gerne mit messung von kosmischer Strahlung o.ä. realisiert, aber die Anforderung ist eine andere. Welche Qualität die Zufallszahlen haben wird dann das zuständige Team analysieren - ich bin darauf gespannt. Danke für die Rückmeldungen, ein paar Anhaltspunkte habe ich nun mehr bezüglich der Auswahl. So wie ich es verstehe, enstehen die Zufälle im FPGA ja meist wohl durch "absichtliche Designfehler", also Timing-Verletzungen o.ä. und ich muss darauf achten, dass meine Synthese-Software so etwas auch zulässt, richtig? Grüße
Georg Weber schrieb: > So wie ich es verstehe, enstehen die Zufälle im FPGA ja meist wohl durch > "absichtliche Designfehler", also Timing-Verletzungen o.ä. und ich muss > darauf achten, dass meine Synthese-Software so etwas auch zulässt, > richtig? Wenn Du wirklich erwägst, damit Zufall zu erzeugen, dann bist Du wirklich nicht mehr zu retten. Es gibt aber immer wieder Helden, die sich an so etwas probieren.
Georg Weber schrieb: > Welche Qualität die Zufallszahlen haben wird dann das > zuständige Team analysieren - ich bin darauf gespannt. Das Beurteilen der Qualität von Zufallszahlen eines TRNG ist gar nicht so einfach wie man vielleicht auf den ersten Blick denkt. > So wie ich es verstehe, enstehen die Zufälle im FPGA ja meist wohl durch > "absichtliche Designfehler", also Timing-Verletzungen o.ä. und ich muss > darauf achten, dass meine Synthese-Software so etwas auch zulässt, > richtig? Zur Not kannst Du immer noch Lattice ice40 verwenden, denn deren Bitstream ist danke Reverse-Engineering komplett dokumentiert: http://www.clifford.at/icestorm/
Gerd E. schrieb: >> So wie ich es verstehe, enstehen die Zufälle im FPGA ja meist wohl durch >> "absichtliche Designfehler", also Timing-Verletzungen o.ä. Eher nicht, sondern durch ein gezieltes Design jenseits der reinen Logikdefinitionen auf die sich die Timing-Vorgaben der Synthese beziehen. Das hier wäre so ein System: Digitaler Zufallszahlengenerator in VHDL Digitaler Rauschgenerator im FPGA Weltbester FPGA-Pongo schrieb: > Es gibt aber immer wieder Helden, die > sich an so etwas probieren. Auch wenn es manch einer nicht glauben mag, es gibt sehr wohl FPGA-spezifische Strategien, die interne Logik verwenden, um Zufall zu erzeugen, als da wären: 1) Der FPGA liefert eine exemplarspezifische Signatur in Form eines Rauschmusters, anhand man ihn identifizieren kann. D.h. eben DIESEN FPGA und nicht einen baugleichen in einer gleichen Schaltung mit dem gleichen FPGA-image aus demselben VHDL-Code, sondern eben wirklich eine Signatur DIESES Chips. Die Mimik ist dieselbe wie die Identifikation bestimmter Analogschaltungskomponenten, um ein System zu identifizieren. Beispiel: Man oberviert aus der Luft Boden-Radare, katalogisiert sie und erkennt deren Verschiebung durch Truppen, auch wenn es sich um mehrere baugleiche in geringer Entfernung handelt. Geht, Gemacht, Funktioniert. 2) Der FPGA liefert eine exemplar-unabhängige Signatur in Form eines in den Daten eincodierten Musters, um ein PCB (und zwar ein ganz bestimmtes) identifizierbar zu machen. Maßgeblich sind die zufälligen Abweichungen er äußeren Beschaltung, also z.B. die Kombination von RC-Werten, der Offset von verbauten Wandlern und Operationsverstärkern. Geht, Gemacht, Funktioniert. Das sind natürlich Spezialanwendungen, die ganz bestimmte Ziele haben und die sich mit den üblichen Methoden nicht oder nur ungenau realisieren lassen. Der FPGA muss dazu nicht nur individuell sein, sondern eben auch ziemlich rechnen. Das ist auch der Grund, warum überhaupt FPGAs eingesetzt werden: Sie können schnell rechnen. Die typischen Anwendungen für Rauschen, Zahlen und Signalgeneration sind nämlich deterministisch und daher in Software analytisch abzubilden. Das bedeutet, dass man sie auch in DSPs machen kann und in FPGAs wird es oft einfach deshalb gemacht, weil man eben die gesamte Rechnung im FPGA hat und dort eben die Rauschzahlen braucht. Das betrifft besonders die Erzeugung von Zahlen, die bestimmten Kriterien entsprechen müssen und z.B. Rauschen muss in der Tat auch oft solchen Kriterien entsprechen, z.B. alle Wellen für einen Tester statistisch gleichmäßig verteilt erzeugen. Der Zufall hält sich da sehr in Grenzen. Mehr ist in den Artikeln "Rauschgenerator" und "Zufallsgenerator" hier im Forum zu finden. Die Liste fortsetzend hätten wir dann 3) Einen Rauschgenerator der voll deterministische Wellen erzeugt, welche perfekt tariert sind und nur für den Betrachter oder den Filter (oder für Suchalgorithmen) "zufällig" aussehen. 4) Ein Zahlengenerator, der eine Wunschverteilung in zufälliger, scheinbar) zufälliger oder deterministischer Reihenfolge vollständig abspielt, was mit einer Tabelle und Zugriff mit Median und Mehrheitsverfahren auf der Basis irgendwelcher! Werte für die Adressen zielführend und sicher funktioniert und damit auch mit schlechtem Rauschen 5) Ein Zahlengenerator, der eine Zufallsverteilung in zufälliger oder auch deterministischer Reihenfolge abspielt und bei der Erzeugung und Abspielen gegenüber 4 ausgetauscht sind. Solche Verfahren werden mit "Umrühralgorithmen" realisiert, mit denen man Daten auf Prozesssysteme loslässt oder auch auch auf FPGAs und ASICs in Form von Testvektoren. Man google man nach Mersenne und Marsaglia. Und ja auch die kann man in FPGAs bauen. Geht, Gemacht, Funktioniert. Was der TE hier jetzt braucht, ist wahrscheinlich Fall 4b. Gerd E. schrieb: > Das Beurteilen der Qualität von Zufallszahlen eines TRNG ist gar nicht > so einfach wie man vielleicht auf den ersten Blick denkt. Das kann man so stehen lassen. Da gibt es Abteilungen, die die Qualität von verrauschten Daten dahingehend abschätzen, wie gut es möglich ist, darin Daten zu verstecken und wie groß die Wahrscheinlichkeit ist, dass man sie entdecken kann.
:
Bearbeitet durch User
Jürgen S. schrieb: > Gerd E. schrieb: > > Auch wenn es manch einer nicht glauben mag, es gibt sehr wohl > FPGA-spezifische Strategien, die interne Logik verwenden, um Zufall zu > erzeugen, als da wären: Aber warum sollte man das tun, wenn man zuverlässigere Rauschquellen durch simple Analogschaltungen ausserhalb des FPGA's aufbauen kann? https://de.wikipedia.org/wiki/Rauschgenerator Die Verwendung von einer überwachten externen Schaltung zur Rauscherzeugung erscheint mir weitaus sinnvoller als 300 € für ein Board ausgeben zu wollen. Auch da kann man gehörig Hirnschmalz verwenden um eine Schaltung aufzubauen die trotz Temp- und Alterungsdrift Zufälle gleicher Güte liefert. Es ist schon manche Kommunikation geknackt worden weil der Zufallsgenerator unbemerkt verhersehbar wurde. https://www.schneier.com/blog/archives/2008/05/random_number_b.html https://eprint.iacr.org/2016/367.pdf https://tools.ietf.org/html/rfc4086 http://www.rambus.com/wp-content/uploads/2015/08/Intel_TRNG_Report_20120312.pdf Welche FPGA-Technologie sich am besten für Rauschgeneratoren eignet ist IMHO noch nicht untersucht worden. Ich könnte mir vorstellen, das Strukturbreite und routing resourcen eine Rolle spielt: Das Phasenrauschen eines Oszillators aka Frequenzgüte eines Freischwingers könnte davon abhängig sein wie groß die Parameterstreuung im Rückkoppelzweig ist, im FPGA also wie unterschiedliche/temperaturbeständig/etc. die Laufzeiten auf den Routingkanälen sind. Bei FPGA's mit hoher strukturgröße bspw Xilinx Spartan3 mit 90 nm könnte die Laufzeit in einem größerern Intervall schwanken als im Altera Max 10 mit 55 nm Technologie. Hinsichtlich der Granularität der Routing-ressourcen gibt es auch Unterschiede, Altera mit row und coloumn basierten routing Kanälen war da mal grob granulärer als Xilinx. Aber für welches FPGA-Board man sich entscheiden sollte wenn man eine gut rauschende Schaltung aufbauen möchte kann IMHO derzeit keiner sagen. Das müsste man selbst mit probieren herausfinden, also mehrer boards unterschiedlicher FPGA-Hersteller und FPGA-familien verwenden. PS: hinsichtlich der Neigung zu metastabilität stehen die FPGA-Hersteller oft auch vor einem Rätsel und können nicht erklären warum manche Typen anfälliger für metastabilitätn sind als andere: https://forums.xilinx.com/t5/PLD-Blog/Metastable-Delay-in-Virtex-FPGAs/ba-p/7996
Ich denke mal, dass Hochschulen dazu da sind, nach neuen Dingen zu forschen. Wenn es also bisher kein beschriebenes Verfahren gibt, wie man einen TRNG mit einem FPGA macht, es aber eine geringe Chance gibt, dass das machbar ist, sollte man es untersuchen. Ich vermute aber, dass das Ergebnis stark technologie- und herstellerabhängig ist.
chris schrieb: > Wenn es also bisher kein beschriebenes Verfahren gibt, wie man > einen TRNG mit einem FPGA macht, es aber eine geringe Chance gibt, dass > das machbar ist, sollte man es untersuchen. Ja, durch Doktoranden vielleicht aber nicht durch Studenten denen man das Entwickeln brauchbarer erst beibringen soll. Studenten müßen etablierte und sichere Lösungswege vermitteln werden und das wäre aus meiner Sicht die Verwendung einer externen Rausch-Schaltung. Und es gibtdurchaus beschriebene Verfahren für entropy sources im FPGA, die ziehen eher ein durchwachsenes Fazit. "But according to the simulations and result in this report it was shown that TERO was dependent on a lot of parameters to make it work properly. Both that the results differed while changing the placement and also that the three implementations on FPGAs gave such a difference" " Can be problematic if implemented in an FPGA, if the delay elements do not have sufficiently small delay. "
Angehängte Dateien:
-
Ring_Oscillator_TRNG.png
95 KB
Erstmal vielen dank für die konstruktiven Antworten! Zum konkretisieren der Fragestellung : Es sollen mehrere Schaltungsvarianten getestet werden. Auf jeden Fall sollte es mit Ringoszillatoren versucht werden. (siehe Bild) Quelle wie oben: https://tu-dresden.de/ing/informatik/ti/vlsi/ressourcen/dateien/dateien_studium/dateien_lehstuhlseminar/vortraege_lehrstuhlseminar/folder-2012-03-21-5634987295/On-the--Fly-Evaluation.pdf?lang=de
web.georg@gmail.com schrieb: > Auf jeden Fall sollte es mit Ringoszillatoren versucht werden. Da ist was: http://www.lothar-miller.de/s9y/categories/29-Ringoszillator
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Da ist was: http://www.lothar-miller.de/s9y/categories/29-Ringoszillator Danke sehr - das ist schon eimal sehr hilfreich, insbesondere die Anweisung "keep" für Xilinx, die verhindert, dass Schlatungen wegoptimiert werden! Ich nehme an, bei Altera gibt es ähnliche anweisungen.
web.georg@gmail.com schrieb: > Lothar M. schrieb: >> Da ist was: http://www.lothar-miller.de/s9y/categories/29-Ringoszillator > > Danke sehr - das ist schon eimal sehr hilfreich, > insbesondere die Anweisung "keep" für Xilinx, die verhindert, dass > Schlatungen wegoptimiert werden! KEEP stoppt nur die Optimierung für die Synthese, place and route kann dir immer noch die Strippe wegziehen. Besser man benutzt DONT_TOUCH https://www.xilinx.com/support/documentation/sw_manuals/xilinx2012_2/ug901-vivado-synthesis.pdf S.33
C. A. Rotwang schrieb: > Aber warum sollte man das tun, wenn man zuverlässigere Rauschquellen > durch simple Analogschaltungen ausserhalb des FPGA's aufbauen kann? Weil (über das von mir schon Geschriebene hinaus) a) ... sich bei den Untersuchungen gezeigt hat, dass die analogen Rauschquellen von Aussen auch reichlich empfindlich sind, wenn die Schaltungen ausserhalb des Labors oder der EMV-TEstkammer betrieben wird und allerlei Dreck aufsammeln und damit nicht automatisch stabiler sind sondern mitunter als Antenne für die Powerschaltung im Nachbarraum fungieren b) ... die analogen Komponenten im FPGA genügend "analog" sind, um mit etwas kluger Verschaltung so ziemlich dasselbe abgeben können, was externe Schaltungen an echtem Zufall so können, wobei sie sowohl reproduzierbarere Ergebnisse liefern können, als auch Zufälligere c) ... externe Schaltungen davon abhängen, wie der Bestücker gearbeitet hat, wie der Lötprozess hingehauen hat, was die Vias zu Reflektionen sagen, was dazu führt, dass unterschiedliche PCBs sehr unterschiedlich arbeiten und obendrein die MTBF FMEA Betrachtung für FPGAs mitunter bessere Ergebniss liefert d) .. es Rauscher gibt, die sich teilweise deterministisch verhalten müssen und richtig Rechenpower ziehen und das bischen primärer Rauschgenerator da nicht mehr viel ausmacht, sondern sogar Platz auf der Platine sparen hilft e), f) weil es noch weitere Aspekt gibt, die Ich hier aber nicht publizieren kann
Zu der Frage, ob man das Studenten machen lassen sollte und wie sinnvoll das generell ist, Dinge zu erfinden, die sich wohl nicht lohnen oder die es anders herum schon gibt - auch wenn sie nicht in publiziert sind sondern einfach nur von Ingenieuren stillschweigend in die Geräte implementiert wurden und die auch nicht patentiert sind, damit man die Konkurrenz nicht aufs Pferd setzt, sei gesagt: Die Unis sind zwar immer schwer am forschen, aber der Technik nicht unbedingt automatisch voraus und irgendwas müssen die Studies ja bauen. Die FPGA-Technologie ist inzwischen vergleichsweise alt und die Ideen, was man mit wenig Einarbeitung bauen kann, gehen den Leuten ja offenbar aus. Ist halt so. Also müssen auch Seitenäste abgegrast werden und sei es nur, um nachzuweisen, dass eine Methode nicht (oder noch nicht) effektiv zu nutzen ist und wo die Probleme liegen. Das ist völlig in Ordnung. Man darf halt nur nicht glauben, dass man da als Studie was Neues baut, nur weil es dazu noch keinen Xilinx-Core oder eine Funktion in der MATLAB-toolbox gibt oder weil es kein paper gibt und auf Youtube noch kein Bastler damit geprahlt hat. Was richtig Neues kann man nur mit neuen Technologien machen und FPGAs sind da lange ausgereizt. Wenn es tatsächlich zu Problemen mit Hacking, Ausfall, schlechter Verteilung oder anderem kommt, dann deshalb, weil der Designer das Feld nicht kennt und die falsche Lösung implementiert hat oder man ihm aus Zeit- und Kostendruck die falsche Prio gesetzt hat. Speziell übers Rauschen und Zufall-Zahlen-Theorien haben sich schon sehr viele Leute sehr viele Gedanken gemacht. Das Feld ist sowohl mathematisch, als auch umsetzungstechnisch so ziemlich abgegrast. Die einzelnen Nischen für "super stabil", "super billig", "super klein", "super schnell", "super genau", "super sicher", "super schnell zu programmieren", "super zufällig" und "super einfach zu verstehen" sind sehr gut und mehrfach besetzt. Ich sehe da allerhöchstens Potenzial für noch die eine oder andere kluge Optimierung hinsichtlich einer Kombination oder Kompromiss zwischen z.B. Implementierungsaufwand und Qualität, wo sich ja durch Kostenänderung und Leistungsfähigkeit ständig die Grenzen verschieben. Ob bei einer optimierten Lösung dann ein analoger externer Rauschgenerator eine Rolle spielt, bin Ich aber nicht so sicher ...
Zu der Bewertung der Möglichkeiten und dem zitierten Artikel C. A. Rotwang schrieb: > "But according to the simulations and result in this report it was shown > that TERO was dependent on a lot of parameters to make it work properly. Ja, das ist aber klar und wenn man probiert, diese Parameter auszugleichen, um z.B. ein perfektes Rauschen hinzubekommen, dann hat man eben schon mal den falschen Denkansatz ;-) > Both that the results differed while changing the placement and > also that the three implementations on FPGAs gave such a difference" Auch das ist vollkommen klar und bekannt. Es wird (auch in anderem Zusammenhang) immer wieder von Fachleuten gepredigt, daß man im FPGA kein zeitorientiertes Design bauen sollte, weil die Synthesetolls das nicht unterstützen. Auch wenn dann mal was funktiert, geht es in der nächsten Synthese schief. FPGA auf VHDL-Ebene ist und bleibt Logidesign. Man muss die Physik im FPGA prinzipiell als einen Teil des Zufalls anerkennen und (zwar konkret als einen nicht gleichverteilten!) und entweder gezielt als Zufall nutzen oder durch Maßnahmen ausblenden. Was die grundsätzliche Thematik der Erzeugung von Zufall im FPGA angeht, ist es also eine Frage des Ziels und Interpretation, sowie der Umsetzung und dass im zitierten Report jemand seine Lösung nicht dahin bekommt, wo er sie gerne haben will, heißt erst einmal nur, dass er es nicht hinbekommt oder falsche Erwartungen hat. web.georg@gmail.com schrieb: > Zum konkretisieren der Fragestellung : > Es sollen mehrere Schaltungsvarianten getestet werden. > Auf jeden Fall sollte es mit Ringoszillatoren versucht werden. (siehe > Bild) Das sieht so aus, als habe sich da jemand ernste Gedanken gemacht. Auf den ersten Blick fällt mir auf, dass die Ringoszillatoren alles gleich lang zu sein scheinen und dass es viele sind. Falls jemand die Erwartungshaltung hat, dass die alle zufällig schwingen, dem kann man schon mal entgegentreten, dass die sich durchaus aufeinander synchen können oder sich auf ein und dasselbe externe Ereignis synchen. Gleichwol kommen die Flanken nicht 100% exakt. Ob man daraus mit 114 XORs direkt ein Signal herausbekommt, weiss ich nicht. Ich würde mal eine EXOR-pipeline vorschlagen und das einzeln prozessieren. Solche Sachen habe Ich durchprobiert, aber keine wirklich Verbesserung gefunden. Von der reinen Implementierung her - auch in Sachen Aufwand - liefert die Methodik der gestörten Inverterkette mit nur einem EXOR genügend Zufall und gerade die Störung ist besonders resistent gegenüber Synch-Effekte. Um dem Ganzen noch eine abrundende Note und einen Denkanstoss zu geben: Die Qualität des Zufalls und auch die Verteilung lassen sich anwendungsspezifisch definieren, bewerten und messen. Nötig ist nur eine Echtzeitmessung der Verteilungsqualität und ein Nachregeln der Parameter, um entweder dem Zufall oder der Verteilung auf die Sprünge zu helfen. Mein synthetischer FPGA-Rauschgenerator z.B. enthält z.B. eine Frequenzanalyse, die exakt das anvisierte Audioband überwacht und die Rauschleistung permanent misst - in einer Version sogar exakt auf den Musikfrequenzen. Damit wird die Leistung frequenzspezifisch einstellbar und auch die Gesamtamplitude stimmt auf Dauer. Es stimmt unabhängig von der Temperatur, dem FPGA und dem PCB auf dem es sitzt. Solange die Inverterketten nur überhaupt schwingen und irgendwas produzieren, kommt am Ende was zufälliges Ausgeglichenes raus. Filtert man entsprechend, gibt es langzeitstabile Akkorde und wenn man ihm einen Ton auf die Regelschleife gibt, dann kompensiert er das sogar und erzeugt selber Akkorde. Theoretisch kann man dieselbe Qualität vielleicht auch mit einem rein mathematischen Verfahren hinbekommen, das dann gfs sogar auch noch weniger resourcen benötigt oder man könnte umgekehrt mit denselben resourcen ein noch besseres Rauschen hinbekommen, aber gefunden habe Ich in 10 Jahren keins, zumindest nicht, das auch die Bandbreite / Bitrate könnte. Vom Platz her konnte mich schon gar keine andere Lösung überzeugen. Die erste Version lief in einem PLD, später in einem mickrigen Spartan FPGA, das zu 95% vom Klangerzeugermodul belegt war. http://www.96khz.org/oldpages/digitalnoisegenerator.htm
:
Bearbeitet durch User
Jürgen S. schrieb: >> Both that the results differed while changing the placement and >> also that the three implementations on FPGAs gave such a difference" > Auch das ist vollkommen klar und bekannt. Es wird (auch in anderem > Zusammenhang) immer wieder von Fachleuten gepredigt, daß man im FPGA > kein zeitorientiertes Design bauen sollte, weil die Synthesetolls das > nicht unterstützen. Auch wenn dann mal was funktiert, geht es in der > nächsten Synthese schief. FPGA auf VHDL-Ebene ist und bleibt Logidesign. Also meine subjektive "Klarheit" über die abhängigkeit des Spektrums vom placement führt mich zu dem schluß entropy sources im FPGA komplett sein zu lassen. Wobei ich die Placementabhängigkeit so interpretiere, daß die Verzögerungszeiten der einzelenen Pfade entscheidend sind. Die sind nun aber nicht nur vom placement abhängig, sondern auch von exemplarstreuungen unter den FPGA's. Wenn also der Konfigurations-bitstream auf einem FPGA ein zufriedenstellendes spectrum erzielt, muss das auf einem typgleichen FPGA nicht unbedingt der Fall sein. Damit wäre die Grundidee der programmierbaren Bausteine ad absurdum geführt, es müsste für jeden einzelnen FPGA ein Extra Placement vorgesehen werden. Auch der Ansatz dann mehrer Generatoren zu verbauen und auf Spektrumsauswertung basierend auszuwählen welcher grad verwendet wird befriedigt mich persönlich nicht. > Die Unis sind zwar immer schwer am forschen, aber der Technik nicht > unbedingt automatisch voraus und irgendwas müssen die Studies ja bauen. > Die FPGA-Technologie ist inzwischen vergleichsweise alt und die Ideen, > was man mit wenig Einarbeitung bauen kann, gehen den Leuten ja offenbar > aus. Ist halt so. Ist in der gesamten Ausbildung so, das die Studenten seit Jahrzehnten die immer gleichen Übungeaufgaben wie Spannungsteiler etc. lösen. Trotzden sollte diese "Monotonie" in den Aufgabenstellungen nicht dazu führen, den Auszubildeten mangelhafte und daher ungebräuchliche Technik-Ansätze als "unkommentierte" Ausbildungsziele vorzusetzen. Ich seh die Gefahr, das dann die Absolventen dann im ersten Job diese akademischen Ansätze auf Biegen und Brechen einsetzen wollen ohne das sie die Praxistauglichkeit einschätzen und mit tradierten Lösungen vergleichen können. ich sehe aber auch etwas Gutes an dieser Aufgabenstellung im Unterschied zu tradiditionellen Ansätzen wie Aufbau eines eigenen FPGA-basierten Digitalscopes. Man muß zur Lösung dieser Aufgabe in die gesamte toolchain eingreifen, es genügt nicht sich nur mit VHDL-KnowHow zu beschäftigen, auch das Place&Route muss gesteuert werden (placement constraint). Es werden also umfassendere Kenntnisse über die FPGA-Entwicklung erworben, etwas was ich an vielen Absolventen vermisse. Die lehnen es zuweilen sogar ab sich über die Niederschrift oder gar Zusammenclicken von VHDL-code mit FPGA-design zu beschäftigen, denn "Optimieren macht der Compiler" und "Hardware kommt billig aus China" :-(
C. A. Rotwang schrieb: > denn "Optimieren macht der Compiler" und > "Hardware kommt billig aus China" :-( was bei näherer Betrachtung so falsch auch nicht ist, weil der Compiler das FPGA am besten kennt und die Schaltung reinpressen kann, besser, als jeder Entwickler es händisch tun könnte. Das andere, daß Elektronik aus China kommt, tut an der Stelle nichts bei. Die Frage ist doch eigentlich einfach: Entweder nutze Ich den FPGA digital (wie es vorgesehen ist) oder analog (wie es nicht vorgesehen ist). Im letzteren Fall muss der Entwickler eben die tool chain umgehen und selber jedes Element einzeln verbinden und darf nichts automatisch verteilen lassen. web.georg@gmail.com schrieb: > Es sollen mehrere Schaltungsvarianten getestet werden. Mich würde interessieren, was der BCH-Code in der Schaltung für eine Funktion haben soll. Wird dadurch nicht wieder Vorhersagbares in die eigentlich zufälligen Daten eingefügt? >Welches FPGA Board für TRNG (VHDL) Jedes und Keines, weil die BHDL in jedem FPGA läuft, Du aber nicht relevant ist, wenn du händisch plazierst. Händische Platzierung geht in keinen FPGA perfekt, weil Du an manche Sachen nicht drankommst. Das kann nur der Hersteller.
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.