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?
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.
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.
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.
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.
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:
1 | @hls(context) |
2 | def calc(idata, coef, odata): |
3 | r0 = idata[0] |
4 | r1 = idata[7] |
5 | |
6 | r2 = r0 + r1 |
7 | r4 = r2 * coef[0] |
8 | |
9 | r3 = r0 - r1 |
10 | r5 = r3 * coef[1] |
11 | |
12 | odata[4] = r4 |
13 | odata[0] = r5 |
In MyHDL-Ausgabe:
1 | .. |
2 | @always(clk.posedge) |
3 | def s1_proc(): |
4 | r0.next = idata[0] |
5 | r1.next = idata[7] |
6 | |
7 | @always(clk.posedge) |
8 | def s2_proc(): |
9 | r2.next = r0 + r1 |
10 | .. |
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?
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
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.
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.
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
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.
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.
1 | #include "ap_int.h" |
2 | |
3 | ap_uint<12> sld_ntc_interpol (ap_uint<12> i_voltage) { |
4 | |
5 | ap_uint<12> s_rem; |
6 | ap_uint<12> s_idx; |
7 | ap_uint<12> s_slope; |
8 | ap_uint<12+12> s_diff_full; |
9 | ap_uint<12> s_diff; |
10 | ap_uint<12> s_temp; |
11 | ap_uint<12> s_temp_tbl[]= |
12 | {1 * 2, // 0 V |
13 | 1 * 2, // 0.625 |
14 | 1 * 2, // 1.25 |
15 | 1 * 2, // 1.875 |
16 | 1 * 2, // 2.5 |
17 | 20.558 * 2, // 3.125 |
18 | 36.768 * 2, // 3.75 |
19 | 47.108 * 2, // 4.375 |
20 | (328-273) * 2}; // 5 |
21 | |
22 | s_rem = i_voltage % (1<< 9); |
23 | s_idx = i_voltage / (1<< 9); |
24 | s_slope = s_temp_tbl[s_idx+1] - s_temp_tbl[s_idx]; |
25 | s_diff_full = (s_slope * s_rem); |
26 | s_diff = (s_diff_full + (1<< 8)) / (1<< 9); |
27 | s_temp = s_diff + s_temp_tbl[s_idx]; |
28 | return s_temp; |
29 | }
|
Das ist ein NTC-Interpolator, um eine Spannung in eine Temperatur umzurechnen. Also nichts was besonders schnell ist. So sieht die Entity aus:
1 | entity sld_ntc_interpol is |
2 | port ( |
3 | ap_clk : IN STD_LOGIC; |
4 | ap_rst : IN STD_LOGIC; |
5 | ap_start : IN STD_LOGIC; |
6 | ap_done : OUT STD_LOGIC; |
7 | ap_idle : OUT STD_LOGIC; |
8 | i_voltage_V : IN STD_LOGIC_VECTOR (11 downto 0); |
9 | ap_return : OUT STD_LOGIC_VECTOR (11 downto 0) ); |
10 | 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
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.
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).
> 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.
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
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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).
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?
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:
1 | 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.
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.
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
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.
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.
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).
Thread beobachten
Seitenaufteilung abschaltenBitte 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.