Announcement: there is an English version of this forum on 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?
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,
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!
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,
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?
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,
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?
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.
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
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?
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.
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
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.
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,
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
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
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.
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).
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,
Fpga K. schrieb: > [...] Das ist der > fehlzustand den man durch einen Reset zu beheben versucht. Ok, das kann ich nachvollziehen.
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.
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,
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
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,
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,
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.
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.
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,
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,
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.
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.
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...
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.
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.
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
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
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?
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.
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.
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?
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.
1 | 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:
1 | grep "RSFF" Netzliste |wc -l |
2 | 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.
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.
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" :-)
:
Bearbeitet durch User
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
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.
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.
:
Bearbeitet durch User
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
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.
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? https://www.youtube.com/watch?v=XOsGnaeT03k -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.
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.
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.
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.
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.
Können wir bitte die Flugzeugdisskusion hier sein lassen? Meine Güte, wenn euch das Thema interessiert, macht nen Offtopic Thread auf!
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.
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
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
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.
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?
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.