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
Nick M. schrieb: > fpga4fun nicht die beste Quelle für gutes Lernen zuviele Möchtegerns und Selbstdarsteller
> 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.
:
Bearbeitet durch User
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.
Bitte 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.