FPGA Standards

Fpga K. schrieb:
> IMHO ist es trotzdem gut diese zu kennen um ein Gespür f. potentiales
> Fehlverhalten zu entwicklen.
Dabei ist es aber eigentlich auch wichtig, den Grund für so eine Regel 
zu kennen. Denn nur dann lässt sich einschätzen, ob und wie weit man 
davon abweichen könnte.
Ein krasser Fall von inkompetenter Regulierung ist z.B. in der PCI Spec 
zu finden. Dort wird in der Übersetzung die Clock Leitung bis auf den 
10tel mm spezifiziert. Im Original ist da dann aber "One and a half 
inch" zu lesen, was sich wesentlich entspannter anhört...

@ Lothar Miller (lkmiller) (Moderator) Benutzerseite

>> IMHO ist es trotzdem gut diese zu kennen um ein Gespür f. potentiales
>> Fehlverhalten zu entwicklen.

>Dabei ist es aber eigentlich auch wichtig, den Grund für so eine Regel
>zu kennen. Denn nur dann lässt sich einschätzen, ob und wie weit man
>davon abweichen könnte.
>Ein krasser Fall von inkompetenter Regulierung ist z.B. in der PCI Spec
>zu finden. Dort wird in der Übersetzung die Clock Leitung bis auf den
>10tel mm spezifiziert. Im Original ist da dann aber "One and a half
>inch" zu lesen, was sich wesentlich entspannter anhört...

EXAKT! Alles andere führt nur zu religiösen Dogmen!

FPGA-Ingenieur schrieb im Beitrag #4339534:
> 2) Wie vermeidet man geschaltete Takte, wenn man sie umschalten muss? -
> SS10
Hast du mal ein Beispiel, welche Takte du da unbedingt umschalten 
willst?

Nase schrieb:
> Und nein, "when others" hilft da gerade eben nicht...
Gegen eine amoklaufende FSM hilft nicht mal eine "safe FSM". Siehe den 
Beitrag "Re: VHDL - 'Warnung' vom Synthesetool (Synplify) unverständlich"

Fpga K. schrieb:
>> 3) Alle Register sollten eine reset-Steuerleitung haben? - SS14?  Wieso
>> das denn?
>
> Begründung dafür ist "last resort" also "letzter Ausweg". Mit externen
> reset ein ausser kontrolle geratenes system wieder auf den Pfad der
> Tugend zu führen ist eine bewährte Methode. Im Avionik-bereich rechnet
> man auch mit plötzlich kippenden FF ,das system muss dann immer noch in
> einen kontrollierbaren Zustand überführbar sein. Und mit der Festlegung
> "alle FF" am Reset macht man sich das Leben einfacher im Vergleich zu
> Einzelfall betrachtung an jedem FF.

Alles korrekt was Du sagst. Aber einen GANZ WICHTIGEN Fall hast Du nicht 
erwähnt:

Die DO-254 gilt auch für ASICs. Und bei ASICS bekommen die FFs beim 
PowerUp (zumindest theoretisch) undefinierte Werte (H/L).
Dann kann das IC aber auch in jedem Zustand, insbesondere auch in 
Unzulässigen hochkommen (z.B. Counter out-of-range).
Darum baut man eine POR-Schaltung (PowerOn reset) ein, die den 
Digitalteil im Reset hält solange VDD noch nicht OK ist.
Der POR braucht aber die Möglichkeit die FFs auf einen definierten Wert 
zu setzen (und dann synchron zum Takt) auch wieder loszulassen.

Ein weiterer Punkt ist die Testbarkeit von ASICs. Ohne steuerbaren nRST 
wird ein Scantest schwierig^^

Grüße
Andreas

Lothar M. schrieb:
> Nase schrieb:
>> Und nein, "when others" hilft da gerade eben nicht...
> Gegen eine amoklaufenden FSM hilft nicht mal eine "safe FSM". Siehe den

Sehr richtig, von daher sind die automatisierten safe implementation 
Strategien der Tools auch mit Vorsicht zu genießen. Was sich bewährt 
hat, sind redundante FMSs und eine Überwachungsschaltung, die bei einem 
Auseinanderlaufen binnen einen CC Alarm schlägt. Diese sind leicht zu 
implementieren, wenn man sie dupliziert. Einfach 3x parallel 
instanziieren. Der Sicherheitsgewinn ist nicht so leicht abzuschätzen, 
wenn man nicht eine detaillierte Fehleranalyse durchführt, aber von der 
Anschauung liegt sie statisch zwischen dem Faktor p * n und p hoch n.

Ich habe auch schon Schaltungen untersucht, die mit zeitversetzt 
ablaufenden FSMs arbeiten, die länger dauernde Störungen tolerieren aber 
deren Verarbeitungstempo ist auf 1(n+1) herabgesetzt, was für manche 
Applikationen nicht mehr geht.

Zu der DO-254:

Bei "Alle Register sollten eine reset-Steuerleitung haben" fällt mir 
wieder das Thema Testbarkeit ein. Damit ist es möglich, das Design in 
einen kontrollierten Zustand zu versetzen und schnell einen bestimmten 
Case anzufahren. Ob das praxistauglich ist, weiß ich nicht. Will man 
bestimmte Fälle nachstellen, bräuchte es eher definierte sets um so zu 
agieren, wie beim boundary scan un dann hätte man optimierte Testmengen, 
die nicht unbedingt von resetteten FFs ausgehen.


>Vorinitialisierte Signale verdecken in der Simu fehlende Reset's
Das ist richtig, allerdings ist der Wert begrenzt. Wenn man den 
undefined-Status wirklich zum Simulieren nutzen möchte, kann man dies 
auch zielführender tun, indem Signale zu Zeiten, in denen sie keine 
relevanten Daten tragen, auf X setzt. Ich nutze das gerne bei Bussen, 
die über Ena verfügen, damit man fehlerhaft eingetaktete Daten leichter 
sieht.

