Forum: FPGA, VHDL & Co. Beschreibungsformen VHDL


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von T. F. (tf2206)


Lesenswert?

Hallo zusammen,
ich hätte mal eine Frage und zwar weiß zufällig jemand den Unterschied 
zwischen den VHDL-Beschreibungsformen: Datenfluss, Struktur und 
Verhalten.

Unser Prof. hat in der Vorlesung folgende Beispiele gemacht.


Für das Datenflussmodel:

architecture dataflow_view of full_adder is
.........
begin
   S<= X xor Y after 10ns;
   Sum <= S or Cin 10ns;
   Cout <= (X and Y) or (S and Cin) after 20ns;
end dataflow_View;

Für das Strukturmodel:

architecture structure_view of full_adder is
.........
begin
  U1: half_adder port map (X,Y,a,b);
  U2: half_adder portmap (b,Cin,c,Sum);
  U3: or port map (a,c,Cout);
end structure_view;

Für das Verhaltensmodel:

architecture behavirol_view of full_adder is
begin
 process
   variable n: integer;
   constant sv ; bit_vector (0 to 3) := "0101";
   constant cv : bit_vector (0 to 3) := "0011";
 begin
     n:=0;
     if X='1' then n:=n+1; end if;
     if Y'1' then n:=n+1; end if;
     if Cin='1' then n:=n+1; end if;
     Sum <= sv(n) after 10ns;
     Cout <= cv(n) after 30ns;
     wait on X,Y,Cin;
  end process;
end behavirol view;

Kann ich jetzt sagen das ich ein Datenflussmodel hab, sobald ich kein 
process hab. Ein Verhaltensmodel wenn ich ein process hab. Ein 
Srukturmodel wenn ich in der Architecture auf andere Architecture 
"verweis"?

Danke für Eure Hilfe...

MfG TF

von Mathi (Gast)


Lesenswert?

Es ist eigentlich ganz einfach. Beginnen wir mit dem Einfachsten, der 
Strukturbeschreibung. Eine Strukturbeschreibung ist quasi die Umsetzung 
eines Schaltplans bzw. Blockdiagramms in VHDL. Dabei werden nur die 
Komponenten instanziiert und "verdrahtet".
In einer Verhaltensbeschreibung wird - möglichst abstrakt - das 
Verhalten der Schaltung beschrieben.
Eine Datenflussbeschreibung liegt quasi dazwischen und entspricht dem 
Konzept der stimulierten Gleichungen.

In dem Beispiel deines Profs siehst Du sehr schön das die 
Verhaltensbeschreibung die abstrakteste aller drei Beschreibungen ist. 
Das was im Prozess passiert hat mit der Umsetzung des Addiers nicht viel 
zu tun, d.h. Du erkennst keine Gatter. Realisiert ist es mit einer 
Lookup-Table.
In der Datenflussmodellierung dagegen findet man die boolschen 
Gleichungen eines Addierers und in der Strukturbeschreibung werden die 
passenden Gatter für die boolschen Gleichungen instanziiert und 
verdrahtet.

In realen Projekten werden Dir alle drei Beschreibungsformen über den 
Weg laufen. Meistens nicht in Rein- sondern in Mischform.

An welcher Uni bist Du denn?

von T. F. (tf2206)


Lesenswert?

Hi, danke für die schnelle Antwort...

Studiere an der FH Heilbronn (Campus Künzelsau) Elektrotechnik.

Haben in einer Laborarbeit auch Modellierungen gemacht, aber wie du auch 
schon sagtest waren das eigentlich immer Mischformen von den 3 
Beschreibungen...

MfG TF

von berndl (Gast)


Lesenswert?

Hi, ich hab' auch mal an der FH HN Elektronik studiert, mann ist das 
lange her...

T. F. schrieb:
> architecture dataflow_view of full_adder is
> .........
> begin
>    S<= X xor Y after 10ns;
>    Sum <= S or Cin 10ns;
>    Cout <= (X and Y) or (S and Cin) after 20ns;
> end dataflow_View;

Das da oben ist eine korrekte (ausser dass da ein 'after' fehlt) 
Verhaltensbeschreibung, verwendet kein Mensch auf diesem Planeten...

