FPGA-Projekte planen und dokumentieren

[Tazitus (Gast)]

Wie werden bei euch FPGA-Projekte aufgesetzt und dokumentiert?

Wir haben das Problem infolge der INSO eines Zulieferers verschiedene 
Projekte importieren und nachdokumentieren zu müssen.

Offen ist, was benötigt wird und was nicht.

Und: Wie man Formalien mit Realität verknüpft.

Momentan hängt es am Praktischen:

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

[Strubi (Gast)]

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

[Schriftforscher (Gast)]

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.

[Tazitus (Gast)]

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.

[Zack - so isses (Gast)]

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 (Gast)]

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.

[J. S. (engineer)]

Zack - so isses schrieb:
> Hardwareentwickler ne ganze
> Menge in Form von Messreihen, Testautomatisierung/Prüfpattern/Waveform -
> Bilder vom Scope/LA oder Simu.

Beim Testen (im Endprozess) "Ja", beim "Testen" im Rahmen der 
Entwicklung (eigentlich Verifikation) Noch weitgehend "Ja" aber beim 
Planen und allem, was Ablauf ist, sieht es schon schlechter aus. Das 
Problem bei SW ist eben, dass da praktisch viel dokumentiert werden muss 
und wenn klassische Hartwerker das tun, wird kaum was gemacht.

Beim FPGA treten dann auch noch beide Aspekte auf und die Wenigsten 
haben gleich viel SW- und HW- Background, bevor sie mit FPGAs anfangen. 
Irgendeine Hälfte fehlt meistens.