Diese Methodik widerspricht auch nicht dem Initialisieren. Im Gegenteil: 
Dadurch verhindert man, dass die Register irgendwie hochkommen und 
irgendwas machen, wenn von Außen der Reset nicht (rechtzeitig) kommt, 
weil dies der angenommene Fehler ist und sonst kein Reset exisitiert. In 
diesem Zusammenhang muss ich auch die Vorgaben, keinen internen 
selbstgenerierten Takt zu nutzen und keinen internen Reset zu verwenden, 
konterkarieren. Genau durch solche Mechanismen nämlich ist es möglich, 
dass der zentrale Baustein FPGA sauber und sicher anläuft und seine 
Ausgänge rasch bedient, während die steuernde Software, die ihn 
Konfigurieren soll, noch nicht einmal begonnen hat, zu booten. Hierbei 
ist festzustellen, dass die festverdrahtete SW im FPGA aufgrund 
geringerer Komplexität in der FMEA in 99% der Fälle als sicherer laufend 
heraus kommt, als uC-firmware.

Der andere Grund wurde schon genannt:

Initialisierungen beim Start sollten dann nicht verwendet werden, wenn 
das design mal in einen ASIC soll. Allerdings gäbe es diesbezüglich noch 
ganz andere und wichtigere Anforderungen, die erwähnenswert währen. Da 
unterscheiden sich FPGAs und ASICs eben und warum sollte man ein Feature 
nicht nutzen?

Nun kann man darüber streiten, welche Strategie die sicherere ist, bzw 
es bleibt Aufgabe des Planers, das zu untersuchen und individuell 
festzulegen.

Alles in Allem bleibt festzustellen, dass solche Dokumente immer ein 
Kompromiss darstellen, der aus einer Diskussion von Experten entstanden 
ist und somit sind diese nicht zwangsweise in sich konsistent und zu 
anderen parallelen Vorgaben in den Systemen passend.

Diese Überlegungen dürften der Grund gewesen sein, warum man bei 
modernen FPGAs eine CheckSumme über die Konfiguration bilden kann und 
diese auch zur Laufzeit prüfen kann. Die Config beim Laden wird ja 
ohnehin geprüft, damit gibt es aus sicherheitstechnischen Überlegungen 
heraus keinen Unterschied zwischen Landen und Resetten. Der eine kann 
nur statistisch eher schief gehen. Erkannt werden sie beide.

Ich sehe die Resetterei diesbezüglich durchaus zwiespältig. Was 
passiert, wenn ein Bit im Resetpfad unbemerkt kippt? Dann beginnen sich 
Teile der Schaltung unbemerkt falsch zu verhalten und ein asynchroner 
reset-Eingang von draussen ist da unschön. Ich hatte mal eine APP, da 
habe ich den nach dem Selbsttest des FPGAs und den Commit durch den 
Supervisor-Chip abgeschaltet. Laufen "tut" dann nur die interne und 
externe Funktionsüberwachung und Schnellabschaltung im Falle eines 
Fehlers. Wie lange der FPGA danach auf die Ersatzbank muss, um wieder zu 
laden und neu konfiguriert (im Bedarfsfall in den gewünchten Mode 
gesetzt werden kann) ist ziemlich Wurscht, weil die redundante Platine 
die Funktion des Systems steuert.

Man kann die FPGA-Sicherei bis dorthinaus treiben, aber wenn man 
realistisch denkt und ein wenig FMEA betreibt, kommt man schnell an den 
Punkt, dass man einige wenige Funktionen redudant auslegen muss und dann 
sehr schnell in Richtung Systemredundanz geht muss, weil andere Fehler 
viel wahrscheinlicher werden, als die angenommenen im FPGA. FPGAs sind 
durchaus recht betriebsstabil, wenn die Schaltung funktionell stimmt und 
wenn nicht, muss man an elektrische Themen, wie Spannungsredundanz 
denken, damit es keine brownouts oder ähnliches gibt.

Fpga K. schrieb:
> FPGA-Ingenieur schrieb im Beitrag #4339534:
>> 1) Was sind "mehrfache Wellenformen" - SS5?

ich denke, damit ist so was gemeint:

1

    t <= '1' AFTER 500 ns, '0' AFTER 1000 ns;

2

    t <= '0' AFTER 750 ns;

nicht ganz einfach zu erkennen, was da passieren soll (und zumindest für 
meinen Geschmack passiert auch was eher Unerwartetes).

Fpga K. schrieb:
> "Ungewollte" FSM-Zustände entstehen typischerweise beim Umschalten durch
> timing-Verletzung bspw. bei nicht einsynchronisierten Eingängen. Dann
> wechselt der Speicherwert eben nicht auf dem am D-Eingang. Das ist der
> fehlzustand den man durch einen Reset zu beheben versucht.

Das ist aber ein Fehler, den man durch Simulation und Design zu beheben 
versucht. Wenn das design nicht korrekt ist, ist der Not-Reset aber 
nicht das dedizierte Mittel der Wahl. Allerhöchstens kann und sollte man 
auf diese Weise den (sehr unwahrscheinlichen) Fall eines Fehlers infolge 
eines metastabilen Zustandes behandeln, der sich trotz der 
Synch-Schaltung hat fortsetzen können.
Allerdings kommt man angesichts der geringen Wahrscheinlichkeit dieses 
Fehlers (wir haben dies in diesem Forum ja bereits an mehreren Stellen 
hinreichend erörtert) sehr schnell dahin, dass das von mir weiter oben 
Gesagte hinsichtlich der FMEA greift: Die zusätzlich Resetlogik und 
deren Steuerung wirft mitunter mehr Fehlereinfluss auf, als durch die 
Wahrscheinlichkeit des Auftretens des ungewollten Zustandes gegeben ist 
und mit Blick auf den sehr geringen Vorteil des Resettens im Vergleich 
zum Neuladen ist die Resetlogik dann nicht gerechtfertigt. Entscheidend 
ist, ob es gelingt, die FPGA-Schaltung so zu designen, dass der Fehler 
auftreten und der FPGA weitermachen kann! Das ist sozusagen der 
"Bringer" und dies sowohl in Sachen Betriebssicherheit, als auch in 
Sachen Betriebsökonomie, also der Frage, ob eine Schaltung 
wirtschaftlich und funktionell gut arbeitet. Dies impliziert eine 
entsprechende Schaltung, die den Fehler erkennt. Mit der aber ist es 
auch sehr schnell möglich, den Fehler komplett zu eliminieren und nicht 
nur stumpf zu resetten.

