Allgemeine Coding Vorgaben für VLSI Design

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 ;)

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.

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?

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).