Liebe FPGA-Programmierer, nach einigen Projekten mit dem bekannten Mikrocontrollern der ATMEGA-Familie von Atmel möchte ich mich nun an ein Projekt wagen, bei dem ich Analogwerte mit einer Abtastrate von ca. 50 MSPS verarbeiten möchte. Hierfür kann ich leider keinen der ATMEGA-Controller nutzen, weshalb ich nun einen FPGA nutzen möchte. Da ich auf diesem Gebiet noch keine Erfahrungen habe, hab ich mir das Xilinx Spartan 3A Starter-Kit besorgt und die Software ISE 13.4 installiert. Nun möchte ich das Programmieren von FPGA's lernen und habe schon ein Tutorial gefunden, bei dem eine LED auf dem Board zum blinken gebracht wurde. Zukünftig möchte ich den FPGA jedoch grafisch programmieren, was mit ISE 13.4 möglich sein sollte. Leider habe ich dazu noch kein Tutorial und keinen Foreneintrag gefunden. Weiß daher jemand wo ein solches Tutorial zu finden ist? Oder gibt es weitere Vorschläge zum Erlernen der FPGA-Programmierung (möglichst grafisch)? Vielen Dank im vorraus und ein fettes Lob schonmal an die fleißigen User im Forum, da sie mir schon mit Ihren Antworten auf Fragen andere User oft weitergeholfen haben! Beste Grüße, Falk
Inwiefern sollte diesbezüglich mit 14.3 etwas möglich sein, was vorher noch nicht ging? Symbol Based Design ging schon lange früher. Oder hat das Vivado-Zeug was Neues? Mein Tipp: All die Schaltungen, die Du in den ersten 3 Jahren des Lernens Dir auszudenken in der Lage sein wirst, werden sich in keiner Grössenordnung bewegen, die einer aufwändigen Verhaltung von Modulen bedürfte, bei welcher die grafische Eingabe vorteilhaft(er) sein sollte, als testbasiertes Arbeiten. Und nach meiner Erfahrung kommt da sehr schnell auch der Punkt, wo die Komplexität der Designs so immens wird, dass man im Team arbeiten kann/muss, dass man aufwändige Pflege und automatisierte Änderungsverfolgung braucht, komplizierte generics und parsing benutzt, die grafisch nicht unterstützt werden.
Hallo! Ich würde dir dringend davon abraten, dich auf eine grafische "Programmierung" (FPGAs werden nicht programmiert) zu stürzen. Dein Design wird dadurch sehr schnell sehr groß und unübersichtlich. Eine grafische Darstellung bietet sich ggf. dann an, wenn man einzelne "Funktionsblöche" miteinander verschaltet. Also das Top-Level des Designs baut. Aber um die eigentliche Funktionalität zu beschreiben, ist die textbasierte Methode auf jeden Fall deutlich übersichtlicher.
Falk R schrieb: > Zukünftig möchte ich den FPGA jedoch grafisch programmieren, Was heißt für dich "grafisch"? Schaltplaneingabe? Oder FSM über Zustandsdiagramme? Und was meinst du mit programmieren? > nach einigen Projekten mit dem bekannten Mikrocontrollern der > ATMEGA-Familie von Atmel Wie hast du den programmiert? > möchte ich mich nun an ein Projekt wagen, bei dem ich Analogwerte mit > einer Abtastrate von ca. 50 MSPS verarbeiten möchte. Du möchtest etwas, das komplizierter ist, als dass ein AVR es könnte, mit einfacheren Mitteln machen? Mein Tipp: lern VHDL (oder Verilog). Denn das ganze grafische Gebastel tut nichts anderes (oder versucht es wenigstens), als solche Beschreibungssprachen-Bibliotheken vor dir zu verstecken. "Unten" werkelt trotzdem Verilog (oder VHDL). Und früher oder später wirst du auf dieser Ebene unsanft aufschlagen...
Lothar Miller schrieb: > Und früher > > oder später wirst du auf dieser Ebene unsanft aufschlagen... ... eher früher als später ;-)
Hallo nochmal, mein erstes "Programm" war das Tutorial von Lothar Miller (schön dass du auch hier aktiv bist). Ich bin prinzipiell gern bereit VHDL zu lernen, da ich Mikrocontroller erst in Assembler und dann in C programmiert habe und somit mit der testbasierten Methode schon etwas vertraut bin. Mir geht es darum, dass das "Programm" später evtl durch eine andere Person gepflegt werden sollte und diese sich dann schneller einfindet. Laut euren Aussagen sollte dies aber nicht der Fall sein!? Mit grafisch meinte ich das Symbol based Design. Ich bin begeistert von eurer schnellen Reaktion! Besten Dank, Falk
Eine grafische Darstellung der Vernetzung einzelner Funktionseinheiten kann durchaus der Übersichtlichkeit dienen. Der "Inhalt" der Funktionseinheiten, also Register und Kombinatorik ist auf jeden Fall übersichtlicher, wenn es mit einer "sauberen" Codiermethode in z.B. VHDL beschrieben wird. Was eine "saubere" Codiermethode ist, ist sicher ein Stück weit Geschmackssache. Ich z.B. arbeite prinzipiell mit der 2 Prozess Methode. Du wirst nicht drumrumkommen, VHLD oder Verilog zu lernen. Daher würde ich auch jetzt am Anfang gar keine Zeit damit "verschwenden", dich mit der grafischen Darstellung vertraut zu machen, da du sowieso sehr schnell an deren Grenzen stoßen wirst. "Zerlege" dein Problem in sinnvolle Funktionseiheiten, beschreibe diese in VHDL und vernetze diese dann in einem Top-Level miteinander. Diese Vernetzung kannst du entweder auch in VHDL vornehmen oder auch grafisch
Falk R schrieb: > Mir geht es darum, dass das "Programm" Es ist eine "Beschreibung", genauer eine "Hardwarebeschreibung"... > später evtl durch eine andere > Person gepflegt werden sollte und diese sich dann schneller einfindet. VHDL ist genauso eine Sprache, die sich durch ihre Geschwätzigkeit fast schon selber dokumentiert. Es gibt weitestgehend keine impliziten Annahmen, jeder Typ muss deklariert und bekannt gemacht werden. Natürlich kann man durch eine unglückliche Beschreibungsweise dieses Konzept aushebeln, aber 50MHz sind schon nicht mehr "langsam" und evtl. bist du trotz grafischer Programmierung schneller wieder auf der VHDL-Ebene und im FPGA, als dir lieb ist... > Laut euren Aussagen sollte dies aber nicht der Fall sein!? Was denn? Ich beschreibe meine Hardware komplett in VHDL. Und das so, dass ich selber es nach 1 Jahr noch verstehe. Und wenn ich das kann, dann können das auch andere. > Mit grafisch meinte ich das Symbol based Design. Beitrag "Labview FPGA brauchbar?" Und dann noch das da: http://robei.com/
Schlumpf schrieb: > Eine grafische Darstellung der Vernetzung einzelner Funktionseinheiten > > kann durchaus der Übersichtlichkeit dienen. absolut, aber dafür haben die tools ja symbolbasierte Eingabe und kaum einer nutzt es. das problem ist einfach die versionierung sollte da mal was kommen, sattle ich sofrt auf, aber ich habe den Groschen schon 2006 bei Xilinx eingeworfen, dass man sowas braucht und die tun nix
Schlumpf schrieb: > Der "Inhalt" der Funktionseinheiten, also Register und Kombinatorik ist > auf jeden Fall übersichtlicher, wenn es mit einer "sauberen" > Codiermethode in z.B. VHDL beschrieben wird. Das sehe ich ebenso. Aus der Graifk geh tnicht hervor, was wohin codiert wird.
Schlumpf schrieb: > Eine grafische Darstellung der Vernetzung einzelner Funktionseinheiten > kann durchaus der Übersichtlichkeit dienen. Das sehe ich ebenso, würde bei mir aber nicht unter "programmieren" laufen, sondern mehr unter "organisieren", denn mehr, als das Verwalten von entities ist das ja nicht, Und es stellt sich die Frage, ob man die Darstellung der entity unbedingt mit der Eingabe der Codes hart verknüpfen muss. Früher hätte ich gesagt ja, heute tendiere ich eher zum nein.
Hallo, sind mit grafisch programmieren Tools wie System Generator und DSP Builder gemeint? Ich selber setze diese Tools ein und habe sehr Produktivitätsfortschritte gesehen. Besonders bei Test und Fehleranalyse liefert Matlab wertvolle Hilfe. Gruß Markus
Schlumpf schrieb: > Eine grafische Darstellung der Vernetzung einzelner Funktionseinheiten > kann durchaus der Übersichtlichkeit dienen. Kann mir mal einer Erklären wie das im Xilinx Webpack geht? Ich habe das mal bei Quartus gesehn. Dort konnte man dann einfach seinen VHDL Code schreiben und dann aus der entity ein "Gehäuse" für den Schaltplan erstellen lassen. Ich finde es sehr übersichtlich das so zu machen.... Nach 400 port map wird mir immer ganz schwindelig .................... Zum Thema ich schreibe meinen Code auch lieber von "Hand". Aber ich denke (auch wenn ich dagegen bin ;-D) wird es immer mehr Richtung graphischer Tools gehn. LabView ist zum kotzen, aber man hat in einem Nachmittag eine Prüfstandsteuerung zusammengekloppt... wenns nicht funktioniert, hat man aber auch ein Problem, was man oft nicht lösen kann ;-D
Fragender schrieb: > Dort konnte man dann einfach seinen VHDL Code > > schreiben und dann aus der entity ein "Gehäuse" für den Schaltplan > > erstellen lassen. Fokus auf das VHDL-file und dann "generate symbol". An dann ist es in der lokalen bib bekannt und kann verwendet werden.
Also mit Matlab Simulink kann man super "graphisch programmieren". Also zumindest die Xilinx FPGAs, bei Altera weiß ich das nicht. Damit lassen dich die ganzen DSP Sachen wie Filter, Regler etc. gut basteln. Für Andere sachen wie FSM oder so finde ich es eher ungeeignet, machbar ist es aber.
Schlumpf schrieb: > ... eher früher als später ;-) Unsanft aufschlagen? Nee, mein Lieber. Ich halte es nach wie vor für die beste Methode, mit Schematics bei Xilinx anzufangen und zumindest die alleroberste Ebene als Schaltbild auszuführen und das ucf File von Hand zu schreiben. Da ist dann erstmal geklärt, was es wo an welchen Pins geben soll und die wichtigsten Signale und die obersten Funktionsblöcke sind im Projekt schonmal richtig vorhanden. Diese Funktionsblöcke dann mit Inhalt zu füllen ist dann Geschmackssache, da kann man dann vdl ode verilog oder wiederum Schematics benutzen, aber die ISE macht einem das Leben leicht, weil sie schon mal den Funktionsrumpf selber generiert. Gerade bei vhdl kriegt man als Normalmensch nämlich sehr leicht graue Haare. Ich selber hatte vor einiger Zeit das Mißvergnügen, was sich wirklich jedesmal!! in nem Zwist zwischen Zahlen und Standardvektoren zuspitzte. Hab dann den ganzen Mist mit nem Dreizeiler in verilog erledigt. Aber verilog ist auch nicht jedermanns Sache. W.S.
W.S. schrieb: > in nem Zwist zwischen Zahlen und Standardvektoren > > zuspitzte. Wo ist da ein Zwist? Du kannst es Dir doch aussuchen und im schlimmsten Fall das, was andere Dir liefern wrappen. Be mir sind Zahlen in Form von Datenströmen immer Integer, Parameter sind Vektoren.
Hmm, zum Thema grafische Programmierung kann ich eigentlich LabView FPGA empfehlen, das kann man bei National Instruments ne Zeit lang evaluieren und funktioniert mit dem Digilent Spartan-3e-Starterkit ganz hervorragend, auch der Zugriff auf ADC/DAC, Display usw ist möglich. Im Hintergrund werkelt da eine Spezial-ISE von Xilinx für NI. Siehe auch: http://www.youtube.com/watch?v=-ulWxOyOfgM Anleitung: http://www-micrel.deis.unibo.it/LABARCH/slidecorso2012/getting_started_spartan.pdf
Angehängte Dateien:
Falk (DB8FS) schrieb: > zum Thema grafische Programmierung kann ich eigentlich LabView FPGA > empfehlen Ich nicht. Die Idee mag zwar verlockend sein, aber wenn ich in die Beispiel-VIs öffne, schaue ich wie die Sau ins Uhrwerk :-( Außerdem ist nie komplett ersichtlich, was der "Code" macht. Man muß sich erst durch diverse if- und case-Konstrukte durchklicken. Wenn man eine fixe Idee im Kopf hat, dann läßt sie sich sicher schnell umsetzen, aber wartbarer Code sieht m.E. anders aus. Duke P.S.: Und solange Labview FPGA mit NI-Hardware gedongelt ist, bleibt es hoffentlich eine Nischenanwendung. (Nach Aussage von NI ist die Unterstützung für das Digilent Spartan3E-Board eine Ausnahme.)
Ich sehe nach wie vor keinen Vorteil darin, einen Komparator als Block in eine Schaltung reinzumalen, dann zwei Striche hinzupinsen, um das Datum und den Wert einzutragen. In VHDL schreibe ich: IF DATUM = SOLLWERT THEN ... fertig. Einfacher geht es nicht und das ist abstrakter, näher an der menschlichen Sprache und näher an dem was in einem Pflichtenheft an REQs steht. Zudem ist es von jedem Prüfer und Planer auch zu verstehen. Das Hinmalen logischer Elemente macht bei FPGAs schon deshalb keinen Sinn, weil die Funktion, die man haben will, nicht notwenigerweise auch explizit aufgebaut werden muss, sondern indirekt im design verschwinden kann und selbst wenn, dann nicht so aussieht, wie beschrieben. Was man grafisch beschreiben kann und sollte, sind Strukturen. Das sind die Modulstruktur und die Resourcen wie PLLs, buffer etc, was also real rein muss. Die Logikfunktion ist etwas Abstraktes und muss nicht durch scheinreale Pseudoelektronikbausteine abgebildet werden, so, als würde man es so noch auflöten. Wozu? Wenn man sich mal ein mittelgrosses Design ansieht, führt das letztlich nur zu einem gewaltigen Drahtverhau wo man mit der Lupe die Drähte verfolgen muss, um zu sehen, wohin sie laufen. Da steckt keine Info drin. Besser ist es daher, man arbeitet wie bei Schaltplänen auch mit stubs, an denen die Signale stehen. Da ist aber dann auch kein wesentlicher Unterschied mehr zum Ausruck einer Komponenten und einer MAP. Für eine Doku ist es auch nicht nötig, jedes PipiSignal hinzumalen, daher ist es IMO besser, man macht das parallel per Softtool, Excel oder Visio.
Duke Scarring schrieb: > Ich nicht. Die Idee mag zwar verlockend sein, aber wenn ich in die > > Beispiel-VIs öffne, schaue ich wie die Sau ins Uhrwerk :-( Das geht mir allerdings auch so: Ich wäre spontan nicht in der Lage, die Funktionalität aus dem Design zu entnehmen. Das ist zwar beim Text auch so und damit müsste man in beiden Fällen eine Doku haben - wenn man aber verstanden hat, was Fakt ist, kann ich beim VHDL sofort loslegen und was dazu schreiben. Beim Labview wüsste ich nicht, wo ich die Symbole herbekomme, wie ich sie verdrahte und was ich alles unternehmen muss um eine Simulation zu machen, eine Synthese und vor allem: Was zu tun ist, wenn da irgendwas absäuft, nicht läuft oder sonst was passiert. Jedes zusätzliche Programm in der tool chain schafft neue Probleme.
Labview ist der grösste Hemmschuh einer geordneten Entwicklung! Das grafische Gepinsel ist zwar für viele Ingenieure schön und angenehm, führt aber zu nichts anderem, als heillosem Hacken und Basteln. Egal, wo ich Labview im Einsatz gesehen habe, überall führt es zu schnell zusammengestrickten Lösungen, die aber alle an der Bandbreite, der Pflegbarkeit und dem mangelnden langfristigen Nutzen kranken. Ich habe seit Mitte der 90er regelmässig mit Labview gearbeitet, es aber aus gutem Grund immer nur für das Nötigste eingesetzt und es auch ersetzt, soweit ich das durfte. Leider gibt es immer wieder Schlauberger, die keine sind, die sich aber von der NI-Werbung blenden und täuschen lassen und das Gebastel einführen. Das Ende vom Lied ist, dass diejenigen, die ohnehin schon das Murksen verinnerlicht hatten, auf diesen Zug aufpringen und nun noch mehr murksen. Zu allem Übel überträgt sich das auch noch auf die eigentliche Entwicklung und bleibt nicht bei dem Labortestmittelbau, für den Labview ja konstruiert wurde (und auch bedingt tauglich ist, wie ich gerne zugebe): Die Methodik, sich ohne zu planen, zu überlegen und über Anforderungen zu arbeiten eigenen sich viele gerne an und sie überträgt sich ohne eigenes Zutun auf den Arbeitsstil und dies gleich auf die gesamte Abteilung - dabei wird heute eigentlich überwiegend über REQs gearbeitet und selbst das Labortestgedöhns über Prüfpläne abgewickelt. Das abstrahierende Denken geht den Labviewern dann zusehens verloren. So meine Erfahrung. Schön ist Labview daher vor allem für diejenigen, die nicht geordnet arbeiten gelernt haben und weiter frickeln wollen sowie für die, die die Labviewkenntnisse und Bedienung als Alleinstellungsmerkmal in der Abteilung nutzen können und wollen, sodass sie die einzigen sind, die in dem Labviewdjungelmist noch durchblicken, um ihre Position zu festigen. Wie man sieht, führe ich hier alleine projektsichtrelevante Aspekte an - die Argumenteliste gegen Labview aufgrund technischer Punkte wäre noch länger. Versionierung? Teamwork? Versionskontrolle? Archivierung? Das sind ungelöste Themen bei NI und das ist gewollt. Die Gestlegung auf das Frickelvorgehen ist nämlich noch viel stärker produktbindend, als die Tatsache, dass man nur mit teuer NI HWardware effektiv mit LV arbeiten kann.
Labviewhasser schrieb: > Schön ist Labview daher vor allem für diejenigen, die nicht geordnet > > arbeiten gelernt haben und weiter frickeln wollen Vermutung oder Ergebnis von Untersuchung?
Moin, > Labview ist der grösste Hemmschuh einer geordneten Entwicklung! Das > grafische Gepinsel ist zwar für viele Ingenieure schön und angenehm, > führt aber zu nichts anderem, als heillosem Hacken und Basteln. Egal, wo > ich Labview im Einsatz gesehen habe, überall führt es zu schnell > zusammengestrickten Lösungen, die aber alle an der Bandbreite, der > Pflegbarkeit und dem mangelnden langfristigen Nutzen kranken. > Ein langer Sermon, aber der Rabbi hat 100% wahr gesprochen :-) Mich erstaunt es auch immer wieder, wie NI es schafft, Projektleitern oder gar dem Management ihren Kram anzudrehen, und ihre Geräte noch derart zu verstümmeln, dass sie fast nur noch mit Labview 'auf die Schnelle' zu programmieren sind. > > Wie man sieht, führe ich hier alleine projektsichtrelevante Aspekte an - > die Argumenteliste gegen Labview aufgrund technischer Punkte wäre noch > länger. Ich habe mich länger mal mit grafischen Programmieren beschäftigt, u.A. auch an einer ganz anderen Baustelle (3D-Simulations-Engine). Fazit: Nie und nimmer ist grafisches Programmieren in irgend einer Weise für ein Produkt wirtschaftlich. Sobald es ans Debuggen, bzw. das Entwickeln eines vernünftigen Debuggers geht, versteht man, warum. Schnelles Prototyping, ok. Aber das geht auch besser mit einer cleveren Scripting-Engine und wiederverwertbaren (!) Utilities. Vom technischen Standpunkt her: Es ist unfassbar, wieviel und wieviel miesen Code Labview für div. Hardware (DSP-Units) generiert. Die anfangs vermutete Wirtschaftlichkeit ("mit klickibunti sind wir doch viel schneller!") wurde eher zum Desaster, am Schluss durfte einer alles nochmal in C schreiben. Es gibt wirklich nur einige wenige gute Ansätze, dazu gehört auch das vor ca. 20 Jahren aktuelle Smalltalk mit einer IMHO recht cleveren Oberfläche, die schnelle Kapselung von Komponenten erlaubt. > > Versionierung? > Teamwork? > Versionskontrolle? > Archivierung? Ganz wichtig für auf lange Zeit angelegte HW-Designs: Wiederverwertbarkeit... (Was denn der Lavbiew-Spezi geht und ein anderer das Design reverse-engieeren/neuschreiben muss?) Oder sich gar die SW-Version ändert? Im Physik-Labor hab ich diesbezüglich schon ne Menge Leichen gesehen.. > > Das sind ungelöste Themen bei NI und das ist gewollt. Die Gestlegung auf > das Frickelvorgehen ist nämlich noch viel stärker produktbindend, als > die Tatsache, dass man nur mit teuer NI HWardware effektiv mit LV > arbeiten kann. Die Frickelei mag ja in einer gewissen Hassliebe enden, da sie meistens am Ende eines solchen Frickelprojekts den Fehlerfüchsen, die mit dem Aufspüren von Bugs Geld verdienen, Arbeit beschert. Andererseits ist das echt verflucht nervig, wenn man dem Projektleiter der Firma kaum erzählen kann, dass sie das ganze Pferd verkehrt aufgezäumt haben, während man bei dem eh schon ausgereizten Budget als Sanierer meist unter Druck steht. Also tut doch den Reverse-Engieering-Spezis den Gefallen und lasst bloss die Finger von dem Frickelkram in Endprodukten. Erstere werden's euch danken.
Plattform (nicht flach) unabhängig, grafisch, und auch für mich ohne VHDL/Verilog Kentnisse (die ich trotzdem gerne hätte, aber keine Zeit) supi zu nutzen/bedienen : http://wiki.altium.com/display/ADOH/Tutorial+-+Getting+Started+with+the+Innovation+Station OpenBus ist was für noobs, die auch gerne mal auf fertige Sachen zurückgreifen. Aber funzt. Und wer tiefer einsteigt, erstellt eigene grafische Icons ... Gruß, dasrotemopped.
ist aber auch wieder eine sonderlocke, bei denen alle sourcen veralten, wenn die Software stirbt "FPGA grafisch programmieren" ist wohl deshalb so beliebt, weil viele Anfänger glauben, dass sie damit schnell was hinbekommen, was auch bedingt stimmt. Da sie sich das dann angewöhnen, bleiben sie dabei.
Ich hab auch mit grafischer FPGA Programmierung angefangen weil's von der Hardware her kommend praktisch, intuitiv und gut selbstdokumentierend erscheint. Das ist es fuer mich auch heute noch, nach ueber 10 Jahren. Wenn die Ansprueche an Komplexitaet nicht allzu hoch sind, passt das immer noch. Ein paar synchrone Zaehler, etwas Logik, passt, bevor man dann wegen der Geschwindigkeit auf ECL gehen muss. Wenn es dann ECL, resp SiGe FPGA gibt, reden wir wieder ueber HDL.
Schlumpf schrieb: > Ich würde dir dringend davon abraten, dich auf eine grafische > "Programmierung" (FPGAs werden nicht programmiert) Sagt wer? Im Wikipedia und hier wird ausdrücklich dargestellt, dass "programmieren" nicht an Mikroprozessoren und Softwareerstellung im klassischen Sinn gebunden ist.
Ja bitte, gibt es im ISE Webpack eine Möglichkeit, Sub-Entities visuell zu verdrahten, inklusive automatischer generierung von lokalen Verbindungssignalen? Ich habe vorhin bestimmt eine halbe Stunde gebraucht, bis ich das mit den Namen usw. bei meinen 5 Blöcken alles richtig hingebastelt habe. Irgendwann ist man nur noch am Hoch- und Runterscrollen, weil Signale nunmal im Kopf definiert werden müssen => die Lokalität geht im Quelltext total flöten, ich war hinterher förmlich kirre im Kopf. Visuell könnte man die Lokalität aber nachträglich super über das VHDL drüberpflanschen.
Michael S. schrieb: > Irgendwann ist man nur noch am Hoch- und > Runterscrollen, weil Signale nunmal im Kopf definiert werden müssen => > die Lokalität geht im Quelltext total flöten, Dafür nehm ich einen Editor mit Window-Split. Außerdem gibt es noch das block-Statement in VHDL. Duke
Hallo, läuft dieses ISE 13.4 auch auf WIN7 Home oder nur mit WIN7 Prof-Version. Ist dieses ISE 13.4 bei dir eine freie Version ? Danke. Gruss
Peter Bierbach schrieb: > Hallo, läuft dieses ISE 13.4 auch auf WIN7 Home oder nur mit WIN7 > Prof-Version. Ist dieses ISE 13.4 bei dir eine freie Version ? Offiziell wird nur professional unterstützt, siehe hier: http://www.xilinx.com/ise/ossupport/index.htm Aber ich sehe keinen Grund, warum es mit der Home-Edition nicht laufen sollte. Privat wird wohl kaum jemand die $3k-$4k ausgeben um ein paar FPGAs zu bespaßen. Duke
Wundert mich schon manchmal dass die üblichen Werkzeuge zwar Schaltplan kennen aber idR nicht die offensichtliche Methode anbieten: Alle Pins und alle Zellen in dem Ding auf den Schirm und dann gib ihm Ratsnest, am besten so dass die Änderungen sofort in den laufenden Versuchsaufbau geschickt werden ;) VHDL und co in allen Ehren aber manchmal will und muss man hacken ;)
Die Designmethodik geht eben weg von der konkreten Programmierung und Verdrahtung wobei Du ja durchaus die Option hast, mit dem FPGA Editor was zu basteln. Es gibt sogar Fälle, wo das sinnvoll ist. Ich mache zum Beispiel einen Algorithmus, der AD-Wandlerdaten verrechnet, wozu soll ich dann verdrahten? Der soll rechnen, Linearisieren und sowas. Mathematik muss man nicht grafisch eingeben.
M. F. schrieb: > Mathematik muss man nicht grafisch eingeben. Eben und genau dafür gibt es MATLAB! Warum soll ich ein und dieselbe Geschichte wieder und wieder in VHDL schreiben? Klick, Symbol, verdrahten, fertig ist die Laube.
optiker schrieb: > weil viele Anfänger glauben, dass sie... Du sitzt auf nem recht hohen Roß, mein Lieber. Es gibt ne Menge Leute, die auch noch was Anderes zu tun haben, als immerzu nur CPLD's und FPGA's zu programmieren. Da stört es gewaltigst, wenn man zu diesem Zweck auch noch 1..2 neue Programmiersprachen (konkret: VHDL und Verilog) lernen muß. Wer ohnehin Schaltungen entwerfen und Leiterplatten trassieren muß, dem fällt es hingegen leicht, seine Logik mit Schematics zu machen - eben wenigstens die allerobersten Ebenen. Kleineren Kram weiter unten in der Hierarchie kann man dann ja per Verilog machen, weil kleiner und damit überschaubarer. Kurzum, dein Ansinnen, es seien ja nur Anfänger und unter diesen insbesondere fehlgeleitete Anfänger, ist völlig daneben. Ich kenne diesen Dünkel aus allen Sparten: Die Mechaniker mosern, weil man als Entwickler 8h7 nicht von 8H7 unterscheiden kann ohne ins Buch zu schauen, die Layouter mosern, weil ihnen Eagle als zu poplig erscheint, die C-Programmierer mosern, wenn sie mal was in Assembler schreiben sollen, die VHDL-Schreiber mosern, weil ihnen Schematics mißfällt, ud so weiter und so fort. Wenn all diese Knaller mal all das zusammen machen sollten, was ich hier nur auszugsweise erwähnt habe, also die VHDL-Leute sich um die Dreh- Fräs- und Gehäuseteile kümmern, die Layouter den 5 beinigen PIC in Assembler programmieren, die C-Programmierer mal die Kunden betreuen, und alle zusammen die Kalkulation (REFA..) erledigen sollten, dann wüßten diese Knaller, daß es neben ihrer tollen Welt noch ne Menge anderen Zeuges gibt, was ebenfalls Platz in der Rübe benötigt. Und die Ausrede "schaff dir doch nen Sack Spezialisten an" gilt nicht, wenn das Marktsegment, in dem man sein Geld verdienen muß, nur ne kleine Firma möglich macht. W.S.
ui, da hat aber jemand Dampf abgelassen. Du siehst also die Möglichkeit, FPGAs grafisch zu programmieren, als Erleichterung an, die es Dir ermöglicht, etwas zu tun, was Du sonst nicht könntest? Oder kannst Du es damit einfacher / schneller? Mal angenommen, das wäre so, dass man mit dem grafischen programmieren schneller, sicherer und besser zum Ziel kommt. Warum sind die VHDL-cracks nicht in der Lage, das zu erkennen und stürzen sich drauf?
Timo schrieb: > Warum sind die VHDL-cracks nicht in der Lage, das zu erkennen und > stürzen sich drauf? Naja, ein bisschen Phantasie ist hier gefragt. Die Cracks beherrschen natürlich VHDL (oder Verilog, wenns denn sein muss), und haben die Lernkurve schon hinter sich, also käme es diesen nie in den Sinn, was mit grafischer Eingabe zu machen, weil sie mit VHDL wesentlich effizienter sind. Wenn Du aber mit FPGA und VHDL nichts am Hut hast und nur ein Garbage-Collector-CPLD aufsetzen musst (das was man ganz früher mit ein paar 74-ern erschlagen hat) ist es ja klar, dass Du Schematic-Entry den Vorrang gibst, und keine lange Lernkurve in Kauf nehmen willst...
Timo schrieb: > Warum sind die > VHDL-cracks nicht in der Lage, das zu erkennen und stürzen sich drauf? Zum Teil aus schierem Hochmut, zum Teil auch weil die Tools dazu schlechter sind als Leiterplatten-Tools, aber vor allem, weil sie die Fähigkeit, mit VHDL virtuos umzugehen mit was Anderem bitter bezahlt haben: Mit der Unfähigkeit, in all den anderen genannten Geschäftsbereichen klarzukommen. Außerhalb ihres Dunstkreises haben sie nämlich zwei linke Hände und das ist verständlich, denn viele Ingenieur-Spezialrichtungen vereinnahmen die Leute so sehr, daß man für "außerhalb" keine einzige graue Zelle mehr übrig hat. Wer in einer kleinen Firma Geräteentwickler ist, macht hingegen ALLES, von der Konzeption bis zur Kundenbetreuung, Mechanik und Elektronik und Programmieren und Kostenrechnung und, und, und. Da ist jeder Teilbereich eben nur ein Bereich neben vielen anderen und spezielle Eigenarten irgendwelcher Tools für einen dieser Bereiche, die sich anders verhalten als das üblichen Verhalten mehrerer anderer Bereiche, sind eben Bockmist und KO-Kritierium. Vielleicht verstehst du jetzt so nebenher meine dezente Abneigung gegen IDE's, weil eben jede IDE anders ist als die nächste. stell dir vor, bei Klavieren würden je nach Examplar die Töne anders angeordnet sein. Das würde jeden Pianisten zur Raserei bringen (nur solchen, die immer nur aud ein und demselben Klavier spielen, fällt da garnix auf). Und VHDL ist im Vergleich zu sonstigen Programmiersprachen so ein umgeordnetes Klavier. Ich hab z.B. ein innerbetrieblich viel wichtiger wahrgenommenes Problem damit, daß Zahlen von mir weitgehend inkompatibel sind mit dem Zeug, womit die Anderen umgehen, weil bei mir 12345.67 dasteht und nicht 12346,67 (vom Tausendertrenner mal ganz abgesehen). Solche Probleme gibt es auch und Streß mit der Chefetage ist noch ärgerlicher als wenn man einen Input-Vektor mit ner Zahl vergleichen muß und es in VHDL partout nicht hinkriegt. Dort dann einen vorgefertigten Digitalkomparator in Schematics hinzuklicken oder VHDL zum Teufen zu schicken und das ebenfalls ungeliebte Verilog zu bemühen, ist schlichtweg die einzige Lösung - jedenfalls, wenn man eben nicht die Zeit hat, ständig NUR irgendwas in VHDL zu schreiben. Verstehst du jetzt den Ansatz? Kurzum, die sogenannten Spezialisten haben ganz häufig Scheuklappen, die sie aber nicht mehr wahrnehmen. Zum allergrößten Teil kommt das daher, daß sie in eine eigene Welt eingestiegen sind, deren innere Art der Logik sie fälschlicherweise als generell logisch erachten. Sowas ist ne Abart des Realitätsverlustes, siehe z.B. die unsäglichen Diskussionen über Pointer-Arithmetik in C - um mal was anderes als VHDL zu erwähnen. W.S.
W.S. schrieb: > Wer in einer > kleinen Firma Geräteentwickler ist, macht hingegen ALLES, ... aber nichts richtig, könnte man hier einhaken und ich weiss, wovon ich hier rede, denn ich war selber in einer "kleinen Firma", in der alles schlampert zusammengestrickt wurde. Sobald man an Problemdesigns kommt, ist Ende im Gelände. Schicht im Schacht. Da geht es ohne genaue Kenntnisse nicht und die Grafik führt eher zur Unübersichtlichkeit, wie ich lernen musste. Du argumentierst für mich auch widersprüchlich, denn einerseits sagst Du W.S. schrieb: > Ingenieur-Spezialrichtungen vereinnahmen die Leute so sehr, > daß man für "außerhalb" keine einzige graue Zelle mehr übrig hat. und stellst dennoch heraus, dass Deine Vorgehensweise die einfachere und bessere / bequemere sei, die weniger Konzentration auf Details und Wissen erfordere. Wie passt das zusammen? Warum sollten die Erfahrenen nicht auch diese Vereinfachungen nutzen? Die Cracks sind doch nicht alle zu eingekapselt, zu erkennen, dass sie auf dem Holzweg sind und sehen die möglichen Vereinfachungen nicht, derer Du Dich bedienst? Was ist z.B. mit denen, die sich hier zu Wort gemeldet haben? Sind Lothar Miller, Jürgen Schuhmacher, Michael S., Mark Fritsch, die sich tendentiell gegen die Grafikgeschichte aussprechen, alles Scheuklappenentwickler? Ok, den Labviewhasser und den Labviewbeführworter Falk lassen wir mal dahingestellt, scheinen Extreme ihrer Art zu sein. Was mich frappiert, ist der Umstand, dass so kontrovers über die gleiche Sache geurteilt wird, wo es doch eigentlich keine 2 Meinungen geben sollte. Haben wir es hier nicht einfach mit Angewohnheiten zu tun? Herr Müller fängt mit grafischer Programmierung an und bleibt dabei, während Herr Meier es ohne gelernt hat und dann das "ohne" beibehält?
Naja, jeder hat so seine Weltsicht. Wenn einer bei Schematic bleibt, weil er keine Versionskontrolle braucht, alleine am Projekt arbeitet, keine Simulation des Designs macht und das auch niemals auch nur auf einem anderen FPGA des gleichen Herstellers wiederverwenden will, sowie eine Fehlersuche von vornherein auszuschließen weiß....na dann soll er halt Schematics reinklickern. Ist in kleinen Klitschen durchaus üblich. Die Qualität und Innovation der Produkte ist dann eben dementsprechend. Das Beispiel mit dem Vergleicher ist doch Murks, dann caste ich den Vektor entsprechend und schon kann ich den mit der Konstante vergleichen. Bei den Schematic weiß man ja nicht mal, welche der obsoleten Synapsis Libs der nun eingebunden hat, signed oder unsiged. Klar muss man sich als Ingenieur mal auf was spezialisieren, solche "Universal-Ingenieure" können eben alles, aber davon nichts richtig. So einen haben wir auch im Haus, der is sogar Dr. und auch so ein Typ, der alles kann, aber eben nur die Summary Sheets lesen und dann losackern. Nach mir die Sintflut. In einer Einmann-Show einer kleinen Krauter-Klitsche mag das gehen, aber wehe man muss mal mit jemandem zusammenarbeiten.
Christian R. schrieb: ... ne Menge wahrer Dinge... Leute, ueberlegt euch mal, warum sowas wie VHDL oder Verilog entstanden ist: VHDL ist entstanden, weil das amerikanische Verteidigungsministerium fuer seine Elektroniksachen eine 'Verhaltensbeschreibung' haben wollte. Vor allem auch aus dem Antrieb heraus, dass nicht mehr verfuegbare Bauteile 'einfach' nachgebaut werden koennen (eben weil da ihr Verhalten genau beschrieben ist). Und die wollten eigentlich nur 'Beschreibung' aka Simulation. Dass man das in HW giessen kann ist eigentlich nur ein Abfallprodukt! Wenn jemand zuhause auf 'genau seinem' Board da irgendwas graphisch zusammentackert, dann ist das ja ok. Aber wenn man einen Design fuer verschiedene Hersteller/Architekturen machen will, dann geht das nicht mit den proprietaeren 'Schematics'-Entschuldigungen irgendwelcher Hersteller. Es geht auch nicht mit irgendwelchen 'High-level-Tools', die unter der Haube auch nur irgendwelche unbekannte IP anziehen. Um's in SW-Sprech zu sagen: Du brauchst fuer deine Zielarchitektur eine 'Library' fuer sowas. Wenn ich heute in VHDL oder Verilog (es gab/gibt uebrigens auch noch andere) etwas beschreibe, dann kann ich das mit einem 'Standard'-Simulator beackern und ich muss auch fast nichts aendern, wenn sich die Technologie oder die Zielplattform aendert. Es ist so in etwa wie ' C fuer Hardware'. Und wie oben schon richtigerweise angemerkt wurde, jedes zusaetzliche Tool macht die ganze Sache auch noch komplizierter. Erst Recht wenn so ein Tool dann nur fuer eine bestimmte Plattform verfuegbar ist oder wenn es nur genau einen Hersteller gibt. Ich mache seit 1990 Logic-Design beruflich, anfangs auch mit proprietaeren Tools meiner damaligen Firma. Aber heute kann ich in z.B. VHDL oder Verilog einen Design machen, der ueber alle moeglichen FPGA- oder ASIC/StandartZell-Technologien 'implementierbar' (und simulierbar) ist. Und davon sind Matlab und Labview noch Ewigkeiten entfernt. Klar, der Trend geht in diese Richtung. Aber das wird noch (imho) ziemlich lange dauern. Und auch weil es oben angesprochen wurde: Kaestchen einer Component malen zu koennen ist ja prima. Aber wenn das dann wieder proprietaerer Mist ist, dann male ich die (vereinfachten) Kaestchen lieber von Hand (mit Inkscape oder Visio oder...) Nur mal meine 2cent zu dem Thema...
Meine Güte, ich kann mich des Eindrucks nicht erwehren, dass sich der Herr W.S. gewaltig selbst im Wege steht. Aber nun gut. Was ich dazu noch gerne sagen würde: Gerade, weil ich als 1-2Mann-Firma Innovationen stemmen muss, amortisieren sich die grafischen Tools so gar nicht, da oft andere Leute, teils auch externe, am Code arbeiten müssen, ohne ihn zu versauen. Da ist einfach - und es wird es in 100 Jahren auch nicht anders sein - die effizienteste Herangehensweise für nachhaltige und gut getestete Entwicklung: die Beschreibungs- oder Programmiersprache. Externe Dienstleister, die mir mit "Gucken Sie mal, ich hab ein super grafisches Tool, damit geht das im Nu" kommen, fliegen in der ersten Evaluations-Stufe schon raus. Nach nunmehr 15 Jahren in dem Geschäft geht das ohne Skrupel. Denn - supachris hat es treffend charakterisiert - 'Murks' kostet mich und den Kunden nur Ärger und Geld.
berndl schrieb: > Ich mache seit 1990 Logic-Design beruflich, .. Siehste, genau DAS ist der Knackpunkt. Du machst vermutlich NUR Logik-Design, oder betätigst du dich nebenher auch noch in anderen Entwicklungs-Gefilden? Und wenn, wieviel Zeit brauchst du, um mal eben von einem Gefilde auf's andere mental umzuschalten? Gehen dir auch noch Endanwender alle Nase lang telefonisch auf den Keks? Kurzum, Arbeitsteilung ist ja was Nettes, wenn man sie sich leisten kann - häufig genug kann man das aber eben nicht. Also auf CPLD's und FPGA's in den Geräten verzichten, sich nen Strick nehmen oder was? Ich denke mal, die hier geäußerten Meinungsunterschiede beruhen auf unterschiedlichen Berufsbildern und daraus entstehenden unterschiedlichen Blickrichtungen. W.S. PS: ach ja.. nochwas: Fitzebutze schrieb: > Meine Güte, und > Externe Dienstleister, die.. Tja, Fitzebutze wollte eigentlich ein Schimpfwort hinschreiben. Aber auch hier guckt das berufliche Umfeld durch. Ich hatte mal zu nem Einstellungsgespräch einen, der auf die Frage, ob er denn auch ein bissel mit Mechanik-CAD wegen Gehäuseentwürfen usw. umgehen kann, geantwortet hat, daß es für sowas ja Designfirmen gäbe. Ist ja nett und im Prinzip nicht falsch, aber rechnet sich bei meinem Marktsegment überhaupt nicht. So einen Gedanken konsequent zu Ende gedacht hieße: Man nehme für jeden Teil der Entwicklungsarbeit eine Spezialfirma, die es schon richten wird. Konsequenterweise dann auch für die AV und alles Weitere... Der Entwickler als Moderator zwischen Firmen, die ihren Teil abrechnen wollen und denen das Endergebnis egal ist, solange man ihnen keinen Fehler nachweisen kann. Mag ja sein, aber dabei kommt was heraus, das schlichtweg unverkäuflich ist. Naja.. welcher VHDL-Crack denkt an sowas, wenn er sich hier brüstet?
Das ist ja mal eine interessante Diskussion hier. Mir geht es haargenau so wie W.S. - ich muss in meiner Klitsche alles, aber auch wirklich alles, selbst machen. Außer der FiBu, die macht mir das Steuerbüro, weil meine Firma als GmbH bilanzpflichtig ist und diese Dienstleistung recht preiswert ist. Da wären also: grundlegende Entwicklungsarbeiten, Schaltungsentwurf, Leiterplattenlayout, mechanische Konstruktion, Schaltkreisentwurf, Prototypenbau, Serienproduktion, Lohnbuchhaltung, Staubsaugen, Kloputzen, Materialeinkauf, Kundenbetreuung (glücklicherweise pflegeleichte Großkunden), betriebiches Messwesen, Prototypeninbetriebnahme, Verpackung und Versand sowie Programmierung und Lebenserhaltung des Bestückungsautomaten. Ich beklage mich nicht über mein Leben, ich habe es selbst so gewollt und betrachte es als einzig mögliche Existenzform für mich, nachdem ich in meiner beruflichen Laufbahn in Groß-, Größt-, Kleinbetrieben gearbeitet habe und auch in der Hierarchie schon mal ziemlich weit oben war, also eigentlich alle Stationen eines Entwicklers kenne. Aber: als ich vor 15 Jahren mit der ISE 3.irgendwas zu arbeiten anfing, habe ich mich auch wie das Kind beim Kacken gefreut, dass ich da mit der Stromlaufeingabe arbeiten konnte. War ja alles gaaanz einfach und einleuchtend. Hat auch funktioniert. Irgendwann wurde es mir zu unhandlich und zu uneffektiv. Vor 10 Jahren habe ich meine ersten Gehversuche mit VHDL gemacht. Nach einer Frustperiode, bei der ich wie das legendäre Schwein ins Uhrwerk geguckt habe, kam dann irgendwann soetwas wie der Konstruktionsrausch. Mit ein paar Zeilen ließen sich komplexe Baugruppen schaffen - hier eine Zeile, dort ein Port, da eine Zuweisung und fast fertig. Das war der sogennante Aha-Effekt, einfach geil. Heute bin ich auf dem Stand, dass ich den Top-Level wegen der für mich besseren Durchsicht als Stromlauf mache und alles darunter als VHDL-Module. Das flutscht und geht ab wie Schmidts Katze, auch wenn ich immer wieder in die einschlägigen Bücher sehen muss. Das Dahingemurkel mit dem Stromlauf war für den Einstieg gut, erweist sich aber ab irgendeiner Stufe der Erkenntnis als uneffektiv, spätestens aber dann, wenn eine Portierung auf einen Schakltkreis eines anderen Herstellers ansteht. Fazit - es ist keinesfalls von Nachteil, wenn man seinec Werkzeuge gut beherrscht. Dann kann man selbige auch zu seinem größtmöglichen Nutzen einsetzen und spart sich effektiv eine Menge Zeit und Frust. Ich bin kein VHDL-Perfektionist und werde es mit fast 60 Jahren auch nicht mehr werden. Aber VHDL ist gegenüber der Durchwurstel-Methode um etliche Klassen eleganter. Bei allen anderen betrieblichen Prozessen mache ich schließlich und letztendlich auch keine Abstriche, sei es der Leiterplkattenentwurf oder die Messtechnik. Also, lieber W.S., auch du wirst noch Blut lecken und auf den Geschmack kommen.
W.S. schrieb: > So einen Gedanken konsequent zu Ende gedacht hieße: Man nehme für jeden > Teil der Entwicklungsarbeit eine Spezialfirma, die es schon richten > wird. Konsequenterweise dann auch für die AV und alles Weitere... > Nein. Ich mache nur die Sachen selber, die ich gut kann. Was andere gut können, sollen andere machen. Es ist ein reiner Effizienzaspekt und im Endeffekt eine Frage des guten Managements. Die Zusammenarbeit mit anderen Cracks funktioniert nur, wenn sie die gleiche Sprache sprechen und für die Sache anstatt fürs Ego arbeiten. Ich gebe Dir recht, dass es auch Cracks gibt, die supergut auf ihrem Fachgebiet sind, aber in der Zusammenarbeit untauglich, da sie ihre ganz eigene Suppe kochen. Heisst, den Begriff "Sprache" kann man auch ausweiten. Bis zum Bier abends in der Kneipe. > Der Entwickler als Moderator zwischen Firmen, die ihren Teil abrechnen > wollen und denen das Endergebnis egal ist, solange man ihnen keinen > Fehler nachweisen kann. Mag ja sein, aber dabei kommt was heraus, das > schlichtweg unverkäuflich ist. Naja.. welcher VHDL-Crack denkt an sowas, > wenn er sich hier brüstet? Wenn mein Produkt unverkäuflich wäre, warum sollte ich dann überhaupt so (ohne Finanzierung und entsprechendes Management) anfangen? Die Cracks, die sich hier outen, sind nach m.E. im Geschäft erfolgreich, und wissen, wovon sie sprechen. (Sie sprechen zumindest meine 'Sprache').
W.S. schrieb: >> Ich mache seit 1990 Logic-Design beruflich, .. > > Siehste, genau DAS ist der Knackpunkt. > > Du machst vermutlich NUR Logik-Design, oder betätigst du dich nebenher > auch noch in anderen Entwicklungs-Gefilden? ...durchaus, ich muss mir 'meine' Spec fuer die Logik auch selbst erarbeiten. Aber ich mache z.B. keine Platine, aus dem Geschaeft bin ich seit ueber 20 Jahren raus und habe dementsprechend auch viel zu viel verpasst. > Und wenn, wieviel Zeit > brauchst du, um mal eben von einem Gefilde auf's andere mental > umzuschalten? Naja, ich muss ueber das Gesamtsystem auch 'ne Menge wissen, um da dann eine Loesung anbieten zu koennen. 'Umschaltzeit' ist dbzgl. eigentlich 'null Sekunden'. Aber ganz klarer Fall, ich decke nicht alles ab, sondern 'nur' ein gewisses Gebiet. Ich wuesste z.B. auch nicht, wo und wie ich die Fertigung einer Platine/eines Geraets organisieren sollte. Ist fuer mich ein komplett anderes Universum. > Gehen dir auch noch Endanwender alle Nase lang telefonisch > auf den Keks? Oh ja, da diese Kisten ziemlich erklaerungsbeduerftig sind und ja niemand mehr die Zeit hat, sich da in Ruhe einzulesen... Ich setz' mich dann auch mal neben die Leute und nehme die Kisten zusammen mit ihnen in Betrieb. Alles andere ist nicht wirklich effektiv. Aber wenn du gerne 'Bildchen' fuer deinen Design hast, hast du schon mal Doxygen ausprobiert? Alles in z.B. VHDL, nur die Kommentare brauchen ein bestimmtes Format. Dann kannst du u.a. auch Grafiken des Designs erzeugen (vollautomatisch). Steht und faellt natuerlich mit der Aktualitaet der Kommentare. Ich hatte ein paar 'geerbte' Designs, da wurde damit gearbeitet. Leider waren die Kommentare nicht up-to-date und dann halt die Doku auch nicht mehr so richtig prickelnd. Aber waere evtl. fuer dich eine Moeglichkeit. Und zumindest unabhaengig von der Technologie/Plattform ist es. Und mein Mgmt war begeistert (dass die Doku outdated war, haben die ja nicht gemerkt/begriffen...). Also, einige Kommentare hier haben viele Vorzuege von 'HDL-only' aufgezeigt. Wenn du das anderst machen willst, ist das ja dein gutes Recht. Aber rede dich danach nicht raus so als haette dich keiner gewarnt :o)
berndl schrieb: > hast du schon mal Doxygen ausprobiert? Alles in z.B. VHDL,... wenn ich könnte, würde ich den, der Doxygen erfunden hat, nach Art von Osmin behandeln: erst geköpft und dann gehangen, dann... Nee, Dokus die mit Doxygen gemacht wurden, sind durchweg das miserabelste was es gibt, weil ein Programm eben niemals den Sinn der zu erklärenden Dinge darstellen und erläutern kann. Sowas kann nur ein realer Mensch. Programme haben keine didaktischen Fähigkeiten, aber genau diese braucht es bei Dokus - wenn sie was bringen sollen und nicht nur als lästige Pflichtübung empfunden werden. Und Schematics ist gut, um eben gerade VHDL zu vermeiden. Jeder, der nen Schaltplan lesen kann, kommt auf Anhieb damit klar - im Gegensatz zu VHDL. So herum. Versuch doch mal, mit Auszügen der VHDL-Quellen im Usermanual den Benutzern deiner Werke zu kommen. Die gesamte Kundendienst-Abteilung wird dir an der nächsten Hausecke auflauern.. Da ist ein sauberes Schematic um Größenordnungen besser. Guck dir als Beispiel mal die HW-Manuals diverser Mikrocontroller an. Da findest du alles - von vorbildlich bis katastrophal. Ich hab einiges gegen VHDL, im Grunde deshalb, weil es zu einschränkend ist - man kann nicht formulieren, was man haben will, sondern nur, was das Sprachkorsett erlaubt und das ist oftmals stupide und wird dem Anliegen nicht gerecht, sondern nur der knöseligen Denkstruktur seiner Erfinder. Eine Formulierungssprache, die darstellt, was man tatsächlich meint und haben will, wäre besser... ;-) W.S.
W.S. schrieb: > Ich hab einiges gegen VHDL, im Grunde deshalb, weil es zu einschränkend > ist - man kann nicht formulieren, was man haben will, sondern nur, was > das Sprachkorsett erlaubt und das ist oftmals stupide und wird dem > Anliegen nicht gerecht, sondern nur der knöseligen Denkstruktur seiner > Erfinder. Naja, ich weiss ja auch nicht wirklich, ob ich VHDL mag oder nicht. Fuer mich ist aber der Punkt: VHDL ist schwer zu schreiben, aber du kannst es dir ein Jahr spaeter wieder ansehen und verstehst es (eben auch wegen der restriktiven Syntax). Verilog ist einfach zu schreiben, aber ein Jahr spaeter verstehst du nur Bahnhof... Und ja, Doxygen sowie die automatisch generierten Bildchen sind nix fuer Kunden oder Mgmt. Das kann, wenn die Kommentare 'up-to-date' sind, fuer den Designer eine Hilfe sein. Aber ich sehe, du bist nicht wirklich ein Freund von HDL. Sei dir auch unbenommen. Ich sehe HDL fuer mich und meine Probleme im Beruf als Segen. Aber wir gelten da beide wohl als subjektiv. Und wenn ich dann noch an so Sachen wie Labview, Matlab, SystemC, ... denke, dann wird's mir auch schlecht... Du musst letztendlich selber wissen, womit du gluecklich wirst. Und ich werde mich hueten, dir hier meine Erfahrungen als Weisheit bis in alle Ewigkeit zu verkuenden... (aber trotzdem finde ich HDL besser als schematics! :o)
W.S. schrieb: > Und Schematics ist gut, um eben gerade VHDL zu vermeiden. Jeder, der nen > Schaltplan lesen kann, kommt auf Anhieb damit klar - im Gegensatz zu > VHDL. So herum. Versuch doch mal, mit Auszügen der VHDL-Quellen im > Usermanual den Benutzern deiner Werke zu kommen. Die gesamte > Kundendienst-Abteilung wird dir an der nächsten Hausecke auflauern.. :o) Naja, VHDL den Endusern beizubrigen sollte nicht das Ziel sein. Aber mit den Schematics stirbst du bei der Komplexitaet heutzutage auch den Heldentod... Usern (und Auftraggebern) zeige ich Inkscape/Visio Blockdiagramme. Mehr kriegen die in ihre Birne nicht rein, genauso wie ich Probleme habe, die 'Probleme' meiner Kunden nachzuvollziehen. Es wird halt recht komplex heutzutage...
W.S. schrieb: > wenn ich könnte, würde ich den, der Doxygen erfunden hat, nach Art von > Osmin behandeln: erst geköpft und dann gehangen, dann... ah, den kann ich mir jetzt nicht verkneifen (sorry dafuer): Wenn du also alles selber machst, dann koenntest du die Kommentare ja so schreiben, dass Doxygen ein brauchbares Ergebnis (==Doku) rausschmeisst :o) Also ich bin auch nicht so der Toolfreund, aber wenn's immer komplexer wird, dann muessen wir eine Moeglichkeit finden besser zu abstrahieren. Ich sehe nicht, dass das anderst funktionieren kann... Nix fuer ungut...
Wer mit Doxygen umgehn kann, schreibt damit auch gute Dokumentation. Ansonsten wäre es ziemlich idiotisch, eine API-Dokumentation manuell zu erstellen. Ich nutze ab und an mal Doxygen auch, um bestehende Projekte zu verstehen bzw. schnell in der Struktur zu navigieren. Also bitte, denkt doch nochmal bisschen nach, bevor ihr den Herrn van Heesch teert und federt..
>Und Schematics ist gut, um eben gerade VHDL zu vermeiden. Jeder, der nen >Schaltplan lesen kann, kommt auf Anhieb damit klar - im Gegensatz zu >VHDL. Es gibt VHDL-Einsteiger-Seminare. Vielleicht solltest Du Dir ein solches Seminar (ganz unvoreingenommen) reinziehen. Schematic-Schaltungen kann man nicht simulieren. Ab einer gewissen Komplexitätsstufe bist Du ohne Simulation VERLOREN. Erzähl doch mal aus dem Schematic-Stübchen: Was für Schaltungen "baust" Du denn so? VG, Dr. Schnaggels
Dr. Schnaggels schrieb: > Schematic-Schaltungen kann man nicht simulieren. Ab einer gewissen > Komplexitätsstufe bist Du ohne Simulation VERLOREN. Das kann man so auch nicht stehen lassen. Bei Xilinx kann man sich daraus VHDL Spaghetti Code erzeugen lassen (vhi File) und das simulieren. Aber das ist einfach nur krank in der Benutzerfreundlichkeit. In dem Sauerkraut findet man dann nichts mehr wieder.
Strubi schrieb: > Wer mit Doxygen umgehn kann, schreibt damit auch gute Dokumentation. > Ansonsten wäre es ziemlich idiotisch, eine API-Dokumentation manuell zu > erstellen. Wer Doygen benutzt schreibt gerne 100 Zeilen vor eine 5 Zeilen Funktion und versaut sich seinen Code. Eine API Beschreibung gehört so oder so nicht in den Sourcecode. > Ich nutze ab und an mal Doxygen auch, um bestehende Projekte zu > verstehen bzw. schnell in der Struktur zu navigieren. Bestimmt mit lynx oder? Evtl. schaffst du dir mal eine gescheite IDE an. > Also bitte, denkt doch nochmal bisschen nach, bevor ihr den Herrn van > Heesch teert und federt.. Ich habe schon sehr viel über den lästigen Doku-Bullshit in Sourcecodes nachgedacht. Es macht einfach keinen Sinn :-). So long.
berndl schrieb: > Aber wir gelten da beide wohl als subjektiv. Logisch. Wir beackern auch unterschiedliche Berufs-Felder und das macht einen gewaltigen Unterschied. Aber ich denke mal, so langsam ist alles zum Thema gesagt - bis demnächst, wo es unter anderem Namen wieder auftaucht. Also denne W.S.
W.S. schrieb: > Aber ich denke mal, so langsam ist alles zum Thema gesagt Ach, weil Du Dich jetzt ausgehustet hast :-) ? Die Frage ist doch: Wo fängt "grafisch programmieren" an und wo hört es aus. Alles als Schaltplan einzugeben macht so gut wie keinen Sinn.
>Das kann man so auch nicht stehen lassen. Bei Xilinx kann man sich >daraus VHDL Spaghetti Code erzeugen lassen (vhi File) und das >simulieren. Man muss auch mal realistisch bleiben: Wird jemand, der VHDL Spaghetti Code aus einem Schematic erzeugen lässt, im Stande sein, eine VHDL-Testbench zu schreiben? Wohl kaum ...
Moin, > > Wer Doygen benutzt schreibt gerne 100 Zeilen vor eine 5 Zeilen Funktion > und versaut sich seinen Code. Eine API Beschreibung gehört so oder so > nicht in den Sourcecode. > Teilweise einverstanden. Sie gehört bevorzugt in den Header. Und der lange Text besser in eine separate main.doxy. Das Problem liegt zwischen zwei Ohren, nicht am Tool. >> Ich nutze ab und an mal Doxygen auch, um bestehende Projekte zu >> verstehen bzw. schnell in der Struktur zu navigieren. > > Bestimmt mit lynx oder? Evtl. schaffst du dir mal eine gescheite IDE an. > Es soll auch grafische Browser geben... Mit einer IDE kann ich a) Code nicht besser verstehen b) Code nicht besser dokumentieren c) nicht schneller arbeiten >> Also bitte, denkt doch nochmal bisschen nach, bevor ihr den Herrn van >> Heesch teert und federt.. > > Ich habe schon sehr viel über den lästigen Doku-Bullshit in Sourcecodes > nachgedacht. Es macht einfach keinen Sinn :-). > Wenn ich das einem Kunden erzählen würde, wäre der Auftrag weg. "Read the source, Luke" geht da nicht. Ich möchte keine Frickelei abliefern, sondern möglichst Module, die sich synchron zur Doku verhalten (veraltete inkonsistente API DOCs in Word sind no go) und woraus ersichtlich ist, was sich der Entwickler beim Entwurf der Library gedacht hat. Sorry, aber wenn ihr einen Quasistandard wie Doxygen attackieren wollt, müsstet ihr schon bessere Argumente bringen. Dasselbe gilt für VHDL, und dazu wurde ansich schon alles gesagt. Wem VHDL stinkt, der kann sich auch mit Novi wie System<whatever> oder MyHDL beschäftigen. Jeder Frickler soll für sich so machen, wie er am schnellsten zum Ziel kommt. Aber: in der Kollaborative zählt ein wohldefinierter Standard, eine einheitliche Kommunikation sowie Dokumentation.
Strubi schrieb: > Quasistandard wie Doxygen Quasistandard? Für Software vielleich, für Hardware sicher nicht.
Und was stört dich daran, dass das etwas zusammenwächst? BTW: Ich finde es immer ziemlich erschreckend, mit welchen vorsintflutlichen Methoden (und buggy SW) die HW-Entwickler oft noch arbeiten (müssen). Das fängt bei Tcl an, das man ja guten Gewissens gar nicht Sprache nennen dürfte... Aber die HWler wollen lieber eine Extra(hart)wurst, damit sie sich gegenüber den SWlern wie echte Männer vorkommen. Bloss nicht über den Tellerrand schauen... Georg (bevor Fragen aufkommen: FPGAs seit '93, VHDL seit '95)
W.S. schrieb: > Es gibt ne Menge Leute, die auch noch was Anderes zu tun haben, als > immerzu nur CPLD's und FPGA's zu programmieren. Da stört es gewaltigst, > wenn man zu diesem Zweck auch noch 1..2 neue Programmiersprachen > (konkret: VHDL und Verilog) lernen muß. Da habe ich aber eine ganz andere Haltung! Gerade weil ich oft genug noch anderes zu tun habe, fehlt mir die Zeit für die Spielerei und ich reduziere das Grafikturnen auf das Nötigste. VHDL lernt man erheblich schneller, als das Grafiktool und alle seine Macken. Uen eigentlichen Aspekt der Schaltungsentwicklung, nämlich die Konzeptphase, das Nachdenken, das Umsetzen in einer Schaltungsstruktur und einen Ablauf kommt man ohnehin nicht herum. Gemessen an den Gesamtaufwänden ist das Coden eigentlich der kleine Anteil und die Grafik nimmt es einem ja nicht ab, die richtige Schaltung zu finden. Im Gegenteil: Tools wie die o.g. stellen mir nur mehr Hürden in den Weg, weil sie nicht funktionieren und einen grossen Mist bauen, wie ich es gerade wieder bei der Firma mit dem grossen X erleben muss: Baut man einen neuen Block oder ein Signal ein, verschieben sich Symbole und Leitungen und es werden vollkommen falsche Verbindungen geschaffen. Das Problem dieser Schaltplantools ist, dass sie aus der Grafikinformation die Logikverbindung generieren wollen, statt umgekehrt die grafische Repräsentation zu zeichnen, nachdem ich ihm mitgeteilt habe, was womit verbunden ist. Sobald eine Schaltung etwas grösser ist, erhält man eine Wüste an Drähten, die die Übersicht mindern. In einem von der Schaltung losgelösten Plan, den ich selber zeichne, kann ich entscheiden, was an Infos rein muss. Ich dokumentiere eine pipeline anders, als die Logikübesicht, den Signalfluss oder den physikalischen Wrapper des FPGA-Designs. Damit erreiche ich den Top-Down-Entwurf, den ich brauche und kann ihn mit den von unten kommenen Anforderungen verbinden. Die geschlossenen existenten Tools helfen mir dabei nicht und unterstützen das auch nicht. Im Gegenteil: Die Tools basieren alle auf der bottom-up Methode, die für ein modernes Design komplett untauglich ist und nur das Hacken und Frickeln fördern. Was ich an Deiner Argementation nicht verstehe: W.S. schrieb: > Vielleicht verstehst du jetzt so > nebenher meine dezente Abneigung gegen IDE's, weil eben jede IDE anders > ist als die nächste. Na, da haben wir es doch: Mehrarbeit bei der Einarbeitung und potenzielle Inkompatibilität der Daten - eher ein Argument gegen die IDE. Allerdings frage ich mich, warum Du dies so einwirfst: Die IDE bestimmt doch nicht, ob man grafisch programmiert. Ich nutze auch die IDE als solche und programmiere nicht automatisch grafisch. Du aber lehnst IDEs als problematisch und gewöhnungsbedürftig ab, aber die Eingabe von VHDL ohne Schnickschnack, die doch gerade die Konsequenz aus dieser Betrachtung wäre, ist Dir zu komplex? >Selbständigkeit Hier werden wieder Begriffe und Themen durcheinander geworfen: Ich bin auch selbständig, arbeite an mehreren Themen gleichzeitig und habe keine Zeit zu verschwenden. Ich habe HW, SW und FW in allen Facetten gemacht und kann nicht erkennen, warum Angestellte in Kleinfirmen oder Grossfirmen grundsätzlich anders designen sollten, als Selbständige. Das ist weder zwingend noch logisch. Ich sehe auch nicht, dass denen allen die Weitsicht fehlt, selbst wenn sie jahrelang nur eine Sache gemacht haben.
Georg A. schrieb: > Aber die HWler wollen lieber eine > Extra(hart)wurst, damit sie sich gegenüber den SWlern wie echte Männer > vorkommen. Soso, das trifft für alle Hardwareentwickler Deutschlands zu? Also die die ich kennne, versuchen täglich, ihre Arbeit zu optmieren und Nutzloses beiseite zu lassen. Georg A. schrieb: > Georg (bevor Fragen aufkommen: FPGAs seit '93, VHDL seit '95) Mit welchem FPGAs hast Du im Jahre 1993 gearbeitet? Bei mir hiessen die noch PLD. Dr. Schnaggels schrieb: > Schematic-Schaltungen kann man nicht simulieren. Ab einer gewissen > Komplexitätsstufe bist Du ohne Simulation VERLOREN. Sagen wir mal so, man kann sie nur schlecht simulieren, weil alles an der Oberfläche bleibt. Genau wie bei einer Schaltung möchte ich aber auch mal reinmessen und wenn ich dann Signalnamen suchen muss, die sich bei jedem Parserdurchlauf ändern, nutzt das alles nichst. Genau an diesem Punkt geht nämlich die angebliche Übersicht, die die Grafik im Designprozess bringen soll, doppelt und dreifach flöten.
> Soso, das trifft für alle Hardwareentwickler Deutschlands zu? > Also die die ich kennne, versuchen täglich, ihre Arbeit zu optmieren und > Nutzloses beiseite zu lassen. Ich kenne durchaus einige HW-Entwickler von kleinen Firmen bis zu sehr grossen. Am "überzeugensten" bzgl. der Effizienz war die Art der Entwicklung eigentlich immer bei Leuten, die sowohl HW also auch SW machen. Hardcore-HWler fallen da eher durch eine gewisse Verbohrtheit auf ("haben wir schon immer so gemacht"). Wobei doch gerade jetzt mit den HDLs SW und HW langsam wieder zusammenfinden... > Mit welchem FPGAs hast Du im Jahre 1993 gearbeitet? Bei mir hiessen die > noch PLD. XC3020/3042. Mit GALs habe ich mit selbstgebasteltem Programmer&"Compiler" schon '87 gespielt. Da sind mir aber entweder immer die FFs oder die Pins ausgegangen. FPGAs haben das (zumindest kurzfristig...) gelöst.
Oder die guten "alten" 4000ter, hier ein XC4040 mit Datumstempel von 1993: http://www.ebay.com/itm/XC4010-5MQ208C-XC4010-5-XC4010-Xilinx-QFP-Integrated-Circui-t-/200752523579#ht_986wt_1032 so einer liegt bei mir auch noch rum. >> Schematic-Schaltungen kann man nicht simulieren. Ab einer gewissen >> Komplexitätsstufe bist Du ohne Simulation VERLOREN. >Sagen wir mal so, man kann sie nur schlecht simulieren, weil alles an >der Oberfläche bleibt. Genau wie bei einer Schaltung möchte ich aber >auch mal reinmessen und wenn ich dann Signalnamen suchen muss, die sich >bei jedem Parserdurchlauf ändern, nutzt das alles nichst. Genau an >diesem Punkt geht nämlich die angebliche Übersicht, die die Grafik im >Designprozess bringen soll, doppelt und dreifach flöten. Kommt auf die Software an, bei teuer Cadence oder Mentor kann man Schematics brauchbar in VHDL oder verilog rausschreiben und simulieren, aber man ist halt dann von einem Hersteller abhängig, wenn das Marketing dort die Tools ändert oder neue Tools kauft oder die Firma verkauft wird, kann man wieder alle Schematics neu machen, VHDL und verilog aber bleiben.
Georg A. schrieb: > XC3020/3042. Die hatte ich auch in der Mache. Ich war nur erstaunt, dass Du diese Bausteine (der 3020 hatte kaum CLBs) als "FPGAs" titulierst :-) Waren das Zeiten, als man einen kompletten Baustein in einer Stunde Programmierarbeit voll hatte ... Mitleser schrieb: > Herr Müller fängt mit grafischer Programmierung an und bleibt dabei, > während Herr Meier es ohne gelernt hat und dann das "ohne" beibehält? Also ich habe "ohne" angefangen, später "mit" fortgesetzt, dann beides mehrfach in allen Lagen gemacht und bin nach reiflicher Erfahrung zum Schluss gekommen, dass Grafikeingabe unnütze ist. Ich habe die Aufwände in Sachen Pflege, Vor-/Nachteile auch bereits genauer untersucht und gegenüber gestellt und die Zeiten für übliche Designzyklen berechnet.
Timo schrieb: > Mal angenommen, das wäre so, dass man mit dem grafischen programmieren > schneller, sicherer und besser zum Ziel kommt. Warum sind die > VHDL-cracks nicht in der Lage, das zu erkennen und stürzen sich drauf? Weil man dann zusätzlich zu den "sowieso" nötigen Schaltplan- und Layouttools nochmal einen (oder zwei oder drei) Schaltplaneditor mit toll versteckten Features und überraschenden Bugs beherrschen lernen müsste. Denn es wird sicher nicht "DEN EINEN" Schalptlaneditor für alle FPGA-Hersteller geben... Ich schreibe meine Hardware lieber so, dass ich sie notfalls unterwegs mit jedem beliebigen Textbetrachter anschauen kann. Die Dokumentation gegenüber den Softies oder gar gegenüber dem Kundendienst ist sowieso wesentlich anders orientiert als ein Schaltplan das hergeben könnte. Oder wie will ich Memory-Mappings (als einfachste Art einer Doku) in einem Schaltplan darstellen? Interessierter Mitleser schrieb: > Herr Müller fängt mit grafischer Programmierung an und bleibt dabei, > während Herr Meier es ohne gelernt hat und dann das "ohne" beibehält? Ich habe "gemischt" angefangen und keinen Vorteil in den Schaltplänen erkannt. Für die Doku waren sie letztlich unnütz, weil zu detailliert. Jetzt beschreibe ich alles in VHDL und bin froh dran, weil ich einfach mal so zu Test ein Design auf einen anderen Hersteller portieren kann. Natürlich ist da jeweils noch Handarbeit nötig, aber sicher weniger, als wenn ich das komplette Design mit den Tools von X gemalt hätte und dann auf L portieren müsste.
Das Einzigste wo man nachdenken kann, es grafisch zu machen, sind die state machines. Alles andere kann man zwar grafisch darstellen, sollte es aber nicht so eingeben. Dies ist scheint ein guter Ansatz: http://embdev.net/topic/297081#new
Markus Wagner schrieb: > Das Einzigste wo man nachdenken kann, es grafisch zu machen, sind die > state machines hmm, also das 'allereinzigst' wahre sind doch state machines mit einem simplen 'case x is'... Also mir persoenlich sollte niemand erzaehlen, dass eine SM/FSM in Grafik leichter zu verstehen ist als eine in Textform... Das will ich echt nicht glauben.
In der Grafik kann man bei vernünftiger Auslegung die Struktur der Zustandswechsel auf einen Blick erkennen (Zyklen, Endzustände, sowas). Grafiken sind immer gut für einen Überblick. Aber ein Überblick muss nicht zwingend einem festen Schema folgen, weil das schnell dazu verleitet, wegen der Umständlichkeit keinen Überblick anzubieten. In Grafik zu programmieren halte ich auch für schwachsinn, aber mag es, in Grafik zu verdrahten.
>Georg A. >Ich finde es immer ziemlich erschreckend, mit welchen >vorsintflutlichen Methoden (und buggy SW) die HW-Entwickler oft noch >arbeiten (müssen). Das fängt bei Tcl an, das man ja guten Gewissens gar >nicht Sprache nennen dürfte... Mit welcher Skriptsprache steuerst Du denn Simulationen und Synthesen? Dr. Schnaggels
Cool fände ich ein Prog was meine Case, if else etc - FSMs in eine Grafik übersetzt... so zur Anschaung. Das wäre echt geil. Erst recht wenn man größere Zustandsautomaten baut, die aus mehreren kleineren FSMs bestehen die parallel arbeiten und miteinander interagieren. Aber sowas wäre wohl programmtechnisch nicht möglich, zumindest kenn ich kein Prog was einem Code (Verilog/VHDL) in Grafik übersetzt. Also muss ich wohl weiterhin selber parallel mit Bleistift auf meinem Block rumkritzeln :)
Also in Altera Quartus gibt es Netlist Viewer, darunter auch einen State Machine Viewer. Der zeigt die aus VHDL/Verilog erzeugten State Machines grafisch an.
Andreas B. schrieb: > Der zeigt die aus VHDL/Verilog erzeugten State Machines > grafisch an. Schon mal ausprobiert? Vollkommen unlesbar. berndl schrieb: > hmm, also das 'allereinzigst' wahre sind doch state machines mit einem > simplen 'case x is'... Also mir persoenlich sollte niemand erzaehlen, > dass eine SM/FSM in Grafik leichter zu verstehen ist als eine in > Textform... Das will ich echt nicht glauben. Absolut d'accord. Je umfangreicher die FSMs werden desto mehr un genauer muss man sie dokumentieren und ein Drahtverhau der klassischen Art ist a denkbar schlecht geeignet. Im bevorzuge partielle Beschreibungen mit den positiven Abläufen, exemplarisch für jeden Fall. Das ergibt auch bei grösseren Funktionseinheiten immer noch ein leicht überschaubares Ablaufverhalten. Ansonsten müsste man ja das Design mit all seinen Entscheidungsoptionen gedanklich durchsimulieren um zu prüfen, ob die auf einander folgenden Entscheidungen und Reaktionen jeweils passen, welche davon erlaubt sind und welche nicht - welche funktionell versagt sind und welche nicht und daher abgefangen werden müssen. Sowas schlüsselt man einfach tabellarisch auf - passt auch bestens zur formellem requirement engineering.
Man sollte sich bei seinem konkreten Automaten auch anschauen, ob evtl. eine ganz andere Form der Implementierung taugt, nämlich Mikroprogrammierung. Wenn man viel lineare Fortschaltungen hat und nur wenig Verzweigungen oder auch wiederkehrende Fortschaltungsschemata (zB. Verharren in einem Zustand mit Warten auf eine Bedingung, ansonsten einen weiter), kann man dafür einen spezialisierten Sequencer bauen, der nur die Addresse einer Lookuptabelle verändert. Dann kommt alles über die eine Addresse (nennen wir sie mal "PC" ;) ) aus RAMs, also Sequencersteuerung (Bedingungen, next-PC) und Ausgangswerte. Mikroprogrammierung ist besonders tauglich, wenn man Vorgänge hat, die man ansonsten eigentlich mit einer CPU machen würde, aber nicht den Platz dafür hat. Die Sache mit dem Sequencer klingt umständlich, bei solchen Automaten lässt sich der aber meistens in einer Handvoll Zeilen erledigen. Man muss halt schauen, dass man die Bedingungen in ein Schema quetscht. Das Schöne an der MP ist dann auch, dass die Entwicklung des Programms auch in strukturierter Textform erfolgen kann/soll und man es auch ohne FPGA-Änderung im System updaten kann, halt wie SW. Hier mal ein Ausschnitt aus dem Mikroprogramm für das Parsen und Erzeugen von Paketen, MUX-CMD ist die Sequencersteuerung, die anderen CMDs gehen an diverse Units und schalten Datenflüsse bzw. starten Aktionen:
1 | // Cur. next PANAMCMD DMANCMD TRANSAMCMD LBMANCMD MUXCMD |
2 | /* W_RQO : Assembles packet for outgoing write_sb(address, data and SCI-cmd) */ |
3 | 1 16 TRANSADR_2_DPR GEN_ADR_LSB NONE NONE GO |
4 | 16 17 DATAL_2_DPR NONE NONE DATA_READY MUX_WAIT |
5 | 17 18 TIDCMD_2_DPR GEN_WRQ_CMD SEND_W_RQO NONE GO |
6 | 18 0 NONE NONE DONE_WRQ DONE GO |
7 | |
8 | /* R_RQO : Assembles packet for outgoing read (SCI-cmd and address), waits for data*/ |
9 | 2 19 TRANSADR_2_DPR GEN_ADR_LSB SEND_R_RQO NONE GO |
10 | 19 20 TIDCMD_2_DPR GEN_RRQ_CMD NONE NONE GO |
11 | 20 21 NONE NONE SET_RRSI NONE MUX_WAIT |
12 | 21 63 DPR_2_DATAL NONE SET_RRSI DATA_READY GO |
13 | |
14 | /* W64_RQO: Assembles packet for DMA-write */ |
15 | 3 22 TIDCMD_2_DPR GEN_W64_CMD NONE NONE MUX_DMA_STATE |
16 | 22 23 TRANSADR_2_DPR GEN_ADR_LSB NONE NONE GO |
17 | 23 24 DATAL_2_DPR NONE NONE DATA_READY MUX_WAIT_DMA |
18 | 24 63 NONE NONE SEND_W64_RQO NONE GO |
19 | ... |
Der Originalautomat (und auch die MP) hat ca. 60 States, das war als case-when-Gewurschtel nicht mehr wartbar. Aber in dem MP-Format verstehe ich es sogar jetzt nach fast 17 Jahren wieder ;) Leider ist das Wissen um die Mikroprogrammierung sowohl bei SWlern als auch HWlern kaum (mehr) vorhanden. Wird alles in die Ecke "unnütze Praktiken aus der Computersteinzeit" einsortiert...
Moin Georg, > Man sollte sich bei seinem konkreten Automaten auch anschauen, ob evtl. > eine ganz andere Form der Implementierung taugt, nämlich > Mikroprogrammierung. Sehr guter Punkt. Gibt bloss HW-Puristen, die behaupten, das sei unlesbar. Allerdings würde ich als auch sagen, es ist einfacher, Microcode zu verstehen als eine aufgeblasene State-Machine. > > Leider ist das Wissen um die Mikroprogrammierung sowohl bei SWlern als > auch HWlern kaum (mehr) vorhanden. Wird alles in die Ecke "unnütze > Praktiken aus der Computersteinzeit" einsortiert... Ich würde es gar nicht als Steinzeit bezeichnen, sondern eher als Geheimtip. In jedem Intel-Prozessor findet sich noch Microcode. Wenn ich mich richtig entsinne, war es bei der Migration zum Pentium noch so, dass der alte i86-Code (16 bit) sogar zur Laufzeit in Microcode übersetzt wurde. Welche Tricks bei on-chip Java-Bytecode-Interpretern verwendet werden, will ich gar nicht wissen... Allerdings mag es sein, dass dieses HW/SW-Hybridwissen bei uns in Europa an den FHs eher dünn gesäht ist. Sollte aber niemanden davon abhalten, offensichtlich elegante Tricks anzuwenden :-) Ich nutze übrigens Microcode auch relativ ausgiebig innerhalb einer DSP-Toolbox. Damit lassen sich z.b. schnelle Matrizenmultiplikation oder Transformationen wie DCT erschlagen. Geschwindigkeits-Nachteile gibt es nicht, sogar der Logik-Bedarf ist oft geringer, da sich alles generell vereinfacht und redundante Opcode-Bits gut von den Tools wegoptimiert werden. Der einzige Nachteil ist bei der Sache nur, dass der Aufwand, einen einheitlichen und lesbaren Micro-Assembler-Befehlssatz ('Mnemonics') zu definieren, etwas hoch ist. Da aber der Microcode selten länger als 16 Wörter wird, kann man sein Programm aber auch einfach mit Hilfe von VHDL records schreiben, zB wie in diesem ROM-Programm:
1 | constant program : program_t(0 to 7) := ( |
2 | |
3 | opcode_t'( OPA_VOM, A_ADDSUB, A_ADDSUB, |
4 | L(1), L(1), U(6), |
5 | OPB_NOP, "00", "0", |
6 | OPC_STA, I(3), I(7)), |
7 | opcode_t'( OPA_VOM, A_ADDSUB, A_SUB, |
8 | L(2), L(2), U(5), |
9 | OPB_VEM, A_ASSIGN, "0", |
10 | OPC_STD, I(0), I(4)), |
11 | |
12 | ... |
Ich habe mal noch einen Ansatz ausprobiert, mit Python den in Python geschriebenen Algorithmus direkt in Microcode zu "compilieren", ähnlich wie MyHDL aus Python VHDL generiert. Lohnte aber vom Aufwand gegenüber der gelegentlichen manuellen Codierung nicht, das weiter zu verfolgen. Bei der Pipeline-Beschreibung wird es überdies haarig..
Könnte ich bitte etwas mehr zu dem Thema erfahren? Mir ist die Funktion nicht voll verständlich.
> Könnte ich bitte etwas mehr zu dem Thema erfahren? Zu Mikroprogrammierung? Sieh es als grosse Modellbahnanlage :) Bei der kannst du auch parallel überall Züge fahren lassen und steuerst (wenn die Anlage gut ist) die Weichen und Signale nicht alle einzeln, sondern über "Fahrstrassen" ("Kommandos von ... nach ..."), die schon einiges zusammenfassen. Der Kniff an der Mikroprogrammierung ist "nur", die gesamten Vorgänge und Datenflüsse erstmal sauber zu analysieren und zu strukturieren. Das sollte dann in einzelne Komponenten münden, die in jedem Takt per Kommando gesteuert werden. Die Kommandos können stark gepackt mit wenigen Bit sein (mein Beispiel oben war sowas), aber auch aus vielen Einzelsteuerbits bestehen. Insgesammt ist es aber alles wieder ein Programm (-> einfach zu entwickeln), aber mit sehr viel parallel laufenden Kommandos und (meistens) sehr spezialisiert. Erfunden hat die MP Maurice Wilkes, leider schon tot. Das Gegenstück ist die feste Verdrahtung von solchen Abläufen. Die ist zwar schneller und braucht weniger Logik, die Entwicklung ist aber schwieriger. Links http://de.wikipedia.org/wiki/Maurice_V._Wilkes http://de.wikipedia.org/wiki/Mikrobefehl Es gab von AMD und Motorola auch mal ICs zum Aufbau eines "eigenen" Spezialprozessors basierend auf MP, die sog Bitslice-Chips. Jeder Chip konnte 4Bit, und mit etwas drumherum war die Custom-CPU fertig. Bei AMD waren das die 29xx-Chips. Hier mal ein Beispiel für die Lehre: http://www.lrr.in.tum.de/~eti/Vorlesung/WS1213/Informationsmaterial/mimaschine.pdf
Hab mir das Wiki mal angetan, so richtig durch bin ich nicht, damit. Bräuchte wohl mehr Beispiele.
Ein konkretes Beispiel hätte ich: Angenommen, eine CPU-Implementation hat keinen Hardware-Divider, aber einen Divisions-Befehl. Da gibts nun folgende Möglichkeiten: a) Der DIV-Befehl schmeisst eine Exception, springt in den passenden Event-Vektor und führt dort die Emulationsroutine aus. Nachteil: Der Nutzer muss dafür den entsprechenden Code dazulinken, mit Context-Save, usw. Vorteil: An der CPU-Implementierung muss nicht gedreht werden. b) Der DIV fungiert intern als Macro und spielt ein kurzes Microcode-Programm ab. Das kann die obige Emulationsroutine sein, da man aber für die ALU weniger Opcodes braucht, ist der Microcode deutlich kompakter und kann u.U. parallelisierende Opcodes für komplerexe Pipeline-Steuerung entwerfen. Nachteil: Das Entwerfen braucht Zeit. Vorteil: Das Design wird kompakter und der Nutzer muss sich nicht um die Exceptions kümmern und darauf achten, dass die Routine nicht reentrant aufgerufen werden kann. Ähnlich findet z.B. der Kontext-Save statt: Ein Befehl wie
1 | MOVE r0-r7, --(sp) |
(Speichere r0-r7 auf dem Spack) dauert mehrere Zyklen und wird intern gerne mit Microcode erle(di)gt, wenn es davon mehrere Varianten gibt. Das Prototyping geht mit MC sehr schnell, da man das MC-RAM auf dem FPGA beschreibbar implementieren kann, d.h. zur Laufzeit den MC updaten kann. Hoffe, das war einigermassen anschaulich. Grüsse, - Strubi
Ok, sieht mir aus, wie ein eingeworfenes Stück Code: Wie verhält sich Microprogrammierung im Bezug auf RT-Fähigkeit / Unterbrachbarkeit für Multitasking?
Hallo Strubi, was du erzählst hört sich sehr interessant an. Strubi schrieb: > Der einzige Nachteil ist bei der Sache nur, dass der Aufwand, einen > einheitlichen und lesbaren Micro-Assembler-Befehlssatz ('Mnemonics') zu > definieren, etwas hoch ist. > Da aber der Microcode selten länger als 16 Wörter wird, kann man sein > Programm aber auch einfach mit Hilfe von VHDL records schreiben, zB wie > in diesem ROM-Programm: > constant program : program_t(0 to 7) := ( > > opcode_t'( OPA_VOM, A_ADDSUB, A_ADDSUB, > L(1), L(1), U(6), > OPB_NOP, "00", "0", > OPC_STA, I(3), I(7)), > opcode_t'( OPA_VOM, A_ADDSUB, A_SUB, > L(2), L(2), U(5), > OPB_VEM, A_ASSIGN, "0", > OPC_STD, I(0), I(4)), > > ... So ganz klar ist mir hier nicht wie die Opcodes in VHDL definiert sind. Handelt es sich bei OPA_VOM, A_ADDSUB... um Konstanten, die in der Datenpfad-Komponente wieder "decodiert werden"? Wie ist denn opcode_t bei dir deklariert? BTW: Gibt es zu dem Thema Microcode und VHDL auch Papers oder gute Webseiten, die das Konzept nochmal ausführlicher erklären? Danke, dito
> die das Konzept nochmal ausführlicher erklären? Schau dir doch einfach mal obiges lrr.in.tum.de-Dokument an. Das zeigt, wie man eine "richtige" CPU aus an sich sehr dummen Komponenten per Mikroprogrammierung zusammenbaut. > Ok, sieht mir aus, wie ein eingeworfenes Stück Code: Jein. Du bringst nur beliebig parallele Vorgänge in eine Struktur, die sich mit x Befehlen pro Takt darstellen lässt. Die "Befehle" sind aber meistens viel simpler als das, was eine "normale" CPU als Befehl so kann. Daher kommt das System ja ursprünglich auch. Man bildet einen komplexen CPU-Befehl über eine Abfolge von vielen/parallelen simplen HW-Steuerbefehlen ab. > Wie verhält sich Microprogrammierung im Bezug auf RT-Fähigkeit / > Unterbrachbarkeit für Multitasking? Falsche Baustelle, darum gehts hier nicht. Das sitzt, wenn überhaupt, "oben" drüber. Ausserdem muss man sich klar sein, dass mit Mikroprogrammierung eben nicht nur "normale" CPUs realisiert werden können, sondern alles, was irgendwie wie komplexer Automat mit Unterzuständen ist.
Georg A. schrieb: >> die das Konzept nochmal ausführlicher erklären? > > Schau dir doch einfach mal obiges lrr.in.tum.de-Dokument an. Das zeigt, > wie man eine "richtige" CPU aus an sich sehr dummen Komponenten per > Mikroprogrammierung zusammenbaut. Wie das funktioniert ist mir schon grundsätzlich klar. Mich würde aber interessieren wie man das konkret in VHDL implementiert, so dass ich das als Template verwenden kann.
dito schrieb: > So ganz klar ist mir hier nicht wie die Opcodes in VHDL definiert sind. > Handelt es sich bei OPA_VOM, A_ADDSUB... um Konstanten, die in der > Datenpfad-Komponente wieder "decodiert werden"? Wie ist denn opcode_t > bei dir deklariert? Genau, sind Konstanten. Der Opcode ist schlicht ein record, etwas gekürzt so:
1 | type opcode_t is record |
2 | a_op : unsigned(1 downto 0); --! Slot A opcode |
3 | a_mode_a : unsigned(1 downto 0); --! Slot A operation mode |
4 | a_mode_b : unsigned(1 downto 0); --! Slot A operation mode |
5 | ... |
6 | b_op : unsigned(1 downto 0); --! Slot B opcode |
7 | b_mode : unsigned(1 downto 0); --! Slot B operation mode |
8 | b_coef : unsigned(0 downto 0); --! Slot B coefficient index |
9 | |
10 | ... |
11 | |
12 | c_op : unsigned(2 downto 0); --! Slot C opcode |
13 | |
14 | .... |
15 | end record; |
E. M. schrieb: > Wie verhält sich Microprogrammierung im Bezug auf RT-Fähigkeit / > Unterbrachbarkeit für Multitasking? Wie Georg schon sagt, tut das hier nix zur Sache, weil es typischerweise für den CPU-Programmierer von aussen wie ein "atomischer" Maschinenbefehl ausschaut, der einfach eine gewisse Anzahl Zyklen braucht. Im Gegensatz zum emulierten Code (a), den du unterbrechen kannst, dich aber auch um das Retten des Kontext kümmern musst. Die MC-Version arbeitet so von Haus aus deterministischer, die Emulation - wenn sie Reentranz erlaubt - weniger. Beim eher komplexen Beispiel des Dividers kann es aber mit RT schon Probleme geben, wenn man ihn (im seriellen Optimierungsdenken) so in MC umsetzt, dass er eine variable Anzahl Zyklen fürs Resultat braucht. (Aber die Division sollte man in den Kernroutinen eh gegen eine HW-Multiplikation austauschen :-) ) Grüsse, - Strubi
Strubi schrieb: > ein "atomischer" Maschinenbefehl Das heißt im Deutschen dann "atomarer" Maschinenbefehl. Weil du allerdings Schweizer bist, darfst du weiterhin "atomisch" sagen: http://www.duden.de/rechtschreibung/atomisch Grüße in die weltbekannte "Hohle Gasse"... ;-)
Strubi schrieb: > Genau, sind Konstanten. > Der Opcode ist schlicht ein record, etwas gekürzt so: Okay Danke. So habe ich es mir auch vorgestellt. Wie kann man eigentlich Microprogrammierung mit Pipelining (darin liegt ja die Stärke von FPGAs) kombinineren? Ich kann pro Microcode-Zyklus z.B. nur genau eine Multiplikation machen. Sollte der Datenpfad aber eine Pipeline sein, könnte ich ja auch mehrere Multiplikationen direkt hintereinander durchführen. Dazu müssten ja dasselbe Mikroprogramme jeweils um einen Takt versetzt mehrmals abgearbeitet werden, oder?
> Wie kann man eigentlich Microprogrammierung mit Pipelining (darin liegt > ja die Stärke von FPGAs) kombinineren? In dem man die Verschiebung von Hand unter der Berücksichtigung der Latenzen macht, das erschwert aber Verzweigungen. Ich habe vor gut 12 Jahren eine 32pt-FFT mit Radix-2 Kern auf einem Spartan 2 ohne HW-Multiplier gemacht. Da dauert die Multiplikation 6 Takte. Zusätzlich mit RAM-Addressierung, Double-Buffering und heftigem Pipelining, damit das Ding 130MHz schaft, sieht das dann aus, wie angehängt. Da sieht man die Verschiebung sehr deutlich (wenn man einen Editor mit Monospaced-Font hat). Ist auch Mikroprogrammierung, der Sequencer ist halt völlig weggefallen. Es werden wie beim mechanischen Klavier mit Lochstreifen nur linear die Ausgänge angesteuert. Aber das Programm ist eben als Text beschreibbar und wird auch erst nach FPGA-Start reingeladen.
Hochinteressantes Thema. Sollte man aber mal einen eigenen thread aufbauen, da die Mico Code Programmierung offensichtlich das Gegenteil des Themas darstellt.
Ralf schrieb: > Habt ihr mal das gelesen? > Beitrag "FPGAs grafisch programmieren - eine Analyse" Nun, das bezieht sich ausschliesslich auf die Programmierung der FPGAs mit MATLAB. Das muss nicht bedeuten, dass es mit anderen Tools nicht besser wäre. Ehrlich gesagt glaube ich aber nicht, dass es jeh welche geben wrd.
Ralf schrieb: > Habt ihr mal das gelesen? Ja, soeben. Ist aber ganz schön von oben herab doziert, ohne die geringsten Begründungen für die Behauptungen. OK, bezieht sich auf Matlab, was mir ohnehin schnurz ist. Wenn man es auf die ordinäre Schematics-Eingabe von Xilinx beziehen würde (ja, würde), dann wäre das alles kompletter Quatsch, angefangen von den überzogenen Übersetzungszeiten bis hin zur angeblichen Gruppenuntauglichkeit. Insgesamt kommt mir der Beitrag ein bissel vor wie am Thema vorbeischimpft. Laß ihn in Frieden ruhen. W.S.
W.S. schrieb: > angefangen von den überzogenen > Übersetzungszeiten bis hin zur angeblichen Gruppenuntauglichkeit. Nun ja, teamtauglich ist die Grafikeingabe per se sicher nicht. Wie willst Du denn sowas pflegen? Wenn Code auch immer wieder komplett neu erzeugt wird, ist es auch Essig mit automatischer Erweiterung im Zuge von Zusammenführungen von Projekten. Daher muss dort sehr stark modulartig gearbeitet werden, wobei die Frage bleibt, wie zwei Designer ihre Teildesigns ineinander einbringen können.
W.S. schrieb: > Wenn man es auf die ordinäre > Schematics-Eingabe von Xilinx beziehen würde Darf ich daraus schlussfolgern, dass Du die Grafikeingabe über ISE Schematic als akzeptabel einstufst?
Ich hab den graphischen Entwurf von digitalen Systemen nie ausprobiert, aber wo ich denke, dass er vielleicht eine Hilfe oder sinnvoll sein könnte, wäre bei komplizierten Reglerimplementationen auf einem FPGA. Einen Regler designen funktioniert z. Bsp. in Matlab/Simulink sehr gut, ebenfalls Simulations und Verifikations, weil man gleich noch die Regelstrecke modellieren und hinten ran klatschen kann. Ich versteh zwar etwas von Reglerentwurf bishin zu nichtlinearen Reglern, aber zum Beispiel die Übersetzung eines kontinuierlichen Systems in ein diskretes System mit eine bestimmten Frequenz, wäre jetzt aufwendig für mich ( -> nicht ohne viel Rechere und Einarbeitung möglich). Ebenso wäre es aufwendig aus der zeitdiskreten Darstellung eine Übersetzung in ein hardware-nahe Implementierung zu entwickeln. Soweit ich weiß macht das Matlab alles automatisch. Gut wenn man nicht nur im allgemeinen Reglerentwurf sondern auch im Übergang zu zeitdiskreten Systemen und vllt auch noch in der Hardwareimplemtierung der gleichen, gut bewandert ist, würde man Matlab/Simulink nur noch für den Reglerentwurf benutzen und nach der Verifikation, aus den Ergebnissen seinen eignen HDL-Code schreiben. Aber für alle nicht Allround-Super-Talente, könnte in diesen Fällen die graphische Entwicklung hilfreich sein.
Trundle Trollkönig schrieb: > Soweit ich weiß macht das > Matlab alles automatisch. Das deklariert die Firma Mathworks auch so. Die Realität sieht aber so aus, dass Matlab nicht weiss: - ob ein Filter sequenziell, parallel oder teilparallel implementiert werden muss, da dies von Wiederverwendbarkeit des Codes, Verfügbarkeit von Cores, Randbedingungen der FPGA-Resourcen, der Taktrelation / Bandbreite und dem Restdesign etc abhängt. - wie breit die Vektoren sein müssen, weil man das nirgendwo als constraint festlegen kann, sodass es MATLAB automatisch und designweit berechnen könnte, was dem Prinzip nach ja sehr leicht wäre Praktisch wirft MATLAB nur ein VHDL Codestück aus (HDL Coder) das man weiter verarbeiten muss, während aus Simulink nichts anderes rauskommt, als das, was man haarklein eingeben hat. Dass es grafisch eingegeben wurde, hat keinen Vorteil.
Was mich jetzt mal konkret interessieren würde, wäre die Zahl der user, die regelmässig grafisch arbeitet, sei es mit LABVIEW, MATLAB oder welchem tool auch immer. Ist das wirklich nur eine Minderheit?
Ich würde sagen, es ist eine wachsende Minderheit, weil die alten Hasen, die nur schwarz programmieren, immer mehr aussterben und das Klickibunti-Gehabe sich in der EDA-Welt immer weiter durchsetzt. Für die Facebook-Generation ist das einfach attraktiver. Die meisten fangen damit an und einige bleiben dann dabei. Was die FPGA-Hersteller da vielfach aber anbieten, würde ich getrost zur Seite lassen. Halbgare Strategien und unvollständige Realisation. Es wird ja auch nicht richtig vorangetrieben! Die Hersteller selber glauben offenbar auch nicht an den Erfolg ihrer Symboleingabe. Hat es in jüngster Vergangenheit irgendwelche grösseren Änderungen in der ISE oder ALTERA gegeben? Das sieht so hässlich aus, wie eh und jeh und ist einfach nur grottenschlecht zu bedienen. Da Linienmalen nervt und erinnert mich vom design her irgendwie an das frühe Windows-SPICE. Allenfalls ein Dritthersteller könnte sich damit etbalieren, wenn er was Gutes brächte. Ansonsten stimme ich der Fraktion der Schreiber hier zu, welche die grafische Darstellung der Zusammenhänge postulieren. Das Hirn merkt sich solche Übersichten einfach viel besser, als reinen Text.
Ralf schrieb: > Was mich jetzt mal konkret interessieren würde, wäre die Zahl der user, > die regelmässig grafisch arbeitet, sei es mit LABVIEW, MATLAB oder > welchem tool auch immer. Ist das wirklich nur eine Minderheit? ok, dann oute ich mich mal. Ich habe schon mit Labview FPGAs gemacht. Es waren einfache Designs, aber die Durchführung war mit Labview eben auch einfach und hat bis auf Kleinigkeiten gut funktioniert.
FPGA-Vollprofi schrieb im Beitrag #3370453: > Ich würde sagen, es ist eine wachsende Minderheit, Ach, das ist schon ein bissel Balsam auf meine Seele. Unsereiner benutzt programmierbare Logik nur dann und dazu, wo es technisch sein muß - und weil sowas ohne Programmierung nicht funktioniert, muß das also auch irgendwie erledigt werden. Aber das ist eben nur ein klitzekleiner Nebenaspekt des Berufslebens und nicht die Hauptsache. Deshalb investiert man nur eine kleine Portion Gehirnschmalz in das Erlernen von verknöselten HDL's - und es muß trotzdem funktionieren. Da tun sich verständlichermaßen gewaltige Unterschiede auf zwischen jemandem, der quasi nur Gelegenheits-Logik-Programmierer ist und Leuten, die tagtäglich nur dieses und nix anderes machen. Man würde ja solche Leute als Dienstleister nehmen, wenn da nicht einige Hinderungsgründe unterschiedlichster Art wären. Aber so muß man's eben selber machen und da ist sowas wie Schematics eben immer noch das Geeignetste - allen Widrigkeiten mit den existierenden elenden Editoren (egal von welchem Hersteller) zum Trotz. Nebenbei gesagt, halte ich grafische Logikprogrammierung (egal ob für CPLD oder FPGA) vom Prinzip her für weitaus angemessener als das Schreiben von ellenlangen Programmtexten in unbequemen Sprachen. Früher hatten wir nichts außer der puren Kommandozeile, dem Stand der Technik war's geschuldet. Wir leben aber nicht mehr in der Computersteinzeit, haben RAM, Festplatten und Gigahertzschnelle Prozessoren bis zum Abwinken und da sollte eigentlich die Software, insbesondere die Tools zum Entwerfen und Entwickeln eigentlich irgendwann mal nachziehen. Unsere Leiterplatten konstruieren wir ja auch grafisch mit Schematics und Layout - und nicht per Leiterplatten-HDL. W.S.
W.S. schrieb: > Wir leben aber nicht mehr in der Computersteinzeit, haben RAM, > Festplatten und Gigahertzschnelle Prozessoren bis zum Abwinken und da > sollte eigentlich die Software, insbesondere die Tools zum Entwerfen und > Entwickeln eigentlich irgendwann mal nachziehen. Naja, darum gehts solchen (fast) Vollzeit-HDLern wie mir aber nicht. Klar sind die in der Lage auch einen Schaltplan in FPGA zu übersetzen und zu optimieren. Aber wenn man das nicht nur nebenbei macht, stehen Sachen wie Versionskontrolle, Simulierbarkeit, Wartbarkeit, Wiederverwendbarkeit und Austauschbarkeit ganz weit oben auf der Prioritätenliste. Und wenn man sich mal einige Zeit mit HDL beschäftigt hat, merkt man erst, was es doch für wunderbare Konstrukte gibt, die einem das Programmieren wesentlich erleichtern, in Schematic hat man da keinen oder kaum Zugriff. Aber wie du schon sagst, das ist meist bei den Vollzeit-FPGA Designern anzutreffen. Um mal schnell ein Design hinzuklatschen, wovon es nur eine Version gibt, nur einer schaut rein, was nicht simuliert wird und auch nur in einem Zielbaustein ist, braucht man vielleicht nicht unbedingt eine HDL. Allerdings wirds ab einer bestimmten Größe da auch irgendwann komplett unübersichtlich.
W.S. schrieb: > Unsereiner benutzt programmierbare Logik nur dann und dazu, wo es > technisch sein muß - und weil sowas ohne Programmierung nicht > funktioniert, muß das also auch irgendwie erledigt werden. Wer benutzt programmierbare Logik denn sonst? Setzen denn nicht alle sowas nur ein, wenn muss? Die Frage ist doch nicht, wieviel FPGA setzt man (unnötigt) ein, sondern wie kriege ich das design am schnellsten und sichersten hin. Ich glaube nicht, dass das eine Frage des Bearbeiters und seinen Absichten ist. Eher schon hat es was mit design Grösse zu tun.
M. Fritsch schrieb: > Ich glaube > nicht, dass.. Ähem.. naja der Glaube fängt dort an, wo das Wissen aufgehört hat. Aber mal im Ernst: Es gibt nen Riesenunterschied zwischen Leuten, die sowas tagtäglich als ihren Broterwerb machen und anderen, die eigentlich was ganz anderes machen und sich dann für ein Gerätedetail überlegen, ob sie die Sache mit nem Controller, nem DSP oder nem FPGA (oder mit sonstwas anderem) machen - und im vorletzteren Falle, ob sich das insgesamt rechnet, ob es von einem selbst stemmbar ist und so. Die Frage ist für unsereinen keineswegs "wie kriege ich das design am schnellsten und sichersten hin", siehe oben. Dein Standpunkt sieht eher so aus, daß dein Chef ankommt und dir ein Design vorgibt. Ist bei mir ganz anders, die Richtung gebe ich selbst vor. Vielleicht ist dir meine Sichtweise jetzt etwas deutlicher geworden. W.S. (der heute EIGENTLICH nur zur Entspannung hier reinschauen wollte)
Wenn ich Deinen Standpunkt richtig auffasse, bist Du der Ansicht, dass die grafische Programmierung also für die Nicht-Vollzeit-FPGA-Entwickler die effektivere ist?
Ja. Wer Schaltungstechnik kann (was ich hier schlichtweg voraussetze), der kann auch mit Schematics und symbolischen Bauteilen richtig umgehen. Wenn man dann noch gelernt hat, Schaltungsteile zu Blöcken zusammmenzufassen und Busse zu kreieren, dann wird das ganze recht effektiv. Wirklich uneffektiv wird die Sache genau dann, wenn man mit einer HDL arbeiten will und deshalb alleweil im Kopf zwischen verschiedenen Programmiersprachen umschalten muß. Da kommen dann nicht nur Formfehler en masse auf, sondern man rennt regelmäßig vor die Wand, weil die Realisierung eines Details (wie vergleiche ich hier ne Zahl mit ner anderen..) anders ist. Mach doch mal nen Test bei dir: Am gleichen Vormittag ein schlichtes CPLD per VHDL, eine µC Firmware mit C und ein Bedienprogramm auf dem PC für nen MAC mit RAD-Studio in Pascal. Und zwischendurch Kunden am Telefon. Ach ja, und emails von Kunden, denen was nicht paßt ("top urrrrrrrrgent.." W.S.
W.S. schrieb: > Am gleichen Vormittag ein schlichtes > CPLD per VHDL, eine µC Firmware mit C und ein Bedienprogramm auf dem PC > für nen MAC mit RAD-Studio in Pascal. Auf den ersten Blick bin ich versucht zu sagen: WOW! Welch ein Power-Man. Was Du da beschreibst, ist aber nur Einzelkämpfertum und noch dazu in einer so argen Form, die ich das nur als >Hacken< bezeichnen kann. Wenn Du so arbeitest, möchte ich nicht die Ergebnisse sehen, oder sowas beauftragt haben. Ein einziger Vormittag reicht i.d.R. gerade aus, um ein Konzept für das PLD zu verfassen und die requirements zu formulieren. Ein Vorschlag: Warum schreibst Du nicht beide Stück Software in Turbopascal? Oder besser alles in C, das liesse sich auch aufs FPGA übertragen. (Pickoblehs, oder wie der heisst). Dann hast Du nur eine Programmiersprache.
Projektleiter schrieb: > Was Du da beschreibst, ist aber nur Einzelkämpfertum Haha :) schreibt der, der sich "Projektleiter" nennt. Lieg bestimmt falsch, aber was ich aus deinen Zeilen lese ist genau das bes******ne : "Ich hab zwar nur ne grobe Ahnung von der genauen Vorgehensweise weil ich BWL/WING studiert hab, aber dafür kann ich ja alles deligieren" . So wirds dann auch gemacht. Ein armes Schwein muss die Anweisung erfüllen, dabei noch fünf andere Sachen wie Telefonieren erledigen und wenn alles fertig ist, ist der "Projektleiter" stolz, dass er das alles so schön geschafft hat.
Hm, versteh da das Problem nicht. Ich beschreibe die FPGAs ja auch in VHDL, mache nebenbei etwas Software in C++/MFC zum Testen, schreibe automatisierte Testprogramme in Python und die Ausgabe in Latex, und auch mal einen µC in C. Außerdem den Schaltungsentwurf für alles, was um das FPGA herum kommt. Ich hatte da noch keine Probleme mit der "Umschaltung" im Kopf. Aber gut, jedem das seine.
Dein Nick ist ja auch nicht umsonst SUPACHRIS ;). Nicht böse nehmen, soll keine Angriff sein nur Spaß! Mal im ernst ich mach das ähnlich wie chris. Nur das es bei mir nicht VHDL sondern Verilog ist und naja sein wir ehrlich automatisierte Testbench Python... ne das kann ich net... da kommen immer selbst geschriebene billig Testbensches raus die dann, Stück für Stück erweitert werden. Und Applikationssoftware gibts auch net (nicht von mir).. nur C für µC und das ziemlich kreplig.. Latex wäre toll aber ist hier auf Arbeit net gern gesehen, alles Ofiicescheisse. Das Umschalten ja das braucht auch bei mir ein bissel, aber ich versuche auch nicht jeden Tag 5 mal zwischen µC und FPGA zuwechseln. Mehr so Woche für Woche. Und Eagle-Krams versuch ich so gut ich es kann an andere abzuschieben... nur wenn es sein muss mach ich das... da krieg ich immer rote Augen und Kopfschmerzen von.
Naja, C++ für "Anwendung" mach ich nur nebenbei, um mit kleinen Programmen low-level ohne API auf meine FPPGA Designs zuzugreifen und die zu testen. Die richtigen Anwendungen und APIs macht dann die Software-Entwicklung in C#. Da versteh ich auch nur das Grundlegende. Lambda und Co sind mir da schon zu abstrakt. Testbenches schreib ich auch in VHDL, aber um unsere Hardware nach Normen zu testen, benutze ich Ironpython, was die .NET API anspricht und für die Protokolle LaTex Code generiert. Schaltungsentwicklung für kleine Testplatten mach ich komplett in Eagle, das richtige Zeug macht der Kollege in Pulsonix, ich arbeite dann auf Papier zu. Aber wenn man einmal richtig Algoritmik und eine strukturierte Programmierspavhe gelernt hat, dann kann man doch sehr vieles sehr schnell lernen.
Ich kann nicht erkennen, wo das Problem bez der Sprachen liegen soll. Gerade dann, wenn einer doch andere Hochsprachen kann, sollte das bissl VHDl doch einfach sein. Grafikeingabe ist was für hardcore-Hartwerker, die keinen code verstehen. Die basteln sich dann eine Rechnerstruktur mit Addierern und Multiplierblöcken.
FPGA-Vollprofi schrieb im Beitrag #3391720: > Ich kann nicht erkennen, wo das Problem bez der Sprachen liegen soll. Vermutlich, weil du es nie selbst erlebt hast. (Nichts ist zu schwer für den Mann, der es nicht selbst tun muß). Gut Nacht, du "FPGA-Vollprofi" W.S.
DerDieDas schrieb: > Haha :) schreibt der, der sich "Projektleiter" nennt. Lieg bestimmt > falsch, aber was ich aus deinen Zeilen lese ist genau das bes******ne : > "Ich hab zwar nur ne grobe Ahnung von der genauen Vorgehensweise weil > ich BWL/WING studiert hab, aber dafür kann ich ja alles deligieren" Ja, Du liegst falsch. Erstens würde ich, wenn überhaupt, etwas del*e*gieren und zweitens besteht meine Funktion nicht darin, Arbeit weiterzutreten, sondern vielmehr dafür zu sorgen, dass Entwickler sich a) nicht im Gebastel verfranzen und b) effektiv arbeiten. Dazu gehört, ihnen, so nötig, auch das Herumspielen mit Grafikprogrammen abzugewöhnen, wenn ich den Eindruck gewinne, dass diese ineffektiv sind. Mein Einwand an Deinem Arbeitsbeispiel besteht darüberhinaus darin, dass Du nur das Umsetzen einer Entwicklungsaktivität als das Tagesgeschäft darstellst. Du unterschlägst damit 80% der Realität, denn diese Umsetzung ist bestenfalls 1/5 des Tuns. Das was Du da machst, ist und bleibt eine ausnahmeweise Einzelaktivität und ist nicht repräsentativ.
Zu Deinem Einwand bez BWL: Ja ich habe ein Zweitstudium in BWL absolviert, um mich weiter zu qualifizieren und meinen Job im Projektgeschäft gut zu machen. Dies habe ich getan, nachdem ich über 12 Jahre in der Entwicklung tätig war, überwiegend im Bereich der embedded Software und Hardware.
Projektleiter schrieb: > Das was Du da machst, ist und bleibt eine ausnahmeweise Einzelaktivität > und ist nicht repräsentativ. Naja, ich kenne das auch von ganz kleinen Klitschen, mit kleiner 5 MA. Da wird das genauso zurecht gefrickelt. Entschuldigt meinen Ausdruck, aber mehr ist es leider nicht. Ich muss zugeben, ich hab genauso angefangen, weil mir ein älterer Kollege (der auch alles kann), das so gezeigt hat und ich so in die FPGA Schiene gekommen bin. Aber schon nach kurzer Zeit hab ich gemerkt, dass das ziemlicher Bastelmurks ist, komplexe Abläufe direkt per Schematic einzuhacken, und ich hab meine VHDL Kenntnisse aus dem Studium soweit vertieft, dass ich endlich effizient arbeiten konnte. Wahrscheinlich aus Faulheit, denn das HDL macht nach Absolvieren der zugegebenermaßen recht steilen Lernkurve viel weniger Arbeit als das rumgeklicker. Notepad++ als Editor mit Autovervollständigung und los gehts! Mit so einer "Ich kann und mache alles" Arbeitsweise kommt man halt nie über einen gewissen Grad heraus und ist nebenbei noch ziemlich ineffizient.
Christian R. schrieb: > dass das ziemlicher Bastelmurks ist, komplexe Abläufe direkt per > Schematic einzuhacken Ja, da muss jeder selber drauf kommen. Mir wäre auf jeden Fall noch ein zusätzliches Schaltplaneingabeprogramm mit nochmal extra Bibliotheken zuviel Gelecke. Deshalb mache ich vom Toplevel an alles was mit FPGA und CPLD zu tun hat (soweit wie möglich) in VHDL.
W.S. schrieb: > FPGA-Vollprofi schrieb im Beitrag #3391720: >> Ich kann nicht erkennen, wo das Problem bez der Sprachen liegen soll. > Vermutlich, weil du es nie selbst erlebt hast. > (Nichts ist zu schwer für den Mann, der es nicht selbst tun muß). > Gut Nacht, du "FPGA-Vollprofi" > W.S. Warum sollte ich das nicht "erlebt" haben? Die meisten FPGA-Entwickler müssen auch verfizieren, mit Scripten umgehen und gfs noch Funktionen in MATLAB checken. Damit sind sie in wenigstens 3 unterschiedlichen Sprachen unterwegs. Diejenigen, die noch mit SYSTEM-C und Ähnlichem arbeiten, kennen gar nichts anderes, als Sprachen und sind täglich in ihrem Aufgabenbereich am Umschalten.
Lothar Miller schrieb: > Christian R. schrieb: >> dass das ziemlicher Bastelmurks ist, komplexe Abläufe direkt per >> Schematic einzuhacken > Ja, da muss jeder selber drauf kommen. Mir wäre auf jeden Fall /noch/ > ein zusätzliches Schaltplaneingabeprogramm mit nochmal extra > Bibliotheken zuviel Gelecke. Das ist ein guter Punkt! Ich denke da an ein ganz bestimmtes Tool, mit dem ich mich mal abkämpfen durfte: Riesen-Biblio mit weitgehend allen Teilen, weitgehend gut gefplegt und weitgehend fehlerfrei :-) dafür aber mit pseudo-künstlerischem Anspruch: Beim Ablegen eines Multiplexers für Busse auf das Sheet z.B. wurde eine ganze Batterie an lustigen Pfeilen mit variablen Krümmungen und Stärken auf das Papier gezaubert, wo sich der Programmierer wochenlang dran abgearbeitet haben dürfte. Was auf den ersten Blick als eine ornamentartige Verifzierung des Schaltplans anmutete, entpuppte sich dann später, wenn man etwas ändern wollte, als Sondermüll, bei dem oft jedes einzelne Grafikelement auch einzeln wieder entsorgt werden musste, um das Signal als solche komplett zu entfernen. Wehe es blieb irgendwo ein kleiner Punktförmiger Rest: Der wurde dann dynamisch mit später verlegten Signalen verbunden, wodurch teilweise ungewollte Verbindungen entstanden, oder er behinderte durch seine Exsitenz die Signalbenennung. Zudem hatten die Pfeile ein oft unvorhersehbares Eigenleben, beim Verschieben. Zu diesem hier wieder zu beobachtenden Vorgehen, logische Verbindungsinformationen aus gemalten Grafiken abzuleiten, statt umgekehrt, hatte ich schon mehrfach in Foren Stellung genommen: Ich halte das für einen grundsätzlichen Denkfehler! Ein grafisches Tool zur Eingabe eines Datenflusses bedürfte überdies nicht zwangläufig irgendwelcher umfangreicher Bibliotheken auf Schaltplanniveau, sondern nur einer einzigen Art von Objekt: Einer flexiblen, dynamischen, grafischen Repräsentation einer entity, der man per Text-Referenz ein VHDL-file oder einen VHDL-Wrapper für Cores zuordnen kann. Die Signalanschlüsse und die Namen der Signale blieben dynamisch. Verknüpft würde per link und nicht per Linie. Die Linie würde dann aus der Verbindung abgeleitet, siehe oben. Nur eine solche Struktur liesse es zu, die einmal geknüpften Verbindungen wieder neu zu hierarchieren und Objektgruppen neu zu bilden oder anders zu ordnen. Dann könnte man eine Gruppe von Objekten selektieren und mit einem "encapsule" Befehl bündeln (wie beim Excel-Zeichnen / "Gruppieren") und dynamisch (also reversibel!!!) eine Hierchiestufe tiefer schicken. Die Innereien wären durch ein "visibility"-tag zu verbergen und die so generierte Gruppe dynamisch im design verknüpft, womit sie beliebig instanziierbar ist, wie Datenbankelemente und Verweise in mehrdimensional verketteten Listen. > Deshalb mache ich vom Toplevel an alles was > mit FPGA und CPLD zu tun hat (soweit wie möglich) in VHDL. So isses. Das tun die meisten.
:
Bearbeitet durch User
Tach, ich verstehe ja die Motivation der Grafikfans irgendwo. VHDL ist für mich quasi die formaljuristischst korrekte unter den Programmiersprachen (ich sag' jetzt mal bewusst "programmieren"), aber dementsprechend auch was für Advokaten. Manchmal bleibt wirklich der Gedanke der HDL auf der Strecke und es artet in programmatische Aspekte auss, sobalds um extensive Testbenches geht. Die geforderte "Verbosity" (Geschwätzigkeit, würde ich auf deutsch sagen) nervt bei VHDL ab und an auch. Zum Labview-Ansatz wurde glaube ich schon alles gesagt, ich würde nur noch gerne einige weitere Aspekte reinbringen. Also, ausgehend vom Kernproblem "Wie entwickeln wir effektiver, schneller, dennoch robust, wiederverwertbar, typensicher und fehlerfrei" habe ich für mich folgende Hilfsmittel entdeckt: - XML: Kann man prima als Beschreibungssprache für Interfaces verwenden. Da gibt es eine Menge (z.B. IP-XACT oder netpp/DCLIB) was man beliebig mit eigenen Stylesheets in VHDL verwandeln kann. Einen neuen UART auf dem SoC instanzieren ist dann faktisch ein neuer 'device'-Knoten im XML-Tree, der so Sachen wie eine Base-I/O-Adresse enthält - MyHDL: Gibts hier irgendwo nen detaillierteren Thread zu, im Prinzip ist das nur eine Python-Library, die mehr oder weniger gut ein Design in VHDL oder Verilog konvertiert. Simulation und Testbenching ist damit optimal, die Konversion allerdings etwas 'quirky' und nicht ganz zuende gedacht, aber egal, es ist recht robust. Gibt auch noch andere Ansätze wie die migen-Toolbox. Den Python-Ansatz mag ich von der Leserlichkeit und Kompaktheit einfach sehr gut. Aber hat u.U. einem gut doxygenisierbaren VHDL-Code nicht immer etwas entgegenzusetzen :-)
Strubi schrieb: > ich verstehe ja die Motivation der Grafikfans irgendwo. Naja, "FAN" würde ich nicht dazu sagen. Eher "notgedrungen". Gründe dafür siehe weiter oben. Es könnte alles so schön und gut sein, aber es ist wohl wie mit der Schlange, die sich in den Schwanz beißt: völlig veraltetes Schematics, User die das schlecht finden und sich abwenden, keine Verbesserungen bei Schematics, noch mehr abgewendete User... Für mich sieht das ganz klar aus wie die Wendeltreppe in den Elfenbeinturm aus. Nun ja, es geht schon aufwärts damit, aber eben immer weiter in den Elfenbeinturm. Schaut euch doch mal in diesem Forum um. Wie viele technische Lösungen werden auf ganz andere Weise realisiert und wie wenige werden mit CPLDs und FPGAs gemacht! Das geht sogar bis hin zum Verwenden eines Atmel AVR als Displaycontroller für Grafikdisplays. Die Leute kommen viel eher mit Controllern zurecht und lassen programmierbare logik weitgehend links liegen. Abstimmung mit den Füßen und basta. Hat einer von den HDL-Verfechtern eigentlich schon mal darüber nachgedacht? Die derzeit bei den üblichen Verdächtigen vorhandenen Schematics-Editoren sind gräßlich, jeder weiß es. Aber keiner kommt auf die Idee, deren Herstellern mal zu sagen "tut endlich was". Stattdessen kommen HDL-Fans daher, die nicht müde werden zu betonen, daß sie ja grundsätzlich nur ne HDL benutzen und den Rest der Welt verachten. So wird das nie was. W.S.
W.S. schrieb: > Die Leute kommen viel eher mit > Controllern zurecht und lassen programmierbare logik weitgehend links > liegen. Abstimmung mit den Füßen und basta. Hat einer von den > HDL-Verfechtern eigentlich schon mal darüber nachgedacht? Ist ja logisch, dass das so sein muss, weil die ihre AVRs grafisch programmieren. :-)
W.S.: für mich gibt es einfach drei bis vier schlagende Argumente, die auch schon mehrfach genannt wurden, warum das mit den grafischen Tools so schlecht in der Realität klappt. Und das sind wohl auch die Argumente, warum viele gute Ansätze (schon vor >10 Jahren) im Sand versunken sind: - Eine Testbench verlangt eine Sprache - Eine Zertifizierung verlangt eine Coverage - Ein Bug-Fixing verlangt Revisionskontrolle und Zuordnung zu einem Autor - Der Kunde verlangt alle obigen Punkte und eine gewisse Sicherheit Deswegen ist eine simple Sprache, so beschissen geschwätzig sie auch ist, der beste durchsetzbare und diskutable, selbst-zertifizierende Standard was die obigen Punkte betrifft. Das oben auf grafischem Wege umzusetzen und zu standardisieren, dürfte ein Ding der Unmöglichkeit sein. Besser, man lässt einen halbgaren Schematics-Editor beim nächsten grossen Release in peinlichem Schweigen verschwinden...
Interessierter Mitleser schrieb: > Was ist z.B. mit denen, die sich hier zu Wort gemeldet haben? Sind > Lothar Miller, Jürgen Schuhmacher, Michael S., Mark Fritsch, die sich > tendentiell gegen die Grafikgeschichte aussprechen, alles > Scheuklappenentwickler? Ok, den Labviewhasser und den > Labviewbeführworter Falk lassen wir mal dahingestellt, scheinen Extreme > ihrer Art zu sein. Alter, auch wenn's schon 'ne ganze Weile her is: mach mal halblang. Der Threaderöffner fragte explizit nach einer Möglichkeit, FPGAs grafisch zu programmieren. Und neben der Möglichkeit, Schematics in der ISE reinzukloppen gibt es da eben die Möglichkeit von Labview. Wer absolut noch nie ein FPGA-Design erstellt hat, aber mal grob ein Feeling für den Ablauf eines CAE-Entwurfsvorgangs kriegen möchte - für den ist LabView nicht schlechter als andere Tools und vielleicht noch 'ne Spur eingängiger, gerade wenn man in Richtung Rapid-Prototyping denkt. Dass man für komplexe FPGA-Projekte mit 'nem Spartan-3e-Starterkit und LabView nicht unbedingt die richtige Wahl seines Werkzeugs trifft, sondern diese Wahl anhand den vorliegenden Anforderungen treffen sollte, müsste eigentlich jedem klar sein. Zum Reinschnuppern in die FPGA-Thematik: warum nicht? Das Spartan-Board kostet nicht die Welt und für 'ne einfache Datenerfassung vom ADC, grafische Auswertung und Ausgabe auf'm DAC reicht's doch aus. Ich vergleich's mal mit normalen Programmiersprachen: Warum programmiert in der Windows-Welt alle Welt .NET und nutzen unter Linux z.B. Python oder Java? Weil es gewisse Abstraktionen bieten, die es einem vereinfachen sein Ziel zu erreichen. Versteh mich nicht falsch: ich bin hauptberuflich C++-Programmierer im Embedded-Bereich, also wahrlich kein großer Klickibunti-Fanatiker und somit schon etwas Leid gewohnt. Daher finde ich es mitunter durchaus erfrischend, Werkzeuge auszuprobieren bzw. anzuschauen, die einem für einfache Sachen die Arbeit erleichtern können - dabei aber unter Umständen Möglichkeiten nehmen. Gerade was die Dotties z.B. an softwaretechnisch sauberen Konstrukten in ihrer Punktsprache haben, lässt einem als C++-Programmierer mitunter (bezogen auf die Wartbarkeit der Projekte, ABI-Stabilität, usw. usf) schon manchmal die Tränen in die Augen treiben - dieser Zucker kostet sie halt Performance. Und so isses mit LabView, FlowCode, Arduino und wie sie alle heißen ebenso. Andererseits ist die Argumentation, erstmal was zu verstehen (im Sinne von Kopp einschalten) und dann zu programmieren auch nicht abwegig. Wenn man manchmal hört, wie manche mit ihren leicht verständlichen Werkzeugen sich auf die Schulter klopfen - na ja, aber dafür gibt's die ja. Wer mehr will, fängt halt mit den klassischen HDLs an, schlägt sich mit synthesefähigen und nicht-synthesefähigen Beschreibungen herum, simuliert funktional und zeitbehaftet und optimiert sein Design bis es die Anforderungen erfüllt. Kostet mehr Lehrgeld und ist auf Dauer wertvoller. Das werden die Leute aber dann merken, wenn sie die Tiefe brauchen und diese nicht dann nicht da ist - deswegen die Werkzeuge zu verteufeln, bringt auch niemanden was. Die Erfahrung müssen die Leute aber selber machen. Als Fazit: Ich denke eher nicht, dass durch grafische Entwurfmittel eine Inflation der gelernten VHDL/Verilog-Coder stattfinden wird. Aber man hat's an Arduino bzw. am Raspberry gesehen: früher konnte man als 8-Bit-uC-Coder oder ARM-Programmierer sich noch was drauf einbilden, jetzt kann das jeder Schüler.
@Falk Schilling: Es wurde ja garnicht bestritten, dass ein Einstieg über Grafik möglich ist, wenigstens von mir nicht. Es wurde nur beigeflochten, dass die Tools, die zur Verfügung stehen (und ich schliesse hier Labview ausdrücklich ein) kaum dazu geeignet sind, kundenspezifische Entwicklungen zu treiben und dies eben nicht nur wegen der Limits nicht sondern eben auch und gerade wegen der Themen Versionierbarkeit, Prüfbarkeit und Analysefähigkeit nicht. Ob man es sich daher angewöhnen sollte, bleibt zu überlegen. Fürs heimische Labor und fliegende Testaufbauten mag es adäquat sein, o.k. Dann aber werden eingefleischte Testspezis sofort kommen und feststellen, dass auch Test- und Prüfaufbauten für FPGAs und andere Umgebungen standardmässig validiert und "zertifiziert" sein müssen. Auch ein solches System müsste ja den von Kunden und Normen geforderten Standards genauso genügen, wie das zu Testende selber- wenn nicht noch mehr! Daher bin ich eher bei Leuten wie Strubi, die XML und MyHDL als höhere Schicht anraten, um sich über das schnöde VHDL zu erheben, gleichsam aber Flexibilität und Zielhaftigkeit beizubehalten. Auch Du hast ja mit dem Argument "*.NET, Python oder Java" eine höhere Abstraktionsebene ins Spiel gebracht ud als vorteilhaft beschrieben. Das unterschreibe ich auch direkt, dass dies in vielen Fällen besser und zielführender ist, als sich basishaft in C/C++ zuverhaspeln. Aber: Die Nutzung all dieser Sprachen impliziert noch lange nicht die Verwendung von Grafik und/oder grafischen Eingaben und/oder Grafikbaukastensystemen. Den Schluss sehe ich defintiv nicht.
Noch etwas zu diesem Punkt: > Als Fazit: Ich denke eher nicht, dass durch grafische > eine Inflation der gelernten VHDL/Verilog-Coder stattfinden wird. Du meinst eine "Inflation der neuen Programmier-Experten neben den gelernten VHDL/Verilog-Codern". Das glaube ich auch nicht, denn eines darf man nicht vergessen: Die Grafik nimmt einem nur einen Schritt im gesamten Prozess ab, nämlich den des praktischen Codens. Planen, Denken, Verschalten und logisch richtiges Prüfen muss man dennoch. Die Grafik ersetzt einem 10% und vermeidet Tippfehler. Sie setzt einem aber einige Rahmen und verführt zu Interpretationen, wie dieser hier: > Aber man hat's an Arduino bzw. am Raspberry gesehen: > früher konnte man als 8-Bit-uC-Coder oder ARM-Programmierer sich > noch was drauf einbilden, jetzt kann das jeder Schüler. WAS kann der Schüler, wäre meine Frage: Ok, er braucht keinen AD-Wandler-Code mehr generieren, weil er ihn im Baukasten hat. Den hat aber jeder VHDL- und C-Coder auch im Baukasten und macht Copy-Paste. Wo ist der Vorteil? Was ist, wenn im Baukasten der 18 Bit-Wandler fehlt? Und was ist, wenn mit den Daten auch etwas gemacht werden soll? Ist im Baukasten auch der richtige Signalfilter drin? Welchen nimmt man? Wie fenstert man die FFT? Kann das der Schüler auch? :-) Die Grafik ersetzt etwas Codingaufwand. Mehr nicht. Im Grunde wird Softwareentwicklung für FPGAs und MCUs durch die Baukasten, die Cores und die open files nicht einfacher, sondern sogar schwerer, weil der Fokus vom einfachen Coden, was jeder Hansi erlernen kann, wegrutscht zum Datenmanagement, der geschickten Speicherung und Interpretation sowie der Algorithmik. Softwareentwicklung ist nicht gleich Coden! Gegenmeinungen? W.S. schrieb: > Schaut euch doch mal in diesem Forum um. Wie viele technische Lösungen > werden auf ganz andere Weise realisiert und wie wenige werden mit CPLDs > und FPGAs gemacht! Das geht sogar bis hin zum Verwenden eines Atmel AVR > als Displaycontroller für Grafikdisplays. Nun ja, es muss ja nicht unbedingt die Nutzung von FPGAs propagiert und verherrlicht werden. Dort, wo ein uC die Arbeit machen kann, ist seine Nutzung in den allermeisten Fällen ja auch angezeigt. Das Forum ist auch kein Massstab, denn es ist ein Microcotrollerforum. Dass hier die FPGAs in der Minderheit sind, ist forenspezifisch - wobei ich das auch nicht unbedingt so sehe: Gerade dieser Beitrag wie auch der Parallelthread "Tutorials" zeigt doch, dass die Controller-Spezis durchaus auf FPGAs wechseln und dies sogar in Anwendungen, wo dies nicht angezeigt wäre.
Falk Schilling schrieb: > Der Threaderöffner fragte explizit nach einer Möglichkeit, FPGAs > grafisch zu programmieren. Und neben der Möglichkeit, Schematics in der > ISE reinzukloppen gibt es da eben die Möglichkeit von Labview. kennt jeman dweitere?
Ich schreibe alles mit VHDL und wenn ich mir mal nicht sicher bin, was die Synthese mir da erzeugt hat, schau ich mir einfach den RTL-Schematic oder den Technology Schematic an. Ich mache es also eher umgekehrt. Erst textuelle Eingabe und bei Unsicherheiten gucke ich mir das graphisch an. in VHDL geht einfach vieles sehr schnell. Ein komplettes taktgesteuertes Schieberegister mit diversen Extras hat man mit ganz wenigen Zeilen hingetippt. Das geht so schnell, da hätte man graphisch sicher länger gebraucht. Man muss ja auch erstmal das passende Symbol heraussuchen und dann die pins anschließen usw... Zudem ist es auch immer problematisch, da man sich nicht sicher ist, was eigentlich in diesem Symbol dann drinn steckt. Handelt es sich wirklich um die geforderte Funktion? In VHDL hat man dann sicherlich eine klarere Definition vorliegen.
Angehängte Dateien:
-
Peakdetect.PNG
63 KB
Falk R schrieb: > Weiß daher jemand wo ein solches Tutorial zu > finden ist? Oder gibt es weitere Vorschläge zum Erlernen der > FPGA-Programmierung (möglichst grafisch)? XILINX Coregen ist dafür der Schlüssel. Using Graphical Loop Structures in LabVIEW FPGA http://www.youtube.com/watch?v=Frk16d6aP-c Fazit: Auskoppeln der Prozess-I/O-variablen von Modul -#1zu Modul#2 (Signal – WIRES ) Writing Your First LabVIEW FPGA Program http://www.youtube.com/watch?v=mv112V-P030 ######################################### Das hat mit bei meinem FPGA Peak Detector geholfen. http://www.ni.com/white-paper/3770/en/#toc3 http://www.ni.com/white-paper/5432/en/#top Fazit: Für den Proto-Typen Bau ist das ganz hilfreich. In wie weit das Graphical Object Box Konzept der Verkoppelung vom User verstanden wird...(Lern u. Erfahrungs-kurve). Genau wie bei PSOC von Cypress. Gruss Holger.
Markus Wagner schrieb: > Falk Schilling schrieb: >> Der Threaderöffner fragte explizit nach einer Möglichkeit, FPGAs >> grafisch zu programmieren. Und neben der Möglichkeit, Schematics in der >> ISE reinzukloppen gibt es da eben die Möglichkeit von Labview. > kennt jeman dweitere? Mentor HDL-Designer: http://www.youtube.com/watch?v=H9ktcisPaDo historisch: speedchart, statemate http://www.eis.cs.tu-bs.de/ackad/ Simulink+systemgenerator: http://www.ece.unm.edu/vhdl/Labs2004/summer04/lab07/lab08_tutorial.htm MfG,
>Mentor HDL-Designer: >Youtube-Video "MENTOR GRAPHICS HDL Designer - Getting Started Tutorial (HD)" mit dem hatte ich schon das "vergnügen", da hab ich ja doch erstmal mit Begeisterung angefangen zu klicken, aber das finden der zueinander passende Versionen von HDL-Designer, Modelsim und der FPGA-software, kam mir mit der Zeit dann in etwa so vor wie bei diesem Spielautomaten da: http://www.youtube.com/watch?v=iHFmcfem6kY Ändert einer z.B, Xilinx/Altera etc, seine Software, dauerts doch einige Zeit bis der HDL_Designer nachzieht und wieder ohne rumzuzicken spielt, brrrrr, nee nee nee, hoffentlich nie nie wieder!
Jürgen S. schrieb: > @Falk Schilling: > > Es wurde ja garnicht bestritten, dass ein Einstieg über Grafik möglich > ist, wenigstens von mir nicht. Es wurde nur beigeflochten, dass die > Tools, die zur Verfügung stehen (und ich schliesse hier Labview > ausdrücklich ein) kaum dazu geeignet sind, kundenspezifische > Entwicklungen zu treiben und dies eben nicht nur wegen der Limits nicht > sondern eben auch und gerade wegen der Themen Versionierbarkeit, > Prüfbarkeit und Analysefähigkeit nicht. Was diese Punkte betrifft, geb ich Dir Full-ACK. Ich bin auch nicht gegen Verilog/VHDL/SystemC/... eher im Gegenteil: die Ada-Anleihen von VHDL machen dies auch für mich zur ersten Wahl für professionelle Projekte, genauso wie der Aspekt des Test-Driven-Development gegen Testbenches. > Ob man es sich daher angewöhnen > sollte, bleibt zu überlegen. Fürs heimische Labor und fliegende > Testaufbauten mag es adäquat sein, o.k. Vielleicht hast du recht und man sollte neuen Entwicklern tatsächlich lieber einen Kurs für VHDL anbieten als grafisch zu programmieren. Andererseits - warum bauen Sebastien Bourdeauducq et.al. so einen Aufwand mit MiGen und Python (http://www.milkymist.org) - klar: just for fun und weil's funktioniert. Und grafisch programmieren - warum nicht: es geht und es funktioniert und wer das möchte, sollte das auch tun dürfen und können. Die Schattenseiten davon kriegen diejenigen dann schon selber früh genug raus. > Dann aber werden eingefleischte > Testspezis sofort kommen und feststellen, dass auch Test- und > Prüfaufbauten für FPGAs und andere Umgebungen standardmässig validiert > und "zertifiziert" sein müssen. Auch ein solches System müsste ja den > von Kunden und Normen geforderten Standards genauso genügen, wie das zu > Testende selber- wenn nicht noch mehr! Daher bin ich eher bei Leuten wie > Strubi, die XML und MyHDL als höhere Schicht anraten, um sich über das > schnöde VHDL zu erheben, gleichsam aber Flexibilität und Zielhaftigkeit > beizubehalten. Klar: so kann man auch abstrahieren. Aber denke mal bitte an den werten Nachwuchs: der RaspberryPi hat Scratch als grafische Programmiersprache drauf, weils todsimpel ist, damit 'ne LED zum blinken zu bringen. Das Teil kannste 'nem 10-jährigen in die Hand drücken und er kann ohne viel Mühe Erfolge erzielen. > Auch Du hast ja mit dem Argument "*.NET, Python oder Java" eine höhere > Abstraktionsebene ins Spiel gebracht ud als vorteilhaft beschrieben. Das > unterschreibe ich auch direkt, dass dies in vielen Fällen besser und > zielführender ist, als sich basishaft in C/C++ zuverhaspeln. Nur mal ein Beispiel: ich hab vor paar Wochen aus Spaß mal für Windows 'ne kleine Anwendung für die WIA2 geschrieben: sprich, Scannen vom Netzwerkscanner und das Dokument danach mal über 'ne OCR-Lib jagen. Mit .NET hat das ganze - obwohl ich hauptberuflich fast ausschließlich C++ für'n ARM oder Intel schreibe - dank Netz nicht mal 3 Stunden gekostet. Und das auch nur, weil ich von den .NET-Frameworkklassen keinen großen Plan habe. Aus Interesse und Spaß habe ich das dann mal in C++ mit COM nachgebaut - ich kann zwar jetzt zeilenweise die gerade empfangenen Daten in 'nen DC blitten, brauchte dafür aber dezent mehr als 3 Stunden - gerade wenn der C++-Code sauber sein soll... > Die Nutzung all dieser Sprachen impliziert noch lange nicht die > Verwendung von Grafik und/oder grafischen Eingaben und/oder > Grafikbaukastensystemen. Den Schluss sehe ich defintiv nicht. Ob du nun ein Buch liest, es dir vorlesen lässt oder dir den Film anschaust: bis auf gewisse Sachen bleibt der Grundinhalt meist gleich. Welchen Weg der beste ist - klar, das Buch! Kopfkino ist das beste Kino. Warum kaufen Leute trotzdem Hörbücher oder gucken die Filme? Aber bloß weil es Filme gibt, zu argumentieren, man solle doch lieber lesen lernen, sehe ich halt auch nur begrenzt ein. Und ich lese gerne!
Jürgen S. schrieb: >> Aber man hat's an Arduino bzw. am Raspberry gesehen: >> früher konnte man als 8-Bit-uC-Coder oder ARM-Programmierer sich >> noch was drauf einbilden, jetzt kann das jeder Schüler. > WAS kann der Schüler, wäre meine Frage: Ok, er braucht keinen > AD-Wandler-Code mehr generieren, weil er ihn im Baukasten hat. Den hat > aber jeder VHDL- und C-Coder auch im Baukasten und macht Copy-Paste. Wo > ist der Vorteil? Was ist, wenn im Baukasten der 18 Bit-Wandler fehlt? > Und was ist, wenn mit den Daten auch etwas gemacht werden soll? Ist im > Baukasten auch der richtige Signalfilter drin? Welchen nimmt man? Wie > fenstert man die FFT? Kann das der Schüler auch? :-) Vollkommen richtig, worauf ich hinauswollte war, dass die Einstiegshürden sinken. Und mal ernsthaft: um sich 'nen kleinen Roboter aus 'nem Arduino oder Raspberry zu basteln, muss man kein Ingenieur sein. Wenn man's ist, klar, dann kann man auch professionell lösen und die Signale sauber aufbereiten. Wenn nicht reichen auch einfache und stumpfe Approximationen. > Die Grafik ersetzt etwas Codingaufwand. Mehr nicht. Im Grunde wird > Softwareentwicklung für FPGAs und MCUs durch die Baukasten, die Cores > und die open files nicht einfacher, sondern sogar schwerer, weil der > Fokus vom einfachen Coden, was jeder Hansi erlernen kann, wegrutscht zum > Datenmanagement, der geschickten Speicherung und Interpretation sowie > der Algorithmik. Softwareentwicklung ist nicht gleich Coden! > Gegenmeinungen? Nö. Aber zur professionellen Softwareentwicklung gehört eine Abschätzung, welches Werkzeug für den jeweiligen Zweck sinnvoll ist. Habe ich 'ne Testumgebung mit LabView, wo mein Oszi per USB als VI drinne ist, mein Frequenzgenerator als VI drinne hängt und mein Spartan3E-Starter-Kit zwischen dem Generator und dem Oszi hängt, dann wäre eben nicht die ISE das Mittel der Wahl. Dann kann ich mit Labview automatische Tests meines FPGA-Designs mit realen Signalen fahren mit relativ billiger Hardware. Auch ein möglicher Anwendungsfall. > Nun ja, es muss ja nicht unbedingt die Nutzung von FPGAs propagiert und > verherrlicht werden. Dort, wo ein uC die Arbeit machen kann, ist seine > Nutzung in den allermeisten Fällen ja auch angezeigt. Das Forum ist auch > kein Massstab, denn es ist ein Microcotrollerforum. Dass hier die FPGAs > in der Minderheit sind, ist forenspezifisch - wobei ich das auch nicht > unbedingt so sehe: Gerade dieser Beitrag wie auch der Parallelthread > "Tutorials" zeigt doch, dass die Controller-Spezis durchaus auf FPGAs > wechseln und dies sogar in Anwendungen, wo dies nicht angezeigt wäre. Na ja, ein Microblaze/Picoblaze mit selbstzusammengeklickter Konfiguration lässt einem ja doch recht viel Flexibilität. Grundsätzlich ist es aber Wurst, ob man ein System auf 'ner Platine mit mehreren uC's zusammenbaut oder einen FPGA nimmt, der das ganze System hostet. Ist 'ne Kostenfrage und auch 'ne Frage nach dem Anwendungsfall.
Den Code für die vielen Instrumente und Anzeigen sowie ADC-Interfaces und Rechenwerke muss man eben auch esrt mal haben und erstellen und vorhanden ist das nur für standardisierte Sachen, z.B. eben denen von National. Damit ist man auch den Hersteller festgelegt. Sobald einer eigene Hardware anbinden will, muss er sich das selber zusammenschreiben. Will er dann Labview benutzen oder irgendwas anderes grafisches, muss er es noch in diese Tools reinstopfen, statt einfach es nur in sein VHDL zu kopieren. Für die meisten Sachen gibt es aber schon native VHDL Cores und viele erfahrene Designer haben umfangreiche Cores aus ihren Projekten zur Verfügung. Für die ist das eben auch nur eine müde Copy & Paste übung, Standardfunktionen zusammenzustellen. Obendrein besteht VHDL-Design heute fast nur noch aus dem Zusammenklicken von Stardardfunktionen wie DSP-Elementen, FFT, DDS und Filtern und auf der anderen Seite dem Beschreiben individueller Verschaltungen und Anwendungsspezifischen Funktionen. Die Standard-Cores laufen über Megawizzard und Instazierung von VHDL-wrapper-files und das individuelle Verschalten ist so simpel, dass man dafür garnichts braucht ausser ein bissl VHDL-text. Das einzig anspruchsvolle sind Spezialrechenfunktionen oder komplexe Abläufe wie z.b. ein MAC. Da kommt man um VHDL nicht herum. Dasselbe bei den Testbenches: Egal ob VHDL oder System-C oder eine Testlanguage: In Text ist alles schnell beschrieben und gesripted, wozu grafische Linien ziehen? Immer wenn ich diese überbunteten über überkontratierten Farb-Bunti-LV-Diagramme sehe, wo es viel Arten von Rahmen und Linien gibt, man aber trotzdem die Funktion nicht selbsterklärend vor sich hat, kriege ich Augenkrebs.
VHDL-Polizei schrieb im Beitrag #3421654: > Den Code für die vielen Instrumente und Anzeigen sowie ADC-Interfaces > und Rechenwerke muss man eben auch esrt mal haben und erstellen und > vorhanden ist das nur für standardisierte Sachen, z.B. eben denen von > National. Damit ist man auch den Hersteller festgelegt. Sobald einer > eigene Hardware anbinden will, muss er sich das selber > zusammenschreiben. Will er dann Labview benutzen oder irgendwas anderes > grafisches, muss er es noch in diese Tools reinstopfen, statt einfach es > nur in sein VHDL zu kopieren. Ich sag's nochmal: der Schwerpunkt von LabView und FPGAs ist die Datenerfassung und Auswertung, sprich Live-Einsatz. Es ist auch nicht das Ziel der Software LabView, die Xilinx Tools bzw. VHDL zu ersetzen. Es ist aber erstaunlich einfach, sowas wie Messungen von Frequenzgängen zu realisieren oder auch ein Spektrum zu ermitteln. > Für die meisten Sachen gibt es aber schon native VHDL Cores und viele > erfahrene Designer haben umfangreiche Cores aus ihren Projekten zur > Verfügung. Für die ist das eben auch nur eine müde Copy & Paste Übung, > Standardfunktionen zusammenzustellen. Das ist doch kein Argument, das geht doch mit fast jeder Programmiersprache. In LV kannste auch SubVIs einbinden. > Obendrein besteht VHDL-Design heute fast nur noch aus dem > Zusammenklicken von Stardardfunktionen wie DSP-Elementen, FFT, DDS und > Filtern und auf der anderen Seite dem Beschreiben individueller > Verschaltungen und Anwendungsspezifischen Funktionen. Die Standard-Cores > laufen über Megawizzard und Instazierung von VHDL-wrapper-files und das > individuelle Verschalten ist so simpel, dass man dafür garnichts braucht > ausser ein bissl VHDL-text. Das einzig anspruchsvolle sind > Spezialrechenfunktionen oder komplexe Abläufe wie z.b. ein MAC. Da kommt > man um VHDL nicht herum. Klar gibt es OpenCores, klar gibt es die DSP Tools mit Matlab. Wer aber nicht groß Hardwareaufbauten zum Test von algorithmischen Lösungen machen will bzw. lieber von einer Simulationsumgebung aus loslegt, für den kann LabView ganz interessant sein. Es bringt etliche virtuelle Instrumente mit, ohne dass du etwas verdrahten musst. > Dasselbe bei den Testbenches: Egal ob VHDL oder System-C oder eine > Testlanguage: In Text ist alles schnell beschrieben und gesripted, wozu > grafische Linien ziehen? LabView + Multisim können nützliche Tools sein. > Immer wenn ich diese überbunteten über überkontratierten > Farb-Bunti-LV-Diagramme sehe, wo es viel Arten von Rahmen und Linien > gibt, man aber trotzdem die Funktion nicht selbsterklärend vor sich hat, > kriege ich Augenkrebs. Schwarz-Weiss-Brille aufsetzen und los geht's... :) Nee, mal ernsthaft: so ganz übel ist das Zeug von NI nicht.
Gut, dann halten wir fest: NI's LabView ist "nicht übel". (fürs schnelle Basteln und Messen)
VHDL-Polizei schrieb im Beitrag #3421719: > Gut, dann halten wir fest: NI's LabView ist "nicht übel". > (fürs schnelle Basteln und Messen) Jo, man kann sich's mal anschauen, gibt ja Eval-Lizenzen zum ausprobieren. Stark wirds halt durch GPIB bzw. USB-Messgeräte. Aber bevor ich das Prädikat "LabView-FPGA-Tüdler" kriege (was ich mir dann selber eingebrockt habe... ^^), will ich mal aufhören, Reklame zu machen. Und ich gelobe Besserung, dass ich die gute ISE häufiger mit VHDL nutzen werde... :)
Falk Schilling schrieb: > dass ich die gute ISE häufiger mit VHDL nutzen werde... :) Tu das! Die ISE ist ein gut durchdachtes Programm, das in einzigartiger Weise die schnelle und sichere Entwicklung von qualitativ hochwertigen VHDL-Designs erlaubt. Sie stürzt nie ab, hat keine Fehler und stellt jederzeit eine stabile, konsistente und leicht handelbare Schnittstelle zu ModelSIM und MATLAB her. Sie ist das ideale Werkzeug für Entwicklung, Test und Verfikation, das in allen Belangen die Intelligenz seiner Planer und Programmierer widerspiegelt. Kurzum: Die ISE ist einfach perfekt. (und Vivado ist sogar noch perfekter) :-)
VHDL-Polizei schrieb im Beitrag #3421832: > Falk Schilling schrieb: >> dass ich die gute ISE häufiger mit VHDL nutzen werde... :) > Tu das! Die ISE ist ein gut durchdachtes Programm, das in einzigartiger > Weise die schnelle und sichere Entwicklung von qualitativ hochwertigen > VHDL-Designs erlaubt. Sie stürzt nie ab, hat keine Fehler und stellt > jederzeit eine stabile, konsistente und leicht handelbare Schnittstelle > zu ModelSIM und MATLAB her. Sie ist das ideale Werkzeug für Entwicklung, > Test und Verfikation, das in allen Belangen die Intelligenz seiner > Planer und Programmierer widerspiegelt. Kurzum: Die ISE ist einfach > perfekt. (und Vivado ist sogar noch perfekter) :-) Diese Ironie, Herrlich ^^
VHDL-Verbrecher schrieb im Beitrag #3421855: > (und Vivado ist sogar noch perfekter) :-) Ich nenns Viwaldo = "Where's waldo?". http://findwally.co.uk/fankit/graphics/IntlManOfLiterature/Scenes/DepartmentStore.jpg ;-)
VHDL-Polizei schrieb im Beitrag #3421832: > Die ISE ist ein gut durchdachtes Programm, das in einzigartiger > Weise die schnelle und sichere Entwicklung von qualitativ hochwertigen > VHDL-Designs erlaubt. Sie stürzt nie ab, hat keine Fehler und stellt > jederzeit eine stabile, konsistente und leicht handelbare Schnittstelle > zu ModelSIM und MATLAB her. Sie ist das ideale Werkzeug für Entwicklung, > Test und Verfikation, das in allen Belangen die Intelligenz seiner > Planer und Programmierer widerspiegelt. Kurzum: Die ISE ist einfach > perfekt. Wer Ironie findet darf sie behalten?^^
Wasser auf die Mühlen der grafischen FPGA-Entwickler: http://www.elektronikpraxis.vogel.de/themen/hardwareentwicklung/messtechnik/labormesstechnik/articles/326796/ Und dies hier erst: http://www.elektronikpraxis.vogel.de/messen-und-testen/articles/426627/ 300 Magneten generieren in Echtzeit ein Magnetfeld, um einen Teilchenstrahl mit hoher Präzision zu erzeugen. Damit lassen sich Krebszellen gezielt angreifen, ohne gesundes Gewebe zu schädigen.
Physiker arbeiten generell sehr oft und gerne mit Labview weil sich sowieso deren ganze Messtechnik damit ansteuern lässt und die Daten weiterverarbeitet werden können. Das Physiker das einsetzen wundert daher nicht wirklich. Bin vor ner Weile mal in der Uni paar mal bei den Physikern gewesen - die fanden das auch alle ganz toll und nutzen das so gut wie immer für ihre Versuche.
Tagchen, der Ex-Physiker sagt dazu nu auch mal was.. Ja, vor 15 Jahren gabs auch schon Labview und die Messkarten im Optik-Labor. Wurde auch alles gerne eingesetzt. Nur: Nachdem der Diplomand weg war, wusste keiner mehr, wie's genau läuft, und der nächste (der war ich) hat alles nochmal von vorne programmiert, diesmal in C. War dann etwas besser dokumentiert und wiederverwertbar. Noch zur CERN-Geschichte: Da muss ich auch etwas grinsen. NI brüstet sich immer gern damit, wer so alles ihre Produkte einsetzt und für tolle Dinger damit macht. Nur, dass Labview vor allem in der Prototyping-Phase eingesetzt wird, die finale Implementation mit Zertifizierung für Med/Mil/Auto aber nun so gar nicht auf Labview basiert, wird oft dezent weggelassen. Abgesehen davon diese Art der "Strahlenbehandlung" seit 20 Jahren schon ein Hype ist, und sich nur wenige Patienten eine solche Behandlung leisten dürfen/können, der Nutzen für die Menschheit sei dahingestellt. Aber anderes Thema.. Grüsse!
VHDL-Polizei schrieb im Beitrag #3421832: > Falk Schilling schrieb: >> dass ich die gute ISE häufiger mit VHDL nutzen werde... :) > Tu das! Die ISE ist ein gut durchdachtes Programm, das in einzigartiger > Weise die schnelle und sichere Entwicklung von qualitativ hochwertigen > VHDL-Designs erlaubt. Ist es schlimm, dass ich bereits bei "gut durchdacht" grinsen musste? Ich komm mir schon ganz schlecht vor... :) > Sie stürzt nie ab, hat keine Fehler und stellt > jederzeit eine stabile, konsistente und leicht handelbare Schnittstelle > zu ModelSIM und MATLAB her. Ich kann mich noch an irgendwelche Xilinx Error Codes erinnern, die bei der Synthese manchmal aufgetreten sind... und dass immer das XST-Handbuch wichtiger als die ISE selber war um was synthesefähiges zusammenzukriegen bzw. zu was welcher Operator synthetisiert wurde... ISE is schon was Feines! > Sie ist das ideale Werkzeug für Entwicklung, > Test und Verfikation, das in allen Belangen die Intelligenz seiner > Planer und Programmierer widerspiegelt. Warte mal, ich erkenne dich, du bist der, der die Artikel im Postillon schreibt... (der-postillon.com) > Kurzum: Die ISE ist einfach > perfekt. (und Vivado ist sogar noch perfekter) :-) Ich möcht's gerne glauben... :)
VHDL-Polizei schrieb im Beitrag #3421832: > (und Vivado ist sogar noch perfekter) Na und ob! Die kann sogar in einer Port Map einer Komponente, die nur über entity work.xyz instanziiert wird, keine Konstanten auf einen Eingang legen. Jaha, da muss man erst mal drauf kommen, das ist so genial, das verstehen gewöhnliche FPGA Entwickler gar nicht. Sorgt ja auch nur für Verwirrung. Und erst diese im Vergleich zur ISE noch viel übersichtlichere Oberfläche mit vielen Hyperlinks und gleichzeitig laufenden Fortschrittsbalken. Herrlich. Achja, per einfacher Command Line lässt sich das natürlich nicht einfach so steuern, neenee, dazu bedarfs schon der extrem intuitiven TCL. Wäre ja noch schöner.
> keine Konstanten auf einen Eingang legen. Nachdem ich mit Synopsys FPGA Compiler "aufgewachsen" bin, der sich bei sowas nicht zwischen einer VHDL-Fehlermeldung oder einem Stackdump entscheiden konnte, mache ich so fancy Zeug gar nicht erst ;) An die Nutzung von Records musste ich mich mit xst auch erst gaaanz langsam gewöhnen... > dazu bedarfs schon der extrem intuitiven TCL. Ja, ASIC/FPGA-Entwickler sind definitiv Masochisten. Mir ist bislang immer noch unklar, warum als Steuersprache nicht gleich INTERCAL verwendet wird. Dagegen wäre der unsägliche TCL-Dreck fast noch zu verständlich. Aber so ist das halt, wenn die Chip-Design-Branche autistisch vor sich hin wurschtelt und sich von den bösen SWlern auch nichts sagen lässt...
Georg A. schrieb: > Aber so ist das halt, wenn die Chip-Design-Branche autistisch vor sich > hin wurschtelt und sich von den bösen SWlern auch nichts sagen lässt... Mich bewegt in diesem Zusammenhang immer wieder, wie sehr man dort von sich überzeugt ist. Gerade ASIC-Entwickler werden nicht müde zu betonen, dass sie die Weisheit mit Löffeln gefressen haben, die Königsklasse der Digitaltechnikentwicklung darstellen und überhaupt Längsten haben. Es gibt nichts Schlimmeres, als ehemalige ASIC-Entwickler, die jetzt auf FPGAs machen. Dicht gefolgt von Physikern, die VHDL entwickeln. Beides gescheiterte Existenzen in ihrem Bereich, die ihr Brot in fremden Feldern verdingen wollen.
Fpga Kuechle schrieb: >> Falk Schilling schrieb: >>> Der Threaderöffner fragte explizit nach einer Möglichkeit, FPGAs >>> grafisch zu programmieren. Und neben der Möglichkeit, Schematics in der >>> ISE reinzukloppen gibt es da eben die Möglichkeit von Labview. >> kennt jeman dweitere? 7-segment Display with LabVIEW FPGA on a Xilinx SPARTAN3E Starter Board https://www.youtube.com/watch?v=cFt3rQ5zVBQ Gruss Holger.
Holger Harten schrieb: >>>> ... Labview. >>> kennt jemand weitere? > 7-segment Display with LabVIEW FPGA Wie war das mit "weitere"?
VHDL-Experte schrieb im Beitrag #3425236: > Georg A. schrieb: >> Aber so ist das halt, wenn die Chip-Design-Branche autistisch vor sich >> hin wurschtelt und sich von den bösen SWlern auch nichts sagen lässt... > Mich bewegt in diesem Zusammenhang immer wieder, wie sehr man dort von > sich überzeugt ist. Gerade ASIC-Entwickler werden nicht müde zu betonen, > dass sie die Weisheit mit Löffeln gefressen haben, > die Königsklasse der > Digitaltechnikentwicklung darstellen und überhaupt Längsten haben. Ist schon wahr, wenn man als Softwareentwickler die Möglichkeit hätte, so gut abgetesten Code haben zu können, wie die ASIC-Entwickler, dann könnte man sich auch weit aus'm Fenster lehnen damit. Will nur blöderweise keiner bezahlen... (bezogen auf C/C++, bei den Dotties mag das anders sein)
:
Bearbeitet durch User
Falk Schilling schrieb: > Ich sag's nochmal: der Schwerpunkt von LabView und FPGAs ist die > Datenerfassung und Auswertung, sprich Live-Einsatz. Sollte man das nicht eher "offline"-Einsatz nennen? Der Live-Einsatz wäre für mich durchaus derjenige im Feld im finalen Gerät. VHDL-Experte schrieb im Beitrag #3425236: > Es gibt nichts Schlimmeres, als ehemalige ASIC-Entwickler, die jetzt auf > FPGAs machen. Dicht gefolgt von Physikern, die VHDL entwickeln. Beides > gescheiterte Existenzen in ihrem Bereich, die ihr Brot in fremden > Feldern verdingen wollen. Den Satz habe ich mir kopiert, eingerahmt und ausgedruckt, um ihn jederzeit zitieren zu können. Aufrichtiges Dankeschön :D
Hier haben wir einen solchen Punkt des "live-Einsatzes": Ex-Physiker schrieb: > Noch zur CERN-Geschichte: > Da muss ich auch etwas grinsen. NI brüstet sich immer gern damit, wer so > alles ihre Produkte einsetzt und für tolle Dinger damit macht. Nur, dass > Labview vor allem in der Prototyping-Phase eingesetzt wird, die finale > Implementation mit Zertifizierung für Med/Mil/Auto aber nun so gar nicht > auf Labview basiert, wird oft dezent weggelassen. Das ist absolut zu unterstreichen. Ich kann jetzt nicht in die Details meiner Projekthistorie gehen, aber in der Tat sehe ich es öfters, dass zunächst mit Labview ein Probeaufbau erfolgte und die eigentliche Applikation dann nochmal "richtig" gemacht wurde. Das war aber niemals eine gesunde oder gewollte Strategie, sondern ergab sich einfach, weil der erste Bearbeiter (Anfänger, Leute von Unis, Studenten oder Projektmitarbeiter) nicht die Kompetenzen hatten, das direkt in frei programmierbarer Hardware zu machen. Labview war aber bekannt und wurde der Einfachheit halber genutzt. So richtig vorangebracht, hat es die Sache aber nicht, manchmal eher im Gegenteil. > Abgesehen davon diese Art der "Strahlenbehandlung" seit 20 Jahren schon > ein Hype ist, und sich nur wenige Patienten eine solche Behandlung > leisten dürfen/können, der Nutzen für die Menschheit sei dahingestellt. > Aber anderes Thema.. Mich wundert (es nicht), dass hier das Projekt bei CERN fokussiert wird. Dort scheint wie im akademischen Bereich zu erwarten, viel "gelabviewed" worden zu sein, wenn man der Webseite folgt. Es gibt aber gerade hinsichtlich der Partikeltheraphie auch andere Beispiele: Ein grosser deutscher Elektrotechnikkonzern hat(te) sich hier ja intensivst engagiert und auch Anlagen in Deutschland erbaut. u.a. in Heidelberg, die ja auch (noch ?) läuft. Tatsache ist, dass die Kosten für eine Anlage und damit die Behandlung gewaltig sind und es folglich auch problematisch ist, das alles zu finanzieren - soweit ist die Kritik daran berechtigt. Tatsache ist aber auch, dass gewissen Tumorarten nur so beizukommen ist, denn nur per punktuell platzierter Teilchenstrahlung kann es gelingen, dem Tumor auf Dauer eine vernichtende Dosis zu applizieren, ohne das Gewebe dorthin durch einen physischen Eingriff oder wirksame Durchtrittsstrahlung wie bei klassischer (extrakorporaler) oder lokaler (invasiver) Röntgenbestrahlung zu schädigen. Gerade die Röntgenstrahlung ist in der Dosis, die zur Zellvernichtung nötigt ist, oft selbst karzinogen und kann daher in Regionen wie im Hirn, in die man nicht einfach schadlos hineinoperieren kann, nicht angewendet werden, ohne neue Zellschäden zu verursachen. Nur durch die Nutzung des speziellen Beschleunigungs- und Bremsverhaltens der hochenergetischen Schwerionen kann man durch ein Gewebe hindurchgehen und Strahlung weit dahinter im Inneren der Körpers platzieren. Die Technologie als solche ist genial, sie stösst halt leider nur an die Grenze der noch bezahlbaren Medizin - wie so vieles, was in der MED erdacht wurde und wird.
Jürgen S. schrieb: > Falk Schilling schrieb: >> Ich sag's nochmal: der Schwerpunkt von LabView und FPGAs ist die >> Datenerfassung und Auswertung, sprich Live-Einsatz. > Sollte man das nicht eher "offline"-Einsatz nennen? Der Live-Einsatz > wäre für mich durchaus derjenige im Feld im finalen Gerät. Deine Aussage schränkt mir die Einsatzzwecke für FPGA zu sehr auf konkrete Endprodukte ein. Wer sagt denn, dass ein FPGA-Board nicht zur Unterstützung der Produktentwicklung dienen kann? Sozusagen als flexibles Werkzeug um damit z.B. eine Testumgebung zu schaffen. Ein automatisierter Test mit dem FPGA-Board und LabView könnte dann den FPGA dynamisch rekonfigurieren und den nächsten Test-Case. Nur ein Anwendungsfall, der sich damit steuern ließe. Gerade für solche Sachen ist ja meistens nicht viel Zeit, eben weil es Entwicklungsunterstützung ist - und es somit durchaus Live-Einsatz.
Falk Schilling schrieb: > Wer sagt denn, dass ein FPGA-Board nicht zur > Unterstützung der Produktentwicklung dienen kann? Sozusagen als > flexibles Werkzeug um damit z.B. eine Testumgebung zu schaffen. Dies wäre dann aber auch kein Einsatz im Feld, sondern einer im Rahmen der Entwicklung und den Fall hatten wir ja schon bejaht, wenn ich mich durch die Argumentationen und Beiträge hier kämpfe. Mich würde ein Fall interessieren, in dem mit Labview tatsächlich FPGAs, also deren Software, erzeugt und in Produkten, also ausserhalb der Firma, in mehr, als einem Gerät, verteilt wird. Wer outet sich? Von meiner Seite gäbe es hinzufügen, dass bei uns begonnen wurde, mit MATHWORKS und SIMULINK zu arbeiten. Den HDL-Coder haben sie wohl noch im Einsatz, das SIMULINK und die damit erreichbare grafische FPGA-Erzeugung wieder in die Tonne gekloppt - obwohl ich persönlich den Eindruck hatte, dass das nicht so ganz schlecht war.
Hat eigentlich schon einmal jemand hier dieses ROBEI benutzt? Der Entwickler wirbt ja öfters mal hier dafür.
Ja, ausprobiert. Ergebnis, hm - man braucht auch dafür wieder eine Lizenz.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.