Aber wenn es in einer Norm erstmal drin steht, steht es drin und muss so 
gebaut werden. :-(


Ich habe mich zu dem Thema der Sinnhaftigkeit einzelner Vorgaben in 
gewissen Normen schon an einigen Stellen geäußert und auch das eine oder 
andere dazu kritisch angemerkt, doch wird das von den "Experten" meist 
sehr schnell als Pamphlet eingestuft. Nun ja. Ich gehe da konform mit 
Lothars Satz zu der inkompetenten Regulierung. Man muss halt immer im 
Auge behalten, dass es nicht unbedingt die hochklassigen und praxisnahen 
Entwickler sind, die sich politisch in Normengremien engagieren und man 
weiß ja auch, wie es dazu geht, wenn solche Bibeln erstellt werden: 
Jeder hat eine eigene Meinung und niedergeschrieben wird nur, was die 
Mehrheit toleriert.


Besonders lustig finde ich das hier:

"Jede Firma oder project soll ihre eigenen Codestandards definieren"

Sehr gut. Jede Firma in der Luftfahrt programmiert, wie sie will. Das 
ist ein Satz, der garantiert noch reingerutscht ist, weil man sich nicht 
auf einen Standard einigen konnte, dabei wäre das doch genau die Lösung: 
Man gibt einen definierten Coding-Standard vor.

Fpga K. schrieb:
> Ich kann die Vehemenz der Ablehnung eines Gesamt-Resets nicht ganz
> nachvollziehen:

Stopp, es ging nicht um die Frage "reset einbauen" oder "keinen reset 
einbauen", sondern um "reset einbauen und damit schneller Wiederstart" 
oder im anderen Fall nur "Neuladen und damit langsamer Wiederstart".

Irgendeine Art von Initialisierung braucht es, natürlich.

Ferner geht es um die Frage, ob man pauschal "alle FFs resetbar halten" 
muss. Ich sage "nur die benötigten FFs müssen setzbar sein" und zwar mit 
der bereits geposteten Begründung des nicht rechtfertigbaren Aufwandes 
in Verbindung mit einer detaillierten FMEA:

Die Störung auf der Taktleitung, die Du als Beispiel bringst, kann genau 
so auf der Resetleitung sein und damit ist die Funktion zunächst 
ebenfalls dahin.

Und: Sie kann auf jeder Datenleitung sein. Und diese Wahrscheinlichkeit 
ist grösser und muss zuerst behandelt werden.

Nochmal mein Fazit: Sobald man diese unwahrscheinlichen Fehler angeht, 
die dazu führen, dass sich z.B. eine FSM dauerhaft verrennen kann oder 
es einen permanenten Fehler gibt, kommt man sofort dahin, dass man 
Überwacher einführen muss und wenn man weiter seamless function haben 
will, braucht es Systemredundanz und einen geordneten Wiederstart.

Jener "geordnete Wiederstart" impliziert aber setzbare FFs und zwar so, 
dass sie mit der vorher geretteten oder parallel existierenden 
Konfiguration geladen werden können.

Man fährt also sinnvollerweise in unkritischen Systemen ein einfaches 
unsicheres System mit nur dem an Reset was man braucht und in kritischen 
Anwendungen ein überwachtes System, das setzbar ist. Der Aufwand für die 
Überwacher und die Redundanz ist der eigentlich Grosse. Die paar 
Leitungen für das spiegeln eine Konfiguration und damit die 
Systemsetzbarkeit ist dagegen kaum noch mehr.

Die von der DO geforderte totale Resetbarkeit liegt damit irgendwo 
dazwischen, ist aber unnötig grösser und bringt effektiv für die 
Sicherheit nichts sowie auch für die Ökonomie nicht viel. Die Sicherheit 
müsste dann oben irgendwo in den SW-Ebenen hängen und die ist unsicherer 
und langsamer.

Ich behaupte, dass die Forderung nach einem vollständig resetbaren 
Design nicht zielführend und in Einzelfällen sogar kontaproduktiv ist.

Für mich hört sich das nach einem der vielen Passus an, die von 
SW-Leuten in die SPECs reingetrieben werden, weil sie Angst vor 
denkenden Funktionen in der ihnen unbekannten Hardware haben und lieber 
weiter oben alles unter Kontrolle haben wollen. Dabei weiß ein jeder 
dass dort der große Mist passiert :-)

Fpga K. schrieb:
> Ich würde diesen Taster aber nie durch eine funkgesteuerte Steckerleiste
> ersetzen  -
Deine Überlegungen führen bei mir zu dem Ergebnis, die Hardware 
intelligent zu machen, selbstüberwachende, selbststabilisierende und 
selbstresettende Mechanismen einzubauen, statt die Funktion 
bereitzustellen und es weiter oben machen zu lassen. Weiter unten in der 
Komponente ist das System einfacher.

Was ist denn, wenn die edle SW, die diesen totalen Reset ausführen soll, 
nicht mitbekommt, dass sie es tun müsste? Die Informationen, wann dies 
zu tun wäre, liegen im FPGA komplett vor.

Fpga K. schrieb:
> Für das "kontraproduktiv " und "nicht zielführend" brauch ich konkrete
> beispiele von Dir um diese Aussage nachvollziehen zu können.

Das Ziel eines Designs ist dessen sichere Funktion und auch dessen 
wirksame Funktion. Man muss also nicht nur dafür sorgen, dass es 
ruckzuck abschaltet, wenn es gefährlich wird, sondern eben möglichst 
auch nicht ungewollt abschaltet. Gerade die Resetleitung oder auch eine 
Konfigurationsleitung ist ein Problem, wenn sie von einer SW 
kontrolliert werden, weil diese an viele Stellen ins Design gehen.

ISt Alteras DEV_CLRn vergleichbar mit Xilinx GSR im STARTUPE2?

Weltbester FPGA-Pongo schrieb im Beitrag #5559546:
> gerade die Tage wurde beschlossen,
> einen Reset nicht einzubauen,

Von wem wurde das Beschlossen, und für wen?

