Forum: FPGA, VHDL & Co. High Level Synthese aus C Code Spielerei oder ernste Anwendungen?


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.
von Hußnätter (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo, die Unis forschen ja an lauter Projekten, die aus C Code 
automatisch Hardware erstellen, die parallel zu einem Prozessor läuft 
und diesen beschleunigt.

Auch gibt es diverse Neukreationen von Hochsprachen, die sich dann zu 
Verilog/VHDL Code konvertieren lassen.

Gibt es Firmen, die das nutzen und damit Geld verdienen?
Oder sind alle ernsthaften Projekte immernoch in einer normalen HDL 
erstellt?

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ja, die gibt es. Auch Versuche dieser Art gibt es. Xilinx selbst bietet 
es bekanntlich an.

Die Thematik mündet aber immer wieder in dasselbe Ergebnis:

1) Der Aufwand zur Beschreibung eines Systems wird nicht geringer, wenn 
man die Sprache austauscht. Was an Informationen einem Synthestool 
mitgegeben werden muss, bleibt gleich.

2) C und C++ haben nicht die Mächtigkeit, um Systeme so zu formulieren, 
wie s nötig ist und müss(t)en erweitert werden. Das gibt es, bringt, 
aber wegen 1 keinen Vorteil bei der Systembeschreibung.

3) C ist am Ende nicht einfacher, als VHDL, wo es alles Benötigte schon 
gibt. C ist lediglich besser bekannt. Aber das ändert sich bekanntlich, 
weil immer mehr VHDL kennen.


C hat dann seine Berechtigung, wenn man sich Dinge beim Modellieren 
ersparen kann, weil sie in C einfacher zu formulieren sind oder man auf 
Vorhandenes zurückgreifen kann-

In Einzelfällen lassen sich in C Funktionen auf DSP-Plattformen 
prototypen bevor sie ins FPGA kommen, statt sie zu Simulieren. IN den 
meisten Fällen, müssen diese aber in eine Hardwareübersetzt werden.

In nur wenigen Fällen bleibt dabei die Ablaufstruktur von C erhalten und 
kann 1:1 gewandelt werden. Meistens muss die Struktur geändert werden. 
Parallelisieung und pipelining sind hier entscheidend. Das ist in C und 
speziell in C++ möglich, aber der Schritt dahin muss in beiden Sprachen 
gegangen werden und ist logischerweise vom Denk- und Planungsaufwand das 
gleiche. Automatisch geht da nicht. Es muss immer in irgendeiner Form 
eine Vorgabe gemacht werden, damit das Tool  die richtige Lösung 
auswählen kann.

In FPGAs gibt es erheblich mehr Freiheitsgrade!

Wenn das Verständnis für die Abläufe und Notwendigkeiten der Struktur 
aber vorliegt, ist die Lösung ausgewählt, ohne mit viel Aufwand das tool 
in diese Ecke zu bewegen. Das Formulieren in VHDL ist ein Klacks. Sind 
ja nur ein paar Befehle. Der Vorteil der Verwendung von C und LIBs und 
vorgefertigten Formeln ist natürlich da, wird aber immer kleiner, weil 
auch in VHDL heute nur noch Cores reingeschmissen und angeschlossen 
werden.

Man darf also nicht erwarten, dass die Welt einfacher wird, nur weil man 
in C++ Objekte definiert, deren Verhalten und Beschreibung dem 
C-Programmierer geläufiger sind, als VHDL und man sich dann Arbeit oder 
Kosten sparen könnte. Das ist nicht der Fall.

Soweit es Vorteile gibt, werden die täglich kleiner.

von Klakx (Gast)


Bewertung
1 lesenswert
nicht lesenswert
heute würde ich es nicht mehr als Spielerei bezeichnen. In Bereichen der 
Narichtentechnik und Signalverarbeitung wird dies schon erfolgreich 
verwendet.
Des Weiteren ist es auch zum Auslagern von zeitaufwendigen 
Software-Funktionen sinnvoll.

Natürlich verliert man Freiheitsgrade, aber das gab es auch von 
Assember->C oder "Gatter-setzen"->VHDL. Man gewinnt Zeit. Die höhere 
Abstraktion durch HLS ermöglicht es viel besser verschiedene 
Design-Auslegungen zu vergleichen oder automatisch optimieren zu lassen.

In VHDL wäre es beispielsweise viel zeitaufwendiger die Anzahl von 
Pipeline-Stufen zu ändern und das Design damit paralleler abarbeiten zu 
lassen.

Hußnätter schrieb:
> Gibt es Firmen, die das nutzen und damit Geld verdienen?
> Oder sind alle ernsthaften Projekte immernoch in einer normalen HDL
> erstellt?

https://semiwiki.com/tag/catapult/
hier findet man viele Artikel, wo Firmen HLS kommerziell im ASIC-Bereich 
einsetzen.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klakx schrieb:
> In VHDL wäre es beispielsweise viel zeitaufwendiger die Anzahl von
> Pipeline-Stufen zu ändern und das Design damit paralleler abarbeiten zu
> lassen.
Die pipeline Stufen ergeben sich aus den Anforderungen der Synthese und 
der Fähigkeiten des FPGAs. Die müssen nicht geändert werden, sondern 
können von der Synthese automatisch verteilt werden, wenn man es richtig 
formuliert.

Einfach ein paar FFs drauf un fertig.

Klakx schrieb:
> Man gewinnt Zeit. D

Ich erbitte ein Bespiel für einen C-Code, der kürzer ist, als das 
gleichwertige Pendant in VHDL.

von Bernd K. (prof7bit)


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5887104:
> Ich erbitte ein Bespiel für einen C-Code, der kürzer ist, als das
> gleichwertige Pendant in VHDL.

Oh, jetzt wirds interessant! Ich hoffe auf eine rege Flut von Beispielen 
und Gegenüberstellungen so daß man als VHDL- und FPGA-Unkundiger mal 
einen Einblick bekommt wie sowas aussieht und was es macht.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5887104:
> Die pipeline Stufen ergeben sich aus den Anforderungen der Synthese und
> der Fähigkeiten des FPGAs. Die müssen nicht geändert werden, sondern
> können von der Synthese automatisch verteilt werden, wenn man es richtig
> formuliert.

Ich glaube er meint die Arithmetik/Verarbeitungs-Pipeline, nicht simples 
Register-Pipelining, was die Synthese optimieren kann. Die muss man 
durchaus in VHDL von Hand stricken.

Weltbester FPGA-Pongo schrieb im Beitrag #5887104:
> Ich erbitte ein Bespiel für einen C-Code, der kürzer ist, als das
> gleichwertige Pendant in VHDL.

Naja, was erwartest du? Man kann eine Rechenformel linear einfach so 
hinschreiben. Allerdings bietet C nicht die Möglichkeiten, sich das 
einfach zu definieren, die Frameworks sind gehörig komplex, um daraus 
HDL zu erzeugen und selten transparent. In C++ geht's schon besser, aber 
IMHO ist es mit Python am besten zu handhaben. Beispiel:
  @hls(context)
  def calc(idata, coef, odata):
    r0 = idata[0]
    r1 = idata[7]

    r2 = r0 + r1
    r4 = r2 * coef[0]

    r3 = r0 - r1
    r5 = r3 * coef[1]

    odata[4] = r4
    odata[0] = r5