>
> Für das Strukturmodel:
>
> architecture structure_view of full_adder is
> .........
> begin
>   U1: half_adder port map (X,Y,a,b);
>   U2: half_adder portmap (b,Cin,c,Sum);
>   U3: or port map (a,c,Cout);
> end structure_view;

Das da oben ist eine korrekte Implementierung, verwendet kein Mensch auf 
diesem Planeten...

>
> Für das Verhaltensmodel:
>
> architecture behavirol_view of full_adder is
> begin
>  process
>    variable n: integer;
>    constant sv ; bit_vector (0 to 3) := "0101";
>    constant cv : bit_vector (0 to 3) := "0011";
>  begin
>      n:=0;
>      if X='1' then n:=n+1; end if;
>      if Y'1' then n:=n+1; end if;
>      if Cin='1' then n:=n+1; end if;
>      Sum <= sv(n) after 10ns;
>      Cout <= cv(n) after 30ns;
>      wait on X,Y,Cin;
>   end process;
> end behavirol view;

Und das da oben kann sich doch nur ein krankes Hirn ausgedacht haben :o(

Ich mache mit sowas jetzt schon >20 Jahre rum (zuerst Schematic dann ab 
Mitte der 90er HDL), aber bitte schoen, was bringen euch die Profs denn 
heute bei? Das ist Steinzeit! Und wenn ich 'bit_vector' sehe, dann denke 
ich mir immer: Frueher mal so gesehen und nie was dazu gelernt!

PS: Es ist richtig wenn ihr lernt wie ein Addierer funktioniert, das 
sind Grundlagen. Aber sowas in einer HDL so wie oben hinzuschreiben ist 
schon fast Koerperverletzung!

PPS: Kriegen Profs eigentlich noch was von der realen Welt mit?

PPPS: Kopfschuettel...

von Fredo (Gast)


Lesenswert?

berndl schrieb:
> PPS: Kriegen Profs eigentlich noch was von der realen Welt mit?

Das Ganze ist ein Versuch, die verschiedenen parktisch vorhandenen 
Beschreibungsformen zu ordnen, um den Studenten die Köpfe zu öffen und 
zum Denken anzurgen! Ich unterstütze das!

Und die Beispiele sind so schlecht nicht, bis auf die Interpretation des 
Dataflow Aspekt und der timings (denn die sind komplett HW-spezifisch) 
und damit liegt der Herr Prof komlett neben seiner Interpretation und 
muss nochmal nachdenken.

Es fehlen auch noch die Apskete pipeline und Loop-Beschreibung, die mit 
denen man Summen parallel und sequenziell berechnen kann.

Ausserdem würde ich dem Hernn Prof raten, jeweils praxisnaähere 
Beispiele zu bringen, in denen aufgezeigt wird, dass meistens immer 
mehrer Beschreibungsformen gemischt werden (Müssen).

von dito (Gast)


Lesenswert?

Fredo schrieb:
> Ausserdem würde ich dem Hernn Prof raten, jeweils praxisnaähere
> Beispiele zu bringen, in denen aufgezeigt wird, dass meistens immer
> mehrer Beschreibungsformen gemischt werden (Müssen).

Das sollte aber eher die Ausnahme sein. Zumindest Struktur- und 
Verhaltensbeschreibung sollte man nicht in einem Modul mischen.

von Reiner (Gast)


Lesenswert?

Hi

(ich finde die Beispiele des Profs gar nicht so schlecht, wenn auch 
nicht gerade praxisnah)

>Kann ich jetzt sagen das ich ein Datenflussmodel hab, sobald ich kein
>process hab.
Nein (1)

>Ein Verhaltensmodel wenn ich ein process hab.
Nein (1,2)

>Ein Srukturmodel wenn ich in der Architecture auf andere Architecture
>"verweis"?
Ja

===============
(1) In VHDL kann jedes "concurrent statement" (Bsp: X<=Y; ) durch einen 
äquivalenten Prozess abgebildet werden kann (Bsp: process begin X<=Y; 
wait until Y'event; end process;). Daher können auch Datenflussmodelle 
Prozesse enthalten.

(2) process wird z.B. insbesondere dann verwendet, wenn man Flipflops in 
eine synthetisierbare Hardwarebeschreibung darstellen will (z. B. 
process(RESET,CLK)...) . Das ist dann natürlich kein Verhaltensmodell!

Im Gegensatz zu Fredos Behauptung ("und der timings (denn die sind 
komplett HW-spezifisch)" kann man ein Verhaltensmodell sehr wohl Timings 
enthalten. Ein Beispiel ist das Modell eines Mikroprozessors, das 
möglichst genau die Signale an den Ports simuliert, natürlich  - aber 
nicht immer - mit Timings.

Bei Verhaltensmodellen kann man alles was VHDL zur Verfügung stellt 
verwenden (Timings, Prozeduren, wait-Statements, andere Architekturen, 
Prozesse, komplizierte Berechnungen ...). Verhaltensmodelle sind für die 
Simulation von Schaltungen wichtig.

Datenflussmodelle eignen sich meines Erachtens nur für einfache Logik 
(welcher Inputport beeinflusst welchen Outputport). Wie berndl bemerkte, 
sind diese eher theoretischer Natur. Allerdings glaube ich, dass dein 
Prof auch demonstrieren wollte, dass ein und dieselbe Logik unter 
verschiedenen Aspekten auch unterschiedlichen VHDL Code erzeugt.

Dein Prof hat die in der Praxis wichtigen "synthetisierbaren 
Architekturen" unterschlagen (kommt wahrscheinlich noch)

HTH
Reiner

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Nachdem berndl eigentlich schon alles Relevante gesagt hat, muss ich 
doch noch meinen Senf abgeben...

T. F. schrieb:
> Kann ich jetzt sagen das ich ein Datenflussmodel hab, sobald ich kein
> process hab. Ein Verhaltensmodel wenn ich ein process hab. Ein
> Srukturmodel wenn ich in der Architecture auf andere Architecture
> "verweis"?
Die Antworten lauten: Nein, Nein und Nein.

dito schrieb:
> Das sollte aber eher die Ausnahme sein. Zumindest Struktur- und
> Verhaltensbeschreibung sollte man nicht in einem Modul mischen.
Jaja, die reine Lehre wieder mal...
Ich mische diese "verschiedenen Beschreibungsarten" so, dass alles gut 
leserlich aussieht und das Zeug hinterher funktioniert. Warum sollte ich 
nicht einen Clock-Manager per Strukturbeschreibung einbinden und den 
erzeugten Takt in einer Verhaltensbeschreibung verwenden?

Fredo schrieb:
> Und die Beispiele sind so schlecht nicht, bis auf die Interpretation des
> Dataflow Aspekt und der timings (denn die sind komplett HW-spezifisch)
> und damit liegt der Herr Prof komlett neben seiner Interpretation und
> muss nochmal nachdenken.
    Sum <= sv(n) after 10ns;
Sowas hat in einer Verhaltensbeschreibung absolut nichts zu suchen. 
Wenn schon überhaupt eine Timingsimulation, dann mit den richtigen 
Zeiten aus der Synthese. Der Synthesizer(+Mappper+P&R) weiß schliesslich 
viel mehr über das FPGA als ich.
Siehe den Beitrag "Re: Frage zu Pseudozufallsgenerator!?"

> berndl schrieb:
>> PPS: Kriegen Profs eigentlich noch was von der realen Welt mit?
> Das Ganze ist ein Versuch, die verschiedenen parktisch vorhandenen
> Beschreibungsformen zu ordnen, um den Studenten die Köpfe zu öffen und
> zum Denken anzurgen! Ich unterstütze das!
Nur sollte man eben mit Ausrufezeichen dazu sagen, dass diese 
Unterschiede fließend und verwaschen sind...

> Es fehlen auch noch die Apskete pipeline und Loop-Beschreibung, die mit
> denen man Summen parallel und sequenziell berechnen kann.
Wenigstens werden aber schon mal total unnötigerweise Variablen 
verwendet...
Und die haben auch so ihre Tücken:
Beitrag "Variable vs Signal"

von T. F. (tf2206)


Lesenswert?

Hallo zusammen, danke für die Antworten...

@Reiner: Haben auch Synthesierbare Modelle gemacht... Sind inzwischen am 
Semesterende angelangt und gerade in der Prüfungsvorbereitung und da ist 
mir/uns aufgefallen das wir zwar Beispiele haben zu den einzelnen 
Beschreibungsformen aber wir hatten unterschiedliche Ansichten worin sie 
sich jetzt unterscheiden...

MfG TF

von berndl (Gast)


Lesenswert?

Fredo schrieb:
> Das Ganze ist ein Versuch, die verschiedenen parktisch vorhandenen
> Beschreibungsformen zu ordnen, um den Studenten die Köpfe zu öffen und
> zum Denken anzurgen! Ich unterstütze das!

Nein, entschiedener Widerspruch!

Es gibt in HW zwei Sachen die wichtig sind:
* Wie kann ich mit ein paar Transistoren etwas loesen, also z.B. einen 
Full/Half-Adder
* Wie kann ich in einer HDL etwas beschreiben, was ein nachgeschaltetes 
Tool in die primitive HW uebersetzen kann

Und ein Adder ist da ein gutes Beispiel. Aber wenn ich dann sehe, dass 
der (HDL) Stand irgendwo >10 Jahre alt ist, dann kann ich diese Typen 
nicht mehr ernst nehmen, sorry...

Wir brauchen hier in Zukunft Leute, die
a:) Wissen wie die Grundlagen gehen
und
b:) Das ganze auf aktuelle Technologien anwenden koennen.

