Mikrocontroller.net - Benutzerbeiträge [de]

Benutzer:Fpgakuechle

2022-06-07T17:07:22Z

Fpgakuechle:

end of transmission

VHDL Editoren und IDEs

2022-01-10T06:05:27Z

Fpgakuechle: Persönliche Meinung gestrichen, zeitliche Einordnung

{| {{Tabelle}} class="wikitable sortable" id="VHDL_Editoren_und_IDEs"
|- bgcolor="#eeeeee"
! Name
! Klasse
! Lizenz
! Windows
! Linux
! Mac
! Kurzbeschreibung
! Evaluierung Fazit
|-
| [http://notepad-plus-plus.org Notepad++]
| Editor
| frei
| ja
| nein
| nein
| Unterstützt viele Sprachen, unter anderem auch VHDL und Verilog
| Sehr vielseitig und intuitiv.
|-
| [http://kate-editor.org/ Kate]
| Editor
| frei
| ja
| ja
| (ja)
| Unterstützt viele Sprachen, unter anderem auch VHDL und Verilog
| Sehr vielseitig und intuitiv.
|-
| [http://www.iis.ee.ethz.ch/~zimmi/emacs/vhdl-mode.html (X)Emacs VHDL Mode]
| Editor
| frei
| ja
| ja
| ja
| Extrem umfangreich, sehr viele automatische Funktionen
| Emacs kann "alles", das Einarbeiten ist aber auch entsprechend aufwendig
|-
| [http://sourceforge.net/projects/veditor Eclipse Verilog editor]
| IDE
| frei
| ja
| ja
| ja
| Eclipse Plugin
| TODO
|-
| [http://zamiacad.sourceforge.net zamiaCAD]
| IDE
| frei
| ja
| ja
| ja
| Eclipse Plugin, eingebauter Simulator
| TODO
|-
| [http://www.sigasi.com Sigasi]
| IDE
| proprietär
| ja
| ja
| ja
| Eclipse Plugin, eingeschränkte Demoversion verfügbar. Integrierter Syntax Check und VCOM-Anbindung. Kontextsensitives Renaming.
| Bislang vermutlich die leistungsfähigste VHDL-IDE. Manchmal etwas instabil. Guter Herstellersupport. Ständige Updates.
|-
| [http://sourceforge.net/projects/signs/ Signs]
| IDE
| frei
| ja
| ja
| ja
| Eclipse Plugin, obsolete, Vorgänger von zamiaCAD
| TODO
|-
| [http://simplifide.com Simplifide]
| IDE
| proprietär
| ja
| ja
| ja
| Eclipse Plugin, kostenlos verfügbar, Entwicklung eingestellt
| TODO
|-
| [http://www.vide-software.at/ ViDE]
| IDE
| proprietär
| ja
| nein
| nein
| basiert auf Visual Studio Shell
| nicht so mächtig wie Sigasi, aber deutlich günstiger
|}

== Siehe auch ==
* Forumsthread 2012: [http://www.mikrocontroller.net/topic/264288#new Welche VHDL IDE benutzt ihr?]
* Weitere IDE: [http://www.vhdplus.com VHDPlus IDE]

== Weblinks ==
* [http://www.vhdleditor.com VHDL Editors - Verilog Editors]

[[Kategorie:VHDL]]

Benutzer:Fpgakuechle

2021-12-12T14:50:11Z

Fpgakuechle: Pause

Ich lege ab 12/21 eine Pause unbestimmter Länge in der Forumsmitarbeit ein.

Benutzer:Fpgakuechle

2021-02-28T10:40:14Z

Fpgakuechle:

=Erstellte Artikel=
*[[Raspberry als Universalprogrammer]]
*[[Hardwarenahe Programmierung am Raspberry Pi]]
*[[Eigenbau ADC am Raspberry Pi]]
*[[Durchblicker]] - FPGA Projekt: Interner Logicanalyzer mit Ausgabe an VGA
*[[PiBla]] - FPGA Projekt: Nachbau des 8 bit controllers Picoblaze als Register-Transfer Level
*[[Retrocomputing auf FPGA]]
*[[TTL74185]] - FPGA benchmark, Untersuchung wie gut verschiedenen Beschreibungsformen synthetisierbar sind
*[[VHDL Code Style und DO-254]] Beispiel für FPGA (VHDL) - Codierrichtlinien aus dem Avionik Umfeld

===Von mir begonnene, inzwischen in der Community stark überarbeitete Artikel===
*[[Taktung FPGA/CPLD]] - Darstellung der Taktverteilung/-domain/-qualität in FPGA's

Benutzer:Fpgakuechle

2020-10-25T15:50:12Z

Fpgakuechle: Änderung 94726 von Fpgakuechle (Diskussion) rückgängig gemacht.

Ich lege eine Pause in der Forumsarbeit bis Ende 2020 ein.

VHDL Code Style und DO-254

2018-09-30T14:23:11Z

Fpgakuechle: Formatierung, ISBN ergänzt, persönliche Revisionsinfo entfernt

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie bei anderen Programmiersprachen, wie z.B. C, existieren auch für [[VHDL]] eine Reihe von Richtlinien, um gut les- und wartbaren Code zu schreiben, der zu stabilen und funktionssicheren Schaltungen führt. Vieles davon ist Geschmackssache sowie Ergebnis firmeninterner Festlegungen, jedoch hat sich auf der Basis von opensource Projekten wie z.B. auf open cores ein gewissen de facto Standard entwickelt. Darüber hinaus existieren inzwischen verschiedene branchenspezifische Standards, die als Vorgabe dienen können. Diese haben teilweise empfehlenden- als auch verpflichtenden Charakter.

In der Luftfahrtbranche gibt es z.B. mit DO-254 einen anerkannten Standard, der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält, sondern auch Methoden zur sicheren Umsetzung von Taktübergängen und FSMs empfiehlt.

== Grundsätzliches zur DO-254==
Die DO-254 ist die bekannteste Spezifikation zur Zertifizierung komplexer digitaler Schaltungen im Bereich der sogenannten Avionik (Fluggeräte). An solche Schaltungen werden üblicherweise höhere Sicherheitsanforderungen gestellt, als bspw. in der Consumer-Elektronik. Sie entsprechen in vielen Bereichen den Vorgaben, wie sie in der Fahrzeugbranche (Automotive) und der Medizintechnik bekannt sind - gehen aber oftmals auch darüber hinaus. Die Aufwände und Kosten für Simulation, Reviews, etc. steigen im Vergleich zu Designs ohne besondere Sicherheitsanforderungen auch um 50% und mehr. Daher ist es um so wichtiger, bereits in der Designphase auf die erhöhten Anforderungen Rücksicht zu nehmen und mehr in die korrekte Formulierung zu investieren - auch im Hinblick darauf, dass eventuelle Fehler in Tests nicht- oder nur schwerlich erkannt werden können.

Das Grundthema der DO-254 ist die Qualitätssicherung, d.h. die Frage, wie man eine Entwicklung gestalten sollte, sodass das Produkt am Ende des Entwicklungsprozesses das Vertrauen in dessen Funktion rechtfertigt. Deshalb finden sich in der DO auch weniger technische Ratschläge oder Designspezifikationen, sondern vermehrt Methoden und Prozessbeschreibungen, die - in der Entwicklung und Verifikation sinngemäß angewandt - zu einem definierten und akzeptierten Grad an Vertrauen in die Funktionsfähigkeit der Produktes führen.

Die DO-254 beginnt mit der Beschreibung, wie Anforderungen (die sogenannten "requirements") erfasst, verfeinert und in einem Dokument festgehalten werden sollen. Alle weiteren im Entwicklungsprozess erstellten Dokumente wie Testspezifikation und -ergebnisse verweisen direkt auf diese Requirements.

Die DO-254 war eine der ersten grundlegenden Spezifikationen für digitale Schaltungen und Entwicklungsmethoden, welche auch weitgehende Vorgaben für VHDL und Verilog gemacht hat. Im Umfeld der DO-254 sind damit früh "Ratschläge" für "saubere" Designs entstanden, die auch außerhalb des Avionik-Umfeldes nützlich sein können.

Dieser Artikel beschränkt sich auf die Darstellung der VHDL-Richtlinien wie von der DO-254 usergroup erarbeitet und in dem Dokument "Best Practice VHDL Coding Standards for DO-254 Programs" aus dem Jahr 2010 festgehalten.

=Aufbau der Richtlinien=

Die designrules sind in 4 Kategorien unterteilt, die Gruppe bestimmt den
Prefix der Regel. Beispielsweise SS-10 für die Zehnte Regel in der Kategorie "Safe synthesis"

*SS - Safe Synthesis
*CP - Coding Practice
*CDC - Clock domain Crossing
*DR - Code Reviews

Jeder Regel ist ein Schweregrad (severity) zugeordnet:

*Note
*warning
*Error

Ja nach Risikograd des designs kann die Einhaltung der Regeln auf einzelne Schweregrade beschrebkt sein. Es ist bei einigen Regeln angegeben das in Einzelfällen Verletzung der Regel in der Schwere herabgestuft (von Error auf Warning) werden kann, wenn diese Fälle entsprechend dokumentiert und begründet werden.

==VHDL Schreibstil - Coding Practice (CP)==
Die Regeln dieser Kategorie stellen sicher, dass ein Kodier-Stil benutzt wird, der auf bewährter Designpraxis im sicherheitskritischen Bereich beruht.

===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
Entity exa is (dat_i: IN dword);
Architecture behave of exa is
signal m_index : std_logic_vector ( 13 downto 0);
--..
m_index <= dat_i(M_index_lo to m_index_hi);
end exa;
</syntaxhighlight>

Sobald diese Fehler bei der Kompilierung entdeckt werden sollte man sie sofort korrigieren.

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide von der Breite eines Vector abhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

Die Zuweisung sollte in einer Weise geschehen, dass sie unabhängig von der Bit-Anzahl im Vektor ist.
Das verringert den Änderungsaufwand bei neuen Vektorbreiten und erleichtert so die Design-Portierung.

===Stelle sicher, dass alle FSM einheitlich codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlicher Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher, dass die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher, dass die Sensitivity list vollständig ist (CP8)===
*''Die Sensitivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher, dass Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollten vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
Dieser Abschnitt (der eine einzelne Regel enthält - Anm.d. Autors) behandelt potentielle Probleme in Designs mit mehreren Takt-Domänen und den dadurch entstehenden asynchronen Taktübergängen

===Analysiere alle asynchronen Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat oder in dem interne Takte generiert werden, ist eine umfassende Analyse der Taktübergänge durchzuführen.''

Fehlerhaft realisierte Signalübergänge führen regelmäßig zu undefinierten Signalen und in Einzelfällen zu Metastabilität von Daten. Damit entsteht ein unbestimmtes Schaltungsverhalten, das stark nachteiligen Einfluss auf den Betrieb des Gerät hat. Diese Richtlinie muss hier erwähnt werden, auch wenn die Analyse von Taktübergängen fern des Fokus von VHDL-Code-Style-check-tools und diesem Dokument ist.

Beim Design-Review muss nach möglichen Taktübergängen gesucht werden und wenn diese aufgefunden wurden, nachgewiesen werden, dass diese korrekt synchronisiert wurden. Fehlverhalten durch inkorrekt ausgeführte Taktübergänge sind mit Testläufen an realer Hardware nur extrem schwierig einzugrenzen, deshalb ist die Designanalyse äußerst wichtig. Es ist oft unmöglich, das Fehlverhalten im Debugging-Prozess konsistent zu reproduzieren. Erschwerend kommt die Wirkung von Umgebungseinflüssen während des Betriebes hinzu: unbekannte kapazitive Lasten, die Temperatur des Die's sowie Potentialschwankungen zB. der Masse. Im schlimmsten Fall zeigt sich der Fehler unter den Testbedingungen nie, sondern nur unter realen Einsatzbedingungen (Flug).

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error
Kombinatorische Rückkopplungen verursachen race-conditions und führen so zu nicht vorhersehbaren Verhalten.

Beispiel f. Verletzung:

<syntaxhighlight lang="vhdl">
fred_s <= gated_in_s OR pulse_r; --comb. loop at fred_s

P_GATED_IN: PROCESS(en_i, fred_s, pulse_r)
BEGIN
gated_in_s <= fred_s AND en_i;
IF (en_i = '0') THEN
gated_in_s <= NOT(fred_s);
ELSIF (pulse_r <= '1') THEN
gated_in_s <= '0';
END IF;
END PROCESS P_GATED_IN;
</syntaxhighlight>

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechten Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt, dass eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und die synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufriedenstellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher bieten "mehrfach", "mannigfaltig", "vielwertig" an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher, dass alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

Alle Register in den designs sollten einen expliziten Resetanschluss haben. Ein Reset-Signal wird benutzt, um ein Gerät in einen determinierten Zustand zu versetzen. Dieses vom system initierte "Error recovery" Kommando wird als letzte Rettungsmöglichkeit für nicht antwortende Systeme benutzt. ("is used as the last resort recovery mechanism for a
non-responsive device.").

Ausnahmen bspw. synchronizer flops und scan chains sind möglich, sollten aber in jedem einzelnen Fall dokumentiert und begründet ("justify") werden. Mehrdimensionale signal/register, die als memory implementiert sind, sind von dieser Warning ausgenommen.

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und Latches die nur unbenutzte Logik treiben, müssen untersucht werden.''
Schweregrad:Error

Unbenutzte Register, Latches und sonstige Logik sind einfach toter Code. Toter Code kann nachteilig sein wenn das Design wieder benutzt wird und der tote Code während der Portierung unbeabichtigt aktiv wird. Die Auswirkungen von totem Code bei der Erstellung von Sicherheitskritische Design ist nicht vorhersehbar und kann sich auch deutlich je nach verwendeten Synthese tool, Release-Version und soga Computersystemen unterscheiden. Damit ist eine konsistente Abschätzung der Folgen nicht möglich.

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide tiefe kombinatorische Verschaltungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer, als eine vorgegebene maximale Logiktiefe sein.''
*Schweregrad: Warning

Die Ermittlung des kritischen Pfades ist schwieriger, wenn der Pfad viele Hierachie-Ebenen durchquert. Lange kombinatorische Pfad - auch snake paths genannt- können Syntheseprobleme verursachen. Das Projekt-Team sollte eine Obergrenze für die Anzahl von Hierarchie-Ebenen die ein Pfad durchqueren kann festlegen. Jeder längere Pfad soll als Regelverletzung gemeldet werden und an einer passenden Stelle durch Einfügen eines Register verkürzt werden.

Anm. FPGAkuechle: ''Die Regel lautet im Original "Avoid Snake Paths"; allerdings ist im deutschen Sprachgebrauch Schlangenpfad oder ähnliches völlig ungebräuchlich und wurde nicht für die Überschrift übernommen. Kritischer Pfad ist der Pfad zwischen zwei Registern, der die längsten Laufzeit aufweist.''

Anm. von J.S.: ''Der Hintergrund des Problems der langen Pfade liegt physikalisch u.a. auch darin, dass mit der Länge und dem Ausmaß von Kombinatorik zwischen zwei Registern die Verletzlichkeit der Information durch Einflüsse wie Strahlung überproportional steigt und damit der Einfluss von Registern, die ein Vergleichen von Werten und somit eine Korrektur mittels Redundanz ermöglichen, relativ reduziert wird. So sind Fehlersimulationen und Testmustermengen weniger gut zu optimieren und praktisch anzuwenden, wenn es um Systemtests oder um system recovery geht. Lange Pfade verschlechtern auch die sogenannte "Fehlerbeobachtbarkeit" im Sinne der Erkennung von "stuck at" - Fehlern in der Produktion. Der gesamte Sachverhalt bezieht sich aber überwiegend auf ASICs. Bei FPGAs ist die Länge eines Pfades allein durch die VHDL-Beschreibung weniger gut bis gar nicht zu kontrollieren. Damit ist die Sinnhaftigkeit der Regel IMO infragegestellt. Man kann zudem beobachten, dass bei FPGAs die Verbindungen (interconnections) insgesamt als solche schon anfällig sind und sich weniger Unterschied durch lange oder kurze Leitungen zeigt, d.h. die Beschreibung kann nur wenig Einfluss auf die Struktur im FPGA nehmen. Umgekehrt kann man bei "langsamen" Schaltungen mit mehr Kombinatorik eine massive Reduzierung von Registerzellen bewirken, die sich als sehr strahlungsanfällig erwiesen haben.''

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Statements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Schweregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß- und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

Anmerkung von J.S. ''Aus meiner Sicht müsste hier beim Thema FPGA eigentlich der Schweregrad "Error" gesetzt werden, weil eine Unterscheidbarkeit in VHDL so gar nicht gegeben ist. Werden zwei verschiedene Signale oder Variablen so formuliert, wird nur eine erzeugt, was in eine Kollision mündet, die bei Berücksichtigung anderer Programmierregeln - vor allem der Behandlung einer Variablen oder eines Signals in nur einem Prozess - direkt entdeckt wird. Damit darf man das Kritarium aber nicht etwas wegfallen lassen, den unter der Annahme der Nichtbefolgung dieser Regel, z.B. in Testbenches, kann eine unbeabsichtigte Doppelreferenzierung durchaus unentdeckt bleiben und äußert sich dann nur über ein funktionelles Fehlverhalten. Dieses muss aber nicht unbedingt auffallen. Dieser Fall wäre also durch diese Regel mit dem Zusatz "error" grundsätzlich zu vermeiden. Um diese Regel praktisch umzusetzen, empfehlen sich alphabetisch geordnete Variablen- und Signallisten, die man im Rahmen der Code-Dokumentation generiert und bei der solche Doppelbelegungen optisch auffallen.''

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad: Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015 ISBN: 978-1482206050
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

Benutzer:Fpgakuechle

2017-01-02T07:06:27Z

Fpgakuechle: Zurück

Nomen est omen - meine Spezialität sind FPGA-Designs.

=Erstellte Artikel=
*[[Raspberry als Universalprogrammer]]
*[[Hardwarenahe Programmierung am Raspberry Pi]]
*[[Eigenbau ADC am Raspberry Pi]]
*[[Durchblicker]] - FPGA Projekt: Interner Logicanalyzer mit Ausgabe an VGA
*[[PiBla]] - FPGA Projekt: Nachbau des 8 bit controllers Picoblaze als Register-Transfer Level
*[[Retrocomputing auf FPGA]]
*[[TTL74185]] - FPGA benchmark, Untersuchung wie gut verschiedenen Beschreibungsformen synthetisierbar sind
*[[VHDL Code Style und DO-254]] Beispiel für FPGA (VHDL) - Codierrichtlinien aus dem Avionik Umfeld

===Von mir begonnene, inzwischen in der Community stark überarbeitete Artikel===
*[[Taktung FPGA/CPLD]] - Darstellung der Taktverteilung/-domain/-qualität in FPGA's

AVR - Die genaue Sekunde / RTC

2016-08-30T18:06:36Z

Fpgakuechle: asm bunt

== Einleitung ==
Oftmals sieht man Projekte, bei denen ein externer RTC-Baustein (engl. '''R'''eal '''T'''ime '''C'''lock, Echtzeituhr; z. B. PCF8583 mit [[I2C]]-Anschluss [http://www-us.semiconductors.philips.com/acrobat/datasheets/PCF8583_5.pdf Datenblatt (PDF)]) angeschlossen ist, ohne dessen Vorteil wirklich zu nutzen.

Die wichtigsten Vorteile einer externen RTC sind
# Die Zeitzählung läuft während eines Ausfalls der Hauptstromversorgung über eine kleine Stützbatterie bei geringem Strombedarf weiter.
# Es gibt hochgenaue RTCs, die man im Gegensatz zu Selbstbaulösungen nicht abgleichen muss.
# Der Strombedarf eines externen RTC ist in der Regel etwas niedriger als die RTC Funktion eines Prozessors. Als Vergleich diene ein DS1302(300nA@2V) zu einem Mega32(5uA@2.7V) als nicht ganz neuer Vertreter, bzw. ein Mega324P(500nA@1.8V) als moderner Vertreter. Dieser Vorteil kommt bei Datenschreibern (engl. data logger) zum Tragen, welche die meiste Zeit inaktiv im [[Sleep Mode]] sind.

In allen anderen Fällen ist die zusätzliche Hardware nicht unbedingt nötig und man kann eine präzise Zeitbasis bequem mit dem Hauptquarz des Mikrokontrollers programmieren. Daraus ergeben sich sogar noch zusätzliche Vorteile, wie eine geringere Temperaturabhängigkeit und höhere Güte, die Quarze im MHz-Bereich gegenüber Quarzen im kHz-Bereich besitzen. Ich möchte hiermit die Angst vor dem bisschen Mathematik nehmen, welche zur Berechnung der Teilerfaktoren benötigt wird.

==Lösung==

Speziell für den AVR kommen Quarze im Bereich 1MHz bis 20MHz zum Einsatz, d.h. in einer Sekunde werden 1.000.000 bis 20.000.000 Zyklen durchlaufen (Zyklen pro Sekunde = Frequenz). Möchte man eine Sekunde messen, kann man somit die entsprechende Anzahl Zyklen von Null an hochzählen oder von dem entsprechenden Wert bis auf 0 runterzählen. Für das Zählen bietet sich im µC der "Clear on compare match" (CTC) Modus eines Timers an.

Die obigen Zahlen lassen sich jedoch nicht in einer 16 Bit Variablen ausdrücken da sie zu gross sind und somit ist ein direktes Setzen des Compare-Wertes des Timers T1 im AVR nicht möglich. Deshalb unterteilt man die Quarzfrequenz in zwei Faktoren; der erste (Softwareteiler) bestimmt die Anzahl der Interrupts pro Sekunde von Timers T1 und der zweite den Reloadwert von Timer 1, welcher die Anzahl von Timertakten pro Interrupt definiert.

==Beispiel==

Im Beispiel AVR wird ein 11,0592-MHz-Quarz verwendet, was einem üblichen [[Baudratenquarz]] entspricht, d.h. damit können die UART-Standardbaudraten erzeugt werden.

Der Softwareteiler wird mit 256 gewählt, d.h. 256 Timerinterrupts pro Sekunde, und kann somit mit nur einem einzigen Byte realisiert werden. Für größere Werte muß der Softwareteiler als int (2 Byte) deklariert werden. Bei kleinen Werten für den Softwareteiler muss man beachten, dass der zweite Faktor immer noch in 2 Byte passt, um als Comparewert für den 16-Bit-Timer 1 verwendet werden zu können. Das wird im unten gezeigten Quelltext automatisch geprüft und ggf. eine Fehlermeldung erzeugt.

Die Timer-[[Interrupt|ISR]] wird in einer Sekunde F_TIMER mal aufgerufen. Mit diesen 256 Hz ergibt sich eine Periodendauer von ca. 4ms, die auch sehr gut zum Entprellen von Tasten benutzt werden kann. Eine Entprellroutine kann also bequem in den Timerinterrupt mit eingefügt werden. Beachten muss man nur noch, dass das Nullsetzen des Timers erst einen Zyklus nach dem Comparematch erfolgt, d.h. eine Periode der ISR ist ORC1A + 1 Timertakte lang.

'''Anmerkung:''' In diesem Beispiel wird die Zahl 256 in einer 8-Bit Variablen gespeichert. Eigentlich geht das nicht, denn bei der Initialisierung wird die Variable aif 0 gesetzt. Praktisch geht es hier doch, weil eben durch das Dekrementieren die Variable beim nächsten Durchlauf der ISR einen normalen Wert bekommt (arithmetischer Überlauf). Allerdings ist das nicht der beste Programmierstil.

==Berechnung==

Die Berechnung des Comparewertes ist sehr einfach:

<syntaxhighlight lang="c">
Periodendauer = 11059200 / 256 = 43200, Rest 0.
Comparewert OCR1A = Periodendauer - 1 = 43199 (siehe Datenblatt, Timer 1 CTC mode)
</syntaxhighlight>

Da haben wir ja noch mal Glück gehabt, es gibt keinen Rest bei der Division und die Sekunde ist exakt 256 * 43200 = 11059200 Zyklen lang. Theoretisch. Denn selbst wenn auf dem Quarz eine Frequenz von 11,0592 Mhz aufgedruckt ist, so schwingt er doch auf einer etwas anderen Frequenz. Der Grund dafür sind Fertigungstoleranzen und natürlich die Tatsache, dass die Frequenz eines Quarzes auch von der Temperatur abhängig ist. Es gilt also zunächst einmal herauszufinden, auf welcher Frequenz der Quarz wirklich schwingt.

Dazu wird eine Uhr programmiert und mit dem nominalen Wert laufen gelassen. Nun habe ich die Uhr
exakt einen Tag laufen lassen und festgestellt, dass sie 1,5 s nach geht. Dazu kann man beispielsweise die Tagesschau nutzen, welche jeden Tag um 20:00 (+einer konstanten Zeitverschiebung durch das Übertragungsmedium SAT,DVB-T, ...) beginnt und sogar eine Uhr dabei einblendet. D.h. die Quarzfrequenz beträgt in Wirklichkeit:

<syntaxhighlight lang="c">
11059200 * (1 - 1,5 / 24 / 60 / 60) = 11059008 Hz.
</syntaxhighlight>
Ausführliche Rechnung:
<syntaxhighlight lang="c">
(Zyklen in 24h - Zyklen Verspätung) / Sekunden pro 24h = korrekte Frequenz
((24 * 60 * 60 * 256 * 43200) - (1,5 * 256 * 43200)) / (24 * 60 * 60) = 11059008 Hz.
</syntaxhighlight>

Also die ganze Rechnung nochmal:
<syntaxhighlight lang="c">
Periodendauer = 11059008 / 256 = 43199, Rest 64.
Comparewert OCR1A = Periodendauer - 1 = 43198
</syntaxhighlight>
Nun haben wir einen Rest und es würden uns jede Sekunde 64 Timer-Zyklen fehlen. Das geht natürlich nicht.

Deshalb wird jedesmal, wenn der Softwareteiler Null ist und die Sekunde weitergezählt wird, ein
anderer Comparewert geladen. Dieser ist dann um den Rest größer. Und beim nächsten Timerinterrupt
wird dann wieder der Comparewert geladen, der das Ergebnis der Division war.

Es ergeben sich somit:
<syntaxhighlight lang="c">
255 * (43198 + 1) + 1 * (43198 + 64 + 1) = 11059008 Zyklen
</syntaxhighlight>
Exakt so, wie wir es wollten.

==Das Programm==

Nachfolgend nun das C-Programm. Da wir ja alle nicht gerne rechnen, lassen wir das einfach den C-Compiler erledigen. D.h. wir brauchen nur noch per Definition für F_CPU den entsprechenden Wert eintragen und der Compiler rechnet alle nötigen Konstanten ganz alleine aus. So ein Compiler ist auch ziemlich faul, der merkt sofort, wenn die Operanden für eine Berechnung alles Konstanten sind. Und ehe er sich damit abquält, extra Code für diese Berechnungen zu erzeugen, rechnet er es lieber selber aus und fügt das Ergebnis direkt in den Code ein. Für den eher seltenen Sonderfall, daß Rest == 0 ist, wird ein Teil des Codes mit #if Rest==0 . . . #endif automatisch entfernt (bedingte Kompilierung mittels Präprozessordirektiven), damit spart man dort minimal CPU-Zeit und Programmspeicher.

Der Assembler kann auch 32-Bit Konstanten-Berechnungen ausführen. Allerdings muß man dann die entsprechenden Präprozessoroperationen benutzen. Man könnte auch eine Divisionsroutine aufrufen, aber dann würde ja echter Code erzeugt.

===Beispiel in C===

<syntaxhighlight lang="c">
/************************************************************************/
/* */
/* Die genaue Sekunde / RTC */
/* */
/* Erzeugt einen Timerinterrupt mit beliebiger Frequenz */
/* */
/* Author: Peter Dannegger */
/* danni@specs.de */
/* */
/************************************************************************/

#include <avr/io.h>
#include <avr/interrupt.h>

// hier alles eintragen
//#define F_CPU 11059201L // Nominalwert des CPU-Taktes
#define F_CPU 11059008L // gemessener Wert, Abweichung -1.5s/d
#define F_TIMER 256L // Timer1 ISR-Frequenz
#define T1_PRESCALER 1 // Hardware-Vorteiler für Timer 1,
// muss mit der Konfiguratiom übereinstimmen!

// hier wird alles berechnet
#define OCRx_RELOAD ((F_CPU / (T1_PRESCALER * F_TIMER)) -1) // Periodendauer pro Interrupt /Timertakte
// -1, weil die Timerperiode OCR1x +1 ist
#define REST (F_CPU % (T1_PRESCALER * F_TIMER)) // Divisionsrest

#if (OCRx_RELOAD+REST) > 65535
#error Überlauf in Timer1! F_TIMER oder T1_PRESCALER erhöhen.
#endif

uint8_t volatile second; // Sekundenzaehler

ISR(TIMER1_COMPA_vect) {
static uint8_t prescaler=(uint8_t)F_TIMER;

if( --prescaler == 0 ) {
prescaler = (uint8_t)F_TIMER;
second++; // eine Sekunde vorueber
if( second == 60 ) second = 0; // eine Minute vorbei
#if REST==0
} // Sonderfall spart ein wenig Code
#else
OCR1A = OCRx_RELOAD + REST; // Rest behandeln
} else {
OCR1A = OCRx_RELOAD; // OCRx jeweils neu laden
}
#endif

/************************************************************************/
/* Hier Entprellung für Tasten etc. einfügen */
/************************************************************************/

}

int main( void ) {

DDRB = 0xFF; // alles Ausgänge mit LEDs zur Anzeige

// Timer 1 initialisieren, mode 4, CTC, Vorteiler 1
// Periode durch OCR1A definiert

TCCR1B = (1<<WGM12) | (1<<CS10);
OCR1A = OCRx_RELOAD;
// OCR1A Interrupt freigeben, wird für Timer CTC mode benutzt
TIMSK = 1<<OCIE1A;

sei();

while(1) {
PORTB = second; // einfache Anzeige der Sekunden in Binärform
}
}
</syntaxhighlight>

===Beispiel in Assembler===

<syntaxhighlight lang="asm">
;************************************************************************/
;* */
;* Precise one second timebase */
;* */
;* Author: Peter Dannegger */
;* danni@specs.de */
;* */
;************************************************************************/
.nolist
.include <m8def.inc>

.equ F_CPU = 11059008
.equ F_TIMER = 256
.equ T1_PRESCALER = 1 ; must be identical to initialisation!
.equ ISR_PERIOD = (F_CPU / (F_TIMER * T1_PRESCALER))
.equ REMAINDER = F_CPU - (ISR_PERIOD * F_TIMER * T1_PRESCALER)

.if (ISR_PERIOD + REMAINDER -1) > 65535
.error "Timer 1 overflow! Increase F_TIMER or T1_PRESCALER."
.endif

.def isr_sreg = r15
.def isr_tmp = r17
.def tmp = r16
.def prescaler = r18
.def second = r19

.list
rjmp Reset
.org OC1Aaddr
rjmp OC1Aint
;-------------------------------------------------------------------------

OC1Aint:
in isr_sreg, sreg

;************************************************************************/
;* Insert Key Debouncing Here */
;************************************************************************/

dec prescaler
brne _oci1

ldi prescaler, (F_TIMER & 0xFF)
inc second
cpi second, 60
brne _oci3

ldi second, 0
_oci3:
ldi isr_tmp, high( ISR_PERIOD + REMAINDER - 1 )
out ocr1ah, isr_tmp
ldi isr_tmp, low( ISR_PERIOD + REMAINDER - 1 )
out ocr1al, isr_tmp
rjmp _oci2

_oci1:
ldi isr_tmp, high( ISR_PERIOD - 1 )
out ocr1ah, isr_tmp
ldi isr_tmp, low( ISR_PERIOD - 1 )
out ocr1al, isr_tmp

_oci2:
out sreg, isr_sreg
reti

;-------------------------------------------------------------------------

Reset:
; Stack initialaisieren
ldi tmp, high( ramend )
out sph, tmp
ldi tmp, low( ramend )
out spl, tmp

; PORTB auf Ausgang
ldi tmp, 0xFF
out ddrb, tmp

; Timer 1 initialisieren, mode 4, CTC, prescaler 1
ldi tmp, 1<<WGM12 | 1<<CS10
out TCCR1B, tmp

; Timer 1 Periode = OCR1A +1
ldi tmp, high( ISR_PERIOD - 1 )
out ocr1ah, tmp
ldi tmp, low( ISR_PERIOD - 1 )
out ocr1al, tmp
out tcnt1l, tmp

ldi prescaler, (F_TIMER & 0xFF)
ldi second, 0

; OCR1A Interrupt freigeben
ldi tmp, 1<<OCIE1A
out TIMSK, tmp
sei

main_loop:
out PORTB, second
rjmp main_loop

;-------------------------------------------------------------------------
</syntaxhighlight>

===Verbesserte Version mit durchlaufendem Hardwarezähler===

Wird im Timer die Option "Clear On Compare Match" verwendet, so verliert man den Overflow Interrupt. Oder möchte man nebenher noch eine Zeit mit der Input Capture Funktion messen, so benötigt man einen durchlaufenden Timer. Um dies zu erreichen wird OCR1A nicht fest eingestellt sondern bei jedem Aufruf um den gleichen Wert erhöht.

In vorherigen Code wird der Rest auf einmal abgearbeitet. Damit erspart man sich bei jedem Interrupt einen Vergleich und die Verarbeitungszeit verkürzt sich geringfügig. Der Unterschied zwischen kurzem und langem Interrupt ist hier die Anzahl REST Timertakte, welche je nach mathematischer Konstellation zwischen 0 und F_TIMER-1 liegen kann (Divisionsrest, Modulo-Operation). Bei dem nachfolgenden Beispiel wird der Rest gleichmäßig abgearbeitet, d.h. die Resttakte werden gleichmäßig über eine Sekunde verteilt. Der Unterschied zwischen kurzem und langem Interrupt beträgt nur 1 Timertakt. Der Preis dafür ist ein klein wenig mehr CPU-Last im Interrupt und eine zusätzliche 16 Bit Variable.

<syntaxhighlight lang="c">
/************************************************************************/
/* */
/* Die genaue Sekunde / RTC */
/* */
/* Erzeugt einen Timerinterrupt mit beliebiger Frequenz */
/* */
/* verbesserte Version mit durchlaufendem Timer 1 */
/* und gleichmäßiger Verteilung der restlichen Timertakte */
/* */
/************************************************************************/

#include <avr/io.h>
#include <avr/interrupt.h>

// hier alles einstellen
//#define F_CPU 11059200L // Nominalwert des CPU-Taktes
#define F_CPU 11059008L // gemessener Wert, Abweichung 1.5s/d
#define F_TIMER 256L // Timer 1 ISR-Frequenz
#define T1_PRESCALER 1 // Hardware-Vorteiler für Timer 1
// muss mit der Konfiguration übereinstimmen

// hier wird alles berechnet
#define OCRx_INC (F_CPU / (T1_PRESCALER * F_TIMER)) // Timertakte pro Interrupt
#define REST (F_CPU % (T1_PRESCALER * F_TIMER)) // Divisionsrest

#if (OCRx_INC+1) > 65536
#error Überlauf in Timer1! F_TIMER oder T1_PRESCALER erhöhen.
#endif

uint8_t volatile second; // Sekundenzaehler

ISR(TIMER1_COMPA_vect) {
static uint8_t prescaler=(uint8_t)F_TIMER;

if( --prescaler== 0 ) {
prescaler= (uint8_t)F_TIMER;
second++; // eine Sekunde vorueber
if( second == 60 ) second = 0; // eine Minute vorbei
}

#if REST !=0
static uint16_t restakku;

restakku += REST;
if (restakku >= F_TIMER) {
restakku -= F_TIMER;
OCR1A += OCRx_INC + 1; // lange Periode
} else {
OCR1A += OCRx_INC; // kurze Periode
}
#else // kein REST
OCR1A += OCRx_INC; // immer kurze Periode
#endif

/************************************************************************/
/* Hier Entprellung für Tasten etc. einfügen */
/************************************************************************/

}

int main( void ) {

DDRB = 0xFF; // alles Ausgänge mit LEDs zur Anzeige

// Timer 1 initialisieren, mode 0, normal, Vorteiler 1
TCCR1B = (1<<CS10);
OCR1A = OCRx_INC;
// OCR1A Interrupt freigeben
TIMSK = 1<<OCIE1A;

sei();

while(1) {
PORTB = second; // einfache Anzeige der Sekunden in Binärform
}
}
</syntaxhighlight>

===Durchlaufender Hardwarezähler und fortlaufende Addition===

Gänzlich ohne Hin- und Hertogglen eines Bits kommt man aus, wenn irgendein Timer mit einer Überlauf-Interruptfrequenz > 1Hz arbeitet. Dann kann die ISR eine 32-bit-Konstante auf einen 32-bit-Akkumulator addieren; bei Überlauf ist eine Sekunde vergangen. Zugegeben, es gibt "lange" und "kurze" Sekunden, aber der Fehler summiert sich nicht, und der Code ist sehr einfach.

Hier ein Beispiel:

Es gibt ein Programm gettick(), das einen Wert holt. Dieser Wert wird von Zeit zu Zeit von der Hardware (Beispiel AVR: der Timer) oder dem Betriebssystem ermittelt. (Beispiel Linux: gettick ruft getmsec, getmsec ruft gettimeofday)

Dieser aufgerufene Wert sollte pro Sekunde um TICKPERSEC erhöht werden, was aber mit einer gewissen Ungenauigkeit geschieht.

Die Laufzeitkorrektur wird dadurch ausgeführt, dass der von gettick() zurückgegebene Wert mit einem Faktor TFAK multipliziert wird. Der Faktor sollte so gewählt werden, dass:

* Das Ergebnis actual_value immer in 32 Bit hineinpasst.
* Die Multiplikation durch Schiebeopertionen ersetzt werden kann, weil der Faktor eine 2-er-Potenz ist. (Das erledigt avr-gcc)

Immer wenn tsdaytim_calibrated() erkennt, dass eine Sekunde vergangen, wird last_value um die Zahl onesecond erhöht.

Der Zahlenwert onsecond wird mit TICKPERSEC*TFAK initalisiert und kann angezeigt oder neu eingegeben werden (Die Bedienung der seriellen Schnittstelle hierfür ist in diesem Beispiel nicht enthalten).

Wenn festgestellt wird, dass die Uhr pro Zeit (P) um (E) zu schnell geht, dann kann der Wert onsecond korrigiert werden.

c = d * (P+E)/P
Beispiel Pro 7 Tage 120 Sekunden zu viel:

7 Tage = 7*86400= 604800 sekunden
c = 992000000 * (604800+120)/604800=991803175
Dann wird die Uhr genauer gehen.

<syntaxhighlight lang="c">
/****************************************************************/
/* File home/cc/qq/danclock.cpp */
/* Precise 1 Second Timebase */
/* */
/* Author: Peter Dannegger / Hjherbert */
/* danni@specs.de */
/* */
/****************************************************************/
// Target: atmega8, (2313?)

#include <avr/io.h>
#include <avr/interrupt.h>
// #include <avr/signal.h>

#ifndef OCR1A
#define OCR1A OCR1 // 2313 support
#endif

#ifndef WGM12
#define WGM12 CTC1 // 2313 support
#endif

#ifndef PINC
#define KEY_INPUT PIND // 2313
#else
#define KEY_INPUT PINC // Mega8
#endif

//#define F_CPU 11059201L // nominal value

#define DIVISOR 256

#define TICKPERSEC (F_CPU/DIVISOR)

uint8_t volatile second; // count seconds

// TFAK ? TICKPERSEC must not exceed 2^32
#define TM (0x7FFFFFFFUL/2/TICKPERSEC) // max of TFAK

#define TFAK ( ( (TM>>1) | (TM>>2) | (TM>>3) | (TM>>4) | (TM>>5) | (TM>>6) | (TM>>7) \
| (TM>>8) | (TM>>9) | (TM>>10) | (TM>>11) | (TM>>12) | (TM>>13) | (TM>>14) | (TM>>15) \
| (TM>>16) | (TM>>17) | (TM>>18) | (TM>>19) | (TM>>20) | (TM>>21) | (TM>>22) | (TM>>23) \
| (TM>>24) | (TM>>25) | (TM>>26) | (TM>>27) | (TM>>28) | (TM>>29) | (TM>>30) | (TM>>31) \
) + 1 )
// TFAK is a power the biggest power of two which is less than TM

uint32_t onesecond = 1*TICKPERSEC*TFAK ; // correct this value if see the clock is late / too fast
uint32_t last_value ;
uint32_t ticks ;

SIGNAL (SIG_OUTPUT_COMPARE1A)
{
++ticks ;
}

uint32_t gettick( void )
{
uint32_t l ;
cli();
l = ticks ;
sei();
return l ;
}

void tsdaytim_calibrated(void)
// Keep the time-of-the-day actual
// Add a second, if a second if gone
{
uint32_t actual_value ; // gettick() multiplied by factor 2^n

actual_value = gettick() * TFAK ; // because TFAK is a power of two
// The compiler will create some shift commands

if ( actual_value - last_value > onesecond )
{ // once per second
if ( ++second >= 60 )
{
second = 0 ;
}
last_value += onesecond ; // One second more
}
}

int main( void )
{
DDRB = 0xFF;
while( KEY_INPUT & 1 ); // start with key 0 pressed

TCCR1B = 1<<WGM12^1<<CS10; // divide by 1
// clear on compare
OCR1A = DIVISOR ; // Output Compare Register
TCNT1 = 0; // Timer start value
second = 0;

TIMSK = 1<<OCIE1A; // beim Vergleichswertes Compare Match
// Interrupt (SIG_OUTPUT_COMPARE1A)
sei();
last_value = gettick() * TFAK ;
for(;;)
{
tsdaytim_calibrated();
PORTB = second; // display second (binary)
}
}

</syntaxhighlight>

== Echtzeituhr mit Uhrenquarz ==

=== RTC mit wenig Stromverbrauch ===

Das vorgestellte Verfahren ist leider nicht direkt anwendbar, wenn man eine RTC mit einem 32,768 KHz Uhrenquarz realisieren möchte. Dieser Weg ist dann notwendig, wenn der Controller [[Ultra low power | batteriebetrieben]] sehr lange laufen soll und durch Verwendung des [[Sleep Mode]] Strom gespart wird.

=== Begrenzung der Auflösung ===

Wo liegt das Problem? Das obige Verfahren nutzt recht hochfrequente Quarze mit 1 MHz und mehr. Wenn man die Frequenz eines Quarzes von 1 MHz = 1.000.000 Hz mit einer [[Auflösung und Genauigkeit| Auflösung]] von 1 Hz angibt, entspricht das einem maximalen Fehler von 1/1.000.000 oder 1ppm (engl. parts per million, millionstel Teil). Das ist sehr wenig. Eine RTC mit einem Fehler von 1ppm hat eine Gangabweichung von 86,4ms pro Tag, oder 2,5s pro Monat. Das ist ein sehr guter Wert. Wenn ich nun aber die Frequenz 32768 Hz mit 1 Hz Auflösung angebe, ist das schlimmstenfalls ein Fehler von 1/32768 = 30,5ppm, was einer Abweichung von 2,5s pro Tag und 75s pro Monat entspricht!

=== Uhrentakt genau messen und digital korrigieren ===

Wie kann man das Problem lösen? Die AVRs können im [[Sleep Mode]] den Uhrenquarz nur am Timer 2 betreiben, welcher ein 8 Bit Timer ist. D.H. ein Überlauf passiert alle 256 Takte, sprich 7,8125ms (=128 Hz). Man kann auch einen Prescaler verwenden, welcher das Problem aber nicht löst.

Wie bereits festgestellt, müssen wir die Frequenz des 32768Hz Uhrenquarzes genauer messen und darstellen. Wir wollen hier annehmen, dass wir die Frequenz auf 0,001Hz = 1mHz (Millihertz) auflösen, ein guter Frequenzzähler kann das problemlos und ist auch so [[Auflösung und Genauigkeit|'''genau''']]. Wir können beispielsweise feststellen, dass ein Quarz mit 32768,423Hz schwingt, das entspricht einem Fehler von

<math>F_r=(\frac{f_{ist}}{f_{soll}} -1 )\cdot 10^6=(\frac{32768,423}{32768} -1 )\cdot 10^6=12,9ppm</math>

Dabei ist zu beachten, daß diese Messung '''nicht''' direkt am Quarz erfolgen darf, auch nicht mit kapazitätsarmen 10:1 Tastköpfen! Denn so ein Quarz wird von kleinsten Kapazitäten im Bereich von weniger als ein pF messbar verstimmt. Darum muss man in so einem Fall den Uhrentakt auf ein anderes IO-Pin ausgeben und dort messen. Beim [[MSP430]] ist das einfach, man kann ACLK auf ein Pin direkt ausgeben. Der [[AVR]] kann das leider nicht. Hier muss man zu einem Trick greifen. Man benutzt die Output Compare Funktion, um mit Timer 2 einen 128 Hz Takt zu erzeugen. Dieser ist fest mit dem Uhrentakt verbunden und kann anstellte dessen gemessen werden, ohne den Quarz zu verstimmen. Die Messung ergibt in diesem Fall eine Frequenz von 128,00165 Hz.

OK, jetzt haben wir den Takt gemessen, wir wissen, daß pro Sekunde 128 Timerüberläufe passieren (Prescaler =1). Wir wissen, dass unser Quarz pro Sekunde um 0,423 Takte zu schnell ist. Wir können aber keine halben Takte mehr oder weniger zählen? Doch! Mit [[Festkommaarithmetik]]! Denn nach 1000s ist unser Quarz um 423 Takte zu weit gelaufen und muss um diese Anzahl zurückgestellt werden. Also könnte man im ersten Ansatz nach 1000 Sekunden den Timer 2 um diesen Betrag korrigieren. Das Problem dabei ist nur, dass der Zähler nur 8 Bit breit ist. Ein Addieren oder Subtrahieren von 423 würde mehrfache Überläufe verursachen, welche programmtechnisch nur schwer zu handhaben wären. Also muss eine etwas bessere Methode her.

=== Bresenham für RTCs ===

Wenn man sich die Idee der [[Festkommaarithmetik]] mal eine Weile durch den Kopf gehen lässt, kommt man vielleicht auf folgende Idee. Der Frequenzfehler beträgt in unserem Beispiel 0,423 Hz, also Takte pro Sekunde. Oder aber 423 Tausendstel Takte pro Sekunde. Nach drei Sekunden sind es schon 1,269 Takte oder 1269 Tausendstel Takte. Moment! '''Einen''' Takt können wir korrigieren, indem wir den Zähler um 1 Takt zurück setzen. Den Restfehler von 269 Tausendstel merken wir uns und akkumulieren weiter. Wenn dann wieder die 1000er Marke überschritten wird machen wir das Gleiche. Analog dazu natürlich auch bei negativem Vorzeichen, sprich wenn der Quarz zu langsam schwingt wird er um einen Takt vorgestellt. É Voilà! Dieses Verfahren ist sehr ähnlich zum [http://de.wikipedia.org/wiki/Bresenham-Algorithmus Bresenham-Algorithmus] zum Zeichnen von Linien auf Computermonitoren.

=== Beispielprogramm ===

Das folgende Beispiel stellt eine RTC mit sehr niedrigem Stromverbrauch zur Verfügung. Laut Datenblatt beträgt die Stromaufnahme nur ca. 6µA bei 3V Versorgungsspannung, besser als einige kommerzielle RTCs! Möglich macht das die Nutzung des Power Save [[Sleep Mode]]s. Die Frequenz kann auf <math>10^{-5}</math> Hz genau abgeglichen werden, was in diesem Fall bei einer Messfrequenz von 128Hz einer Auflösung von 0,078ppm entspricht. Das bedeutet eine Abweichung von 6,7ms pro Tag, 0,2s pro Monat oder 2,46s pro Jahr!

Die Abweichung des Quarzes wird in einer vorzeichenbehafteten 16 Bit Variable in der Einheit <math>10^{-3}</math> Hz gespeichert. D.h. es kann ein Frequenzfehler von +/- 32,768 Hz korrigiert werden, das sind 1000ppm! Normale Quarze haben Abweichungen von max. 100ppm, meist viel weniger. Jede Sekunde wird der Frequenzfehler neu berechnet und in den darauffolgenden 128 Interrupts ggf. mehrfach korrigiert. Wichtig ist dabei, dass die Korrektur wirklich ganz am Anfang der ISR steht, weil hier das Timing wirklich kritisch ist. Denn innerhalb eines Uhrenquarztaktes von ~30µs muss der Timer 2 neu beschrieben werden. Bei 1 MHz RC-Oszillatortakt sind das nur 30 Takte, wovon 6 zum Aufwachen und 4 zum Anspringen der ISR benötigt werden. Dazu kommen noch das Sichern einiger Register am Anfang der ISR, was man im C nicht direkt sieht. Sicherheitshalber sollte man auch einen höheren Takt einstellen, z. B. 2 MHz, dann ist das Timing wesentlich entspannter.

<syntaxhighlight lang="c">
/*
************************************************************************
*
* Stromsparende Echtzeituhr mit 32768Hz Uhrenquarz
*
* ATmega88 mit internem 2 MHz Oszillator + 32,768 kHz Quarz
*
* Fuses bleiben auf Standardeistellungen
* LOW Fuse Byte = 0x62
* HIGH Fuse Byte = 0xDF
* EXT Fuse Byte = 0xF9
*
* LED mit 1K Vorwiderstand an PB5
* Kalibriertaktausgang an PB3
************************************************************************
*/

#define F_CPU 2000000L // Systemtakt in Hz
#define F_CAL 12800000L // gemessener Kalibriertakt in 10^-5 Hz
// Endung L ist wichtig!

#define LED_TOGGLE PORTB ^= (1<<PB5);

#include <avr/io.h>
#include <avr/sleep.h>
#include <avr/interrupt.h>
#include <avr/eeprom.h>
#include <util/delay.h>

// EEPROM Daten

int16_t ee_rtc_cal EEMEM = (F_CAL-12800000)*256/100; // Kalibrierung für RTC, Frequenzfehler in 1/1000 Hz

// globale Variablen

// beidseitiger Zugriff durch ISR und Hauptprogramm

volatile uint32_t time; // 24h Zeitstempel, 1s Auflösung
volatile int16_t rtc_cal; // Kalibrierung des 32K Quarzes
volatile uint8_t flag_1s; // Flag für 1s Intervall

void long_delay(uint16_t ms) {
for (; ms>0; ms--) _delay_ms(1);
}

int main (void) {

// Clock divider auf /4

CLKPR = 0x80; // update enable
CLKPR = 2; // Prescaler /4

// IO konfigurieren

DDRB = (1<<PB3) | (1<<PB5);
PORTB = ~((1<<PB3) | (1<<PB5)); // Pull ups
PORTC = 0xFF;
PORTD = 0xFF;

// Analogcomparator ausschalten

ACSR = 0x80;

// Timer2 konfigurieren

ASSR = (1<< AS2); // Timer2 asynchron takten
long_delay(1000); // Einschwingzeit des 32kHz Quarzes
TCCR2A = (1<<COM2A1) | (1<<WGM21) | (1<<WGM20); // Fast PWM, non inverted
TCCR2B = 1; // Vorteiler 1 -> 7,8ms Überlaufperiode
OCR2A = 128; // PWM, Tastverhältnis 50%
while((ASSR & (1<< TCR2BUB))); // Warte auf das Ende des Zugriffs
TIFR2 &= ~(1<<TOV2); // Interrupts löschen
TIMSK2 |= (1<<TOIE2); // Timer overflow Interrupt freischalten

// EEPROM Werte auslesen

rtc_cal= eeprom_read_word(&ee_rtc_cal);

// Interrupts freigeben

sei();

// Endlose Hauptschleife

while(1) {

while((ASSR & (1<< OCR2AUB))); // Warte auf das Ende des Zugriffs
set_sleep_mode(SLEEP_MODE_PWR_SAVE);
sleep_mode(); // in den Schlafmodus wechseln

// hier wachen wir wieder auf, nach Ausführung des 7,8ms Timerinterupt

if (flag_1s) {
flag_1s =0;
LED_TOGGLE // Test
}

}
}

// Timer2 overflow Interrupt

ISR(TIMER2_OVF_vect) {
static uint8_t ticks; // Hilfsvariable für Messintervall
static int16_t time_error; // RTC Fehlerkompensation

// Zeitkritische Dinge, welche am Anfang der ISR stehen müssen!

OCR2A=128; // Dummy-Write zur Sicherung des Timings
// von Timer 2 im asynchronen Modus

// RTC Fehler korrigieren

if (time_error>999) { // RTC zu schnell
TCNT2 = 2; // Zähler einen Schritt zurück setzen (2 Takte Verzögerung!)
time_error -= 1000;
} else if (time_error<-999) { // RTC zu langsam
TCNT2 = 4; // Zähler einen Schritt vor setzen (2 Takte Verzögerung!)
time_error += 1000;
}

// ab hier ist es nicht mehr zeitkritisch

// Echtzeituhr
ticks++; // 1/128tel Sekunde
if (ticks==128) { // Sekundenintervall
time_error += rtc_cal; // RTC Fehler akkumulieren

// 24h Timer
time++;
if (time==86400) time=0; // 24h Überlauf

ticks=0;
flag_1s =1; // setzte Flag für 1s Verarbeitung in main Endlosschleife
}
}
</syntaxhighlight>

=== Weitere Verbesserungen ===

Der Algorithmus ermöglicht eine sehr hochauflösende Kalibrierung der RTC. Allerdings heisst das leider noch lange nicht, daß die RTC dann auch wirklich so genau ist. Denn diese Kalibrierung gilt nur für eine exakte Temperatur! Auch ein Quarz hat eine Temperaturabhängigkeit der Schwingfrequenz. Wenn man nun eine sehr genaue RTC bauen möchte, welche über einen grossen Temperaturbereich genau läuft, muss man periodisch die Temperatur messen und in die Kalibrierung einbeziehen. Einen typischen Temperaturverlauf des Frequenzfehlers zeigt das folgende Bild.

[[bild:rtc_tk.gif|thumb|260px|left|Temperaturgang eines Uhrenquarzes]]
<br clear="all" />

Weiterhin kann man natürlich die Kalibrierung ohne erneutes Kompilieren des Quelltextets vornehmen, indem man den Kalibrierwert per [[UART]] oder [[I2C]] an den AVR sendet und im [[Speicher#EEPROM | EEPROM]] speichert.

Kernpunkt der Kalibrierung ist natürlich die Messung der realen Quarzfrequenz. Die oben beschriebene Methode per Tagesschau und 1 Tag warten ist sehr zeitaufwändig und hat eine begrenzte Genauigkeit von ca. 1/2 Sekunde, das entspricht 5,8ppm. Hier muss zwangsläufig ein guter Frequenzzähler her. Da dieser nicht jedem Hobbybastler zur Verfügung steht, muss man sich in Lehrwerkstätten, Universitäten oder Firmen im Elektronikbereich umsehen und nachfragen, ob man einen Frequenzzähler vor Ort kurze Zeit nutzen kann.

Einige GPS-Module bieten auch einen hochgenauen 1PPS (Pulse Per Second) Ausgang an, der sich für den Abgleich gut heranziehen lässt. Auch das Sekunden-Zeichen eines DCF77-Funkuhr-Moduls ist sehr genau und kann als Referenz dienen.

== Links ==

*[http://www.mikrocontroller.net/articles/Uhr Implementierung einer Uhr mit Siebensegmentausgabe auf einem AVR ATTiny2313]
*[http://www.mikrocontroller.net/topic/165249 Uhr mit genauer Sekunde BASCOM]
*[https://www.mikrocontroller.net/topic/298306 Stromsparende und günstige Zeitmessung: ATtiny mit Uhrenquarz getaktet]

[[Category:AVR-Projekte]]
[[Category:Timer und Uhren]]

AVR 16-Bit-Register

2016-08-30T17:41:59Z

Fpgakuechle: /* Makros */ Bunt

=== Allgemeines ===

Speziell bei den '''16-Bit-Timern''' und auch beim '''ADC''' ist es bei allen Zugriffen auf Datenregister erforderlich, dass diese Daten synchronisiert sind. Wenn z. B. bei einem 16-Bit-Timer das High-Byte des Zählregisters gelesen wurde und vor dem Lesezugriff auf das Low-Byte ein Überlauf des Low-Bytes stattfindet, erhält man einen völlig unsinnigen Wert. Auch die Compare-Register müssen synchron geschrieben werden, da es ansonsten zu unerwünschten Compare-Ereignissen kommen kann.

Beim ADC besteht das Problem darin, dass zwischen den Zugriffen auf die beiden Teilregister eine Wandlung beendet werden kann und der ADC ein neues Ergebnis in ADCL und ADCH schreiben will, wodurch High- und Low-Byte nicht zusammenpassen.

Um diese Datenmüllproduktion zu verhindern, gibt es in beiden Fällen eine Synchronisation, die jeweils durch den Zugriff auf das Low-Byte ausgelöst wird:
* Bei den Timer-Registern (das gilt für alle TCNT-, OCR- und ICR-Register bei den 16-Bit-Timern) wird bei einem '''Lesezugriff''' auf das Low-Byte automatisch das High-Byte in ein temporäres Register, das ansonsten nach außen nicht sichtbar ist, geschoben. Greift man nun ''anschließend'' auf das High-Byte zu, dann wird eben dieses temporäre Register gelesen.
* Bei einem '''Schreibzugriff''' auf eines der genannten Register wird das High-Byte in besagtem temporären Register zwischengespeichert und erst beim Schreiben des Low-Bytes werden ''beide'' gleichzeitig in das eigentliche Register übernommen.

Das bedeutet für die Reihenfolge beim '''Lesezugriff: Erst Low-Byte, dann High-Byte''' und für den '''Schreibzugriff: Erst High-Byte, dann Low-Byte'''.

Des weiteren ist zu beachten, dass es für all diese 16-Bit-Register nur ein einziges temporäres Register gibt, so dass das Auftreten eines Interrupts, in dessen Handler ein solches Register manipuliert wird, bei einem durch ihn unterbrochenen Zugriff i.d.R. zu Datenmüll führt. '''16-Bit-Zugriffe sind generell nicht atomar!''' Wenn mit '''Interrupts''' gearbeitet wird, kann es erforderlich sein, vor einem solchen Zugriff auf ein 16-Bit-Register die Interrupt-Bearbeitung zu deaktivieren.

Beim '''ADC-Datenregister ADCH/ADCL''' ist die Synchronisierung anders gelöst. Hier wird beim Lesezugriff (ADCH/ADCL sind logischerweise Read-only) auf das Low-Byte ADCL beide Teilregister für Zugriffe seitens des ADC so lange gesperrt, bis das High-Byte ADCH ausgelesen wurde. Dadaurch kann der ADC nach einem Zugriff auf ADCL keinen neuen Wert in ADCH/ADCL ablegen, bis ADCH gelesen wurde. Ergebnisse von Wandlungen, die zwischen einem Zugriff auf ADCL und ADCH beendet werden, gehen verloren!

'''Nach einem Zugriff auf ADCL muss grundsätzlich ADCH gelesen werden!'''

Beim ADC gibt es für den Fall, dass eine Auflösung von 8 Bit ausreicht, die Möglichkeit, das Ergebnis "linksbündig" in ADCH/ADCL auszurichten, so dass die relevanten 8 MSB in ADCH stehen. In diesem Fall muss bzw. sollte nur ADCH ausgelesen werden.

=== Zugriffe in C ===

In beiden Fällen (also sowohl bei den Timern als auch beim ADC) werden von '''C-Compilern''' 16-Bit-Pseudo-Register zur Verfügung gestellt (z. B. TCNT1H/TCNT1L → TCNT1, ADCH/ADCL → ADC bzw. ADCW), bei deren Verwendung der Compiler automatisch die richtige Zugriffsreihenfolge regelt. '''In C-Programmen sollten grundsätzlich diese 16-Bit-Register verwendet werden'''. Sollte trotzdem ein Zugriff auf ein Teilregister erforderlich sein, sind obige Angaben zu berücksichtigen.

Es ist darauf zu achten, dass auch ein Zugriff auf die 16-Bit-Register vom Compiler in zwei 8-Bit-Zugriffe aufgeteilt wird und dementsprechend genauso nicht-atomar ist wie die Einzelzugriffe. Auch hier gilt, dass u.U. die Interrupt-Bearbeitung gesperrt werden muss, um Datenmüll zu vermeiden.

ADC und ADCW sind unterschiedliche Bezeichner für das selbe Registerpaar. Üblicherweise kann man in C-Programmen ADC verwenden, was analog zu den anderen 16-Bit-Registern benannt ist. ADCW (ADC Word) existiert nur deshalb, weil die Headerdateien auch für Assembler vorgesehen sind und es bereits einen Assembler-Befehl namens ''adc'' gibt.

=== Makros ===

Um den Zugriff auf diese 16Bit Register zu vereinfachen
hast ATMEL in der Application Note AVR072 [http://www.atmel.com/dyn/resources/prod_documents/doc1493.pdf] folgende Makros
zur freien Verwendung vorgeschlagen:

'''AVR Assembler Macros'''
<syntaxhighlight lang="asm">
.macro outw
cli
out @0, @1
out @0-1, @2
sei
.endmacro

.macro inw
cli
in @1, @2-1
in @0, @2
sei
.endmacro
</syntaxhighlight>

''Usage''
<pre>
.include “8515def.inc”

inw r17, r16, TCNT1H ; Reads the counter value (high, low, adr)
outw TCNT1H, r17, r16 ; Writes the counter value (adr, high, low)
</pre>

'''IAR C MACROS'''
<pre>
#include <ina90.h>
#define outw( ADDRESS, VAL )\
{\
_CLI();
ADDRESS = VAL;\
_SEI();\
}

#define inw( ADDRESS, VAL )\
{\
_CLI();
VAL = ADDRESS;\
_SEI();\
}
</pre>

''Usage''
<pre>
#include <io8515.h>
inw( TCNT1, i ) ;/* Reads the counter value */
outw( TCNT1, i ) ;/* Writes the counter value */
</pre>

[[Kategorie: AVR-Tutorial|AVR 16-Bit-Register]]

Benutzer:Fpgakuechle

2016-06-15T04:52:54Z

Fpgakuechle: umformuliert

Ich lege eine Pause in der Forumsarbeit bis Ende 2016 ein, Gründe dort:
https://www.mikrocontroller.net/topic/399644#new

Benutzer:Fpgakuechle

2016-06-12T05:59:44Z

Fpgakuechle: Habe fertig

Ich stelle meine Forumsarbeit ein - macht Euren Dreck doch bitte alleine.

MfG,

VHDL Code Style und DO-254

2015-11-18T06:20:23Z

Fpgakuechle: /* VHDL Schreibstil - Coding Practice (CP) */ Erläuterungen detaillierter

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-11-09, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie bei "richtigen" Programmiersprachen, wie C, existieren auch für [[VHDL]] Richtlinien, um gut les- und wartbaren Code zu schreiben, der zu stabilen und funktionssicheren Designs führt. Vieles davon ist Geschmackssache, mit der DO-254 gibt es jedoch einen anerkannten Standard, der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält, sondern auch Methoden zur
sicheren Umsetzung von Taktübergängen und FSMs empfiehlt.

== Grundsätzliches zur DO-254==
Die DO-254 ist die bekannteste Spezifikation zur Zertifizierung komplexer digitaler Schaltungen im Bereich der sogenannten Avionik (Fluggeräte). An solche Schaltungen werden üblicherweise höhere Sicherheitsanforderungen gestellt, als bspw. in der Consumer-Elektronik. Die Aufwände und Kosten für Simulation, Reviews, etc. steigen daher im Vergleich zu Designs ohne besondere Sicherheitsanforderungen auch um 50% und mehr.

Im Umfeld der DO-254 sind aber auch weniger teure "Ratschläge" für "saubere" Designs entstanden, die außerhalb des Avionikumfeldes nützlich sein können.

Das Grundthema der DO-254 ist die Qualitätssicherung, d.h. die Frage, wie man eine Entwicklung gestalten sollte, sodass das Produkt am Ende des Entwicklungsprozesses das Vertrauen in dessen Funktion rechtfertigt. Deshalb finden sich in der DO auch weniger technische Ratschläge oder Designspezifikationen, sondern vermehrt Methoden und Prozessbeschreibungen, die - in der Entwicklung und Verifikation sinngemäß angewandt - zu einem definierten und akzeptierten Grad an Vertrauen in die Funktionsfähigkeit der Produktes führen.

Die DO-254 beginnt mit der Beschreibung, wie Anforderungen (die sogenannten "requirements") erfasst, verfeinert und in einem Dokument festgehalten werden sollen. Alle weiteren im Entwicklungsprozess erstellten Dokumente wie Testspezifikation und -ergebnisse verweisen direkt auf diese Requirements.

Dieser Artikel beschränkt sich auf die Darstellung der VHDL-Richtlinien wie von der DO-254 usergroup erarbeitet und in dem Dokument "Best Practice VHDL Coding Standards for DO-254 Programs" aus dem Jahr 2010 festgehalten.

=Aufbau der Richtlinien=

Die designrules sind in 4 Kategorien unterteilt, die Gruppe bestimmt den
Prefix der Regel. Beispielsweise SS-10 für die Zehnte Regel in der Kategorie "Safe synthesis"

*SS - Safe Synthesis
*CP - Coding Practice
*CDC - Clock domain Crossing
*DR - Code Reviews

Jeder Regel ist ein Schweregrad (severity) zugeordnet:

*Note
*warning
*Error

Ja nach Risikograd des designs kann die Einhaltung der Regeln auf einzelne Schweregrade beschrebkt sein. Es ist bei einigen Regeln angegeben das in Einzelfällen Verletzung der Regel in der Schwere herabgestuft (von Error auf Warning) werden kann, wenn diese Fälle entsprechend dokumentiert und begründet werden.

==VHDL Schreibstil - Coding Practice (CP)==
Die Regel dieser Kategoriestellen sicher das ein Kodier-Stil benutzt wird der auf bewährter Designpraxis im Sicherheitskritischen Bereich beruht.

===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
Entity exa is (dat_i: IN dword);
Architecture behave of exa is
signal m_index : std_logic_vector ( 13 downto 0);
--..
m_index <= dat_i(M_index_lo to m_index_hi);
end exa;
</syntaxhighlight>

Sobald diese Fehler bei der Kompilierung entdeckt werden sollte man sie sofort korriegieren.

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide von der Breite eines Vector abhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

Die Zuweisung sollte in einer Weise geschehen das sie unabhängig von der bit-Anzahl im Vektor ist.
Das Verringert den Änderungsaufwand bei neuen Vektorbreiten und erleichter so die Design-Portierung.

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
Dieser Abschnitt (der eine einzelnen Regel enthält - Anm.d. Autors) behandelt potentialle Probleme in Designs mit mehreren Takt-Domainen und asynchronen Taktübergängen
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat oder in dem interne Takte generiert werden ist eine umfassende Analyse der Taktübergänge durchzuführen.''

Fehlerhafte Taktübergänge führen zur Metastabilität und unbestimmten Schaltungsverhalten, die stark nachteilige Einfluß auf den Betrieb des Gerät haben. Diese Richtlinien muß hier erwähnt werden, auch wenn die Analyse von Taktübergänge fern des Fokus von VHDL-Code-Style-check-tools und diesem Dokument ist.

Beim Design-Review muß nach möglichen Taktübergängen gesucht werden und wenn aufgefunden nachgewiesen werden das diese korrekt einsynchronisiert werden. Fehlverhalten durch inkorrekt ausgeführte Taktübergänge sind mit Testläufen an realer Hardware nur extrem schwierig einzugrenzen, deshalb ist die Designanalyse äußerst wichtig. Es ist oft unmöglich das Fehlverhalten fürs Debugging konsistent zu reproduzieren. Erschwerend kommt der Einfluß von Umgebungseinflußen während des Betriebes hinzu: kapazitive Last, Temperatur des Die's, Masseprellen. Im schlimmsten Fall zeigt sich der Fehler nie unter normalen Testbedingungen aber unter realen Einsatzbedingungen (Flug).

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error
Kombinatorische Rückkopplungen verursachen race-conditions und führen so zu nicht vorhersehbaren Verhalten.

Beispiel f. Verletzung:

<syntaxhighlight lang="vhdl">
fred_s <= gated_in_s OR pulse_r; --comb. loop at fred_s

P_GATED_IN: PROCESS(en_i, fred_s, pulse_r)
BEGIN
gated_in_s <= fred_s AND en_i;
IF (en_i = '0') THEN
gated_in_s <= NOT(fred_s);
ELSIF (pulse_r <= '1') THEN
gated_in_s <= '0';
END IF;
END PROCESS P_GATED_IN;
</syntaxhighlight>

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

Alle Register in den design sollten einen expliziten Reset haben. Ein Reset-Signal wird benutzt um ein Geröt in einen determinierten Zustand zu versetzen. Dieses vom system initierte "Error recovery" Kommando wird als letzte Rettungsmöglochkeit für nicht antwortende systzem benutzt. ("is used as the last resort recovery mechanism for a
non-responsive device.")

Ausnahmen bspw. synchronizer flops und scan chains sind möglich, sollten aber in jedem einzelnen Fall dokumentiert und begründet ("justify") werden. Mehrdimensionale signal/register die als memory implementiert sind, sind von dieser Warning ausgenommen.

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und Latches die nur unbenutzte Logik treiben, müssen untersucht werden.''
Schweregrad:Error

Unbenutzte Register, Latches und sonstige Logik sind einfach toter Code. Toter Code kann nachteilig sein wenn das Design wieder benutzt wird und der tote Code während der Portierung unbeabichtigt aktiv wird. Die Auswirkungen von totem Code bei der Erstellung von Sicherheitskritische Design ist nicht vorhersehbar und kann sich auch deutlich je nach verwendeten Synthese tool, Release-Version und soga Computersystemen unterscheiden. Damit ist eine konsistente Abschätzung der Folgen nicht möglich.

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide tiefe kombinatorische Veschaltungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

Die Ermittlung des kritischen Pfades ist schwieriger wenn der Pfad viele Hierachie-Ebenen durchquert. Lange kombinatorische Pfad - auch snake paths genannt- können Syntheseprobleme verursachen. Das Projekt-Team sollte eine Obergrenze für die Anzahl von Hierarchie-Ebenen die ein Pfad durchqueren kann festlegen. Jeder längere Pfad soll als Regelverletzung gemeldet werden und an einer passenden Stelle durch Einfügen eines Register verkürzt werden.

Anm. des Autors: Die Regel lautet im Original "Avoid Snake Paths"; allerdings ist im deutschen Sprachgebrauch Schlangenpfad oder ähnliches völlig ungebräuchlich und wurde nicht für die Überschrift übernommen.

Kritischer Pfad ist der Pfad zwischen zwei Registern der die längsten Laufzeit aufweist.

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Statements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Schweregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß- und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-11-15T19:21:51Z

Fpgakuechle: /* Grundsätzliches zur DO-254 */ jahr, Titel ergänzt

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-11-09, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie bei "richtigen" Programmiersprachen, wie C, existieren auch für [[VHDL]] Richtlinien, um gut les- und wartbaren Code zu schreiben, der zu stabilen und funktionssicheren Designs führt. Vieles davon ist Geschmackssache, mit der DO-254 gibt es jedoch einen anerkannten Standard, der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält, sondern auch Methoden zur
sicheren Umsetzung von Taktübergängen und FSMs empfiehlt.

== Grundsätzliches zur DO-254==
Die DO-254 ist die bekannteste Spezifikation zur Zertifizierung komplexer digitaler Schaltungen im Bereich der sogenannten Avionik (Fluggeräte). An solche Schaltungen werden üblicherweise höhere Sicherheitsanforderungen gestellt, als bspw. in der Consumer-Elektronik. Die Aufwände und Kosten für Simulation, Reviews, etc. steigen daher im Vergleich zu Designs ohne besondere Sicherheitsanforderungen auch um 50% und mehr.

Im Umfeld der DO-254 sind aber auch weniger teure "Ratschläge" für "saubere" Designs entstanden, die außerhalb des Avionikumfeldes nützlich sein können.

Das Grundthema der DO-254 ist die Qualitätssicherung, d.h. die Frage, wie man eine Entwicklung gestalten sollte, sodass das Produkt am Ende des Entwicklungsprozesses das Vertrauen in dessen Funktion rechtfertigt. Deshalb finden sich in der DO auch weniger technische Ratschläge oder Designspezifikationen, sondern vermehrt Methoden und Prozessbeschreibungen, die - in der Entwicklung und Verifikation sinngemäß angewandt - zu einem definierten und akzeptierten Grad an Vertrauen in die Funktionsfähigkeit der Produktes führen.

Die DO-254 beginnt mit der Beschreibung, wie Anforderungen (die sogenannten "requirements") erfasst, verfeinert und in einem Dokument festgehalten werden sollen. Alle weiteren im Entwicklungsprozess erstellten Dokumente wie Testspezifikation und -ergebnisse verweisen direkt auf diese Requirements.

Dieser Artikel beschränkt sich auf die Darstellung der VHDL-Richtlinien wie von der DO-254 usergroup erarbeitet und in dem Dokument "Best Practice VHDL Coding Standards for DO-254 Programs" aus dem Jahr 2010 festgehalten.

=Aufbau der Richtlinien=

Die designrules sind in 4 Kategorien unterteilt, die Gruppe bestimmt den
Prefix der Regel. Beispielsweise SS-10 für die Zehnte Regel in der Kategorie "Safe synthesis"

*SS - Safe Synthesis
*CP - Coding Practice
*CDC - Clock domain Crossing
*DR - Code Reviews

Jeder Regel ist ein Schweregrad (severity) zugeordnet:

*Note
*warning
*Error

Ja nach Risikograd des designs kann die Einhaltung der Regeln auf einzelne Schweregrade beschrebkt sein. Es ist bei einigen Regeln angegeben das in Einzelfällen Verletzung der Regel in der Schwere herabgestuft (von Error auf Warning) werden kann, wenn diese Fälle entsprechend dokumentiert und begründet werden.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
Dieser Abschnitt (der eine einzelnen Regel enthält - Anm.d. Autors) behandelt potentialle Probleme in Designs mit mehreren Takt-Domainen und asynchronen Taktübergängen
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat oder in dem interne Takte generiert werden ist eine umfassende Analyse der Taktübergänge durchzuführen.''

Fehlerhafte Taktübergänge führen zur Metastabilität und unbestimmten Schaltungsverhalten, die stark nachteilige Einfluß auf den Betrieb des Gerät haben. Diese Richtlinien muß hier erwähnt werden, auch wenn die Analyse von Taktübergänge fern des Fokus von VHDL-Code-Style-check-tools und diesem Dokument ist.

Beim Design-Review muß nach möglichen Taktübergängen gesucht werden und wenn aufgefunden nachgewiesen werden das diese korrekt einsynchronisiert werden. Fehlverhalten durch inkorrekt ausgeführte Taktübergänge sind mit Testläufen an realer Hardware nur extrem schwierig einzugrenzen, deshalb ist die Designanalyse äußerst wichtig. Es ist oft unmöglich das Fehlverhalten fürs Debugging konsistent zu reproduzieren. Erschwerend kommt der Einfluß von Umgebungseinflußen während des Betriebes hinzu: kapazitive Last, Temperatur des Die's, Masseprellen. Im schlimmsten Fall zeigt sich der Fehler nie unter normalen Testbedingungen aber unter realen Einsatzbedingungen (Flug).

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error
Kombinatorische Rückkopplungen verursachen race-conditions und führen so zu nicht vorhersehbaren Verhalten.

Beispiel f. Verletzung:

<syntaxhighlight lang="vhdl">
fred_s <= gated_in_s OR pulse_r; --comb. loop at fred_s

P_GATED_IN: PROCESS(en_i, fred_s, pulse_r)
BEGIN
gated_in_s <= fred_s AND en_i;
IF (en_i = '0') THEN
gated_in_s <= NOT(fred_s);
ELSIF (pulse_r <= '1') THEN
gated_in_s <= '0';
END IF;
END PROCESS P_GATED_IN;
</syntaxhighlight>

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

Alle Register in den design sollten einen expliziten Reset haben. Ein Reset-Signal wird benutzt um ein Geröt in einen determinierten Zustand zu versetzen. Dieses vom system initierte "Error recovery" Kommando wird als letzte Rettungsmöglochkeit für nicht antwortende systzem benutzt. ("is used as the last resort recovery mechanism for a
non-responsive device.")

Ausnahmen bspw. synchronizer flops und scan chains sind möglich, sollten aber in jedem einzelnen Fall dokumentiert und begründet ("justify") werden. Mehrdimensionale signal/register die als memory implementiert sind, sind von dieser Warning ausgenommen.

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und Latches die nur unbenutzte Logik treiben, müssen untersucht werden.''
Schweregrad:Error

Unbenutzte Register, Latches und sonstige Logik sind einfach toter Code. Toter Code kann nachteilig sein wenn das Design wieder benutzt wird und der tote Code während der Portierung unbeabichtigt aktiv wird. Die Auswirkungen von totem Code bei der Erstellung von Sicherheitskritische Design ist nicht vorhersehbar und kann sich auch deutlich je nach verwendeten Synthese tool, Release-Version und soga Computersystemen unterscheiden. Damit ist eine konsistente Abschätzung der Folgen nicht möglich.

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide tiefe kombinatorische Veschaltungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

Die Ermittlung des kritischen Pfades ist schwieriger wenn der Pfad viele Hierachie-Ebenen durchquert. Lange kombinatorische Pfad - auch snake paths genannt- können Syntheseprobleme verursachen. Das Projekt-Team sollte eine Obergrenze für die Anzahl von Hierarchie-Ebenen die ein Pfad durchqueren kann festlegen. Jeder längere Pfad soll als Regelverletzung gemeldet werden und an einer passenden Stelle durch Einfügen eines Register verkürzt werden.

Anm. des Autors: Die Regel lautet im Original "Avoid Snake Paths"; allerdings ist im deutschen Sprachgebrauch Schlangenpfad oder ähnliches völlig ungebräuchlich und wurde nicht für die Überschrift übernommen.

Kritischer Pfad ist der Pfad zwischen zwei Registern der die längsten Laufzeit aufweist.

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Statements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Schweregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß- und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-11-15T19:19:06Z

Fpgakuechle: /* Taktübergange - Clock Domain Crossing (CDC) */ Begründung ergänzt

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-11-09, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie bei "richtigen" Programmiersprachen, wie C, existieren auch für [[VHDL]] Richtlinien, um gut les- und wartbaren Code zu schreiben, der zu stabilen und funktionssicheren Designs führt. Vieles davon ist Geschmackssache, mit der DO-254 gibt es jedoch einen anerkannten Standard, der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält, sondern auch Methoden zur
sicheren Umsetzung von Taktübergängen und FSMs empfiehlt.

== Grundsätzliches zur DO-254==
Die DO-254 ist die bekannteste Spezifikation zur Zertifizierung komplexer digitaler Schaltungen im Bereich der sogenannten Avionik (Fluggeräte). An solche Schaltungen werden üblicherweise höhere Sicherheitsanforderungen gestellt, als bspw. in der Consumer-Elektronik. Die Aufwände und Kosten für Simulation, Reviews, etc. steigen daher im Vergleich zu Designs ohne besondere Sicherheitsanforderungen auch um 50% und mehr.

Im Umfeld der DO-254 sind aber auch weniger teure "Ratschläge" für "saubere" Designs entstanden, die außerhalb des Avionikumfeldes nützlich sein können.

Das Grundthema der DO-254 ist die Qualitätssicherung, d.h. die Frage, wie man eine Entwicklung gestalten sollte, sodass das Produkt am Ende des Entwicklungsprozesses das Vertrauen in dessen Funktion rechtfertigt. Deshalb finden sich in der DO auch weniger technische Ratschläge oder Designspezifikationen, sondern vermehrt Methoden und Prozessbeschreibungen, die - in der Entwicklung und Verifikation sinngemäß angewandt - zu einem definierten und akzeptierten Grad an Vertrauen in die Funktionsfähigkeit der Produktes führen.

Die DO-254 beginnt mit der Beschreibung, wie Anforderungen (die sogenannten "requirements") erfasst, verfeinert und in einem Dokument festgehalten werden sollen. Alle weiteren im Entwicklungsprozess erstellten Dokumente wie Testspezifikation und -ergebnisse verweisen direkt auf diese Requirements.

Dieser Artikel beschränkt sich auf die Darstellung der VHDL-Richtlinien wie von der DO-254 usergroup erarbeitet.

=Aufbau der Richtlinien=

Die designrules sind in 4 Kategorien unterteilt, die Gruppe bestimmt den
Prefix der Regel. Beispielsweise SS-10 für die Zehnte Regel in der Kategorie "Safe synthesis"

*SS - Safe Synthesis
*CP - Coding Practice
*CDC - Clock domain Crossing
*DR - Code Reviews

Jeder Regel ist ein Schweregrad (severity) zugeordnet:

*Note
*warning
*Error

Ja nach Risikograd des designs kann die Einhaltung der Regeln auf einzelne Schweregrade beschrebkt sein. Es ist bei einigen Regeln angegeben das in Einzelfällen Verletzung der Regel in der Schwere herabgestuft (von Error auf Warning) werden kann, wenn diese Fälle entsprechend dokumentiert und begründet werden.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
Dieser Abschnitt (der eine einzelnen Regel enthält - Anm.d. Autors) behandelt potentialle Probleme in Designs mit mehreren Takt-Domainen und asynchronen Taktübergängen
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat oder in dem interne Takte generiert werden ist eine umfassende Analyse der Taktübergänge durchzuführen.''

Fehlerhafte Taktübergänge führen zur Metastabilität und unbestimmten Schaltungsverhalten, die stark nachteilige Einfluß auf den Betrieb des Gerät haben. Diese Richtlinien muß hier erwähnt werden, auch wenn die Analyse von Taktübergänge fern des Fokus von VHDL-Code-Style-check-tools und diesem Dokument ist.

Beim Design-Review muß nach möglichen Taktübergängen gesucht werden und wenn aufgefunden nachgewiesen werden das diese korrekt einsynchronisiert werden. Fehlverhalten durch inkorrekt ausgeführte Taktübergänge sind mit Testläufen an realer Hardware nur extrem schwierig einzugrenzen, deshalb ist die Designanalyse äußerst wichtig. Es ist oft unmöglich das Fehlverhalten fürs Debugging konsistent zu reproduzieren. Erschwerend kommt der Einfluß von Umgebungseinflußen während des Betriebes hinzu: kapazitive Last, Temperatur des Die's, Masseprellen. Im schlimmsten Fall zeigt sich der Fehler nie unter normalen Testbedingungen aber unter realen Einsatzbedingungen (Flug).

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error
Kombinatorische Rückkopplungen verursachen race-conditions und führen so zu nicht vorhersehbaren Verhalten.

Beispiel f. Verletzung:

<syntaxhighlight lang="vhdl">
fred_s <= gated_in_s OR pulse_r; --comb. loop at fred_s

P_GATED_IN: PROCESS(en_i, fred_s, pulse_r)
BEGIN
gated_in_s <= fred_s AND en_i;
IF (en_i = '0') THEN
gated_in_s <= NOT(fred_s);
ELSIF (pulse_r <= '1') THEN
gated_in_s <= '0';
END IF;
END PROCESS P_GATED_IN;
</syntaxhighlight>

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

Alle Register in den design sollten einen expliziten Reset haben. Ein Reset-Signal wird benutzt um ein Geröt in einen determinierten Zustand zu versetzen. Dieses vom system initierte "Error recovery" Kommando wird als letzte Rettungsmöglochkeit für nicht antwortende systzem benutzt. ("is used as the last resort recovery mechanism for a
non-responsive device.")

Ausnahmen bspw. synchronizer flops und scan chains sind möglich, sollten aber in jedem einzelnen Fall dokumentiert und begründet ("justify") werden. Mehrdimensionale signal/register die als memory implementiert sind, sind von dieser Warning ausgenommen.

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und Latches die nur unbenutzte Logik treiben, müssen untersucht werden.''
Schweregrad:Error

Unbenutzte Register, Latches und sonstige Logik sind einfach toter Code. Toter Code kann nachteilig sein wenn das Design wieder benutzt wird und der tote Code während der Portierung unbeabichtigt aktiv wird. Die Auswirkungen von totem Code bei der Erstellung von Sicherheitskritische Design ist nicht vorhersehbar und kann sich auch deutlich je nach verwendeten Synthese tool, Release-Version und soga Computersystemen unterscheiden. Damit ist eine konsistente Abschätzung der Folgen nicht möglich.

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide tiefe kombinatorische Veschaltungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

Die Ermittlung des kritischen Pfades ist schwieriger wenn der Pfad viele Hierachie-Ebenen durchquert. Lange kombinatorische Pfad - auch snake paths genannt- können Syntheseprobleme verursachen. Das Projekt-Team sollte eine Obergrenze für die Anzahl von Hierarchie-Ebenen die ein Pfad durchqueren kann festlegen. Jeder längere Pfad soll als Regelverletzung gemeldet werden und an einer passenden Stelle durch Einfügen eines Register verkürzt werden.

Anm. des Autors: Die Regel lautet im Original "Avoid Snake Paths"; allerdings ist im deutschen Sprachgebrauch Schlangenpfad oder ähnliches völlig ungebräuchlich und wurde nicht für die Überschrift übernommen.

Kritischer Pfad ist der Pfad zwischen zwei Registern der die längsten Laufzeit aufweist.

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Statements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Schweregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß- und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-11-14T08:52:47Z

Fpgakuechle: /* Vermeide Schlangengleiche Verdrahtungen (SS19) */ Erläuterung ergänst

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-11-09, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie bei "richtigen" Programmiersprachen, wie C, existieren auch für [[VHDL]] Richtlinien, um gut les- und wartbaren Code zu schreiben, der zu stabilen und funktionssicheren Designs führt. Vieles davon ist Geschmackssache, mit der DO-254 gibt es jedoch einen anerkannten Standard, der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält, sondern auch Methoden zur
sicheren Umsetzung von Taktübergängen und FSMs empfiehlt.

== Grundsätzliches zur DO-254==
Die DO-254 ist die bekannteste Spezifikation zur Zertifizierung komplexer digitaler Schaltungen im Bereich der sogenannten Avionik (Fluggeräte). An solche Schaltungen werden üblicherweise höhere Sicherheitsanforderungen gestellt, als bspw. in der Consumer-Elektronik. Die Aufwände und Kosten für Simulation, Reviews, etc. steigen daher im Vergleich zu Designs ohne besondere Sicherheitsanforderungen auch um 50% und mehr.

Im Umfeld der DO-254 sind aber auch weniger teure "Ratschläge" für "saubere" Designs entstanden, die außerhalb des Avionikumfeldes nützlich sein können.

Das Grundthema der DO-254 ist die Qualitätssicherung, d.h. die Frage, wie man eine Entwicklung gestalten sollte, sodass das Produkt am Ende des Entwicklungsprozesses das Vertrauen in dessen Funktion rechtfertigt. Deshalb finden sich in der DO auch weniger technische Ratschläge oder Designspezifikationen, sondern vermehrt Methoden und Prozessbeschreibungen, die - in der Entwicklung und Verifikation sinngemäß angewandt - zu einem definierten und akzeptierten Grad an Vertrauen in die Funktionsfähigkeit der Produktes führen.

Die DO-254 beginnt mit der Beschreibung, wie Anforderungen (die sogenannten "requirements") erfasst, verfeinert und in einem Dokument festgehalten werden sollen. Alle weiteren im Entwicklungsprozess erstellten Dokumente wie Testspezifikation und -ergebnisse verweisen direkt auf diese Requirements.

Dieser Artikel beschränkt sich auf die Darstellung der VHDL-Richtlinien wie von der DO-254 usergroup erarbeitet.

=Aufbau der Richtlinien=

Die designrules sind in 4 Kategorien unterteilt, die Gruppe bestimmt den
Prefix der Regel. Beispielsweise SS-10 für die Zehnte Regel in der Kategorie "Safe synthesis"

*SS - Safe Synthesis
*CP - Coding Practice
*CDC - Clock domain Crossing
*DR - Code Reviews

Jeder Regel ist ein Schweregrad (severity) zugeordnet:

*Note
*warning
*Error

Ja nach Risikograd des designs kann die Einhaltung der Regeln auf einzelne Schweregrade beschrebkt sein. Es ist bei einigen Regeln angegeben das in Einzelfällen Verletzung der Regel in der Schwere herabgestuft (von Error auf Warning) werden kann, wenn diese Fälle entsprechend dokumentiert und begründet werden.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error
Kombinatorische Rückkopplungen verursachen race-conditions und führen so zu nicht vorhersehbaren Verhalten.

Beispiel f. Verletzung:

<syntaxhighlight lang="vhdl">
fred_s <= gated_in_s OR pulse_r; --comb. loop at fred_s

P_GATED_IN: PROCESS(en_i, fred_s, pulse_r)
BEGIN
gated_in_s <= fred_s AND en_i;
IF (en_i = '0') THEN
gated_in_s <= NOT(fred_s);
ELSIF (pulse_r <= '1') THEN
gated_in_s <= '0';
END IF;
END PROCESS P_GATED_IN;
</syntaxhighlight>

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

Alle Register in den design sollten einen expliziten Reset haben. Ein Reset-Signal wird benutzt um ein Geröt in einen determinierten Zustand zu versetzen. Dieses vom system initierte "Error recovery" Kommando wird als letzte Rettungsmöglochkeit für nicht antwortende systzem benutzt. ("is used as the last resort recovery mechanism for a
non-responsive device.")

Ausnahmen bspw. synchronizer flops und scan chains sind möglich, sollten aber in jedem einzelnen Fall dokumentiert und begründet ("justify") werden. Mehrdimensionale signal/register die als memory implementiert sind, sind von dieser Warning ausgenommen.

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und Latches die nur unbenutzte Logik treiben, müssen untersucht werden.''
Schweregrad:Error

Unbenutzte Register, Latches und sonstige Logik sind einfach toter Code. Toter Code kann nachteilig sein wenn das Design wieder benutzt wird und der tote Code während der Portierung unbeabichtigt aktiv wird. Die Auswirkungen von totem Code bei der Erstellung von Sicherheitskritische Design ist nicht vorhersehbar und kann sich auch deutlich je nach verwendeten Synthese tool, Release-Version und soga Computersystemen unterscheiden. Damit ist eine konsistente Abschätzung der Folgen nicht möglich.

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide tiefe kombinatorische Veschaltungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

Die Ermittlung des kritischen Pfades ist schwieriger wenn der Pfad viele Hierachie-Ebenen durchquert. Lange kombinatorische Pfad - auch snake paths genannt- können Syntheseprobleme verursachen. Das Projekt-Team sollte eine Obergrenze für die Anzahl von Hierarchie-Ebenen die ein Pfad durchqueren kann festlegen. Jeder längere Pfad soll als Regelverletzung gemeldet werden und an einer passenden Stelle durch Einfügen eines Register verkürzt werden.

Anm. des Autors: Die Regel lautet im Original "Avoid Snake Paths"; allerdings ist im deutschen Sprachgebrauch Schlangenpfad oder ähnliches völlig ungebräuchlich und wurde nicht für die Überschrift übernommen.

Kritischer Pfad ist der Pfad zwischen zwei Registern der die längsten Laufzeit aufweist.

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Statements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Schweregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß- und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-11-12T07:14:03Z

Fpgakuechle: /* Vermeide Logik ohne Treiber oder Nutzung (SS17) */ Begründung ergänzt

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-11-09, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie bei "richtigen" Programmiersprachen, wie C, existieren auch für [[VHDL]] Richtlinien, um gut les- und wartbaren Code zu schreiben, der zu stabilen und funktionssicheren Designs führt. Vieles davon ist Geschmackssache, mit der DO-254 gibt es jedoch einen anerkannten Standard, der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält, sondern auch Methoden zur
sicheren Umsetzung von Taktübergängen und FSMs empfiehlt.

== Grundsätzliches zur DO-254==
Die DO-254 ist die bekannteste Spezifikation zur Zertifizierung komplexer digitaler Schaltungen im Bereich der sogenannten Avionik (Fluggeräte). An solche Schaltungen werden üblicherweise höhere Sicherheitsanforderungen gestellt, als bspw. in der Consumer-Elektronik. Die Aufwände und Kosten für Simulation, Reviews, etc. steigen daher im Vergleich zu Designs ohne besondere Sicherheitsanforderungen auch um 50% und mehr.

Im Umfeld der DO-254 sind aber auch weniger teure "Ratschläge" für "saubere" Designs entstanden, die außerhalb des Avionikumfeldes nützlich sein können.

Das Grundthema der DO-254 ist die Qualitätssicherung, d.h. die Frage, wie man eine Entwicklung gestalten sollte, sodass das Produkt am Ende des Entwicklungsprozesses das Vertrauen in dessen Funktion rechtfertigt. Deshalb finden sich in der DO auch weniger technische Ratschläge oder Designspezifikationen, sondern vermehrt Methoden und Prozessbeschreibungen, die - in der Entwicklung und Verifikation sinngemäß angewandt - zu einem definierten und akzeptierten Grad an Vertrauen in die Funktionsfähigkeit der Produktes führen.

Die DO-254 beginnt mit der Beschreibung, wie Anforderungen (die sogenannten "requirements") erfasst, verfeinert und in einem Dokument festgehalten werden sollen. Alle weiteren im Entwicklungsprozess erstellten Dokumente wie Testspezifikation und -ergebnisse verweisen direkt auf diese Requirements.

Dieser Artikel beschränkt sich auf die Darstellung der VHDL-Richtlinien wie von der DO-254 usergroup erarbeitet.

=Aufbau der Richtlinien=

Die designrules sind in 4 Kategorien unterteilt, die Gruppe bestimmt den
Prefix der Regel. Beispielsweise SS-10 für die Zehnte Regel in der Kategorie "Safe synthesis"

*SS - Safe Synthesis
*CP - Coding Practice
*CDC - Clock domain Crossing
*DR - Code Reviews

Jeder Regel ist ein Schweregrad (severity) zugeordnet:

*Note
*warning
*Error

Ja nach Risikograd des designs kann die Einhaltung der Regeln auf einzelne Schweregrade beschrebkt sein. Es ist bei einigen Regeln angegeben das in Einzelfällen Verletzung der Regel in der Schwere herabgestuft (von Error auf Warning) werden kann, wenn diese Fälle entsprechend dokumentiert und begründet werden.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error
Kombinatorische Rückkopplungen verursachen race-conditions und führen so zu nicht vorhersehbaren Verhalten.

Beispiel f. Verletzung:

<syntaxhighlight lang="vhdl">
fred_s <= gated_in_s OR pulse_r; --comb. loop at fred_s

P_GATED_IN: PROCESS(en_i, fred_s, pulse_r)
BEGIN
gated_in_s <= fred_s AND en_i;
IF (en_i = '0') THEN
gated_in_s <= NOT(fred_s);
ELSIF (pulse_r <= '1') THEN
gated_in_s <= '0';
END IF;
END PROCESS P_GATED_IN;
</syntaxhighlight>

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

Alle Register in den design sollten einen expliziten Reset haben. Ein Reset-Signal wird benutzt um ein Geröt in einen determinierten Zustand zu versetzen. Dieses vom system initierte "Error recovery" Kommando wird als letzte Rettungsmöglochkeit für nicht antwortende systzem benutzt. ("is used as the last resort recovery mechanism for a
non-responsive device.")

Ausnahmen bspw. synchronizer flops und scan chains sind möglich, sollten aber in jedem einzelnen Fall dokumentiert und begründet ("justify") werden. Mehrdimensionale signal/register die als memory implementiert sind, sind von dieser Warning ausgenommen.

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und Latches die nur unbenutzte Logik treiben, müssen untersucht werden.''
Schweregrad:Error

Unbenutzte Register, Latches und sonstige Logik sind einfach toter Code. Toter Code kann nachteilig sein wenn das Design wieder benutzt wird und der tote Code während der Portierung unbeabichtigt aktiv wird. Die Auswirkungen von totem Code bei der Erstellung von Sicherheitskritische Design ist nicht vorhersehbar und kann sich auch deutlich je nach verwendeten Synthese tool, Release-Version und soga Computersystemen unterscheiden. Damit ist eine konsistente Abschätzung der Folgen nicht möglich.

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Statements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Schweregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß- und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-11-11T06:50:32Z

Fpgakuechle: /* Vermeide Kombinatorische Rückkoppelungen (SS3) */ *Beispiel u. Begründung

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-11-09, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie bei "richtigen" Programmiersprachen, wie C, existieren auch für [[VHDL]] Richtlinien, um gut les- und wartbaren Code zu schreiben, der zu stabilen und funktionssicheren Designs führt. Vieles davon ist Geschmackssache, mit der DO-254 gibt es jedoch einen anerkannten Standard, der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält, sondern auch Methoden zur
sicheren Umsetzung von Taktübergängen und FSMs empfiehlt.

== Grundsätzliches zur DO-254==
Die DO-254 ist die bekannteste Spezifikation zur Zertifizierung komplexer digitaler Schaltungen im Bereich der sogenannten Avionik (Fluggeräte). An solche Schaltungen werden üblicherweise höhere Sicherheitsanforderungen gestellt, als bspw. in der Consumer-Elektronik. Die Aufwände und Kosten für Simulation, Reviews, etc. steigen daher im Vergleich zu Designs ohne besondere Sicherheitsanforderungen auch um 50% und mehr.

Im Umfeld der DO-254 sind aber auch weniger teure "Ratschläge" für "saubere" Designs entstanden, die außerhalb des Avionikumfeldes nützlich sein können.

Das Grundthema der DO-254 ist die Qualitätssicherung, d.h. die Frage, wie man eine Entwicklung gestalten sollte, sodass das Produkt am Ende des Entwicklungsprozesses das Vertrauen in dessen Funktion rechtfertigt. Deshalb finden sich in der DO auch weniger technische Ratschläge oder Designspezifikationen, sondern vermehrt Methoden und Prozessbeschreibungen, die - in der Entwicklung und Verifikation sinngemäß angewandt - zu einem definierten und akzeptierten Grad an Vertrauen in die Funktionsfähigkeit der Produktes führen.

Die DO-254 beginnt mit der Beschreibung, wie Anforderungen (die sogenannten "requirements") erfasst, verfeinert und in einem Dokument festgehalten werden sollen. Alle weiteren im Entwicklungsprozess erstellten Dokumente wie Testspezifikation und -ergebnisse verweisen direkt auf diese Requirements.

Dieser Artikel beschränkt sich auf die Darstellung der VHDL-Richtlinien wie von der DO-254 usergroup erarbeitet.

=Aufbau der Richtlinien=

Die designrules sind in 4 Kategorien unterteilt, die Gruppe bestimmt den
Prefix der Regel. Beispielsweise SS-10 für die Zehnte Regel in der Kategorie "Safe synthesis"

*SS - Safe Synthesis
*CP - Coding Practice
*CDC - Clock domain Crossing
*DR - Code Reviews

Jeder Regel ist ein Schweregrad (severity) zugeordnet:

*Note
*warning
*Error

Ja nach Risikograd des designs kann die Einhaltung der Regeln auf einzelne Schweregrade beschrebkt sein. Es ist bei einigen Regeln angegeben das in Einzelfällen Verletzung der Regel in der Schwere herabgestuft (von Error auf Warning) werden kann, wenn diese Fälle entsprechend dokumentiert und begründet werden.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error
Kombinatorische Rückkopplungen verursachen race-conditions und führen so zu nicht vorhersehbaren Verhalten.

Beispiel f. Verletzung:

<syntaxhighlight lang="vhdl">
fred_s <= gated_in_s OR pulse_r; --comb. loop at fred_s

P_GATED_IN: PROCESS(en_i, fred_s, pulse_r)
BEGIN
gated_in_s <= fred_s AND en_i;
IF (en_i = '0') THEN
gated_in_s <= NOT(fred_s);
ELSIF (pulse_r <= '1') THEN
gated_in_s <= '0';
END IF;
END PROCESS P_GATED_IN;
</syntaxhighlight>

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

Alle Register in den design sollten einen expliziten Reset haben. Ein Reset-Signal wird benutzt um ein Geröt in einen determinierten Zustand zu versetzen. Dieses vom system initierte "Error recovery" Kommando wird als letzte Rettungsmöglochkeit für nicht antwortende systzem benutzt. ("is used as the last resort recovery mechanism for a
non-responsive device.")

Ausnahmen bspw. synchronizer flops und scan chains sind möglich, sollten aber in jedem einzelnen Fall dokumentiert und begründet ("justify") werden. Mehrdimensionale signal/register die als memory implementiert sind, sind von dieser Warning ausgenommen.

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Statements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Schweregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß- und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

Diskussion:VHDL Code Style und DO-254

2015-11-10T19:06:01Z

Fpgakuechle: Danke!

== Lemma ==
Habe mir mal erlaubt, das Ganze flüssiger zu machen. Ich hoffe der Tenor bleibt erhalten und wird deutlicher. [[Spezial:Beiträge/87.178.122.136|87.178.122.136]] 02:18, 10. Nov. 2015 (CET)
:Vielen Dank, es ist Dir wirklich flüssiger gelungen. Manchmal steckt man quasi im Englischen Duktus fest, leider gibt es zuwenig deutsche Fachliteratur die man hier als Formulierungsvorlage benutzen könnte. MfG, --[[Benutzer:Fpgakuechle|Fpgakuechle]] ([[Benutzer Diskussion:Fpgakuechle|Diskussion]]) 20:06, 10. Nov. 2015 (CET)

VHDL Code Style und DO-254

2015-11-09T22:27:11Z

Fpgakuechle: Mehr Einordnung; Einleitung SS-14 detailierter

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-11-09, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie für "richtige Programmiersprachen wie C" gibt es auch für VHDL Richtlinien um gut les- und wartbaren
Code zu schreiben der zu stabilenen und sicheren Designs führt. Viel davon ist Geschmackssache, mit der DO-254 gibt es
einen anerkannten Standard der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält sondern auch Methodiken zur
sicheren Umsetzung von Taktübergängen und FSM enthält.

== Grundsätzliches zur DO-254==
Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik. An diese werden deutlich höhere Sicherheitsanforderungen gestellt als bspw. Consumer-Elektronik. Die Aufwände und Kosten für Simulation, Reviews, etc. steigt um ca 50% im Vergleich zu Designs ohne besondere Sichherheitsanforderungen. Im Umfeld der DO-254 sind aber auch weniger teure "Ratschläge" für "saubere" Designs entstanden.

Grundidee der DO-254 ist Qualitätssicherung - wie gestaltet man die Entwicklung so das das Produkt
an Ende des Entwicklungsprozesses das Vertrauen in diesen Funktion gerechtfertigt. Deshalb finden sich in der DO auch kaum technische Ratschläge oder Designspezifikationen sondern Methoden und Prozessbeschreibungen die angewandt in der Entwicklung und Verifikation zu einem aktzeptierten Grad an Vertrauen in die Funktionsfähigkeit der Produktes führen.

Die DO beginnt mit der Beschreibung wie Anforderungen (requirements) erfasst, verfeinert und in einem Dokument festgehalten werden. Alle weiteren im Entwicklungsprozess erstellten Dokumente wie Testspezifikation und -ergebnisse verweisen direkt auf diese Requirements.
Dieser Artikel beschränkt sich auf die Darstellung der VHDL-Richtlinien wie von der DO-254 usergroup erarbeitet.

=Aufbau der Richtlinien=

Die designrules sind in 4 Kategorien unterteilt, die Gruppe bestimmt den
Prefix der Regel. Beispielsweise SS-10 für die Zehnte Regel in der Kategorie "Safe synthesis"

*SS - Safe Synthesis
*CP - Coding Practice
*CDC - Clock domain Crossing
*DR - Code Reviews

Jeder Regel ist ein Schweregrad (severity) zugeordnet:

*Note
*warning
*Error

Ja nach Risikograd des designs kann die Einhaltung der Regeln auf einzelne Schweregrade beschrebkt sein. Es ist bei einigen Regeln angegeben das in Einzelfällen Verletzung der Regel in der Schwere herabgestuft (von Error auf Warning) werden kann, wenn diese Fälle entsprechend dokumentiert und begründet werden.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

Alle Register in den design sollten einen expliziten Reset haben. Ein Reset-Signal wird benutzt um ein Geröt in einen determinierten Zustand zu versetzen. Dieses vom system initierte "Error recovery" Kommando wird als letzte Rettungsmöglochkeit für nicht antwortende systzem benutzt. ("is used as the last resort recovery mechanism for a
non-responsive device.")

Ausnahmen bspw. synchronizer flops und scan chains sind möglich, sollten aber in jedem einzelnen Fall dokumentiert und begründet ("justify") werden. Mehrdimensionale signal/register die als memory implementiert sind, sind von dieser Warning ausgenommen.

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Statements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Schweregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß- und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-11-08T21:17:42Z

Fpgakuechle: /* Vermeide Register ohne Reset (SS14) */ Ausnahmen und Behandlung dieser ergänzt

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie für "richtige Programmiersprachen wie C" gibt es auch für VHDL Richtlinien um gut les- und wartbaren
Code zu schreiben der zu stabilenen und sicheren Designs führt. Viel davon ist Geschmackssache, mit der DO-254 gibt es
einen anerkannten Standard der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält sondern auch Methodiken zur
sicheren Umsetzung von Taktübergängen und FSM enthält.

Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik. An diese werden deutlich höhere Sicherheitsanforderungen gestellt als bspw. Consumer-Elektronik. Die Aufwände und Kosten für Simulation, Reviews, etc. steigt um ca 50% im Vergleich zu Designs ohne besondere Sichherheitsanforderungen. Im Umfeld der DO-254 sind aber auch weniger teure "Ratschläge" für "saubere" Designs entstanden.

Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

Ausnahmen bspw. synchronizer flops und scan chains sind möglich, sollten aber in jedem einzelnen Fall dokumentiert und begründet ("justify") werden. Mehrdimensionale signal/register die als memory implementiert sind, sind von dieser Warning ausgenommen.

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Statements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Schweregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß- und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-11-07T16:35:39Z

Fpgakuechle: typos

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie für "richtige Programmiersprachen wie C" gibt es auch für VHDL Richtlinien um gut les- und wartbaren
Code zu schreiben der zu stabilenen und sicheren Designs führt. Viel davon ist Geschmackssache, mit der DO-254 gibt es
einen anerkannten Standard der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält sondern auch Methodiken zur
sicheren Umsetzung von Taktübergängen und FSM enthält.

Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik. An diese werden deutlich höhere Sicherheitsanforderungen gestellt als bspw. Consumer-Elektronik. Die Aufwände und Kosten für Simulation, Reviews, etc. steigt um ca 50% im Vergleich zu Designs ohne besondere Sichherheitsanforderungen. Im Umfeld der DO-254 sind aber auch weniger teure "Ratschläge" für "saubere" Designs entstanden.

Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Statements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Schweregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß- und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-11-06T22:06:23Z

Fpgakuechle: /* Checkliste für FPGA (VHDL)-Designs (nach DO-254) */ Verdeutlichung DO-254 ist für Designs mit erhöhten Sicherheitsstandards

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie für "richtige Programmiersprachen wie C" gibt es auch für VHDL Richtlinien um gut les- und wartbaren
Code zu schreiben der zu stabilenen und sicheren Designs führt. Viel davon ist Geschmackssache, mit der DO-254 gibt es
einen anerkannten Standard der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält sondern auch Methodiken zur
sicheren Umsetzung von Taktübergängen und FSM enthält.

Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik. An diese werden deutlich höhere Sicherheitsanforderungen gestellt als bspw. Consumer-Elektronik. Die Aufwände und Kosten für Simulation, Reviews, etc. steigt um ca 50% im Vergleich zu Designs ohne besondere Sichherheitsanforderungen. Im Umfeld der DO-254 sind aber auch weniger teure "Ratschläge" für "saubere" Designs entstanden.

Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Staements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Scheregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-11-06T21:45:39Z

Fpgakuechle: /* Vermeide mehrfache Wellenformen (SS5) */ Ausführlich, Hinweis auf Überstzungshürden; missmatch Simu und Synthese

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie für "richtige Programmiersprachen wie C" gibt es auch für VHDL Richtlinien um gut les- und wartbaren
Code zu schreiben der zu stabilenen und sicheren Designs führt. Viel davon ist Geschmackssache, mit der DO-254 gibt es
einen anerkannten Standard der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält sondern auch Methodiken zur
sicheren Umsetzung von Taktübergängen und FSM enthält.

Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik.
Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Signalkurven - Avoid Multiple Waveforms (SS5) ===
*Nur eine Waveform soll auf der rechte Seite einer Signalzuweisung stehen. Beispiel Fehler:
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

In der Erklärung wird ausgeführt das eine Signalkurve ("waveform") aus einer Wertzuweisung ("assignment Value expression") und einer optionalen Verzögerung ("assignment delay expression") besteht. Mehrfache Signalkurven sind nicht synthetisierbar und daher stimmt Simulation und synthetisierte Hardware für diese nicht überein.
Leider kennt der Autor keine ihn zufrieden stellende Übersetzung für "multiple waveform". "Waveform" kann hier Signalform, Signalkurve heißen , was "multiple" am besten wiedergibt ist weitaus unklarer. Wörterbücher biten "mehrfach", "mannigfaltig", "vielwertig an.

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Staements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Scheregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-04-19T15:45:10Z

Fpgakuechle: /* Stelle sicher das die Zustandsübergänge sicher sind (CP6) */ typo

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie für "richtige Programmiersprachen wie C" gibt es auch für VHDL Richtlinien um gut les- und wartbaren
Code zu schreiben der zu stabilenen und sicheren Designs führt. Viel davon ist Geschmackssache, mit der DO-254 gibt es
einen anerkannten Standard der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält sondern auch Methodiken zur
sicheren Umsetzung von Taktübergängen und FSM enthält.

Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik.
Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= ABRT;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Wellenformen (SS5) ===
*Nur eine Waveform soll auf der rechte Seite nur eine Wellenform haben.
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Staements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Scheregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-04-19T15:43:51Z

Fpgakuechle: /* Stelle sicher das die Zustandsübergänge sicher sind (CP6) */ +bsp

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie für "richtige Programmiersprachen wie C" gibt es auch für VHDL Richtlinien um gut les- und wartbaren
Code zu schreiben der zu stabilenen und sicheren Designs führt. Viel davon ist Geschmackssache, mit der DO-254 gibt es
einen anerkannten Standard der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält sondern auch Methodiken zur
sicheren Umsetzung von Taktübergängen und FSM enthält.

Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik.
Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error
<syntaxhighlight lang="vhdl">
TYPE T_STATE_TYPE is (NOP, --default and reset state
START_TR,
BRST_CONT,
BRST_END
-- FGH --auskommentierter Zustand
);
-- ..

CASE state_q IS
WHEN NOP =>
IF (tr_req = '1' AND rnw = '1' ) THEN
next_state <= START_TR;
END IF;
--...
WHEN BRST_CONT => --Fehler: kein hinführender Übergang
next_state <= BRST_END;

WHEN BRST_END => --Fehler: kein verlassender Übergang
IF tr_req = '0' THEN
status <= BRST_END;
END IF;

WHEN OTHERS =>
next_state <= FGH; --Fehler FGH ist nicht definiert

END CASE;

</syntaxhighlight>

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Wellenformen (SS5) ===
*Nur eine Waveform soll auf der rechte Seite nur eine Wellenform haben.
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Staements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Scheregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-04-17T05:11:01Z

Fpgakuechle: /* Vermeide vectorlängenabhängige Zuweisungen (CP4) */ typo

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie für "richtige Programmiersprachen wie C" gibt es auch für VHDL Richtlinien um gut les- und wartbaren
Code zu schreiben der zu stabilenen und sicheren Designs führt. Viel davon ist Geschmackssache, mit der DO-254 gibt es
einen anerkannten Standard der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält sondern auch Methodiken zur
sicheren Umsetzung von Taktübergängen und FSM enthält.

Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik.
Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0');
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Wellenformen (SS5) ===
*Nur eine Waveform soll auf der rechte Seite nur eine Wellenform haben.
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Staements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Scheregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-04-13T05:57:27Z

Fpgakuechle: Einleitung

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Wie für "richtige Programmiersprachen wie C" gibt es auch für VHDL Richtlinien um gut les- und wartbaren
Code zu schreiben der zu stabilenen und sicheren Designs führt. Viel davon ist Geschmackssache, mit der DO-254 gibt es
einen anerkannten Standard der nicht nur "Schönheitsregeln" wie Namenskonventionen enthält sondern auch Methodiken zur
sicheren Umsetzung von Taktübergängen und FSM enthält.

Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik.
Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0)";
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Wellenformen (SS5) ===
*Nur eine Waveform soll auf der rechte Seite nur eine Wellenform haben.
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Staements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Scheregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Platzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

VHDL Code Style und DO-254

2015-04-13T05:16:51Z

Fpgakuechle: +Kat

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik.
Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===
*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen.''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden.''
*Schweregrad: Error

<syntaxhighlight lang="vhdl">
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
</syntaxhighlight>

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0)";
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollten nicht hart codiert sein, außer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Reset-Zustand haben.''
*''b: Alle ungenutzen (illegale oder undefinierte) Zustände sollen in einen definierten Zustand übergehen. In diesem Zustand soll die fehlerursache angemessen bearbeitet werden''
*''c: Es sollen keine unerreichbaren und keine Sackgassen-Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig ist (CP8)===
*''Die sensetivity list sollte nur im process verwendete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll:''
*''nur einen Entrittspunkt,''
*''keine Rekursion,''
*''nur Zugriff auf lokale Variablen/Signale haben.''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein,''
*''b) keine doppelten oder überlappenden Anweisungen enthalten,''
*''c) keine nichterreichbare Anweisungen enthalten,''
*''d) immer eine "when others" Regel enthalten.''
*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning

===Vermeide mehrfache Wellenformen (SS5) ===
*Nur eine Waveform soll auf der rechte Seite nur eine Wellenform haben.
<syntaxhighlight lang="vhdl">
write <= '1' after clk_prd, '0' after 8*clk_prd;
</syntaxhighlight>
*Schweregrad: Error

===Vermeide mehrfache Signaltreiber (SS6) ===
''*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.''
*Schweregrad: Error

=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*''Stelle sicher das alle VHDL Konstanten initialisiert werden.''
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*''Takt-Signale sollen nicht in einem Logik-pfad den Daten-Eingang eines FlipFlops treiben.''
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*''Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.''
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*''Datensignale sollten nicht in einen Logik-Pfad benutzt werden, der den CLK-Eingang eines Registers treibt.''
*Schweregrad: Warning

=== Vermeide intern generierte Takte (SS11) ===
*''Vermeide intern generierte Taktsignale.''
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*''Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.''
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*''Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.''
*Schweregrad: Warning

=== Vermeide Register ohne Reset (SS14) ===
*''Alle Register sollten eine reset-Steuerleitung haben.''
*Schweregrad: Warning

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*''Resets sollten synchron freigegeben werden.''
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*''Verwende keine Register Initialisierung.''
*Schwerergrad: Error

=== Vermeide Logik ohne Treiber oder Nutzung (SS17) ===
*''a) Jedes Register oder Latch muss benutzt und getrieben werden.''
*''b) Register und latches die nur unebenutzte Logik treiben müssen untersucht werden.''
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*''Jedes Register soll über seine Eingänge steuerbar sein.''
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*''Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.''
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*''Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe gestattet.''
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*''Benutze die selbe Multi-Bit Vektor Indizierung ("downto" vers. "to") im gesamten Design einheitlich.''
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Staements (DR1) ===
*''Case-Konstrukte, Always und initial blocks sollen Labels haben.''
*Scheregrad: Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*''Namen sollen nicht allein durch Groß und Kleinschreibung unterscheidbar sein.''
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*''Der selbe Name soll nicht für verschiedenen Typen von Identifiers benutzt werden.''
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*''Eine Zeile pro Deklaration.''
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*''Eine Zeile pro Anweisung.''
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*''Code soll einheitlich eingerückt sein.''
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und Dateien sollen nicht nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File Header sicher.''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein.''
*Schweregrad: Warning

=== Stelle ordentliche Paltzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

[[Category:FPGA und Co]]
[[Kategorie:VHDL]]

Benutzer:Fpgakuechle

2015-04-07T20:08:53Z

Fpgakuechle: /* Erstellte Artikel */ +1

VHDL Code Style und DO-254

2015-04-07T19:50:09Z

Fpgakuechle: Formatierung,typos

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik.
Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===

*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen''
*Schweregrad: Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein Signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden''.
*Schweregrad: Error

IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else

===Vermeide numerischen Werte mitten im Code (CP3)===
*''Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden.''
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*''Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden''
*Schweregrad: Note

Statt
<syntaxhighlight lang="vhdl">
data <= "00000000";
</syntaxhighlight>
besser:
<syntaxhighlight lang="vhdl">
data <= (others => '0)";
</syntaxhighlight>

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*''a: In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.''
*''b: der FSM Zustand sollte hard codiert sein, aüßer unvermeidbar.''
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*''a: Ein Zustandsautomat sollte einen definierten Zustandsautomat haben.''
*''b: Alle ungenutzen (illegale oder undefinierte Zustände sollen) in einen definierten Zustand übergehen.''
*''c: Es sollen keine unerreichbaren und keine Sackgassen Zustände in einem Zustandsautomaten geben.''
*Schweregrad: Error

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*''Bit-breiten an beiden Seiten einer Zuweisung, Vergleich oder Assoziation sollten übereinstimmen.''
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig (CP8)===
*''Die sensetivity list sollte nur im process verwednete Signale enthalten.''
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
''Jedes Unterprogramm soll''
*''nur einen Entrittspunkt''
*''keine Rekursion''
*''nur Zugriff auf lokale Variablen/Signale haben''
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*''Jedem Objekt (Signal, Variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.''
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*''Jeder Eingang sollte von einem Anschluss, Signal oder Konstante getrieben werden.''
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
*''Design Ausgänge sollten verbunden sein''
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*''Objekte sollte vor der Benutzung deklariert werden''
*Schweregrad: Error

===Vermeide Ungenutzte Deklarationen (CP14)===
*''Alle deklarierten Objekte sollten benutzt werden.''
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*''Für jedes Design das mehrere zueinander asynchrone Takte hat ist eine umfassende Analyse der Taktübergänge durchzuführen.''

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordentliche Case-Anweisungen sicher (SS2)===
''Case statements sollen:''
*''a) Vollständig sein''
*''b) keine doppelten oder überlappenden Anweisungen enthalten''
*''c) keine nichterreichbare Anweisungen enthalten''
*''d) immer eine "when others" Regel enthalten''

*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*''In einem kombinatorischen Prozess ist kein Lesen und Zuweisen desselben Signals zulässig.''
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning
===Vermeide mehrfache Wellenformen (SS5) ===
*Nur eine Waveform soll auf der rechte Seite nur eine Wellenform haben.

write <= '1' after clk_prd, '0' after 8*clk_prd;
*Schweregrad: Error

===Vermeide mehrfache Signaltreiber (SS6) ===
*Schweregrad: Error
*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.
=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*Stelle sicher das alle VHDL Konstanten initialisiert werden.
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*Takt-Signale sollen nicht in einem Logik-pfad das den D-Eingang eines FF treiben.
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*Datensignale sollten nicht in einen logik-pfad benutzt werden das den CLK-Eingang eines Registers treibt.
*Schweregrad:Warning

=== Vermeide intern genrierte Takte (SS11) ===
*Vermeide intern generierte Taktsignale.
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.
*Schweregrad:Warning

=== Vermeide Register ohne Reset (SS14) ===
*Alle Register sollten eine reset-Steuerleitung haben.
*Schweregrad: Warning

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*Resets sollten synchron freigegeben werden.
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*Verwende keine register initialisierung.
*Schwerergrad: Error

=== Vermeide Logic ohne Treiber oder Nutzen (SS17) ===
*a) Jedes Register und latch muss benutzt und getrieben werden.
*b) Register und latches die nur unebenutzte Logik treiben müßen untersucht werden.
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*Jedes Register soll über seine Eingänge steuerbar sein.
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe zu gestatten.
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*Benutze die selbe multibit Vektor indizierung (downt/to) im gesamten design konsequent
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Staements (DR1) ===
*case- Konstrukte, Always und initial blocks sollen labels haben.
*Scheregrad:Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*Name sollen nicht allein an Groß und Kleinschreibung unterscheidbar
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*Der selbe Name soll nicht für verschiedenen typen von identifiers benutzt werden
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*Eine Zeile für eine Deklaration
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*eine Zeile für eine Anweisung
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*Code soll einheitlich eingerückt sein
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und datein sollen nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File header sicher''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein''
*Schweregrad: Warning

=== Stelle ordentliche Paltzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

VHDL Code Style und DO-254

2015-04-07T19:35:58Z

Fpgakuechle: Erstfassung

''von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-04-07, vollständig aber Codebeispiele fehlen und Einführung ist ein bisserl knapp

=Checkliste für FPGA (VHDL)-Designs (nach DO-254)=
Die DO-254 ist ein Standard zur Zertifizierung komplexer digitaler Schaltungen für Fluggerät - Avionik.
Die DO-254 usergroup hat in diesem Zusammenhang folgende Regel erarbeitet.

==VHDL Schreibstil - Coding Practice (CP)==
===Vermeide Fehler bei Typ_Deklarationen (CP1)===

*''Kontrolliere den Code auf inkorrekten Gebrauch von Typen, nichtpassende Begrenzungen oder Randbedingungen''
*Error

===Vermeide doppelte Signalzuweisungen (CP2)===
*''Ein signal soll innerhalb eines Statementsbereich nur einmal zugewiesen werden''.
*Schweregrad: Error
IF reset = 1 then
ausgang <= '1' ;
blablup <= blupbla;
ausgang <= '0';
else
===Vermeide numerischen Werte mitten im Code (CP3)===
*"Für Re-Use und einfacher Portierbarkeit sollten keine hart-codierte Zahlenwerte benutzt werden."
*Schweregrad: Warning

===Vermeide vectorlängenabhängige Zuweisungen (CP4)===
*Für Zuweisung während Reset keine hart-codierten Zahlenwerte verwenden
*Schweregrad: Note
Statt "data" <= "00000000"; besser "data <= (others => '0)";

===Stelle sicher das alle FSM einheitlichen codiert sind (CP5)===
*a:" In einem Design sollte ein einheitlichen Stil für alle Zustandsautomaten verwendet werden.
*b: der FSM Zustand sollte hard codiert sein, aüßer unvermeidbar.
*Schweregrad: Error

===Stelle sicher das die Zustandsübergänge sicher sind (CP6)===
*a: Ein Zustandsautomat sollte einen definierten Zustandsautomat haben.
*b: Alle ungenutzen (illegale oder undefinierte Zustände sollen) in einen definierten Zustand übergehen.
*c: Es sollen keine unerreichbaren und keine Sackgassen Zustände in einem Zustandsautomaten geben.
*Schweregrad: Error

===Vermeide unstimmige Intervallgrenzen (missmatching ranges) (CP7)===
*Bit breiten an beiden seiten eines Zuweisung, Vergleich oder assoziation sollten übereinstimmen.
*Schweregrad: Warning

===Stelle sicher das die Sensitivity list vollständig (CP8)===
*Die sensetivity list sollte nur im process verwednete Signale enthalten.
*Schweregrad: Warning

===Stelle sicher das Unterprogramme ordentlich sind (CP9)===
Jedes Unterprogramm soll
*nur einen Entrittspunkt
*keine Rekursion
*nur Zugriff auf lokale variablen/Signale haben
*Schweregrad: Warning

===Weise Werte vor Nutzung zu (CP10)===
*Jedem Objekt (signal, variable, Anschluß) sollte eine Wert zugewiesen werden bevor es benutzt wird.
*Schweregrad: Warning

===Vermeide offene Eingänge (CP11)===
*Jeder Eingang sollte von einem Anschluß, sognal oder constant getrieben werden.
*Schweregrad: Error

===Vermeide offene Ausgänge (CP12)===
"Design Ausgänge sollten verbunden sein"
*Schweregrad: Note

===Deklariere Objekte vor Nutzung (CP13)===
*Schweregrad: Error
"Objekte sollte vor der Benutzung deklariert werden"

===Vermeide Ungenutzte Deklarationen (CP14)===
*alle deklarierten Objekte sollten benutzt werden.
*Schweregrad: Warning

==Taktübergange - Clock Domain Crossing (CDC)==
===Analysiere Mehrfache asynchrone Takte (CDC-1)===
*Jedes Design das mehrere zueinander asynchrone Takte eine umfassende Analyse der taktübergänge sollte durchgeführt halten.

==Sichere Synthese - Safe Synthesis (SS)==
===Vermeide implizierte Logik (SS1)===
*Erlaube keinen Code der feed-throughs, Schieberegister und interne Tristate-Treiber impliziert.

===Stelle ordebtlich Case-Anweisungen sicher (SS2)===
Case statements sollen:
*a) Vollständig sein
*b) keine doppelten oder überlappenden Anweisungen enthalten
*c) keine nichterreichbare Anweisungen enthalten
*d) immer eine "when others" Regel enthalten

*Schweregrad: Error

===Vermeide Kombinatorische Rückkoppelungen (SS3)===
*In einem kombinatorischen prozess ist kein lesen und Zuweisen desselben Signals zulässig.
*Schweregrad: Error

===Vermeide automatische Einführung von latches (SS4) ===
*Der Codierstil sollte den automatischen Einbau von Latches verhindern.
*Schweregrad: Warning
===Vermeide mehrfache Wellenformen (SS5) ===
*Nur eine Waveform soll auf der rechte Seite nur eine Wellenform haben.

write <= '1' after clk_prd, '0' after 8*clk_prd;
*Schweregrad: Error

===Vermeide mehrfache Signaltreiber (SS6) ===
*Schweregrad: Error
*Ein Signal/Variable soll nur in einem einzigen sequentiellen Block zugewiesen werden.
=== Vermeide uninitialisierte VHDL Konstante (SS7) ===
*Stelle sicher das alle VHDL Konstanten initialisiert werden.
*Schweregrad: Warning

=== Vermeide die Nutzung des Taktes als Data (SS8)===
*Takt-Signale sollen nicht in einem Logik-pfad das den D-Eingang eines FF treiben.
*Schweregrad: Fehler

=== Vermeide gemeinsame genutzte Takt und Resetsignal (SS9) ===
*Ein Signal sollte nicht sowohl als Takt und auch als Resetsignal benutzt werden.
*Schweregrad: Error

=== Vermeide geschaltetet Takte (SS10) ===
*Datensignale sollten nicht in einen logik-pfad benutzt werden das den CLK-Eingang eines Registers treibt.
*Schweregrad:Warning

=== Vermeide intern genrierte Takte (SS11) ===
*Vermeide intern generierte Taktsignale.
*Schweregrad: Warning

=== Vermeide intern generierte Reset (SS12) ===
*Vermeide intern generierte Reset, außer sie sind ordentlich isoliert.
*Schweregrad: Warning

=== Vermeide Resets unterschiedlicher Polarität (SS13) ===
*Ein und dasselbe Resetsignal sollte nicht mit unterschiedlicher Polarität oder Stil benutzt werden.
*Schweregrad:Warning

=== Vermeide Register ohne Reset (SS14) ===
*Alle Register sollten eine reset-Steuerleitung haben.
*Schweregrad: Warning

=== Vermeide asynchrone deaktivierten Reset (SS15) ===
*Resets sollten synchron freigegeben werden.
*Schweregrad:Fehler

=== Vermeide Zuweisung bei der Initialisierung (SS16) ===
*Verwende keine register initialisierung.
*Schwerergrad: Error

=== Vermeide Logic ohne Treiber oder Nutzen (SS17) ===
*a) Jedes Register und latch muss benutzt und getrieben werden.
*b) Register und latches die nur unebenutzte Logik treiben müßen untersucht werden.
Schweregrad:Error

=== Stelle sicher das Register steuerbar bleiben (SS18) ===
*Jedes Register soll über seine Eingänge steuerbar sein.
*Schweregrad: Warning

=== Vermeide Schlangengleiche Verdrahtungen (SS19) ===
*Kombinatorische Pfade sollen nicht tiefer als eine vorgegebenes maximale Logiktiefe sein.
*Schweregrad: Warning

=== Stelle Grenze für Verschachtelungen sicher (SS20) ===
*Bedingte Verzweigungen sind nur bis zu einer maximalen Verschachtelungstiefe zu gestatten.
*Schweregrad: Warning

=== Stelle stets gleiche Richtung der Vektorindizierung sicher (SS21) ===
*Benutze die selbe multibit Vektor indizierung (downt/to) im gesamten design konsequent
*Schweregrad: Warning

== Code-Durchsichten - Design Reviews (DR)==
=== Verwende Labels für Staements (DR1) ===
*case- Konstrukte, Always und initial blocks sollen labels haben.
*Scheregrad:Note

=== Vermeide gemischte Groß-/Kleinschreibung zur Unterscheidung (DR2)===
*Name sollen nicht allein an Groß und Kleinschreibung unterscheidbar
*Schweregrad: Warning

=== Stelle eindeutige Namensräume sicher (DR3)===
*Der selbe Name soll nicht für verschiedenen typen von identifiers benutzt werden
*Schweregrad: Error

=== Nutze "Trennenden Deklarations Stil" (DR4)===
*Eine Zeile für eine Deklaration
*Schweregrad: Note

=== Nutze "Trennenden Statement Stil" (DR5)===
*eine Zeile für eine Anweisung
*Schweregrad:Note

=== Stelle einheitlichen Einrückungen sicher (DR6)===
*Code soll einheitlich eingerückt sein
*Schweregrad: Note

=== Vermeide Tabulatoren (DR7) ===
*''Tabulatoren sollen nicht benutzt werden.''
*Schweregrad: Note

=== Vermeide lange Files (DR8)===
*''Das Design soll in Unterdesigns gegliedert sein und datein sollen nach Belieben lang sein.''
*Schweregrad: Warning

=== Stelle über Hierarchien einheitliche Signalnamen sicher (DR9)===
*''Signale und Busse sollen über das gesamte Design einheitliche Namen haben.''
*Schweregrad: Warning

=== Stelle einheitlichen Datei-Header sicher (DR10) ===
*''Stelle einheitliche File header sicher''
*Schweregrad: Warning

=== Stelle ausreichende Kommentardichte sicher (DR11) ===
*''Code soll durch inline Kommantare ausreichend dokumentiert sein''
*Schweregrad: Warning

=== Stelle ordentliche Paltzierung von Kommentaren sicher (DR12) ===
*''Kommentare sollten so platziert sein das sie das Verständniss unterstützen.''
*Schweregrad: Note

=== Stelle Firmenspezifische Namensstandard sicher (DR13) ===
*''Jede Firma oder project soll ihre eigenen Codestandards definieren und durchsetzen.''
*Schweregrad: Note

=Literatur=
*[DOUG] DO-254 User Group Position Paper DO254-UG-001 „Best PracticeVHDL Coding Standards for DO-254 Programs, modified 2010-Sep-13
*[Fulton] Randall Fulton, Ray Vandermolen „Airborne Electronic Hardware Design Assurance - A practitioners Guide to RTCA/DO-254“, CRC Press 2015
*[Synopsys] Synopsys Inc. White paper „Understanding DO-254 Compliance for the verification of Airborne Digital Hardware“

Xilinx Microblaze MCS Workflow

2015-03-12T22:01:47Z

Fpgakuechle: /* Erstellung Board support package */ Kurz und knackig

''Gestartet von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-Feb-27 -> Material,Tips zur Fehlersuch und Screenshots sammeln

Der Artikel beschreibt wie der 32bit Softcore "microblaze MCS" in FPGA verwendet wird.
Verwendet wird dabei die kostenfrei verfügbare "leichtgewichtige" MicroBlaze-mcs (µB-MCS) Variante aus dem coregenerator (ab ISE 13.4 (ab 01/2013) und Vivado) und nicht die kostenpflichtige MicroBlaze (ohne -MCS) Variante.

=MicroBlaze und MicroBlaze MCS=

=Ablauf=
Die Implementierung eines FPGA-Systems mit Softcore verläuft in folgenden Phasen:
*Erstellung des FPGA-drumherum (Top-level design, pinassigments) und FPGA ohne microblaze-Core implementieren
*Generierung des Softcore im CoreGenerator
*Instanziierung Core, Script für bm referenz ausführen und FPGA mit microblaze-Core implementieren
*Erstellung der compilerumgebung (board support package, libraries, linkerscript)
*Erstellung und Kompilierung des Programms
*Zusammenfügen programm-binarie mit FPGA-bitstream file

=Benötigte Software=
Es wird von Xilinx die FPGA Implementierungssoftware und das Software Development Kit (SDK)benötigt. Nutzer der FPGA's vor der 7Serie (bspw Spartan3-Großfamilie, Spartan-6, Virtex5/6) muüßen installieren:
*ISE Design Suite: WebPack edition
*ISE Design Suite: Embedded edition
(Siehe http://www.xilinx.com/products/design-tools/ise-design-suite.html )

Nutzer der neueren 7er Reihe dagegen benötigen:
*Vivado Design Suite Webpack edition
(Siehe http://www.xilinx.com/products/design-tools/vivado.html)

=Beispiel=
Es wird ein einfacher Core mit 3 Ausgangsport a 8,4 und 6 bit, einem Eingangsport zu 8bit sowie einem Festwert- (FIT) und ein programmierbarer Zähler (PIT) generiert.
[[Datei:Mcs block.png|thumb|center|400px|Blockdiagramm Beispiel]]

Neben dem Core ist ein weitere Zähler -''heartbeat''- im Design. Die drei Ausgangsporst sind für das verwendete S3AN Starterkit verbunden mit dem Datenbus und den Steuerleitung des alphanumerischen Displays und den 6 LED rechts. Die LED Nr 8 wird von dem FPGA-Logiccounter zum blinken gebracht, LED nummero 7 vom toggle-signal des Festwertcounter. Damit lassen sich 3 Implementierungsziele detektieren.
*Nix blinkt -> Totalversagen
*LED Nr. 8 blinkt -> FPGA erfolgreich geladen und gestartet
*LED 8 und 7 blinken: -> microblaze ist erfolgreich im FPGA implementiert, aber das Programm läuft nicht.
*Aktivität auf allen 8 LED's -> Perfekt

=FPGA-Implementierung und SoftCore-Generierung=
==FPGA-Gerüst==
Es ist Empfehlenswert zuerst ein "Basis-FPGA" ohne µB fertigzustellen und zu testen. Hier wurde das zum Starterkit gehörige Demo adaptiert und somit war schon mal die Pinzuordnung und das Taktsystem fehlerfrei. Eine heartbeat-LED die im Sekundentakt blinkt grenzt den Fehler deutlich ein.

==CoreGen==
CoreGen starten (beispw. Programme -> Xilinx -> ISE 14.7 -> ISE Design tools -> 64bit tools -> coregen). Project für den benutzen FPGA aufsetzen (hier im Beispiel S3AN-700; package: FGG484; speedgrade 4; Verilog)

Im IP Catalog findet sich der MCE unter embedded Processing -> processors -> microblaze MCE :
[[Datei:Ss coregen main.png|thumb|center|400px|CoreGen Auswahl microblaze MCS Core]]

Im Unterschied zum Screenshot sollte man den Speicher auf mindestens 8 kByte setzen. Die Angabe der Taktfrequenz ist nur für die Berechnung des Baudraten-Teilers für die UART wichtig. Benutzt man die UART nicht, ist dieser Wert (theoretisch?) für den Core bedeutungslos. Das Place&Route für den FPGA richtet sich nach der Taktvorgabe aus dem ucf-file.
Die in den Karteikarten gezeigten Kürzel stehen für die einzigen "Peripherie-controllern" die für dem µB-MCS generiert
werden können. Mit dem weiterhin kostenpflichten Platform Studio sind weitere Cores einfach hinzufügbar. Aber beim MCS muß man nicht komplett darauf verzichten da an dem IO-Bus selbtgeschriebene Komponenten angeschlossen werden können.

*UART: feste Baudrate, Interrupt für RX
*FIT: Fixed length timer -4 möglich
*PIT: programmable Timer - 4 möglich
*GPO: Generalpurpose Output-Port - 4 Ports mit jeweils 1-32 bit Breite Konfigurierbar
*GPI: Generalpurpose Input-Port - 4 Ports mit jeweils 1-32 bit Breite Konfigurierbar
*INT: External Interrupt Sources

Für die Treiber kann auch ein toggle output signal generiert werden das immer beim Erreichen der '0' invertiert wird.

[[Datei:Ss coregen generalsettings.png|thumb|center|400px|CoreGen Settings für microblaze MCS Teil 1]]
[[Datei:Ss coregen fitsettings.png|thumb|center|400px|CoreGen Settings für Fixed Timer]]
[[Datei:Ss coregen generated files.png|thumb|center|400px|Liste Generierter Dateien]]
Mit
[[Datei:Ss coregen info sdk.png|thumb|center|400px|Coregen Hinweis nächste Schritte]]
[[Datei:Ss coregen info tcl.png|thumb|center|400px|Coregen Hinweis Tcl-script]]
[[Datei:Ss tcl console.png|thumb|center|400px|Tcl-Console]]

==Vorbereitung Synthese mit MCS core==

==Top-Level==
<syntaxhighlight lang="verilog">
wire heartbeat_s;

wire [7:0] GPO1_s; //display data
wire [3:0] GPO2_s; //display control
wire [6:0] GPO3_s; // led's
wire [7:0] GPI1_s; //switches

wire FIT1_Toggle_s;

MikroBlaze_mcs microblaze_s3an_disp (
.Clk(clk), // input Clk
.Reset(rst), // input Reset
.FIT1_Toggle(FIT1_Toggle_s), // output fixed timer toggler (every 25M ticks)
.FIT2_Interrupt(/*FIT2_Interrupt*/), // UNUSED - output FIT2_Interrupt
.FIT2_Toggle(/*FIT2_Toggle*/), // UNUSED - output FIT2_Toggle
.PIT1_Interrupt(/*PIT1_Interrupt*/), // UNUSED - output PIT1_Interrupt
.PIT1_Toggle(/*PIT1_Toggle*/), // UNUSED - output PIT1_Toggle
.GPO1(GPO1_s), // output [7 : 0] GPO1
.GPO2(GPO2_s), // output [3 : 0] GPO2
.GPO3(GPO3_s), // output [6 : 0] GPO3
.GPI1(GPI1_s), // input [7 : 0] GPI1
.GPI1_Interrupt(/*GPI1_Interrupt*/), // UNUSED - output GPI1_Interrupt
.INTC_IRQ(/*INTC_IRQ*/) // UNUSED - output INTC_IRQ
);

always @(posedge clk)
begin

assign LCD_DB = GPO1_s[7:0];
assign LCD_RW = GPO2_s[0];
assign LCD_RS = GPO2_s[1];
assign LCD_E = GPO2_s[2];
end

heartbeat heartbeat(
.clk(clk),
.rst(rst),
.heartbeat_o(heartbeat_s)
);

assign LED[7] = heartbeat_s;
assign LED[6] = FIT1_Toggle_s;
assign LED[5:0] = GPO3_s[5:0];
</syntaxhighlight>

==FPGA Implementierung ==
Am besten den FPGA mit den µB-MCS '''vor''' der Vorbereitung des SDK komplett implementieren und auf das Board laden. Es müßen die LED's 7 und 8 mit jeweils eigene Frequenz blinken. Wenn nicht, dann ist bei der Generierung und Instanziierung des Cores ein Fehler unterlaufen.

Jetzt, falls noch nicht geöffnet, ein Tcl Fenster öffnen (''ISE:View->Panels->Tcl Console'') dann erscheint unten eine schmale Zeile in der Tcl Kommandos eingegeben werden können, die Ausgabe erscheint in dem Fenster darüber.

Jetzt das vom ''coregen'' erzeugte tcl Script starten: ''source ../core/microblaze_mcs_setup.tcl'' . Dieses script fügt eine Option für das tool ''ngdbuild'' (Process "''Translate''") bei der Implementierung
hinzu. Zur Überprüfung die Optionen anzeigen lassen mit Mausklick rechts auf "''Translate''" im Process-Fenster und "process properties" auswählen. Es findet sich jetzt in der Zeile "Other ... options" ein Eintrag beginnend mit "-bm" der auf eine ebenfalls von coregen erzeugtes *.bmm Datei zeigt.

[[Datei:Ss after setup tcl.png|thumb|center|400px|Tcl-Console]]

Diese Datei am besten in einem Texteditor öffnen. wichtig ist hier der Pfad zu den RAM-Blöcken die das binary für den Softcore speichern werden.
Der Teil ganz links ist der in ersten ''CoreGen''-Fenster angegebene Instanz-name. Der muss auch mit dem Instanznamen im Top-file übereinstimmen, sonst
bricht Translate ab. Entfernt man die grad erwähnte -bm Option wieder aus den "Process Properties" läuft zwar der Schritt Translate und alle Folgenden
durch, aber es wird Probleme bei "Vereinigung von Programm-binarie und FPGA bitfile" geben -> die FPGA logic wird zwar funktionieren, aber es wird kein Programm
auf dem Softcore laufen.

=Generierung Compilerumgebung und microblaze-programm=
Für die folgenden Schritte ist das Software development Kit (SDK) zu starten,
das findet sich im Ordner EDK (Embedded Development Kit):

[[Datei:Ss programmmenu sdk.png|thumb|center|400px|Startmenu mit Xilinx-tools]]

Das SDK fragt beim Start nach einem Verzeichniss für den workspace.

Dannach erscheint beim ersten Start ein Welcome-Screen. Diesen an besten wegklicken da er
das fenster "project explorer" überdeckt. Jetzt müßen wir nacheinander 3 verschieden "typen" von "projekten" anlegen:
*Hardware Platform spezification - eine beschreibung des systems aus microblaze, Programmspeicher und Peripherie.
Diese benötigt die Infos aus dem Coregenlauf
*board support package - Header-dateien, linkerskripte mit kosntanten/ addressbereichen etc. passend zum mikrocontrollersystem
*C/C++projekt die leere C-datei für das eigentliche Programm

[[Datei:Sdk project wizards.png|thumb|center|400px|New -> Projects]]

==Hardware Platform Specification==
File -> new -> project -> Xilinx -> Hardware Platform Specification

Der Projectname erscheint dann im project explorer. Der Autor wählte zur besseren Unterscheidbarkeit
zu den anderen Projekttypen den suffix _hwp. in der Spalte hardwareproject-file ist das file aus den Coregen-lauf
anzugeben, es findet sich daher in dem Verzeichniss Core.

==Erstellung Hardware project==
[[Datei:Ss hardware palltform settings.png|400px|thumb|center]]
==Erstellung Board support package==
Nachdem die Infodateien für die Hardware des µB-MCE System generiert worden, werden nun dazu passende Header Dateien und Bibliotheken
generiert. Die erstellten Dateien werden auch als "Board support package" bezeichnet. Dazu wird das Menü File -> New -> "Board Support package" audgewählt, dem Namen des support packages sollte man eine Endung wie _BSP anhängen. Im Feld "Target Hardware" trägt man die gerade erstellte Plattform ein, als Betriebssystem "OS" ist standalone eingetragen.
[[Datei:Ss sdk file new board support package.png|thumb|400px|center|Aufsetzen board support package]]

==Erstellung Programm==
[[Datei:Ss sdk cproject settings.png|400px|thumb|center]]
<syntaxhighlight lang="C">
#include <xparameters.h>
#include <xiomodule.h>
#include <stdbool.h>

#define LED_DELAY 100000

int main()
{
//instantiate IOs
XIOModule GPIO;

volatile u32 i = 0;

//initialize IOs
XIOModule_Initialize(&GPIO, XPAR_IOMODULE_0_DEVICE_ID);
XIOModule_Start(&GPIO);

//LED
bool led_on = false;
int run = 1;

for (;;)
{
if (led_on) {XIOModule_DiscreteWrite(&GPIO, 3,run);
if (run == 0x20) run = 1; else run *= 2;}
led_on = !led_on;
for(i=0;i < LED_DELAY; ++i);
}
}
</syntaxhighlight>

==Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei==
Im Menu "Xilinx Tools" den Punkt "Programm FPGA" auswählen und
[[Datei:Program FPGA.png|thumb|400px|center|Menu SDK program FPGA]]

anschließend das (beim CoreGen) angelegte *.bmm file, das compilierte Programm (*.elf) und das *.bit File des in der ISE generierten FPGA's auswählen und den Button "Program" drücken.
[[Datei:Program FPGA files.png|thumb|400px|center|Auswahl *.bmm *.bit *.elf for programming]]

Jetzt wird mittels der Information über die genutztem BRAM-Blöcke aus der *.bmm-Datei im *.bit-File die Bereiche die die Initdaten für die BRAM-Speicherblöcke enthält mit dem Binary des Programms ausgetauscht und anschließend das FPGA programmiert.

=Fehlersuche=
Wenn möglich auch die beiden Zwischenergebnisse ("Gesamtdesign ohne MCS-Core instanziierung" und "Mit Core aber ohne Programm" am Board testen. Nur so lassen sich Fehler auf die Schritte im workflow zurückführen.

Bei Änderungen am Core versagt gelegentlich das automatische Update von BPS etc.. Deshalb bei Coreänderungen die obsoleten Projekte (Hardware project, BSP und C-projekt) löschen und den workflow ab Schritt "tcl.script" wiederholen.

Fehlermeldungen in die Eingabemaske von google kopieren und nach Antworten bei Xilinx oder Internetforen suchen. Das führt bei den
oft verwirrenden Fehlermeldungen schnell zum Erfolg. So weist diese Meldung über Memory leaks:
[[Datei:Ss more ngdbuilt error.png|400px|thumb|center|ngdbuil error]]
eigentlich darauf hin, das der Instanzname des MCS-cores nicht stimmt. Der "Answer record" bei Xilinx http://www.xilinx.com/support/answers/51538.html erklärt wie man den korrekten Namen findet und in das BMM-file einträgt.

= Literatur =
* http://ece.wpi.edu/~rjduck/Microblaze%20MCS%20Tutorial%20v5.pdf - Eine in Englisch verfasste Anleitung zum Durchklicken.
Als Beispiel wird eine microblaze basierte UART-Verbindung zwischen PC und Nexsys2/3 board implementiert, verwendet wird die ISE 14.5.
* http://jimselectronicsblog.blogspot.de/2014/03/implementing-microblaze-mcs-on-papilio.html
Eine Englischsprachige Klickanleitung für das papilio-One board. Hier wird auch gezeigt wie UCF und top entity
mit dem PlanAHead tool angelegt wird. Die Screenshost sind recht gut kommentiert.
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/ds865_microblaze_mcs.pdf - XILINX DS865, die offizielle Beschreibung des Cores
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/pg116-microblaze-mcs.pdf - XILINX PG116, die offizielle Anleitung für Vivado
*http://www.xilinx.com/support/documentation/sw_manuals_j/xilinx14_5/pg048-microblaze-mcs.pdf - Xilinx PG048, die offizielle Anleitung für Vivado

Datei:Ss sdk file new board support package.png

2015-03-12T21:45:43Z

Fpgakuechle: Screenshoot Xilinx SDK - board support package Lizenz: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Screenshoot Xilinx SDK - board support package Lizenz: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Xilinx Microblaze MCS Workflow

2015-03-12T21:27:50Z

Fpgakuechle: /* CoreGen */ Typos

''Gestartet von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-Feb-27 -> Material,Tips zur Fehlersuch und Screenshots sammeln

Der Artikel beschreibt wie der 32bit Softcore "microblaze MCS" in FPGA verwendet wird.
Verwendet wird dabei die kostenfrei verfügbare "leichtgewichtige" MicroBlaze-mcs (µB-MCS) Variante aus dem coregenerator (ab ISE 13.4 (ab 01/2013) und Vivado) und nicht die kostenpflichtige MicroBlaze (ohne -MCS) Variante.

=MicroBlaze und MicroBlaze MCS=

=Ablauf=
Die Implementierung eines FPGA-Systems mit Softcore verläuft in folgenden Phasen:
*Erstellung des FPGA-drumherum (Top-level design, pinassigments) und FPGA ohne microblaze-Core implementieren
*Generierung des Softcore im CoreGenerator
*Instanziierung Core, Script für bm referenz ausführen und FPGA mit microblaze-Core implementieren
*Erstellung der compilerumgebung (board support package, libraries, linkerscript)
*Erstellung und Kompilierung des Programms
*Zusammenfügen programm-binarie mit FPGA-bitstream file

=Benötigte Software=
Es wird von Xilinx die FPGA Implementierungssoftware und das Software Development Kit (SDK)benötigt. Nutzer der FPGA's vor der 7Serie (bspw Spartan3-Großfamilie, Spartan-6, Virtex5/6) muüßen installieren:
*ISE Design Suite: WebPack edition
*ISE Design Suite: Embedded edition
(Siehe http://www.xilinx.com/products/design-tools/ise-design-suite.html )

Nutzer der neueren 7er Reihe dagegen benötigen:
*Vivado Design Suite Webpack edition
(Siehe http://www.xilinx.com/products/design-tools/vivado.html)

=Beispiel=
Es wird ein einfacher Core mit 3 Ausgangsport a 8,4 und 6 bit, einem Eingangsport zu 8bit sowie einem Festwert- (FIT) und ein programmierbarer Zähler (PIT) generiert.
[[Datei:Mcs block.png|thumb|center|400px|Blockdiagramm Beispiel]]

Neben dem Core ist ein weitere Zähler -''heartbeat''- im Design. Die drei Ausgangsporst sind für das verwendete S3AN Starterkit verbunden mit dem Datenbus und den Steuerleitung des alphanumerischen Displays und den 6 LED rechts. Die LED Nr 8 wird von dem FPGA-Logiccounter zum blinken gebracht, LED nummero 7 vom toggle-signal des Festwertcounter. Damit lassen sich 3 Implementierungsziele detektieren.
*Nix blinkt -> Totalversagen
*LED Nr. 8 blinkt -> FPGA erfolgreich geladen und gestartet
*LED 8 und 7 blinken: -> microblaze ist erfolgreich im FPGA implementiert, aber das Programm läuft nicht.
*Aktivität auf allen 8 LED's -> Perfekt

=FPGA-Implementierung und SoftCore-Generierung=
==FPGA-Gerüst==
Es ist Empfehlenswert zuerst ein "Basis-FPGA" ohne µB fertigzustellen und zu testen. Hier wurde das zum Starterkit gehörige Demo adaptiert und somit war schon mal die Pinzuordnung und das Taktsystem fehlerfrei. Eine heartbeat-LED die im Sekundentakt blinkt grenzt den Fehler deutlich ein.

==CoreGen==
CoreGen starten (beispw. Programme -> Xilinx -> ISE 14.7 -> ISE Design tools -> 64bit tools -> coregen). Project für den benutzen FPGA aufsetzen (hier im Beispiel S3AN-700; package: FGG484; speedgrade 4; Verilog)

Im IP Catalog findet sich der MCE unter embedded Processing -> processors -> microblaze MCE :
[[Datei:Ss coregen main.png|thumb|center|400px|CoreGen Auswahl microblaze MCS Core]]

Im Unterschied zum Screenshot sollte man den Speicher auf mindestens 8 kByte setzen. Die Angabe der Taktfrequenz ist nur für die Berechnung des Baudraten-Teilers für die UART wichtig. Benutzt man die UART nicht, ist dieser Wert (theoretisch?) für den Core bedeutungslos. Das Place&Route für den FPGA richtet sich nach der Taktvorgabe aus dem ucf-file.
Die in den Karteikarten gezeigten Kürzel stehen für die einzigen "Peripherie-controllern" die für dem µB-MCS generiert
werden können. Mit dem weiterhin kostenpflichten Platform Studio sind weitere Cores einfach hinzufügbar. Aber beim MCS muß man nicht komplett darauf verzichten da an dem IO-Bus selbtgeschriebene Komponenten angeschlossen werden können.

*UART: feste Baudrate, Interrupt für RX
*FIT: Fixed length timer -4 möglich
*PIT: programmable Timer - 4 möglich
*GPO: Generalpurpose Output-Port - 4 Ports mit jeweils 1-32 bit Breite Konfigurierbar
*GPI: Generalpurpose Input-Port - 4 Ports mit jeweils 1-32 bit Breite Konfigurierbar
*INT: External Interrupt Sources

Für die Treiber kann auch ein toggle output signal generiert werden das immer beim Erreichen der '0' invertiert wird.

[[Datei:Ss coregen generalsettings.png|thumb|center|400px|CoreGen Settings für microblaze MCS Teil 1]]
[[Datei:Ss coregen fitsettings.png|thumb|center|400px|CoreGen Settings für Fixed Timer]]
[[Datei:Ss coregen generated files.png|thumb|center|400px|Liste Generierter Dateien]]
Mit
[[Datei:Ss coregen info sdk.png|thumb|center|400px|Coregen Hinweis nächste Schritte]]
[[Datei:Ss coregen info tcl.png|thumb|center|400px|Coregen Hinweis Tcl-script]]
[[Datei:Ss tcl console.png|thumb|center|400px|Tcl-Console]]

==Vorbereitung Synthese mit MCS core==

==Top-Level==
<syntaxhighlight lang="verilog">
wire heartbeat_s;

wire [7:0] GPO1_s; //display data
wire [3:0] GPO2_s; //display control
wire [6:0] GPO3_s; // led's
wire [7:0] GPI1_s; //switches

wire FIT1_Toggle_s;

MikroBlaze_mcs microblaze_s3an_disp (
.Clk(clk), // input Clk
.Reset(rst), // input Reset
.FIT1_Toggle(FIT1_Toggle_s), // output fixed timer toggler (every 25M ticks)
.FIT2_Interrupt(/*FIT2_Interrupt*/), // UNUSED - output FIT2_Interrupt
.FIT2_Toggle(/*FIT2_Toggle*/), // UNUSED - output FIT2_Toggle
.PIT1_Interrupt(/*PIT1_Interrupt*/), // UNUSED - output PIT1_Interrupt
.PIT1_Toggle(/*PIT1_Toggle*/), // UNUSED - output PIT1_Toggle
.GPO1(GPO1_s), // output [7 : 0] GPO1
.GPO2(GPO2_s), // output [3 : 0] GPO2
.GPO3(GPO3_s), // output [6 : 0] GPO3
.GPI1(GPI1_s), // input [7 : 0] GPI1
.GPI1_Interrupt(/*GPI1_Interrupt*/), // UNUSED - output GPI1_Interrupt
.INTC_IRQ(/*INTC_IRQ*/) // UNUSED - output INTC_IRQ
);

always @(posedge clk)
begin

assign LCD_DB = GPO1_s[7:0];
assign LCD_RW = GPO2_s[0];
assign LCD_RS = GPO2_s[1];
assign LCD_E = GPO2_s[2];
end

heartbeat heartbeat(
.clk(clk),
.rst(rst),
.heartbeat_o(heartbeat_s)
);

assign LED[7] = heartbeat_s;
assign LED[6] = FIT1_Toggle_s;
assign LED[5:0] = GPO3_s[5:0];
</syntaxhighlight>

==FPGA Implementierung ==
Am besten den FPGA mit den µB-MCS '''vor''' der Vorbereitung des SDK komplett implementieren und auf das Board laden. Es müßen die LED's 7 und 8 mit jeweils eigene Frequenz blinken. Wenn nicht, dann ist bei der Generierung und Instanziierung des Cores ein Fehler unterlaufen.

Jetzt, falls noch nicht geöffnet, ein Tcl Fenster öffnen (''ISE:View->Panels->Tcl Console'') dann erscheint unten eine schmale Zeile in der Tcl Kommandos eingegeben werden können, die Ausgabe erscheint in dem Fenster darüber.

Jetzt das vom ''coregen'' erzeugte tcl Script starten: ''source ../core/microblaze_mcs_setup.tcl'' . Dieses script fügt eine Option für das tool ''ngdbuild'' (Process "''Translate''") bei der Implementierung
hinzu. Zur Überprüfung die Optionen anzeigen lassen mit Mausklick rechts auf "''Translate''" im Process-Fenster und "process properties" auswählen. Es findet sich jetzt in der Zeile "Other ... options" ein Eintrag beginnend mit "-bm" der auf eine ebenfalls von coregen erzeugtes *.bmm Datei zeigt.

[[Datei:Ss after setup tcl.png|thumb|center|400px|Tcl-Console]]

Diese Datei am besten in einem Texteditor öffnen. wichtig ist hier der Pfad zu den RAM-Blöcken die das binary für den Softcore speichern werden.
Der Teil ganz links ist der in ersten ''CoreGen''-Fenster angegebene Instanz-name. Der muss auch mit dem Instanznamen im Top-file übereinstimmen, sonst
bricht Translate ab. Entfernt man die grad erwähnte -bm Option wieder aus den "Process Properties" läuft zwar der Schritt Translate und alle Folgenden
durch, aber es wird Probleme bei "Vereinigung von Programm-binarie und FPGA bitfile" geben -> die FPGA logic wird zwar funktionieren, aber es wird kein Programm
auf dem Softcore laufen.

=Generierung Compilerumgebung und microblaze-programm=
Für die folgenden Schritte ist das Software development Kit (SDK) zu starten,
das findet sich im Ordner EDK (Embedded Development Kit):

[[Datei:Ss programmmenu sdk.png|thumb|center|400px|Startmenu mit Xilinx-tools]]

Das SDK fragt beim Start nach einem Verzeichniss für den workspace.

Dannach erscheint beim ersten Start ein Welcome-Screen. Diesen an besten wegklicken da er
das fenster "project explorer" überdeckt. Jetzt müßen wir nacheinander 3 verschieden "typen" von "projekten" anlegen:
*Hardware Platform spezification - eine beschreibung des systems aus microblaze, Programmspeicher und Peripherie.
Diese benötigt die Infos aus dem Coregenlauf
*board support package - Header-dateien, linkerskripte mit kosntanten/ addressbereichen etc. passend zum mikrocontrollersystem
*C/C++projekt die leere C-datei für das eigentliche Programm

[[Datei:Sdk project wizards.png|thumb|center|400px|New -> Projects]]

==Hardware Platform Specification==
File -> new -> project -> Xilinx -> Hardware Platform Specification

Der Projectname erscheint dann im project explorer. Der Autor wählte zur besseren Unterscheidbarkeit
zu den anderen Projekttypen den suffix _hwp. in der Spalte hardwareproject-file ist das file aus den Coregen-lauf
anzugeben, es findet sich daher in dem Verzeichniss Core.

==Erstellung Hardware project==
[[Datei:Ss hardware palltform settings.png|400px|thumb|center]]
==Erstellung Board support package==
==Erstellung Programm==
[[Datei:Ss sdk cproject settings.png|400px|thumb|center]]
<syntaxhighlight lang="C">
#include <xparameters.h>
#include <xiomodule.h>
#include <stdbool.h>

#define LED_DELAY 100000

int main()
{
//instantiate IOs
XIOModule GPIO;

volatile u32 i = 0;

//initialize IOs
XIOModule_Initialize(&GPIO, XPAR_IOMODULE_0_DEVICE_ID);
XIOModule_Start(&GPIO);

//LED
bool led_on = false;
int run = 1;

for (;;)
{
if (led_on) {XIOModule_DiscreteWrite(&GPIO, 3,run);
if (run == 0x20) run = 1; else run *= 2;}
led_on = !led_on;
for(i=0;i < LED_DELAY; ++i);
}
}
</syntaxhighlight>

==Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei==
Im Menu "Xilinx Tools" den Punkt "Programm FPGA" auswählen und
[[Datei:Program FPGA.png|thumb|400px|center|Menu SDK program FPGA]]

anschließend das (beim CoreGen) angelegte *.bmm file, das compilierte Programm (*.elf) und das *.bit File des in der ISE generierten FPGA's auswählen und den Button "Program" drücken.
[[Datei:Program FPGA files.png|thumb|400px|center|Auswahl *.bmm *.bit *.elf for programming]]

Jetzt wird mittels der Information über die genutztem BRAM-Blöcke aus der *.bmm-Datei im *.bit-File die Bereiche die die Initdaten für die BRAM-Speicherblöcke enthält mit dem Binary des Programms ausgetauscht und anschließend das FPGA programmiert.

=Fehlersuche=
Wenn möglich auch die beiden Zwischenergebnisse ("Gesamtdesign ohne MCS-Core instanziierung" und "Mit Core aber ohne Programm" am Board testen. Nur so lassen sich Fehler auf die Schritte im workflow zurückführen.

Bei Änderungen am Core versagt gelegentlich das automatische Update von BPS etc.. Deshalb bei Coreänderungen die obsoleten Projekte (Hardware project, BSP und C-projekt) löschen und den workflow ab Schritt "tcl.script" wiederholen.

Fehlermeldungen in die Eingabemaske von google kopieren und nach Antworten bei Xilinx oder Internetforen suchen. Das führt bei den
oft verwirrenden Fehlermeldungen schnell zum Erfolg. So weist diese Meldung über Memory leaks:
[[Datei:Ss more ngdbuilt error.png|400px|thumb|center|ngdbuil error]]
eigentlich darauf hin, das der Instanzname des MCS-cores nicht stimmt. Der "Answer record" bei Xilinx http://www.xilinx.com/support/answers/51538.html erklärt wie man den korrekten Namen findet und in das BMM-file einträgt.

= Literatur =
* http://ece.wpi.edu/~rjduck/Microblaze%20MCS%20Tutorial%20v5.pdf - Eine in Englisch verfasste Anleitung zum Durchklicken.
Als Beispiel wird eine microblaze basierte UART-Verbindung zwischen PC und Nexsys2/3 board implementiert, verwendet wird die ISE 14.5.
* http://jimselectronicsblog.blogspot.de/2014/03/implementing-microblaze-mcs-on-papilio.html
Eine Englischsprachige Klickanleitung für das papilio-One board. Hier wird auch gezeigt wie UCF und top entity
mit dem PlanAHead tool angelegt wird. Die Screenshost sind recht gut kommentiert.
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/ds865_microblaze_mcs.pdf - XILINX DS865, die offizielle Beschreibung des Cores
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/pg116-microblaze-mcs.pdf - XILINX PG116, die offizielle Anleitung für Vivado
*http://www.xilinx.com/support/documentation/sw_manuals_j/xilinx14_5/pg048-microblaze-mcs.pdf - Xilinx PG048, die offizielle Anleitung für Vivado

Xilinx Microblaze MCS Workflow

2015-03-12T21:11:22Z

Fpgakuechle: /* Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei */ +screenshots

''Gestartet von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-Feb-27 -> Material,Tips zur Fehlersuch und Screenshots sammeln

Der Artikel beschreibt wie der 32bit Softcore "microblaze MCS" in FPGA verwendet wird.
Verwendet wird dabei die kostenfrei verfügbare "leichtgewichtige" MicroBlaze-mcs (µB-MCS) Variante aus dem coregenerator (ab ISE 13.4 (ab 01/2013) und Vivado) und nicht die kostenpflichtige MicroBlaze (ohne -MCS) Variante.

=MicroBlaze und MicroBlaze MCS=

=Ablauf=
Die Implementierung eines FPGA-Systems mit Softcore verläuft in folgenden Phasen:
*Erstellung des FPGA-drumherum (Top-level design, pinassigments) und FPGA ohne microblaze-Core implementieren
*Generierung des Softcore im CoreGenerator
*Instanziierung Core, Script für bm referenz ausführen und FPGA mit microblaze-Core implementieren
*Erstellung der compilerumgebung (board support package, libraries, linkerscript)
*Erstellung und Kompilierung des Programms
*Zusammenfügen programm-binarie mit FPGA-bitstream file

=Benötigte Software=
Es wird von Xilinx die FPGA Implementierungssoftware und das Software Development Kit (SDK)benötigt. Nutzer der FPGA's vor der 7Serie (bspw Spartan3-Großfamilie, Spartan-6, Virtex5/6) muüßen installieren:
*ISE Design Suite: WebPack edition
*ISE Design Suite: Embedded edition
(Siehe http://www.xilinx.com/products/design-tools/ise-design-suite.html )

Nutzer der neueren 7er Reihe dagegen benötigen:
*Vivado Design Suite Webpack edition
(Siehe http://www.xilinx.com/products/design-tools/vivado.html)

=Beispiel=
Es wird ein einfacher Core mit 3 Ausgangsport a 8,4 und 6 bit, einem Eingangsport zu 8bit sowie einem Festwert- (FIT) und ein programmierbarer Zähler (PIT) generiert.
[[Datei:Mcs block.png|thumb|center|400px|Blockdiagramm Beispiel]]

Neben dem Core ist ein weitere Zähler -''heartbeat''- im Design. Die drei Ausgangsporst sind für das verwendete S3AN Starterkit verbunden mit dem Datenbus und den Steuerleitung des alphanumerischen Displays und den 6 LED rechts. Die LED Nr 8 wird von dem FPGA-Logiccounter zum blinken gebracht, LED nummero 7 vom toggle-signal des Festwertcounter. Damit lassen sich 3 Implementierungsziele detektieren.
*Nix blinkt -> Totalversagen
*LED Nr. 8 blinkt -> FPGA erfolgreich geladen und gestartet
*LED 8 und 7 blinken: -> microblaze ist erfolgreich im FPGA implementiert, aber das Programm läuft nicht.
*Aktivität auf allen 8 LED's -> Perfekt

=FPGA-Implementierung und SoftCore-Generierung=
==FPGA-Gerüst==
Es ist Empfehlenswert zuerst ein "Basis-FPGA" ohne µB fertigzustellen und zu testen. Hier wurde das zum Starterkit gehörige Demo adaptiert und somit war schon mal die Pinzuordnung und das Taktsystem fehlerfrei. Eine heartbeat-LED die im Sekundentakt blinkt grenzt den Fehler deutlich ein.

==CoreGen==
Coregen starten (beispw. Programme -> Xilinx -> ISE 14.7 -> ISE Design tools -> 64bit tools -> coregen) Project für den benutzen FPGA aufsetzen (hier im beispiel S3AN-700; package: FGG484; speedgrade 4 Verilog)

IM IP catalog findet sich der MCE unter embedded Processing -> processors -> microblaze MCE :
[[Datei:Ss coregen main.png|thumb|center|400px|CoreGen Auswahl microblaze MCS Core]]

Im Unterschied zum Screenshot sollte man den Speicher auf mindestens 8 kByte setzen. Die Angabe der Taktfrequenz ist für die Berechnung des Baudraten-teilers für die UART wichtig. Benutzt man die UART nicht, ist dieser Wert (theoretisch?) für den Core bedeutungslos. Das Place&Route für den FPGA richtet sich nach der Taktvorgabe aus dem ucf-file.
Die in den Karteikarten gezeigten Kürzel stehen für die einzigen "Peripheriecontrollern" die für dem µB-MCS generiert
werden können. Mit dem weiterhin kostenpflichten Platform Studio sind weitere Cores einfach hinzufügbar. Aber beim MCS muß man nicht komplett darauf verzichten da an dem IO-Bus selbtgeschriebene Komponenten angeschlossen werden können.

*UART: feste Baudrate, Interrupt für RX
*FIT: Fixed length timer -4 möglich
*PIT: programmable Timer - 4? möglich
*GPO: Generalpurpose Output-Port - 4 Ports mit jeweils 1-32 bit Breite Konfigurierbar
*GPI: Generalpurpose Input-Port - 4 Ports mit jeweils 1-32 bit Breite Konfigurierbar
*INT: External Interrupt Sources

Für die Treiber kann auch ein toggle output signal geriert werden das immer beim Erreichen der O invertiert wird.

[[Datei:Ss coregen generalsettings.png|thumb|center|400px|CoreGen Settings für microblaze MCS Teil 1]]
[[Datei:Ss coregen fitsettings.png|thumb|center|400px|CoreGen Settings für Fixed Timer]]
[[Datei:Ss coregen generated files.png|thumb|center|400px|Liste Generierter Dateien]]
[[Datei:Ss coregen info sdk.png|thumb|center|400px|Coregen Hinweis nächste Schritte]]
[[Datei:Ss coregen info tcl.png|thumb|center|400px|Coregen Hinweis Tcl-script]]
[[Datei:Ss tcl console.png|thumb|center|400px|Tcl-Console]]
==Vorbereitung Synthese mit MCS core==

==Top-Level==
<syntaxhighlight lang="verilog">
wire heartbeat_s;

wire [7:0] GPO1_s; //display data
wire [3:0] GPO2_s; //display control
wire [6:0] GPO3_s; // led's
wire [7:0] GPI1_s; //switches

wire FIT1_Toggle_s;

MikroBlaze_mcs microblaze_s3an_disp (
.Clk(clk), // input Clk
.Reset(rst), // input Reset
.FIT1_Toggle(FIT1_Toggle_s), // output fixed timer toggler (every 25M ticks)
.FIT2_Interrupt(/*FIT2_Interrupt*/), // UNUSED - output FIT2_Interrupt
.FIT2_Toggle(/*FIT2_Toggle*/), // UNUSED - output FIT2_Toggle
.PIT1_Interrupt(/*PIT1_Interrupt*/), // UNUSED - output PIT1_Interrupt
.PIT1_Toggle(/*PIT1_Toggle*/), // UNUSED - output PIT1_Toggle
.GPO1(GPO1_s), // output [7 : 0] GPO1
.GPO2(GPO2_s), // output [3 : 0] GPO2
.GPO3(GPO3_s), // output [6 : 0] GPO3
.GPI1(GPI1_s), // input [7 : 0] GPI1
.GPI1_Interrupt(/*GPI1_Interrupt*/), // UNUSED - output GPI1_Interrupt
.INTC_IRQ(/*INTC_IRQ*/) // UNUSED - output INTC_IRQ
);

always @(posedge clk)
begin

assign LCD_DB = GPO1_s[7:0];
assign LCD_RW = GPO2_s[0];
assign LCD_RS = GPO2_s[1];
assign LCD_E = GPO2_s[2];
end

heartbeat heartbeat(
.clk(clk),
.rst(rst),
.heartbeat_o(heartbeat_s)
);

assign LED[7] = heartbeat_s;
assign LED[6] = FIT1_Toggle_s;
assign LED[5:0] = GPO3_s[5:0];
</syntaxhighlight>

==FPGA Implementierung ==
Am besten den FPGA mit den µB-MCS '''vor''' der Vorbereitung des SDK komplett implementieren und auf das Board laden. Es müßen die LED's 7 und 8 mit jeweils eigene Frequenz blinken. Wenn nicht, dann ist bei der Generierung und Instanziierung des Cores ein Fehler unterlaufen.

Jetzt, falls noch nicht geöffnet, ein Tcl Fenster öffnen (''ISE:View->Panels->Tcl Console'') dann erscheint unten eine schmale Zeile in der Tcl Kommandos eingegeben werden können, die Ausgabe erscheint in dem Fenster darüber.

Jetzt das vom ''coregen'' erzeugte tcl Script starten: ''source ../core/microblaze_mcs_setup.tcl'' . Dieses script fügt eine Option für das tool ''ngdbuild'' (Process "''Translate''") bei der Implementierung
hinzu. Zur Überprüfung die Optionen anzeigen lassen mit Mausklick rechts auf "''Translate''" im Process-Fenster und "process properties" auswählen. Es findet sich jetzt in der Zeile "Other ... options" ein Eintrag beginnend mit "-bm" der auf eine ebenfalls von coregen erzeugtes *.bmm Datei zeigt.

[[Datei:Ss after setup tcl.png|thumb|center|400px|Tcl-Console]]

Diese Datei am besten in einem Texteditor öffnen. wichtig ist hier der Pfad zu den RAM-Blöcken die das binary für den Softcore speichern werden.
Der Teil ganz links ist der in ersten ''CoreGen''-Fenster angegebene Instanz-name. Der muss auch mit dem Instanznamen im Top-file übereinstimmen, sonst
bricht Translate ab. Entfernt man die grad erwähnte -bm Option wieder aus den "Process Properties" läuft zwar der Schritt Translate und alle Folgenden
durch, aber es wird Probleme bei "Vereinigung von Programm-binarie und FPGA bitfile" geben -> die FPGA logic wird zwar funktionieren, aber es wird kein Programm
auf dem Softcore laufen.

=Generierung Compilerumgebung und microblaze-programm=
Für die folgenden Schritte ist das Software development Kit (SDK) zu starten,
das findet sich im Ordner EDK (Embedded Development Kit):

[[Datei:Ss programmmenu sdk.png|thumb|center|400px|Startmenu mit Xilinx-tools]]

Das SDK fragt beim Start nach einem Verzeichniss für den workspace.

Dannach erscheint beim ersten Start ein Welcome-Screen. Diesen an besten wegklicken da er
das fenster "project explorer" überdeckt. Jetzt müßen wir nacheinander 3 verschieden "typen" von "projekten" anlegen:
*Hardware Platform spezification - eine beschreibung des systems aus microblaze, Programmspeicher und Peripherie.
Diese benötigt die Infos aus dem Coregenlauf
*board support package - Header-dateien, linkerskripte mit kosntanten/ addressbereichen etc. passend zum mikrocontrollersystem
*C/C++projekt die leere C-datei für das eigentliche Programm

[[Datei:Sdk project wizards.png|thumb|center|400px|New -> Projects]]

==Hardware Platform Specification==
File -> new -> project -> Xilinx -> Hardware Platform Specification

Der Projectname erscheint dann im project explorer. Der Autor wählte zur besseren Unterscheidbarkeit
zu den anderen Projekttypen den suffix _hwp. in der Spalte hardwareproject-file ist das file aus den Coregen-lauf
anzugeben, es findet sich daher in dem Verzeichniss Core.

==Erstellung Hardware project==
[[Datei:Ss hardware palltform settings.png|400px|thumb|center]]
==Erstellung Board support package==
==Erstellung Programm==
[[Datei:Ss sdk cproject settings.png|400px|thumb|center]]
<syntaxhighlight lang="C">
#include <xparameters.h>
#include <xiomodule.h>
#include <stdbool.h>

#define LED_DELAY 100000

int main()
{
//instantiate IOs
XIOModule GPIO;

volatile u32 i = 0;

//initialize IOs
XIOModule_Initialize(&GPIO, XPAR_IOMODULE_0_DEVICE_ID);
XIOModule_Start(&GPIO);

//LED
bool led_on = false;
int run = 1;

for (;;)
{
if (led_on) {XIOModule_DiscreteWrite(&GPIO, 3,run);
if (run == 0x20) run = 1; else run *= 2;}
led_on = !led_on;
for(i=0;i < LED_DELAY; ++i);
}
}
</syntaxhighlight>

==Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei==
Im Menu "Xilinx Tools" den Punkt "Programm FPGA" auswählen und
[[Datei:Program FPGA.png|thumb|400px|center|Menu SDK program FPGA]]

anschließend das (beim CoreGen) angelegte *.bmm file, das compilierte Programm (*.elf) und das *.bit File des in der ISE generierten FPGA's auswählen und den Button "Program" drücken.
[[Datei:Program FPGA files.png|thumb|400px|center|Auswahl *.bmm *.bit *.elf for programming]]

Jetzt wird mittels der Information über die genutztem BRAM-Blöcke aus der *.bmm-Datei im *.bit-File die Bereiche die die Initdaten für die BRAM-Speicherblöcke enthält mit dem Binary des Programms ausgetauscht und anschließend das FPGA programmiert.

=Fehlersuche=
Wenn möglich auch die beiden Zwischenergebnisse ("Gesamtdesign ohne MCS-Core instanziierung" und "Mit Core aber ohne Programm" am Board testen. Nur so lassen sich Fehler auf die Schritte im workflow zurückführen.

Bei Änderungen am Core versagt gelegentlich das automatische Update von BPS etc.. Deshalb bei Coreänderungen die obsoleten Projekte (Hardware project, BSP und C-projekt) löschen und den workflow ab Schritt "tcl.script" wiederholen.

Fehlermeldungen in die Eingabemaske von google kopieren und nach Antworten bei Xilinx oder Internetforen suchen. Das führt bei den
oft verwirrenden Fehlermeldungen schnell zum Erfolg. So weist diese Meldung über Memory leaks:
[[Datei:Ss more ngdbuilt error.png|400px|thumb|center|ngdbuil error]]
eigentlich darauf hin, das der Instanzname des MCS-cores nicht stimmt. Der "Answer record" bei Xilinx http://www.xilinx.com/support/answers/51538.html erklärt wie man den korrekten Namen findet und in das BMM-file einträgt.

= Literatur =
* http://ece.wpi.edu/~rjduck/Microblaze%20MCS%20Tutorial%20v5.pdf - Eine in Englisch verfasste Anleitung zum Durchklicken.
Als Beispiel wird eine microblaze basierte UART-Verbindung zwischen PC und Nexsys2/3 board implementiert, verwendet wird die ISE 14.5.
* http://jimselectronicsblog.blogspot.de/2014/03/implementing-microblaze-mcs-on-papilio.html
Eine Englischsprachige Klickanleitung für das papilio-One board. Hier wird auch gezeigt wie UCF und top entity
mit dem PlanAHead tool angelegt wird. Die Screenshost sind recht gut kommentiert.
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/ds865_microblaze_mcs.pdf - XILINX DS865, die offizielle Beschreibung des Cores
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/pg116-microblaze-mcs.pdf - XILINX PG116, die offizielle Anleitung für Vivado
*http://www.xilinx.com/support/documentation/sw_manuals_j/xilinx14_5/pg048-microblaze-mcs.pdf - Xilinx PG048, die offizielle Anleitung für Vivado

Datei:Program FPGA files.png

2015-03-12T21:07:00Z

Fpgakuechle: Screenshoot Xilinx SDK - Program FPGA menu: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Screenshoot Xilinx SDK - Program FPGA menu: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Datei:Program FPGA.png

2015-03-12T21:03:28Z

Xilinx Microblaze MCS Workflow

2015-03-09T20:38:00Z

Fpgakuechle: /* FPGA Implementierung */ Kloankram

''Gestartet von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-Feb-27 -> Material,Tips zur Fehlersuch und Screenshots sammeln

Der Artikel beschreibt wie der 32bit Softcore "microblaze MCS" in FPGA verwendet wird.
Verwendet wird dabei die kostenfrei verfügbare "leichtgewichtige" MicroBlaze-mcs (µB-MCS) Variante aus dem coregenerator (ab ISE 13.4 (ab 01/2013) und Vivado) und nicht die kostenpflichtige MicroBlaze (ohne -MCS) Variante.

=MicroBlaze und MicroBlaze MCS=

=Ablauf=
Die Implementierung eines FPGA-Systems mit Softcore verläuft in folgenden Phasen:
*Erstellung des FPGA-drumherum (Top-level design, pinassigments) und FPGA ohne microblaze-Core implementieren
*Generierung des Softcore im CoreGenerator
*Instanziierung Core, Script für bm referenz ausführen und FPGA mit microblaze-Core implementieren
*Erstellung der compilerumgebung (board support package, libraries, linkerscript)
*Erstellung und Kompilierung des Programms
*Zusammenfügen programm-binarie mit FPGA-bitstream file

=Benötigte Software=
Es wird von Xilinx die FPGA Implementierungssoftware und das Software Development Kit (SDK)benötigt. Nutzer der FPGA's vor der 7Serie (bspw Spartan3-Großfamilie, Spartan-6, Virtex5/6) muüßen installieren:
*ISE Design Suite: WebPack edition
*ISE Design Suite: Embedded edition
(Siehe http://www.xilinx.com/products/design-tools/ise-design-suite.html )

Nutzer der neueren 7er Reihe dagegen benötigen:
*Vivado Design Suite Webpack edition
(Siehe http://www.xilinx.com/products/design-tools/vivado.html)

=Beispiel=
Es wird ein einfacher Core mit 3 Ausgangsport a 8,4 und 6 bit, einem Eingangsport zu 8bit sowie einem Festwert- (FIT) und ein programmierbarer Zähler (PIT) generiert.
[[Datei:Mcs block.png|thumb|center|400px|Blockdiagramm Beispiel]]

Neben dem Core ist ein weitere Zähler -''heartbeat''- im Design. Die drei Ausgangsporst sind für das verwendete S3AN Starterkit verbunden mit dem Datenbus und den Steuerleitung des alphanumerischen Displays und den 6 LED rechts. Die LED Nr 8 wird von dem FPGA-Logiccounter zum blinken gebracht, LED nummero 7 vom toggle-signal des Festwertcounter. Damit lassen sich 3 Implementierungsziele detektieren.
*Nix blinkt -> Totalversagen
*LED Nr. 8 blinkt -> FPGA erfolgreich geladen und gestartet
*LED 8 und 7 blinken: -> microblaze ist erfolgreich im FPGA implementiert, aber das Programm läuft nicht.
*Aktivität auf allen 8 LED's -> Perfekt

=FPGA-Implementierung und SoftCore-Generierung=
==FPGA-Gerüst==
Es ist Empfehlenswert zuerst ein "Basis-FPGA" ohne µB fertigzustellen und zu testen. Hier wurde das zum Starterkit gehörige Demo adaptiert und somit war schon mal die Pinzuordnung und das Taktsystem fehlerfrei. Eine heartbeat-LED die im Sekundentakt blinkt grenzt den Fehler deutlich ein.

==CoreGen==
Coregen starten (beispw. Programme -> Xilinx -> ISE 14.7 -> ISE Design tools -> 64bit tools -> coregen) Project für den benutzen FPGA aufsetzen (hier im beispiel S3AN-700; package: FGG484; speedgrade 4 Verilog)

IM IP catalog findet sich der MCE unter embedded Processing -> processors -> microblaze MCE :
[[Datei:Ss coregen main.png|thumb|center|400px|CoreGen Auswahl microblaze MCS Core]]

Im Unterschied zum Screenshot sollte man den Speicher auf mindestens 8 kByte setzen. Die Angabe der Taktfrequenz ist für die Berechnung des Baudraten-teilers für die UART wichtig. Benutzt man die UART nicht, ist dieser Wert (theoretisch?) für den Core bedeutungslos. Das Place&Route für den FPGA richtet sich nach der Taktvorgabe aus dem ucf-file.
Die in den Karteikarten gezeigten Kürzel stehen für die einzigen "Peripheriecontrollern" die für dem µB-MCS generiert
werden können. Mit dem weiterhin kostenpflichten Platform Studio sind weitere Cores einfach hinzufügbar. Aber beim MCS muß man nicht komplett darauf verzichten da an dem IO-Bus selbtgeschriebene Komponenten angeschlossen werden können.

*UART: feste Baudrate, Interrupt für RX
*FIT: Fixed length timer -4 möglich
*PIT: programmable Timer - 4? möglich
*GPO: Generalpurpose Output-Port - 4 Ports mit jeweils 1-32 bit Breite Konfigurierbar
*GPI: Generalpurpose Input-Port - 4 Ports mit jeweils 1-32 bit Breite Konfigurierbar
*INT: External Interrupt Sources

Für die Treiber kann auch ein toggle output signal geriert werden das immer beim Erreichen der O invertiert wird.

[[Datei:Ss coregen generalsettings.png|thumb|center|400px|CoreGen Settings für microblaze MCS Teil 1]]
[[Datei:Ss coregen fitsettings.png|thumb|center|400px|CoreGen Settings für Fixed Timer]]
[[Datei:Ss coregen generated files.png|thumb|center|400px|Liste Generierter Dateien]]
[[Datei:Ss coregen info sdk.png|thumb|center|400px|Coregen Hinweis nächste Schritte]]
[[Datei:Ss coregen info tcl.png|thumb|center|400px|Coregen Hinweis Tcl-script]]
[[Datei:Ss tcl console.png|thumb|center|400px|Tcl-Console]]
==Vorbereitung Synthese mit MCS core==

==Top-Level==
<syntaxhighlight lang="verilog">
wire heartbeat_s;

wire [7:0] GPO1_s; //display data
wire [3:0] GPO2_s; //display control
wire [6:0] GPO3_s; // led's
wire [7:0] GPI1_s; //switches

wire FIT1_Toggle_s;

MikroBlaze_mcs microblaze_s3an_disp (
.Clk(clk), // input Clk
.Reset(rst), // input Reset
.FIT1_Toggle(FIT1_Toggle_s), // output fixed timer toggler (every 25M ticks)
.FIT2_Interrupt(/*FIT2_Interrupt*/), // UNUSED - output FIT2_Interrupt
.FIT2_Toggle(/*FIT2_Toggle*/), // UNUSED - output FIT2_Toggle
.PIT1_Interrupt(/*PIT1_Interrupt*/), // UNUSED - output PIT1_Interrupt
.PIT1_Toggle(/*PIT1_Toggle*/), // UNUSED - output PIT1_Toggle
.GPO1(GPO1_s), // output [7 : 0] GPO1
.GPO2(GPO2_s), // output [3 : 0] GPO2
.GPO3(GPO3_s), // output [6 : 0] GPO3
.GPI1(GPI1_s), // input [7 : 0] GPI1
.GPI1_Interrupt(/*GPI1_Interrupt*/), // UNUSED - output GPI1_Interrupt
.INTC_IRQ(/*INTC_IRQ*/) // UNUSED - output INTC_IRQ
);

always @(posedge clk)
begin

assign LCD_DB = GPO1_s[7:0];
assign LCD_RW = GPO2_s[0];
assign LCD_RS = GPO2_s[1];
assign LCD_E = GPO2_s[2];
end

heartbeat heartbeat(
.clk(clk),
.rst(rst),
.heartbeat_o(heartbeat_s)
);

assign LED[7] = heartbeat_s;
assign LED[6] = FIT1_Toggle_s;
assign LED[5:0] = GPO3_s[5:0];
</syntaxhighlight>

==FPGA Implementierung ==
Am besten den FPGA mit den µB-MCS '''vor''' der Vorbereitung des SDK komplett implementieren und auf das Board laden. Es müßen die LED's 7 und 8 mit jeweils eigene Frequenz blinken. Wenn nicht, dann ist bei der Generierung und Instanziierung des Cores ein Fehler unterlaufen.

Jetzt, falls noch nicht geöffnet, ein Tcl Fenster öffnen (''ISE:View->Panels->Tcl Console'') dann erscheint unten eine schmale Zeile in der Tcl Kommandos eingegeben werden können, die Ausgabe erscheint in dem Fenster darüber.

Jetzt das vom ''coregen'' erzeugte tcl Script starten: ''source ../core/microblaze_mcs_setup.tcl'' . Dieses script fügt eine Option für das tool ''ngdbuild'' (Process "''Translate''") bei der Implementierung
hinzu. Zur Überprüfung die Optionen anzeigen lassen mit Mausklick rechts auf "''Translate''" im Process-Fenster und "process properties" auswählen. Es findet sich jetzt in der Zeile "Other ... options" ein Eintrag beginnend mit "-bm" der auf eine ebenfalls von coregen erzeugtes *.bmm Datei zeigt.

[[Datei:Ss after setup tcl.png|thumb|center|400px|Tcl-Console]]

Diese Datei am besten in einem Texteditor öffnen. wichtig ist hier der Pfad zu den RAM-Blöcken die das binary für den Softcore speichern werden.
Der Teil ganz links ist der in ersten ''CoreGen''-Fenster angegebene Instanz-name. Der muss auch mit dem Instanznamen im Top-file übereinstimmen, sonst
bricht Translate ab. Entfernt man die grad erwähnte -bm Option wieder aus den "Process Properties" läuft zwar der Schritt Translate und alle Folgenden
durch, aber es wird Probleme bei "Vereinigung von Programm-binarie und FPGA bitfile" geben -> die FPGA logic wird zwar funktionieren, aber es wird kein Programm
auf dem Softcore laufen.

=Generierung Compilerumgebung und microblaze-programm=
Für die folgenden Schritte ist das Software development Kit (SDK) zu starten,
das findet sich im Ordner EDK (Embedded Development Kit):

[[Datei:Ss programmmenu sdk.png|thumb|center|400px|Startmenu mit Xilinx-tools]]

Das SDK fragt beim Start nach einem Verzeichniss für den workspace.

Dannach erscheint beim ersten Start ein Welcome-Screen. Diesen an besten wegklicken da er
das fenster "project explorer" überdeckt. Jetzt müßen wir nacheinander 3 verschieden "typen" von "projekten" anlegen:
*Hardware Platform spezification - eine beschreibung des systems aus microblaze, Programmspeicher und Peripherie.
Diese benötigt die Infos aus dem Coregenlauf
*board support package - Header-dateien, linkerskripte mit kosntanten/ addressbereichen etc. passend zum mikrocontrollersystem
*C/C++projekt die leere C-datei für das eigentliche Programm

[[Datei:Sdk project wizards.png|thumb|center|400px|New -> Projects]]

==Hardware Platform Specification==
File -> new -> project -> Xilinx -> Hardware Platform Specification

Der Projectname erscheint dann im project explorer. Der Autor wählte zur besseren Unterscheidbarkeit
zu den anderen Projekttypen den suffix _hwp. in der Spalte hardwareproject-file ist das file aus den Coregen-lauf
anzugeben, es findet sich daher in dem Verzeichniss Core.

==Erstellung Hardware project==
[[Datei:Ss hardware palltform settings.png|400px|thumb|center]]
==Erstellung Board support package==
==Erstellung Programm==
[[Datei:Ss sdk cproject settings.png|400px|thumb|center]]
<syntaxhighlight lang="C">
#include <xparameters.h>
#include <xiomodule.h>
#include <stdbool.h>

#define LED_DELAY 100000

int main()
{
//instantiate IOs
XIOModule GPIO;

volatile u32 i = 0;

//initialize IOs
XIOModule_Initialize(&GPIO, XPAR_IOMODULE_0_DEVICE_ID);
XIOModule_Start(&GPIO);

//LED
bool led_on = false;
int run = 1;

for (;;)
{
if (led_on) {XIOModule_DiscreteWrite(&GPIO, 3,run);
if (run == 0x20) run = 1; else run *= 2;}
led_on = !led_on;
for(i=0;i < LED_DELAY; ++i);
}
}
</syntaxhighlight>

==Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei==
=Fehlersuche=
Wenn möglich auch die beiden Zwischenergebnisse ("Gesamtdesign ohne MCS-Core instanziierung" und "Mit Core aber ohne Programm" am Board testen. Nur so lassen sich Fehler auf die Schritte im workflow zurückführen.

Bei Änderungen am Core versagt gelegentlich das automatische Update von BPS etc.. Deshalb bei Coreänderungen die obsoleten Projekte (Hardware project, BSP und C-projekt) löschen und den workflow ab Schritt "tcl.script" wiederholen.

Fehlermeldungen in die Eingabemaske von google kopieren und nach Antworten bei Xilinx oder Internetforen suchen. Das führt bei den
oft verwirrenden Fehlermeldungen schnell zum Erfolg. So weist diese Meldung über Memory leaks:
[[Datei:Ss more ngdbuilt error.png|400px|thumb|center|ngdbuil error]]
eigentlich darauf hin, das der Instanzname des MCS-cores nicht stimmt. Der "Answer record" bei Xilinx http://www.xilinx.com/support/answers/51538.html erklärt wie man den korrekten Namen findet und in das BMM-file einträgt.

= Literatur =
* http://ece.wpi.edu/~rjduck/Microblaze%20MCS%20Tutorial%20v5.pdf - Eine in Englisch verfasste Anleitung zum Durchklicken.
Als Beispiel wird eine microblaze basierte UART-Verbindung zwischen PC und Nexsys2/3 board implementiert, verwendet wird die ISE 14.5.
* http://jimselectronicsblog.blogspot.de/2014/03/implementing-microblaze-mcs-on-papilio.html
Eine Englischsprachige Klickanleitung für das papilio-One board. Hier wird auch gezeigt wie UCF und top entity
mit dem PlanAHead tool angelegt wird. Die Screenshost sind recht gut kommentiert.
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/ds865_microblaze_mcs.pdf - XILINX DS865, die offizielle Beschreibung des Cores
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/pg116-microblaze-mcs.pdf - XILINX PG116, die offizielle Anleitung für Vivado
*http://www.xilinx.com/support/documentation/sw_manuals_j/xilinx14_5/pg048-microblaze-mcs.pdf - Xilinx PG048, die offizielle Anleitung für Vivado

Xilinx Microblaze MCS Workflow

2015-03-07T21:52:50Z

Fpgakuechle: Peripherie

''Gestartet von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-Feb-27 -> Material,Tips zur Fehlersuch und Screenshots sammeln

Der Artikel beschreibt wie der 32bit Softcore "microblaze MCS" in FPGA verwendet wird.
Verwendet wird dabei die kostenfrei verfügbare "leichtgewichtige" MicroBlaze-mcs (µB-MCS) Variante aus dem coregenerator (ab ISE 13.4 (ab 01/2013) und Vivado) und nicht die kostenpflichtige MicroBlaze (ohne -MCS) Variante.

=MicroBlaze und MicroBlaze MCS=

=Ablauf=
Die Implementierung eines FPGA-Systems mit Softcore verläuft in folgenden Phasen:
*Erstellung des FPGA-drumherum (Top-level design, pinassigments) und FPGA ohne microblaze-Core implementieren
*Generierung des Softcore im CoreGenerator
*Instanziierung Core, Script für bm referenz ausführen und FPGA mit microblaze-Core implementieren
*Erstellung der compilerumgebung (board support package, libraries, linkerscript)
*Erstellung und Kompilierung des Programms
*Zusammenfügen programm-binarie mit FPGA-bitstream file

=Benötigte Software=
Es wird von Xilinx die FPGA Implementierungssoftware und das Software Development Kit (SDK)benötigt. Nutzer der FPGA's vor der 7Serie (bspw Spartan3-Großfamilie, Spartan-6, Virtex5/6) muüßen installieren:
*ISE Design Suite: WebPack edition
*ISE Design Suite: Embedded edition
(Siehe http://www.xilinx.com/products/design-tools/ise-design-suite.html )

Nutzer der neueren 7er Reihe dagegen benötigen:
*Vivado Design Suite Webpack edition
(Siehe http://www.xilinx.com/products/design-tools/vivado.html)

=Beispiel=
Es wird ein einfacher Core mit 3 Ausgangsport a 8,4 und 6 bit, einem Eingangsport zu 8bit sowie einem Festwert- (FIT) und ein programmierbarer Zähler (PIT) generiert.
[[Datei:Mcs block.png|thumb|center|400px|Blockdiagramm Beispiel]]

Neben dem Core ist ein weitere Zähler -''heartbeat''- im Design. Die drei Ausgangsporst sind für das verwendete S3AN Starterkit verbunden mit dem Datenbus und den Steuerleitung des alphanumerischen Displays und den 6 LED rechts. Die LED Nr 8 wird von dem FPGA-Logiccounter zum blinken gebracht, LED nummero 7 vom toggle-signal des Festwertcounter. Damit lassen sich 3 Implementierungsziele detektieren.
*Nix blinkt -> Totalversagen
*LED Nr. 8 blinkt -> FPGA erfolgreich geladen und gestartet
*LED 8 und 7 blinken: -> microblaze ist erfolgreich im FPGA implementiert, aber das Programm läuft nicht.
*Aktivität auf allen 8 LED's -> Perfekt

=FPGA-Implementierung und SoftCore-Generierung=
==FPGA-Gerüst==
Es ist Empfehlenswert zuerst ein "Basis-FPGA" ohne µB fertigzustellen und zu testen. Hier wurde das zum Starterkit gehörige Demo adaptiert und somit war schon mal die Pinzuordnung und das Taktsystem fehlerfrei. Eine heartbeat-LED die im Sekundentakt blinkt grenzt den Fehler deutlich ein.

==CoreGen==
Coregen starten (beispw. Programme -> Xilinx -> ISE 14.7 -> ISE Design tools -> 64bit tools -> coregen) Project für den benutzen FPGA aufsetzen (hier im beispiel S3AN-700; package: FGG484; speedgrade 4 Verilog)

IM IP catalog findet sich der MCE unter embedded Processing -> processors -> microblaze MCE :
[[Datei:Ss coregen main.png|thumb|center|400px|CoreGen Auswahl microblaze MCS Core]]

Im Unterschied zum Screenshot sollte man den Speicher auf mindestens 8 kByte setzen. Die Angabe der Taktfrequenz ist für die Berechnung des Baudraten-teilers für die UART wichtig. Benutzt man die UART nicht, ist dieser Wert (theoretisch?) für den Core bedeutungslos. Das Place&Route für den FPGA richtet sich nach der Taktvorgabe aus dem ucf-file.
Die in den Karteikarten gezeigten Kürzel stehen für die einzigen "Peripheriecontrollern" die für dem µB-MCS generiert
werden können. Mit dem weiterhin kostenpflichten Platform Studio sind weitere Cores einfach hinzufügbar. Aber beim MCS muß man nicht komplett darauf verzichten da an dem IO-Bus selbtgeschriebene Komponenten angeschlossen werden können.

*UART: feste Baudrate, Interrupt für RX
*FIT: Fixed length timer -4 möglich
*PIT: programmable Timer - 4? möglich
*GPO: Generalpurpose Output-Port - 4 Ports mit jeweils 1-32 bit Breite Konfigurierbar
*GPI: Generalpurpose Input-Port - 4 Ports mit jeweils 1-32 bit Breite Konfigurierbar
*INT: External Interrupt Sources

Für die Treiber kann auch ein toggle output signal geriert werden das immer beim Erreichen der O invertiert wird.

[[Datei:Ss coregen generalsettings.png|thumb|center|400px|CoreGen Settings für microblaze MCS Teil 1]]
[[Datei:Ss coregen fitsettings.png|thumb|center|400px|CoreGen Settings für Fixed Timer]]
[[Datei:Ss coregen generated files.png|thumb|center|400px|Liste Generierter Dateien]]
[[Datei:Ss coregen info sdk.png|thumb|center|400px|Coregen Hinweis nächste Schritte]]
[[Datei:Ss coregen info tcl.png|thumb|center|400px|Coregen Hinweis Tcl-script]]
[[Datei:Ss tcl console.png|thumb|center|400px|Tcl-Console]]
==Vorbereitung Synthese mit MCS core==

==Top-Level==
<syntaxhighlight lang="verilog">
wire heartbeat_s;

wire [7:0] GPO1_s; //display data
wire [3:0] GPO2_s; //display control
wire [6:0] GPO3_s; // led's
wire [7:0] GPI1_s; //switches

wire FIT1_Toggle_s;

MikroBlaze_mcs microblaze_s3an_disp (
.Clk(clk), // input Clk
.Reset(rst), // input Reset
.FIT1_Toggle(FIT1_Toggle_s), // output fixed timer toggler (every 25M ticks)
.FIT2_Interrupt(/*FIT2_Interrupt*/), // UNUSED - output FIT2_Interrupt
.FIT2_Toggle(/*FIT2_Toggle*/), // UNUSED - output FIT2_Toggle
.PIT1_Interrupt(/*PIT1_Interrupt*/), // UNUSED - output PIT1_Interrupt
.PIT1_Toggle(/*PIT1_Toggle*/), // UNUSED - output PIT1_Toggle
.GPO1(GPO1_s), // output [7 : 0] GPO1
.GPO2(GPO2_s), // output [3 : 0] GPO2
.GPO3(GPO3_s), // output [6 : 0] GPO3
.GPI1(GPI1_s), // input [7 : 0] GPI1
.GPI1_Interrupt(/*GPI1_Interrupt*/), // UNUSED - output GPI1_Interrupt
.INTC_IRQ(/*INTC_IRQ*/) // UNUSED - output INTC_IRQ
);

always @(posedge clk)
begin

assign LCD_DB = GPO1_s[7:0];
assign LCD_RW = GPO2_s[0];
assign LCD_RS = GPO2_s[1];
assign LCD_E = GPO2_s[2];
end

heartbeat heartbeat(
.clk(clk),
.rst(rst),
.heartbeat_o(heartbeat_s)
);

assign LED[7] = heartbeat_s;
assign LED[6] = FIT1_Toggle_s;
assign LED[5:0] = GPO3_s[5:0];
</syntaxhighlight>

==FPGA Implementierung ==
Am besten den FPGA mit den MCS '''vor''' der Vorbereitung des SDK komplett implementieren und auf das board laden. Es müßen die LED's 7 und 8 mit jeweils eigene Frequenz blinken. Wenn nicht, dann ist bei der Generierung und Instanziierung des Cores ein Fehler unterlaufen.

Jetzt, falls noch nicht geöffnet, ein Tcl Fenster öffnen (ISE:View->Panels_Tcl console) dann erscheint unten eine schmale Zeile in der tcl Kommandos eingegeben werden können, die Ausgabe erscheint in dem Fenster darüber.

Jetzt das vom coregen erzeugte tcl script starten: source ../core/microblaze_mcs_setup.tcl . Dieses script fügt eine Option für das tool ''ngdbuild'' (für den Process "''Translate''" bei der Implementierung
hinzu. Zur Überprüfung die Optionen anzeigen lassen mit Mausklick rechts auf "Translate im Process-Fenster und "process properties" auswählen. Es findet sich jetzt in der Zeile "Other ... options" ein Eintrag beginnend mit "-bm" der auf ein ebenfalls von coregen erzeugtes .bmm file zeigt.

[[Datei:Ss after setup tcl.png|thumb|center|400px|Tcl-Console]]

Diese Datei am besten in einem Texteditor öffnen. wichtig ist hier der Pfad zu den RAM-Blöcken die das binary für den Softcore speichern werden.
Der Teil ganz links ist der in ersten Coregen fenster angegebene Instanz-name. Der muss auch mit dem Instanznamen im Top-file übereinstimmen, sonst
bricht Translate ab. Entfernt man die grad erwähnte -bm Option wieder aus den "Process Properties" läuft zwar der Schritt Translate und alle folgenden
durch, aber es wird Probleme bei "Vereinigung von Programm-binarie und FPGA bitfile geben -> die FPGA logic wird zwar funktionieren, aber es wird kein Programm
auf dem Softcore laufen.

=Generierung Compilerumgebung und microblaze-programm=
Für die folgenden Schritte ist das Software development Kit (SDK) zu starten,
das findet sich im Ordner EDK (Embedded Development Kit):

[[Datei:Ss programmmenu sdk.png|thumb|center|400px|Startmenu mit Xilinx-tools]]

Das SDK fragt beim Start nach einem Verzeichniss für den workspace.

Dannach erscheint beim ersten Start ein Welcome-Screen. Diesen an besten wegklicken da er
das fenster "project explorer" überdeckt. Jetzt müßen wir nacheinander 3 verschieden "typen" von "projekten" anlegen:
*Hardware Platform spezification - eine beschreibung des systems aus microblaze, Programmspeicher und Peripherie.
Diese benötigt die Infos aus dem Coregenlauf
*board support package - Header-dateien, linkerskripte mit kosntanten/ addressbereichen etc. passend zum mikrocontrollersystem
*C/C++projekt die leere C-datei für das eigentliche Programm

[[Datei:Sdk project wizards.png|thumb|center|400px|New -> Projects]]

==Hardware Platform Specification==
File -> new -> project -> Xilinx -> Hardware Platform Specification

Der Projectname erscheint dann im project explorer. Der Autor wählte zur besseren Unterscheidbarkeit
zu den anderen Projekttypen den suffix _hwp. in der Spalte hardwareproject-file ist das file aus den Coregen-lauf
anzugeben, es findet sich daher in dem Verzeichniss Core.

==Erstellung Hardware project==
[[Datei:Ss hardware palltform settings.png|400px|thumb|center]]
==Erstellung Board support package==
==Erstellung Programm==
[[Datei:Ss sdk cproject settings.png|400px|thumb|center]]
<syntaxhighlight lang="C">
#include <xparameters.h>
#include <xiomodule.h>
#include <stdbool.h>

#define LED_DELAY 100000

int main()
{
//instantiate IOs
XIOModule GPIO;

volatile u32 i = 0;

//initialize IOs
XIOModule_Initialize(&GPIO, XPAR_IOMODULE_0_DEVICE_ID);
XIOModule_Start(&GPIO);

//LED
bool led_on = false;
int run = 1;

for (;;)
{
if (led_on) {XIOModule_DiscreteWrite(&GPIO, 3,run);
if (run == 0x20) run = 1; else run *= 2;}
led_on = !led_on;
for(i=0;i < LED_DELAY; ++i);
}
}
</syntaxhighlight>

==Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei==
=Fehlersuche=
Wenn möglich auch die beiden Zwischenergebnisse ("Gesamtdesign ohne MCS-Core instanziierung" und "Mit Core aber ohne Programm" am Board testen. Nur so lassen sich Fehler auf die Schritte im workflow zurückführen.

Bei Änderungen am Core versagt gelegentlich das automatische Update von BPS etc.. Deshalb bei Coreänderungen die obsoleten Projekte (Hardware project, BSP und C-projekt) löschen und den workflow ab Schritt "tcl.script" wiederholen.

Fehlermeldungen in die Eingabemaske von google kopieren und nach Antworten bei Xilinx oder Internetforen suchen. Das führt bei den
oft verwirrenden Fehlermeldungen schnell zum Erfolg. So weist diese Meldung über Memory leaks:
[[Datei:Ss more ngdbuilt error.png|400px|thumb|center|ngdbuil error]]
eigentlich darauf hin, das der Instanzname des MCS-cores nicht stimmt. Der "Answer record" bei Xilinx http://www.xilinx.com/support/answers/51538.html erklärt wie man den korrekten Namen findet und in das BMM-file einträgt.

= Literatur =
* http://ece.wpi.edu/~rjduck/Microblaze%20MCS%20Tutorial%20v5.pdf - Eine in Englisch verfasste Anleitung zum Durchklicken.
Als Beispiel wird eine microblaze basierte UART-Verbindung zwischen PC und Nexsys2/3 board implementiert, verwendet wird die ISE 14.5.
* http://jimselectronicsblog.blogspot.de/2014/03/implementing-microblaze-mcs-on-papilio.html
Eine Englischsprachige Klickanleitung für das papilio-One board. Hier wird auch gezeigt wie UCF und top entity
mit dem PlanAHead tool angelegt wird. Die Screenshost sind recht gut kommentiert.
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/ds865_microblaze_mcs.pdf - XILINX DS865, die offizielle Beschreibung des Cores
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/pg116-microblaze-mcs.pdf - XILINX PG116, die offizielle Anleitung für Vivado
*http://www.xilinx.com/support/documentation/sw_manuals_j/xilinx14_5/pg048-microblaze-mcs.pdf - Xilinx PG048, die offizielle Anleitung für Vivado

Xilinx Microblaze MCS Workflow

2015-03-07T18:26:46Z

Fpgakuechle: /* SoftCore-Generierung und FPGA-Implementierung */ a biiserl drumherum vor der Core-genrierung

''Gestartet von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-Feb-27 -> Material,Tips zur Fehlersuch und Screenshots sammeln

Der Artikel beschreibt wie der 32bit Softcore "microblaze MCS" in FPGA verwendet wird.
Verwendet wird dabei die kostenfrei verfügbare "leichtgewichtige" microblaze mcs Variante aus dem coregenerator (ab ISE 13.4 und Vivado) und nicht die kostenpflichtige EDK Variante.

=Ablauf=
Die Implementierung eines FPGA-Systems mit Softcore verläuft in folgenden Phasen:
*Erstellung des FPGA-drumherum (Top-level design, pinassigments) und FPGA ohne microblaze-Core implementieren
*Generierung des Softcore im CoreGenerator
*Instanziierung Core, Script für bm referenz ausführen und FPGA mit microblaze-Core implementieren
*Erstellung der compilerumgebung (board support package, libraries, linkerscript)
*Erstellung und Kompilierung des Programms
*Zusammenfügen programm-binarie mit FPGA-bitstream file

=Benötigte Software=
Es wird von Xilinx die FPGA Implementierungssoftware und das Software Development Kit (SDK)benötigt. Nutzer der FPGA's vor der 7Serie (bspw Spartan3-Großfamilie, Spartan-6, Virtex5/6) muüßen installieren:
*ISE Design Suite: WebPack edition
*ISE Design Suite: Embedded edition
(Siehe http://www.xilinx.com/products/design-tools/ise-design-suite.html )

Nutzer der neueren 7er Reihe dagegen benötigen:
*Vivado Design Suite Webpack edition
(Siehe http://www.xilinx.com/products/design-tools/vivado.html)

=Beispiel=
Es wird ein einfacher Core mit 3 Ausgangsport a 8,4 und 6 bit, einem Eingangsport zu 8bit sowie einem Festwert- (FIT) und ein programmierbarer Zähler (PIT) generiert.
[[Datei:Mcs block.png|thumb|center|400px|Blockdiagramm Beispiel]]

Neben dem Core ist ein weitere Zähler -''heartbeat''- im Design. Die drei Ausgangsporst sind für das verwendete S3AN Starterkit verbunden mit dem Datenbus und den Steuerleitung des alphanumerischen Displays und den 6 LED rechts. Die LED Nr 8 wird von dem FPGA-Logiccounter zum blinken gebracht, LED nummero 7 vom toggle-signal des Festwertcounter. Damit lassen sich 3 Implementierungsziele detektieren.
*Nix blinkt -> Totalversagen
*LED Nr. 8 blinkt -> FPGA erfolgreich geladen und gestartet
*LED 8 und 7 blinken: -> microblaze ist erfolgreich im FPGA implementiert, aber das Programm läuft nicht.
*Aktivität auf allen 8 LED's -> Perfekt

=FPGA-Implementierung und SoftCore-Generierung=
==FPGA-Gerüst==
Es ist Empfehlenswert zuerst ein "Basis-FPGA" ohne µB fertigzustellen und zu testen. Hier wurde das zum Starterkit gehörige Demo
adaptiert und somit war schon mal die Pinzuordnung und das Taktsystem fehlerfrei. Eine heartbeat-LED die im Sekundentakt blinkt
grenzt den Fehler schon deutlich ein.

==CoreGen==
Coregen starten (beispw. Programme -> Xilinx -> ISE 14.7 -> ISE Design tools -> 64bit tools -> coregen) Project für den benutzen FPGA aufsetzen (hier im beispiel S3AN-700; package: FGG484; speedgrade 4 Verilog)

IM IP catalog findet sich der MCE unter embedded Processing -> processors -> microblaze MCE :
[[Datei:Ss coregen main.png|thumb|center|400px|CoreGen Auswahl microblaze MCS Core]]

Im Unterschied zum Screenshot sollte man den Speicher auf mindestens 8 kByte setzen. Die Angabe der Taktfrequenz ist für die Berechnung des Baudraten-teilers für die UART wichtig. benutzt man die UART nicht, ist dieser Wert (theoretisch?) für den Core bedeutungslos. Das Place&Route für den FPGA richtet sich nach der Taktvorgabe aus dem ucf-file.
[[Datei:Ss coregen generalsettings.png|thumb|center|400px|CoreGen Settings für microblaze MCS Teil 1]]
[[Datei:Ss coregen fitsettings.png|thumb|center|400px|CoreGen Settings für Fixed Timer]]
[[Datei:Ss coregen generated files.png|thumb|center|400px|Liste Generierter Dateien]]
[[Datei:Ss coregen info sdk.png|thumb|center|400px|Coregen Hinweis nächste Schritte]]
[[Datei:Ss coregen info tcl.png|thumb|center|400px|Coregen Hinweis Tcl-script]]
[[Datei:Ss tcl console.png|thumb|center|400px|Tcl-Console]]
==Vorbereitung Synthese mit MCS core==

==Top-Level==
<syntaxhighlight lang="verilog">
wire heartbeat_s;

wire [7:0] GPO1_s; //display data
wire [3:0] GPO2_s; //display control
wire [6:0] GPO3_s; // led's
wire [7:0] GPI1_s; //switches

wire FIT1_Toggle_s;

MikroBlaze_mcs microblaze_s3an_disp (
.Clk(clk), // input Clk
.Reset(rst), // input Reset
.FIT1_Toggle(FIT1_Toggle_s), // output fixed timer toggler (every 25M ticks)
.FIT2_Interrupt(/*FIT2_Interrupt*/), // UNUSED - output FIT2_Interrupt
.FIT2_Toggle(/*FIT2_Toggle*/), // UNUSED - output FIT2_Toggle
.PIT1_Interrupt(/*PIT1_Interrupt*/), // UNUSED - output PIT1_Interrupt
.PIT1_Toggle(/*PIT1_Toggle*/), // UNUSED - output PIT1_Toggle
.GPO1(GPO1_s), // output [7 : 0] GPO1
.GPO2(GPO2_s), // output [3 : 0] GPO2
.GPO3(GPO3_s), // output [6 : 0] GPO3
.GPI1(GPI1_s), // input [7 : 0] GPI1
.GPI1_Interrupt(/*GPI1_Interrupt*/), // UNUSED - output GPI1_Interrupt
.INTC_IRQ(/*INTC_IRQ*/) // UNUSED - output INTC_IRQ
);

always @(posedge clk)
begin

assign LCD_DB = GPO1_s[7:0];
assign LCD_RW = GPO2_s[0];
assign LCD_RS = GPO2_s[1];
assign LCD_E = GPO2_s[2];
end

heartbeat heartbeat(
.clk(clk),
.rst(rst),
.heartbeat_o(heartbeat_s)
);

assign LED[7] = heartbeat_s;
assign LED[6] = FIT1_Toggle_s;
assign LED[5:0] = GPO3_s[5:0];
</syntaxhighlight>

==FPGA Implementierung ==
Am besten den FPGA mit den MCS '''vor''' der Vorbereitung des SDK komplett implementieren und auf das board laden. Es müßen die LED's 7 und 8 mit jeweils eigene Frequenz blinken. Wenn nicht, dann ist bei der Generierung und Instanziierung des Cores ein Fehler unterlaufen.

Jetzt, falls noch nicht geöffnet, ein Tcl Fenster öffnen (ISE:View->Panels_Tcl console) dann erscheint unten eine schmale Zeile in der tcl Kommandos eingegeben werden können, die Ausgabe erscheint in dem Fenster darüber.

Jetzt das vom coregen erzeugte tcl script starten: source ../core/microblaze_mcs_setup.tcl . Dieses script fügt eine Option für das tool ''ngdbuild'' (für den Process "''Translate''" bei der Implementierung
hinzu. Zur Überprüfung die Optionen anzeigen lassen mit Mausklick rechts auf "Translate im Process-Fenster und "process properties" auswählen. Es findet sich jetzt in der Zeile "Other ... options" ein Eintrag beginnend mit "-bm" der auf ein ebenfalls von coregen erzeugtes .bmm file zeigt.

[[Datei:Ss after setup tcl.png|thumb|center|400px|Tcl-Console]]

Diese Datei am besten in einem Texteditor öffnen. wichtig ist hier der Pfad zu den RAM-Blöcken die das binary für den Softcore speichern werden.
Der Teil ganz links ist der in ersten Coregen fenster angegebene Instanz-name. Der muss auch mit dem Instanznamen im Top-file übereinstimmen, sonst
bricht Translate ab. Entfernt man die grad erwähnte -bm Option wieder aus den "Process Properties" läuft zwar der Schritt Translate und alle folgenden
durch, aber es wird Probleme bei "Vereinigung von Programm-binarie und FPGA bitfile geben -> die FPGA logic wird zwar funktionieren, aber es wird kein Programm
auf dem Softcore laufen.

=Generierung Compilerumgebung und microblaze-programm=
Für die folgenden Schritte ist das Software development Kit (SDK) zu starten,
das findet sich im Ordner EDK (Embedded Development Kit):

[[Datei:Ss programmmenu sdk.png|thumb|center|400px|Startmenu mit Xilinx-tools]]

Das SDK fragt beim Start nach einem Verzeichniss für den workspace.

Dannach erscheint beim ersten Start ein Welcome-Screen. Diesen an besten wegklicken da er
das fenster "project explorer" überdeckt. Jetzt müßen wir nacheinander 3 verschieden "typen" von "projekten" anlegen:
*Hardware Platform spezification - eine beschreibung des systems aus microblaze, Programmspeicher und Peripherie.
Diese benötigt die Infos aus dem Coregenlauf
*board support package - Header-dateien, linkerskripte mit kosntanten/ addressbereichen etc. passend zum mikrocontrollersystem
*C/C++projekt die leere C-datei für das eigentliche Programm

[[Datei:Sdk project wizards.png|thumb|center|400px|New -> Projects]]

==Hardware Platform Specification==
File -> new -> project -> Xilinx -> Hardware Platform Specification

Der Projectname erscheint dann im project explorer. Der Autor wählte zur besseren Unterscheidbarkeit
zu den anderen Projekttypen den suffix _hwp. in der Spalte hardwareproject-file ist das file aus den Coregen-lauf
anzugeben, es findet sich daher in dem Verzeichniss Core.

==Erstellung Hardware project==
[[Datei:Ss hardware palltform settings.png|400px|thumb|center]]
==Erstellung Board support package==
==Erstellung Programm==
[[Datei:Ss sdk cproject settings.png|400px|thumb|center]]
<syntaxhighlight lang="C">
#include <xparameters.h>
#include <xiomodule.h>
#include <stdbool.h>

#define LED_DELAY 100000

int main()
{
//instantiate IOs
XIOModule GPIO;

volatile u32 i = 0;

//initialize IOs
XIOModule_Initialize(&GPIO, XPAR_IOMODULE_0_DEVICE_ID);
XIOModule_Start(&GPIO);

//LED
bool led_on = false;
int run = 1;

for (;;)
{
if (led_on) {XIOModule_DiscreteWrite(&GPIO, 3,run);
if (run == 0x20) run = 1; else run *= 2;}
led_on = !led_on;
for(i=0;i < LED_DELAY; ++i);
}
}
</syntaxhighlight>

==Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei==
=Fehlersuche=
Wenn möglich auch die beiden Zwischenergebnisse ("Gesamtdesign ohne MCS-Core instanziierung" und "Mit Core aber ohne Programm" am Board testen. Nur so lassen sich Fehler auf die Schritte im workflow zurückführen.

Bei Änderungen am Core versagt gelegentlich das automatische Update von BPS etc.. Deshalb bei Coreänderungen die obsoleten Projekte (Hardware project, BSP und C-projekt) löschen und den workflow ab Schritt "tcl.script" wiederholen.

Fehlermeldungen in die Eingabemaske von google kopieren und nach Antworten bei Xilinx oder Internetforen suchen. Das führt bei den
oft verwirrenden Fehlermeldungen schnell zum Erfolg. So weist diese Meldung über Memory leaks:
[[Datei:Ss more ngdbuilt error.png|400px|thumb|center|ngdbuil error]]
eigentlich darauf hin, das der Instanzname des MCS-cores nicht stimmt. Der "Answer record" bei Xilinx http://www.xilinx.com/support/answers/51538.html erklärt wie man den korrekten Namen findet und in das BMM-file einträgt.

= Literatur =
* http://ece.wpi.edu/~rjduck/Microblaze%20MCS%20Tutorial%20v5.pdf - Eine in Englisch verfasste Anleitung zum Durchklicken.
Als Beispiel wird eine microblaze basierte UART-Verbindung zwischen PC und Nexsys2/3 board implementiert, verwendet wird die ISE 14.5.
* http://jimselectronicsblog.blogspot.de/2014/03/implementing-microblaze-mcs-on-papilio.html
Eine Englischsprachige Klickanleitung für das papilio-One board. Hier wird auch gezeigt wie UCF und top entity
mit dem PlanAHead tool angelegt wird. Die Screenshost sind recht gut kommentiert.
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/ds865_microblaze_mcs.pdf - XILINX DS865, die offizielle Beschreibung des Cores
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/pg116-microblaze-mcs.pdf - XILINX PG116, die offizielle Anleitung für Vivado
*http://www.xilinx.com/support/documentation/sw_manuals_j/xilinx14_5/pg048-microblaze-mcs.pdf - Xilinx PG048, die offizielle Anleitung für Vivado

Xilinx Microblaze MCS Workflow

2015-03-02T20:59:38Z

Fpgakuechle: Start coreGen

''Gestartet von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-Feb-27 -> Material,Tips zur Fehlersuch und Screenshots sammeln

Der Artikel beschreibt wie der 32bit Softcore "microblaze MCS" in FPGA verwendet wird.
Verwendet wird dabei die kostenfrei verfügbare "leichtgewichtige" microblaze mcs Variante aus dem coregenerator (ab ISE 13.4 und Vivado) und nicht die kostenpflichtige EDK Variante.

=Ablauf=
Die Implementierung eines FPGA-Systems mit Softcore verläuft in folgenden Phasen:
*Erstellung des FPGA-drumherum (Top-level design, pinassigments) und FPGA ohne microblaze-Core implementieren
*Generierung des Softcore im CoreGenerator
*Instanziierung Core, Script für bm referenz ausführen und FPGA mit microblaze-Core implementieren
*Erstellung der compilerumgebung (board support package, libraries, linkerscript)
*Erstellung und Kompilierung des Programms
*Zusammenfügen programm-binarie mit FPGA-bitstream file

=Benötigte Software=
Es wird von Xilinx die FPGA Implementierungssoftware und das Software Development Kit (SDK)benötigt. Nutzer der FPGA's vor der 7Serie (bspw Spartan3-Großfamilie, Spartan-6, Virtex5/6) muüßen installieren:
*ISE Design Suite: WebPack edition
*ISE Design Suite: Embedded edition
(Siehe http://www.xilinx.com/products/design-tools/ise-design-suite.html )

Nutzer der neueren 7er Reihe dagegen benötigen:
*Vivado Design Suite Webpack edition
(Siehe http://www.xilinx.com/products/design-tools/vivado.html)

=Beispiel=
Es wird ein einfacher Core mit 3 Ausgangsport a 8,4 und 6 bit, einem Eingangsport zu 8bit sowie einem Festwert- (FIT) und ein programmierbarer Zähler (PIT) generiert.
[[Datei:Mcs block.png|thumb|center|400px|Blockdiagramm Beispiel]]

Neben dem Core ist ein weitere Zähler -''heartbeat''- im Design. Die drei Ausgangsporst sind für das verwendete S3AN Starterkit verbunden mit dem Datenbus und den Steuerleitung des alphanumerischen Displays und den 6 LED rechts. Die LED Nr 8 wird von dem FPGA-Logiccounter zum blinken gebracht, LED nummero 7 vom toggle-signal des Festwertcounter. Damit lassen sich 3 Implementierungsziele detektieren.
*Nix blinkt -> Totalversagen
*LED Nr. 8 blinkt -> FPGA erfolgreich geladen und gestartet
*LED 8 und 7 blinken: -> microblaze ist erfolgreich im FPGA implementiert, aber das Programm läuft nicht.
*Aktivität auf allen 8 LED's -> Perfekt

=SoftCore-Generierung und FPGA-Implementierung=
==CoreGen==
Coregen starten (beispw. Programme -> Xilinx -> ISE 14.7 -> ISE Design tools -> 64bit tools -> coregen) Project für den benutzen FPGA aufsetzen (hier im beispiel S3AN-700; package: FGG484; speedgrade 4 Verilog)

IM IP catalog findet sich der MCE unter embedded Processing -> processors -> microblaze MCE :
[[Datei:Ss coregen main.png|thumb|center|400px|CoreGen Auswahl microblaze MCS Core]]
[[Datei:Ss coregen generalsettings.png|thumb|center|400px|CoreGen Settings für microblaze MCS Teil 1]]
[[Datei:Ss coregen fitsettings.png|thumb|center|400px|CoreGen Settings für Fixed Timer]]
[[Datei:Ss coregen generated files.png|thumb|center|400px|Liste Generierter Dateien]]
[[Datei:Ss coregen info sdk.png|thumb|center|400px|Coregen Hinweis nächste Schritte]]
[[Datei:Ss coregen info tcl.png|thumb|center|400px|Coregen Hinweis Tcl-script]]
[[Datei:Ss tcl console.png|thumb|center|400px|Tcl-Console]]
==Vorbereitung Synthese mit MCS core==

==Top-Level==
<syntaxhighlight lang="verilog">
wire heartbeat_s;

wire [7:0] GPO1_s; //display data
wire [3:0] GPO2_s; //display control
wire [6:0] GPO3_s; // led's
wire [7:0] GPI1_s; //switches

wire FIT1_Toggle_s;

MikroBlaze_mcs microblaze_s3an_disp (
.Clk(clk), // input Clk
.Reset(rst), // input Reset
.FIT1_Toggle(FIT1_Toggle_s), // output fixed timer toggler (every 25M ticks)
.FIT2_Interrupt(/*FIT2_Interrupt*/), // UNUSED - output FIT2_Interrupt
.FIT2_Toggle(/*FIT2_Toggle*/), // UNUSED - output FIT2_Toggle
.PIT1_Interrupt(/*PIT1_Interrupt*/), // UNUSED - output PIT1_Interrupt
.PIT1_Toggle(/*PIT1_Toggle*/), // UNUSED - output PIT1_Toggle
.GPO1(GPO1_s), // output [7 : 0] GPO1
.GPO2(GPO2_s), // output [3 : 0] GPO2
.GPO3(GPO3_s), // output [6 : 0] GPO3
.GPI1(GPI1_s), // input [7 : 0] GPI1
.GPI1_Interrupt(/*GPI1_Interrupt*/), // UNUSED - output GPI1_Interrupt
.INTC_IRQ(/*INTC_IRQ*/) // UNUSED - output INTC_IRQ
);

always @(posedge clk)
begin

assign LCD_DB = GPO1_s[7:0];
assign LCD_RW = GPO2_s[0];
assign LCD_RS = GPO2_s[1];
assign LCD_E = GPO2_s[2];
end

heartbeat heartbeat(
.clk(clk),
.rst(rst),
.heartbeat_o(heartbeat_s)
);

assign LED[7] = heartbeat_s;
assign LED[6] = FIT1_Toggle_s;
assign LED[5:0] = GPO3_s[5:0];
</syntaxhighlight>

==FPGA Implementierung ==
Am besten den FPGA mit den MCS '''vor''' der Vorbereitung des SDK komplett implementieren und auf das board laden. Es müßen die LED's 7 und 8 mit jeweils eigene Frequenz blinken. Wenn nicht, dann ist bei der Generierung und Instanziierung des Cores ein Fehler unterlaufen.

Jetzt, falls noch nicht geöffnet, ein Tcl Fenster öffnen (ISE:View->Panels_Tcl console) dann erscheint unten eine schmale Zeile in der tcl Kommandos eingegeben werden können, die Ausgabe erscheint in dem Fenster darüber.

Jetzt das vom coregen erzeugte tcl script starten: source ../core/microblaze_mcs_setup.tcl . Dieses script fügt eine Option für das tool ''ngdbuild'' (für den Process "''Translate''" bei der Implementierung
hinzu. Zur Überprüfung die Optionen anzeigen lassen mit Mausklick rechts auf "Translate im Process-Fenster und "process properties" auswählen. Es findet sich jetzt in der Zeile "Other ... options" ein Eintrag beginnend mit "-bm" der auf ein ebenfalls von coregen erzeugtes .bmm file zeigt.

[[Datei:Ss after setup tcl.png|thumb|center|400px|Tcl-Console]]

Diese Datei am besten in einem Texteditor öffnen. wichtig ist hier der Pfad zu den RAM-Blöcken die das binary für den Softcore speichern werden.
Der Teil ganz links ist der in ersten Coregen fenster angegebene Instanz-name. Der muss auch mit dem Instanznamen im Top-file übereinstimmen, sonst
bricht Translate ab. Entfernt man die grad erwähnte -bm Option wieder aus den "Process Properties" läuft zwar der Schritt Translate und alle folgenden
durch, aber es wird Probleme bei "Vereinigung von Programm-binarie und FPGA bitfile geben -> die FPGA logic wird zwar funktionieren, aber es wird kein Programm
auf dem Softcore laufen.

=Generierung Compilerumgebung und microblaze-programm=
Für die folgenden Schritte ist das Software development Kit (SDK) zu starten,
das findet sich im Ordner EDK (Embedded Development Kit):

[[Datei:Ss programmmenu sdk.png|thumb|center|400px|Startmenu mit Xilinx-tools]]

Das SDK fragt beim Start nach einem Verzeichniss für den workspace.

Dannach erscheint beim ersten Start ein Welcome-Screen. Diesen an besten wegklicken da er
das fenster "project explorer" überdeckt. Jetzt müßen wir nacheinander 3 verschieden "typen" von "projekten" anlegen:
*Hardware Platform spezification - eine beschreibung des systems aus microblaze, Programmspeicher und Peripherie.
Diese benötigt die Infos aus dem Coregenlauf
*board support package - Header-dateien, linkerskripte mit kosntanten/ addressbereichen etc. passend zum mikrocontrollersystem
*C/C++projekt die leere C-datei für das eigentliche Programm

[[Datei:Sdk project wizards.png|thumb|center|400px|New -> Projects]]

==Hardware Platform Specification==
File -> new -> project -> Xilinx -> Hardware Platform Specification

Der Projectname erscheint dann im project explorer. Der Autor wählte zur besseren Unterscheidbarkeit
zu den anderen Projekttypen den suffix _hwp. in der Spalte hardwareproject-file ist das file aus den Coregen-lauf
anzugeben, es findet sich daher in dem Verzeichniss Core.

==Erstellung Hardware project==
[[Datei:Ss hardware palltform settings.png|400px|thumb|center]]
==Erstellung Board support package==
==Erstellung Programm==
[[Datei:Ss sdk cproject settings.png|400px|thumb|center]]
<syntaxhighlight lang="C">
#include <xparameters.h>
#include <xiomodule.h>
#include <stdbool.h>

#define LED_DELAY 100000

int main()
{
//instantiate IOs
XIOModule GPIO;

volatile u32 i = 0;

//initialize IOs
XIOModule_Initialize(&GPIO, XPAR_IOMODULE_0_DEVICE_ID);
XIOModule_Start(&GPIO);

//LED
bool led_on = false;
int run = 1;

for (;;)
{
if (led_on) {XIOModule_DiscreteWrite(&GPIO, 3,run);
if (run == 0x20) run = 1; else run *= 2;}
led_on = !led_on;
for(i=0;i < LED_DELAY; ++i);
}
}
</syntaxhighlight>

==Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei==
=Fehlersuche=
Wenn möglich auch die beiden Zwischenergebnisse ("Gesamtdesign ohne MCS-Core instanziierung" und "Mit Core aber ohne Programm" am Board testen. Nur so lassen sich Fehler auf die Schritte im workflow zurückführen.

Bei Änderungen am Core versagt gelegentlich das automatische Update von BPS etc.. Deshalb bei Coreänderungen die obsoleten Projekte (Hardware project, BSP und C-projekt) löschen und den workflow ab Schritt "tcl.script" wiederholen.

Fehlermeldungen in die Eingabemaske von google kopieren und nach Antworten bei Xilinx oder Internetforen suchen. Das führt bei den
oft verwirrenden Fehlermeldungen schnell zum Erfolg. So weist diese Meldung über Memory leaks:
[[Datei:Ss more ngdbuilt error.png|400px|thumb|center|ngdbuil error]]
eigentlich darauf hin, das der Instanzname des MCS-cores nicht stimmt. Der "Answer record" bei Xilinx http://www.xilinx.com/support/answers/51538.html erklärt wie man den korrekten Namen findet und in das BMM-file einträgt.

= Literatur =
* http://ece.wpi.edu/~rjduck/Microblaze%20MCS%20Tutorial%20v5.pdf - Eine in Englisch verfasste Anleitung zum Durchklicken.
Als Beispiel wird eine microblaze basierte UART-Verbindung zwischen PC und Nexsys2/3 board implementiert, verwendet wird die ISE 14.5.
* http://jimselectronicsblog.blogspot.de/2014/03/implementing-microblaze-mcs-on-papilio.html
Eine Englischsprachige Klickanleitung für das papilio-One board. Hier wird auch gezeigt wie UCF und top entity
mit dem PlanAHead tool angelegt wird. Die Screenshost sind recht gut kommentiert.
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/ds865_microblaze_mcs.pdf - XILINX DS865, die offizielle Beschreibung des Cores
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/pg116-microblaze-mcs.pdf - XILINX PG116, die offizielle Anleitung für Vivado
*http://www.xilinx.com/support/documentation/sw_manuals_j/xilinx14_5/pg048-microblaze-mcs.pdf - Xilinx PG048, die offizielle Anleitung für Vivado

Xilinx Microblaze MCS Workflow

2015-03-01T21:56:36Z

Fpgakuechle: +links zu Datenblatt, Implementierungsschritte genauer

''Gestartet von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-Feb-27 -> Material,Tips zur Fehlersuch und Screenshots sammeln

Der Artikel beschreibt wie der 32bit Softcore "microblaze MCS" in FPGA verwendet wird.
Verwendet wird dabei die kostenfrei verfügbare "leichtgewichtige" microblaze mcs Variante aus dem coregenerator (ab ISE 13.4 und Vivado) und nicht die kostenpflichtige EDK Variante.

=Ablauf=
Die Implementierung eines FPGA-Systems mit Softcore verläuft in folgenden Phasen:
*Erstellung des FPGA-drumherum (Top-level design, pinassigments) und FPGA ohne microblaze-Core implementieren
*Generierung des Softcore im CoreGenerator
*Instanziierung Core, Script für bm referenz ausführen und FPGA mit microblaze-Core implementieren
*Erstellung der compilerumgebung (board support package, libraries, linkerscript)
*Erstellung und Kompilierung des Programms
*Zusammenfügen programm-binarie mit FPGA-bitstream file

=Benötigte Software=
Es wird von Xilinx die FPGA Implementierungssoftware und das Software Development Kit (SDK)benötigt. Nutzer der FPGA's vor der 7Serie (bspw Spartan3-Großfamilie, Spartan-6, Virtex5/6) muüßen installieren:
*ISE Design Suite: WebPack edition
*ISE Design Suite: Embedded edition
(Siehe http://www.xilinx.com/products/design-tools/ise-design-suite.html )

Nutzer der neueren 7er Reihe dagegen benötigen:
*Vivado Design Suite Webpack edition
(Siehe http://www.xilinx.com/products/design-tools/vivado.html)

=Beispiel=
Es wird ein einfacher Core mit 3 Ausgangsport a 8,4 und 6 bit, einem Eingangsport zu 8bit sowie einem Festwert- (FIT) und ein programmierbarer Zähler (PIT) generiert.
[[Datei:Mcs block.png|thumb|center|400px|Blockdiagramm Beispiel]]

Neben dem Core ist ein weitere Zähler -''heartbeat''- im Design. Die drei Ausgangsporst sind für das verwendete S3AN Starterkit verbunden mit dem Datenbus und den Steuerleitung des alphanumerischen Displays und den 6 LED rechts. Die LED Nr 8 wird von dem FPGA-Logiccounter zum blinken gebracht, LED nummero 7 vom toggle-signal des Festwertcounter. Damit lassen sich 3 Implementierungsziele detektieren.
*Nix blinkt -> Totalversagen
*LED Nr. 8 blinkt -> FPGA erfolgreich geladen und gestartet
*LED 8 und 7 blinken: -> microblaze ist erfolgreich im FPGA implementiert, aber das Programm läuft nicht.
*Aktivität auf allen 8 LED's -> Perfekt

=SoftCore-Generierung und FPGA-Implementierung=
==CoreGen==

[[Datei:Ss coregen main.png|thumb|center|400px|CoreGen Auswahl microblaze MCS Core]]
[[Datei:Ss coregen generalsettings.png|thumb|center|400px|CoreGen Settings für microblaze MCS Teil 1]]
[[Datei:Ss coregen fitsettings.png|thumb|center|400px|CoreGen Settings für Fixed Timer]]
[[Datei:Ss coregen generated files.png|thumb|center|400px|Liste Generierter Dateien]]
[[Datei:Ss coregen info sdk.png|thumb|center|400px|Coregen Hinweis nächste Schritte]]
[[Datei:Ss coregen info tcl.png|thumb|center|400px|Coregen Hinweis Tcl-script]]
[[Datei:Ss tcl console.png|thumb|center|400px|Tcl-Console]]
==Vorbereitung Synthese mit MCS core==

==Top-Level==
<syntaxhighlight lang="verilog">
wire heartbeat_s;

wire [7:0] GPO1_s; //display data
wire [3:0] GPO2_s; //display control
wire [6:0] GPO3_s; // led's
wire [7:0] GPI1_s; //switches

wire FIT1_Toggle_s;

MikroBlaze_mcs microblaze_s3an_disp (
.Clk(clk), // input Clk
.Reset(rst), // input Reset
.FIT1_Toggle(FIT1_Toggle_s), // output fixed timer toggler (every 25M ticks)
.FIT2_Interrupt(/*FIT2_Interrupt*/), // UNUSED - output FIT2_Interrupt
.FIT2_Toggle(/*FIT2_Toggle*/), // UNUSED - output FIT2_Toggle
.PIT1_Interrupt(/*PIT1_Interrupt*/), // UNUSED - output PIT1_Interrupt
.PIT1_Toggle(/*PIT1_Toggle*/), // UNUSED - output PIT1_Toggle
.GPO1(GPO1_s), // output [7 : 0] GPO1
.GPO2(GPO2_s), // output [3 : 0] GPO2
.GPO3(GPO3_s), // output [6 : 0] GPO3
.GPI1(GPI1_s), // input [7 : 0] GPI1
.GPI1_Interrupt(/*GPI1_Interrupt*/), // UNUSED - output GPI1_Interrupt
.INTC_IRQ(/*INTC_IRQ*/) // UNUSED - output INTC_IRQ
);

always @(posedge clk)
begin

assign LCD_DB = GPO1_s[7:0];
assign LCD_RW = GPO2_s[0];
assign LCD_RS = GPO2_s[1];
assign LCD_E = GPO2_s[2];
end

heartbeat heartbeat(
.clk(clk),
.rst(rst),
.heartbeat_o(heartbeat_s)
);

assign LED[7] = heartbeat_s;
assign LED[6] = FIT1_Toggle_s;
assign LED[5:0] = GPO3_s[5:0];
</syntaxhighlight>

==FPGA Implementierung ==
Am besten den FPGA mit den MCS '''vor''' der Vorbereitung des SDK komplett implementieren und auf das board laden. Es müßen die LED's 7 und 8 mit jeweils eigene Frequenz blinken. Wenn nicht, dann ist bei der Generierung und Instanziierung des Cores ein Fehler unterlaufen.

Jetzt, falls noch nicht geöffnet, ein Tcl Fenster öffnen (ISE:View->Panels_Tcl console) dann erscheint unten eine schmale Zeile in der tcl Kommandos eingegeben werden können, die Ausgabe erscheint in dem Fenster darüber.

Jetzt das vom coregen erzeugte tcl script starten: source ../core/microblaze_mcs_setup.tcl . Dieses script fügt eine Option für das tool ''ngdbuild'' (für den Process "''Translate''" bei der Implementierung
hinzu. Zur Überprüfung die Optionen anzeigen lassen mit Mausklick rechts auf "Translate im Process-Fenster und "process properties" auswählen. Es findet sich jetzt in der Zeile "Other ... options" ein Eintrag beginnend mit "-bm" der auf ein ebenfalls von coregen erzeugtes .bmm file zeigt.

[[Datei:Ss after setup tcl.png|thumb|center|400px|Tcl-Console]]

Diese Datei am besten in einem Texteditor öffnen. wichtig ist hier der Pfad zu den RAM-Blöcken die das binary für den Softcore speichern werden.
Der Teil ganz links ist der in ersten Coregen fenster angegebene Instanz-name. Der muss auch mit dem Instanznamen im Top-file übereinstimmen, sonst
bricht Translate ab. Entfernt man die grad erwähnte -bm Option wieder aus den "Process Properties" läuft zwar der Schritt Translate und alle folgenden
durch, aber es wird Probleme bei "Vereinigung von Programm-binarie und FPGA bitfile geben -> die FPGA logic wird zwar funktionieren, aber es wird kein Programm
auf dem Softcore laufen.

=Generierung Compilerumgebung und microblaze-programm=
Für die folgenden Schritte ist das Software development Kit (SDK) zu starten,
das findet sich im Ordner EDK (Embedded Development Kit):

[[Datei:Ss programmmenu sdk.png|thumb|center|400px|Startmenu mit Xilinx-tools]]

Das SDK fragt beim Start nach einem Verzeichniss für den workspace.

Dannach erscheint beim ersten Start ein Welcome-Screen. Diesen an besten wegklicken da er
das fenster "project explorer" überdeckt. Jetzt müßen wir nacheinander 3 verschieden "typen" von "projekten" anlegen:
*Hardware Platform spezification - eine beschreibung des systems aus microblaze, Programmspeicher und Peripherie.
Diese benötigt die Infos aus dem Coregenlauf
*board support package - Header-dateien, linkerskripte mit kosntanten/ addressbereichen etc. passend zum mikrocontrollersystem
*C/C++projekt die leere C-datei für das eigentliche Programm

[[Datei:Sdk project wizards.png|thumb|center|400px|New -> Projects]]

==Hardware Platform Specification==
File -> new -> project -> Xilinx -> Hardware Platform Specification

Der Projectname erscheint dann im project explorer. Der Autor wählte zur besseren Unterscheidbarkeit
zu den anderen Projekttypen den suffix _hwp. in der Spalte hardwareproject-file ist das file aus den Coregen-lauf
anzugeben, es findet sich daher in dem Verzeichniss Core.

==Erstellung Hardware project==
[[Datei:Ss hardware palltform settings.png|400px|thumb|center]]
==Erstellung Board support package==
==Erstellung Programm==
[[Datei:Ss sdk cproject settings.png|400px|thumb|center]]
<syntaxhighlight lang="C">
#include <xparameters.h>
#include <xiomodule.h>
#include <stdbool.h>

#define LED_DELAY 100000

int main()
{
//instantiate IOs
XIOModule GPIO;

volatile u32 i = 0;

//initialize IOs
XIOModule_Initialize(&GPIO, XPAR_IOMODULE_0_DEVICE_ID);
XIOModule_Start(&GPIO);

//LED
bool led_on = false;
int run = 1;

for (;;)
{
if (led_on) {XIOModule_DiscreteWrite(&GPIO, 3,run);
if (run == 0x20) run = 1; else run *= 2;}
led_on = !led_on;
for(i=0;i < LED_DELAY; ++i);
}
}
</syntaxhighlight>

==Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei==
=Fehlersuche=
Wenn möglich auch die beiden Zwischenergebnisse ("Gesamtdesign ohne MCS-Core instanziierung" und "Mit Core aber ohne Programm" am Board testen. Nur so lassen sich Fehler auf die Schritte im workflow zurückführen.

Bei Änderungen am Core versagt gelegentlich das automatische Update von BPS etc.. Deshalb bei Coreänderungen die obsoleten Projekte (Hardware project, BSP und C-projekt) löschen und den workflow ab Schritt "tcl.script" wiederholen.

Fehlermeldungen in die Eingabemaske von google kopieren und nach Antworten bei Xilinx oder Internetforen suchen. Das führt bei den
oft verwirrenden Fehlermeldungen schnell zum Erfolg. So weist diese Meldung über Memory leaks:
[[Datei:Ss more ngdbuilt error.png|400px|thumb|center|ngdbuil error]]
eigentlich darauf hin, das der Instanzname des MCS-cores nicht stimmt. Der "Answer record" bei Xilinx http://www.xilinx.com/support/answers/51538.html erklärt wie man den korrekten Namen findet und in das BMM-file einträgt.

= Literatur =
* http://ece.wpi.edu/~rjduck/Microblaze%20MCS%20Tutorial%20v5.pdf - Eine in Englisch verfasste Anleitung zum Durchklicken.
Als Beispiel wird eine microblaze basierte UART-Verbindung zwischen PC und Nexsys2/3 board implementiert, verwendet wird die ISE 14.5.
* http://jimselectronicsblog.blogspot.de/2014/03/implementing-microblaze-mcs-on-papilio.html
Eine Englischsprachige Klickanleitung für das papilio-One board. Hier wird auch gezeigt wie UCF und top entity
mit dem PlanAHead tool angelegt wird. Die Screenshost sind recht gut kommentiert.
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx13_4/ds865_microblaze_mcs.pdf - XILINX DS865, die offizielle Beschreibung des Cores
* http://www.xilinx.com/support/documentation/sw_manuals/xilinx2013_3/pg116-microblaze-mcs.pdf - XILINX PG116, die offizielle Anleitung für Vivado
*http://www.xilinx.com/support/documentation/sw_manuals_j/xilinx14_5/pg048-microblaze-mcs.pdf - Xilinx PG048, die offizielle Anleitung für Vivado

Xilinx Microblaze MCS Workflow

2015-02-27T21:06:47Z

Fpgakuechle: +Blockbild und tips zur fehlersuche

''Gestartet von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-Feb-27 -> Material,Tips zur Fehlersuch und Screenshots sammeln

Der Artikel beschreibt wie der 32bit Softcore "microblaze MCS" in FPGA verwendet wird.
Verwendet wird dabei die kostenfrei verfügbare "leichtgewichtige" microblaze mcs Variante aus dem coregenerator (ab ISE 13.4 und Vivado) und nicht die kostenpflichtige EDK Variante.

=Ablauf=
Die Implementierung eines FPGA-Systems mit Softcore verläuft in folgenden Phasen:
*Generierung des Softcore im CoreGenerator
*Erstellung des FPGA-drumherum (Top-level design, pinassigments) und Instanziierung Core
*Erstellung der compilerumgebung (board support package, libraries, linkerscript)
*erstellung und Kompilierung des Programms
*Zusammenfügen programm-binarie mit FPGA-bitstream file

=Benötigte Software=
Es wird von Xilinx die FPGA Implementierungssoftware und das Software Development Kit (SDK)benötigt. Nutzer der FPGA's vor der 7Serie (bspw Spartan3-Großfamilie, Spartan-6, Virtex5/6) muüßen installieren:
*ISE Design Suite: WebPack edition
*ISE Design Suite: Embedded edition
(Siehe http://www.xilinx.com/products/design-tools/ise-design-suite.html )

Nutzer der neueren 7er Reihe dagegen benötigen:
*Vivado Design Suite Webpack edition
(Siehe http://www.xilinx.com/products/design-tools/vivado.html)

=Beispiel=
Es wird ein einfacher Core mit 3 Ausgangsport a 8,4 und 6 bit, einem Eingangsport zu 8bit sowie einem Festwert- (FIT) und ein programmierbarer Zähler (PIT) generiert.
[[Datei:Mcs block.png|thumb|center|400px|Blockdiagramm Beispiel]]

Neben dem Core ist ein weitere Zähler -''heartbeat''- im Design. Die drei Ausgangsporst sind für das verwendete S3AN Starterkit verbunden mit dem Datenbus und den Steuerleitung des alphanumerischen Displays und den 6 LED rechts. Die LED Nr 8 wird von dem FPGA-Logiccounter zum blinken gebracht, LED nummero 7 vom toggle-signal des Festwertcounter. Damit lassen sich 3 Implementierungsziele detektieren.
*Nix blinkt -> Totalversagen
*LED Nr. 8 blinkt -> FPGA erfolgreich geladen und gestartet
*LED 8 und 7 blinken: -> microblaze ist erfolgreich im FPGA implementiert, aber das Programm läuft nicht.
*Aktivität auf allen 8 LED's -> Perfekt

=SoftCore-Generierung und FPGA-Implementierung=
==CoreGen==

[[Datei:Ss coregen main.png|thumb|center|400px|CoreGen Auswahl microblaze MCS Core]]
[[Datei:Ss coregen generalsettings.png|thumb|center|400px|CoreGen Settings für microblaze MCS Teil 1]]
[[Datei:Ss coregen fitsettings.png|thumb|center|400px|CoreGen Settings für Fixed Timer]]
[[Datei:Ss coregen generated files.png|thumb|center|400px|Liste Generierter Dateien]]
[[Datei:Ss coregen info sdk.png|thumb|center|400px|Coregen Hinweis nächste Schritte]]
[[Datei:Ss coregen info tcl.png|thumb|center|400px|Coregen Hinweis Tcl-script]]
[[Datei:Ss tcl console.png|thumb|center|400px|Tcl-Console]]
==Vorbereitung Synthese mit MCS core==

==Top-Level==
<syntaxhighlight lang="verilog">
wire heartbeat_s;

wire [7:0] GPO1_s; //display data
wire [3:0] GPO2_s; //display control
wire [6:0] GPO3_s; // led's
wire [7:0] GPI1_s; //switches

wire FIT1_Toggle_s;

MikroBlaze_mcs microblaze_s3an_disp (
.Clk(clk), // input Clk
.Reset(rst), // input Reset
.FIT1_Toggle(FIT1_Toggle_s), // output fixed timer toggler (every 25M ticks)
.FIT2_Interrupt(/*FIT2_Interrupt*/), // UNUSED - output FIT2_Interrupt
.FIT2_Toggle(/*FIT2_Toggle*/), // UNUSED - output FIT2_Toggle
.PIT1_Interrupt(/*PIT1_Interrupt*/), // UNUSED - output PIT1_Interrupt
.PIT1_Toggle(/*PIT1_Toggle*/), // UNUSED - output PIT1_Toggle
.GPO1(GPO1_s), // output [7 : 0] GPO1
.GPO2(GPO2_s), // output [3 : 0] GPO2
.GPO3(GPO3_s), // output [6 : 0] GPO3
.GPI1(GPI1_s), // input [7 : 0] GPI1
.GPI1_Interrupt(/*GPI1_Interrupt*/), // UNUSED - output GPI1_Interrupt
.INTC_IRQ(/*INTC_IRQ*/) // UNUSED - output INTC_IRQ
);

always @(posedge clk)
begin

assign LCD_DB = GPO1_s[7:0];
assign LCD_RW = GPO2_s[0];
assign LCD_RS = GPO2_s[1];
assign LCD_E = GPO2_s[2];
end

heartbeat heartbeat(
.clk(clk),
.rst(rst),
.heartbeat_o(heartbeat_s)
);

assign LED[7] = heartbeat_s;
assign LED[6] = FIT1_Toggle_s;
assign LED[5:0] = GPO3_s[5:0];
</syntaxhighlight>

==FPGA Implementierung ==
Am besten den FPGA mit den MCS '''vor''' der Vorbereitung des SDK komplett implementieren und auf das board laden. Es müßen die LED's 7 und 8 mit jeweils eigene Frequenz blinken. Wenn nicht, dann ist bei der Generierung und Instanziierung des Cores ein Fehler unterlaufen.

Jetzt, falls noch nicht geöffnet, ein Tcl Fenster öffnen (ISE:View->Panels_Tcl console) dann erscheint unten eine schmale Zeile in der tcl Kommandos eingegeben werden können, die Ausgabe erscheint in dem Fenster darüber.

Jetzt das vom coregen erzeugte tcl script starten: source ../core/microblaze_mcs_setup.tcl . Dieses script fügt eine Option für das tool ''ngdbuild'' (für den Process "''Translate''" bei der Implementierung
hinzu. Zur Überprüfung die Optionen anzeigen lassen mit Mausklick rechts auf "Translate im Process-Fenster und "process properties" auswählen. Es findet sich jetzt in der Zeile "Other ... options" ein Eintrag beginnend mit "-bm" der auf ein ebenfalls von coregen erzeugtes .bmm file zeigt.

[[Datei:Ss after setup tcl.png|thumb|center|400px|Tcl-Console]]

Diese Datei am besten in einem Texteditor öffnen. wichtig ist hier der Pfad zu den RAM-Blöcken die das binary für den Softcore speichern werden.
Der Teil ganz links ist der in ersten Coregen fenster angegebene Instanz-name. Der muss auch mit dem Instanznamen im Top-file übereinstimmen, sonst
bricht Translate ab. Entfernt man die grad erwähnte -bm Option wieder aus den "Process Properties" läuft zwar der Schritt Translate und alle folgenden
durch, aber es wird Probleme bei "Vereinigung von Programm-binarie und FPGA bitfile geben -> die FPGA logic wird zwar funktionieren, aber es wird kein Programm
auf dem Softcore laufen.

=Generierung Compilerumgebung und microblaze-programm=
Für die folgenden Schritte ist das Software development Kit (SDK) zu starten,
das findet sich im Ordner EDK (Embedded Development Kit):

[[Datei:Ss programmmenu sdk.png|thumb|center|400px|Startmenu mit Xilinx-tools]]

Das SDK fragt beim Start nach einem Verzeichniss für den workspace.

Dannach erscheint beim ersten Start ein Welcome-Screen. Diesen an besten wegklicken da er
das fenster "project explorer" überdeckt. Jetzt müßen wir nacheinander 3 verschieden "typen" von "projekten" anlegen:
*Hardware Platform spezification - eine beschreibung des systems aus microblaze, Programmspeicher und Peripherie.
Diese benötigt die Infos aus dem Coregenlauf
*board support package - Header-dateien, linkerskripte mit kosntanten/ addressbereichen etc. passend zum mikrocontrollersystem
*C/C++projekt die leere C-datei für das eigentliche Programm

[[Datei:Sdk project wizards.png|thumb|center|400px|New -> Projects]]

==Hardware Platform Specification==
File -> new -> project -> Xilinx -> Hardware Platform Specification

Der Projectname erscheint dann im project explorer. Der Autor wählte zur besseren Unterscheidbarkeit
zu den anderen Projekttypen den suffix _hwp. in der Spalte hardwareproject-file ist das file aus den Coregen-lauf
anzugeben, es findet sich daher in dem Verzeichniss Core.

==Erstellung Hardware project==
[[Datei:Ss hardware palltform settings.png|400px|thumb|center]]
==Erstellung Board support package==
==Erstellung Programm==
[[Datei:Ss sdk cproject settings.png|400px|thumb|center]]
<syntaxhighlight lang="C">
#include <xparameters.h>
#include <xiomodule.h>
#include <stdbool.h>

#define LED_DELAY 100000

int main()
{
//instantiate IOs
XIOModule GPIO;

volatile u32 i = 0;

//initialize IOs
XIOModule_Initialize(&GPIO, XPAR_IOMODULE_0_DEVICE_ID);
XIOModule_Start(&GPIO);

//LED
bool led_on = false;
int run = 1;

for (;;)
{
if (led_on) {XIOModule_DiscreteWrite(&GPIO, 3,run);
if (run == 0x20) run = 1; else run *= 2;}
led_on = !led_on;
for(i=0;i < LED_DELAY; ++i);
}
}
</syntaxhighlight>

==Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei==
=Fehlersuche=
Wenn möglich auch die beiden Zwischenergebnisse ("Gesamtdesign ohne MCS-Core instanziierung" und "Mit Core aber ohne Programm" am Board testen. Nur so lassen sich Fehler auf die Schritte im workflow zurückführen.

Bei Änderungen am Core versagt gelegentlich das automatische Update von BPS etc.. Deshalb bei Coreänderungen die obsoleten Projekte (Hardware project, BSP und C-projekt) löschen und den workflow ab Schritt "tcl.script" wiederholen.

Fehlermeldungen in die Eingabemaske von google kopieren und nach Antworten bei Xilinx oder Internetforen suchen. Das führt bei den
oft verwirrenden Fehlermeldungen schnell zum Erfolg. So weist diese Meldung über Memory leaks:
[[Datei:Ss more ngdbuilt error.png|400px|thumb|center|ngdbuil error]]
eigentlich darauf hin, das der Instanzname des MCS-cores nicht stimmt. Der "Answer record" bei Xilinx http://www.xilinx.com/support/answers/51538.html erklärt wie man den korrekten Namen findet und in das BMM-file einträgt.

= Literatur =
* http://ece.wpi.edu/~rjduck/Microblaze%20MCS%20Tutorial%20v5.pdf - Eine in Englisch verfasste Anleitung zum Durchklicken.
Als Beispiel wird eine microblaze basierte UART-Verbindung zwischen PC und Nexsys2/3 board implementiert, verwendet wird die ISE 14.5.

* http://jimselectronicsblog.blogspot.de/2014/03/implementing-microblaze-mcs-on-papilio.html
Eine Englischsprachige Klickanleitung für das papilio-One board. Hier wird auch gezeigt wie UCF und top entity
mit dem PlanAHead tool angelegt wird. Die Screenshost sind recht gut kommentiert.

Datei:Ss more ngdbuilt error.png

2015-02-27T21:01:16Z

Fpgakuechle: Screenshoot Xilinx ngdbuilt error: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Screenshoot Xilinx ngdbuilt error: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Datei:Mcs block.png

2015-02-27T20:40:14Z

Fpgakuechle: block schematic of simple microblaze mcs implementation Own Work - Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/

block schematic of simple microblaze mcs implementation
Own Work - Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/

Xilinx Microblaze MCS Workflow

2015-02-26T21:59:49Z

Fpgakuechle: More Pics, less typos

''Gestartet von [[Benutzer:Fpgakuechle]] (Volker Urban)''

Status: 2015-Feb-26 -> Material und Screenshots sammeln

Der Artikel beschreibt wie der 32bit Softcore "microblaze MCS" in FPGA verwendet wird.
Verwendet wird dabei die kostenfrei verfügbare "leichtgewichtige" microblaze mcs Variante aus dem coregenerator (ab ISE 13.4 und Vivado) und nicht die kostenpflichtige EDK Variante.

=Ablauf=
Die Implementierung eines FPGA-Systems mit Softcore verläuft in folgenden Phasen:
*Generierung des Softcore im CoreGenerator
*Erstellung des FPGA-drumherum (Top-level design, pinassigments) und Instanziierung Core
*Erstellung der compilerumgebung (board support package, libraries, linkerscript)
*erstellung und Kompilierung des Programms
*Zusammenfügen programm-binarie mit FPGA-bitstream file

=Benötigte Software=
Es wird von Xilinx die FPGA Implementierungssoftware und das Software Development Kit (SDK)benötigt. Nutzer der FPGA's vor der 7Serie (bspw Spartan3-Großfamilie, Spartan-6, Virtex5/6) muüßen installieren:
*ISE Design Suite: WebPack edition
*ISE Design Suite: Embedded edition
(Siehe http://www.xilinx.com/products/design-tools/ise-design-suite.html )

Nutzer der neueren 7er Reihe dagegen benötigen:
*Vivado Design Suite Webpack edition
(Siehe http://www.xilinx.com/products/design-tools/vivado.html)

=Beispiel=
Es wird ein einfacher Core mit 3 Ausgangsport a 8,4 und 6 bit, einem Eingangsport zu 8bit sowie einem Festwert- und ein programmierbarer Zähler generiert.
Neben dem Core ist ein weitere Zähler im Design. Die drei Ausgangsport sind für das verwendete S3AN Starterkit verbunden mit dem Datenbus und den Steuerleitung des alphanumerischen Displays und den 6 LED rechts. Die LED Nr ( wird von dem FPGA-Logiccounter zum blinken gebracht, LED nummero 7 vom toggle-signal des Festwertcounter. damit lassen sich 3 Implementierungsziele detektieren.
*Nix blinkt -> Totalversagen
*LED Nr. 8 blinkt -> FPGA erfolgreich geladen und gestartet
*LED 8 und 7 blinken: -> microblaze ist erfolgreich im FPGA implementiert, aber das Programm läuft nicht.
*Aktivität auf allen 8 LED's -> Perfekt

=SoftCore-Generierung und FPGA-Implementierung=
==CoreGen==

[[Datei:Ss coregen main.png|thumb|center|400px|CoreGen Auswahl microblaze MCS Core]]
[[Datei:Ss coregen generalsettings.png|thumb|center|400px|CoreGen Settings für microblaze MCS Teil 1]]
[[Datei:Ss coregen fitsettings.png|thumb|center|400px|CoreGen Settings für Fixed Timer]]
[[Datei:Ss coregen generated files.png|thumb|center|400px|Liste Generierter Dateien]]
[[Datei:Ss coregen info sdk.png|thumb|center|400px|Coregen Hinweis nächste Schritte]]
[[Datei:Ss coregen info tcl.png|thumb|center|400px|Coregen Hinweis Tcl-script]]
[[Datei:Ss tcl console.png|thumb|center|400px|Tcl-Console]]
==Vorbereitung Synthese mit MCS core==

==Top-Level==
<syntaxhighlight lang="verilog">
wire heartbeat_s;

wire [7:0] GPO1_s; //display data
wire [3:0] GPO2_s; //display control
wire [6:0] GPO3_s; // led's
wire [7:0] GPI1_s; //switches

wire FIT1_Toggle_s;

MikroBlaze_mcs microblaze_s3an_disp (
.Clk(clk), // input Clk
.Reset(rst), // input Reset
.FIT1_Toggle(FIT1_Toggle_s), // output fixed timer toggler (every 25M ticks)
.FIT2_Interrupt(/*FIT2_Interrupt*/), // UNUSED - output FIT2_Interrupt
.FIT2_Toggle(/*FIT2_Toggle*/), // UNUSED - output FIT2_Toggle
.PIT1_Interrupt(/*PIT1_Interrupt*/), // UNUSED - output PIT1_Interrupt
.PIT1_Toggle(/*PIT1_Toggle*/), // UNUSED - output PIT1_Toggle
.GPO1(GPO1_s), // output [7 : 0] GPO1
.GPO2(GPO2_s), // output [3 : 0] GPO2
.GPO3(GPO3_s), // output [6 : 0] GPO3
.GPI1(GPI1_s), // input [7 : 0] GPI1
.GPI1_Interrupt(/*GPI1_Interrupt*/), // UNUSED - output GPI1_Interrupt
.INTC_IRQ(/*INTC_IRQ*/) // UNUSED - output INTC_IRQ
);

always @(posedge clk)
begin

assign LCD_DB = GPO1_s[7:0];
assign LCD_RW = GPO2_s[0];
assign LCD_RS = GPO2_s[1];
assign LCD_E = GPO2_s[2];
end

heartbeat heartbeat(
.clk(clk),
.rst(rst),
.heartbeat_o(heartbeat_s)
);

assign LED[7] = heartbeat_s;
assign LED[6] = FIT1_Toggle_s;
assign LED[5:0] = GPO3_s[5:0];
</syntaxhighlight>

==FPGA Implementierung ==
Jetzt, falls noch nicht geöffnet, ein Tcl Fenster öffnen (ISE:View->Panels_Tcl console) dann erscheint unten eine schmale Zeile in der tcl Kommandos eingegeben werden können, die Ausgabe erscheint in dem Fenster darüber.

Jetzt das vom coregen erzeugte tcl script starten: source ../core/microblaze_mcs_setup.tcl . Dieses script fügt eine Option für das tool ''ngdbuild'' (für den Process "''Translate''" bei der Implementierung
hinzu. Zur Überprüfung die Optionen anzeigen lassen mit Mausklick rechts auf "Translate im Process-Fenster und "process properties" auswählen. Es findet sich jetzt in der Zeile "Other ... options" ein Eintrag beginnend mit "-bm" der auf ein ebenfalls von coregen erzeugtes .bmm file zeigt.

[[Datei:Ss after setup tcl.png|thumb|center|400px|Tcl-Console]]

Diese Datei am besten in einem Texteditor öffnen. wichtig ist hier der Pfad zu den RAM-Blöcken die das binary für den Softcore speichern werden.
Der Teil ganz links ist der in ersten Coregen fenster angegebene Instanz-name. Der muss auch mit dem Instanznamen im Top-file übereinstimmen, sonst
bricht Translate ab. Entfernt man die grad erwähnte -bm Option wieder aus den "Process Properties" läuft zwar der Schritt Translate und alle folgenden
durch, aber es wird Probleme bei "Vereinigung von Programm-binarie und FPGA bitfile geben -> die FPGA logic wird zwar funktionieren, aber es wird kein Programm
auf dem Softcore laufen.

=Generierung Compilerumgebung und microblaze-programm=
Für die folgenden Schritte ist das Software development Kit (SDK) zu starten,
das findet sich im Ordner EDK (Embedded Development Kit):

[[Datei:Ss programmmenu sdk.png|thumb|center|400px|Startmenu mit Xilinx-tools]]

Das SDK fragt beim Start nach einem Verzeichniss für den workspace.

Dannach erscheint beim ersten Start ein Welcome-Screen. Diesen an besten wegklicken da er
das fenster "project explorer" überdeckt. Jetzt müßen wir nacheinander 3 verschieden "typen" von "projekten" anlegen:
*Hardware Platform spezification - eine beschreibung des systems aus microblaze, Programmspeicher und Peripherie.
Diese benötigt die Infos aus dem Coregenlauf
*board support package - Header-dateien, linkerskripte mit kosntanten/ addressbereichen etc. passend zum mikrocontrollersystem
*C/C++projekt die leere C-datei für das eigentliche Programm

[[Datei:Sdk project wizards.png|thumb|center|400px|New -> Projects]]

==Hardware Platform Specification==
File -> new -> project -> Xilinx -> Hardware Platform Specification

Der Projectname erscheint dann im project explorer. Der Autor wählte zur besseren Unterscheidbarkeit
zu den anderen Projekttypen den suffix _hwp. in der Spalte hardwareproject-file ist das file aus den Coregen-lauf
anzugeben, es findet sich daher in dem Verzeichniss Core.

==Erstellung Hardware project==
[[Datei:Ss hardware palltform settings.png|400px|thumb|center]]
==Erstellung Board support package==
==Erstellung Programm==
[[Datei:Ss sdk cproject settings.png|400px|thumb|center]]
<syntaxhighlight lang="C">
#include <xparameters.h>
#include <xiomodule.h>
#include <stdbool.h>

#define LED_DELAY 100000

int main()
{
//instantiate IOs
XIOModule GPIO;

volatile u32 i = 0;

//initialize IOs
XIOModule_Initialize(&GPIO, XPAR_IOMODULE_0_DEVICE_ID);
XIOModule_Start(&GPIO);

//LED
bool led_on = false;
int run = 1;

for (;;)
{
if (led_on) {XIOModule_DiscreteWrite(&GPIO, 3,run);
if (run == 0x20) run = 1; else run *= 2;}
led_on = !led_on;
for(i=0;i < LED_DELAY; ++i);
}
}
</syntaxhighlight>

==Zusammenfügen FPGA bitstream und Executable zur downladbaren Datei==

= Literatur =
* http://ece.wpi.edu/~rjduck/Microblaze%20MCS%20Tutorial%20v5.pdf - Eine in Englisch verfasste Anleitung zum Durchklicken.
Als Beispiel wird eine microblaze basierte UART-Verbindung zwischen PC und Nexsys2/3 board implementiert, verwendet wird die ISE 14.5.

* http://jimselectronicsblog.blogspot.de/2014/03/implementing-microblaze-mcs-on-papilio.html
Eine Englischsprachige Klickanleitung für das papilio-One board. Hier wird auch gezeigt wie UCF und top entity
mit dem PlanAHead tool angelegt wird. Die Screenshost sind recht gut kommentiert.

Datei:Ss after setup tcl.png

2015-02-26T21:57:52Z

Fpgakuechle: Screenshoot Xilinx Settings ngdbuilt: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Screenshoot Xilinx Settings ngdbuilt: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Datei:Ss tcl console.png

2015-02-26T21:53:33Z

Fpgakuechle: Screenshoot Xilinx Projektnavigator - Tcl-Console: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Screenshoot Xilinx Projektnavigator - Tcl-Console: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Datei:Ss coregen info tcl.png

2015-02-26T21:49:01Z

Fpgakuechle: Screenshoot Xilinx Coregen - Hinweis nach Generierung: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Screenshoot Xilinx Coregen - Hinweis nach Generierung: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Datei:Ss coregen info sdk.png

2015-02-26T21:46:08Z

Fpgakuechle: Screenshoot Xilinx Coregen - Hinweis nach der Genreierung: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)

Screenshoot Xilinx Coregen - Hinweis nach der Genreierung: Screenshoot taken by Volker Urban (fpgakuechle) licence: CC-BY 3.0 http://creativecommons.org/licenses/by/3.0/de/ in respect with regulations regarding software screenshots (here Xilinx Inc.)