mikrocontroller.net

Forum: FPGA, VHDL & Co. Rechen-Framework für VHDL


Autor: Batzi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich habe zunehmende Anforderungen Berechnungen in VHDL, also in einem 
FPGA darzustellen. Es geht um in der Hauptsache CO-Berechnungen und 
Variationen von Reglern. Die Algorithmen sind eher einfacher Natur, als 
vom Konzept simpel und verständlich. Es gibt aber eine Reihe von Formeln 
umzusetzen und ich frage mich, ob man das nicht automatisieren kann.

Besonders die Breiten der unsigneds und signeds und die z.T. abartigen 
Bitschiebereien und Abschneidereien sind meine Sache nicht.

Geht das mit MATLAB und oder Python?

Es geht z.B. um sowas wie hier:

Y(t+1)= k*X(t)) + (1-k)*Y(t)/2 + (1-k*k)*Y(t-2)/2 ...

und oft auch die Quadrate und Kubike von X und Y. X und Y sind jeweils 
im Bereich von -100% und +100%, k = 0 .. 1.999

Ich würde gerne den range festlegen für k, x und den Rest rechnet das 
Programm aus. Also, was rauskommen kann, welche Bitbreite benötigt wird 
und wie man das zusammenstreichen muss, dass es stimmt.