Und dann gibt es noch:
c:) Genies, die was ganz neues machen

von Reiner (Gast)


Lesenswert?

Hi

>> Das Ganze ist ein Versuch, die verschiedenen praktisch vorhandenen
>> Beschreibungsformen zu ordnen, um den Studenten die Köpfe zu öffen und
>> zum Denken anzurgen! Ich unterstütze das!

>Nein, entschiedener Widerspruch!

>Es gibt in HW zwei Sachen die wichtig sind:
>* Wie kann ich mit ein paar Transistoren etwas loesen, also z.B. einen
Full/Half-Adder
>* Wie kann ich in einer HDL etwas beschreiben, was ein nachgeschaltetes
Tool in die primitive HW uebersetzen kann

ich verstehe nicht, wie man so etwas schreiben kann
1. VHDL wurde ursprünglich für die Simulation/Dokumentation von 
komplexen ASICs, jedoch nicht für die Übersetzung in HW erfunden (Quelle 
en:Wikidpedia). Das ist etwas gänzlich anderes als das was du behauptest
2. Die Übersetzung von VHDL in HW wurde später möglich, durchaus mit 
Erfolg

und VHDL war doch unser Thema, oder?

Reiner

von berndl (Gast)


Lesenswert?

Reiner schrieb:
> ich verstehe nicht, wie man so etwas schreiben kann
> 1. VHDL wurde ursprünglich für die Simulation/Dokumentation von
> komplexen ASICs, jedoch nicht für die Übersetzung in HW erfunden (Quelle
> en:Wikidpedia). Das ist etwas gänzlich anderes als das was du behauptest
> 2. Die Übersetzung von VHDL in HW wurde später möglich, durchaus mit
> Erfolg

