Kennt jemand Quellen für Coding Styles für VHDL im Bezug auf ASIC und FPGA? Ich meine dabei nicht nur die Optik des Codes sondern auch dessen Aufbau, die Organisation des Projektes, die Einteilung in Submodule, das handling von Komponenten, Verwaltung von Enties und Architectures, Verwendung und Behandlung von Vektoren, Nomenklatur der Signale und Variablen. Findet das in euren Firmen Anwendung?
Hatte ich schon gefunden, danke. Genauso wie dies hier: http://www.dz.ee.ethz.ch/de/information/hdl-hilfe/vhdl-namenskonvention.html mit dem ich aber auch nicht sonderlich glücklich bin. Besonders die Namenskonventionen scheinen mir ziemlich weit hergeholt.
Naja, der Gaisler...ob das das Maß der Dinge ist? Soviele unnütze Variablen wie der immer verwendet...
Christian R. schrieb: > Soviele unnütze Variablen wie der immer verwendet... Aber für Softwareprogrammierer ist das doch so richtig heimelig, so mit einem Monsterprozess, der immer von oben nach unten durchlaufen wird. Da muss man sich gar keine Hardware mehr vorstellen und beschreiben, sondern einfach wie gewohnt drauflos programmieren...
Du sprichst mir aus der Seele. Hoffentlich kommt der Sarkasmus an... Pass ma auf, gleich kommt Peter um die Ecke ;)
Unter"Best Practice VHDL Coding Standards for DO-254 programs" findet sich ein guter Satz an richtlinien von der DO-254 users group. Große Konzerne haben eigene Richtlinien für VHDL-Code der auch weitgehend eingehalten wird (schon wegen ISO-9001 o.ä.) bspw. die Schwarzen Rhodieschen, Hermann Bäcker oder die Münchner Bastel Bude. ;-) MfG,
An die Kritiker der Gaisler-Methode: Habt ihr das schon mal konkret in einem Projekt ausprobiert oder nur die Folien überflogen? Ich habe die Erfahrung, dass die Gaisler-Methode bei vielen erstmal auf Ablehnung stößt, weil sich nicht umgewöhnen wollen oder der Mehrwert zunächst nicht klar erkenntlich ist. Gaisler in einem größeren Projekt eingesetzt, erhöht deutlich das Abstraktionslevel und die Lesbarkeit des Codes. Ich verwende seit vielen Jahren die Gaisler-Methode und finde daher "traditonellen VHDL-Code" mittlerweile eklig. Ich habe auch noch nie Probleme mit FPGA- oder ASIC-Synthese gehabt. Es läuft auch mit allen mir bekannten Simulatoren einwandfrei (okay mit GHDL habe ich es noch nicht ausprobiert).
Nettes Thema, hatte ich gerade auch wieder :-) Mehr, als die Art des Codierens ist es wichtig, was man codiert, damit die Tools damit klarkommen, der Code übersichtlich, verwertbar und portierbar bleibt. Nicht alles, was ich in Coding Styles lese, entspricht diesen Kriterien. Vieles ist einfach Definitionssache, daher kommt es für mich dabei an, dass ich zu dem kompatibel bleibe, was schon da ist, was von Kollegen geliefert wurde oder aus höher angeordneten Designtools ausgeworfen wird, auch wenn es objektiv subopimal ist. Was ein VHDL-Entwickler abliefert, muss von anderen Kollegen auch mal gelesen werden können und diesbezüglich hätte ich mit einer Methodik, wie sie von Gaisler propagiert wird, so meine Bedenken. Das ist IMHO auch 50% Geschmack und Ideologie und höchstens 50% begründbare Strategie. Da hätte ich sofort einige Kritikpunkte. Das Papier der ETH Zürich ist aus meiner Sicht eher verwirrend. Die Suffixes haben keinen wirklichen Wert für die Portierbarkeit oder Lesbarkeit und sind zudem nicht logisch ergänzend und damit überfrachtet. Ein invertiertes asynchrones Resetsignal, das dem Testen dient, müsste demnach 4 Suffixes tragen, wobei "B" angeblich auf "low aktiv" hinweist. Das ist IMHO vollkommener Quark! Erstens gibt es im Logikdesign kein "low", sondern bestenfalls invertierte Signale, ("low-Aktivität" ist eine Eigenschaft von Ports, das macht die halbe Welt falsch) und zweitens deklarieren 90% der Welt invertierte Signale mit "not". Matthias schrieb: > An die Kritiker der Gaisler-Methode: Habt ihr das schon mal konkret in > einem Projekt ausprobiert oder nur die Folien überflogen? Ich zumindest ja, und : > Ich habe die Erfahrung, dass die Gaisler-Methode bei vielen erstmal auf > Ablehnung stößt, weil sich nicht umgewöhnen wollen oder der Mehrwert > zunächst nicht klar erkenntlich ist. der Mehrwert schlägt sich erst bei komplexeren Projekten nieder, die auch in Richtung ASIC gehen oder zumindest von Teams bearbeitet und häufiger modifiziert werden. Der Aufwand muss sich halt lohnen. Und wie oben angedeutet, müssen alle mitziehen. Daran ist schon eine vernüftige Codenormierung in C gescheitert. Fpga Kuechle schrieb: > die Münchner Bastel Bude. ; Wer ist denn die ? :-)
>> die Münchner Bastel Bude. ; >Wer ist denn die ? :-) Lohnt sich nicht, den aktuellen Namen zu erwähnen. In einem Jahr heissen sie eh wieder anders... Mit etwas Pech klagt ihnen auch wieder ein Parfümhersteller (wie letzthin Boss) das neue Logo weg.
Jürgen S. schrieb: > Fpga Kuechle schrieb: >> die Münchner Bastel Bude. ; > Wer ist denn die ? :-) Such nach den drei Anfangsbuchstaben in de.wikipedia.org. Und ja der Firmenname hat sich mehrmals geändert - das Basteln ist geblieben ;-) MfG,
Christian R. schrieb: > Naja, der Gaisler...ob das das Maß der Dinge ist? Soviele unnütze > Variablen wie der immer verwendet... Es ist sicherlich nicht das Mass der Dinge. Mir hat das lesen seines Papers jedenfall viel gebracht, nur schon um mal einen ganz anderen Stil zu sehen und so zu lernen wie mächtig VHDL eigentlich ist. Für meinen Alltag habe ich einen Teil von seinen Empfehlungen übernommen. Konkret benutze ich in Entities nur noch zwei Records (je für Eingang/Ausgang). Das erleichtert das Erweitern mit neuen Funktionen oder Debuginformation ungemein und strukturelle Beschreibungen sind so sehr lesbar, da Quelle und Ziel immer Sichbar sind. Sieht teilweise fast wie objektorientier Code aus :-) Typ- und Komponentendefinitionen kommen in ein Package, macht die Nutzung einfach. Innerhalb einer Architektur arbeite ich "klassisch" weil es eher meiner Denkweise in Funktionsblöcken entspricht, also für jede Funktionseinheit einen eigenen Prozess und so gut es geht sortiert nach Datenfluss, Daten oben hinein und unten heraus. Jürgen S. schrieb: > Und wie > oben angedeutet, müssen alle mitziehen. Coding Guidelines müssen durchgesetzt werden, sonst sind sie nichts Wert. Der Nutzen ergibt sich ja erst dadurch, dass man eigenen/fremden Code auch nach längerer Zeit schnell begreifen kann und z. B. Fehler schneller findet weil man sich schnell zurechtfindet. Fpga Kuechle schrieb: > Unter"Best Practice VHDL Coding Standards for DO-254 programs" findet > sich ein guter Satz an richtlinien von der DO-254 users group. Blöde Frage, gibt es das irgendwo zum Herunterladen oder muss man das kaufen?
Christoph Z. schrieb: > Fpga Kuechle schrieb: >> Unter"Best Practice VHDL Coding Standards for DO-254 programs" findet >> sich ein guter Satz an richtlinien von der DO-254 users group. > > Blöde Frage, gibt es das irgendwo zum Herunterladen oder muss man das > kaufen? Also ich hab mir das PDF das grad ausgedruckt vor mir liegt vor ca. 2-3 Jahren aus dem Netz geholt. Auf deine Frage hin hab ich mal google befragt und da scheint es nicht mehr auffindbar - ist wohl "commerzialisiert" worden. MfG,
Die Dokumentennummer ist: DO254-UG-001 Einen Teil davon kann man hier lesen: http://de.scribd.com/doc/151230668/Best-Practice-VHDL-Coding-Standards-for-DO-254-Programs Das ganze lesen und herunterladen nur wenn man dafür bezahlt. Ob es überhaupt dort sein darf ist eine ganz andere Frage (Da ich keine Ahnung habe, welches Gremium die DO Standards eigentlich erstellt und wie diese üblicherweise zugänglich gemacht werden).
Frank Petelka schrieb: > Du hättest nicht zufällig den Namen des PDFs parat? Zufällig nicht, aber "on-request" hab ich mal nachgeschaut: do-254-ug-001.pdf Es ist gut möglich, das ich nach dem PDF von einem Firmen-PC aus gesucht habe. Dann ist gut möglich das der Usergroup-server dem Proxy als den eines Usergroup-Members identifizierte und deshalb den download gestattete. MfG,
ok, danke ich habe auf einem PDF Server (zwar nicht dieses aber anderes) einiges gefunden, auch mit dem Bezug zur DO 254.
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.