Hallo,
wir setzten kleine bis mittlere Projekte in VHDL um. Momentan gestaltet
es sich jedoch so, dass mehrere Entwickler an ihren eigenen Projekten
schreiben und viel Code einfach mehrfach geschrieben wird.
Wie ist Eure Erfahrung mit Code Reuse und der Möglichkeit diese in
firmeninterne Bibliotheken zu packen?
Wie kann ich allgemeine Module die getestet und dokumentiert sind gegen
Modifikationen von den Kollegen schützen?
Macht es hierfür Sinn diese Module in ein Versionsmanagment zu
überführen? Die Codequalität ist sicherlich unterschiedlich, aber gerade
hier wollen wir interene Richtlinien aufstellen.
Welche weiteren Tools machen hierfür ggf. Sinn. Oder wie handhabt Ihr
das? Vertraut Ihr dem Code von Kollegen oder nur das was Ihr selbst
geschrieben und getestet habt? Oder
Freddy
> Wie ist Eure Erfahrung mit Code Reuse und der Möglichkeit diese in> firmeninterne Bibliotheken zu packen?> Wie kann ich allgemeine Module die getestet und dokumentiert sind gegen> Modifikationen von den Kollegen schützen?> Macht es hierfür Sinn diese Module in ein Versionsmanagment zu> überführen?SVN oder GIT ist natürlich Pflicht! Da lohnt sich ein SVN nur für
projektübergreifende Module. Die Entwickler checken dann einfach beide
SVNs im gleichen Pfad aus, so dass man relative Pfadangaben benutzen
kann.
> Die Codequalität ist sicherlich unterschiedlich, aber gerade> hier wollen wir interene Richtlinien aufstellen.
Da lohnt sich ein kurzer Styleguide, zB wie Input und Outputs auszusehen
haben, oder welche FSM-Schreibweise benutzt werden darf. Klar schafft
man es ab und an nicht 100% der Vorgaben zu erfüllen, aber selbst wenns
nur 90% sind, dann ist es schon sehr Übersichtlich und Einheitlich.
> Welche weiteren Tools machen hierfür ggf. Sinn. Oder wie handhabt Ihr> das?
Evt. noch ein Bugtracker oder nen Trac für die Doku. Sowas erzeugt
allerdings auch großen Overhead und sollte gut abgewägt werden.
> Vertraut Ihr dem Code von Kollegen oder nur das was Ihr selbst> geschrieben und getestet habt?
Vollständige Testbenches müssen natürlich vorhanden sein. Nachweis meist
durch Coverage + Constraint Random Verification. Wenn das nicht da ist,
benutze ich kein fremdes Modul!
Hallo,
bin zwar komplett VHDL / FPGA fremd. Ich komm eigentlich aus der reinen
Software ecke.
Versionierung von Software (dazu zähl ich jetzt auch mal VHDL code) ist
immer sinnvoll. Dadurch lassen sich z.B. Versionen miteinander
vergleichen, Fehler die mal weg waren und wieder auftauchen finden, Auf
alten software Ständen aufsetzen, ...
Das wilde modufizieren von code läst sich meist nicht ganz vermeiden.
ggf sind ja anpassungen notwendig bzw erweiterungen die nicht immer für
alle gelten können. bzw wieso tonnen von code mitschleifen, nur weil ich
eine funktion brauche. Das dann in einer Versionsverwaltung abzubilden
wird gelinde gesagt hässlich.
Im prinzip ist jedes Modul ein eigenes Projekt das unter
Versionskontrolle steht. Ein Hauptprojekt "verweist" jetzt auf die
Module.
Hier gibt es für mich eigentlich 2 möglichkeiten. 1. das Modul
auschecken, und die dateien in das Projekt kopieren(Will man eigentlich
ja nicht). oder 2. Das Versionierungs tool unterstützt das. Wie das hier
im einzelnen genau funktiuniert, hängt vom System ab.
Und damit gehen die Proleme schon los.
Nehmen wir an ein Modul X wird in Projekt A und B verwendet. läst sich
sicher schön in der Versionskontrolle einrichten. Nur in Projekt B wird
eine spezielle anpassung benötigt, die sollte aber so Versioniert
werden, damit A diese nicht mitbekommt. Und jetzt kommt zu allem
überfuss noch ein Projet C, in dem ein kleiner Fehler / unschönheit in
dem Modul beseitigt wurde. Diese sollte nach möglichkeit ja wieder alle
zu sehen bekommen und einpflegen können. das geht alles, nur mit
entsprechendem Aufwand und Disziplin.
Subversion oder Git könnte man sich mal dafür anschauen.
Flensen schrieb:> Vollständige Testbenches müssen natürlich vorhanden sein. Nachweis meist> durch Coverage + Constraint Random Verification. Wenn das nicht da ist,> benutze ich kein fremdes Modul!
womit macht Ihr die Tests? Mit Extra-Software oder beispielsweise mit
der freien Implementierung von Synthworks?
123 schrieb:> Das wilde modufizieren von code läst sich meist nicht ganz vermeiden.> ggf sind ja anpassungen notwendig bzw erweiterungen die nicht immer für> alle gelten können. bzw wieso tonnen von code mitschleifen, nur weil ich> eine funktion brauche. Das dann in einer Versionsverwaltung abzubilden> wird gelinde gesagt hässlich.
in VHDL kann man seinen Code optimieren. z.B. auf Geschwindigkeit oder
auf die Fläche. Es wird halt alles in Hardware geschrieben.
In der Software sieht man das eher wenn beispielsweise Inline Assembler
benutzt wird. Das sind aber meist die Härtefälle.
Daher ist das wilde modifizieren immer ein gewisses Risiko. Aber im
Gegensatz zur Software kann man in VHDL nur im gewissen Maße allgemein
die Funktion beschreiben. Die Schnittstellen sollten in einem Modul fest
sein und es gibt immer Kollegen die damit nicht klarkommen.
Bei der Busbreite und kleiner Dingen kann man sich mit Generics oder
einem Package helfen, aber ein Modul allgemein zu halten ist natürlich
immer mehr Aufwand als eins nur für sein Projekt zu schreiben.
Hi,
Ohne source code manamgenent (SCM) sollte man gar keine
Gemeinschaftsprojekte anfangen, da verbrät man sowas von Zeit.
Was '123' sagt, kann ich voll unterschreiben, hatte in der Vergangenheit
viel mit Codemanagement zu tun, das lässt sich genauso auf VHDL
anwenden.
Ansonsten ist so ein kleiner Wiki oder ein "developers manual" nicht
schlecht, das man jedem Neuankömmling (oder auch Bewerber) mal auf den
Tisch legen kann. Wenn daran schon herumdiskutiert wird, weiss man
Bescheid :-)
Den Leuten vorzuschreiben, welchen Editor sie benutzen sollen, ist bei
Profis sinnlos und kontraproduktiv. Nur bei gewisser Code-Notation wie
dem IMHO unleserlichen GNU-Style gab's 'Verbote'. Ansonsten würde ich
eher darauf achten, dass genau eine Person per Modul Dateien editiert.
und CR/LF versus CR sowie Tabulator versus Space konsistent behandelt.
Ansonsten gibt es ne Menge Tools, die den Formatkram automatisieren
(gerade in Verbindung mit SCM).
Bei VHDL hatten wir uns mal drauf geeinigt, dass Components aus der
Library, die mit Grossbuchstaben anfangen, vom Interface und dem
Verhalten nicht mehr geändert werden dürfen. Die mit
Kleinbuchstaben-Notation hingegen schon, sofern alle Abhängigkeiten
aufgelöst werden.
Für Software hatten wir mal eine Tinderbox am Laufen, die bei jedem
zentralen Check-In das Programm neugebaut hat. Machte einer den Code
"kaputt", bekam er gleich automatisch ne Mail, sobald die Testbench
fehlschlug. Könnte man auch für VHDL machen, aber lohnt vermutlich erst
ab einem CPU-Design mit > 10 Entwicklern..
Das mit dem Code Resue ist so eine Sache: Wenn man VHDL so auffasst, wie
ich das tue, nämlich als eine Art Pflichtenheft als Vorgabe für den
virtuellen Layouter (die Synthese), dann macht der Versuch, auf
Wiederverwertbarkeit zu achten, soviel Sinn, wie beim Worddokument
einzelne Textbausteine in der GA neuer Produkte wiederzuverwenden - ist
also von begrenztem Wert.
Das, was man wirklich braucht, sind Standardteile wie Interfaces und die
gibt es wie Sand am Meer und als Core. Andersherum ist ja das, was man
im Detail braucht, eben gerade nicht da. Deshalb wird es ja neu
entwickelt.
Ich handhabe und empfehle das so:
1) Module, die nicht IP oder Standard sind und trotzdem gross genug
sind, dass reuse Sinn macht, weil es weitgegeben werden soll, oder
Firmen-Knowhow ist, das in mehrere ähnliche Geräte fliesst, sollten
peinlichs genau dokumentiert werden, um deren Funktion exakt von der
ähnlicher Derivate abzugrenzen. Am Besten als Tabelle mit Bescheibung
der Teilfunktionen mit Bezügen zum Code. Versionierung und Code-Doku
sind da begleitende Themen.
2) Derivate, die aus Erweiterung bestehen, werden als ein Projekt
geführt und versioniert, besonders, wenn die alten Versionen nicht mehr
in Produkten verwendet werden.
3) Derivate, die nicht nur Erweiterung sind und in Produkten eingesetzt
werden, die in direkter Linie folgen, werden als eigene Projekte mit
eingener Datenbasis geführt. Sie werden einmal kopiert und dann getrennt
bearbeitet. Das erspart solche Spielchen wie Pragmas, die verschiedene
Versionen steuern und Seitenzweige die nur den Code aufblähen. Die
Rücksichtnahme auf Vorfunktionen und Nebenfunktionen führt immer zu
umständlicheren und aufwändigeren Änderungen. Dieser Mehraufwand wird
niemals eingespielt. Besser ist es, man kann ein VHDL in einem kleineren
Modul in die Niesche treiben.
4) Eine Grundmassnahme ist, die Module immer so klein wie möglich zu
halten und nach Subfunktionen zu suchen, die mutmasslich unverändert
bleiben werden und diese zu extrahieren. Auch da muss man den Aufwand
sehen - gfs lohnt das nicht in jedem Fall.
5) Jedes isolierte Modul bekommt seine eigene blocklevel Testbench, die
die Gutfunktion des Moduls, aber auch die Fehlfunktionen dokumentiert
und veranschaulicht. Der Punkt ist nämlich der, dass es bei vielen
Programmen Fälle gibt, in denen es versagt, die aber bei der konkreten
Anwendung nicht vorkommen, z.B. irgendwelche Zugriffe auf RAMs, die
nicht kollidieren können, es aber nicht tun, weil der Zugreifer von
Aussen das abfängt oder der Ablauf im FPGA das nicht hergibt.
Ein anderer User kann das aber gfs. nicht überschauen, baut das
angeblich getestete Modul ein und hat dann unerklärliche Fehler, die er
nicht versteht. Je komplizierter die Geschichte ist, desto effektiver
ist es oft, das Ganze selber zu formulieren, statt in der Doku des
Vorgängers die versteckten Fallen zu suchen.
Freddy schrieb:> Flensen schrieb:>> Vollständige Testbenches müssen natürlich vorhanden sein. Nachweis meist>> durch Coverage + Constraint Random Verification. Wenn das nicht da ist,>> benutze ich kein fremdes Modul!>> womit macht Ihr die Tests? Mit Extra-Software oder beispielsweise mit> der freien Implementierung von Synthworks?
SystemVerilog
Freddy schrieb:> wir setzten kleine bis mittlere Projekte in VHDL um. Momentan gestaltet> es sich jedoch so, dass mehrere Entwickler an ihren eigenen Projekten> schreiben und viel Code einfach mehrfach geschrieben wird.> Wie ist Eure Erfahrung mit Code Reuse und der Möglichkeit diese in> firmeninterne Bibliotheken zu packen?
eigentlich ganz einfach: Fuer den jeweiligen Toplevel gibt es (neben
einer Beschreibung in Textform) eine Testbench! Diese TB ist
idealerweise gut kommentiert und 'faehrt' einen Sack voll Stimuli durch
(die dann idealerweise auch wieder abgeprueft werden).
Tja, und in der Realitaet sieht dann das ganze wieder voellig anders
aus...
> Tja, und in der Realitaet sieht dann das ganze wieder voellig anders> aus...
Ich kenne eine Firma die hat Schaltungen modularisiert.
Das lief sehr gut.
Das Modul hatte einen Status.
--entworfen
--simuliert
--Review bestanden
--im Prototypen erfolgreich getestet
--seit 1Jahr im Feldeinsatz ohne Ausfälle
Des weiteren gab es für jedes Modul einen Verantwortlichen und der
passte aus Eingeninteresse auf, dass die Dokumentation stimmte, weil er
sonst später von Fragen überhäuft wird.
Dann wurden noch allgemeine Kennzahlen, wie Durchkontaktierungen und
Leiterplattenfläche und Anzahl der Bauelemente erhoben.
Kritiker schrieb:> René D. schrieb:>> --seit 1Jahr im Feldeinsatz ohne Ausfälle>> Wie wird das geprüft - dem Modul zugeordnet, wenn ein Fehler auftritt?
Die Geräte hatten Garantie. So kamen auch die Reklamationen ins Werk
zurück.
Dann gab es ein Qualitätsabteilung, die Fehler untersucht hat und dann
Fehlerstatistik betrieben hat. Sicher wurde nicht jeder Reklamation
nachgegangen, doch bei einem Bock gab es schnell Häufungen in der
Fehlerbeschreibung.