zu 1.: Genau richtig. Aber es hat sich recht schnell herausgestellt, 
dass man mit einer HDL (VHDL, Verilog, andere) HW sehr effizient 
beschreiben kann, wenn ein 'paar Tools' die Basics in HW uebersetzen 
koennen

zu 2.: Klar, sieht man ja heute. Aber bis man aus ein paar 'if' oder 
'case' Konstrukten eine sinnvolle HW bauen konnte hat des doch noch eine 
Weile gedauert.

Deshalb auch mein Kommentar: Klar, man muss auch wissen wie man eine 
simples Ding wie einen Volladdierer aus Gattern aufbaut. Aber ab einem 
gewissen Abstaktionslevel spielt das dann keine Rolle mehr. Die Tools 
muessen das dann einfach hinbekommen

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

berndl schrieb:
> Klar, man muss auch wissen wie man eine
> simples Ding wie einen Volladdierer aus Gattern aufbaut. Aber ab einem
> gewissen Abstaktionslevel spielt das dann keine Rolle mehr. Die Tools
> muessen das dann einfach hinbekommen
Richtig, denn um z.B. heute mit einem Auto fahren zu können, muss man 
auch nicht wissen, wie ein Motor im tiefsten Inneren aufgebaut ist, wo 
die Schmierkanäle verlaufen, wie sich eine Zylinderkopfdichtung 
zusammensetzt und mit welchem Drehmoment die Schrauben am Motor 
angezogen gehören. In der Regel reicht es aus, den Schlüssel rumzudrehen 
und loszufahren.

