Unser aller Cheffe hat heute seine Vorliebe für Dokumentation entdeckt
(oder irgendein Q-Fritze hat es für ihn entdeckt und/oder ihm Beine
gemacht) und uns eine Vortrag gehalten, dass die Designs besser
dokumentiert werden müssen, um die Wiederverwertbarkeit zu steigern.
Da die geschätzte Xilinx ISE ja inzwischen sehr stabil läuft und kaum
noch Abstürze zu verzeichnen sind, wird offen in Erwägung gezogen, den
Designern (und damit auch mir) aufzugeben, in Zukunft schematic based zu
arbeiten, wozu ich erstens keine Lust habe und zweitens auch keinen
echten Sinn sehe.
Wie bringe ich den Kritikern bei, dass das ein Hohlweg ist?
Das Argument, dass ISE angeblich eingefroren wird, lässt man nicht
gelten, weil "das noch nicht offiziell ist" und "wir ISE noch mindestens
3 Jahre nutzen und bis dahin auch keine neueren FPGAs eingesetzt
werden".
Durch die Benutzung der SCH soll der Designer gezungen werden, sauber zu
dokumentieren, bevor er lossynthetisiert.
Die ISE wird just im Moment schon wieder komplett umgebaut
(Planahead...)...
Schematic ist hirnfick. Vielleicht - wirlich nur vielleicht -
sinnvoll, um die Toplevel-Entitäten miteinander zu verdrahten und so den
(hoffentlich) modularen Aufbau des Designs hervorzubringen.
Aber Verhalten als Schematic zu beschreiben, ist totaler Schwachsinn.
Sehr viel Arbeit wird doch gerade in die Synthetisierer für VHDL und
Verilog gesteckt, damit man eben nicht mehr Gatter für Gatter
verdrahten muss, sondern das formuliert, was man auch meint.
ich würde Versionshistorie als Grund setzen. Ich weiß nicht wie man in
Schematic Änderungen verfolgen kann. Ich kann es mir aber nicht
vorstellen, dass es mit SVN oder GIT mithalten kann.
Das Einzige, was als Schematics noch akzeptabel sein könnte, ist es (wie
erwähnt) die Struktur zu verdrahten. Und dann nach Serieneinführung
daraus eine VHDL Beschreibung zu erzeugen. Die kann dann auch noch nach
15 Jahren gelesen werden. Dass das mir einer Schematic geht, wage ich zu
bezweifeln.
Aber niemals wird es Sinn machen, die Funktion mit einem Schaltplan zu
beschreiben. Denn gerade diese Module sollen ja wiederverwendet werden.
Und das Argument mit dem Versionsmanagement lässt sich auch auf so
simple Tools wie Windiff (Textvergleicher) ausdehnen.
Michel schrieb:> Wie bringe ich den Kritikern bei, dass das ein Hohlweg ist?
garnicht.
Gewöhne dir lieber an, als Toplevel tatsächlich Schematics zu benutzen.
Das ist ein durchaus probates Mittel gegen das "geniale" Schlampertum.
Obendrein erleichtert es die Konversation mit den Leuten, die die
Elektronik rings um dein genial programmiertes FPGA machen müssen.
W.S.
Versionskontrolle ist das Totschlagargument, das geht nämlich mit den
Binär-Files für die Schematic überhaupt nicht sinnvoll. Und ich sehe
keine Übersichtsprobleme auch wenn das Top-Level als VHDL gemacht ist.
Notfalls größere Unterblöcke machen. Ich knall ja nicht 40 Module direkt
ins Top-Level. Außerdem arbeitet ISE extrem instabil im Schematic-Edtor,
bei jeder Änderung wird man wahnsinnig beim Leitungen schubsen, Labels
verschieben....gruselig. Einfach mit erhöhten Kosten durch mehr
Fehleranfälligkeit und Ineffizienz argumentieren. Kannst dem Chef ja zur
Doku einen RTL Schaltplan generieren lassen, wenn er das geil findet
(finden muss).
W.S. schrieb:> Das ist ein durchaus probates Mittel gegen das "geniale" Schlampertum.
Ich sehe schon, wir werden W.S. anstellen, um für uns die Schaltpläne zu
machen :-)
Hast Du Dir den HDL Designer schonmal angesehen?
Ich meine jetzt nicht die Funktion um dort Schematics zu erstellen,
sondern die einem VHDL Code graphisch mittels Flußdiagrammen und
FSM-Bubbles darzustellen.
Ich hatte mal eine 14 Tage Testversion und zum dokumentieren von VHDL
Code finde ich es nicht schlecht. Sicherlich gibt es hier und da Macken,
aber die hat jede Software. Screenshot von der graphischen Darstelleung
machen, ablegen und glücklich sein. Hilft manchmal auch ungemein fremden
Code im Ansatz zu verstehen.
Sicherlich HTML Reports, etc. gehen auch - aber ehrlich gesagt reicht
mir zur Doku häufig nen Screenshot von der Simulation sowie eine kleine
graphische Aufbereitung als Erinnerungshilfe.
Desweiteren kann der HDL Designer noch viel mehr, aber pssst nicht alles
dem QMler erzählen sonst muss nachher der Code von irgendwelchen
bekloppten Rulechecks (vom QMler definierten) durchlaufen werden.
Eine firmeninterene Definition von wichtigen Signalen oder Strukturen
kann man auch anregen, aber auch hier gilt weniger ist mehr und soll nur
dazu dienen anderen Entwicklern das Modul schneller zu verstehen...
Ich persönlich würde dringend dazu raten, (auch) den VHDL-Code zu
sichern!
Als ein Argument wurde ja schon Versionskontrolle genannt - ich hoffe,
Ihr verwendet sowas? Falls nicht, wäre die Einführung eines solchen
Systems wesentlich sinnvoller als die Umstellung auf Schematics -
Versionskontrolle ist nämlich nicht nur "Archivieren und Vergessen",
sondern dient auch und hauptsächlich zur einwandfreien Rückverfolgung
von Änderungen (Change Management), Vergleichen von Codes verschiedener
Revisionen (Diff) und Zusammenführen von Codes (Merge).
Ein weiteres Argument: Gerade WEIL eine verbesserte
Wiederverwendbarkeit gefordert wird, ist es das mit Abstand Sinnvollste,
den Quellcode, welcher einem definierten und weit verbreiteten Standard
entspricht, aufzuheben, als ein proprietäres Schematic-File, mit dem u.
U. in ein paar Jahren niemand mehr etwas anfangen kann. Wenn man beim
VHDL-Design noch die gängigen Regeln beachtet (z. B. "nur eine Clock für
das System" etc.; so etwas kann man sinnvollerweise als
unternehmensweite Entwicklungsregeln festlegen) und die Verwendung von
IP-Cores vermeidet, geht es fast nicht portabler.
Für die "Zuarbeit" kann z. B., wie schon erwähnt, der VHDL Designer
eingesetzt werden, um State Machines o. ä. grafisch zu illustrieren, und
die Quellcodedokumentation kann z. B. mit Doxygen erfolgen. Das ist IMHO
der sinnvollste Weg.
Doxygen und HDL Designer halte ich für übertrieben.
Wenn man VHDL vernünftig strukturiert programmiert, sich an ein paar
einfache Regeln hält und ggf. den ein oder anderen Process im Quellcode
mit 1-3 Zeilen dokumentiert reicht dies häufig.
Der Einsatz von einer Versionsverwaltung sollte dazu führen dass der
Code aufgeräumt bleibt und keine Kommentar-Roman wie "folgendes
funktionierte mal, aber ... bevor ich den Code lösche lasse ich lieber 5
km kommentierten Code stehen".
Je mehr Dokumentation gefordert ist, desto mehr ist der Entwickler
eingeschränkt und ggf. führt es dann dazu dass a) alte Kommentare nicht
bei Codeänderung geändert werden oder b) jede zweite Zeile kommentiert
wird...
Also daher meine persönliche Empfehlung (ja und da hat jeder eine
eigene)
- firmeninterne Styleguide mit den wichtigen Signalnamen und
-konstrukten (3-5 Seiten reichen meist) (clk-Name, reset-Name, fallende
Flanke, steigende Flanke, Signale synchronisiert, Signale delayed, State
Maschine State-Namen (z.B. etx für end of transmission, stx - start of
transmission), etc.)
- sinnvolle Signalnamen
- einheitlicher Header mit kurzer Modulbeschreibung und
Schnittstellenbeschreibung
- Prozesse wenn nötig blockweise in 1-3 Zeile kommentieren
- Quellcode äufräumen und einrücken (EMacs oder Sigasi machen das ganz
gut)
- Versionsverwaltung einsetzen
- Testbenches schreiben und auch pflegen, d.h. nicht nur am Anfang der
Entwicklung und irgendwann passen die Entities nicht mehr
- Simulationsergebnisse dokumentieren, zB. Screenshot
- graphische Aufbereitung mittels HDL Designer
- Designregeln beachten (nur 1 Clock, ggf. Clk-Enable, keine Gated
Clocks, keine asynchr. Resets...)
- bei Modulen bei denen es Sinn mach Generics oder Constanten nutzen
- Zähler wenn möglich mit Constants flexibel halten
- allerdings macht es bei einfachen Modulen ggf. mehr Arbeit ein Modul
für 98 Generic Konfigurationen zu testen als es ggf. bei einem Reuse
anzupassen.
1. Frage: Kann man in Schematic Toplevel-Beschreibungen mit generischen
Instanziierungen vornehmen?
Dies ist dann wichtig, wenn man Designs hat, in denen eine generische
Anzahl an Komponenten (via GENERATE) instanziiert werden soll. Wozu
generisch? Der Wiederverwendbarkeit halber ... ;-)
2. In VHDL ist man im Toplevel gezwungen, ALLE Netze sinnvoll zu
benennen. Im Schematic? Nicht unbedingt, $75n4...
3. Wenn ich eine Subkomponente ändere, muss ich, um sie im
Schematic-Toplevel zu instanziieren, ein neues Symbol der Subkomponente
erstellen. Lästig, lästig ...
4. Im VHDL-Toplevel kann ich sinnvoll Gruppierungen und Formatierungen
vornehmen (Stichwort: BLOCK)
5. Im VHDL-Toplevel kann ich sinnvoll Kommentare einfügen
6. Wenn man unbedingt ein Schematic braucht, um grob alle Komponenten zu
überblicken, so kann man sich dieses z.B. in SynplifyPro generieren
lassen. Dort kann man sogar in der Hierarchie navigieren.
VG, SuperWilly
Michel schrieb:> Wie bringe ich den Kritikern bei, dass das ein Hohlweg ist?
Durch ein gemeinsames Gespräch, bei dem jede Partei gleichberechtigt zu
Wort kommen darf. Dabei werden zunächst alle Wünsche und Probleme auf
den Tisch gelegt und dann sachlich argumentiert um gemeinsam einen
effektiven Lösungsweg zu finden.
Warum schreien gleich alle VHDL? Im Kern geht es doch um ein
Kommunikationsproblem.
Joe G. schrieb:> urch ein gemeinsames Gespräch, bei dem jede Partei gleichberechtigt zu> Wort kommen darf. Dabei werden zunächst alle Wünsche und Probleme auf> den Tisch gelegt und dann sachlich argumentiert um gemeinsam einen> effektiven Lösungsweg zu finden.
nenne mir eine firma wo das so gehandhabt wird
graphische repräsentationen sind schon sinnvoll
aber wer sagt, dass man die mit dem design 1:1 verknüpfen muss?
wenn man mehrere versionen eines programm codes will, reicht normal ein
schalter - will malt man das auf?
Hallo,
ich verwende hier schon seit mehreren Jahren Ease von HDL Works, in
Verbindung mit einem Styleguide. Mit Ease wird das ganze Projekt
verwaltet. Das Teil hat einen guten grafischen FSM-Editor und man kann
sich schnell durch die Hierarchie klicken. Das kommt einem insbesondere
bei ständig unterschiedlichen Projekten entgegen. Alte
Projekte/Bibliotheken lassen sich auch gut importieren. Natürlich wird
dabei aus einer Text-FSM keine grafische. Aber die Hierarchie wird
grafisch abgebildet.
Aus den Grafiken wird dann VHDL generiert. Die interne Datenbank ist
XML, geht also gut in die Versionsverwaltung. Wenn man will kann man
auch eine Version kaufen, die die Versionsverwaltung direkt unterstützt.
Zur Dokumentation kann man HTML und PDFs erzeugen, kommt gut bei
Design-Reviews.
Ok, das Teil kostet etwas, ist aber deutlich billiger als der HDL
Designer aber deutlich besser als die Tools der FPGA-Hersteller.
wenn es um die Dokumentation geht, finde ich Doxygen besser geeignet.
Vielleicht kannst du mit einem besserem Tool überzeugen.
Ich habe es auch nur sporadisch eingesetzt.
Es ist aber sehr wirksam nutzbar.
Ich habe letztens Doxygen und auch VhDocl ausprobiert. Und das Doxygen
hat mir richtig gut gefallen. (Ok, ich hatte es auch schon für C++
benutzt).
Ich möchte nicht von Hand irgendwelche Bildchen malen, die nach einer
Code-Änderung auch mühsam umgezeichnet werden müssen. Wenn, dann sollte
das automatisch gehen. Und da ist für mich Doxygen praktischer.
Und Schematics sind nichts für mich, ich bevorzuge richtigen Quellcode.
