mikrocontroller.net

Forum: FPGA, VHDL & Co. "Asynchroner Addierer" in Verilog (noob alert)


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.
Autor: Nick M. (muellernick)
Datum:
Angehängte Dateien:
  • Fail.v (1,84 KB, 38 Downloads)

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

: Bearbeitet durch User
Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: Klakx (Gast)
Datum:

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

Autor: Nick M. (muellernick)
Datum:

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

Autor: Nick M. (muellernick)
Datum:

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

: Bearbeitet durch User
Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nick M. schrieb:
> fpga4fun

nicht die beste Quelle für gutes Lernen

zuviele Möchtegerns und Selbstdarsteller

Autor: Nick M. (muellernick)
Datum:

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

Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: Nick M. (muellernick)
Datum:

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

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Youtube-Video "Books for Learning FPGA Design"

Autor: Robert P. (fpgazumspass) Benutzerseite
Datum:

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

Autor: C. A. Rotwang (Gast)
Datum:

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

Autor: Nick M. (muellernick)
Datum:

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

Autor: Nick M. (muellernick)
Datum:

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

Autor: Robert P. (fpgazumspass) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Nick M. (muellernick)
Datum:

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

Autor: K. L. (Gast)
Datum:

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

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.

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