Umnd genauso mache ich es in VHDL: wenn ich einen Addierer will, 
schreibe ich ein '+' hin. Für einen Multiplizierer gibt es ein '*'. Nur 
beim '/' sollte man dann ein wenig von Schaltungstechnik wissen (aber 
wirklich nur wenig...)

von Ralf R. (rrascher)


Lesenswert?

Im Prinzip habt ihr Recht.
Im Studium wird aber VHDL gelernt und nicht
FPAG oder ASIC Entwicklung. Wer sagt denn
das nicht irgend ein Abschlusskandandidat
mal Altera oder Xilinx einen VHDL Compiler
programmiert, dann muss er wirklich die
Grundlagen beherschen.
Also nicht alles nur so einseitig sehen. ;-).

Ralf

ps: Ich habe auch an der FH Heilbronn Elektronik
studiert. Ist jetzt zwanzig Jahre her. Zu meiner
Zeit gabs aber noch keine VHDL Vorlesung.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Ralf R. schrieb:
> Im Studium wird aber VHDL gelernt
Das genau ist aber falsch. Denn ich will ja anschliessend nicht VHDL um 
VHDL Willens machen, sondern um meine Schaltung damit zu realisieren. 
Und da ist die ganze Simuliererei dann für die Katz.

> Wer sagt denn das nicht irgend ein Abschlusskandandidat mal Altera oder
> Xilinx einen VHDL Compiler programmiert, dann muss er wirklich die
> Grundlagen beherschen.
Und für die 10 Leute, die bei X und A im Jahr dafür gebraucht werden, 
sollten 10000 andere auch den kompletten Sprachumfang lernen? Das ist 
ein übler Wirkungsgrad...

> Wer sagt denn das nicht irgend ein Abschlusskandandidat mal Altera oder
> Xilinx einen VHDL Compiler programmiert,
Und die Anderen machen dann "Dual-Edge-Flipflops", "Wait-Glieder", 
"synthetiserbare File-Zugriffe", kombinatorische Schleifen und 
ressourcenfressende "RAMs mit massiv parallelem Zugriff und 8192 
Datenleitungen", weil sie alles lernen mussten und keiner gesagt 
hat, was das eine Promille ihrer Kollegen (die jetzt ja bei X und A 
Synthesizer bauen) tatsächlich in Hardware umzusetzen vermögen....  :-o

> dann muss er wirklich die Grundlagen beherschen.
Aber der "durchschnittliche" VHDL-Anwender braucht eben nicht die 
kompletten VHDL-Grundlagen, sondern hauptsächlich die 10%, die vom 
ganzen ausufernden VHDL Sprachumfang synthetisierbar sind. Und er muss 
das eine vom anderen unterscheiden können...

Was hilft es, wenn ein Design tadellos simulierbar ist, aber in der 
Praxis garantiert versagt? Ich mache so ein Design mit ein paar Zeilen:
http://www.lothar-miller.de/s9y/archives/64-State-Machine-mit-asynchronem-Eingang.html
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren
Und wenn die jetzt unter 1000 anderen Zeilen versteckt sind und keiner 
den Mechanismus kennt, dann gute Nacht...

von Robert K. (Firma: Medizintechnik) (robident)


Lesenswert?

Ralf R. schrieb:
> Im Studium wird aber VHDL gelernt und nicht
>
> FPAG oder ASIC Entwicklung.

und DAS ist der Fehler!

von Ralf R. (rrascher)


Lesenswert?