Weltbester FPGA-Pongo schrieb im Beitrag #5559546:
> in Verbindung mit einer eventuell zuckenden Leitung von Außen die FMEA
> ergeben hat, dass das schlechter ist.
Man sollte den externen Reset, wenn man ihn denn verwendet, schon 
wenigstens einsynchronisieren und auf Plausibilität prüfen 
(Mindestpulsdauer...). Dann wird der Asynchrone Reset automatisch wieder 
zum synchronen Reset und das Design kommt beim Deaktivieren des Resets 
wenigstens anständig ans Laufen...

Weltbester FPGA-Pongo schrieb im Beitrag #5560350:
> Von der obersten Heeresleitung nach Studium der FMEA und Timing
> Stresstestes.
Wurde der gesamte Reset nicht eingebaut oder nur der asynchrone nicht?


Fpga K. schrieb:
> In der DO ist der reset so begründet das er ein non-responsive also
> nicht reagierendes/Kommunizierendes System wieder zurückholen soll also
> im gewissen Sinne einsatzbereit machen soll. Mglw impliziert das das das
> System aber dabei nicht unbedingt ausgelöst werden soll.

Ich halte diesen Sachverhalt für durchaus ambivalent, d.h. es kann ein 
Vorteil und auch Nachteil sein, asynchrone Resetoptionen zu haben.

Altera betont diesen Sachverhalt ganz sicher deshalb, weil sie das von 
Haus aus integriert haben und damit einen Marktvorteil besitzen. Ob man 
das zur Notwendigkeit erheben sollte, bleibt dahingestellt. Richtig ist, 
damit sie damit während der Designphase ASIC-kompatibler sind, die oft 
einen Reset brauchen.

Umgekehrt lässt Xilinx bekanntlich keine Gelegenheit aus, festzustellen, 
daß solche Resets gar nicht nötig sind, weil sie ja die gelobten 
INIT-Werte haben. Durch die "asynchronous" to "synchronous" Option kann 
man das auch bedingt automatisieren, wenn  es sein muss, also ein 
"Altera-Design in ein Xilinx-Design überführen", wie sich mal ein FAE 
ausdrückte.

Ich finde asynchrone Resets nicht zielführend und verwende sie nur, wenn 
das Design mal in einen ASIC wandern soll.


Blechbieger schrieb:
> Altera FPGA haben einen optionalen DEV_CLRn mit "A logic low on the
> DEV_CLRn pin clears all of the device's registers." . Spricht etwas
> dagegen das als Reset zu benutzen? Hätte den Vorteil das es dedizierte
> Resourcen und nicht das normale Routing verwendet.
Ganz klar, ja!  Das exakt ist ein Teil der Xilinx-Argumentation. Altera 
wiederum stellt es so dar, dass diese Reset-HW drin ist und die 
programmierbare Logik nicht belastet. Die Argumentation ist in etwa die 
der Autohersteller, die einen Kleinlaster mit und ohne Ladefläche 
verkaufen und den jeweils anderen beschuldigen etwas nicht / überflüssig 
zu haben.

Fpga K. schrieb:
> Dem schließe ich mich gern an, die Beiträge haben auch mir gezeigt das
> der Lerneffekt nicht im Sturen Befolgung/Ablehnung von Richtlinien liegt
> sondern in der Diskussion und im Nachdenken darüber.

Man darf halt nicht vergessen, dass Richtlinien immer das Ergebnis von 
Kompromissen in Gremien sind, wo sich Leute tummeln, die schon seit 
Jahren nicht mehr viel mit Entwicklung zu tun haben und auch nicht 
notwendigerweise auf dem neuesten Stand sind. Zudem spielen da viele 
subjektive Punkte eine Rolle. Je nachdem, was einer im Fokus hat(te), 
sind andere oder gegenteilige Arbeitsweisen angezeigt und/oder 
Vorschriften überholt. Oft sind sie unzeitgemäß oder sie haben bestimmte 
Sachverhalte nicht berücksichtigt.

Die Vorgaben, welche z.B. die DO-254 macht, scheinen mir z.T. auch aus 
dem ASIC-Bereich zu kommen und sind nicht direkt auf FPGAs übertragbar, 
wie z.B. den Aspekt "Vermeide tiefe kombinatorische Verschaltungen 
(SS19)". Da habe ich mal was zu geschrieben. Manche Sachen sind auch 
durch die Tools und die Technik längst überholt und können als Fehler 
gar nicht mehr gemacht werden. Insofern ist das aus meiner Sicht nicht 
der Standard der FPGA-Entwicklung.

Andererseits war die DO-254 meines Wissens das erste Papier, welches 
überhaupt mal Vorgaben für VHDL gemacht hat, während in anderen Branchen 
noch die Vorstellung herrschte, dass man Software-Validierung umgehen 
könne, wenn man FSM ins FPGA gestopft hat und damit in Hardware. Habe 
auch das mal sinngemäß in den Artikel eingefügt.

Mit Bezug auf das thread-Thema ist das m.E. aber keineswegs erschöpfend 
beantwortet. In der DO ist hauptsächlich Prozessdenken etabliert worden 
und weniger Coding-Vorgaben. Da wurde gerade mal das Allerschlimmste 
aufs Korn genommen. In der DO fehlen mir z.B. klare "Do"s.!

Was dort dort hingegen als "DO-nt's" angegeben ist, sind n.m.E. Dinge, 
die ein normaler Entwickler eh nur einbaut oder praktiziert, wenn er 
zwei Weißbier intus- oder was Falsches geraucht hat, wie die 
unvollständigen Pfade, widersprüchliche Zuweisungen und das liebe alte 
Problem der doppelten Signalzuweisungen, was oft die Folge davon ist, 
wenn C-Programmierer die FPGAs bauen, weil sie signaltechnisch von vorne 
her- und zeitgesteuert denken.

Jürgen S. schrieb:
> Manche Sachen sind auch
> durch die Tools und die Technik längst überholt und können als Fehler
> gar nicht mehr gemacht werden. Insofern ist das aus meiner Sicht nicht
> der Standard der FPGA-Entwicklung.

