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.
René D. schrieb: > --seit 1Jahr im Feldeinsatz ohne Ausfälle Wie wird das geprüft - dem Modul zugeordnet, wenn ein Fehler auftritt?
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.
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.