Hallo, der letzte Beitrag zu diesem Thema ist ja schon etwas angestaubt. Womit entwickelt ihr? Ich benutze das kostenlose Xilinx Webkit, aber zum programmieren nehme ich Notepad++. Für kleine Sachen geht das ja ganz gut, aber für größere Projekte währe eine richtige IDE schon was feines. Folgende Seite gibt einen guten Überblick: http://www.vhdleditor.com/vhdl-ides Insbesondere zamiaCAD macht auf den ersten Blick einen guten Eindruck: http://zamiacad.sourceforge.net
Hallo Thomas, ich nehme derzeit noch gedit (als Editor - meine Designs sind klein und übersichtlich) und schaue mir gerade XEmacs (das ist auch ein weit verbreiteter Editor für VHDL) an. Eine weitere sehr gute Übersicht gibt es hier: http://tams-www.informatik.uni-hamburg.de/vhdl/index.php?content=07-tools Hier fehlt aber der von die gepostete zamiacad, welchen ich auf den ersten Blick auch sehr interessant finde. Viele Grüße Boris
Vorneweg: ich habe dem Tread mal einen sinnvollen Titel verpasst. Und ich verwende an Editoren, was mir gerade unter die Finger kommt. Hauptsache es gibt "find in files" und Blockbearbeitung...
Danke für den sinnvollen Titel. Mit den Nummern habe ich nur meinen sinnvollen Titel auf die 15 erforderlichen Zeichen aufgefüllt. Das ist meine Form von Protest gegen neunmalkluge Computer die mir vorschreiben wollen was ich zu tun hab. > Und ich verwende an Editoren, was mir gerade unter die Finger kommt. > Hauptsache es gibt "find in files" und Blockbearbeitung... Ist das nicht ein bischen wenig für größere Projekte? Ich meine für jeden Java-Entwickler sind heutzutage dinge wie Projektnavigation, Refactoring, online-Syntaxkontrolle, Team-Integration, etc. völlig selbstverständlich. Sind VHDL-Entwickler wirklich so anspruchslos?? Hat jemand Erfahrung mit zamiaCAD und kann was dazu sagen? Was ist mit Sigasi? Nutzt das jemand?
> gvim bzw vim
Ich dachte immer das ist ein Editor.
Kann das auch nur eins der von mir genannten Features?
Thomas schrieb: > Sind VHDL-Entwickler wirklich so anspruchslos?? Das nicht, aber das blöde an all den Editoren ist, dass sie sich nicht nahtlos in die jeweilige IDE des FPGA Herstellers einbinden lassen. Klar sind all die Dinge sinnvoll, aber wenn ich dann wieder mit min. 2 verschiedenen IDEs arbeiten muss, ist das auch wieder umständlich. Ganz auf z.B. Xilinx ISE verzichten ist zwar möglich, macht aber im täglichen Gebrauch auch wenig Spaß, schon wenn man ein neues Modul zum projekt hinzufügt, muss man mindestens die xst Datei anpassen, Den Core-Gen muss man extra aufrufen, die Fehler- und Warnemldungen manuell aus den xml Dateien ziehen. Wenn die in Zamia Cad mal den FPGA Work Flow mit einbauen, dann ist das sicherlich sinnvoll...
Christian R. schrieb: > Thomas schrieb: >> Sind VHDL-Entwickler wirklich so anspruchslos?? > > Das nicht, aber das blöde an all den Editoren ist, dass sie sich nicht > nahtlos in die jeweilige IDE des FPGA Herstellers einbinden lassen. Klar > sind all die Dinge sinnvoll, aber wenn ich dann wieder mit min. 2 > verschiedenen IDEs arbeiten muss, ist das auch wieder umständlich. Ganz > auf z.B. Xilinx ISE verzichten ist zwar möglich, macht aber im täglichen > Gebrauch auch wenig Spaß, schon wenn man ein neues Modul zum projekt > hinzufügt, muss man mindestens die xst Datei anpassen, Den Core-Gen muss > man extra aufrufen, die Fehler- und Warnemldungen manuell aus den xml > Dateien ziehen. Wenn die in Zamia Cad mal den FPGA Work Flow mit > einbauen, dann ist das sicherlich sinnvoll... Das Aufsetzen einer Tool-Chain ist nicht Zweck einer Editors. Für so was haben die Schöpfer der Softwareentwicklung make und scripte erfunden. Dann braucht man sich auch nicht persönlich bemühen den Coregenerator oder modelsim aufzurufen. Fehler- und Warnmeldungen kann ein Grep aus den log-files ziehen, perl kann dergleichen noch sortieren. Oder man öffnet im Emacs zwei horizontale Fenster, eins für den Code, eins für die Logdatei und wechsel per Tastenkürzel schnell zwischen beiden. Neben deutlsichen Geschwindigkeitsvorteilen ist ein solcher (make-basierender) Flow auch reproduzierbar und in ein Revisionsystem pflegbar. Und nicht zuletzt kann man eigene tools (präprozessor, script zum erzeugen Contsnate mit compile datum und automatischer Versionsnummer einbauen). Der Aufwand make zu lernen ist nicht gering, er macht sich aber dank handjustierter, schneller, komplexer und vollautomatisierter Syntheseläufe schnell bezahlt. IDE sind für den schnellen Einstieg sinnnvoll, volle kontrolle über die Code-gerierung erlangt man aber dadurch nicht. Editoren sind zweitrangig, was zählt ist die Toolchain. MfG,
Hier muss ich dir uneingeschränkt zustimmen. Es muss zwar nicht unbedingt make sein, aber ein standartisierter Flow ist die beste Möglichkeit die Übersicht zu wahren. Ein Projekt ständig neu aufsetzen oder gar die Projektdateien mit kopieren/pflegen/tauschen kommt eigentlich kaum in Frage wenn man nicht alleine arbeitet.
Ich geb dir vollkommen recht, was den Build-Prozess angeht. Wir haben den auch auf einem TeamCity Server laufen, batch-gesteuert und die Quellen im SVN, automatischer Eintrag der Versionsnummer usw. Aber lokal konnte ich mich aus den genannten Gründen damit noch nicht anfreunden, ist schon ein erheblicher Aufwand, wenn man dann Warnungen parsen muss usw. Wenn man das besser in z.B. Zamia CAD integrieren könnte, wäre das sicherlich sinnvoll, müsste ich mal gucken, was die aktuelle Version alles kann.
Lothar Miller schrieb: > und Blockbearbeitung... Yepp! Notepad++ benutze ich meistens, weil man sich da eine einfach Sprache selber definieren kann, z.B. UCF. Beitrag "Re: VHDL extension für Programmers Notepad" @Stachele ich nehme an, Dich stört die Sensi-Liste? Ich habe da einen Verdacht, warum die Signale da drin stehen...
Hallo, ich nutze seit einiger Zeit Sigasi. Ich kann nur sagen, absolut der Hammer. Softwareentwickler die Eclipse, QTCreator oder VS gewöhnt sind können da nur müde lächeln, aber Hardwareentwickler die sich seit Jahren mit öden Editoren rumplagen werden es lieben... LG
Ich benutze beruflich auch Sigasi. Besonders die Integration von vcom macht das Arbeiten sehr effizient, weil man sofort bzw. beim Speichern der Datei alle Warnungen und Fehler im Editor-Fenster angezeigt bekommt. Auch das Renaming ist sehr gut. Es ist wie alle Eclipse basierten IDEs ein bisschen träge, aber damit kann ich leben. Ein paar Bugs sind auch drin (manchmal stürzt er sogar ab), aber es gibt ständig Updates mit teilweisen neuen interessanten Funktionen. Ich möchte nicht mehr mit einem "normalen" VHDL-Editor arbeiten.
Christian R. schrieb im Beitrag #2750196:
> Was kostet eigentlich die Pro von Sigasi?
599 Euro pro Jahr.
Ja, habs dann doch gefunden. Ich hatte gleich auf "Buy Online" geklickt im Untermenü :) Naja, Tomaten auf den Augen....
Es gibt auch eine Kostenlose Demo-Version. Allerdings ist da die Code Größe beschränkt.
> und Blockbearbeitung... Kann Eclipse übrigens auch: Alt + Shift + A Ok, Notepad++ hats besser integriert. Sigasi: > Es gibt auch eine Kostenlose Demo-Version. Allerdings ist da die Code > Größe beschränkt. Laut Webseite gehen damit immerhin 2000 bis 5200 Codezeilen: http://www.sigasi.com/faq/what-small-project Das Video Tutorial gibt schonmal einen guten Eindruck: http://www.sigasi.com/content/eclipse-workbench-tutorial zamiaCAD: Ich habe das Tutorial durchgearbeitet: http://zamiacad.sourceforge.net/web/?q=tutorial Die Simulation klappt bei mir nicht wie beschrieben, der interne Simulator geht aber. Ansonsten ist das eher ein Editor mit gewissen Projektmanagement-Eigenschaften. Syntaxhighlighting und Projektnavigation gehen, sonst gibt es nicht viel Unterstützung. Ist trotzdem besser als ein einfacher Editor wie Notepad++. Zumal sich das mit etlichen Eclipse-Plugins wie z.B. eGit erweitern lässt.
> zamiaCAD: > Ich habe das Tutorial durchgearbeitet: > http://zamiacad.sourceforge.net/web/?q=tutorial > Die Simulation klappt bei mir nicht wie beschrieben Hat das mal jemand getestet? Klappt das bei euch? Wenn nicht, dann würde ich mal einen Bug-Report schreiben.
Kann ich evtl. in den nächsten Tagen mal machen. Ich hab jetzt erst mal ein Projekt von mir nach Eclipse mit Veditor "portiert". Das klappt auch soweit gut, er nimmt auch den ModelSim vcom als Kompiler für den Syntax Check. Der Error Parser klappt auch einigermaßen, hat aber ein Problem mit verlinkten Files, die nicht physisch im Projektordner sind. Ansonsten ist VEditor echt schön, vor allem die automatische Komponenten-Instanziierung. Mein (Batch-)Build Script lässt sich auch leicht über external Tools einbinden und so verknüpfen, dass es bei Crtl+B startet. Schön wäre noch, wenn der Error-Parser dann den Build Output auch parsen könnte, man kann ja eigene Parser erstellen, aber die wirken da offenbar nicht (richtig).
Christian R. schrieb: > Kann ich evtl. in den nächsten Tagen mal machen. Ich hab jetzt erst mal > ein Projekt von mir nach Eclipse mit Veditor "portiert". Das klappt auch > soweit gut, er nimmt auch den ModelSim vcom als Kompiler für den Syntax > Check. Der Error Parser klappt auch einigermaßen, hat aber ein Problem > mit verlinkten Files, die nicht physisch im Projektordner sind. > Ansonsten ist VEditor echt schön, vor allem die automatische > Komponenten-Instanziierung. Mein (Batch-)Build Script lässt sich auch > leicht über external Tools einbinden und so verknüpfen, dass es bei > Crtl+B startet. Schön wäre noch, wenn der Error-Parser dann den Build > Output auch parsen könnte, man kann ja eigene Parser erstellen, aber die > wirken da offenbar nicht (richtig). Das größe Manko an Veditor ist wohl, dass es so gut wie nicht mehr weiter entwickelt wird. Was schade ist, denn es ist ein wirklich guter Ansatz. Und leider ist es auch noch nicht so weit, dass es bei meinem Projekt wirklich ohne größere Fehler läuft. Das parsen das VHDL Codes funktioniert nicht richtig, und in der Outline steht alles doppelt drin. Ich hatte mir auch mal den Sourcecode angeguckt, und versucht was dran weiter zu bauen, aber leider hab ich bisher nicht genug Zeit gefunden wirklich was zu machen.
@ Klaus: Geht bei dir der Error Parser für Modelsim im Veditor richtig? Bei mir kriegt der das irgendwie nicht gebacken, die Fehler den Files im Projekt zuzuordnen. Manchmal geht es, wenn ich probeweise eine Quellcode Datei direkt im Eclipse Projektverzeichnis habe, aber dann auch nur nach Sonnenstand. Ich hab ein Testprojekt jetzt so angelegt, dass die VHDL Dateien usw. nur über linked folders rein hole, da gehts irgendwie erst recht nicht. Allerdings funktioniert der integrierte Syntax-Parser. Die doppelte Outline stört jetzt nicht wirklich, ansonsten sind viele Bugs in der 1.1.7 die man bei testing runterladen kann, behoben.
Ich hab übrigens gestern abend noch das hier gefunden: http://simplifide.com/drupal6/content/hdl-plugin Mal sehen wie das so ist, man muss erst eine Lizenz anfordern.
> ansonsten sind viele Bugs in der 1.1.7 die man bei testing runterladen kann, behoben. Kannst du mir mal auf die Sprünge helfen? Auf sourceforge finde ich nichts... http://sourceforge.net/projects/veditor/
Hier die Eclipse Update Site: http://veditor.sourceforge.net/testing Die geht soweit ganz gut, nur dass eben der ModelSim Error Parser nicht läuft und die Outline manchmal doppelt anzeigt. Ansonsten kann man damit sehr gut arbeiten...
Nee, keine Ahnung. Aber im Bugtracker waren relativ neue Einträge und der Bug, dass keine Einstellungen gespeichert werden, ist offenbar noch nicht allzu lange raus...
Zur Übersicht habe ich mal einen Artikel angelegt: http://www.mikrocontroller.net/articles/VHDL_Editoren_und_IDEs
Christian R. schrieb: > Ich hab übrigens gestern abend noch das hier gefunden: > http://simplifide.com/drupal6/content/hdl-plugin Mal sehen wie das so > ist, man muss erst eine Lizenz anfordern. das habe ich auch schon mal getestet. Es ist sehr brauchbar. Es werden auch Signale, die nicht mehr verwendert werden rot gekenzeichnet. So kann man Leichen aus dem Code gut entfernen. Mit "strg und Leertaste" ging auch noch was interessantes. Ich glaube es war eine Auswahlliste. Ich hatte erneut nach einer Testlizenz angefragt aber keine bekommen. Irgendwann wird man eben kostenpflichtig.
Laut http://www.vhdleditor.com/vhdl-ides wurde die Entwicklung von Simplifide eingestellt. Auf deren Homepage finde ich diese Info nicht. Sollte das nicht stimmen, muss das im Artikel korrigiert werden: http://www.mikrocontroller.net/articles/VHDL_Editoren_und_IDEs
René D. schrieb: > Ich hatte erneut nach einer Testlizenz angefragt aber keine bekommen. > Irgendwann wird man eben kostenpflichtig. Das ist auch irgendwie undurchsichtig. Irgendwo bei der Installation steht, dass es frei ist, aber eine Lizenz nötig ist. Ich denke aber dass man eher mal am Veditor dran bleiben sollte. Wenn der Error Parser repariert wäre, wäre das Ding äußerst brauchbar. Interessant wäre noch ein Parser, der die Xilinx XML Files nach dem Build durchsucht.
Ich schreibe / programmiere auschließlich mit vim (Linux/MacOS). Verifiziert wird dann mit Modelsim (beruflich) oder GHDL (privat). Zur Steuerung des Buildprozesses kommen Makefiles, TCL und diverse kleine Bashscripte zum Einsatz. Als Versionsverwaltung wird Subversion und Git genutzt. :)
T.M. schrieb: > auschließlich mit vim Hehe. Und ich dachte schon, ich bin der einzige vim/gvim Nutzer :-) Duke
Weiß jemand, wie man an den Quellcode vom Veditor der aktuellen 1.1.7 aus der Testing Update Site kommt? Ich hab mir den SVN Code mal gezogen und den Unsinn mit dem Filename-Parser berichtigt (ErrorParser.java in /veditor/src/net/sourceforge/veditor/builder):
1 | private IResource getFile(String filename) |
2 | {
|
3 | File TestFile = new File(filename); |
4 | IResource test; |
5 | if(TestFile.isAbsolute()) |
6 | {
|
7 | IPath projectPath = Path.fromOSString(TestFile.getAbsolutePath()); |
8 | test = getFileRecursive(project, projectPath); |
9 | }
|
10 | else
|
11 | {
|
12 | IPath projectPath = project.getLocation().append(buildConfig.getWorkFolder()); |
13 | projectPath = projectPath.append(filename); |
14 | test = getFileRecursive(project,projectPath); |
15 | }
|
16 | |
17 | return test; |
18 | }
|
Das funktioniert bei mir jetzt zumindest mit den Absolut-Pfad-Ausgaben von vcom problemlos, damit findet er das File, auch wenn das nur zum Projekt gelinkt ist. Allerdings hat diese 1.1.5 Version das Problem, dass sie die Preferences nicht speichert....also würde das nichts bringen, darauf weiter zu arbeiten. Der letzte Commit dort ist übrigens von diesem Jahr, also irgendwas wird schon noch getan.
> Der letzte Commit dort ist übrigens von diesem Jahr, also irgendwas wird > schon noch getan. Tatsache. Komisch nur, dass man das nur im SVN sieht, und nicht auch auch auf sourceforge. Die letzten Jahre war allerdings nur eine Person aktiv: aghoras > Weiß jemand, wie man an den Quellcode vom Veditor der aktuellen 1.1.7 > aus der Testing Update Site kommt? Am besten aghoras mal eine PM schreiben.
Schon geschehen. Bug report hab ich auch geschrieben. Mal sehen, ob noch jemand aktiv ist.
Um der Diskussion mal den Schwung in Richtung Professionalität zu geben: Entscheidend sind doch nicht Vorlieben sondern die Effizienz bein Code-schreiben die ein Editor gewährleistet. Für mich bedeutet dies fürs VHDL-Code schreiben: -zwei fenster nebeneinander um Code abzugleichen bzw. nachzuscheuen: zwei unterschiedliche files (bspw. Port -Definition|Port MAP;Package mit functions def und File mit Test aufruf;top.vhd|ucf) unterschiedl. Positionen selbes file (bspw. enum definition - case) zwischen diesen beiden soll sich leicht (ohne Maus) code auswählen und übertragen lassen -zwei Fenster untereinander: Oben code unten Fehlerreport, zwischen den fesntern soll man während eine Suche gut wechseln können. ->Multi-Windowing und schneller Wechsel zwischen diesen ist für mich einer der Hauptgründe für einen Editor zum VHDL-schreiben. Für notizen ist das nicht so wichtig, da tuts auch ein ein-Fenstereditor. - In dieser Disziplin hat mich Notepad++ schwer enttäuscht. Mehrerer Files geöffnethaben und leicht zwischen diesen Wechseln: - eigentlich eine Konfortfunktion, hilft aber ungemein in VHDL. Durch das modulare Konzept zieht sich eine Änderung oft über mehrere Files. Und sei es das man für modelsim den neuen Signalnamen in "Add to wave" aufnimmt. - das können inzwischen fast alle editoren, vim m.E. ausgenohmen. Kopieren von rechtwinkligen Ausschnitten (Spalten-Modus) brauch ich auch immer mal wieder (templates für MUXer mit hohen FAN-In). Filebrowser oder Ersatzweise filenamenergänzung. Setzen von Textmarken Sprung zum ebenen-ende Sprung zu Zeilennummer Blockweises auskommentieren fürs VHDL an sich ist Syntax-Highlighting mehr eine Komfortfunktion als Effizienzsteigerung. zeitsparend dagegen das Paste as (component,Instanz,Testbench, ...) des EMACS-VHDL-mode also das Setzen von code-templates. Keyword-vervollständigung ist auch ganz nett. Neben VHDL schreiben ist filevergleich und angleich (neudeutsch merge) eine Disziplin in der ein editor punkten kann. Auch hier komme ich mit dem EMACS (im EDIFF-Mode) recht weit, bevorzuge aber dann doch dedizierte Mergetools. Insgesamt kann ich mit dem Emacs am Effizientesten VHDL-Code schreiben, Notepad++ nehme ich so für Notizen oder C-Code. Notepad++ ist gut im definieren von farblichen Hervorhebung, also man schnell definiert das im Synthesereport @E rot,@W gelb und @I grau hervorgehebn wird. (Konfiguriern vom Emacs ist IMHO eine Qual).Emacs kann dank vhdl-mode fast zur IDE hochgerüstet werden. Ultraedit benutze ich garnicht mehr, dem fehlt ein Alleinstellungsmerkmal und irgendwie gefällt mir die Optik nicht. Für den schnellen Remote-Hack greife ich zu VIM, da effizient bei geringen Bandbreiten (ssh-Verbindung). Unter DOS bspw. bei der AVR-Assembler programmierung ist Boxer editor der Wahl. Die Editoren von IDE's verwende ich garnicht, da schnarchlangsam und wenig Komfort. Da wechsele ich lieber zwischen Editor (Code schreiben) und IDE (Compile-Flow options variieren ) hin und her - solange bis alles in Scripten etc automatisiert ist. MfG, PS: Link zum Emacs VHDL-Mode (Screenshot): http://www.iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.gif
Thomas schrieb: > Am besten aghoras mal eine PM schreiben. Er lebt noch ;)
1 | Hi Christian, |
2 | The latest version of the code is available via subversion. |
3 | The project is still being developed. As a matter of fact, my |
4 | last source submission was to address the very problem you are |
5 | working on. |
6 | |
7 | I\'m currently on vacation but I\'ll be back by Thursday. I\'ll |
8 | be able to offer more assistance then. |
T.M. schrieb: > Ich schreibe / programmiere auschließlich mit vim (Linux/MacOS). > Verifiziert wird dann mit Modelsim (beruflich) oder GHDL (privat). Zur > Steuerung des Buildprozesses kommen Makefiles, TCL und diverse kleine > Bashscripte zum Einsatz. Als Versionsverwaltung wird Subversion und Git > genutzt. :) Auf der Welle schwimme ich auch mit. Hast du noch ein paar Scripte oder Makefiles? Man wird durch den Austausch immer effektiver. Ich komme mit GHDL sehr gut zurecht und habe schon mehrere Anläufe zu modelsim unternommen und bin immer wieder bei GHDL gelandet.
Where to download Veditor 1.1.7 plugin? Seems http://veditor.sourceforge.net/testing doesn't work. Thanks!
Aktuell wird der Veditor wieder mehr weiterentwickelt. Schaut euch doch mal die neue Version an 1.2 mal an ( http://sourceforge.net/projects/veditor/ ). Es wurde unter anderem der nervige Bug mit verlinkten Files behoben und es gibt mehr Möglichkeiten bei der Erstellung einer neuen Datei (mehrere mögliche Templates) und es ist nun möglich die Eclipse-Variablen beim "Synthesize" und beim "Compile Command" zu verwenden. Zudem wurde der Formatter weiter verbessert. Im Wiki findet ihr auch eine Hilfe zum Veditor ( http://sourceforge.net/apps/mediawiki/veditor/index.php?title=Main_Page ) Wenn ihr weitere Verbesserungsvorschläge habt, dann schreibt sie hier rein :-)
Ja hab ich schon probiert, was noch fehlt ist ein extra Error parser für compile/synthesize der auch triggert wenn man build nicht benutzt. Ansonsten super Arbeit in der Zwischenzeit.
Fritz Jaeger schrieb: > Neben deutlsichen Geschwindigkeitsvorteilen Hallo! Interessanter Thread. Mir ist nicht klar wie ein make-basierter Flow Geschwindgkeitsvorteile bringt. Kannst Du mir das erklären??? (in der Hoffnung das Fritz Jaeger noch da ist...)
Heinrich H. schrieb: > Mir ist nicht klar wie ein make-basierter Flow Geschwindgkeitsvorteile > bringt Hm, das kann man so auch nicht stehen lassen, denn von ISE werden die entsprechenden Programme XST, NGDBUILD, MAP, PAR usw. auch nur per command line aufgerufen. Da spart man nichts. Ich lasse die toolchain per command line (batch) auf einem Server laufen, der die Projekte automatisiert baut, das dauert genauso lange wie aus ISE heraus.
Christian R. schrieb: > Heinrich H. schrieb: >> Mir ist nicht klar wie ein make-basierter Flow Geschwindgkeitsvorteile >> bringt > > > Hm, das kann man so auch nicht stehen lassen, denn von ISE werden die > entsprechenden Programme XST, NGDBUILD, MAP, PAR usw. auch nur per > command line aufgerufen. Da spart man nichts. Ich lasse die toolchain > per command line (batch) auf einem Server laufen, der die Projekte > automatisiert baut, das dauert genauso lange wie aus ISE heraus. Sehe ich auch so.
Thomas W. schrieb: > Zur Übersicht habe ich mal einen Artikel angelegt: > http://www.mikrocontroller.net/articles/VHDL_Editoren_und_IDEs Sehr gute Idee! Man sollte es noch um Funktionalitäten erweitern. Was ich brauche, wäre eine intelligente Kommentarfunktion wie bei Excel, um Codezeilen mit Kommentaren versehen zu können. Sowas müssste sich in einem Extra-file speichern und zublenden lassen. Ebenso müsste es eine Verknüpfung der Entites geben, sodass man Busbreiten und Namen konsitent ändern kann, damit erst gar keine Diskrepanzen beim Erweitern der Ports entstehen. Sowas müsst sich per plugin implementieren lassen, von daher tendiere ich ja zu einer OpenSOurce Lösung. Vor Jahren schon habe ich probiert, die SourceForge-Leute dahin zu puschen, aber für VHDL sah man damals keine Anwendung. Wäre aber mal ein richtig interessantes Projekt.
Schön, dass sich beim Veditor wieder etwas tut, muss ich bei Gelegenheit noch mal testen. Es gibt noch ein aktives Projekt mit ähnlichen Namen auf Sourceforge; http://sourceforge.net/projects/sveditor Habs mir noch nicht angeschaut, kann aber anscheinend nur Verilog. > Was ich brauche, wäre eine intelligente Kommentarfunktion wie bei Excel, > um Codezeilen mit Kommentaren versehen zu können. Sowas müssste sich in > einem Extra-file speichern und zublenden lassen. Warum nicht einfach direkt im Quellcode dokumentieren? Gängige Editoren können Codeblöcke auf- und zuklappen. Eclipse versteht auch noch Schlüsselwörter wie TODO. Externe Datei wird im Team scheitern, weil andere Editoren damit nichts anfangen können. > Ebenso müsste es eine Verknüpfung der Entites geben, sodass man Busbreiten > und Namen konsitent ändern kann, damit erst gar keine Diskrepanzen beim > Erweitern der Ports entstehen. Nennt sich "Refactoring" und ist in allen anderen Sprachen längs Standard. Davon abgesehen, such mal nach "VHDL Package".
Nachtrag zu Thema Kommentarfunktion: Ich benutze hier Redmine und Git (-> Google). Wenn man sich dazu zwingt folgende Prozesse einzuhalten, dann ist das wirklich sehr Übersichtlich: * Es werden grundsätzlich nur kompilierbare, synthetisierbare, lauffähige Versionsstände eingecheckt. * Jeder Checkin enthält nur ein einziges Feature oder Bugfix. * Zu jedem Feature / Bug wird ein Issue in Redmine aufgemacht. Und zwar noch bevor man mit der Umsetzung beginnt. Dort werden kurz die Anforderungen, Probleme, Lösungen beschrieben. Diskussionen werden auch dort geführt (und nicht per Email!). Idealerweise gibt es also zu jedem Checkin ein Issue (Issues könne auch mehrere Checkins haben). * Im Checkin-Kommentar wird auf das Issue verwiesen. * Im Issue wird auf die Checkins verwiesen (geht auch automatisch, wenn man den vorherigen Punkt berücksichtigt hat). Das ziehe ich auch bei 1-Mann Projekten durch. Sehr geil, wenn: * man nach langer Zeit noch mal ran muss. * man Ideen mit Lösungsansätzen, Konzepten, Links, etc. bis zur Umsetzung schon mal da ablegt. So vergisst man nichts und spart sich doppelte Arbeit. * jemand anderes das Projekt übernimmt. * Teammitglieder hinzu kommen. Ohne geht gar nicht mehr.
Thomas schrieb: > * Es werden grundsätzlich nur kompilierbare, synthetisierbare, > lauffähige Versionsstände eingecheckt. ok, mit der Einschränkung, dass "synthetisierbar" immer an ein Projekt, an ein FPGA und Randbedingungen gekoppelt ist. Ich checke normalerweise einzelne VHDL Module mitsamt ihrer Doku etc ein. Thomas schrieb: > Warum nicht einfach direkt im Quellcode dokumentieren? Weil ich nicht einen unlesbaren Quellcode haben will und zudem dort auch Anmerkungen rein kommen, die nicht an einen Endnutzer / Kunden weitergeben werden sollen können dürfen. Ausserdem gibt es Dokumenationsaspekte, die an ein bestimmtes Projekt gekoppelt sind und die ich gerne vom Code getrennt hätte, wie requirements.
Was mich an der Eclipse-Lösung stört, ist dass man zwei IDEs parallel laufen lassen muss. Ich mache es nämlich genauso wie Thomas (Gast): Nur was läuft, wird auf den Build-Server (bei uns TeamCity) eingecheckt. Daher brauch ich immer mal die ISE im Normal-Modus, weil man einfach so schnell mal die aufbereiteten Logs bekommt. Außerdem hab ich mit Eclipse-VEditor noch keine sinnvolle Möglichkeit gefunden, nur die sinnvollen Dateien ins Projekt einzubinden, denn ISE müllt ja das Arbeitsverzeichnis immer so zu. Eclipse zeigt dann brav alle erzeugten Dateien in der Projektübersicht an. Oder wie macht ihr das mit dem VEditor? Millterweile benutze ich schon recht lange Notepad++ als externen Editor in ISE, hab mir da auch noch Syntax-Dateien für UCF geschrieben. Das reicht für das meiste. Lediglich refactoring und Typ-Anzeige bei mouse-over fehlt mir da...
>Eclipse zeigt dann brav alle erzeugten >Dateien in der Projektübersicht an. Gegenmittel: Resourcefilter (Project props)
J. S. schrieb: > Ausserdem gibt es > Dokumenationsaspekte, die an ein bestimmtes Projekt gekoppelt sind und > die ich gerne vom Code getrennt hätte, wie requirements. Dafür gibt es passende Tools, wie ReqTracer. Damit kann man die Anforderungen auf verschiedenen Abstraktionsebenen in verschiedenen Dokumenten halten. Das Tool prüft dann über Verknüpfungen (Tags) in wieweit die Anforderungen bereits erfüllt sind. Nette Sache, wurde ich mir als Open Source wünschen. Duke
Christian R. schrieb: > Außerdem hab ich mit > Eclipse-VEditor noch keine sinnvolle Möglichkeit gefunden, nur die > sinnvollen Dateien ins Projekt einzubinden, denn ISE müllt ja das > Arbeitsverzeichnis immer so zu. Mein Tip: Alle selbsterstellte Dateien (vhd, ucf, etc...) in eigene Unterordner sortieren. ISE zwingt ja keinen die sourcefiles im Work-Ordner zu haben...
Heinrich H. schrieb: > Fritz Jaeger schrieb: >> Neben deutlsichen Geschwindigkeitsvorteilen > > Hallo! > Interessanter Thread. > Mir ist nicht klar wie ein make-basierter Flow Geschwindgkeitsvorteile > bringt. Kannst Du mir das erklären??? (in der Hoffnung das Fritz Jaeger > noch da ist...) Hallo und danke für die Nachfrage. Die Aussage ist fehlinterpretierbar da vom falschen blickwinkel aus gemacht. Gemeint ist das ein vom Projectnavigator (PN) angestossener Designflow durch den höheren Ressourcenbedarf (Overhead) mehr Rechnerleistung benötigt als ein durch ein schlankes make angestossener. Schon bei "normalen" Arbeits-PC kann es zu permanenten Swapping kommen da GUI und Tool-Daten nicht gleichzeitig in den physikalischen RAM passen. Gerade bei frühen Linux-Varianten (ISE9) ging ein Aufschrei über schneckenlangsame GUI-Synthesen durch die Foren, so dass zu vermuten war das zu jedem Display-Update der Projektnavigator von der Festplatte neugeladen und anschließend wieder ausgelagert werden musste. Wohl ein Grund warum Xilinx die GUI-Basis vor einiger Zeit komplett ersetzte (von Java auf Qt?) Alternativ kann man unter Linux auch auf Projectnavigator und GUI (X11) verzichten und die Synthese allein über die Konsole (tty oder ptty) steuern. Dann steht fast der gesamte RAM der Synthese zur Verfügung. Ferner vermute ich das der PN weit häufiger auf die Platte zugreift (Log updaten, fileänderungen erkennen) als make. Auch hier kann eine Schwelle erreicht werden, bei der die Leistung deutlich einbricht da der Lesekopf nur noch im ZickZack über die Scheiben huscht. Ebenfalls werden die tools vom PN anders gestartet als vom make, der commandline Schalter -intstyle steht nicht auf xflow. Wohl um damit die generierung von xml zusätzlich txt zu steuern. Auch kann die Verbindung zum server in der Bndbreite beschränkt sein und die übertragung der GUI-Daten bremst den Designflow aus. Bspw. eine X11 - Verbindung zu einem Linux-Mietserver über ADSL. X11-beschleuniger die den Protokollaufwand minimieren (Message queing, vereinfachtes handshake) helfen in solchen Situationen, aber ideal ist in diesem Fall ein Linux komplett ohne GUI-Code. Allerdings steht heutzutage soviel Rechenleistung zur Verfügung das das zumindest bei kleinen Designs kaum zzu Tragen kommt. Ich hab grad an auf eimem Win-64 laufend auf i5@2.27GHz mit 4GB ein s3-200k Design mit 80% Slice Auslastung in 2 min 55 sec bis zum PROM-File generiert. Gleiche Zeit bei PN-Flow und make-flow. 2006 habe ich für ein s3E-1000k noch deutliche Unterschiede erlebt so etwa 5 min versus 15 min. Wobei da noch 2,3 kleine Handoptimierungen dazu kamen (z.B. LOC-Constraint für DCM) die Optimierungen durch die Software unnötig machten. MfG
Kennt sich jemand mit Eclipse aus? Ich habe versucht das ans Laufen zu bekommen, (Keppler) erhalte aber die Fehlermeldung dass es keine Win32 Anwendung sei. Java ist drauf.
Java und Eclipse gibt es in 32 und 64 Bit. Beides muss zueinander passen. Grüße aus Thüringen
Duke Scarring schrieb: > Dafür gibt es passende Tools, wie ReqTracer. Wie habe ich mir das vorzustellen? Gehen wir mal von REQs aus, die man in einem Tool wie Doors vorliegen hat. Wie verknüpfe ich die dynamisch mit dem Source Code? Bislang kopiere ich einfach die REQ-Nummer dorthin.
Juergen S. schrieb: >> Dafür gibt es passende Tools, wie ReqTracer. > Wie habe ich mir das vorzustellen? > Gehen wir mal von REQs aus, die man in einem Tool wie Doors vorliegen > hat. Wie verknüpfe ich die dynamisch mit dem Source Code? > Bislang kopiere ich einfach die REQ-Nummer dorthin. Ich kenne Doors nicht (nur Windows ;-). Bei ReqTracer werden alle Dokumente (z.B. allg. Anforderungen, technische Anforderungen, Schaltpläne, Quellcode) in einem Projekt zusammengefasst. Über Tags wird dann ermittelt, welche Anforderungen schon erfüllt sind und welche nicht. Die Tags dürften Deinen REQ-Nummern entsprechen. Duke P.S.: Bisher habe ich in das Tool nur mal kurz reingeschnuppert.
Fritz Jaeger schrieb: > Gemeint ist das ein vom Projectnavigator (PN) angestossener Designflow > durch den höheren Ressourcenbedarf (Overhead) finde ich interessant, was Du da schreibst, vor allem im Hinblick auf das Thema RAM. Nach Deiner Auffassung sollte man also auf GUI verzichten, wenn es geht? Wie sieht es mit der grafischen Eingabe der FPGA / VHDL zur automatischen Dokumentation aus? Da läuft ja noch viel mehr, als nur etwas Projektnavigation.
HTI schrieb: > Fritz Jaeger schrieb: >> Gemeint ist das ein vom Projectnavigator (PN) angestossener Designflow >> durch den höheren Ressourcenbedarf (Overhead) > > finde ich interessant, was Du da schreibst, vor allem im Hinblick auf > das Thema RAM. Nach Deiner Auffassung sollte man also auf GUI > verzichten, wenn es geht? > Wie sieht es mit der grafischen Eingabe der FPGA / VHDL zur > automatischen Dokumentation aus? Da läuft ja noch viel mehr, als nur > etwas Projektnavigation. Fritz Jaeger schrieb: > Gemeint ist das ein vom Projectnavigator (PN) angestossener Designflow > durch den höheren Ressourcenbedarf (Overhead) Hallo HTI, das eine hat mit dem anderen wenig zu tun. Da Synthese nach Abschluß der Codeeingabe startet, besteht keine Notwendigkeit, beide glecihzeitig laufen zu lassen. Ideal ist es ohnehin einen Server ausschließlich für Synthese zu betreiben und Codeeingabe auf einen anderen Rechner zu bewerkstelligen. Da fast alle Text-Editoren eine GUI voraussetzen (spontan fällt mir mit dem vim nur ein einziger halbwegs auf VHDL optimierte Editor ein der auch auf einem /dev/tty läuft) ist ein Verzicht auf eine GUI während der Sourceeinstellung eine reichlich harte Selbstbeschränkung. Dagegen ist nach meiner Erfahrung ein script/makefile basiertes Designfile gegenüber dem Projektnavigator kein Verzicht sondern Gewinn. Das man für das Aufsetzen eines scriptes die toolchain-doku gelesen und verstanden haben muß, führt dazu dass man die tools beherrscht und nicht umgekehrt. Ist natürlich mit mehr Lernaufwand verbunden im Vergleich zum Trial und Error Häkchen setzen. Aber mehr Lernaufwand - mehr Wissen und mehr Wissen - mehr Macht (über den Computer ;-)) > Wie sieht es mit der grafischen Eingabe der FPGA / VHDL zur > automatischen Dokumentation aus? Der HDL-Designer ist mir geläufig, meiner Erfahtung nach dokumentiert der HDL-Designer aber keinen Code automatisch. Sondern damit wird grafischer "Code" erstellt, der in Grenzen selbstdokumentierend ist. Dokumentierend in dem Sinne, das sich die implementierte Funktion ohne Programmierkenntnisse erschliesst. Auch textuell kann selbstdokumentierter Code erstellt werden, zumal VHDL sich stark an natursprachliches Englisch anlehnt. Ich ziehe ein übersichliches Blockdiagramm (Visio, Inkscape, Handskizze) dem HDL-Designer vor. In einem Blockdiagramm kann man genau den Detailgrad unterbringen der zur Erläuterung nötig ist. Beim (synthesefähige) HDL-Designer Code dagegen müssen immer alle Signale etc gezeichnet werden. Und die Erstellung ist nicht unbedingt schneller als mit dem Emacs im VHDL-Mode. Abgesehen von dem Liniengewirr das schon genau geplant sein will damit es verständlich bleibt. Gruß,
> das eine hat mit dem anderen wenig zu tun. Da Synthese nach Abschluß > der Codeeingabe startet, besteht keine Notwendigkeit, beide > glecihzeitig laufen zu lassen Was ist bei paralleler Weiterentwicklung? > Sondern damit wird grafischer "Code" erstellt, der in Grenzen > selbstdokumentierend Von meiner Warte aus sehe ich ein Problem darin, dass viele FPGA-Programmierer aus der Softwareecke stammen und sich dort einen Entwicklungsstil angeeignet haben, wie Rumpelstielzchen. Ohne irgendein Konzept zu machen, wird drauflos gehämmert, zusammengeschrieben und später geändert ohne Ende. Der Weg zum Ziel ist bei FPGAs aber oft viel weiter, als bei z.B. C, weil erst einmal eine Hardware und ihre Verschaltung definiert werden muss, bevor überhaupt irgend eine Funktion da ist, deshalb ist schlampiges Vorgehen auf dem Sektor ungleich problematischer und zeitraubender. Die grafische Eingabe ist eine Methode, um den Entwickler dazu zwingen, darüber nachzudenken, was er macht und gleichzeitig ein Weg, eine verständliche Dokumentation der Arbeit zu erwirken. Die IDE wiederum gibt ein standardisiertes Vorgehen vor, das von allen Entwicklern verstanden wird. Das Sripten und makefilen verführt eher dazu, alles eigenbrödlerisch und individuell zu machen.
> Die grafische Eingabe ist eine Methode, um den Entwickler dazu zwingen > darüber nachzudenken, was er macht und gleichzeitig ein Weg eine > verständliche Dokumentation der Arbeit zu erwirken. Den Standpunkt hatte ich noch vor Jahren ebenfalls so vertreten. Inzwischen sehe ich das etwas differenzierter: Ich habe in der Vergangenheit mit verschiedenen grafischen Wwerkzeugen (Mentor HDL Designer, Siemens Data Flow, Xilinx Schematic, Altera Schematic, Labview FPGA, Diamond 3D (DSP+FPGA), MATLAB+Simulink) gearbeitet und alle auferlegten mir immer wieder Beschränkungen, was die volle Nutzung der in VDHL denkbaren und zur Umsetzung der Anforderung nötigen Funktionen angeht. Nicht selten waren einfache Sachen garnicht oder nur sehr umständlich zu formulieren. Das Grundproblem war immer, dass ich erst viele Zusatzfunktionen, Methoden und Denkweisen des Herstellers erlernen musste, um simple Dinge hinzubekommen, die dann aber keinen wirklichen Mehrnutzen hatten. Ein grossen Problem waren die programmtypischen Macken, Fehler, Mängel und Abstürze. Das Enttäuschendste war, dass die Grafik, die hinterher dabei rauskam, nicht wirklich zur besseren Übersicht beigetragen hat, weil es in einem gewaltigen Drahtverhau mündete, siehe auch das hier: Beitrag "Re: FPGA grafisch programmieren" Viele FPGA Designer, die ab und an grafisch arbeiten, beschränken sich daher darauf, die Signalverbindungen mit signal stubs zu realisieren, was dazu führt, dass ein grosses Sheet mit einer Ansammlung an Symbolen herauskommt, was nicht so wirklich besser ist Ich bevorzuge daher nach wie vor ebenfall die händische Dokumentation und zeichne einen übersichtlichen Datenfluss und/oder einige Schematics, um die wesentlichen und wichtigen Dinge aufzuzeigen und zu planen, gehe dabei aber spezifischer vor. Mithin sehe ich das ähnlich, wie Fritz Jäger. Für simple Funktionen braucht es keine Grafik, während verschachtelte Funktionen gar nicht genug Doku bekommen können. Meistens nutze ich dazu Excel, weil ich damit die Möglichkeit habe, Timings und Delays bei Modulen einzutragen und bei der Umplanung fortberechnen zu lassen. Das hilft bei der Ersterstellung enorm. Dazu kann man Busse und Signale in unterschiedlichen Darstellungen auch unterschiedlich farbig anlegen, um den jeweiligen Aspekt zu dokumentieren, z.B. die Zugehörigkeit zu einer bestimmten Domain oder einer Zeitebene, wie bei pipelines. Solch ein Output ist wertig, von jedem lesbar und hochgradig wiederverwendbar, sei es für Derivate oder neue Designs. Die Lesbarkeit durch andere und die Druckbarkeit ist bei Excel auch besser gegeben. Mit den mir bekannten Grafiktools ist das nicht annähernd möglich. Meist fehlen die Farben / Farbebenen, oftmals fehlt der Platz und das Blatt ist zu klein, die Schriften sind nicht lesbar oder skalierbar. Wenn man es farbig haben will, geht es oft nur über umständliche Symbolbearbeitung, wobei die Farben bei Aktualisierung des Sysbols teilweise wieder vergessen werden. Nervig ist, dass man bei der Neuplazierung von Bauteilen erstmal manuell Platz schaffen und Drähte umverlegen muss, um es hinlegen zu können, obwohl ein Tool das automatisch können sollte. Zu allem Überfluss werden dann völlig unsinnige Verbindungen erzeugt, wenn beim Verschieben irgendetwas ungewollt angeschlossen wird. Der grosse Denkfehler vieler tools ist, dass aus eine grafischen Liniengruppe eine logische Verbindung erzeugt wird, statt umgekehrt eine durch den Bediener vorgegebenen logischen Verbindung dynamisch grafisch darzustellen. Ein gewaltiges Problem ist die Portierung der Schematics in neue Versionen oder indie Tools anderer Hersteller. Protokolliert man mal den Aufwand, der dabei entsteht, so sieht man rasch, dass man mit getrennter Doku und VHDL besser hinkommt. Ich habe mehrfach schon Analysen zu dem Thema gemacht, z.T. auch den Firmen vorgelegt, für die ich tätig war und die Schlussfolgerung war immer dieselbe: *********************************************************************** Die grafische Repräsentationen von Schaltungen, deren Funktion und Timing, sowie das ausdrückliche bildliche Dokumentieren einiger wichtiger Aspekte ist gerade bei grösseren FPGA-Designs generell zu empfehlen, da in den meisten Fällen von grossem- bzw. in vielen Fällen wenigstens von mittlerem Vorteil. Die direkte grafische Programmierung mit den existenten tools jedoch leistet viele dieser Anforderungen nicht. Vielmehr stellen sie teils systembedingte / teils konzeptionelle (oftmals unnötige) Hürden in den Weg, da sie nicht gut durchdacht, oft schlecht programmiert und unvollständig sind. Damit wird die Arbeit in den meisten Fällen unproduktiv, teils frustierend und kontraproduktiv. Im Sinne einer flexiblen und der individuellen Anforderung angepassten Planung und Doku ist die manuelle grafiche Representation definitiv vorzuziehen. *********************************************************************** An diesem Sachverhalt wird sich nicht nur deshalb nichts ändern, weil die einschlägigen Hersteller nicht in der Lage oder Willens sind, geradlinige Konzepte aufzubieten sondern auch deshalb, weil die FPGA-Designs immer hetrogener werden. Quellen aus einem herstellerabhängigen SOC-builder müssen mit Algorithmen verheiratet werden, die ein Parser erzeugt hat, wie z.B. dem MATLAB HDL Coder. Auch müssen C-Programme aus einem ARM-Entwicklungsumgebung dynamisch gebunden werden.
:
Bearbeitet durch User
Die andere Frage, ob man mit der Hersteller-IDE oder lieber sriptbasiert arbeitet, sehe ich weniger kritisch. Von der einen Seite her hast Du durchaus Recht, wenn Du sagst: >Das Sripten und makefilen verführt eher dazu, alles eigenbrödlerisch > und individuell zu machen. Das muss aber nicht zwingend so sein und umgekehrt, garantiert die grafische IDE auch nicht, dass das Vorgehen ordentlicher oder strukturierter wird. Wenn die Grafikeingabe oder die IDE-basierte Methodik nämlich beginnt, umständlich oder hinderlich zu werden, beginnt meistens erst der Zeitdruck und die Schlampigkeit: Mir begegnen viele Design, die ursprünglich mal als Grafik begonnen wurden, bei denen es aber versäumt wurde, die diesbezüglichen Vorteile auch zu nutzen. Das Ergebnis sind gleichfarbige und gleichdicke Verbindungsdrähte, die eher verwirren, als aufklären und anonyme Signale, die man weder im Chip-Editor noch im Simulator wiederfindet. Das ist mehr Chaos als Nutzen. Spripte lassen sich genau so einchecken und dokumentieren, wie die IDE-file, wenn nicht noch besser. Am Ende müssen die Randbedingungen der Simulation und Synthese ohnehin in irgendeiner Weise festgehalten und aufgelistet werden, um sie verständlich zu halten und für einen Weiterbearbeiter nutzbar zu machen. Scripte erhöhen mitunter auch die Portierbarkeit, so nutzen die aktuellen FPGAs von Altera und Xilinx inzwischen beide SDCs. Ganz ohne Grafik bzw spezifischer IDE wird es natürlich nicht gehen, wenn man z.B. SOPC Systeme zusammenklickt. Man kann aber die Nutzung von IDE ohne Probleme auf solche Fälle begrenzen.
:
Bearbeitet durch User
Jürgen Schuhmacher schrieb: >> Die grafische Eingabe ist eine Methode, um den Entwickler dazu zwingen >> darüber nachzudenken, was er macht und gleichzeitig ein Weg eine >> verständliche Dokumentation der Arbeit zu erwirken. > Den Standpunkt hatte ich noch vor Jahren ebenfalls so vertreten. > Inzwischen sehe ich das etwas differenzierter: Wie stellst Du dann bitte sicher, dass der Entwickler den manuellen Plan immer konsistent hält zu dem, was er in VHDL Text eingibt? > Mit den mir bekannten Grafiktools ist das nicht annähernd möglich. Meist > fehlen die Farben / Farbebenen, oftmals fehlt der Platz und das Blatt > ist zu klein, die Schriften sind nicht lesbar oder skalierbar. Das gibt es die Möglichkeit, Hierarchien einzuführen und zu verwenden. Und Farben braucht man ja nicht unbedingt. > Nervig ist, dass man bei der Neuplazierung von Bauteilen erstmal > manuell Platz schaffen und Drähte umverlegen muss, um es hinlegen > zu können, obwohl ein Tool das automatisch können sollte. Musst Du bei einer manuellen Darstellung aber auch.
Angehängte Dateien:
-
96kHz-VASynth_Spartan3.gif
130 KB
HTI schrieb: > Wie stellst Du dann bitte sicher, dass der Entwickler den manuellen Plan > immer konsistent hält zu dem, was er in VHDL Text eingibt? Wie stelle ich sicher, dass der viel grössere Rest der Doku konsistent ist zum Stand der Entwicklung? Wie stelle ich sicher, dass das Grafikdesign den Requirements entspricht? Wie stelle ich sicher, dass das Sript das den Simulator steuert, die realen Abläufe im Feld widerspiegelt, die als Punkteliste in der Spec stehen? Wie stelle ich sicher, das die SW, die auf dem Softcore läuft, das tut, was in der SPEC seht? Die wird ja auch nicht grafisch eingegeben sondern existiert gfs nur als Prinzipablauf. > Das gibt es die Möglichkeit, Hierarchien einzuführen und zu verwenden. Hierarchien möchte ich dann erwenden, wenn es sinnvoll und angezeigt ist und nicht davon abhängig machen, was auf das Bild passt. Das Tool darf nicht durch seine Restriktionen vorgeben, wie ein Design logisch struktiert werden muss. Ausserdem sprengt schon ein mittleres Design das, was einem manche als Maximum so anbieten. > Und Farben braucht man ja nicht unbedingt. Da bin ich etwas anderer Ansicht. Mit den Farben erhöhe ich die Erkennbarkeit von domains und Taktabhängigkeiten auf einen Blick und erspare dem Betrachter das unnötige Suchen, wo ein Signal überall verwendet wird. Wenn Du Dir das Bild oben mal im Original ansiehst, wirst Du innerhalb von wenigen Sekunden sehen, welches Modul welchen Takt verarbeitet, wo es Domainübergänge gibt und wo nicht. http://www.96khz.org/files/2007/va-synth-spartan3-96k-video.png Man sieht auch sofort, was VHDL Schaltung ist und was echte FPGA-Hardware-Komponente wie PLL / Buffer ist. Mit den Farben kann ich Wichtiges markieren und die Zusammenhänge der Daten-Ports auf einen Blick verdeutlichen ohne dass Quelle und ihre Senken auf dem Blatt gesucht werden müssen. Im Vergleich zur Vorgängerschaltung ohne Video ist auf den ersten Blick zu erkennen, dass die Module anders getaktet wurden und es folglich bei der neueren Ausgabe mehr Synchronizer geben muss, wegen der komplexeren Domainstruktur etc. http://www.96khz.org/files/2006/va-synth-spartan3-96k.png >> Nervig ist, dass man bei der Neuplazierung von Bauteilen erstmal >> manuell Platz schaffen und Drähte umverlegen muss, um es hinlegen >> zu können, obwohl ein Tool das automatisch können sollte. > Musst Du bei einer manuellen Darstellung aber auch. Es geht zumindest in Excel aber einfacher. 2-3x "Zeilen einfügen" in X und Y und die Bauteile rücken zur Seite. Bei vielen tools muss ich erst das halbe Blatt selektieren und verschieben.
Man kanns auch übertreiben. Im Prinzip denke ich schon, dass man soviel wie möglich in ein Blockschaltbild packen soll, aber nicht durch die ganzen Ebenen hindurch. Im oberen Blockbild sind IBUF zusammen mit FF und irgendwelchen Komponenten dargestellt, wem soll das was bringen, erschließt mir persönlich überhaupt nicht. Ich mache alles ähnlich, nur eben mehr schematisch und wirklich nur, dass man das Prinzip versteht. Solche Details wie FF/MUXer, und schon gar solche spezielle Komponenten wie IBUF oder ODDR haben da meiner Meinung nach nichts verloren (sehr wohl aber Farben für unterschiedliche Clock-Domänen). Ist aber wohl Ansichtssache. Sollte sich konzeptionell was ändern, dann wird das Blockschaltbild eben nachgezogen. Passiert aber extremst selten, weil ich eben nicht ins Detail gehe. Grüße Kest
Kest schrieb: > Im Prinzip denke ich schon, dass man soviel wie möglich in ein > Blockschaltbild packen soll, aber nicht durch die ganzen Ebenen > hindurch. Das ist der physikalische Teil der Schaltung, so wie Du ihn auch mit eimem CAD Tool eingeben würdest, wenn die VHDL-Blöcke Chips wären, bzw es gar kein FPGA wäre. Ab diesem physikalischen Toplevel ist der Rest dann virtuelles Logikdesign. Ein Blockschaltbild hingegen wäre z.B. das hier: http://www.96khz.org/images/synthesizerstructure3.gif > Im oberen Blockbild sind IBUF zusammen mit FF und > irgendwelchen Komponenten dargestellt, wem soll das was bringen, > erschließt mir persönlich überhaupt nicht. Bezüglich der IBUFs kann man geteilter Meinung sein, weil sie mehr oder weniger an jedem Pin existieren aber schon bei den FFs macht es Sinn, zu unterscheiden, ob ein Design noch IOFFs in den Pins nutzt, oder nicht. Das ist für die Betrachtung bei der Latenz von Businterfaces wichtig, wenn nur das Logikdesign innen simuliert wird. Natürlich kannst Du die IOFFs auch im Design verstecken und sie in all jenen Ports als existent annehmen, wo Du per constraint welche hinkommandiert hast, aber ich zeichne sie hin, weil es sich um reale physikalische FPGA-Elemente handelt - im Gegensatz zu virtuellen FFs aus den rising_edge-Konstrukten im Logikdesign, welche hin-und her geschoben und wegoptimiert werden können. Die ODDR sind deshalb drin, weil man Takte (hier sind es Ref-Takte) auch halbiert über FFs ausgeben könnte. Zudem muss irgendwo die Polarität dokumentiert sein, wegen edge/center aligned Problematik und auch die ODDR sind physische FPGA-Resourcen. Natürlich stellt sich die Fraga, ob man sowas hinmalen muss, aber irgendwo muss es ja niedergelegt werden, also kann ich es auch eintragen. (Ist ja nur Copy-Paste :-)). Ansonsten muss man eben im VHDL nachsehen, wie der Buffer an D0,D1 beschaltet ist aber es ging ja gerade darum, ob Grafik verwendet werden soll.
:
Bearbeitet durch User
Kest schrieb: > Man kanns auch übertreiben. Ich habe es selten gesehen, daß die Dokumentation im Bereich FPGA übertrieben wurde. Meistens ist es doch umgekehrt: Die Leutz verrennen (um nicht zu sagen "verlieben") sich in ihre Erzeugnisse, tippeln und basteln vor sich hin und generieren gewaltige Textfiles, wo sie am Ende selber nicht mehr wissen, wo vorne und hinten ist. Am Schlimmsten sind die. die es für eine Leistung oder Qualitätsmerkmal halten, das angerichtete Chaos noch zu beherrschen. Wehe dem, es muss einmal ein anderer ran zum Ändern, dann ist aber die K...e am Dampfen! Im Zweifel lasse ich eher zuviel, als zu wenig Doku machen, weil ein paar Stunden mehr kaum etwas kosten im Vergleich zu dem, was jemandem an Einarbeitung in unbekannten oder schlecht dokumentierten Code bevorsteht. Da können kleinste Verständnisfehler oder -mängel schon zu viel unnötigem Suchen und falschem Weiterbauen führen und am Ende des Tages hat man mehr Änderungsverstrickung, als sonst was. Es kann nicht sein, dass man erst aufwändiges reengineering betreiben muss, um die Grundfunktionen einer Schaltung zu verstehen. Den Heinis, die immer noch glauben, man könne sich alles aus dem Code zusammensuchen, wenn man fit genug ist, gehört eins hinten drauf gekkloppt! Leider ist das aber eher die Regel, als die Ausnahme.
FPGA-Vollprofi schrieb im Beitrag #3370503: > Am Schlimmsten sind die. die es für eine Leistung oder > Qualitätsmerkmal halten, das angerichtete Chaos noch zu beherrschen. Ok, da ist wirklich was dran. Von der Sorte habe ich einige kennengelernt. Die hocken wie die Glucken auf dem Source Code und nur sie haben wirklich Ahnung, wo dort wie was genau funktioniert, weil es nirgendwo versinnbildlicht ist. Man muss aber sagen, dass sie da in der jüngsten Zeit viel getan hat. Siet Einführung von UML, Coding-Standards und milestone basierten Entwicklungen sind die Softwareentwickler (und ich sehe VHDL hier ausdrücklich im Bereich der Software!) immer mehr dazu gezwungen, ordendlich zu arbeiten, sich Konzepte zu machen, bevor sie starten und wenigstens ihr Machwerk zu dokumentieren. Nach meiner Erfahrung hängt dabei alle davon ab, wie genau die jeweilige Firma oder der Vorgesetzte hinsieht, bzw Anforderungen stellt. Oft kommen solche Anforderungen inzwischen ja auch aus Zertifizierungsvorschriften und Zulassungnormen, die es einzuhalten gilt. Meine Frage in dem Zusammenhang wäre: Gibt es sowas ähnliches wie SPICE oder DMMI auch in der Hardwarenahen Softwareentwicklung, konkret der VHDL-Entwicklung? Und dann: Mit welcher IDE kann man das erstellen? Gibt es für VHDL sowas wie einen UML-wrapper oder ein Abbild des Codes? Wie wird die Software für ein FPGA gemacht, das noch einen Prozessor enthält?
Softwerker schrieb: > Meine Frage in dem Zusammenhang wäre: Gibt es sowas ähnliches wie SPICE > oder DMMI auch in der Hardwarenahen Softwareentwicklung, konkret der > VHDL-Entwicklung? > > Und dann: Mit welcher IDE kann man das erstellen? Gibt es für VHDL sowas > wie einen UML-wrapper oder ein Abbild des Codes? > > Wie wird die Software für ein FPGA gemacht, das noch einen Prozessor > enthält? da sprichst du etwas an... Ich kenne kein gescheites System, vor allem, wenn man seine Designs auch fuer mehrere Hersteller (es faengt schon bei verschiedenen Devices eines Herstellers an) zur Verfuegung stellen will. Es ist und bleibt momentan 'Handarbeit'! @work habe ich momentan viele Designs (zum Glueck wenige die auch noch einen Soft-CPU-core verwenden), die auf jeweils mehrere Zielplattformen laufen sollen/muessen. Der 'Code' (VHDL oder Programm) ist da immer wieder dupliziert (wir verwenden Subversion als 'Ablage'), man muss also Aenderungen und Bugfixes immer in allen Designs von Hand nachziehen... Ist Schade, ist aber so, und ich hab' auch keine wirklich gute Idee wie man das besser loesen koennte... Aber zum Thema des Threads: Moeglichst alles zu einem Design in lesbaren ASCII Files zu halten und nicht ueber Tools (auch noch grafisch) eines Herstellers zu machen, halte ich fuer eine sehr gute Idee. Ein Textfile kann ich auf einer beliebigen Plattform ohne das jeweilige Tool installiert zu haben nach Jahren noch oeffnen/lesen und ich sehe dann, was da gemacht wird/wurde. Deshalb verwende ich auch nach Moeglichkeit keine herstellerspezifische Tools um z.B. einen Fifo oder ein RAM zu beschreiben. Generisches VHDL ist da einfach besser... Zum schnellen arbeiten mal in der GUI rumklicken ist ja ok, aber wenn es etwas 'dauerhaftes' sein soll, dann moeglichst generisch. Und das ist halt ein STINO ASCII-File... Um einen fremden Design zu analysieren oder verwenden zu wollen muss es moeglich sein einfach einen Texteditor (mit Syntaxhighlighting) anzuwerfen. Und dazu gehoeren nicht nur die Designs, sondern auch die Toolchain zum zusammenbauen (also Toolaufrufe in lesbarer Form). Ist nicht das Optimum, aber im Moment das was mit den Tools moeglich ist...
HTI schrieb: >> das eine hat mit dem anderen wenig zu tun. Da Synthese nach Abschluß >> der Codeeingabe startet, besteht keine Notwendigkeit, beide >> glecihzeitig laufen zu lassen > > Was ist bei paralleler Weiterentwicklung? > >> Sondern damit wird grafischer "Code" erstellt, der in Grenzen >> selbstdokumentierend > > Die grafische Eingabe ist eine Methode, um den Entwickler dazu zwingen, > darüber nachzudenken, was er macht und gleichzeitig ein Weg, eine > verständliche Dokumentation der Arbeit zu erwirken. A fool with a tool is still a fool. Deutsch: Tolle Tools machen aus einem Narren keine(n) Entwickler/-in der/die gute Designs bliefert. Zur Sicherstellung der Code-qualität haben sich bewährt: -Style Guides (Konventionen by der Namensvergabe, erlaubte Konstrukte, etc) -moderierte und vorbereitete Codereviews -Reuse von Kompnenten aus Firmenbibliothek (Register-package, aber auch Counter, IF zu Peripherie) > Von meiner Warte aus sehe ich ein Problem darin, dass viele > FPGA-Programmierer aus der Softwareecke stammen und sich dort einen > Entwicklungsstil angeeignet haben, wie Rumpelstielzchen. Ohne irgendein > Konzept zu machen, wird drauflos gehämmert, zusammengeschrieben und > später geändert ohne Ende. Meines Erachtens liegt die konzeptlose Programmierweise genau daran das die Entwickler keine Orientierung haben, wie man das macht. Sie haben es in der Hochschule nichtgelernt und in der Firma findet sich auch keiner der sie dazu befähigt. Also Richtlinien an die hand geben, templates für Dokumente zur Vefügung stellen und hand eines bestehenden Projektes einarbeiten lassen. Aber da bisher in der Firma nie struktiriert FPGA's gebaut worden, sind die neuen FPGA-Entwickler überfordert und scheitern daran sich selbt eine Orientierung vorzugeben. MfG,
Softwerker schrieb: > Meine Frage in dem Zusammenhang wäre: Gibt es sowas ähnliches wie SPICE > oder DMMI auch in der Hardwarenahen Softwareentwicklung, konkret der > VHDL-Entwicklung? Mit dem Kürzel DMMI kann ich und meine internetbasierten Gedächniserweitungenen nichts anfangen. Was ist das? (Neugierig wie immer) Softwerker schrieb: > Und dann: Mit welcher IDE kann man das erstellen? Gibt es für VHDL sowas > wie einen UML-wrapper oder ein Abbild des Codes? Genau genommen brauchst du keinen UML-Wrapper sondern ein Tool für SysML, das einen Im-/Export von VHDL kann. SysML ist aus UML entstanden, damit komplette Systeme und nicht nur Software modeliert werden kann. Requirements und Nebenläufigkeit gehören fix dazu. Details: https://de.wikipedia.org/wiki/SysML http://www.sysml.org/ In unserer Firma wird von den Applikationssoftware Entwicklern für UML Enterprise Architekt eingesetzt, die haben in einer grösseren Version auch SysML und VHDL Unterstützung (Aus Mangel an Lizenz kann ich das leider nicht testen. Und nein wir FW Entwickler nutzen kein UML, auch keine Versionverwaltung und z. B. kein Doxygen... Man sieht von weitem wer Elektrotechnik und wer Softwareentwicklung studiert hat). http://www.sparxsystems.com/products/mdg/tech/sysml/index.html
Fritz Jaeger schrieb: > A fool with a tool is still a fool. Deutsch: Tolle Tools machen aus > einem Narren keine(n) Entwickler/-in der/die gute Designs bliefert. Deine Worte in der Firma Mathworks Ohr :-) Ich stimme vollkommen zu, wobei dies hier: > Zur Sicherstellung der Code-qualität haben sich bewährt: > -Style Guides (Konventionen by der Namensvergabe, erlaubte Konstrukte > -moderierte und vorbereitete Codereviews > -Reuse von Kompnenten aus Firmenbibliothek (Register-package, aber auch > Counter, IF zu Peripherie) ... mehr Umsetzungsthemen sind und noch nicht die Frage klären, woher das gute Design, also die Schaltungstruktur und das algorithmische Konzept kommen. Die entstehen dann letztlich doch irgendwo im Kopf. Ich finde es daher immer wieder bezaubernd zu sehen, dass diesbezüglich einerseits angenommen wird, dass der Designer in der Lage ist, komplexe Konzepte zu erdenken, man ihm andererseits aber unterstellt, er wäre nicht in der Lage, diese adäquat zu formulieren und zu dokumentieren und bräuchte dazu Zwangsmassnahmen, wie den fixen Zusammenhang zwischen Grafik und Code.
berndl schrieb: > Und dazu gehoeren nicht nur die Designs, > sondern auch die Toolchain zum zusammenbauen (also Toolaufrufe in > lesbarer Form). Da ist was dran. Wobei das Anschubsen der Tools mit einer tauglichen config noch nachzuarbeiten wäre. Da gibt es noch einiges mehr: Das fängt bei den Megawizzards an und hört bei den CoreGens auf. Oft liegt bei unbekannten Designs nur das Ergebnis vor, nicht aber das, was dazu geführt hat. Vor allem die Überlegung, was warum wie konfiguriert wurde, fehlt. Anpassungen auf neue Tool-Versionen sind da erschwert bis unmöglich.
Es gibt ein VHDL Plugin für den gedit. Funktioniert mit der gedit Version 3.10. Link mit Screenshot: http://redd.it/27mqhn
Tippgeber schrieb: > Verwendet jemand das hier: > http://www.gmvhdl.com/VHDLStudio.html Ich hatte mir das seinerzeit mal angeschaut. Aber leider scheint das Projekt auf der Zielgeraden verhungert zu sein:
1 | Copyright (c) 2001 Green Mountain Computing Systems |
2 | ... |
3 | © 2008 Green Mountain Computing Systems |
Beitrag #5294549 wurde von einem Moderator gelöscht.
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.