Lothar Miller schrieb:
> Das genau ist aber falsch. Denn ich will ja anschliessend nicht VHDL um
> VHDL Willens machen, sondern um meine Schaltung damit zu realisieren.
in der Vorlesung wird aber tatsaechlich VHDL gelernt um des VHDL Willens
bzw. um die Sprache kennen zulernen, nicht um eine Schaltung zu 
entwicklen. "Anschliessend" gibt es dann vielleicht dazu Laboruebungen.

> Aber der "durchschnittliche" VHDL-Anwender braucht eben nicht die
> kompletten VHDL-Grundlagen, sondern hauptsächlich die 10%, die vom
> ganzen ausufernden VHDL Sprachumfang synthetisierbar sind.
Man weiss man aber waehrend des Studiums noch nicht was man spaeter mal
genau braucht. Vielleicht braucht man eben jene 10%, die nicht
gelernt wurden...

R. K. (robident) schrieb:
>... und DAS ist der Fehler! ...
Ich sage ja nicht das das richtig ist, so wie es zur Zeit laeuft.
Auch ich bin der Meinung das die Vorlesungen praxisnaher sein
sollten. Es gibt aber so viele verschiedenen Einsatzmoeglichkeiten
als Ingenieur im spaeteren Beruf das man leider nicht alle
Moeglichkeiten beruecksichtigen kann. Wie man mit VHDL richtig umgeht,
dazu braucht man sowieso mehr als nur eine Vorlesung im Studium, dazu
muss man bereit sein auch selbst etwas zu tun. Und am besten lernt
man es in praktischen Versuchen, ob zu Hause, oder in der UNI bzw. FH.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

Ralf R. schrieb:
> Man weiss man aber waehrend des Studiums noch nicht was man spaeter mal
> genau braucht. Vielleicht braucht man eben jene 10%, die nicht gelernt
> wurden...
Dann ist man nie fertig mit dem Studium...

> Man weiss man aber waehrend des Studiums noch nicht was man spaeter mal
> genau braucht. Vielleicht braucht man eben jene 10%, die nicht gelernt
> wurden...
Ich habe während des Studiums bestenfalls 20% dessen gelernt, was ich 
jetzt brauche. Aber ich habe "das Lernen gelernt"...

> Wie man mit VHDL richtig umgeht, dazu braucht man sowieso mehr als nur
> eine Vorlesung im Studium, dazu muss man bereit sein auch selbst etwas
> zu tun. Und am besten lernt man es in praktischen Versuchen.
Das stimmt allerdings. Nichtsdestoweniger gibt es in der Praxis diese 
Unterteilungen nicht:
>>> Für das Datenflussmodel:      (BTW: da fehlt überall nochn l)
>>> Für das Strukturmodel:
>>> Für das Verhaltensmodel:
Bei mir kommen die immer als Mischform vor...

von Jürgen S. (engineer) Benutzerseite


Lesenswert?

Lothar Miller schrieb:
> berndl schrieb:
>> Klar, man muss auch wissen wie man eine
>> simples Ding wie einen Volladdierer aus Gattern aufbaut. Aber ab einem
>> gewissen Abstaktionslevel spielt das dann keine Rolle mehr. Die Tools
>> muessen das dann einfach hinbekommen
> Richtig, denn um z.B. heute mit einem Auto fahren zu können, muss man
> auch nicht wissen, wie ein Motor im tiefsten Inneren aufgebaut ist, wo
> die Schmierkanäle verlaufen, wie sich eine Zylinderkopfdichtung
> zusammensetzt und mit welchem Drehmoment die Schrauben am Motor
> angezogen gehören. In der Regel reicht es aus, den Schlüssel rumzudrehen
> und loszufahren.

Da gehe ich nicht konform!

Wir sind Ingenieure, also durchaus Autobauer und nicht nur Autofahrer! 
Die Frage ist, wieviel man vom GEsamtsystem verstehen soll und muss, 
wenn man an der Komponente frickelt.

Man kann diesbezüglich natürlich der Ansicht sein, dass der 
mathematische Programmierer nur das "+" benötigt, um seine Aufgabe zu 
lösen, aber der Ingenieur, so wie ich ihn verstehe, muss auch verstehen, 
wie die Hardware das letzlich löst. Das ist doch das Problem, dass 
manche Neulinge nur in Prozessen denken und keinen Bezug mehr zu 
Hardware haben. Daher ist es absolut nötig, den Studenten die 
verschiedenen Bescheibungsformen und Möglichkeiten nahezubringen, auch 
wenn die sich nicht so eindeutig von einander abgrenzen lassen und man 
manches vielleicht nicht mehr gebrauchen kann.

