FPGA-Projekte planen und dokumentieren

Moin,

Kurzantwort (für importierte Projekte :-) ):

- Sourcecode-Doku: Doxygen
- Reverse-Engineering: GHDL Doku-Output (xrefs, etc.)
- Top-Level: Docbook XML

Tazitus schrieb:
> Was von den Sourcen, Dokumenten und Codes /IPs muss wie dokumentiert
> werden, damit ein Auditor zufrieden ist?

Hängt vom Auditor ab. Ich denke mal, gute Karten hast Du, wenn Du die 
Struktur der Module dokumentieren kannst (das kriegt Doxygen gut hin, 
aber man muss auch selber eine Menge sinnvolle Doku-Strings einfügen). 
Ob der Code dann wirklich was taugt, ist ne ganz andere Geschichte, da 
wird dann einer Test-Benches und Regressions-Tests schreiben müssen.

Gruss,

- Strubi

Tazitus schrieb:

> Was von den Sourcen, Dokumenten und Codes /IPs muss wie dokumentiert
> werden, damit ein Auditor zufrieden ist?

Ich würd mal sagen wichtiger als Dok zu den sourcen sind die specs 
und/oder Requirements. Schließlich will man ja wissen was das Design tun 
soll. Das was es tut sollte man anhand der Testbench/Integrationstest 
nachweisen. Listing der Files wäre auch gut, und Code 
style/namenskonventionen.

Solche Standards werden schon erarbeitet, ok. Was mich noch bewegt: Wie 
plant man ein FPGA-Projekt?  Als Hardware in Software oder umgekehrt?

Für die Software haben wir schon Richtlinien und Spezifikationsvorlagen. 
Für die Hardware gibt es nichts, weil die Hardwareentwickler naturgemäß 
nichts dokumentieren, was sie nicht müssen.

Tazitus schrieb:
> Für die Software haben wir schon Richtlinien und Spezifikationsvorlagen.
> Für die Hardware gibt es nichts, weil die Hardwareentwickler naturgemäß
> nichts dokumentieren, was sie nicht müssen.

Doch doch für Hardware gibt es auch Entwicklungs-Richtlinie wie für die 
Software. Beispielsweise Fliegerei: DO-278 für die Software und DO-254 
für Hardware.

Und nach meiner Erfahrung dokumentieren Hardwareentwickler ne ganze 
Menge in Form von Messreihen, Testautomatisierung/Prüfpattern/Waveform - 
Bilder vom Scope/LA oder Simu. Ist halt ausserhalb des Verständniss von 
"Dokumentation" eines Softwerkers.

Zack - so isses schrieb:
> Doch doch für Hardware gibt es auch Entwicklungs-Richtlinie wie für die
> Software. Beispielsweise Fliegerei: DO-278 für die Software und DO-254
> für Hardware.

Korrektur DO-178 für Software.