FPGA grafisch programmieren

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.

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

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.

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

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.

achso, Systemgenerator heißt das

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.

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

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?

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.

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.

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

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

Win 7 home premium läuft hier mit ise 13,3 und 14.4

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?

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?

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

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.

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.

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.

>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

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.

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

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:
> 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?

Hochinteressantes Thema. Sollte man aber mal einen eigenen thread 
aufbauen, da die Mico Code Programmierung offensichtlich das Gegenteil 
des Themas darstellt.

Habt ihr mal das gelesen?
Beitrag "FPGAs grafisch programmieren - eine Analyse"

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.

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

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.

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.

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.

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

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.

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.

Für jede rising_edge ne grafische Box? Nee,ne?

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!

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.

Gut, dann halten wir fest: NI's LabView ist "nicht übel".
(fürs schnelle Basteln und Messen)

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!

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.

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.