In MyHDL-Ausgabe:
..
    @always(clk.posedge)
    def s1_proc():
        r0.next = idata[0]
        r1.next = idata[7]

    @always(clk.posedge)
    def s2_proc():
        r2.next = r0 + r1
..

Die Arithmetik, Rundungsdetails und Umwandlung in korrektes HDL macht 
das dahinterliegende MyHDL-Framework.
Ich möchte den Xilinx-Ansatz nicht dissen, aber sehe ihn eher als wenig 
produktiv für komplexe DSP-Pipelines, mal vom "vendor lock-in" 
abgesehen.

Hußnätter schrieb:
> Gibt es Firmen, die das nutzen und damit Geld verdienen?
> Oder sind alle ernsthaften Projekte immernoch in einer normalen HDL
> erstellt?

Ich würde fast sagen, dass es kaum noch Sinn macht, komplexe 
'ernsthafte' Designs die konfigurierbar sein müssen (wie CPU SoCs, etc), 
noch in bare-metal HDL zu machen. Immer mit Ausnahmen, natürlich.
Auch wenn jetzt Ansätze wie chisel eher als Murks einzustufen sind: 
RISC-V ist auch ein ernsthaftes Projekt...oder?

von daniel__m (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5887104:
> Ich erbitte ein Bespiel für einen C-Code, der kürzer ist, als das
> gleichwertige Pendant in VHDL.

hi, in etwa so

int distance(int a, int b) {
  return sqrt(a*a+b*b);
}

?

HLS hat seine Einschränkungen. Da gibt es keine Diskussion, auch die 
Resourceneffizienz ist schlechter als bei HDL. Es verhält sich 
vermutlich wie Assembler zu C/C++. Der große Gewinn ist die gesparte 
Zeit (nach der grundlegenden Einarbeitung). Ich setzte HLS gerne für 
reines numbercrunching ein, wo ich mich auf den Algo konzentriere und 
der Kontrollpfad von HLS automatisch erzeugt wird. Per Hand möchte ich 
komplexe Berechnungen nicht (mehr) manuell ausbalanzieren, ggf. mit 
Hand-Shaking-Signalen hantieren und Core/Primitive Latenzen kennen. 
Inzwischen wird auch immer öfter Floating Point Artihmetik (zumindest 
punktuell) eingesetzt, das macht es nicht einfacher.

Definitiv ist HLS keine Lösung für jedes Problem, aber es ist ein 
Blick wert.

Grüße

von FPGA zum Spass (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die VHDL implementierung davon ist gleichlang....

Beschreib bitte noch was du dir davon erwartest:
- Latenz
- Ressourcenverbrauch
- ...

Das Problem ist doch eher was daraus gebaut wird. WENN HLS da effizient 
wäre und z.b. automatisch Pipelining oder was auch immer macht, dann 
wäre das ja ok.
Nur weiß HLS eben nicht was ich als Entwickler daraus machen will und 
DAFÜR braucht man dann wieder VHDL.

Das sind eben die Probleme wenn man etwas synthetisieren will.

Du wirst ja wohl kaum diese Rechnung da oben in einem Takt haben wollen.

von Klakx (Gast)


Bewertung
0 lesenswert
nicht lesenswert
FPGA zum Spass schrieb im Beitrag #5888347:
> Das Problem ist doch eher was daraus gebaut wird. WENN HLS da effizient
> wäre und z.b. automatisch Pipelining oder was auch immer macht, dann
> wäre das ja ok.

Das ist es ja der Witz dabei. Über Pragmas und Constraints gibst du das 
Designziel vor. Z.b. Anzahl der Takte.

von daniel__m (Gast)


Bewertung
0 lesenswert
nicht lesenswert
FPGA zum Spass schrieb im Beitrag #5888347:
> - Latenz
> - Ressourcenverbrauch

Das hängt massiv von deinen weiteren Designvorgaben ab. Klassisch wird 
die Taktfrequenz als erste Vorgabe benötigt. Diese sagt dem HLS, wieviel 
Kombinatorik es zwischen zwei Registern packen darf (daher ist die 
Kenntnis des FPGA-Typs relevant). Als nächste Angabe wird oft der II 
angegeben: alle wieviele Takte soll ein neuer Wert verarbeitet werden, 
z.B II=1: jeder Takt neue Daten. Daraus resultiert dann die Latenz und 
der Resourcenverbrauch (ähnlich dem ohmschen Gesetz). Latenz und 
Resourcenverbrauch werden dann üblicherweise auf Akzeptanz bewertet 
(manuell vom Entwickler per Report), und wenn nicht, müssen die Vorgaben 
überdacht werden: z.B. höherer Takt, dafür nur II=2, was 
Resourcensharing ermöglicht bei ca. gleicher Latenz.

Ich glaube, ich werde mal myHDL anschauen, bin aber skeptisch, wie 
effizient die Resourcen sind. Ich kann mir aktuell nicht vorstellen, 
dass ohne Kenntnisse des FPGA-Typs eine effiziente Beschreibung 
herauskommt.

grüße

von Vancouver (Gast)


Bewertung
0 lesenswert
nicht lesenswert
daniel__m schrieb:
> Ich glaube, ich werde mal myHDL anschauen

MyHDL ist eine tolle Sache, aber man sollte sich vor Augen halten, dass 
man damit keinen "FPGA in Python programmiert". Eine MyHDL-Bescheibung 
sieht genauso aus wie eine VHDL- oder Verilog-Beschreibung (eben ein 
RTL-Design, kein Algorithmus), aber mit den Sprachelementen von Python. 
Ohne eine Vorstellung, wie das beschriebene Design nach der Synthese 
aussehen würde, kommt man mit MyHDL nicht ans Ziel, selbst wenn man 
Python beherrscht.

von Thomas R. (Firma: abaxor engineering) (abaxor)


Bewertung
1 lesenswert
nicht lesenswert
Ich benutze regelmäßig Vivado HLS, um Berechnungen zu implementieren.

Der große Vorteil bei C/C++ ist, dass es eine natürliche Sequenz hat. 
Diese muss man in VHDL mit einer FSM nachbilden. Das nimmt einem das 
HLS-Tool ab.

Auch wenn Vivado von Xilinx ist, kann man damit Code für Altera/Intel, 
Lattice und Microsemi generieren. Man muss die Einstellungen nur so 
machen, dass keine Xilinx spezifischen Komponenten instanziert werden.


Hier ist der C++ Code für einen Interpolator.

#include "ap_int.h"

ap_uint<12> sld_ntc_interpol (ap_uint<12> i_voltage) {

  ap_uint<12> s_rem;
  ap_uint<12> s_idx;
  ap_uint<12> s_slope;
  ap_uint<12+12> s_diff_full;
  ap_uint<12> s_diff;
  ap_uint<12> s_temp;
  ap_uint<12> s_temp_tbl[]=
      {1 * 2, // 0 V
       1 * 2,   // 0.625
       1 * 2, // 1.25
       1 * 2, // 1.875
       1 * 2, // 2.5
       20.558 * 2, // 3.125
       36.768 * 2, // 3.75
       47.108 * 2, // 4.375
       (328-273) * 2}; // 5 

  s_rem = i_voltage % (1<< 9);
  s_idx = i_voltage / (1<< 9);
  s_slope = s_temp_tbl[s_idx+1] - s_temp_tbl[s_idx];
  s_diff_full = (s_slope * s_rem);
  s_diff = (s_diff_full + (1<< 8)) / (1<< 9);
  s_temp = s_diff + s_temp_tbl[s_idx];
    return s_temp;
}

Das ist ein NTC-Interpolator, um eine Spannung in eine Temperatur 
umzurechnen. Also nichts was besonders schnell ist. So sieht die Entity 
aus:
entity sld_ntc_interpol is
port (
    ap_clk : IN STD_LOGIC;
    ap_rst : IN STD_LOGIC;
    ap_start : IN STD_LOGIC;
    ap_done : OUT STD_LOGIC;
    ap_idle : OUT STD_LOGIC;
    i_voltage_V : IN STD_LOGIC_VECTOR (11 downto 0);
    ap_return : OUT STD_LOGIC_VECTOR (11 downto 0) );
end;

Man legt i_voltage_v an, aktiviert ap_start. Nach ein paar Takten liegt 
das Ergebnis an ap_return an und ap_done wird aktiviert. Das ist nur ein 
einfaches Beispiel, es gehen auch komplexere Sachen.

Tom

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Vancouver schrieb:
> MyHDL ist eine tolle Sache, aber man sollte sich vor Augen halten, dass
> man damit keinen "FPGA in Python programmiert". Eine MyHDL-Bescheibung
> sieht genauso aus wie eine VHDL- oder Verilog-Beschreibung (eben ein
> RTL-Design, kein Algorithmus), aber mit den Sprachelementen von Python.

Eigentlich ist MyHDL auf einer Meta-HDL-Ebene angesiedelt, d.h. man 
beschreibt in Python, wie eine HDL-Beschreibung erzeugt werden soll. Wie 
schon von Vancouver völlig richtig erkannt, ist das keine algorithmische 
Besschreibung z.B. von Signalverarbeitungs- oder Rechenfunktionen.

von Martin S. (strubi)


Bewertung
0 lesenswert
nicht lesenswert
Andreas S. schrieb:
> Eigentlich ist MyHDL auf einer Meta-HDL-Ebene angesiedelt, d.h. man
> beschreibt in Python, wie eine HDL-Beschreibung erzeugt werden soll. Wie
> schon von Vancouver völlig richtig erkannt, ist das keine algorithmische
> Besschreibung z.B. von Signalverarbeitungs- oder Rechenfunktionen.

Ich schrob auch generisch oben "Python". MyHDL generiert nicht die 
Pipeline aus der Formel. Die Generatoren für solche HLS-Sachen muss man 
sich selber stricken, also auf jeden Fall für seine spezifischen 
DSP-Elemente die Arbeit reinstecken. Aus derselben Formel will man z.B. 
Vektor(SIMD)-Befehle ausspucken, oder HW generieren.

Ansonsten sollte natürlich klar sein, dass die MyHDL-Erweiterung Python 
'nur' zu einer HDL im Sinn von VHDL und Verilog macht. Also: nach wie 
vor wird auf dem Layer in getakteten Prozessen und Kombinatorik gedacht, 
zu Verilog/VHDL schenkt sich nur, dass das Datentypen-Handling deutlich 
flexibler ist, neben einiger anderer cleverer Schmankerl, wie 
Wiederverwertung und die beliebte Reset-Thematik (ASIC vs. FPGA).

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
> Die pipeline Stufen ergeben sich aus den Anforderungen der Synthese und
> der Fähigkeiten des FPGAs.
Es gibt Fälle, wo diese Einteilung benötigt wird, wenn eine bestimmte 
Rhythmizität der pipe benötigt wird, weil sie mehr, als eine Dimension 
hat oder eine dedizierte Länge braucht, die mit anderen Zweigen 
zusammenpasst, wie bei Iterationen oder emulierten Rekursionen.

Die genaue Definition ist dann aber in HLS oder auch Simulink nicht 
wirklich einfacher. Macht man das design nicht im Kopf, sondern z.B. mit 
Excel, dann hat man eigentlich das Instrument an der Hand, um die FF 
automatisch setzen zu lassen und auch passend zu verändern. Das geht 
allemal schneller, als es manuell über die Eingabe beim tool zu machen.

> Die können von der Synthese automatisch verteilt werden,
> wenn man es richtig formuliert.
Sie können auch dann verteilt werden, wenn man es gar nicht formuliert 
:-)
Man lässt die FF einfach weg:-)

