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.
Wie setzt man eigentlich Attribute wie "keep" im Schematic? Geht das überhaupt?
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.
Angehängte Dateien:
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.