Hallo!
Ich habe mal eine Frage zur Berechnung der Standardabweichung im FPGA.
Wie würdet ihr da rangehen?
Vielleicht erst einmal zum Hintergrund: Ich habe Signale, die ich durch
meine 11 bit breites und 10 'Schiebungen' tiefes Schieberegister im FPGA
im µs-Takt durchjage (vielleicht hat der eine oder andere von euch ja
schon meinen letzten Beitrag mitverfolgt . . . ). In dem SR ist zum
größten Teil an einer bestimmten Stelle kein Datensatz, also alles auf
'0'. Wenn jetzt ein bestimmt definierter Datensatz an dieser Stelle
auftaucht, dann fange ich an einen µs-Zähler zu starten, der den Abstand
zum nachsten definierten Datensatz misst. Das geht dann immer so weiter,
bis Datensätze auftauchen, die nicht mehr die selbe Definition
beinhalten, aber dennoch vom gleichen Typ sind, und deswegen als
Datensätze vom selben Typ gekennzeichnet werden sollen. Die Abstände
zwischen diesen Datensätzen sind zunächst mal im Bereich 3,21 - 3,27 ms.
Ich wollte nun die Abstände der definierten Datensätze sammeln, und aus
ihnen die Standardabweichung berechnen, um dann immer im Zeitbereich
'Mittelwert der Abstände +- x*Standardabweichung' nach undefinierten
Datensätzen suchen, um diese dann dem definierten Typ zuzuordnen.
Da das Ganze nicht immer bei 3,21-3,27 ms Zeitabstand bleiben muss,
wollte ich eben immer den Mittelwert und die Standardabweichung
berechnen, um die undefinierten Datensätze in einem bestimmten
Zeitfenster nach dem letzten definierten Datensatz, welches auf diese
Werte basiert, suchen.
Ich habe mich bei der Berechnung der Standardabweichung ein wenig an
dieses Kapitel und die Equation 3-2 in einem eBook gehalten:
>http://www.dspguide.com/ch2/2.htm <.
Ich habe dann für jedes zu berechnende Element (sum, sum^2,
sum_of_squares, etc.) integer signale angelegt, und dann alles nach und
nach, Takt für Takt berechnet.
1
-- Zunächst die Summe der P2-Impulsspacings bestimmen
Meine Frage an euch alte Hasen ist nun, wie ihr die Integer ranges der
einzelnen Variabeln anlegen würdet? Bisher habe ich immer so grob über
den Daumen gepeilt, und jedem Signal unterschiedliche ranges zugewiesen.
Die Summe der Abstände muss ja bei weitem nicht so groß sein, wie deren
Quadrat, usw.
Vielleicht ist das aber auch das Problem, dass ich bei der Zeile
sum_square <= sum * sum; für sum_square im Simulator nie ein Ergebnis
bekomme. Da steht dann immer 'X'.
Sollten deswegen die ranges bei allen Variabeln gleich groß sein?
Natürlich bin ich auch für andere Herangehensweisen an dieses Problem
und für eine herzhafte Diskussion über meine Vorgehensweise offen ;-).
Grundsätzlich möchte ich noch anmerken, dass ich ein recht gutes Gefühl
bei der Sache habe, so wie ich es mache . . . .
Gruß
Maik
Dass Du "X" bekommst liegt nicht an "range"s. Eher läuft Deine
Statemaschine nicht richtig. Bzw. srp2(0/2/3) werden nicht
initialisiert.
Ansonsten verstehe ich die Frage nicht ganz: wie definiert man ranges?
Woher sollen wir denn das wissen (okay, zugegeben ich habe jetzt nicht
ganz durchgestiegen, was gemacht werden muss). Eigentlich schreibst Du
ja selber, dass Du es Dir schon Gedanken darüber gemacht hast. Rechne
mal die maximalmögliche Werte aus und da hast Du Integer-Ranges.
So aus der Ferne finde ich es schwer durchzusteigen, was gemacht werden
soll. Trotzdem viel Erfolg! :-)
Kest
@ Maik Ritter (kiamur)
>Ich habe mal eine Frage zur Berechnung der Standardabweichung im FPGA.>Wie würdet ihr da rangehen?
Genauso wie auf dem Papier. Die Fromel muss halt duchgezigen werden.
Wobei Division aufwändig wird, Wurzel erst recht.
>Vielleicht erst einmal zum Hintergrund: Ich habe Signale, die ich durch>meine 11 bit breites und 10 'Schiebungen' tiefes Schieberegister im FPGA
????
Das sind 10 Messwerte a 11 Bit.
>zwischen diesen Datensätzen sind zunächst mal im Bereich 3,21 - 3,27 ms.>Ich habe dann für jedes zu berechnende Element (sum, sum^2,>sum_of_squares, etc.) integer signale angelegt, und dann alles nach und>nach, Takt für Takt berechnet.
Das verbrauch ordentlich Resourcen.
>Natürlich bin ich auch für andere Herangehensweisen an dieses Problem>und für eine herzhafte Diskussion über meine Vorgehensweise offen ;-).
Was du machst ist alle Arithmetik parallel in Hardware zu giessen. Das
ist hier Verschwendung. Wenn eine Messung ca 3,2 ms dauert hast du alle
Zeit der Welt, das per Softcore Prozessor oder State Machine sequentiell
zu berechnen. Dann brauchst du du nur einen Quadrierer, Dividierer und
Addierer. Die einzelnen Messwerte legst du sinnvollerweie in einen RAM
im FPGA.
>Grundsätzlich möchte ich noch anmerken, dass ich ein recht gutes Gefühl>bei der Sache habe, so wie ich es mache . . . .
Das haben viele, bis sie die Augen geöffnet bekommen . . . ;-)
Jugendliche Naivität.
MFG
Falk
@Kest:
>Ansonsten verstehe ich die Frage nicht ganz: wie definiert man ranges?
Naja, ich meine damit, ob ich die ranges so definieren sollte, dass
jedes Signal seine eigen range bekommt (also range von sum kleiner als
range von sum^2), oder ob lieber für alle an einer Berechnung
beteiligten Signale die range des Signals mit der größten range genommen
werden sollte. Ist ja nur ein Frage, was eure Erfahrungen da so sagen,
und warum ihr es so machen würdet.
@Falk:
>Genauso wie auf dem Papier. Die Fromel muss halt duchgezigen werden.
Das habe ich in meinem Code-Ausschnitt auch versucht umzusetzen.
>Wobei Division aufwändig wird, Wurzel erst recht.
Für die Wurzel beutze ich eine vom Megawizard in Quartus II generierte
Megafunction.
Wenn es zu aufwändig wird, so dass die (kombinatorische) Berechnung
nicht in einem Takt über die Bühne geht, dann kann ich der Berechnung ja
auch 2 oder mehr Takte Zeit geben.
>Das sind 10 Messwerte a 11 Bit.
Naja, es ist etwas schwer zu beschreiben, aber ich muss mir immer
mehrere Datensätze gleichzeitig anschauen, um die bestimmten Datensätze
zu finden, deren Abstände ich messen möchte. Deswegen ist das
Schieberegister 10 Schiebungen tief. Es bedeutet nicht, das es von vorne
bis hinten voll ist mit Messungen. Es sieht z.B. so aus:
-Y------X- : Y ist gesuchter Datensatz, weil X an Stelle 9 steht.
-Y----X--- : Y ist kein gesuchten Datensatz, weil X nicht an richtiger
Stelle steht.
>Das verbrauch ordentlich Resourcen.
Genau, deswegen meine Frage, wie es anders gehen könnte aber das hier .
. .
>Was du machst ist alle Arithmetik parallel in Hardware zu giessen. Das>ist hier Verschwendung. Wenn eine Messung ca 3,2 ms dauert hast du alle>Zeit der Welt, das per Softcore Prozessor oder State Machine sequentiell>zu berechnen. Dann brauchst du du nur einen Quadrierer, Dividierer und>Addierer. Die einzelnen Messwerte legst du sinnvollerweie in einen RAM>im FPGA.
. . . kann ich nicht machen, weil die Datensätze in ihrer Reihenfolge
auf keinen Fall durcheinander kommen dürfen. Damit meine ich nicht nur
die Datensätze, mit denen Berechnungen durchgeführt werden sollen,
sondern auch die Datensätze "dazwischen". Es können unter Umständen jede
µs Datensätze kommen (müssen aber nicht). Um da nicht durcheinander zu
kommen, lasse ich alle Datensätze durch das Schieberegister laufen (was
ja sozusagen zwischen 2 Schiebetakten auch ein Speicher ist, da es die
Werte für ein µs speichert. In den Pausen zwichen den Schiebungen führe
ich dann die Berechnung der Standardabweichung durch, oder suche nach
Datensätzen, die ich Markieren möchte.
Letztendlich ist das der Weg, den ich meiner meinung nach gehen muss, um
nicht das gesamte Konzept meines designs durcheinander werfen zu müssen.
Wenn ihr also die Standardabweichungsberechnung in Hardware parallel
durchführen müsstet, würdet ihr es dann so ähnlich machen, wie es in
meinem Codebeispiel obe abgebildet ist, oder habt ihr da noch andere
Ideen zu?
Gruß
Maik
@ Maik Ritter (kiamur)
> . . . kann ich nicht machen, weil die Datensätze in ihrer Reihenfolge>auf keinen Fall durcheinander kommen dürfen. Damit meine ich nicht nur
Ja und? Das hat doch damit gar nichts zu tun. Wer sagt, dass du alles
durcheinanderwürfeln sollst?
>Letztendlich ist das der Weg, den ich meiner meinung nach gehen muss, um>nicht das gesamte Konzept meines designs durcheinander werfen zu müssen.
Du bist vollkommen engstirning auf ein Konzept fixiert. Keine gute Idee.
Dann brauchst du ausserdem nicht nach Alternativen fragen.
MFG
Falk
>@ Maik Ritter (kiamur)>>> . . . kann ich nicht machen, weil die Datensätze in ihrer Reihenfolge>>>auf keinen Fall durcheinander kommen dürfen. Damit meine ich nicht nur>Ja und? Das hat doch damit gar nichts zu tun. Wer sagt, dass du alles>durcheinanderwürfeln sollst?
Ganz kurz zum RAM: Ich brächte halt ne ganze Menge an RAM, wenn ich
immer alle Datensätze zwischenspeichern möchte (und das müsste ich ja
auch mit denen machen, die nicht berechnet werden sollen, damit die
Reihenfolge und die Abstände untereinander gleich bleibn sollen). Ich
brächte dann u.U. auch wieder Zeitstempel für jeden datensatz, die mir
die datenflut nur wieder unnötig aufblähen wurde. Es hat sich halt nach
anfänglichen, gründlichen Überlegungen herausgestellt, dass das
Schieberegister Konzept das Beste für dieses Design ist, und deswegen
muss ich nun damit leben.
>>Letztendlich ist das der Weg, den ich meiner meinung nach gehen muss, um>>nicht das gesamte Konzept meines designs durcheinander werfen zu müssen.>Du bist vollkommen engstirning auf ein Konzept fixiert. Keine gute Idee.>Dann brauchst du ausserdem nicht nach Alternativen fragen.
Och Mensch, nee. Es ist halt so, dass ich eben nicht alles hier
aufschreiben kann, was mit dem Projekt zusammenhängt, weil es ganz
einfach den Rahmen sprengen würde. Deswegen sieht es von außen
vielleicht aus, wie Quatsch, den ich hier fabriziere. Aber bis jetzt
funktioniert alles wunderbar (sogar problemloser, als erwartet).
Wenn ich jetzt anfange alles in einen Softcore zu gießen, oder wieder
den RAM rein-designe, den ich schon raus-designed habe, dann ist ja ein
halbes Jahr Arbeit futsch. Und es geht doch auch so. Meine Fragen waren
ja grundsätzlich nur, ob ich bei derartigen Berechnungen die Integer
Signale alle auf die gleiche Range bringen sollte, und wenn ja, warum,
oder eben nicht, und warum denn dann nicht.
Außerdem habe ich ja auch was von dem 'X' im Simulatorergebnis
geschrieben, und hatte halt gehofft, dass sich jemand mal kurz den
Sourcecode oben anschaut, um mir evtl einen Fehler aufdeckt, den ich
einfach nicht gesehen habe.
Zu diesen Fragen habe ich leider noch nichts gehört. Was ist nicht klar
daran? Dann versuche ich mich noch deutlicher auszudrücken . . .
Manchmal habe ich so das Gefühl, dass hier alle Fragenden als komplette
Idioten in einen Topf geworfen werden, und wenn sie es nicht so machen,
wie ihr es sagt, dann gibt es etwas auf die Mütze. Ich gebe mir schon
die größte Mühe meine Fragen so genau wie möglich zu stellen, aber ich
kann eben nicht das komplette Projekt hier darlegen. Deshalb scheint
vieles für euch aus der Luft gegriffen zu sein, aber es ist in sich
schon alles recht stimmig. . . .
Naja, bis dann . . . . :-(
Maik
Maik Ritter wrote:
> if(state_register = b"000111") then --7
Warum verwendest du kein case? Und ist es wirklich nötig die Zustände
von Hand zu kodieren?
> Meine Frage an euch alte Hasen ist nun, wie ihr die Integer ranges der> einzelnen Variabeln anlegen würdet? Bisher habe ich immer so grob über> den Daumen gepeilt, und jedem Signal unterschiedliche ranges zugewiesen.> Die Summe der Abstände muss ja bei weitem nicht so groß sein, wie deren> Quadrat, usw.
Da gibt es zwei Möglichkeiten: entweder wählst du alle Bereiche so, dass
es nie Überläufe geben kann, oder so dass die Überläufe hinreichend
unwahrscheinlich sind (durch Simulation mit realistischen Daten
ausprobieren). Im letzteren Fall kannst du dann noch eine
Überlauferkennung einbauen, oder damit leben dass ab und zu falsche
Werte berechnet werden. Kommt drauf an was du erreichen willst.
> Vielleicht ist das aber auch das Problem, dass ich bei der Zeile> sum_square <= sum * sum; für sum_square im Simulator nie ein Ergebnis> bekomme. Da steht dann immer 'X'.
Bau doch einfach ein paar entsprechende assertions oder
report-Statements in den Code ein und prüfe es nach.
@Andreas:
>Warum verwendest du kein case? Und ist es wirklich nötig die Zustände
von Hand zu kodieren?
Gute Frage. Ist das Ganze denn jetzt eigentlich schon als
Zustandsautomat zu sehen (wegen dem state_register)? Die Berechnung der
Standardabweichung hat sich dann letztendlich so ergeben, wie sie jetzt
dort steht. Wenn es wirklich so etwas wie ein Zustandsautomat ist, dann
gibt es glaube ich die Möglichkeit beim definieren der Zustände das
state_register zu kodieren, richtig? Ich habe mich noch nicht so
ausführlich mit Zustandsautomaten beschäftigt.
Das mit dem 'if' (und kein case) beruht darauf, dass diese Form der
bedingten Abarbeitung für mich irgendwie natürlicher ist. Wegen der
Übersichtlichkeit hatte ich dann aber auch schon überlegt, es umzuändern
. . .
>Da gibt es zwei Möglichkeiten: entweder . . . .
Okay, über die range der einzelnen Variabeln habe ich mir schon Gedanken
gemacht. Das soll natürlich noch alles mit Simulationen überprüft
werden. Aber würdest du nun raten, das ich jeder Variabeln ihre eigen
Range zuweisen sollte, oder eben allen Variabeln die größte in der
Berechnung vorhandene, damit nicht evtl. Daten bei der Konvertierung von
einer Range-Größe in die andere verloren gehen . . . . .
>Bau doch einfach ein paar entsprechende assertions oder>report-Statements in den Code ein und prüfe es nach.
Hmmm. okay, dass kann ich ja mal versuchen. Hoffentlich kommt Quartus II
mit diesen Statements auch klar . . . .
Gruß
Maik
>@ Maik Ritter (kiamur)>>Ich habe mal eine Frage zur Berechnung der Standardabweichung im FPGA.>>Wie würdet ihr da rangehen?> Genauso wie auf dem Papier. Die Fromel muss halt duchgezigen werden.
Definitiv nicht! Gerade beim FPGA Design kommt es darauf an, die
Mathemtik so umzuformen, daß einfach gerechnet werden kann und nicht,
daß eine einfach mathematische Darstellung des Sachverhaltes vorliegt
(das Ziel jeder Umformung).
Die Bildung der benötigten Partialsummen für Varianz und Sigma kann je
Term in einem einzigen Schritt erfolgen, ohne den Umweg über den
Mittelwert. Dazu bemühe man mal sein Mittelstufenwissen aus Klasse 8 und
forme die Gleichung passend um.
Wenn man es drauf anlegt, möglichst schnell zu sein, ginge es auch in
einem einzigen Formelschritt, allerdings dann wieder mit entsprechenden
Resourcen. Ich würd zu einer pipeline raten, die 4x clocked (wegen der 4
Elemente).
>Wobei Division aufwändig wird, Wurzel erst recht.
Ansichtssache. Die Division und indirekt auch die Wurzel erfolgen
mittels Partialbruchzerlegung und benötigen nicht mal zwingend
Multiplier.
Der Megawizzard hat beides parat: Je nach Breite der benötigten
Datenworte gehen da einige clocks drauf, wenn man es pipelined bauen
möchte. In einem konkreten Beispiel eines Cyclnoe II bei 50MHz brauchte
der 48Bit Divider 14 clocks und die Wurzel 6.
Da Du genug Zeit hast, wirst Du keinen besonders breiten Divider
benötigen. Must aber dann eine Remainderbehandlung nachschalten.
>> Das haben viele, bis sie die Augen geöffnet bekommen . . . ;-)>> Jugendliche Naivität.>Oh man, so ein Pfosten.
Es gibt eben viele (hier), die schon von Beginn an alles wussten. Gelobt
seien sie, da sie uns, die wir naive Fragen stellen, die Augen öffnen.
(bitte aber erst wieder Morgen, für heute mache ich die Augen zu)
@ pumpkin (Gast)
>> Das haben viele, bis sie die Augen geöffnet bekommen . . . ;-)>> Jugendliche Naivität.>Oh man, so ein Pfosten.
[ ] Du hast den Smily gesehen.
[ ] Du kennst den Unterschied zwischen Dummheit und Naiviät.
[X] Du bist eine Mimose.
MfG
Falk
@Jürgen:
>Definitiv nicht! Gerade beim FPGA Design kommt es darauf an, die>Mathemtik so umzuformen, daß einfach gerechnet werden kann und nicht,>daß eine einfach mathematische Darstellung des Sachverhaltes vorliegt>(das Ziel jeder Umformung).>Die Bildung der benötigten Partialsummen für Varianz und Sigma kann je>Term in einem einzigen Schritt erfolgen, ohne den Umweg über den>Mittelwert. Dazu bemühe man mal sein Mittelstufenwissen aus Klasse 8 und>forme die Gleichung passend um.
Ich gebe gerne zu, dass meine mathematischen Fähigkeiten leider nicht so
gut sind, wie sie sein könnten (woran das liegt muss hier ja nicht
diskutiert werden . . . ). Aus diesem Grund habe ich mir mal die
Standardabweichungsberechnung mit diesem (wie ich finde sehr gut
geschriebenen) eBook draufgeschafft, und habe versucht die Berechnung
mit Hilfe der dort vorgestellten 'Equation 3-2' (siehe Link aus meinem
Eröffnungsthread) im FPGA umzusetzen.
Nun vertshe ich nicht so recht, ob du auch diesen Weg gegangen wärst,
oder ob du es anders gemacht hättest. Du erwähnst z.B. die 'Bildung der
benötigten Partialsummen für Varianz und Sigma'. Da kann ich mir ehrlich
gesagt nicht so viel drunter vorstellen (wie gesagt, mathematisch hapert
es etwas bei mir). Kannst du da vielleicht noch mal etwas genauer drauf
eingehen, speziell, wie du das im FPGA umsetzen würdest.
Ansonsten vielen Dank für deinen konstruktiven Beitrag!
Gruß
Maik
>@ pumpkin (Gast)>>> Das haben viele, bis sie die Augen geöffnet bekommen . . . ;-)>>> Jugendliche Naivität.>>Oh man, so ein Pfosten.>>[ ] Du hast den Smily gesehen.>[ ] Du kennst den Unterschied zwischen Dummheit und Naiviät.>[X] Du bist eine Mimose.
Meine Fresse! Falk Brunner ist ein :
[ ] Selbstdarsteller
[ ] Schwätzer
[ ] Forenvollmüller
[ ] Schreiber wertvoller Beiträge
Bitte ausdrucken, ankreuzen und Faxen!
>finde sehr gut geschriebenen) eBook draufgeschafft, und habe>versucht die Berechnung mit Hilfe der dort vorgestellten 'Equation 3-2'
Auf welches book beziehst Du Dich hier ?
>Auf welches book beziehst Du Dich hier ?
Auf das, auf dessen Kapitel ich in meinem Eröffnungsbeitrag gelinkt hab:
>http://www.dspguide.com/ch2/2.htm <.
Die Hauptseite dieses Buches ist dann : > http://www.dspguide.com/ <.
Ich finde das sehr gut geschrieben, und hat mir schon einiges an
Verständnis zu der Thematik gebracht.
Vielleicht noch der Vollständigkeit halber: Die Berechnung der
Standardabweichung in meinem Projekt scheint zu funktionieren. Habe die
Simulatorergebnisse jetzt mal nachgerechnet, und es haut so hin. leider
kann ich immer noch nicht alle Signale beobachten, da der Simulator
immer nur 'X' rausspuckt. Ergebnisse, die auf diese Zwischenergebnis
bauen, sind dann aber wieder richtig simuliert. . . .
Im FPGA scheint es dann auch zu klappen. Das muss allerdings noch heftig
getestet werden . . .
Gruß
Maik
>@ Credo (Gast)>Kannst du eigentlich noch mehr als billig kopieren und labern?
[x] Selbstdarsteller
[ ] Schwätzer
[x] Forenvollmüller
[ ] Schreiber wertvoller Beiträge
!
und jetzt bitte zurück zum Thema ...
> @ Credo (Gast)>> Kannst du eigentlich noch mehr als billig kopieren und labern?
Wie war das mit der "jugendlichen Naivität"? "Manche lernens nie . . .
;-)", nicht wahr Falk? Geh spielen!
pumpkin
Mensch Leute . . . .
Kann man für solche Dinge nicht einen extra Thread öffnen? Ich freue
mich immer, das jemand was zum Thema gesagt hat, und dann so was . . . .
Thread beobachten
Seitenaufteilung abschalten