mikrocontroller.net

Forum: FPGA, VHDL & Co. FPGA Standards


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: FPGA-Ingenieur (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Nach Durchsicht es Artikels VHDL Code Style und DO-254 muss ich 
feststellen, dass da einige Unklarheiten bleiben.

1) Was sind "mehrfache Wellenformen" - SS5?

2) Wie vermeidet man geschaltete Takte, wenn man sie umschalten muss? - 
SS10

3) Alle Register sollten eine reset-Steuerleitung haben? - SS14?  Wieso 
das denn?

4) Warum dürfen die Initialisierungen bei Start (z.B.) bei Xilinx nicht 
verwendet werden? - SS16

Ist das nicht ein wenig realitätsfremd?

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
FPGA-Ingenieur schrieb im Beitrag #4339534:

Zwei Fragen kann ich gleich beantworten, die anderen übers Wochenede

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

> 4) Warum dürfen die Initialisierungen bei Start (z.B.) bei Xilinx nicht
> verwendet werden? - SS16

Vorinitialisierte Signale verdecken in der Simu fehlende Reset's und 
PowerUp Initialisierung. O-Ton: "It is desireable to allow uninitialized 
signals to simulate as unknown to detect and evaluate the X-propagation 
through the design. This may reflect actual design issues in Hardware".
Ferner hat man dann 2 Urzustände des Systems:
1) nach (externen) Reset
2) nach Konfiguration
Das widerspricht dem Streben nach einem design mit möglichst geringer 
Komplexität.


> Ist das nicht ein wenig realitätsfremd?

Was meinst Du jetzt mit realitätsfremd? Übertriebende Vorsicht? Dieser 
Guide wurde für Avionik also fliegendes Gerät aufgestellt. Da ist dieses 
Sicherheitsdenken IMHO völlig berechtigt. Die DO-254 lässt bei der 
Anwendung aber auch Spielraum.  Man muß der Zertifizierungsbehörde 
gegenüber nachweisen, das man diese Punkte in Betracht gezogen hat. Wenn 
durch fehlfunktionen keine Gefährdung entsteht dann ist es OK. Oder man 
hat eine andere "Sicherung" (Redundante System).


Im Consumerbereich geht man relaxter mit diesen Designregeln um. IMHO 
ist es trotzdem gut diese zu kennen um ein Gespür f. potentiales 
Fehlverhalten zu entwicklen. und die Wahrscheinlichkeit für Designfehler 
von beginn an klein zu halten (Oder zumindest es im Anforderungsfall zu 
können).

MfG,

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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...