"Richtige" Flugzeuge bzw. deren Komponenten haben aber nicht den 
Lebenszyklus aktueller Konsumelektronik. Von der Bauelementeauswahl bis 
zu einem zertifizierungsfähigen Hardware- und Softwarestand vergehen 
etliche Jahre. Und für die verschiedenen Zertifizierungen selbst noch 
einmal weitere Jahre. Bei einem Produkt eines meiner Kunden dauerte der 
letzte Schritt zwölf Jahre. Und danach beginnt ja erst das Rollout.

Wenn also später für eine verhältnismäßig junge Komponente eine kleine 
Überarbeitung oder Erweiterung ansteht, bedeutet das, ggf. auf einem 
zehn bis zwanzig Jahre alten Entwicklungsstand aufzusetzen. Wenn man 
sich zu dem Zeitpunkt keine Neuzertifizierung der Toolchain antun 
möchte, staubt man eben die alte Sun-Workstation oder VAX noch mal ab...

> Andererseits war die DO-254 meines Wissens das erste Papier, welches
> überhaupt mal Vorgaben für VHDL gemacht hat, während in anderen Branchen
> noch die Vorstellung herrschte, dass man Software-Validierung umgehen
> könne, wenn man FSM ins FPGA gestopft hat und damit in Hardware. Habe
> auch das mal sinngemäß in den Artikel eingefügt.

Diese Sichtweise bestand bei einigen Entwicklern auch noch im Jahr 2012.

Fpga K. schrieb:
> -denkt man die Logik (Störmöglichkeit beseitigen indem man
> Eingangsleitung kappt) konsequent weiter, müsste man alle
> Eingangsleitungen entfernen um das System sicher zu machen -> was keinen
> Input kriegt kann auch nicht falsch reagieren ....

Ich plädiere schon seit Jahren dafür, Rettungsringe aus massivem, 
salzwasserfestem Edelstahl herzustellen, da solch ein Ring sowohl recht 
feuerfest wäre und gegenüber einem hohlen Ring den Vorteil besäße, dass 
eine Beschädigung nicht zu einem Wassereintritt führen könnte. Solch ein 
massiver metallischer Ring wäre auch deutlich witterungsbeständiger. 
Ebenso ließe er sich auch einfach am Schiff festschweißen und somit 
gegen Diebstahl und Vandalismus sichern.

Für eher niedrige Boote (z.B. Ruderboote, Tretboote) eignen sich auch 
Rettungsringe aus Naturstein.

dzopf schrieb:
> In diesem Sinne: Wäre es nicht sinnvoll, die Do's und Dont's
> für moderne FPGA-Entwicklungsansätze unter verschiedenen
> Aspekten mal niederzuschreiben?
Das wird ja getan. Zumindest firmenintern gibt es meistens Richtlinien 
und wenn nicht, werden sie erlassen. Ich habe da auch selbst über die 
Jahre einiges zusammengestellt, was auf die Anforderungen der 
SOC-Entwicklung, Test und Validierung mit ModelSIM Rücksicht und auf die 
Möglichkeiten der tools Rücksicht nimmt. Einige Kunden haben das auch so 
übernommen.

Andreas S. schrieb:
> Diese Sichtweise bestand bei einigen Entwicklern auch noch im Jahr 2012.
In der Medizintechnik ist man so seit 2008 auf den Trichter gekommen, 
dass die Argumentationsweise nicht so richtig schlüssig ist. Noch 2005 
habe ich an einem Design mitentwickelt, welches ausdrücklich deshalb in 
einen ASIC ging, damit es keine Software ist.

Andreas S. schrieb:
> Wenn also später für eine verhältnismäßig junge Komponente eine kleine
> Überarbeitung oder Erweiterung ansteht,
.. hat man aber das Problem, offizell "nach dem Stand der Technik" 
entwickeln zu müssen und kommt um die Nutzung aktueller Tools nicht rum 
und die erzeugen das Problem der tool validierung, genau wie die 
Methoden selber. Ich kenne eigentlich kaum Fälle, in denen man es sich 
so einfach machen konnte. Im Gegenteil: Ich habe regelmäißg Projekte, in 
denen alte Design erweitert und in dem Zuge nachdokumentiert und nach 
aktuellem Standard entwickelt werden.

Fpga K. schrieb:
> -denkt man die Logik (Störmöglichkeit beseitigen indem man
> Eingangsleitung kappt) konsequent weiter, müsste man alle
> Eingangsleitungen entfernen um das System sicher zu machen -> was keinen
> Input kriegt kann auch nicht falsch reagieren ..
Das ist aber eine durchaus sinnvolle Forderung. Wenn man annimmt, dass 
keine Leitung sich was einfangen kann, dann braucht man keine Strahlen- 
oder Störbetrachtung zu machen. Ich verweise dazu auf diesen thread:
Beitrag "Re: kritische I2C-Kommunikation in gestörten Bereichen"

Eine Leitung, die nicht benötigt wird oder deren Nutzen geringer ist, 
als der Schaden, fällt in der Beurteilung immer nach hinten. Zumindest 
wird in der Medizintechnik so gedacht. Aber möglicherweise ist das ja 
der Grund, warum viele Diagnostikgeräte prima arbeiten, während Drohnen 
und A400M nicht fliegen :-)

Andreas S. schrieb:
> Ich plädiere schon seit Jahren dafür, Rettungsringe aus massivem,
> salzwasserfestem Edelstahl herzustellen,
Das ist ganz sicher schon irgendwo angedacht worden und wegen der hohen 
Kosten verworfen worden. Außerdem: Rettungsringe sind "Wegwerfartikel" 
:-)

Nochmals speziell zu Resets:

