mikrocontroller.net

Forum: FPGA, VHDL & Co. Welches FPGA Board für TRNG (VHDL)


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Georg Weber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Georg Weber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von eddy (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Georg Weber (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
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/

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von chris (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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. "

von web.georg@gmail.com (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von web.georg@gmail.com (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bitwurschtler (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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 ...

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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
von C. A. Rotwang (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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" :-(

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.