Allerdings ist es so, dass man durchaus das HW-nahe Wissen gebrauchen 
kann, wenn man sich nicht nur aus gekapselte VHDL zurückziehen will. 
Tief innen im FPGA reicht vielleicht die Betrachtung der reinen 
Funktionslogik und die ablauftechnische Bescheibung. Wie die FSM, die 
pipeline, die Rechnenstruktur oder der Softcore dann aussieht, ist 
zunächst zweitrangig.

Sobald es aber an die (kosten)technische Optimierung und die Umsetzung 
ins PProdukt geht, braucht es in Teilen bereits Wissen über die 
technischen Randbedingungen des jeweiligen FPGAs und deren Möglichkeiten 
und eine Vorstellung, wie man sie nutzt. Wenn man weiter nach Aussen 
geht, kommt immer mehr Physik und Analogbetrachtung hinzu. Bei einem 
Addierer ist diese natürlich simpel, aber der soll ja auch in 
Vorlesungen nur als leicht verständliches Beispiel dienen. Bei einem 
kompletten DSP-Element sieht es nämlich schon anders aus. Da machen 
Unterschiede in der Beschreibung indirekt Vorgaben für die Realisation 
und die heute in den FPGA verwendeten Strukturen werden immer 
dedizierter! Denken wir mal an PLLs, RAMs, RAM-controller etc. Wenn die 
nicht herstellerspezifisch oder sogar FPGA-spezifisch beschrieben 
werden, wird es schwierig bis unmöglich, ein taugliches Ergebnis zu 
erzielen.

Über die Nutzung von Gates, LUTs als Schalt- und Verzögerungselemente 
wage ich gar nicht nachzudenken.

Selbst bei reiner Mathematik reicht es oft nicht, einfach nur die Formel 
reinzuklopfen und sich vom MATLAB das VDHL backen zu lassen. Komplexe 
Rechenarchitekturen bergen immer Parallelität, Mischformen von 
pipelining und sequeziellem Rechnen und da mischen sich 
Beschreibungsformen für Struktur, Ablauf und Funktion. Um diese zu 
verstehen und passend kombinieren zu können, muss man sie elementar und 
modular vor Augen haben und das geht nur anhand von einfachen, klar 
strukturierten Beispielen.

Daher ist die Herangehensweise, durchaus richtig, das breit aufzufächern 
und auch etwas zu theoretisieren, wo es nicht notwendig erscheint, weil 
man das theoretisieren auch wieder an einfachen Beispielen erlernen 
muss, um es dann mal später auf komplexe Beispiele anwenden zu können.

Die Beispiele der HS Heilbronn sind da allerdings leider etwas 
suboptimal, denn sie behandeln nicht dasselbe funktionelle Beispiel und 
klären auch nicht über die Mischung der Beschreibungsformen in der 
Beschreibung selber auf. Ferner ist die Unterscheidung von nur 3 
Möglichkeiten ebenfalls zu stark einschränkend und nicht gut durchdacht, 
finde ich. Mein formales Modell der Beschreibungstypen und die 
Kombination derselben mit Physik, Logik und Funktion hat etwas mehr 
Dimensionen :-)  Die Darstellung des angeblichen "Datenflusses" ist 
meiner Ansicht sogar vollkommen falsch, weil in einem Datenfluss 
grundsätlzich keinerlei Physik oder Timing auftauchen darf.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

J. S. schrieb:
> Wir sind Ingenieure, also durchaus Autobauer und nicht nur Autofahrer!
> Die Frage ist, wieviel man vom GEsamtsystem verstehen soll und muss,
> wenn man an der Komponente frickelt.
Wieviel versteht ein Softwareprogrammierer von seinem PC?

