Hi!
Gleich vorweg: Ich kann es wohl nicht.;-)
Und ja, ich bin Programmierer und Verilog ist keine Programmiersprache
sondern eine Beschreibungssprache.
Hier mein Problem:
Es gibt zwei Datenquellen (T1 und T2) die leicht zweitversetzt (oder
auch gleichzeitig) Werte liefern. Die beiden Werte müssen addiert werden
und ausgegeben werden. Ich hab das (mein) Problem so weit runtergekocht,
dass ihr euch nicht mit unwichtigen (weiteren) Mist aufregen müsst.
T1 und T2 (T für Term) haben ein output clock wenn sie fertig sind (im
source ist die Berechnung aber völlig banal). Der clock und der Wert der
Terme gehen in den Addierer, der, wenn beide Werte anliegen einfach
addieren soll und das Ergebnis dann wieder ausgeben.
Mir ist klar, dass das im Addierer so nicht geht, weil die Werte
parallel reinkommen können und somit parallel gleiche register
manipuliert werden sollten. Geht halt nicht.
Nur, wie macht man das richtig? Ich find keine Lösung. Was ist ein
geeignetes Lösungsmuster für Probleme solcher Art?
Ihr könnt gerne rumstänkern ... Danke!
Gruß,
Nick
Nick M. schrieb:> Nur, wie macht man das richtig? Ich find keine Lösung. Was ist ein> geeignetes Lösungsmuster für Probleme solcher Art?
Eine Lösung nütztz Dir nichts weil du das Problem nicht kennst,
respektive nicht richtig beschreiben kannst.
> Ich hab das (mein) Problem so weit runtergekocht,> dass ihr euch nicht mit unwichtigen (weiteren) Mist aufregen müsst.
Nein, du hast dem forum die Aufgabe nicht leichter sondern schwerer
gemacht, weil du wichtigste Eigenschaften des Szenarios unterschlägst.
So ist völlig Unklar welche Signale in welchen Zahlenformat zu wlcher
Zeit vorliegen. Ein timing diagramm wäre hier sehr hilfreich.
Wenn es sich um eine Hausaufgabe handelt dann veröffentlich diese so wie
du sie erhalten hast. Wobei, wer Teile der Aufgabenstellung als
"unwichtigen Mist" bezeichnet, ist mglw. ein hoffnungsloser Fall.
Das sind wichtige Grundlagen, die aber meist an der Uni nicht
beigebracht werden. Du musst mit einem Signal erst in die ClockDomain
des anderen wechseln.
Im Prinzip so:
x_clk1 + CDC-zu-Clk1(y_clk2) = ergbenis_clk1
hier gibt es gute Grundlagen zu Clock-Domain-Crossing(CDC):
https://www.fpga4fun.com/CrossClockDomain.html
> Wenn es sich um eine Hausaufgabe handelt
Das hast du perfekt erraten! Es ist eine Hausaufgabe. Die Aufgabe hab
ich mir selber gegeben und löse sie zu Hause. Und ich mach das, weil
ich will und nicht weil ich muss.
> Eine Lösung nütztz Dir nichts weil du das Problem nicht kennst,> respektive nicht richtig beschreiben kannst.
Eine Lösung kann ich mir anschauen und versuchen sie zu verstehen. Wenn
dann noch Fragen da sind, trau ich mich fragen.
Und wenn ich das Problem nicht richtig beschreiben kann, dann liegt es
wohl daran, dass ich nicht genug weiss. Darum frag ich.
Nick
> hier gibt es gute Grundlagen zu Clock-Domain-Crossing(CDC):
Ah! Jetzt hat das Problem einen Namen. Damit komm ich hoffentlich
weiter.
fpga4fun war mir bekannt, hab ich auch schon mal durchgelesen.
Herzlichen Dank für den Schubs in die richtige Richtung!
Edit, 30 Minuten später:
Jup, das war es! Flag synchronization auf fpga4fun. Es geht, muss ich
aber noch vertiefen.
Gruß,
Nick
> nicht die beste Quelle für gutes Lernen
Anregungen sind willkommen!
Ich hab das Buch "Verilog by example" von Blain C. Readler. Gefällt mir
sehr gut als Einstieg. Locker und klarer Schreibstil.
Dann hab ich "Fundamentals of Digital Logic with Verilog Design" von
Brown & Vranesic. Glücklicherweise die preiswerte Auflage für Indien,
Nepal ...
Geht leider davon aus, dass man bestehende Hardware in Verilog
übersetzen will. Hilft mir absolut nicht weiter.
Ich programmier die Logik in C, teste sie aus und übersetz das dann in
Verilog. Ja, genau daher kommen meine Probleme! Ich denk in Software und
nicht in Hardware. Aber das wird schon ...
Gruß,
Nick
Nick M. schrieb:>> hier gibt es gute Grundlagen zu Clock-Domain-Crossing(CDC):>> Ah! Jetzt hat das Problem einen Namen. Damit komm ich hoffentlich> weiter.> fpga4fun war mir bekannt, hab ich auch schon mal durchgelesen.>> Herzlichen Dank für den Schubs in die richtige Richtung!>> Edit, 30 Minuten später:> Jup, das war es! Flag synchronization auf fpga4fun. Es geht, muss ich> aber noch vertiefen.
So so da sucht einer explizit nach asynchron und freut sich über ne
synchrone Lösung ... das hört sich reichlich seltsam.
Bei der spass-seite fehlt IMHO die gebrauchlichste Lösung: Fifo. und die
zweitgebräuchlichste Gray ist ach mehr ausgekotzt als hilfreichend
beschrieben.
>Das sind wichtige Grundlagen, die aber meist an der Uni nicht>beigebracht werden.
Doch da wird einem an der Uni beigebracht, auch an Hochschulen
jedenfalls in der richtigen Fakultät.
> Und wenn ich das Problem nicht richtig beschreiben kann, dann liegt es> wohl daran, dass ich nicht genug weiss
Glaub ich nicht, "Beschreiben" ist grundlegende Kulturtechnik, die wird
ab der ersten Klasse immer wieder durchexeziert.
Hier wäre eine Handskizze angebracht die die Datenströme, deren Quelle
und die geforderte Verknüpfung zeigt. Mit verilog löst man Probleme in
Hardware, also zeichnet man Hardware. Und man tut gut daran reale
hardware wie ADC zu verwenden, als irgendwelche abstrakten,
hypothetischen "Datenquellen".
Nick M. schrieb:> Ich programmier die Logik in C, teste sie aus und übersetz das dann in> Verilog. Ja, genau daher kommen meine Probleme! Ich denk in Software und> nicht in Hardware. Aber das wird schon
Das ist doch völliger Käse, das braucht doch keiner. Was man braucht ist
in Hardware implementierte Algos, also bist du mit:
>"Geht leider davon aus, dass man bestehende Hardware in Verilog>übersetzen will. Hilft mir absolut nicht weiter."
völlig auf den Holzweg.
Üblicherweise entwirft man den Algo nicht in C sondern als
Datenflussgraph.
Bspw.:
https://www.researchgate.net/figure/DFG-of-the-gray-scale-transformation-example-The-numbers-on-the-left-side-are-the_fig5_226893498
Denn kann man in C emulieren muss aber nicht. und diesen Datenflußgraph,
aber nicht die C-Nachäfferei, übersetzt und testet man dann bspw über
Verilog in Hardware.
Besorg dir einen Kurs über digitale Schaltungstechnik, notfalls
computerarchitektur. Das sind die Grundlagen die du brauchst, nicht
irgendwelche C zu hardware zaubereien.
> völlig auf den Holzweg.> Üblicherweise entwirft man den Algo nicht in C sondern als> Datenflussgraph.
Den Datenfluss hab ich auf einem xmos-Prozessor (16 Kerne) entworfen,
implementiert und getestet.*) Das läuft tw. parallel, tw. sequentiell.
Und ich brauch dafür kein Papier.
Jeder Kern ist "so ein Kästchen" im Datenflussgraphen. Wie die Daten von
wo nach wo gehen sind die Variablen/Parameter. Das lässt sich sehr schön
in regs und wires übersetzen. Auch auf dem xmos muss ich mich um
Synchronisierung kümmern, das ist nicht ein linearer code.
Was in Verilog modules sind, sind auf dem xmos Kerne. Wie die modules
beschrieben werden hat mit C dann aber eher wenig zu tun, das C dient
nur als grober Anhalt.
*) Ist aber per meiner Definition nicht schnell genug. Da ist mir die
Idee gekommen, dass das interessant wäre in Verilog zu modellieren. Und
dazu hab ich mir von Trenz ein RefKit gekauft (weil mein vorhandenes
wohl ungeeignet ist). Das zieh ich jetzt bis zu Ende durch, bis es
läuft.
Nick
Nick M. schrieb:> Den Datenfluss hab ich auf einem xmos-Prozessor (16 Kerne) entworfen,> implementiert und getestet.*) Das läuft tw. parallel, tw. sequentiell.> Und ich brauch dafür kein Papier.> Jeder Kern ist "so ein Kästchen" im Datenflussgraphen.
Nope, so ein Kästchen ist eine atomare Operation wie Addition,
Subtraktion, Multiplikation, kein Prozessor.
Nochmal der dringende Hinweis sich mit den Grundlagen des
Hardwareenrwurfes zu befassen. Wenn man dafür keine gescheite Website
findet, muss sich halt ein Buch besorgen, Bücher gibt es in der
Bibliothek:
Da ein Video mit empfehlenswerten Empfehlungen:
https://www.youtube.com/watch?v=kobf8IOB0oA
Was soll daran verwerflich sein, einen Algorithmus erst in Software zu
entwerfen?
Mache ich für aufwändige Dinge immer: erst mal überlegen wie es geht.
Für ganz einfache Sachen reicht auch mal ein Blatt Papier oder Excel,
für komplexere Dinge mache ich das erst in Software (allerdings c#).
Der Vorteil: man kann in die volle Laufzeit reindebuggen und nicht nur
der ersten paar Millisekunden.
Das man dann natürlich Richtung FPGA die Programmlogik nicht 1:1
benutzen kann sollte einem schon klar sein.
Typischerweise ist es aber schwieriger SOWOHL den Algorithmus zu
implementieren, ALS auch noch effizient in eine Hardwarebescxhreibung zu
gießen, dabei auf Logiklevel, Pipelining und Ressourcen zu achten.
Robert P. schrieb:> Was soll daran verwerflich sein, einen Algorithmus erst in Software zu> entwerfen?
Falls die Software C oder C++ heisst öffnet man sich dutzende Falltüren
die an den weg zu einer späteren HW-Lösung unnötig verlängern wenn nicht
gar unpassierbar machen.
Das beginnt schon mit der Wahl der Datentypen (double, Float versus
signed integer) über die Wahl der Opratoren (division versus shift)
endet noch lange nicht bei der Tiefe der verwendetet ROM-LUT's. Bspw.
profitieren, falls ich mich irre, Butterfly-FFT's erheblich von der
Vorhandensein einer bit-reverse Addressierung, eoin Feature das man
leicht in DSP haben kann, aber kaum in PC-Software.
https://en.wikipedia.org/wiki/Bit-reversal_permutation
So besteht hier die Gefahr bei einer PC-Implementierung, das man eine
FFT wählt die zwar schneller auf dem PC, aber so nicht optimal für einen
DSP mit diesem Hardware-feature ist.
Und leider beeinflusst das oft nicht nur die Rechengeschwindigkeit,
sondern auch die Genauigkeit resp. numerische Stabilität.
Deshalb sollte man den Algo von Anfang mit den Operatoren und ressourcen
programmieren die man auch auf der Zielhardware zur Verfügung und sich
nicht daran orientieren wie man das auf PC-Hardware macht. Deshalb ist
es IMHO nötig sich zu beginn klar zu machen, welche Hardware einem für
die finale Lösung zur Verfügung steht.
> Nope, so ein Kästchen ist eine atomare Operation wie Addition,> Subtraktion, Multiplikation, kein Prozessor.
Der Code für einen Kern ist i.A. lächerlich kurz. Ich seh den Code das
als eine Abstraktionsebene über Addierer usw. Um die Details kümmere ich
mich, wenn das Grundgerüst in Verilog funktioniert. Ich will nicht in
TTL-Gräbern denken, sondern in der großen Funktion. Dann wird
verfeinert. Und Verilog gibt es, damit man die TTL-Gräber abstrakt
beschreiben kann. Wie weit man bei der Verfeinerung runtergehen muss
wird sich für mich zeigen. "Learning by Beule".
Mag sein, dass ich damit falsch liege. Aber ich kann besser aus Fehlern
lernen. Und die nächste Watsche lauert mich bestimmt schon auf. :-)
Danke für den Link, schau ich mir gleich an.
Gruß,
Nick
> Das beginnt schon mit der Wahl der Datentypen (double, Float versus> signed integer) über die Wahl der Opratoren (division versus shift)
Der Punkt ist mir schon klar. Ich hab das auf dem xmos rein in
Integer-Aritmetik implementiert und alle Divisionen rausgeworfen bis auf
ein finales asl. Und ja, in meinem Verilog steht nur signed reg statt
die tatsächliche Breite anzugeben. Das wird so nicht bleiben. Die
"TTL-Denke" ist mir nicht fremd, liegt aber schon Dekaden zurück.
Und ja, mir ist auch klar, dass es für den FPGA bessere/andere
Algoritmen gibt. Dafür gibts "Advanced Synthesis Cookbook" oder AppNotes
die ich dann lese wenn es dafür nötig ist. Ich hab auch nicht vor eine
FFT sklavisch von C nach Verilog zu übersetzen. Das ginge sicher
daneben.
Gruß,
Nick
C. A. Rotwang schrieb:> So besteht hier die Gefahr bei einer PC-Implementierung, das man eine> FFT wählt die zwar schneller auf dem PC, aber so nicht optimal für einen> DSP mit diesem Hardware-feature ist.
Wenn man das tut, obwohl man weiß das man mal aufs FPGA will, ist man
wohl selbst schuld. Fällt dann unter Kopf nicht benutzt.
Ein Beispiel wo ich grundsätzlich erst alles in Software mache, sind
Algorithmen die man landläufig als Floating Point findet.
Die teste ich erst ob sie auch als Fixed Point taugen über die volle
Range und wie groß der Fehler ist.
Wenn es etwas taugt, dann weiß ich schon ganz genau wie viele Addierer,
Multiplizierer, Takte, ggf LookupRam usw ich brauche und wie genau das
Ergebnis wird, ohne das in VHDL ausprobiern zu müssen.
Nur zur Info:
Ich hab meinen Ansatz vor einigen Tagen weggeworfen und generiere mir
jetzt ordentliche Takte für jede Stufe der Verarbeitung.
Nachdem das alles getaktet ist, ist der Addierer jetzt auch einfach
geworden. Daten kommen an, es gibt einen Takt und feddisch. Dann geht
es in die nächste Stufe.
Funktioniert soweit formal. Ich hab noch eine Nuss zu knacken, dann kann
ich simulieren und auch auf der Hardware testen.
@Rotwang und Andere:
Ich denk jetzt mehr "in ICs" (egal wie komplex die sein müssten) und wie
ich die sinnvoll ansteuern kann. Deine Bemerkungen waren also fruchtend.
Ich find FPGAs jedenfalls sehr spannend und eine interessante
Herausforderung.
Nick
Nick M. schrieb:> Ich find FPGAs jedenfalls sehr spannend und eine interessante> Herausforderung.
Na dann viel Spass. Warte mal ab, bis du an die kniffeligen Sachen
kommst und es ein paar Jahre gemacht hast, dann kannst du keine FPGAs
mehr sehen.