Ich persönlich bevorzuge und empfehle bei FPGAs auch die Nutzung des 
echten HW-Resets des FPGAs, soweit er nötig und auch nutzbar ist. Das 
aber ist er meistens nicht, denn die FFs resetten bei den meisten FPGAs 
immer auf den selben Wert, also die Null und das führt dazu, dass man 
die Logik in der Beschreibung partiell drehen muss. Ich habe das bei 
einem Design mal näher untersucht und allein diese Effekte fressen den 
Resourcen-Vorteil des asynch Reset schnell wieder auf. Dann kommt das, 
was Lothar sagte: Man muss ja den FPGA mal wieder starten und das geht 
nur synchron zu einer PLL, zu einem externen System, zu einer CPU oder 
was auch immer. Es braucht also irgend ein Art des synchronen Loslassens 
und anders als bei ASICs ist das Routing bei FPGAs kritischer und kann 
nicht beliebig optimiert werden. Einen ASIC-Pfad kann man mit 
Baumverdrahtung und Verzögerungen so balancieren, dass in der Tat an 
jeder Ecke des Designs eine Flanke auf wenige Bruchteile einer 
Nanosekunde exakt kommt - inklusve aller Produktions- und 
Betriebsparameterschwankungen.

Ich plädiere daher bei FPGAs für einen synchronen Reset. Der Nachteil 
der möglichen verzögerten Reaktion und Auszeit durch Wiederladen ist 
eigentlich keiner, denn der FPGA ist zum "Start der Schaltung" ohnehin 
nicht anwesend. Da muss man sich also so oder so was überlegen. Für den 
normalen Betriebsfall ergibt sich eine ähnliche Argumentation, die ich 
an anderer Stelle schon verfasst habe:

Es gibt neben dem Problem des Reset-Loslassens noch einen wichtigen 
Punkt: In den sicherheitskritischen Anwendungen haben FPGAs oft eine 
wichtige Aufgabe und diese eine Weile zu pausieren, weil Panikartik der 
Reset ausgelöst wurde, ist nicht der Weissheit letzter Schluss.

Schlauer ist es, die FSMs und Module im FPGA so zu gestalten, dass sie 
sich selber überwachen und auf andere Module und deren Stati einklinken 
können. Das bedeutet, dass sie die Randbedinungen des richtigen 
Funktionierens kennen und bei Verlassen dieses ranges oder einem fremd 
getriggerten Panikresets rasch wieder richtig arbeiten können, während 
sie dazwischen neutral arbeiten.

Das bekommt man aber mit einem pauschalen Nullzustand nicht hin sondern 
bedarf genauer an die Situation angepasster Definitionen, was im 
Einzelfall "neutral" ist. Statt alle Problemfälle auf einen Reset zu 
projizieren brauchten die Module ein dediziertes Anlaufverhalten mit 
einer moderierten Ausgabe von Daten sowie Bekanntgabe ihres Zustands im 
System.

Digitalfilter in Audoschaltungen, PDM-Modulatoren für Leistungstreiber 
oder Ansteuerschaltungen für MOS-FET-Brücken und praktisch alle 
Überwachungsschaltungen sowie vor allem Regelsysteme sind solche 
Kandidaten.

Es muss dazu wie oben angedeutet auch eine passende analoge Beschaltung 
geben, die den Folgeschaltungen die Pegel vorgibt, wenn der FPGA "noch 
nicht da ist" sowie eine Mimik, die es erlaubt, dass der FPGA "bootet" 
und sich nach und nach der Ausgänge und damit der Schaltung bemächtigt.

Mit einem Reset-Puls kann man dann z.B. die Steuerung nullen und das 
Ausgangsmodul wieder in den Anlauffall setzen, von wo aus es seine 
Filter neu einstellt und dann, wenn alles eingeschwungen- und die 
korrekte Funktion der Ausgangsschaltung im Selbsttest ermittelt wurde, 
so langsam wieder beginnt, diesen zu treiben.

So etwas braucht man und wenn man das hat, dann reicht oft auch ein 
total boot als Ersatz für einen Reset, weil man den dann nur alle 
Schaltjahre verwenden muss. Im umgekehrten Fall kann man sich dann das 
synchrone Reset komplett sparen.

Ich habe als Konsequenz in meinem Schaltungen praktisch immer einen 
Reset-Eingang drin (und zwar einen synchronen) sehe aber zu, dass ich 
den nicht verwende, wenn nicht nötig, sondern stelle sicher, dass die 
Schaltung wie o.a. einschwingt und gfs. so lange auch einen neutralen, 
plausiblen Ausgangswert liefert, wenn "Müll" nicht tolerabel ist.

Man kann so etwas ja auch mit einem globalen Überwacher leisten, der von 
allen Modulen die ready-Signale checkt und erst dann die physischen 
Ausgänge passend freigibt, wenn die TRUE liefern.

Diese Funktion ist es dann auch, welche die beroffenen Ausgänge direkt 
abhängt oder neutral bedient, wenn was Kritisches passiert. Einen 
PDM-Modulator schaltet man z.B. nicht einfach auf 0 sondern lässt ihn 
auf 50% laufen, damit der analoge Rest der Baugruppe mitsamt der Filter 
in einen neutralen Zustand läuft und sofort startfähig ist, wenn der 
Modulator wieder plausible Daten bekommt.

So vermeidet man nicht nur knackende Lautsprecher, wenn das 
Decoderdatenstrom aussetzt, oder knallende / zuckende Motoren, wenn die 
Steuerung einen Looping macht, sondern auch ein chaotischen Einregeln 
von Steuerungen selbst, wenn von vorne die Sensordaten mal ausfallen 
waren.

Solche Methoden sehe ich als integralen Anteil funktioneller Sicherheit, 
vermisse sie aber teilweise immer noch in den einschlägigen Normen.

Jürgen S. schrieb:
> Das wird ja getan. Zumindest firmenintern gibt es meistens Richtlinien
> und wenn nicht, werden sie erlassen.

Das ist aber eine Neuerung und sicher auch nur in manchen Firmen der 
Fall. Viele Entwickler programmieren wild drauf los. Früher war es noch 
schlimmer, als heute. Es hat kaum jemand auf Standarde geachtet. Auch 
nicht an Universitäten! Ein schönes Beispiel ist das Terror-Design hier:

http://www1.cs.columbia.edu/~sedwards/classes/2004/4840/reports/terrormouse.pdf

Mehr als 3 Takte in einem design, owohl unnötig, dafür fehlende 
Synchronisationsstufen zwischen den Domänen und einen ganzen Haufen an 
"gated Clocks".