> Das ist doch das Problem, dass manche Neulinge nur in Prozessen denken
> und keinen Bezug mehr zu Hardware haben.
Das kommt aber daher, dass zuerst und vorrangig "Programmieren" 
gelehrt wird, und danach erst der Aufbau der Hardware und so gut wie 
nicht deren "Beschreibung".

> Sobald es aber an die (kosten)technische Optimierung und die Umsetzung
> ins PProdukt geht, braucht es in Teilen bereits Wissen über die
> technischen Randbedingungen des jeweiligen FPGAs und deren Möglichkeiten
> und eine Vorstellung, wie man sie nutzt.
> Denken wir mal an PLLs, RAMs, RAM-controller etc. Wenn die
> nicht herstellerspezifisch oder sogar FPGA-spezifisch beschrieben
> werden, wird es schwierig bis unmöglich, ein taugliches Ergebnis zu
> erzielen.
Richtig. Nur wir eben genau das auf den Hochschulen nicht gelehrt. 
Sondern man versumpft sich wochenlang in Halbaddierern und Addierern und 
deren extensiver Simulation.
Wenn ich hier einen Praktikanten habe, dann lernt der in 3 Monaten mehr 
als in seinem ganzen Studium. Und das nicht nur, weil er den ganzen Tag 
Zeit hat, sondern weil ich ihm die Stolpersteine des täglichen Lebens 
zeige. Drüber oder dran vorbei findet der dann (mit leichter 
Richtungsangabe) selber...
Nein, er lernt schon deshalb so viel, weil ich ihm die "richtige" und 
"nötige" Literatur (Synthesis Guide und Appnotes) und den RTL-Plan 
seiner Designs zeige...

Ich hatte mal eine Diplomarbeit gegenzulesen, die war nicht ohne. Der 
Diplomand hatte da (vermutlich, weil es das einzige war, was er 
verstanden hatte) die komplette Schaltung mit manuell instatiierten 
herstellerspezifischen Komponenten (bis hin zum Inverter) strukturell 
beschrieben. Das war starker Tobak...  :-o

> Selbst bei reiner Mathematik reicht es oft nicht, einfach nur die Formel
> reinzuklopfen und sich vom MATLAB das VDHL backen zu lassen.
Das wird aber gern von den entsprechenden Toolherstellern so verkauft 
und taucht dann regelmässig hier auf, weil das ganze Design dann an 
einer Nichtigkeit wie einem nicht synchronisierten Reset scheitert...

> Die Darstellung des angeblichen "Datenflusses" ist
> meiner Ansicht sogar vollkommen falsch, weil in einem Datenfluss
> grundsätlzich keinerlei Physik oder Timing auftauchen darf.
Richtig, das hat mich auch sehr gestört.

von Robert K. (Firma: Medizintechnik) (robident)


Lesenswert?

Lothar Miller schrieb:
> Wieviel versteht ein Softwareprogrammierer von seinem PC?

Die Frage ist doch, wie weit das Wissen eines Ingenieurs geht oder gehen 
soll. Ein Softwareentwickler, der nur mit Klassen arbeitet, braucht das 
Wissen um den PC nicht. Der, der jedoch Treiber schreiben und BIOS 
herstellen soll, sehr wohl.

Aus meiner Sicht ist ein Ingenieur mehr, als jemand, der nur VHDL kann 
und in Software denkt, weil er die PLD-Hardware immer auch in einen 
Kontext der Elektronik setzen muss.

Mit reinem VHDL kann man auch nicht allzuviel anfangen. Das kann sich 
jeder aneignen und wenn ich mich umsehe, ist das auch der Fall.

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Lesenswert?

R. K. schrieb:
> Aus meiner Sicht ist ein Ingenieur mehr, als jemand, der nur VHDL kann
> und in Software denkt
Da war dann noch der Trend aus dem Anfang dieses Jahrtausends, wo mit 
SystemC die nach dem Platzen der Internetblase frei gewordenen 
Programmierer günstig in die Hardwareecke übernommen werden sollten...

von Michael (Gast)


Lesenswert?

Lothar Miller schrieb:
> wo mit
>
> SystemC die nach dem Platzen der Internetblase frei gewordenen
>
> Programmierer günstig in die Hardwareecke übernommen werden sollten

was ja auch vortrefflich geklappt hat

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]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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