Aber wie gesagt: Eine Änderung, die einer o.g. Qualität bedarf, kann 
auch nicht beliebig eingestellt werden.

 Wenn schön bräuchte es eine übergeordnete Sprache, mit der solche 
pipelines definiert und gestaltet werden können.

Davon ist HLS aber noch sehr weit weg.

von daniel__m (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> Das geht
> allemal schneller, als es manuell über die Eingabe beim tool zu machen.

Hmm, könnte sein. Wie gesagt, HLS ist nicht für jedes Problem gleich gut 
geeignet (Hammer <> Nagel).

Jürgen S. schrieb:
> Es gibt Fälle, wo diese Einteilung benötigt wird, wenn eine bestimmte
> Rhythmizität der pipe benötigt wird, weil sie mehr, als eine Dimension
> hat oder eine dedizierte Länge braucht, die mit anderen Zweigen
> zusammenpasst, wie bei Iterationen oder emulierten Rekursionen.

Klingt mir ganz nach dem Latency-Pragma. Das habe ich auch schon 
eingesetzt, um eine HLS-Implementierung mit einem anderen Pfad zu 
synchronisieren.

Vancouver schrieb:
> Eine MyHDL-Bescheibung
> sieht genauso aus wie eine VHDL- oder Verilog-Beschreibung (eben ein
> RTL-Design, kein Algorithmus).

Dann ist MyHDL wohl doch nichts für mich, wenn ich in RTL denken muss, 
da möchte ich lieber bei VHDL bleiben. Das ist ja gerade das schöne an 
HLS, dass ich vordergründig nur den Algo betrachten muss und er verteilt 
die Schritte auf die Pipelinestufen (inkl. ready/valid hand-shaking, 
wenn gewünscht). Gut, die Simulation in MyHDL wird deutlich schneller 
sein, jedoch muss ich nach der Transformation in VHDL diese auch testen.

PS: das bietet HLS auch: Simulation der Algorithmik in C mit hoher 
Geschwindigkeit, Kontrolle der HDL (mit flow-control, etc) durch 
"Co-Simulation".

grüße

von Jürgen S. (engineer) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Ich sehe einen Vorteil darin, eventuelle Algos auf C-basierten 
Plattformen zu testen. Ansonsten kann man in VHDL das pipeline delay 
Thema ja auch entkoppeln. Wenn ich nicht mit Excel arbeite, was die 
delays und Bezeichnungen automatisch vergibt und den Code baut, dann 
schreibe ich es in VHDL ohne delays / FF hin und habe ebenfalls direkt 
simulationsfähigen Code, der richtig arbeitet.

In den meisten Fällen, in denen die exakte Delaytiefe iirellevant ist, 
kann man dann auch n FF-Stufen dahintersetzen und es von der Synthes 
reinbalcieren lassen.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
daniel__m schrieb:
>> Eine MyHDL-Bescheibung sieht genauso aus wie eine VHDL- oder
>> Verilog-Beschreibung (eben ein RTL-Design, kein Algorithmus).
>
> Dann ist MyHDL wohl doch nichts für mich, wenn ich in RTL denken muss,
> da möchte ich lieber bei VHDL bleiben.

Der Hauptvorteil von MyHDL ist nicht, dass die Hardware für die Synthese 
schöner beschrieben werden kann, sondern dass man in der Simulation 
vollen Zugriff auf sämtliche Python-Bibliotheken hat.

Aber ich glaube, der wichtigste Punkt wurde am Anfang gesagt:

Weltbester FPGA-Pongo schrieb im Beitrag #5886721:
> Wenn das Verständnis für die Abläufe und Notwendigkeiten der Struktur
> aber vorliegt, ist die Lösung ausgewählt, ohne mit viel Aufwand das tool
> in diese Ecke zu bewegen. Das Formulieren in VHDL ist ein Klacks.

Wenn ich die Lösung bereits habe, ist das Hinschreiben kein Problem.

Aber das, was akademisch unter "design space exploration" läuft, also 
einfach mal verschiedene Ansätze ausprobieren, deren Vor- und Nachteile 
gegeneinander abzuwägen und dann für die jeweilige Anwendung 
auszuwählen, ist sehr aufwändig.

Damit wären wir bei der Assembler-Diskussion angekommen: Ein fertiger 
Algorithmus lässt sich einfach in Assembler runterschreiben und wird 
dann auch funktionieren. Aber der Aufwand, mal schnell (global) "-O3" 
gegen ein "-Os" abzuwägen, ist enorm.

von Kinderkacke Entsorger (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Der Hauptvorteil von MyHDL ist nicht, dass die Hardware für die Synthese
> schöner beschrieben werden kann, sondern dass man in der Simulation
> vollen Zugriff auf sämtliche Python-Bibliotheken hat.

Ja und damit würde sich MyHDL wunderbar für Einsteiger eignen, falls 
sich die Einsteiger ausgiebig mit der Simulation befassen würden, statt 
gleich den FPGA zu konfigurieren.
Aber so glotzen sie nur blöde, weil die Hardware nix tut und sie keine 
Ahnung haben welche Schaltvorgänge nun konkret ausgeführt werden. Falls 
sie überhaupt wissen, wass Schaltvorgänge sind, weil die ja nicht im 
C-Syntax ersichtlich sind.

von S. R. (svenska)


Bewertung
1 lesenswert
nicht lesenswert
Kinderkacke Entsorger schrieb:
> Ja und damit würde sich MyHDL wunderbar für Einsteiger eignen,
> falls sich die Einsteiger ausgiebig mit der Simulation befassen
> würden, statt gleich den FPGA zu konfigurieren.

Wenn ich nur simulieren wollte, könnte ich auch programmieren. Letzteres 
ist einfacher. Als Einsteiger fasse ich Hardware hauptsächlich an, um 
was zu sehen (blinkende LEDs, Siebensegmentanzeigen, ...).

Kinderkacke Entsorger schrieb:
> Falls sie überhaupt wissen, wass Schaltvorgänge sind,
> weil die ja nicht im C-Syntax ersichtlich sind.

Vollkommen überraschend ist C-Syntax in MyHDL kein Thema.

von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Kinderkacke Entsorger schrieb:
> Ja und damit würde sich MyHDL wunderbar für Einsteiger eignen, falls
> sich die Einsteiger ausgiebig mit der Simulation befassen würden, statt
> gleich den FPGA zu konfigurieren.

Viele Einsteiger haben aber große Verständnisprobleme damit, dass sie 
auf der Hardware eben nur einen Bruchteil der Betriebsmittel wie in der 
Simulation möglich zur Verfügung haben. Es gab doch erst kürzlich hier 
einen Thread zur VGA-Ausgabe eines in einer Datei gespeicherten Bildes. 
Oder auch vor längerer Zeit die Frage, wie man denn nun einen 
TCP/IP-Socket auf dem instantiierten Ethernet-IP-Block öffne, usw..

> Aber so glotzen sie nur blöde, weil die Hardware nix tut und sie keine
> Ahnung haben welche Schaltvorgänge nun konkret ausgeführt werden. Falls
> sie überhaupt wissen, wass Schaltvorgänge sind, weil die ja nicht im
> C-Syntax ersichtlich sind.

Aus genau diesen Gründen halte ich es für wichtig, sehr frühzeitig 
(=sofort) auch(!) mit realer Hardware zu arbeiten, damit sich die 
Softwaresicht nicht zu stark festigt.

von Weltbester FPGA-Pongo (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Damit wären wir bei der Assembler-Diskussion angekommen:
Das kann man aber nicht vergleichen. C-Ablauf und ASM-Lauf sind ähnlich.

VHDL <-> C ist schon deutlich anders und deckt andere Dinge ab.

Mir ging es daraum aufzuzeigen, dass durch die Verwendung von C, das 
Finden eines Konzeptes nicht wirklich vereinfacht wird. Ich habe im 
Gegenteil den Eindruck, dass diejenigen, die aus der C-Ecke kommen, so 
Ablauf-orientierten Lösungen greifen, und FPGA-spezifische Dinge 
garnicht sehen und Kennenlernen.

Dann bleibt es nur bei dem Vorteil einer vereinfachten Beschreibung, 
innerhalb des scheinbar richtigen Konzeptes.

Ich schreibe das, was ich seit 20 Jahren FPGA-Lösungen sehe und die 
Versuche vor Augen habe, die mit C-ähnlichen Ansätzen produziert wurden 
und werden.

Die Lösungen werden eher schlechter. In einem aktuellen Fall, wurde in 
einem Projekt alles erdenkliche in C formuliert und verinfacht dann auch 
gleich ins SoC gestopft. Die Hälfte der Moduln hätte in gänzlich anderer 
Form ins FPGA gehört. Dann hätte hätte man keinen fetten "Ultraslave" 
gebraucht und wäre mit einem Drittel der FPGA-Kosten davon gewesen. Was 
bei der Stückzahl eine fette Summe ausmacht und jeden Mehraufwand an 
VHDL-Entwicklung rechtfertigt hätte.

Und:

Ich habe den Eindruck, dass Entscheider aufgrund der Existenz solcher 
Systeme, mehr und mehr dazu neigen, FPGA-Themen zu unterschätzen. Noch 
mehr, als sie es jetzt schon tun. Da werden dann C-Entwickler 
beauftragt, die nie eine HW gemacht haben.

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5892068:
>> Damit wären wir bei der Assembler-Diskussion angekommen:
> Das kann man aber nicht vergleichen.
> C-Ablauf und ASM-Lauf sind ähnlich.

Sicher, beides ist "Software programmieren".

> VHDL <-> C ist schon deutlich anders und deckt andere Dinge ab.

Ich sehe VHDL/Verilog (also die RTL-Sicht) auf der gleichen Ebene wie 
Assembler, nicht wie C. Natürlich nebeneinander, weil Hardware und 
Software nicht das gleiche sind.

> Die Lösungen werden eher schlechter.

Schau dir Softwareentwicklung an und die siehst den gleichen Trend und 
auch die Gründe dafür. Ist so, nimm es hin.

> Da werden dann C-Entwickler beauftragt, die nie eine HW gemacht haben.

Wieviele C-Entwickler gibt es, wieviele VHDL-Entwickler?
Welcher Anteil davon ist kompetent?

Kostenfrage. In unseren Breiten ist der Entwickler der Kostenfaktor, 
nicht der FPGA. Solange die verkürzte Entwicklungszeit (inkl. 
time-to-market) die höheren Produktkosten rechtfertigt, lohnt sich das. 
Und solange hinten noch Gewinn rausfällt, passt alles.

von Gatterloge (Gast)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
>> Da werden dann C-Entwickler beauftragt, die nie eine HW gemacht haben.
>
> Wieviele C-Entwickler gibt es, wieviele VHDL-Entwickler?
> Welcher Anteil davon ist kompetent?

Meine Schätzung:

Anzahl C-Programmierer : FPGA-Entwickler:  1: 100 ... 1000

Kompetenz C-Programmierung bei FPGA_Entwickler: 50%
Kompetenz FPGA-Entwicklung bei C-Programmierer:  0.1 ‰

Schulungsaufwand FPGA-Entwickler zu C_Programmierer : Gering bis mittel
Schulungsaufwand C_Programmierer zu FPGA-Entwickler : mittel bis sehr 
hoch

von Bastian (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gatterloge schrieb:
> Anzahl C-Programmierer : FPGA-Entwickler:  1: 100 ... 1000

Du meinst es sicher anders herum, nehme ich an.

Egal, ich denke, du unterschätzt die Zahl der FPGA-Kenner. Ich würde es 
10:1 sehen. Aber 99% auf beiden Seiten sind Anfänger, die kaum mehr 
können, als Schleifen und Funktionsaufrufe, bzw Komponentenverdrahtung.

von Elbi (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wir haben seit einigen Jahren eine wachsende Entwicklungsabteilung, die 
sich mit dem rapid design befasst. Alles, was an Produkten released 
wird, wird auf Eval-Plattformen geprototyped und so beschleunigt.

Wir arbeiten zu 80% mit Vivado, der Rest ist Lattice. Altera wurde aus 
verschiedenen Gründen aus der Abteilung entfernt, was ich schade fand, 
weil ich privat nur mit Altera baue.

Xilinx kommt besonders bei den Hochgeschwindigkeitsanwendungen und 
Interface-lastigen designs in Spiel, daher läuft gefühlt 90% der 
schwierigen Dinge in Vivado. Für die Innereien haben wir daher auch 
überwiegend Xilinx-Cores im Gebrauch. Aus Kompatibiltätsgründen wird 
jeder Pfurz mit einem Axi-wrapper versehen und die Daten zwischen RPU 
und PL hin und hergewürfelt.

Seit etwa 1 Jahr ist auch verstärkt HLS im Gebrauch. Geht super schnell 
für Anwendungen, die sich in C einfach formulieren lassen. Das sind 
gefühlt 30% der Innereien. Weitere 40% gehen so einigermassen flott und 
werden auch nicht größer.

Zu 70% ist das recht brauchbar würde ich sagen. Das einzige, was bei den 
Lösungen auftritt, ist eventuell mehr Einlesebedarf und Verständnis für 
die Xilinx-typischen Vorgehens- und Denkweisen und ein Mehraufwand im 
Silizim sowie in den Abläufen. Das bedeutet größere Delays, Latenz, 
Laufzeit und vor allem auch mehr Stromverbrauch, als generische 
Lösungen.

Das letzte Drittel der Aufgaben aber wirf enorme Umstände auf! Jede noch 
so kleine Funktion muss verpackt, in IPs gebacken und umständlich 
instanziiert werden. Konfiguration über AXI erfordert gleich einen 
Prozessor und zusätzliche Funktionen im BSP und den root Code.

Wir haben hier aber einige Jungspunde, die vollständig AXI-süchtig sind 
und davon nicht wegkommen. Scheinen sich bei PLC2 angesteckt zu haben. 
Jetzt wird alles AXI-fiziert, was bei 3 nicht auf den Bäumen ist.

Obendrein sind sehr viele in der Abteilung, die von der C-Welt kommen 
und am Liebsten alles auf dem Prozessorsystem laufen lassen würde.

Das Resultat ist an vielen Stellen der 10fache Aufwand, wie es "normal" 
gewesen wäre. Das macht vieles wieder kaputt.

Das größte Problem sehe ich in der Abhängigkeit zu Xilinx. Wenn da 
irgend ein CoreGen oder eine Script nicht läuft oder fehlt, dann geht 
alles in die Hose und man findet den Fehler einfach nicht.

HLS ist ein weiterer Schritt in diese Richtung. Wenn die Funktion stimmt 
und alles zusammenpasst, ist das fein und bequem. Aber wehe, wenn nicht.

von Christophz (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Danke Elbi für diesen Blick aus deiner praktischen Erfahrung.

Mein Problem an dieser ganzen Diskussion zeigt sich schon im Titel: 
"High Level Synthese aus C Code"

Wenn ich Software schreibe will ich seit Jahren schon kein C mehr 
benutzen, bekomme jedes mal Fluchtgedanken wenn ich das machen muss. 
Eigentlich ist hier der Trend ja auch Richtung höherer Abstraktion bzw. 
Sprachen in denen weniger kaputt gemacht werden kann (Rust, D, Ada, 
Matlab code generator, zum teil anwendbar auf C++).

High level synthese ist ein sehr spannendes Thema und die aktiven FPGA 
Entwickler wissen ja (wie auch die Diskussion hier zeigt) dass da viel 
Zeitersparnis denkbar ist, weil oft die Struktur ab einer gewissen 
Planungsstufe klar ist und dann von Hand viel HDL code geschrieben 
werden muss.

Meiner Meinung nach ist C viel zu low-level (ist ja auch zu low-level 
für moderne CPUs...) um als vernünftige Basis zu dienen um all die 
Zukunftsvisionen zu erreichen, die mit HLS verknüpft werden. Einen guten 
Vorschlag habe ich derzeit aber auch nicht.

von Gatterloge (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christophz schrieb:
> dass da viel
> Zeitersparnis denkbar ist, weil oft die Struktur ab einer gewissen
> Planungsstufe klar ist und dann von Hand viel HDL code geschrieben
> werden muss.

Nein, es muss nicht viel Code mit der Hand geschrieben, weil FPGA's 
durch parallele und kanonische Strukturen charakterisiert sind. Wenn für 
ein OS Millionen LoC's geschaffen werden müßen, reichen für den 
zugrundeliegenden Prozessor einige Zehntausend.

Der Zeitaufwand steckt in der Verifikation, nicht in der Code 
Erstellung.

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gatterloge schrieb:
> Der Zeitaufwand steckt in der Verifikation, nicht in der Code
> Erstellung.

Sehr richtig, und genau hier verspricht HLS ja auch Möglichkeiten zur 
Zeitersparnis.

Sei es simple, wie schon geschrieben, dass C schneller rennt als ein HDL 
Simulator. Auf höherer Abstraktionsstufe hat man weniger Lines-of-code 
(LoC) und somit ist eine hohe code coverage schneller erreicht in der 
Verifikation. Die Vision ist, das auch zu erreichen/bewahren ohne die 
parametriesierbarkeit/design-space-exploration einzuschränken.

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christophz schrieb:
> Meiner Meinung nach ist C viel zu low-level (ist ja auch zu low-level
> für moderne CPUs...) um als vernünftige Basis zu dienen um all die
> Zukunftsvisionen zu erreichen, die mit HLS verknüpft werden. Einen guten
> Vorschlag habe ich derzeit aber auch nicht.

Ein Beispiel wie ich zu solchen Aussagen komme und die mir einen 
Vorgeschmack gegeben haben, kam mir gestern wieder in den Sinn:

Die Domain-specific-language FAUST (https://faust.grame.fr/) "Faust 
(Functional Audio Stream) is a functional programming language for sound 
synthesis and audio processing" wird meistens in C++ Code übersetzt aber 
kann auch in C, JAVA, JavaScript, LLVM bit code, WebAssembly übersetzt 
werden.

Schon 2006 kam ein Paper heraus, wo ein proof-of-concept vorgestellt 
wurde, um FAUS in VHDL zu übersetzen 
(https://hal.archives-ouvertes.fr/hal-02158935/document). Sehr 
interessant zu lesen, da sich die Autoren bewusst waren, das z. B. die 
Umsetzung von float nach fixpoint Arithmetik automatisch passieren soll 
aber trotzdem transparent für den Benutzer, so dass bei Bedarf vorgaben 
gemacht werden können.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Christophz schrieb:
> Meiner Meinung nach ist C viel zu low-level (ist ja auch zu low-level
> für moderne CPUs...) um als vernünftige Basis zu dienen um all die
> Zukunftsvisionen zu erreichen, die mit HLS verknüpft werden. Einen guten
> Vorschlag habe ich derzeit aber auch nicht.

C ist ja auch als portable Low-Level-Sprache eine Schicht über'm 
Assemblercode designt, warum nicht auch für moderne CPUs.
Nur taugt sie halt als Beschreibungssprache nicht, und 
#pragma-Verunstaltungen gelten als tool-spezifischer Murks, der in der 
Sprache eigentlich nichts zu suchen hat.

Christophz schrieb:
>> Der Zeitaufwand steckt in der Verifikation, nicht in der Code
>> Erstellung.
>
> Sehr richtig, und genau hier verspricht HLS ja auch Möglichkeiten zur
> Zeitersparnis.

Da bin ich mir eben nicht ganz sicher. Mag sein, dass man mit dem 
C-basierenden HLS-Ansatz von Xilinx in der SDR-Domäne einige Treffer 
landen kann, aber bei Bildverarbeitung sieht's z.B. schon anders aus.

Und besagte Abhängigkeit von Tools/Herstellern ist unter Umständen ein 
veritabler Graus, wenn man das Zeug nach Jahren mal warten muss.

Python deckt da zumindest meine Wunschliste komplett ab, d.h. es geht 
aus einem Guss:
- Volle Kontrolle über Instanzierung der Logik
- Verifikation, Simulation 'eingebaut' (per MyHDL)
- Konversion nach VHDL/Verilog per MyHDL
- Co-Simulation, Geräte-Ansteuerung externer HW

Das lässt sich dann auch nach vielen Jahren wieder aus der 
Revisionskontrolle rausgraben, bzw. laufend per kontinuierliche 
Integration bauen, um auch das Werkzeug gegen die Anwendung zu 
verifizieren.
Solche Mechanismen vermisse ich bei den HLS-Toolchains bisher, bzw. ist 
das mit TCL deutlich frickeliger und bei jedem Tool (Modelsim, Diamond, 
ISE/Vivado) anders.
Für die Zeitersparnis im Gesamtbild muss man auch das Code- und 
Projektmanagement über die Jahre rechnen. Da würde ich das ähnlich wie 
Elbi in seinem Erfahrungsbericht unterschreiben.

Der FAUST-Ansatz klingt auch interessant, ist mir nur noch nicht 
untergekommen. Es ist halt immer schwierig, die Industrie von 
bestehenden Frickellösungen wegzukriegen, und Optimierungen sind auch 
oft gar nicht erwünscht (könnte ja eine Stelle wegfallen).

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> C ist ja auch als portable Low-Level-Sprache eine Schicht über'm
> Assemblercode designt, warum nicht auch für moderne CPUs.

Mal ein paar Stichworte die mir in den Sinn kommen:
- Einzelnes Bit lesen/testen/schreiben auf Architektur die das als 
Atomic Opcode besitzt. Fühlt sich nicht an wie high-level programmieren 
sondern wie HDL coden nach "Guck ins Handbuch, damit auch wirklich ein 
RAM rauskommt, wenn du ein RAM willst"
- Algorithmen so schreiben, dass der Compiler die Flags von Registern 
optimal nutzen kann (C weiss ja nicht was ein Carry ist)
- Alles was mit Vektorbefehlen zu tun hat (SSE, Neon etc.)
- C geht davon aus, dass eine CPU kein Pipelining hat.
- Und mit Multicore Systemen ist C definitiv überfordert

Ich war erstaunt, dass Fortran unter anderem immer noch eingesetzt wird, 
weil es sich herausgestellt hat, dass es so high-level ist, das älterer 
Fortran Code auf modernen Maschinen recht gut skaliert und moderne CPU 
Features gut nutzen kann (Ich finde den Artikel dazu gerade nicht mehr).

Strubi schrieb:
> Der FAUST-Ansatz klingt auch interessant, ist mir nur noch nicht
> untergekommen. Es ist halt immer schwierig, die Industrie von
> bestehenden Frickellösungen wegzukriegen, und Optimierungen sind auch
> oft gar nicht erwünscht (könnte ja eine Stelle wegfallen).

Wurde nach meinem Wissen nach dem proof-of-concept auch nicht 
weiterentwickelt. Sollte mehr zeigen, wie meine Sichtweise auf HLS ist.

Für die HDL Umsetzung hilft es z. B. dass Faust eine "Data stream 
oriented Language" ist. So wie eben auch Simulink oder Labview. Was eine 
natürliche Betrachtungsweise für DSP Algorithmen ist.

Strubi schrieb:
> Und besagte Abhängigkeit von Tools/Herstellern ist unter Umständen ein
> veritabler Graus, wenn man das Zeug nach Jahren mal warten muss.

Definitiv. Ist aus meiner Sicht der Hauptgrund wieso sich fasst niemand 
getraut etwas anderes als Verilog/VHDL einzusetzen. Ich kenne Firmen die 
aktiv mit Simulink/HDLcoder Produkte Entwickeln, wo auch der 
vendor-lock-in  besteht.

Ach ja, um es auch in den Topf zu werfen, mit SysML (Ein Standard) und 
z. B. Enterprise Architect soll man auch VHDL Code generieren können. 
Kenne da aber auch niemanden aus der Praxis.

Im Vergleich zu Xilinx versucht es Altera/Intel ja mit einer 
Standardisierten Sprache: OpenCL.

Hat das schon jemand in der Praxis gesehen?

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christophz schrieb:

>
> Mal ein paar Stichworte die mir in den Sinn kommen:
> - Einzelnes Bit lesen/testen/schreiben auf Architektur die das als
> Atomic Opcode besitzt. Fühlt sich nicht an wie high-level programmieren
> sondern wie HDL coden nach "Guck ins Handbuch, damit auch wirklich ein
> RAM rauskommt, wenn du ein RAM willst"

Naja, das hier:
r0 |= BIT1 | BIT2;

kann/soll der Compiler aufdröseln. Wenns atomisch nicht geht, muss halt 
ein  CRITICAL_SECTION-Makro her, aber für die HLS wär's ja irrelevant.

> - Algorithmen so schreiben, dass der Compiler die Flags von Registern
> optimal nutzen kann (C weiss ja nicht was ein Carry ist)

Das ist definitiv ein riesen Aergernis, gerade wenn es Richtung 
Fraktionale Datentypen (anstatt Float) geht, da hätte man gerne die 
Modifier aus diversen Assembler-Konstrukten. Oder muss C++-Konstrukte 
bauen, die das tun.

> - Alles was mit Vektorbefehlen zu tun hat (SSE, Neon etc.)
> - C geht davon aus, dass eine CPU kein Pipelining hat.
> - Und mit Multicore Systemen ist C definitiv überfordert
>

Da könnte man jetzt auch argumentieren, dass der C-Compiler das 
erledigen soll, da hat man in GCC auch eine Menge Unterstützung, was die 
RTL angeht.
Das klappt teil auch ganz gut, dass die Pipeline ohne Stalls (mit 
Hardware-Schleifen) durchgenudelt wird. Bei Hybrid-Architekturen wie 
Blackfin (dessen Instruktions-Set auch von Intel stammt) ist die 
Assembly so gut lesbar bzw. C-ähnlich, dass man die Vektor-ALU besser 
gleich manuell programmiert anstatt trial&error in C, und darauf hoffen, 
dass die Optimierung richtig greift.

Mit GCC hätte man ja ansich die Möglichkeiten, wenn die 
RTL/gimple-Geschichte so flott von der Hand ginge, sich seine HLS selber 
zu bauen und Datentypen und Arithmetiken in Abhängigkeiten von gewissen 
Primitiven zu beschreiben. Wenn...


> Ich war erstaunt, dass Fortran unter anderem immer noch eingesetzt wird,
> weil es sich herausgestellt hat, dass es so high-level ist, das älterer
> Fortran Code auf modernen Maschinen recht gut skaliert und moderne CPU
> Features gut nutzen kann (Ich finde den Artikel dazu gerade nicht mehr).
>

Meinst du nicht, dass das auch eher am Compiler liegt? Die numerischen 
Libs sind bei Fortran halt auch state of the art, zumindest war das vor 
20 Jahren so (öhm..)

>
> Ach ja, um es auch in den Topf zu werfen, mit SysML (Ein Standard) und
> z. B. Enterprise Architect soll man auch VHDL Code generieren können.
> Kenne da aber auch niemanden aus der Praxis.
>

Meine Erfahrungen mit grafischen Programmieransätzen a la Labview oder 
Symbolen sind leider, dass das meist zum write-only-Proramming wird und 
die Systeme schnell nicht mehr wartbar werden. Und auch hier das alte 
Ding mit der Revisionskontrolle.

> Im Vergleich zu Xilinx versucht es Altera/Intel ja mit einer
> Standardisierten Sprache: OpenCL.
>
> Hat das schon jemand in der Praxis gesehen?

Ich kenne das nur von den Vektor-GPUs her, also die generischere 
Weiterentwicklung von nvidias CUDA bzw. Shader-Assembly.
Aber was ich nicht weiss: Wie man da die Kontrolle über die HDL, 
Pipelining und benutzte Resourcen erhält, unabhängig von der 
eigentlichen Rechnung. Bisher wurden da einfach mehrere Instanzen 
angelegt und die Daten verteilt.

Im Prinzip will ich für eine gewisse Architektur sowas wie ein 'Style 
sheet', was auch die Resourcen beschreibt. Da möchte man dann die 
Freiheit haben, Pipelining versus parallelle Abarbeitung anzupassen.
Davon getrennt dann das eigentliche HLS-Modul, was die Verarbeitung des 
besagten Stream beschreibt. Das kann ja dann durchaus im Sinne eines 
Programms zu lesen sein, damit man denselben Code in der HW wie auch auf 
einer allenfalls dedizierten CPU verifizieren kann. Derselbe Code kann 
mit anderem Stylesheet dann auf FPGA Y statt X mit 10 Zyklen anstatt 2 
o.ä. die Rechnung abarbeiten.

Mit der universalen "Klebersprache" Python geht das im Ansatz recht gut, 
es fehlt nur irgendwie an Moment, während an den Hochschulen laufend 
neue HDL-Sprachen mit wechselnder Akzeptanz entstehen. Mit unzähligen 
proprietären Frameworks muss man so oder so leben, bei den Sprachen 
denke ich eher: Muss nicht sein.

Die Frage ist halt immer, ob sich das alles rechnet. Wenn man die 
Frameworks an der Hand hat - so wie Intel - designt man sich mal eben 
eine neue Mikrocode-Architektur und die zugehörigen parallelisierenden 
Asm oder gar VLIW-Befehle. Dasselbe dann im FPGA, anstatt die Pipeline 
hart zu codieren.

Fürs Prototyping kann man allerdings allein schon einen Sinn in HLS 
sehen, um schnell eine funktionierende Referenz zu haben. Wenn man gegen 
die im Klartext (VHDL oder Verilog) vorliegende Simulation vergleichen 
kann, spart man auch schon Zeit, auch wenn man alles nochmal neu 
schreibt oder handoptimiert. Nur: Derjenige der das tut, muss die 
Randbedingungen und die Innereien genau kennen, also wiederum: HDL, 
Synthese und PnR auf die Knochen beherrschen.

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
>> Ich war erstaunt, dass Fortran unter anderem immer noch eingesetzt wird,
>> weil es sich herausgestellt hat, dass es so high-level ist, das älterer
>> Fortran Code auf modernen Maschinen recht gut skaliert und moderne CPU
>> Features gut nutzen kann (Ich finde den Artikel dazu gerade nicht mehr).
>>
>
> Meinst du nicht, dass das auch eher am Compiler liegt? Die numerischen
> Libs sind bei Fortran halt auch state of the art, zumindest war das vor
> 20 Jahren so (öhm..)

Ja, genau um das geht es. Unmodifizierter Fortran Code der die 
Standardlibraries benutzt wird jedes Jahr schneller. Weil die Computer 
schneller werden, Compiler besser werden und die Standardlibraries 
state-of-the-art sind. Für Physiker, Mathematiker, Metreologen etc. 
scheint Fortran tatsächlich immer noch high-level genug zu sein. 
(Korrigiert mich, falls jemand genaueres weiss). Das ist das, was eine 
high-level-sprache an Effizienzgewinn verspricht.

Bei nicht-mehr-genug-high-level Sprachen wie C (Meine Stichworte hast du 
genutzt um gut zu Zeigen, wie Aufwändig es mit C ist diese zu 
beherrschen) darf man alle paar Jahre den Code anfassen um z. B. OpenMP 
pragmas nachzurüsten, array Längen etc. an Cacheline Grössen ausrichten 
oder Libraries mit neuen state-of-the-art Libraries ersetzen (Weil C 
kaum Standartlibraries hat, dies gilt mal wieder nicht für C++).

Strubi schrieb:
> Im Prinzip will ich für eine gewisse Architektur sowas wie ein 'Style
> sheet', was auch die Resourcen beschreibt.

Die Idee gefällt mir. Algorithmusdefinition von 
Implementierungsdefinition trennen.

von Markus F. (mfro)


Bewertung
0 lesenswert
nicht lesenswert
Christophz schrieb:
> Ja, genau um das geht es. Unmodifizierter Fortran Code der die
> Standardlibraries benutzt wird jedes Jahr schneller. Weil die Computer
> schneller werden, Compiler besser werden und die Standardlibraries
> state-of-the-art sind.

Der eigentliche Grund für die (unbezweifelte) Überlegenheit von (vielen) 
Fortran-Programmen bzw. -Libraries in Sachen Performance ist m.E. die 
Limitierung auf Call-By-Reference.

Grob vergleichbar zu einem C-Programm, das alle Variablen in einem 
einzigen, globalen Array hält und nur Indizes hin- und herschiebt (man 
kann also auch in C "Fortran programmieren" - bloß den Code nicht mehr 
lesen).

Das erspart eine Menge Stack-Rumgehopse und erlaubt dem Compiler 
deutlich besser zu optimieren.

Hier: 
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.85.9974&rep=rep1&type=pdf 
habe ich eine hübsche Aussage dazu gefunden:

"Why  Fortran  uses  call-by-reference  may  have  more  to  do  with 
the  history  of  the  implementation  than  aesthetics.   In 
retrospect, language designers might view Fortran’s machine memory model 
as a defect, but this appears to be irrelevant to most Fortran 
programmers."

: Bearbeitet durch User
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christophz schrieb:
> Für Physiker, Mathematiker, Metreologen etc.
> scheint Fortran tatsächlich immer noch high-level genug zu sein.

Die Programmiersprache hat nichts mit dem Hochschulabschluss der Akteure 
zu tun, sondern mit dem jeweiligen Einsatzgebiet. Nicht jede der 
genannten Berufsgruppen beschäftigt sich ausschließlich mit 
rechenintensiven Simulationen, sondern diese stellen nur einen winzigen 
Teil dar.

Für Allerweltsaufgaben verwenden die meisten Mitglieder der genannten 
Berufsgruppen auch die für den jeweiligen Einsatzzweck geeigneten 
Programmiersprachen. Ich (Physiker) habe zuletzt Anfang der 1990 Jahre 
FORTRAN verwendet, d.h. als Hiwi einige Programme von PDP10/TOPS auf 
VAX/VMS übertragen. In den letzten Jahren verwende(te) ich C, C++, 
Python, TCL, SCL, (VHDL), (GNU Make), bash, BAT/CMD, kein FORTRAN.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christophz schrieb:
> state-of-the-art sind. Für Physiker, Mathematiker, Metreologen etc.
> scheint Fortran tatsächlich immer noch high-level genug zu sein.
> (Korrigiert mich, falls jemand genaueres weiss). Das ist das, was eine
> high-level-sprache an Effizienzgewinn verspricht.

Ich habe kurz vor Fortran90 eigentlich das Handtuch geschmissen, u.a. 
wegen der mühseligen Pointerthematik. Da gab's auch Fälle, wo Fortran 
dann deutlich langsamer war als C (wie 2D-FFT).
Hatte auch den Eindruck, dass Fortran nur aufm Grossrechner wirklich 
effizienten Code produziert hat, gfortran/g77 war damals nicht wirklich 
brauchbar.
Aber man sollte auch gnädig sein: Obige Forschergattung möchte zu gutem 
Recht nicht in die Details trickreicher Programmierung einsteigen und 
sehr oft einfach nur brute force rechnen. Die NAG-Lib gibt's offenbar 
immer noch, ob auch für GPU, entzieht sich mir.

Markus F. schrieb:
> Das erspart eine Menge Stack-Rumgehopse und erlaubt dem Compiler
> deutlich besser zu optimieren.

Ich bin mir nicht sicher, ob das heutzutage noch wirklich gilt. 
Zyklenteuer ist eh meist nur die innere (2D-) Schleife. Und diejenigen, 
die ihre Algorithmen optimieren wollen (ohne Library), hacken selbige 
gleich in asm()-Konstrukte.

Um zur HLS zurückzukommen: Ich sehe nicht, was Fortran grundsätzlich 
gegenüber C besser könnte, ausser dass man allenfalls mit der genannten 
CBR-Architektur aus dem Compiler leichter die benötigten Resourcen für 
die Synthese ausspucken kann, da statisch angelegt. Und Fortran77 ist 
schon mal generell (ggü. C) sprachlich so eingeschränkt, dass man 
weniger Gefahr läuft, synthese-inkompatible Konstrukte zu erzeugen.
Stecke aber nicht tief genug drin und kenne die aktuelle Entwicklung 
bzgl. gfortran nicht, alles andere ist für unsereiner auch zu 
hochpreisig.

von Christophz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Strubi schrieb:
> Um zur HLS zurückzukommen: Ich sehe nicht, was Fortran grundsätzlich
> gegenüber C besser könnte, ausser dass man allenfalls mit der genannten
> CBR-Architektur aus dem Compiler leichter die benötigten Resourcen für
> die Synthese ausspucken kann, da statisch angelegt. Und Fortran77 ist
> schon mal generell (ggü. C) sprachlich so eingeschränkt, dass man
> weniger Gefahr läuft, synthese-inkompatible Konstrukte zu erzeugen.

Mein Abschweifen zu Fortran war auch nicht als Vorschlag gedacht es als 
HLS Sprache zu nutzen. Mehr nochmals als Ergänzung, dass eben das 
Sprachparadigma High-Level sein soll um erfolgreich zu sein (was ich 
eben bei C nicht sehe).

Christophz schrieb:
> Strubi schrieb:
>> Im Prinzip will ich für eine gewisse Architektur sowas wie ein 'Style
>> sheet', was auch die Resourcen beschreibt.
>
> Die Idee gefällt mir. Algorithmusdefinition von
> Implementierungsdefinition trennen.

Eine Ergänzung hierzu:
Der Flow von Simulink bringt das einigermassen hin. In Simulink wird die 
Funktion definiert (Zwingend in Integerarithmetik beschrieben, wenn 
Integer im Ziel genutzt werden soll). Implementationsdetails wie 
Zielfrequenz, Anzahl Zyklen pro Resultat etc. werden unabhängig davon in 
diversen GUI Kontextmenues eingestellt (Halt nicht das, was wir hier als 
Style sheet gerne hätten).

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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