Autor: Falk B. (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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!

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> 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.

Ja, sobald man erkannt hat was man eigentlich tut - darf man  alles tun.

Zu den erwähnten Richtlinien gibt es im Orginal auch Begründungen. Da 
aber die Übersetzung von Guidelines nicht gerade meine 
Lieblingsbeschäftigung ist gibt es im Artikel noch große Lücken. Nach 
gezielten Nachfragen fülle ich diese, so sollte jetzt:

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

klarer sein. Im Grund geht es um die Nichtverwendung einer nicht 
synthesefähigen Syntax, die warum auch immer "multiple Waveforms" 
genannt wird. Gut für Simulations-Stimuli, schlecht für Synthese.

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

ein standard der nicht internationale Einheit verwendet - ja nix ist 
perfect. Bei Standards zählt imho eh immer nur die Orginalsprache und 
meist gibt es auch noch eine ellenlange Terminology dazu. Was heisst 
"Optional", was bedeutet "must"  was "reset release" was "active 
state",...

MfG,

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> 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?

In der Begründung wird "Power save at battery-power devices" als 
akzeptierte Grund für Clock gating genannt aber nicht ohne genaue 
Analyse auf seiteneffekte zu verlangen und für FPGA's ohne Clock gating 
unterstützung darf man es dann doch nicht:

"Clock gating designs for FPGA should not be allowed if the targeted 
FPGA device does not contain special purpose-built clock gating 
circuitry in silicon."


MfG,

: Bearbeitet durch User
Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Fpga K. schrieb:
> klarer sein. Im Grund geht es um die Nichtverwendung einer nicht
> synthesefähigen Syntax, die warum auch immer "multiple Waveforms"
> genannt wird. Gut für Simulations-Stimuli, schlecht für Synthese.

Heisst dass, dass diese Vorgaben nur für den Synthesefähigen Code gelten 
und nicht für den Rest der Testbenches, Modelle etc?

Autor: Nase (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.
Man könnte auch argumentieren, dass das FPGA selbst einen Reset-Eingang 
hat: Neu laden.

Und gerade das "plötzlich kippende FF" ist eigentlich ein Paradebeispiel 
für ein Problem, das man mit VHDL-Regeln allein* praktisch nicht 
beherrschen kann.
Schon bei einem einfachen Zustandsautomaten kann man mit VHDL alleine 
nicht mehr verhindern, dass ein FF im Zustandsregister umkippt und der 
Automat dann hängen bleibt. Schlimmstenfalls, weil das heiße FF bei 
einer One-Hot-Kodierung umfällt.

Und nein, "when others" hilft da gerade eben nicht...

(*) Synthesewerkzeug-spezifische Attribute usw. nehme ich dabei jetzt 
aus.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

: Bearbeitet durch Moderator
Autor: Nase (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Nase schrieb:
>> Und nein, "when others" hilft da gerade eben nicht...
> Gegen eine amoklaufenden FSM hilft nicht mal eine "safe FSM".
Aber das ist ja eigentlich das Problem.
Man kann manchen Synthesewerkzeugen so ein "safe-impl" ankreuzen, das 
hilft statistisch messbar. Aber es hilft ja nur an einer bestimmten 
Stelle: FSMs.

Entweder setzt man wenigstens voraus, dass das FPGA in sich konsistent 
arbeitet, also nicht willkürlich FF umfallen.
Oder man darf das FPGA "allein" nicht einsetzen?

Autor: Nase (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nase schrieb:
> es hilft

Also "helfen" im Sinne von der Automat hängt sich zumindest nicht auf. 
Konsistent und in einem sinnvollen Zustand ist er danach natürlich 
trotzdem nicht.

Autor: Andreas H. (ahz)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Markus W. schrieb:
> Fpga K. schrieb:
>> klarer sein. Im Grund geht es um die Nichtverwendung einer nicht
>> synthesefähigen Syntax, die warum auch immer "multiple Waveforms"
>> genannt wird. Gut für Simulations-Stimuli, schlecht für Synthese.
>
> Heisst dass, dass diese Vorgaben nur für den Synthesefähigen Code gelten
> und nicht für den Rest der Testbenches, Modelle etc?

Die designrules sind in 4 Kategorien unterteilt, die Gruppe bestimmt den 
Prefix der regel hier SS-10 also SS

SS steht für Safe synthesis, die Regeln dieser Kategorie decken den 
Bereich der Synthese ab.

Die anderen Kategorien sind:

*CP - Coding Practice
*CDC - Clock domain Crossing
*DR - Codereview

Der Artikel VHDL Code Style und DO-254 folgt dieser Unterteilung.

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Nase schrieb:
> Man könnte auch argumentieren, dass das FPGA selbst einen Reset-Eingang
> hat: Neu laden.

Ja, aber Neuladen und Reset ist nicht dasselbe, auch wenn sie in den 
selben Zustand münden sollten. Für den Reset brauchts es nur das 
auslösende Reset-Pin. Für eine Neukonfiguration die gesamte 
Konfigurationsmimik wie im einfachsten Fall Config-ROM oder im 
komplexeren Fall eine CPU die über JTAG den FPGA konfiguriert. Da kann 
eine Menge schief gehen. Ausserdem dauert eine Neukonfiguration deutlich 
länger (Millionen takte) als ein reset (ein Takt). Und ob ein system 
nach mikro- oder ganzenen sekunden wieder steuerbar ist kann im Flug 
entscheidend sein.

Für die meisten Anwendungsfälle ist Neu-konfiguration sicher ein 
ausreichend zuverlässiger "Reset". Für das letzte Quentchen Sicherheit 
ist reset des FPGA per Pin m.E. zuverlässiger und weniger komplex als 
"System - Neu Konfiguration".

Wobei es natürlich auch FPGA's gibt bei denen die Konfiguration was 
nicht von einem Reset zu unterscheiden ist, bspw. Spartan 3AN oder 
flashbasierte Baureihen.

MfG,

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Nase (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Fpga K. schrieb:
> Nase schrieb:
>> Man könnte auch argumentieren, dass das FPGA selbst einen Reset-Eingang
>> hat: Neu laden.
>
> Ja, aber Neuladen und Reset ist nicht dasselbe, auch wenn sie in den
> selben Zustand münden sollten. Für den Reset brauchts es nur das
> auslösende Reset-Pin. Für eine Neukonfiguration die gesamte
> Konfigurationsmimik wie im einfachsten Fall Config-ROM oder im
> komplexeren Fall eine CPU die über JTAG den FPGA konfiguriert. Da kann
> eine Menge schief gehen. Ausserdem dauert eine Neukonfiguration deutlich
> länger (Millionen takte) als ein reset (ein Takt). Und ob ein system
> nach mikro- oder ganzenen sekunden wieder steuerbar ist kann im Flug
> entscheidend sein.

Naja, jetzt schießt sich die Argumentation aber stellenweise selbst in 
den Fuß:
Auf der einen Seite lieber einen eigenen Reset(-Pin) in der Logik 
ausformulieren. Damit kann man eine entlaufene Schaltung wieder 
definiert einfangen - ok. Zum Beispiel, wenn mal ein FF umfällt.

Was passiert denn, wenn nicht eines der FF umfällt, die du formuliert 
hast (a.k.a. inferiert via process o.ä.), sondern eines, welches eine 
Ressource im FPGA steuert? Übliche SRAM-basierte FPGAs bestehen ja im 
Prinzip nur aus FF/LUT. Mit einem ausformulierten Reset ist das nicht 
mehr hinzukriegen.

Da hilft praktisch nur neu laden.

Das relativiert sich natürlich wieder, wenns ins ASIC geht, wo diese 
FF/LUT fest eingegossen werden.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus F. (mfro)
Datum:

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

ich denke, damit ist so was gemeint:
    t <= '1' AFTER 500 ns, '0' AFTER 1000 ns;
    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).

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nase schrieb:

> Was passiert denn, wenn nicht eines der FF umfällt, die du formuliert
> hast (a.k.a. inferiert via process o.ä.), sondern eines, welches eine
> Ressource im FPGA steuert? Übliche SRAM-basierte FPGAs bestehen ja im
> Prinzip nur aus FF/LUT. Mit einem ausformulierten Reset ist das nicht
> mehr hinzukriegen.

Bei spontanenen Umfall des Speicherwerts einer Steuer-SRAM-Zelle hast Du 
sicher recht, da hilft kein Design-Reset. Das ist aber nicht das 
typische Fehlermodell was man ausrastenden FSM modellhaft unterlegt. Das 
habe ich oben verwechselt:

Fpga K. schrieb:
> Im Avionik-bereich rechnet
> man auch mit plötzlich kippenden FF ,das system muss dann immer noch in
> einen kontrollierbaren Zustand überführbar sein.

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

Die Steuer SRAM's des FPGA schalten nach der Konfiguration nicht mehr, 
da besteht die Gefahr von timing Verletzungen nicht.

MfG,

Autor: Nase (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fpga K. schrieb:
> [...] Das ist der
> fehlzustand den man durch einen Reset zu beheben versucht.
Ok, das kann ich nachvollziehen.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Murphies Law in der ursprünglichen Formulierung:

„Wenn es mehrere Möglichkeiten gibt, eine Aufgabe zu erledigen, und eine 
davon in einer Katastrophe endet oder sonstwie unerwünschte Konsequenzen 
nach sich zieht, dann wird es jemand genau so machen.“

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


Jürgen S. schrieb:
> 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.

Der Not-Reset soll aber gerade in den Fällen die Steuerbarkeit des 
Systems wiederherstellen die man wegen menschlicher fehlbarkeit nicht 
wegdesignt hat resp. konnte. Shit happens - Störspitze auf der 
Taktleitung wegen Power surge beim Turbinenstart, niedrige Corespannung 
bei gealterten Kapazitäten und was nach Murphies gesetz sonst noch so 
schief gehen.

> Wenn das design nicht korrekt ist, ist der Not-Reset aber
> nicht das dedizierte Mittel der Wahl.

Hun ja wenn man vor den Notfall wüsste wo das Design inkorrekt ist dann 
hätte man das design vor Eintreten des Notfall korregiert.

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

Ja genau das sind erhöhte Sichherheitsanfordeungen: den 
unwahrscheinlichen Fall noch unwahrscheinlicher machen und wenn er 
trotzdem eintritt gewappnet sein.

Ich kann die Vehemenz der Ablehnung eines Gesamt-Resets nicht ganz 
nachvollziehen:
FF mit synchronen Reset bauen ist das kleine Einmals des 
FPGA-Entwicklers, wer das nicht kann hat in diesem Job nichts zu suchen. 
Nachweisführung das alle FF zurückgesetzt werden können sollte man auch 
erlernt haben: Log-files analysieren, constraints setzen, mit skript die 
Netzliste auf die passenden FF-Makros parsen, Simulation ... Zur ve

Die Nachteile eine Resetnetzwerkes mit highen FAN-Out wie mglw. 
schlechteres timing sind beherschbar. Erst recht unter der Prämisse 
"Safety first" -> lieber mit 100 MHz sicher beherrschbar als mit 500MHz 
Systenneustarts im ungünstigsten Zeitpunkt.

--

Bezüglich der Bewertung Pin-Reset versus neu-Konfiguration mache ich 
folgenden Vergleich: Not-Aus-Schalter im Labor - die gelben Kästen mit 
dem Roten "Panik"-Knopf. Muss man extra einen Installateur kommen lassen 
und sieht im Hi-Tech Büro irgendwie antiquiert aus.

Ich würde diesen Taster aber nie durch eine funkgesteuerte Steckerleiste 
ersetzen  - selbst wenn es gestattet wäre und ich den 
Not-Aus-Panik-button in Form der Fernsteuerung direkt am Labortisch 
hätte. Murphies Law -> wenn der Schalter verzögert reagiert sobald ein 
anders gerät auf der selben Frequenz aktiv ist oder oder oder wird im 
Notfall genau das eintreten.
Die gelben Monsterknöpfen sind gegen diesen Unbill der Hitech immun.

MfG,

: Bearbeitet durch User
Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Jürgen S. schrieb:

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

Hier braucht es einige Hintergrundwissen um das Fehlen von Technischen 
Vorgaben in der DO-254 zu verstehen: Grundidee der DO-254 ist 
Qualitätssicherung - wie gestalte ich die Entwicklung so das das Produkt 
an Ende des Entwicklungsprozess das Vertrauen in diesen Funktion 
gerechtfertigt.

13-978-1-4822-0605-0 S. 1 Google-books: 
https://books.google.de/books?id=QmlYBQAAQBAJ&pg=PR4&lpg=PR4&dq=13-978-1-4822-0605-0&source=bl&ots=7Ur4QBQXbc&sig=LVoQO1mvEu70qRDVF6GZ4g51iig&hl=de&sa=X&ved=0CB4Q6AEwAGoVChMIvrfz_NyByQIVwd9yCh3S0Agv#v=onepage&q=13-978-1-4822-0605-0&f=false

"DO-254 is not ... an engineering cookbook. .. It does not prescribe the 
design characteristics, nor does it contains design standards. Instead 
it provides guidance on the processes and methodologies that should 
applied in the development and verification of electronic hardware to 
achieve an acceptable level of confidence that the end hardware 
functions correctly ..."

In diesem Sinne ist auch DR-13 "Stelle Firmenspezifische Namensstandard 
sicher  - Jede Firma oder project soll ihre eigenen Codestandards 
definieren und durchsetzen " zu verstehen. ->

Wichtig für erfolgreiche Reviews und gegenseitige Code-durchsichten ist 
das diese einem konsisten Standard hindichtlich der identifier etc. 
genügen. Wie der nun konkret ausieht - ob beispw. Ausgange mit präfix 
O_* oder suffix *_out gekennzeichnet werden und wie aus dem Filenamen 
auf den Inhalt (bspw [entity]_[architechture].vhd ) geschlossen wird ist 
wurscht, wichtig es gibt einen Standard innerhalb der Projektmitarbeiter 
auf den man sich verlassen kann. Und damit bspw. Boeing in den USA eine 
sichere Hardware baut ist es nicht notwendig das sie genau den selben 
Coding style verwendet wie bspw. Antonow in der Ukraine - Hauptsache, es 
gibt einen mit dem das jeweilige Team vernünftig arbeiten kann.

MfG,

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> 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".

OK, das hatte ich anders aufgefasst, danke für die Klarstellung.

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

Die DO-254 fordert keine totale Resetbarkeit, da muss ich die Passage 
die  als "Warning" klassifiziert ist - wohl klarer übersetzen:
 Avoid unresetable Reegisters (SS14) - all registers should have a reset 
control

This ... is used as the last resort recovery mechanism for a 
non-responsive device.

...
There are occasional situations where the registers are not implemented 
with a reset (e.g. synchronizer flops and scan chains). In these cases 
the applicant should document and justify each exception. ...


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

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

MfG,

Autor: FPGA-Ingenieur (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ausdrücklichen Dank für die Aufklärung an alle Beteiligten. Besonders 
auch an FPGA-Küchle für den Engagement bei der Überarbeitung des 
Artikels.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
FPGA-Ingenieur schrieb im Beitrag #4344100:
> Ausdrücklichen Dank für die Aufklärung an alle Beteiligten.

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. So macht das 
Beiträge schreiben Spass und nützt im Job.

MfG,

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jürgen S. schrieb:

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

Ja, eine Anforderung wie "schnell und einfach im Notfall auslösen aber 
im Normalbetrieb nie" ist wahrscheinlich nie 100% widerspruchsfrei 
spezifizierbar. Alltagsbeispiel "Notbremse im Zug" . Die "Schäden" bei 
Fehlauslösung müßen gering gehalten werden.

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.

Das spricht jetzt IMHO nicht gegen die Resetleitung an sich sondern nur 
das man die resetphase direkt an kritische Aktionen koppelt. Besser ist 
wohl erst eine Selbstdiagnose  (PowerOn -Built In Self Test) durchlaufen 
lassen und Trigger von kritischen Aktionen extra abzusichern bspw. 
"Bestätigung anfordern".

Insofern ist die Auslegung auf "Schnell aus dem Reset" wohl tatsächlich 
kontraproduktiv - interessante Anregung.


MfG,

: Bearbeitet durch User
Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fpga K. schrieb:
> So macht das
> Beiträge schreiben Spass und nützt im Job.

+1

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fpga K. schrieb:
> 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.
Das finde ich jetzt interessant, denn gerade die Tage wurde beschlossen, 
einen Reset nicht einzubauen, weil die Resetleitung selber zu soviel 
zusätzlichen Resourcen benötigt, dass die Anfälligkeit stieg und dass in 
Verbindung mit einer eventuell zuckenden Leitung von Außen die FMEA 
ergeben hat, dass das schlechter ist.

Autor: Blechbieger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ISt Alteras DEV_CLRn vergleichbar mit Xilinx GSR im STARTUPE2?

Autor: Da D. (dieter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> Dann wird der Asynchrone Reset automatisch wieder
> zum synchronen Reset und das Design kommt beim Deaktivieren des Resets
> wenigstens anständig ans Laufen...

... aber dann kann man den asynchronen Reset-PIN der FFs bei Altera 
nicht nutzen. Dann lieber den FPGA neu laden. Dass die DO vorschreibt, 
keine INIT Werte zu nehmen kann ich mir nur so erkären, dass das 
Altera-Männer mitgeschrieben haben. Würde auch deren Manie erklären 
überall resets einbauen zu müssen. Altera empfiehlt das in jedem 
Trainung.

Autor: Weltbester FPGA-Pongo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da D. schrieb:
> 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?

Von der obersten Heeresleitung nach Studium der FMEA und Timing 
Stresstestes.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: dzopf (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> 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.!

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? Ich kann mich noch erinnern, wie ich vor wenigen 
Jahren im Studium mit FPGAs und VHDL angefangen habe, und mir eben 
solche Sachen gefehlt haben! Vielleicht gibt es bereits so ein Dokument, 
vielleicht gibt es unzählige gestückelte Dokumente, aber bspw. ein 
Git-Repo, das von allen Entwicklern leicht zu finden ist, wäre meiner 
Meinung nach ideal. So ähnlich wie die C++ Core Guidelines. Interesse?

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Andreas S. schrieb:
> ISt Alteras DEV_CLRn vergleichbar mit Xilinx GSR im STARTUPE2?
Ich denke nicht, wenn ich dem thread folge, denn Altera's clear ist ein 
momentaner reset und der von Xilinx nur ein power up, also das Laden der 
Initwerte. Oder lässt sich das beliebig wiederholen?

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?
Dann fang mal an. Du wirst schnell sehen, dass 3 verschiedene 
FPGA-Entwickler 5 verschiedene Meinungen haben, weil jeder einen anderen 
background hat und etliche nicht aus der Elektronikecke kommen sondern 
Autodidakten sind, die sich ihre eigene Welt zusammengezimmert haben.

Heute programmiert jeder FPGAs, der in seinem eigentlichen Jobs nichts 
zu tun hat: Physiker, Informatiker, Maschinenbauer und neuerdings auch 
viele "Fachkräfte für Systemintegration" die bei der Volkshochschule 
einen VHDL-Kurs gemacht haben.

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fpga K. schrieb:
> Ich kann die Vehemenz der Ablehnung eines Gesamt-Resets nicht ganz
> nachvollziehen:
Wer lehnt den konkret ab?

> FF mit synchronen Reset bauen ist das kleine Einmals des
> FPGA-Entwicklers, wer das nicht kann hat in diesem Job nichts zu suchen.
Dito, wobei man in vielen Beispielen im Netz nur asynchrone 
Formulierungen findet. Das nehmen sich die Neulinge als Beispiel.

> Nachweisführung das alle FF zurückgesetzt werden können sollte man auch
> erlernt haben: Log-files analysieren, constraints setzen, mit skript die
> Netzliste auf die passenden FF-Makros parsen
Wie erreichts du mit dem Setzen von welchen Constraints eine 
Nachweisführung, dass FFs setzbar sind und wie darf ich mir den Vorgang 
des Parsens auf die passenden FF-Makros vorstellen?

Wird dann nach jedem einzelnen FF gesucht und dessen Setzbarkeit 
nachgewiesen? Wie könnte es denn überhaupt passieren, dass es ein FF 
gibt, das nicht setzbar ist? In der DO steht z.B. auch etwas von 
verwaisten Schaltungsteilen, die keine Funktion haben. Meines Wissens 
nach werden die doch von der Synthese entfernt?

Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
M. W. schrieb:
> Fpga K. schrieb:
>> Ich kann die Vehemenz der Ablehnung eines Gesamt-Resets nicht ganz
>> nachvollziehen:
> Wer lehnt den konkret ab?
Siehe Zitat-Kontext.

>> Nachweisführung das alle FF zurückgesetzt werden können sollte man auch
>> erlernt haben: Log-files analysieren, constraints setzen, mit skript die
>> Netzliste auf die passenden FF-Makros parsen
> Wie erreichts du mit dem Setzen von welchen Constraints eine
> Nachweisführung, dass FFs setzbar sind

Synchron rücksetzbar sind FF nur wenn die Pfadlängen mit der Taktperiode 
zusammenpasst, bei asynchron könnten die FF natürlich wurscht sein. 
Obwohl man constraints mit wildcards verwenden könnte um allein das 
Vorhandensein von Pfaden von verschiedenen Schaltungspunkten zu den FF 
zu ermitteln, also vom Reset-source zu den FF.
TIMESPEC TS_RST_PATH = FROM "ID_of_RST_SRC" TO FFS 42 ns datapathonly;
Im constraint report steht dann wieviele Pfade auf dieses constraint 
passen und das sollte dann nicht kleiner als die FF's sein die 
rückgesetzt werden sollen.


> und wie darf ich mir den Vorgang
> des Parsens auf die passenden FF-Makros vorstellen?

vereinfacht:
grep  "RSFF" Netzliste |wc -l
grep  "DFF" Netzliste  |wc -l
Damit wird die Anzahl der FF ermittel die über Setzeingänge verfügen 
ermittel und die denen er fehlt. Für RSFF und DFF sind natürlich die 
Makroidentifier des jeweiligen FPGA Herstellers zu verwenden. bspw:
http://www-wjp.cs.uni-saarland.de/lehre/hadeprak/block_ss11/lib.pdf S. 
47 ff


> Wird dann nach jedem einzelnen FF gesucht und dessen Setzbarkeit
> nachgewiesen?

Zumindest die netztechnische Möglichkeit wird nachgewiesen - ist der 
Setzeingang beschaltet, dann gilt das FF als setzbar.

Dazu schafft das grep beispiel von oben natürlich nicht, da muss man 
mehr Hirnschmalz in das parse-script stecken.

> Wie könnte es denn überhaupt passieren, dass es ein FF
> gibt, das nicht setzbar ist?

Weil Software und Entwickler Fehler machen? Das ist doch der Sinn der 
Qualitätssicherung/QA nachzuweisen das das Produkt die Eigenschaften 
hat, die man von ihm fordert.

> In der DO steht z.B. auch etwas von
> verwaisten Schaltungsteilen, die keine Funktion haben. Meines Wissens
> nach werden die doch von der Synthese entfernt?

Wissen ist gut, Nachweis ist besser -> parse die netzliste. Die DO gibt 
auch Ratschläge wie man die Zuverlässigkeit des synthesetools 
einschätzt.

: Bearbeitet durch User
Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weltbester FPGA-Pongo schrieb im Beitrag #5559546:
> Fpga K. schrieb:
>> 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.
> Das finde ich jetzt interessant, denn gerade die Tage wurde beschlossen,
> einen Reset nicht einzubauen, weil die Resetleitung selber zu soviel
> zusätzlichen Resourcen benötigt,

Naja, wenn man die Argumentation von Kopf auf die Füße stellt, ist es 
ganz einfach:

Fordert  man in der Systemarchitektur eine 
Rücksetz/Neustart-möglichkeit, dann sind die Resourcen dafür vorzusehen 
resp. zu schaffen.
Es gibt neben dem FF-Reset noch andere Rücksetzmöglichkeiten wie 
Neustart Konfiguration oder Strom Aus/An. Alle drei Möglichkeiten sind 
unterschiedlich schnell, unterschiedlich anspruchsvoll hinsichtlich der 
Ressourcen und haben unterschiedlich grosse Nebenwirkungen. So crashte 
eine Maschine in Indonesien weil die Piloten beim Neustart des 
Navigationssystems die Lageregelung und die Rollanzeige (künstliches 
Horizont) mitabschalteten (Adam-Air-Flug 574).

Und bei Industrieanlagen muss man auch ganz schön tief in die Eingeweide 
steigen, um den Stecker zu ziehen; da lobt man sich einen einfach 
auslösbaren "begrenzten" Componenten-reset aka Soft-Restart.

> dass die Anfälligkeit stieg und dass in
> Verbindung mit einer eventuell zuckenden Leitung von Außen die FMEA
> ergeben hat, dass das schlechter ist.

Diese FMEA krankt an vielem:
-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 ....
-besser das system wird von der Störungen "entkoppelt" bspw. durch 
Schirmung (Schirmkäfig, Masselagen, Entkoppel-C,...)
-Wie schon geschrieben, "falsche" resets können erkannt und ausgefilter 
werden, dafür gibbets so extra IC, Reset-IC.
-die Wahrscheinlichkeit für falsche resets ist erbarmungslos 
übertrieben. So bis zum Jahr 2000 hatte jeder PC an der Frontseite einen 
Reset-Button der über ca. 20 cm verdrillten "Klingeldraht" ans 
Motherboard ging. Das diese PC's häufig in den falschen Reset geschickt 
worden sind, wäre mir neu.

: Bearbeitet durch User
Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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" 
:-)

: Bearbeitet durch User
Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Fpga K. (fpgakuechle) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jürgen S. schrieb:

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

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. Und genau das kann man aus der Beschreibung des 
"Wegdiskutierens" herauslesen.
Da wird mit der Begründung "Kann fehlausgelöst werden" eine 
Rettungsmöglichkeit aus dem Systemkonzept geworfen und vielleicht noch 
als unbedeudent kleingeredet, weil ja eher selten im Geräteleben aktiv 
falls überhaupt.

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.

Besser man überlegt sich wenig störanfällige Signalübertragungen wie 
Optische Glasfasern oder verwendet wenigstens sauber in Kabelkanälen 
geschirmte Leitungen resp. Kabelbäume. Das Beispiel Airbag zeigt das 
sowas möglich ist.

Bei großen Teams und Entwicklung über Jahre ist es notwendig das Design 
immer mehr zu konsolidieren, und nicht manisch zu vereinfachen.

 Irgendwas hatt sich das Architekturteam schon dabei gedacht und viele 
schlauenen Köpfe haben das Architekturdesign-Dokument überarbeitet und 
freigegeben. Da kann jetzt nicht der Innenarchitekt aus ästhetischen 
Gründen oder ein Maurer einen Durchbruch weglassen weil er vergessen 
hatt die Hilti mit einzupacken. Nicht das im Brandfall das Gebäude zur 
Todesfalle wird, weil der Durchbruch für die Kabelführung vom 
Brandmelder zur Brandmeldezentrale fehlt.

Autor: Rolf S. (audiorolf)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Gustl B. (-gb-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jürgen S. schrieb:
> 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.

Falsch, es gibt Berechnungen Passagierflugzeuge mit einen Full-Flugzeug 
Fallschirm auszurüsten, dann müsste man aber 20% des Nutzvolumens für 
den Fallschirm "opfern". Bei Kleinflugzeugen geht das noch und wird dort 
auch praktiziert.
https://www.airspacemag.com/daily-planet/those-parachutes-small-airplanes-really-do-work-180969057/

Und was macht dich sicher das ein Fallschirm für diese Höhe nicht viel 
wiegt??? Es sind schon einige Flugzeugkatastrophen eingetreten weil die 
Passagiere zuviel gepäck mitführten, das erhöht die notwendige 
Startgeschwindigkeit und wenn noch ein paar Faktoren wie schlechter 
Wind, vereistes Rumpf etc hinzukommen, knallt die Maschine beim 
Starversuch mit Schmackes auf den Boden zurück. Und bei 11 kg für 
Gurtzeug/Fallschirm pro Passagiere biste bei 200 Passagieren schon mal 
2.2t Zusatzlast.

> Man käme also
> mit etwas mehr Treibstoff für die Masse und den Luftwiderstand raus.
> Risiken fürs Flugzeug sehe ich nicht.

Weil Du keine Ahnung von Flugzeugbau/Fliegen hast.

> Traut man den Passagieren den Absprung nicht zu?
 Warum wohl braucht es eine Ausbildung in Theorie und am Übungsfallturm? 
Warum muss ein Flugzeug extra mit sicheren Austiegslucken etc 
ausgerüstet werden damit man damit springen kann. Oder man sieht sich 
gezwungen einen Schleudersitz einzubauen, weil eben ein Fallschirm nicht 
praktikabel genug ist. Und das ein Schleudersitz gegenüber einen 
Fallschirm das Gegenteil eines einfachen Rettungsmittels ist muss wohl 
nicht extra erläutert werden.
Abgesehen von hohen Verletzungsrisikos bei der Benutzung desselben.


> Wird das Landen als zu gefährlich angesehen?
Youtube-Video "Career Ending Airborne Accident" -keine Ansichtssache, 
sondern Statistik

> Weil es meist aufs Wasser geht?
Flugzeuge die über Wasser fliegen müssen extra um zusätzliche 
rettungsmittel ausgerüstet werden, das half beim Wunder auf dem Hudson. 
Katastrophe über Wasser ist definitiv ein Fall der von den 
Fluzeugregularien bedacht wird.

> Will man die Passagiere nicht einsammeln?
Knallkopp!

> Oder sagt mal sich einfach, es passiert zu selten?
Nein sagt man sich nicht, man zitiert eher Mantra-artig Murphies Law- 
"Was schief gehen kann, wird schief gehen" und richtet sich 
damentsprechend ein. Das geht soweit das man für ganz kritische Fälle 
den Lufttransport generell verbietet (bspw. spaltbares Material, 
Castortransporte).

Und es passieren die meisten Unfälle beim Start/Landen da ist Fallschirm 
sinnfrei. Das ist auch keine Ansichtssache, sondrn Statistik. Der Unfall 
mit den meisten Opfern passierte übrigens bei der Bewegung am Boden 
(Taxing), Flugzeugkatastrophe von Teneriffa 1977 - 583 Tote.

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

Naja eine Flugzeugkatastrophe zerstört i.d. Regel Flugzeug und 
Passagiere, bei einer Schiffskatastropeh haben die Passagiere in der 
Regel Zeit den "Wirkungsradius" der Katastrophe zu verlassen. Und der 
Aufenthalt in 11000 m höhe ohne künstlichen Sauerstoff/Normaldruck ist 
tödlich, da nutzt auch ein Fallschirm nicht. Siehe Helios-Airways-Flug 
522.

Ich glaub, wir sollten diesen unsinnigen Vergleich zwischen IC-Reset und 
Evakuierung von hunderten Passagieren aus einem kaputten Flugzeug besser 
lassen.

Autor: Björn (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
>> Man käme also
>> mit etwas mehr Treibstoff für die Masse und den Luftwiderstand raus.
>> Risiken fürs Flugzeug sehe ich nicht.
> Weil Du keine Ahnung von Flugzeugbau/Fliegen hast.
Komm, wenn gewaltige Transportmaschinen abheben, kann das auch eine 747. 
Die haben sowieso nur dreiviertel volle Tanks und auf den Inlandflügen 
1/3 voll. Es gibt völlig unförmige FLugzeuge, die fliegen können und ein 
etwas dickerer Rumpf macht nichts aus. Die  Tonnen sind auch nicht 
relevant angesichts des Gesamtmasse. Das sind weniger, als 1%.

In Kleinflugzeugen werden auch Fallschirme mitgeführt und die erhöhend 
die Masse viel dramatischer. Die Piloten haben in der Regel keine 
besondere Ausbildung am Fallturm. Viele führen den auch einfach so mit 
auf dem Rücksitz. Wenn Dir nämlich bei 10.000 der Motor ausfällt, kannst 
Du bei den meisten Flugsituationen bequem bis auf 1000 runtersegeln und 
dann noch abspringen. Man muss dort oben nicht aussteigen, sondern sich 
nur den Fallschirm anlegen. Die Schwimmwesten legen die auch an, wenn es 
kritisch wird und eine Notlandung droht. Ausstiegsluke ist auch kein 
Problem, wenn man hinten aussteigt, hinter den Tragflächen. Die 
ausgestossenen Gase der Triebwerke sind in der Relativgeschwindigkeit 
versickert.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Markus F. (mfro)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Björn schrieb:
> C. A. Rotwang schrieb:
>>> Man käme also
>>> mit etwas mehr Treibstoff für die Masse und den Luftwiderstand raus.
>>> Risiken fürs Flugzeug sehe ich nicht.
>> Weil Du keine Ahnung von Flugzeugbau/Fliegen hast.
> Komm, wenn gewaltige Transportmaschinen abheben, kann das auch eine 747.
> Die haben sowieso nur dreiviertel volle Tanks und auf den Inlandflügen
> 1/3 voll. Es gibt völlig unförmige FLugzeuge, die fliegen können und ein
> etwas dickerer Rumpf macht nichts aus. Die  Tonnen sind auch nicht
> relevant angesichts des Gesamtmasse. Das sind weniger, als 1%.

Wie gesagt, es sind schon viele Maschinen wegen Überladung 
verunglückten. Nicht immer ist Schönwetter und nicht jede Startbahn ist 
griffig trocken und lang wie die Leiden Christi. Und Luftbetankung wie 
gerne bei Militätmaschinen mit zu hohen Startgewicht eingesetzt ist 
voller Risiken.

> In Kleinflugzeugen werden auch Fallschirme mitgeführt und die erhöhend
> die Masse viel dramatischer. Die Piloten haben in der Regel keine
> besondere Ausbildung am Fallturm.

Die haben aber eine gesundheitliche Prüfung hinter sicher, die schon mal 
die Hundertfünfzig Kilo Klöpse die so die amerikanischen Inlandflüge 
bevölkern aussortiert. Kleinkinder, Tatergreise, etc alles Kanditaten 
für den Sprung in den Tod wenn unvorbereitet am fallschirm. Und auch die 
fitten unter den US-Präsidenten bekommen in der AirForce One einen 
Rettungskabine und keinen Fallschirm.

> Viele führen den auch einfach so mit
> auf dem Rücksitz. Wenn Dir nämlich bei 10.000 der Motor ausfällt, kannst
> Du bei den meisten Flugsituationen bequem bis auf 1000 runtersegeln und
> dann noch abspringen. Man muss dort oben nicht aussteigen, sondern sich
> nur den Fallschirm anlegen. Die Schwimmwesten legen die auch an, wenn es
> kritisch wird und eine Notlandung droht.

Vor ein paar Wochen passierte dies:
https://www.ndr.de/nachrichten/niedersachsen/braunschweig_harz_goettingen/Toedlicher-Unfall-Flugschueler-sollte-abspringen,absturz504.html

Die Maschine fragt nicht nach ob's jetzt gerade gut zum aussteigen wäre.

In den wenigsten Katastrophenszenarien verbleibt Zeit und Lenkbarkeit um 
den flieger koordiniert auf 1000 m zu kriegen. Und wenn man noch segeln 
kann, wird man immer eine Notlandung versuchen. Flugrouten werden extra 
so gelegt das man in den (einfachen) Notlagen immer einen Flugplatz 
erreichen kann.

> Ausstiegsluke ist auch kein
> Problem, wenn man hinten aussteigt, hinter den Tragflächen. Die
> ausgestossenen Gase der Triebwerke sind in der Relativgeschwindigkeit
> versickert.

Nope, das ist eine für die Zivilluftfahrt völlig unrealistische 
Verharmlosung. Zügige evakuierung ist schon am Boden ein heikles 
Szenario, schon dabei gibt es Todesfälle (British-Airtours-Flug 28M, 
Saudia-Flug 163). Da schlagen einfach die Neandertalergene zu und die 
Passagiere drängen in die Maschine statt raus und  zertrampeln alle 
Stewarddessen die sie lieber über die Klippe springen lassen wollen.


PS:
ich bin raus aus dieser Diskussion, auch wenn der thread ins Offtopic 
gehen sollte.

Autor: Björn (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
C. A. Rotwang schrieb:
> PS:
> ich bin raus aus dieser Diskussion, auch wenn der thread ins Offtopic
> gehen sollte.

Das haben wir gern: Das Thema ad absurdum führen und dann abhauen.

Du vergisst bei deinen Betrachtungen, dass fast alle Abstürze von den 
Piloten rechtzeitg als Problem erkannt wurden und die eben versucht 
haben, das ding noch zu landen. Wenn man Fallschirme hätte, hätte es die 
Chance gegeben, die auch zu nutzen.

Autor: Da D. (dieter)
Datum:

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

Autor: C. A. Rotwang (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Björn schrieb:

> Du vergisst bei deinen Betrachtungen, dass fast alle Abstürze von den
> Piloten rechtzeitg als Problem erkannt wurden und die eben versucht
> haben, das ding noch zu landen.
Nein, bei den wenigsten Abstürzen war die Piloten in der Lage das 
Problem zu erkennen und durch eine Not-Ladung den Flug sicher zu 
beenden.

> Wenn man Fallschirme hätte, hätte es die
> Chance gegeben, die auch zu nutzen.
Die Nutzung eines Fallschirm unter suboptimalen Bedingungen ist tödlich.

Autor: Axel L. (axel_5)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Axel L. schrieb:
> 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
Ja, das aber auch nur dann wichtig, wenn man tatsächlich ASICs macht.

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

Duke

Autor: Jürgen S. (engineer) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Duke Scarring schrieb:
> Gatelevelsimulation lieft das letzte Mal vor 10 Jahren, um
> Synthesefehler zu finden...

Kann man das denn überhaupt? 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?

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Markus W. (elektrowagi78) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich meine auch die Simulation der gerouteten Netzliste. Diese ist ja nur 
ein virtuelles Abbild und hat nichts mit den LUTs zu tun. Wenn die 
übereinstimmen oder nicht übereinstimmen, sagt das nichts über richtig 
oder falsch geroutet.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [vhdl]VHDL-Code[/vhdl]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.