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
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?
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
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...
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).
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.
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
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"
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
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
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
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
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...)
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.
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...
Ralf R. schrieb: > Im Studium wird aber VHDL gelernt und nicht > > FPAG oder ASIC Entwicklung. und DAS ist der Fehler!
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.
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...
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.
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.
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.
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...
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
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.