Die Ausarbeitung von allgemeinen Richtlinien und Standards ist dringend 
erforderlich, damit nicht jeder Hinz und Kunz im großen Stil FPGAs 
zusammenschustert, die andere dann in den Wahnsinn treiben, wenn sie es 
richten sollen. Ich hatte erst vor Wochen mit einer Angelegenheit zu 
tun, wo ein Fahrzeug andauernd depanniert werden musste, weil der FPGA 
irgendwann spontan die Kommunikation versagte. Tatverdächtig für die 
Entwicklung des Bausteins war ein Herr der zuvor 3 Jahre am QEC 
programmiert hat und sich das VHDL selber beigebracht hat. Die 
Autodidakten der Institute liefern die Schlimmsten Sachen, die man sich 
vorstellen kann.

Fpga K. schrieb:
> In der Medizintechnik wird aber auch darauf geachtet, das nachgelagerte
> Designschritte wie FMEA der elektrischen Realisierung nicht die Arbeit
> der vorhergehende Designteams wie Systemarchitektur über den Haufen
> werfen.

Schon richtig, wenn aber die FMEA als vorgelagerter Schritt im Rahmen 
des Systemdesigns liefert, dass eine bestimmte Funktion mehr Gefahr, als 
Nutzen bringt, weil der Nutzen nur alle paar Jubeljahre mal eintritt und 
zudem auch anders erledigt werden kann, dann wird die Funktion erst gar 
nicht als Anforderung zur Umsetzung fürs Realisationsteam aufgenommen 
:-)

Und bei den Resets ist es so, dass die so gut wie nie gebraucht werden, 
weil man man den FPGA im Falle eines Falles auch einfach neu booten 
kann. Das muss man auch können und einen dazu sicheren Betriebsfall 
gestalten, in welchem das möglich ist, weil eben ein FPGA ausfallen kann 
und booten muss. Dann braucht es oft keinen extra Reset, der die gleiche 
Funktion nochmals zur Verfügung stellt, aber permanent die 
Angriffsfläche erhöht. Wenn nicht unbedingt Teile des FPGAs 
"weiterleben" müssen und andere Teile resettet werden sollen, lässt man 
den am besten weg. Resetbar und autoresetfähig sollte man z.B. 
Interface-Controller machen, die falsch angesteuert werden können sowie 
die Schaltungsteile, die sich von Außen was einfangen können. Für dieses 
Teile liefert die FMEA nämlich regelmäßig ein "pro Reset".


>Auf diese Weise könnte man auch Rettungsrutschen im Flugzeug oder
>Airbags im Auto wegdiskutieren - könnte ja fehlausgelöst werden und
>beschädigt dann das ganze schöne Gerät.
Nein, ganz sicher nicht, weil schon eine oberflächliche Betrachtung 
bereits das Ergebnis liefert, dass solche Rutschen 1) klaren Nutzen 
haben, 2) anders nicht darstellbar sind und 3) wenig Risiko bringen. Das 
Ergebnis einer Risikountersuchung wäre in jedem Fall ganz klar "pro".

Es geht ja um die Fälle, bei denen die Abwägung ein "Contra" ergibt und 
da gibt es gerade in der Medizintechnik durchaus einige.

Fpga K. schrieb:
> Auf diese Weise könnte man auch Rettungsrutschen im Flugzeug oder
> Airbags im Auto wegdiskutieren - könnte ja fehlausgelöst werden und
> beschädigt dann das ganze schöne Gerät.

Gerade im Flugzeugbau werden ja auch viele Dinge "wegdiskutiert", weil 
entweder deren Nutzen geringer als der hierdurch zuvermeidende Schaden 
wäre oder weil von ihnen selbst ein Risiko ausginge. Beispiele:

- Normale, große Passagierflugzeuge sind nicht mit Fallschirmen 
ausgestattet.

- Es gibt ebenso keinen Rettungsschirm für das gesamte Flug oder die
  Passagierkabine.

Beide entsprechenden Ideen wurden und werden von Laien auch immer wieder 
hervorgekramt und klingen auf den ersten Blick so, als könnte damit die 
Sicherheit erhöht werden. Im Detail stellt sich dann aber heraus, dass 
sie nicht nur völlig nutzlos wären, sondern die mit dem Einsatz 
verbundenen Vorkehrungen als Flugzeug als ganzes unsicherer machen 
würden.

Andreas S. schrieb:
> - Normale, große Passagierflugzeuge sind nicht mit Fallschirmen
> ausgestattet.

Wäre interessant, warum eigentlich nicht?

Technologie kann es nicht sein: Fallschirme unter dmm Sitz oder über dem 
Kopf wären sicher zu machen, wenn die Flugzeuge 20cm höher gebaut 
würden. Masse kann es nicht sein: Die wiegen nicht viel. Man käme also 
mit etwas mehr Treibstoff für die Masse und den Luftwiderstand raus. 
Risiken fürs Flugzeug sehe ich nicht.

Traut man den Passagieren den Absprung nicht zu?
Wird das Landen als zu gefährlich angesehen?
Weil es meist aufs Wasser geht?
Will man die Passagiere nicht einsammeln?

Oder sagt mal sich einfach, es passiert zu selten?

Ich meine, Schiffe haben ja auch Rettungsboote und Schwimmwesten und da 
passiert nicht viel.

Wie sieht es aus mit Schwimmwesten in Flugzeugen? Wozu sollen die sein, 
wenn man aus 10.000m runterfällt? Fallschirme wären praktischer.

Für den Sprung aus dem Flugzeug braucht man Zeit. Also wenn viele Leute 
springen sollen. Und das Flugzeug muss einigermaßen ruhig fliegen. Es 
gibt wohl kaum echte Notsituationen bei denen man weiß, dass man 
abstürzen wird und trotzdem noch eine Zeit lang ruhig fliegen kann. Das 
ist entweder wahnsinnig hektisch oder man ahnt noch nichts oder etwas 
ist kaputt und der Flug deutlich unruhig.
Schwimmwesten sind für den Fall, dass man doch irgendwie auf dem Wasser 
gelandet ist.

Björn schrieb:
> Komm, wenn gewaltige Transportmaschinen abheben, kann das auch eine 747.