Autor: Strubi (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Moin,

guck dir mal MyHDL und die diversen third-party Erweiterungen wie fixbv 
an.

Das macht das Leben etwas leichter, aber nicht alles automatisch. Wenn 
du solche Formeln effizient umsetzen willst, musst du immer noch etwas 
Grips in das Design der Pipeline stecken. Auch die hochgehypte 'HLS' 
kriegt das nicht so hin, wie man eigentlich will...

Autor: Andreas H. (ahz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Batzi schrieb:
> Geht das mit MATLAB und oder Python?

https://de.mathworks.com/products/hdl-coder.html

Hth

Andreas

Autor: Markus F. (mfro)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Batzi schrieb:
> Ich würde gerne den range festlegen für k, x und den Rest rechnet das
> Programm aus. Also, was rauskommen kann, welche Bitbreite benötigt wird
> und wie man das zusammenstreichen muss, dass es stimmt.

Na dann mach' das doch.

Das einzige Problem das Du hast, sind die Konstanten, soweit ich sehe. 
Die sind (weil eben signed oder unsigned) einfach mal 32 bit breit.

VHDL 2008 erlaubt die Definition von Konstanten mit Angabe der 
Vektorbreite.

Wenn die 2 nicht 32 (sondern eben nur 2) bit breit sein soll, dann 
schreibst Du nicht "2", sondern 2d"2" (oder 2u"2").

Entsprechend wird dein Ergebnisvektor bei der Multiplikation mit dieser 
Konstante eben nicht 32 + 32 Bit breit, sondern eben nur 32 + 2.

Wenn Du weiter gehen willst, kannst Du auch die arithmetischen 
Operationen von unsigned (oder signed) für eigene Datentypen 
überschreiben:
    subtype u16 is unsigned(15 downto 0);
    function "+" (f : u16; s : u16) return u16 is
        variable res : u16;
    begin
        res := resize(unsigned'(f) + unsigned'(s), res'length);
        return res;
    end function "+";

Ab jetzt kannst Du mit u16 addieren und bekommst wieder ein u16 
Ergebnis, mußt aber eben selber aufpassen, ob dein Ergebnis noch in den 
Vektor paßt (aber das ist anderswo auch so).

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas H. schrieb:
> https://de.mathworks.com/products/hdl-coder.html

Der HDL-Coder löst genau dieses Problem auch nicht. Das kann er auch 
nicht, ohne Hinweise auf die Art der Verwendung des Ergebnisses. Das 
gleiche gilt hierfür:

Strubi schrieb:
> Auch die hochgehypte 'HLS'
> kriegt das nicht so hin, wie man eigentlich will...

Wie auch soll ein Mathematiksyntheseprogramm (mehr sind die beide ja 
nicht) auch wissen, was man mit der Rechnung bezweckt? Es kann ja sein, 
dass der Überlauf gewollt ist, wie z.B. bei einer DDS, einer digitalen 
PLL oder ähnlichen Anwendungen.

Es gibt also hinsichtlich des Überlaufverhaltens (passiert / passiert 
nicht) und der Intention (gewollt, ungewollt)  eine Kombination von 4 
Fällen. Hinzu kommt dass der Überlauf nur scheinbar ist, infolge der 
Wertefüllung oder eben der funktionellen Abläufe wegen gar nicht 
auftritt. Diese Fälle müsste man typisieren.

Da ist es besser, das von Hand hinzuschreiben und ausdrücklich 
vorzugeben und zu benennen, was man möchte, also eben auch das 
Abschneiden der Werte und Vergessen eventueller Bits.


Hinsichtlich der Möglichkeit, Werte zu begrenzen und auszurechnen, wie 
breit die benötigten Vektoren dann sein müssen, mache ich das mit Excel. 
Solche Elementarfunktionen wie Addieren, Subtrahieren und Multiplizieren 
kopiert man dann als Blöckchen einfach rein und kriegt die VHDL als 
fertigen Block heraus. Besonders wirksam ist das immer bei Operationen, 
die den Ergebnisvektor nicht vollständig füllen, wie z.B. das Quadrieren 
eines singned: Limitiert man den z.B. nicht, kommen 2n-2 Bits heraus, 
bei händischer Berücksichtigung des Vorzeichens wie bei DDS 2n-1. 
Unterlässt man den Extremwert "-n" am Eingang, kommen immer maximal nur 
2n-2 heraus und im Fall der Füllung des Wertes von nur z.B. 70% kommt 
2n-3 heraus.

Beispiel: die 5 Bit Zahlen zwischen maximal -11 und +11 ergeben 7 bit 
statt scheinbaren 10. Nimmt man -16 x -16 ergibt sich 256 also 9 Bit.

Damit ist die Rechnung durchsichtig, vorgeplant, dokumentiert und man 
hat direkt Werte, die mit denen aus Modelsim zu vergleichen sind.

Das kann MATLAB nicht besser. Im Gegenteil: Wenn ich bei der Nutzung vom 
Systemgenerator im Simulink einen Vergleich setze, muss ich händisch 
Vektorbreiten mitgeben, weil dieser sonst trotz richtigen Werten 
verneint wird. Da gibt es eine Reihe von Dingen, die MATLAB übrigens 
durchaus können könnte und IMO auch können sollte. Z.B. die Berechnung 
der Vektorbreite nach einer Division zweier Binärzahlen mit Vor- und 
Nachkommastellen: Die Position des Kommas ist eigentlich fest definiert 
und kann von mir im Kopf ja auch berechnet werden, Simulink kennt die 
aber nicht.

: Bearbeitet durch User
Autor: Batzi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus F. schrieb:
> VHDL 2008 erlaubt die Definition von Konstanten mit Angabe der
> Vektorbreite.

Danke für den Hinweis und deine Ausführungen. Das ist schon richtig, 
löst aber nicht die Aufgabe, die Formeln richtig anzuwenden und zu 
übersetzen. Mit dem HDL-Coder von MATHWORK's konnte ich mich in der 
Zwischenzeit auseinandersetzen, aber nicht anfreunden, weil er das was 
ich möchte, nicht kann.

Eigentlich kann ich es nicht so recht glauben, dass es nichts geben 
soll. Codieren denn alle FPGA-Entwickler ihre Formeln per Hand?

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Batzi schrieb:
> Eigentlich kann ich es nicht so recht glauben, dass es nichts geben
> soll. Codieren denn alle FPGA-Entwickler ihre Formeln per Hand?

Nö. Aber einfach so die Formel hinschreiben is nich. Du musst Dir deine 
Pipeline/gewünschte Arithmetik definieren. Dann kannst du, wenn du 
zumindest bei Python tiefer in die Tricks mit Generatoren eingestiegen 
bist, an den Punkt gelangen, dass du die Formeln zumindest aufgebrochen 
relativ gut lesbar hinschreiben kannst und MyHDL dir daraus auch 
simulier/synthetisierbare HDL generiert. Also sowas wie:
def pipeline(...):
  
  @dsp_element
  def dmac1(a, b, k):
     y0 = k*a + (1-k) * b
     return y0

  @dsp_element
  def dmac2(a, b, k):
     y1 = ...
     return y1

  ...


Es gibt sowas auch für C++, aber das ist wesentlich uneleganter und 
schwerfälliger zu benutzen. Ich kann schlussendlich nur raten, das für 
seine spezifische Anwendung selber zu machen - wie man's dreht und 
wendet, muss man sich schliesslich damit beschäftigen, ob das Ding 
richtig rechnet.
Aber der Aufwand muss sich auch amortisieren, sonst schreibt man's doch 
besser in HDL hin.

Autor: Marcus H. (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Batzi schrieb:
> Eigentlich kann ich es nicht so recht glauben, dass es nichts geben
> soll. Codieren denn alle FPGA-Entwickler ihre Formeln per Hand?

Nein. Viele schauen erstmal, ob das Tool das alleine zufriedenstellend 
hinbekommt und wenden sich dann dem nächsten Problem zu. Man muss der 
Synthese natürlich die Möglichkeit geben, Randbedingungen wie z.B. 
Wertebereiche zu erkennen.

Wird die Arithmetik zu komplex, kann man es mit automatischem Pipelining 
bzw Registerbalancing versuchen. Das ist zumindest bei der ASIC Synthese 
eigentlich seit langem Stand der Technik.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> und MyHDL dir daraus auch
> simulier/synthetisierbare HDL generiert.
Bleibt die Frage, wie effektiv das HDL ist, das daraus erzeugt wrd. 
Solange das einfache lineare Rechenketten sind, mag das gehen. 
Allerdings kann man das auch gleich direkt hinschreiben.

Autor: hls-nap (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich würde an der Stelle einfach zum Q Format greifen...

Autor: Strubi (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5670402:
> Bleibt die Frage, wie effektiv das HDL ist, das daraus erzeugt wrd.
> Solange das einfache lineare Rechenketten sind, mag das gehen.
> Allerdings kann man das auch gleich direkt hinschreiben.

Was du pro "Stage" hinschreibst, wird auch so instanziert, d.h. wenn die 
Pipeline nicht voll ausgelastet ist (im Sinne der linearen Ketten), 
verschwendet man allenfalls Logik.
Ansonsten wird das Framework sehr viel kniffliger, z.B. wenn man eine 
fixe Anzahl MAC-Units vorgibt, und z.B. eine (hochdimensionale) 
Matrizen-Multiplikationn draufwirft, macht's keinen Sinn, das zu 
automatisieren.

Den Gewinn den man in jedem Fall gegenüber dem Hinschreiben in V* hat, 
ist, dass man die Beschreibung der Arithmetik von der Formel getrennt 
hält und die Wiederverwertbarkeit recht gut ist.

Autor: Name H. (hacky)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Besonders die Breiten der unsigneds und signeds und die z.T. abartigen
Bitschiebereien und Abschneidereien sind meine Sache nicht.

Das ist das absolute Minimum. Zusaetzlich sollte man eine gute Ahnung 
von Mathematik haben..
Sonst wird das nichts.

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.