mikrocontroller.net

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

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?

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

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.

Autor: Klakx (Gast)
Datum:

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.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

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.

Autor: Bernd K. (prof7bit)
Datum:

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.

Autor: Martin S. (strubi)
Datum:

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?

Autor: daniel__m (Gast)
Datum:

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

Autor: FPGA zum Spass (Gast)
Datum:

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.

Autor: Klakx (Gast)
Datum:

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.

Autor: daniel__m (Gast)
Datum:

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

Autor: Vancouver (Gast)
Datum:

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.

Autor: Thomas R. (Firma: abaxor engineering) (abaxor)
Datum:

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

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

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.

Autor: Martin S. (strubi)
Datum:

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

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

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.

Autor: daniel__m (Gast)
Datum:

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

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

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.

Autor: S. R. (svenska)
Datum:

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.

Autor: Kinderkacke Entsorger (Gast)
Datum:

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.

Autor: S. R. (svenska)
Datum:

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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

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.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

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.

Autor: S. R. (svenska)
Datum:

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.

Autor: Gatterloge (Gast)
Datum:

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

Autor: Bastian (Gast)
Datum:

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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

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