Eine gewaltige Transportmaschine muss aber auch keine 500 Fallschirme 
umherfliegen und die Besatzung weiß, wie man da sinnvoll evakuiert.

https://de.wikipedia.org/wiki/Flugzeugabsturz

Such' dir einen aus, bei dem in ausreichender Flughöhe (4000 - 1000 m), 
ausreichend niedriger Geschwindigkeit (< 200 km/h) und ausreichend 
stabiler Fluglage (geradeaus auf gleichbleibender Höhe) "ausreichend 
viele" Passagiere genügend Zeit gehabt hätten, mit einigermassen 
realistischer Überlebenschance auszusteigen.

Das ist m.E. völlig unrealistisch.

Können wir bitte die Flugzeugdisskusion hier sein lassen? Meine Güte, 
wenn euch das Thema interessiert, macht nen Offtopic Thread auf!

FPGA-Ingenieur schrieb:
> Nach Durchsicht es Artikels VHDL Code Style und DO-254 muss ich
> feststellen, dass da einige Unklarheiten bleiben.
>
> 2) Wie vermeidet man geschaltete Takte, wenn man sie umschalten muss? -
> SS10
>
Man kann es nicht immer, also macht man es so gut es geht. Aber 
geschaltete Signale bergen immer das Problem, dass man Spikes generiert 
und wenn diese auf einen Takteingang gehen, hat man ein Problem, welches 
man monatelang suchen kann. Die müssen also alle von Hand darauf 
überprüft werden, dass sie garantiert Spikefrei sind, was natürlich 
schwieriger wird, je mehr man davon hat.

> 3) Alle Register sollten eine reset-Steuerleitung haben? - SS14?  Wieso
> das denn?
Spätestens, wenn man eine Gate Level Simulation macht, wird man merken, 
wie sinnvoll sowas ist. Und bevor man zumindest ein ASIC abgibt, sollte 
man mal eine Gate-Level Simulation angestartet haben, um z. B. zu sehen, 
ob die Spikes da sind, die man oben eingebaut hat oder ob das Ding 
überhaupt losrennt. Sowas kann dann zum Ende des Designs, wenn die Zeit 
alle ist und der Abgabetermin drängt, noch mal so richtig ärgerlich 
werden.

>
> 4) Warum dürfen die Initialisierungen bei Start (z.B.) bei Xilinx nicht
> verwendet werden? - SS16
>
> Ist das nicht ein wenig realitätsfremd?
Siehe 3. Bei reinen FPGAs kein Problem, aber spätestens, wenn man die 
Familie wechselt oder auf ein ASIC geht, kann das wichtig werden.


Gruß
Axel

Duke Scarring schrieb:
> Von meinen Designs ist noch keines in einen ASIC gewandert und eine
> Gatelevelsimulation lieft das letzte Mal vor 10 Jahren, um
> Synthesefehler zu finden...

Das ist das, was ich weiter oben schon anklingen ließ: FPGA-Design und 
ASIC-Design driften stark auseinander, weil FPGAs immer stärker 
spezialisiert sind und das gilt auch für die Nieschen, in die die 
Designs vom Compiler hinein optimiert werden. Geht man z.B. her und 
sieht pauschal resets und Rücklesbarkeit für FFs vor, so verbleiben die 
zwanghaft im Design. Andernfalls werden sie gfs. umoptimiert und fallen 
weg und zwar bei FPGAs wiederum anders, als bei ASICs:

Aufgrund der grundsätzlich freien Plazierbarkeit der FFs in ASICs werden 
da immer weniger FFs benötigt, als in FPGAs, wo feste Strukturen 
vorliegen, man von einer Ecke des Designs (PLL) in eine andere muss 
(RAM) und wo noch allgemeine Verdrahtung getrieben werden muss. Da ist 
das Wegoptimieren von FFs und Umbalancieren durchaus essenziell. Man 
darf nie ausser Acht lassen, dass das Register, wie ich es in VHDL sehe, 
so in keinster Weise im FPGA exisitiert. Dessen Funktion wird gfs. über 
das Areal verteilt.

Bei ASICs besteht zudem das Problem einer gewissen Design- und 
Produktionsunsicherheit, weil speziell im fulls custom design etwas raus 
kommt, was nicht getestet wurde. Daher muss man gfs Exemplartests 
durchführen, was wiederum einen Testpfad erfordert, um die 
kombinatorischen Strukturen zu testen. Dieser wiederum erzwingt eine 
genügende Dichte von FFs zwischen der Kombinatorik und einen Zugang zu 
denselben, wenn keine scan path FFs Verwendung finden.

Insgesamt muss man sich vornehmen, einen Punkt im Design zu definieren, 
ab dem entschieden wird, ob das Design portierbar sein soll und wohin 
und ob dafür entwickelt werden soll, oder nicht.
Dementsprechend müssen die Anforderungen formuliert werden.

Wenn dann ein FPGA eine bestimmte Resource anbietet, wird man sie auch 
nutzen. Sei es eine bestimmte DSP-Funktion, Logik im RAM, eine PLL, 
SERDES oder was auch immer. Und demgemäß wird man auch die INITs beim 
Xilinx nutzen, wenn man sie hat.

Eine allgemeine Spec im Tenor einer DO müsste entsprechend divergiert 
werden.

Wie gesagt gibt es da Dinge, die ich bezüglich FPGA nicht so ganz teile.

Z.B würde ich die Forderung nach dem Vermeiden unverbundener 
Schaltungslogik nicht so hoch hängen. Ich habe öfters etwas Test und 
Interpretationslogik im Design, die mir bei der Simulation etwas 
anzeigen, was mir nur in der Designphase hilft. Das wird dann von der 
Synthese freundlicherweise entfernt. Auf die Weise muss ich nicht alles 
per Generate von einer simulierbaren Version abhängig machen.

M. W. schrieb:
> Ich meine, wenn die Synthese es nicht schafft,
> eine Beschreibung richtig zu übersetzen, wie soll sie dann eine
> Simulation dafür erzeugen, bei der das auffällt?

Du kannst die Simulation der Verhaltensebene mit der Simulation auf 
Gateebene vergleichen. Wenn die nicht übereinstimmen, dann hat die 
Synthese Unsinn erzeugt.