High Level Synthese aus C Code Spielerei oder ernste Anwendungen?

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.

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.

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

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.

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.

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:
> 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).