Welche VHDL IDE benutzt ihr?

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

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,

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

Ich nutze geany.

Ja, habs dann doch gefunden. Ich hatte gleich auf "Buy Online" geklickt 
im Untermenü :) Naja, Tomaten auf den Augen....

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

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

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

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.

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.

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.

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.

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.

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

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

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.

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ß,

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

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.

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.

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.

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.

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