Guten Tag, zuerstmal bitte ich darum dumme Fragen zu entschuldigen und trotzdem brauchbar zu antworten. Ja ich hab gegooglet und trotzdem nicht gefunden was ich gesucht habe. Falls ich relevante Informationen nicht angegeben habe bitte darauf hinweisen, damit ich fürs nächste mal lernen kann. Worum geht es: Ich bin dabei mit VHDL zu arbeiten und versuche nun zu analysieren was die Synthese aus meinem Code macht. Dabei gucke ich mir den Synthese Report an. (Die zu analysierende Komponente ist ein (in der Länge, per generic, konfigurierbarer) Addierer. Ich hab verschiedene Eingangslängen eingegeben (2 bis 6 bit). Dabei sind in der Synthese auch 2 bis 6 LUT's rausgekommen, soweit wie erwartet. Im Synthesereprt steht unter Punkt 1 "Slice Logic" auch diese Zahl an LUTs. Merkwürdig wird es jedoch unter Punkt 7 "Primitives". Dort werden verschiedene LUT Typen aufgezählt (LUT2 bis LUT6). Ich habe inzwischen rausgefunden, das es sich dabei um verschiedene LUT arten handelt und die Zahl die Anzahl der eingangsbits beschreibt. Used scheint zu b3edeuten wie viele LUTs des entsprechenden Typs verwendet werden. Jetzt gehen diese Zahlen aber nicht auf. Beispiel: 4 Bit Addierer (2 4bit Eingänge und 1 4bit Ausgang): 1. Slice Logic Slice LUTs* 4 LUT as Logic 4 7 Primitives LUT4 2 LUT6 1 LUT5 1 LUT2 1 Beispiel: 6 Bit Addierer (2 6bit Eingänge und 1 6bit Ausgang): 1. Slice Logic Slice LUTs* 6 LUT as Logic 6 7 Primitives LUT6 3 LUT2 2 LUT5 1 LUT4 1 LUT3 1 Ich hab den Eindruck, dass je größer mein Basiswert wird, desto mehr Luts werden verwendet (irgendwie intuitiv). Jetzt frage ich mich allerdings wie sich die Unterschiede in den beiden Kategorien (1 und 7) erklären und was das alles bedeutet? Ich hoffe das jemand zu meiner Bildung beitragen und Licht ins Dunkel bringen kann. Bei Fragen und Unklarheiten bitte melden. Ich wünsche euch soweit ein schönes Wochenende. Delay_Lama
Erik M. schrieb: > Jetzt frage ich mich allerdings wie sich die Unterschiede in den beiden > Kategorien (1 und 7) erklären und was das alles bedeutet? Weißt du wie ein Slice oder eine Logikzelle aufgebaut ist? Wenn nein: lies das entsprechende Kapitel im Datenblatt des FPGAs. Wenn ja: sie dir den RTL-Schaltplan deines Designa an. Dort kannst du sehen, in welche Schaltung der Synthesizer deine VHDL Beschreibung umgesetzt hat. Passt diese Schaltung zu dem, was du beschreiben wolltest? Wenn nein: simuliere das Design so lange, bis das Verhalten passt. Wenn ja: sieh dir im Strukturschaltplan (nach dem Mappen) an, wie dieser Schaltplan auf die LUTs abgebildet hat. > Jetzt gehen diese Zahlen aber nicht auf. Was hättest du statt dieser Zahlen erwartet? > Jetzt gehen diese Zahlen aber nicht auf. Da sind noch einige Optimierungsschritte dazwischen, so dass du das nicht so ganz einfach irgendwie 1:1 umrechnen oder extrapolieren kannst. > Jetzt frage ich mich allerdings wie sich die Unterschiede in den beiden > Kategorien (1 und 7) erklären und was das alles bedeutet? Das, was du beobachtet hast: ein breiterer Addierer braucht mehr Logik.
Die Primitives findest du nicht 1:1 so im FPGA. Die sind nochmal abstrahiert. Also es sind Basisfunktionen, die man im Design verwenden kann, die aber nicht 100% ig 1:1 im FPGA physisch vorhanden sind. Es gibt z.B. ein Primitive AND2. Du wirst aber im FPGA kein AND-Gate finden. Dieses wird dann wiederum in LUTs abgebildet. Und es gibt eben auch LUTs als Primitive, wie z.B. eine LUT2. Die ist aber im FPGA nicht physisch vorhanden. sondern wird in einer (z.B.) physisch vorhandenen LUT6 des FPGA abgebildet.
Hallo, danke für die schnellen Antworten. Ich hab sowas in der art auch schon vermutet, aber konnte keine beschreibung dafür finden und war mir daher unsicher. Vielen Dank für die Aufklärung, das hat für einiges an Klarheit gesorgt. Ich nehme an, dass z.B. zwei LUT2 in einer LUT6 zusammengefasst werden können und ich mich dann nicht wundern muss wenn 2 LUT2 angegeben werden, jedoch nur eine LUT verwendet wird? Das würde ja genau die "Unsimmigkeit" in den Besipielen erklären.
Erik M. schrieb: > Ich nehme an, dass z.B. zwei LUT2 in einer LUT6 zusammengefasst werden > können Das hängt natürlich von dem gewählten FPGA ab. Evtl hat der LUT mit zwei Ausgängen. Oder es wird in nem Optimierungsprozess noch Logik besser zusammengefasst. Im Prinzip sowas, was du auch manuell über ein KV Diagramm machen kannst.
Erik M. schrieb: > Ich hab sowas in der art auch schon vermutet, aber konnte keine > beschreibung dafür finden und war mir daher unsicher. Nun, das man Dir keine auf deinen FPGA passende Beschreibung liefern konnte, liegt zu grossen Teil daran, das du nirgendswo schreibst um welche FPGA-Architektur es sich handelt (Xilinx series7, generatio Spartan, Altera, ...). Da gibt es schon relevante Unterschiede zwischen denen. Und die Randbedingungen wie Optimierung auf Speed oder Fläche werden auch nicht genannt. Bitte das nächste Mal den vollständigen Report/synthese-log als Datei-Anhang beifügen, denn dort steht alles drin. Da mal ein Document für älterer Xilinx Architekturen, das beschreibt, woran man optimale Adder erkennt und welche Primitive neben den LUT's die Logikimplementierung bestimmen (Stichwort Carry-Chain). https://www.xilinx.com/support/documentation/application_notes/xapp215.pdf Und da ein Dokument für modernere Typen https://www.xilinx.com/support/documentation/user_guides/ug474_7Series_CLB.pdf Auf S. 21 bspw wird deutlich das man eine LUT eben nur grob als hat n-Inputs und einen Ouptut beschreiben kann. Und ne seite davor wird das Grundelement Slice mit etlichen Designelementen mehr gezeigt.
Erik M. schrieb: > Ich nehme an, dass z.B. zwei LUT2 in einer LUT6 zusammengefasst werden > können Eher nicht, weil vermutlich das Ausgangssignal dieser LUT genau so benötigt wird. Von der im FPGA tatsächlich verbauten 6er LUT wird also quasi nur 1/3 benutzt.
Lothar M. schrieb: > Eher nicht, weil vermutlich das Ausgangssignal dieser LUT genau so > benötigt wird. Auch wenn das so ist und die Logik nicht weiter zusammengefasst werden kann: ZB Xilinx hat LUT6 mit 'two independent outputs'. In die kann entweder eine 6-input Logik oder zwei 5-input Logik (oder kleiner) gepackt werden. So steht es zumindest in den Datenblättern diverser FPGAs
Schlumpf schrieb: > So steht es zumindest in den Datenblättern diverser FPGAs Bspw. im bereits oben genanten https://www.xilinx.com/support/documentation/user_guides/ug474_7Series_CLB.pdf auf S.21 ("O5 and O6 outputs")
Jetzt erstmal Hallo. Danke für die vielen Antworten. C. A. Rotwang schrieb: > Erik M. schrieb: > >> Ich hab sowas in der art auch schon vermutet, aber konnte keine >> beschreibung dafür finden und war mir daher unsicher. > > Nun, das man Dir keine auf deinen FPGA passende Beschreibung liefern > konnte, liegt zu grossen Teil daran, das du nirgendswo schreibst um > welche FPGA-Architektur es sich handelt .... Ja das stimmt, das habe ich nicht. Ich meinte mit der Beschreibung aber eher wie die einzelnen Punkte des Synthe Reports zu deuten sind. So was in dem Sinne von: "punkt 1 beschreibt die pyhiskalisch verwendete HW", "Punkt 7. beschreibt die logisch verwendete HW" (grob gesagt). Also ein Dokument wie der Reort zu lesen ist, da würde ich jetzt erstmal naiv annehmen, dass es da zwischen den FPGAs keine großen Unterschiede geben sollte. Vielleicht kennt da jeand eine Quelle, oder ist der Synthese Report strukturell vom FPGA abhängig? Wäre ja auch spannend wenn, kann ich mir aber irgendwie nicht so richtig vorstellen. Lothar M. schrieb: > Erik M. schrieb: >> Ich nehme an, dass z.B. zwei LUT2 in einer LUT6 zusammengefasst werden >> können > Eher nicht, weil vermutlich das Ausgangssignal dieser LUT genau so > benötigt wird. Von der im FPGA tatsächlich verbauten 6er LUT wird also > quasi nur 1/3 benutzt. Okay, das würde mich jetzt jedoch sehr überraschen: Erik M. schrieb: > Beispiel: > 4 Bit Addierer (2 4bit Eingänge und 1 4bit Ausgang): > > 1. Slice Logic > Slice LUTs* 4 > LUT as Logic 4 > > > 7 Primitives > LUT4 2 > LUT6 1 > LUT5 1 > LUT2 1 Daraus ergibt sich Oben (1) 4 physikalische LUT und Unten (7) 5 logische LUT. woraus ich jetzt schließen würde, dass mindestens eine irgendwie doppelt verwendet werden müsste. Ohne genauere Kenntniss würde ich jetzt schätzen das eine der 4er und die 2er Lut zusammengefasst werden, was eine 6er mit zwei Ausgängen ergeben könnte. Ist das soweit plausibel? Oder gebe es grundsätzliche Dinge, die mit nicht bekannt sind, die dieser Beobachtung und Folgerung wiedersprechen würden? Mit freundlichen Grüßen Delay_Lama
Erik M. schrieb: > Ohne genauere Kenntniss würde ich jetzt > schätzen das eine der 4er und die 2er Lut zusammengefasst werden, was > eine 6er mit zwei Ausgängen ergeben könnte. > > Ist das soweit plausibel? Oder gebe es grundsätzliche Dinge, die mit > nicht bekannt sind, die dieser Beobachtung und Folgerung wiedersprechen > würden? Das ist plausibel. Wobei du beachten musst, dass das nur funktioniert, wenn die beiden Funktionen die gleichen Eingänge haben. Also: Q1 <= A and B; Q2 <= A or B; lässt sich in einer LUT mit zwei Ausgängen zusammenfassen Q1 <= A and B; Q2 <= C and D; lässt sich nicht in einer LUT zusammenfassen.
Schlumpf schrieb: > Q1 <= A and B; > Q2 <= C and D; > lässt sich nicht in einer LUT zusammenfassen. Dann ist die Software noch nicht ganz fertig. Denn ich könnte die LUT so füllen, dass sie das kann. Man müsste hier z.B. nur das Ergebnis der beiden Berechnungen jeweils 4-fach ablegen... ;-) > Wobei du beachten musst, dass das nur funktioniert, wenn die beiden > Funktionen die gleichen Eingänge haben. Zum Glück ist die Software soweit aber tatsächlich fertig und somit geht das laut verlinktem Datenblatt auf Seite 21 wie zu erwarten sogar für bis zu 3 völlig unabhängige Eingänge:
1 | •Two arbitrarily defined Boolean functions of 3 and 2 inputs or less |
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Schlumpf schrieb: >> Q1 <= A and B; >> Q2 <= C and D; >> lässt sich nicht in einer LUT zusammenfassen. > Dann ist die Software noch nicht ganz fertig. Denn ich könnte die LUT > so füllen, dass sie das kann. Man müsste hier z.B. nur das Ergebnis der > beiden Berechnungen jeweils 4-fach ablegen... ;-) Das wäre sicherlich möglich bei entsprechend synchronisierten Designs. Xilinx gibt meines Erachtens an, dass am Ausgang einer LUT nur dann sicher kein Glitch entsteht, wenn sich innerhalb eines gewissen Zeitfensters der Wert maximal eines Einganges ändert. Falls also A, B, C, D, Q1, Q2 nun auf externe Pins gelegt werden, um eine rein kombinatorische Logik darzustellen, könnte es also eine Art "Übersprechen" zwischen den Logiken um Q1 und Q2 geben. Würde also ein aktuelles Synthesewerkzeug (Vivado o.ä.) solche Abhängigkeiten erkennen und daher auf jeden Fall separate LUTs verwenden?
Lothar M. schrieb: > Denn ich könnte die LUT > so füllen, dass sie das kann. Dann bist du schlauer, als Vivado... Hab mein Beispiel gerade in Vivado gechecked und da ist es so, wie ich es vorhergesagt habe. Aber vielleicht strengt sich Vivado auch nicht genug an, wenn der Chip noch nicht knallvoll ist. Aber du hast recht, man müsste die Funktion mehrfach ablegen, dann geht es. Weißt du, wie die LUT intern aufgebaut ist? Vermutlich wird der 1 Bit breite Speicher einfach halbiert, parallel mit 5 Bit adressiert und der obere Adressbereich auf Q5 ausgegeben. Also eine Aufteilung in zwei mal 32 x 1Bit mit parallel geschalteten Adressleitungen. Denn dann sind zwei unabhängige LUTs mit 5 Eingängen zu realisieren, wenn die 5 Eingänge identisch sind. Und dann könnten auch 3+2 oder 2+2 unabhängige Inputs durch Mehrfachablage der Funktion realisiert werden. Hast recht :-)
Andreas S. schrieb: > Falls also A, B, > C, D, Q1, Q2 nun auf externe Pins gelegt werden, um eine rein > kombinatorische Logik darzustellen, könnte es also eine Art > "Übersprechen" zwischen den Logiken um Q1 und Q2 geben. Na ja, sich auf Glitchfreiheit in einem asynchronen FPGA Design zu verlassen, ist wohl eher was für ganz besonders Mutige, oder?
Andreas S. schrieb: > Würde also ein aktuelles Synthesewerkzeug (Vivado o.ä.) solche > Abhängigkeiten erkennen und daher auf jeden Fall separate LUTs > verwenden? Sollte möglich sein. Denn es ist ja ausgehend von Quelle und Ziel relativ einfach festzustellen, ob die LUTs zueinander "synchron" angesteuert sind. > Xilinx gibt meines Erachtens an, dass am Ausgang einer LUT nur dann > sicher kein Glitch entsteht, wenn sich innerhalb eines gewissen > Zeitfensters der Wert maximal eines Einganges ändert. Mir erschließt sich noch nicht, warum das nicht auch z.B. bei 2 oder gar 3 parallelgeschalteten Eingängen der Fall sein sollte. Denn eigentlich ist es egal, ob nur 1 Eingang "gleichzeitig" die Adresse in der LUT umbiegt, oder es 3 Eingänge "gleichzeitig" tun... Schlumpf schrieb: > Na ja, sich auf Glitchfreiheit in einem asynchronen FPGA Design zu > verlassen, ist wohl eher was für ganz besonders Mutige, oder? Es geht hier eher darum, dass sich im obigen Beispiel C und D ändern und statt wie erwartet nur Q2 unerwarteterweise auch Q1 mit einem Spike/Glitch "reagiert", weil während des Umschaltens ein anderer Pegel "gestreift" wird.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Es geht hier eher darum, dass sich im obigen Beispiel C und D ändern und > statt wie erwartet nur Q2 unerwarteterweise auch Q1 mit einem > Spike/Glitch "reagiert", weil während des Umschaltens ein anderer Pegel > "gestreift" wird. Das ist mir schon klar. Aber unter der Voraussetzung, dass ein FPGA Design in der Regel aus mehr als einer LUT besteht, hat man das Problem doch sowieso. Die Skews der Laufzeiten zwischen den LUTs sorgen dafür, dass es Glitches gibt. Aber ja, ein potenziell mögliches "Übersprechen" zwischen zwei Funktionen käme dann zu den ganzen anderen Sauereien noch dazu. Ich sag ja.. Nur für Mutige ;-)
Schlumpf schrieb: > Aber unter der Voraussetzung, dass ein FPGA Design in der Regel aus mehr > als einer LUT besteht, hat man das Problem doch sowieso. Ein FPGA muss ja nicht nur eine einzelne Gesamtfunktion darstellen, sondern es können natürlich mehrere voneinander weitgehend unabhängige Funktionen realisiert werden. Und da spräche wenig dagegen, z.B. etwas anderweitig benötigte "glue logic" auch in das FPGA zu legen, wenn noch Pins frei wären. > Die Skews der Laufzeiten zwischen den LUTs sorgen dafür, dass es > Glitches gibt. Das betrifft aber primär nur die Elemente, die sich in solch eine Kette befinden. > Aber ja, ein potenziell mögliches "Übersprechen" zwischen zwei > Funktionen käme dann zu den ganzen anderen Sauereien noch dazu. Genau. Es handelt sich eben um einen zusätzlichen Effekt. > Ich sag ja.. Nur für Mutige ;-) Wenn das Synthesewerkzeug nachweislich(!) solche Konstallationen erkennt und dementsprechend nicht mehrere Funktionalitäten in einer LUT zusammenfasst, bestehen keine Einwände gegen solch eine Nutzung. In einem aktuellen Projekt habe ich genau diesen Fall, nämlich dass ein FPGA unter anderem dafür verwendet wird, einen zum FPGA-Takt asynchronen seriellen Bus umzuschalten.
Genaugenommen ist das keine Frage der Synthese, die allein die Umwandlung Hochsprache -> Logigleichungen vollzieht; sonder Aufgabe des Map/Fit, also dem Tool nach der Synthese das die Logikgleichungen optimiert auf die Hardware-elemente des FPGA abbildet. Also mal auf den Gesamtreport und die map-Optionen schauen und nicht nur auf den Synthese-output. Bei Vivado die Optimierungsroutine -remap einsetzen https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_1/ug904-vivado-implementation.pdf p.56 c. Man kann die Überführung in eine LUT auch erzwingen, indem man die passende LUT als macro instanziiert: https://www.xilinx.com/support/documentation/sw_manuals/xilinx2017_2/ug953-vivado-7series-libraries.pdf p. 372 an dem dortigen Blockdiagramm sieht man auch gut warum eben zum Zusammenlegen von LUT's Randbedingungen wie in Beitrag "Re: Interpretation Synthese report" genannt erfüllt sein müßen.
@ Andreas
Ich verstehe, was du meinst.
In dem Fall wäre es in der Tat ekelhaft, wenn auf dem asynchronen Bus
plötzlich Glitches erscheinen, die von einer ganz anderen Domäne
herrühren.
Lothar hat ja zurecht gesagt, dass sich auch 2 logische Pfade mit
unabhängigen Eingängen in einer LUT vereinen lassen, indem man die Logik
eben mehrfach abbildet.
Mein o.g. Versuch mit Vivado hat aber gezeigt, dass offenbar nur in
einer LUT zusammengefasst wird, wenn die Eingänge identisch sind.
Vielleicht liegt das ja gar nicht daran, dass Vivado unausgereift ist,
sondern daran, dass es absichtlich so gehandhabt wird, um das von dir
genannte Problem zu umgehen.
Also sicher zu stellen, dass keine unabhängingen Pfade über eine
gemeinsame LUT geführt werden.
Hab gerade mal getestet:
Q <= A and B;
Q1 <= A and C;
wird ebenfalls in eine LUT gepresst.
Ok, hier könnte man noch sagen, dass die Änderung von C keinen Glitch
auf Q erzeugt, da sich ja nur ein Bit ändert.. Aber:
Q <= A and B;
Q1 <= A and C and D;
wird auch in eine LUT gepackt. Und hier könnten sich C und D
gleichzeitig ändern, was dann zu Glitches auf Q führen könnte.
Erst
Q <= A and B;
Q1 <= C and D;
Führt dazu, dass zwei getrennte LUTs verwendet werden.
Vivado packt also offenbar die Logik automatisch in eine LUT, wenn
mindestens ein Eingang auf beide Ausgänge vernknüft ist.
Das lässt sich aber verhindern, indem man in den Synthese Settings
"no_lc" aktiviert. Dann wird das Beispiel
Q <= A and B;
Q1 <= A and C and D;
in zwei LUTs gepackt.
Gut zu wissen, dass das ne Stelle ist, auf die man achten muss.
Und jetzt muss ich grad an den Thread denken, wo einige der Meinung
sind, dass man in VHDL ne Idee "programmiert" und daraus dann ganz
automatisch eine gute Implementierung wird.
Beitrag "VHDL Denken-wie?"
Herzlichen Glückwunsch. So jemand bekommt nie raus, warum im o.g.
Beispiel Q glitched, wenn sich C und D ändert.
Schlumpf schrieb: > Gut zu wissen, dass das ne Stelle ist, auf die man achten muss. Nur, wenn man asynchrone Schweinere^HDesigns macht. Ich habe damit noch nie ein Problem gehabt. Hier die Aussage von einem, der es wissen muß:
1 | The LUT is not glitch free. |
2 | |
3 | Each bit input to the LUT slects a multiplexer path, in a binary tree. So only a change to a single input is glitch free. If more than one input changes, then due to the delay of each stage of the multiplexder tree, there may be glitches. The first stage is the slowest, and the last stage is the fastest. No attempt is made to equalize the delays, as the wires to get there will dominate, and will all be different, regardless. |
4 | |
5 | Austin Lesea |
6 | Principal Engineer |
Quelle: https://forums.xilinx.com/t5/Simulation-and-Verification/Glitches-in-combinational-logic/td-p/133786 Duke
Duke Scarring schrieb: > Hier die Aussage von einem, der es wissen muß: Genau das ist doch die Sache, die hier diskutiert wird. Keiner zweifelt an, dass eine LUT Glitches erzeugt. Man kann natürlich asynchrone Designs machen, wenn man sich der Sache bewusst ist. Aber wenn plötzlich durch das Zusammenlegen von LUTs zwei unabhängige logische Pfade sich gegenseitig beeinflussen, dann gibt es eben ein Problem, mit dem man gar nicht gerechnet hat. Man beschreibt: Q = f(A,B) Q1 = f(A,C,D) Und geht davon aus, dass Glitches auf Q nur von A oder B erzeugt werden können, aber stellt dann plötzlich fest, dass auch C und D Glitches auf Q erzeugen können.
Duke Scarring schrieb: >> Gut zu wissen, dass das ne Stelle ist, auf die man achten muss. > Nur, wenn man asynchrone Schweinere^HDesigns macht. Dies lässt sich eben manchmal nicht vermeiden, wenn man z.B. Testsysteme entwickelt, in denen externe Signalpfade eben zwischen verschiedenen Quellen und Senken verschaltet werden müssen. Diese Signale sauber einzusynchronisieren kostet aber Durchlaufzeit ohne Ende und führt zu einer "Modulation" der externen Signalpfade mit dem jeweiligen FPGA-Takt. Die Alternative ist also nicht das Einsynchronisieren, sondern entweder das Verhindern von LUT-Zusammenfassungen oder eben die Verwendung externer diskreter Logik. Und letztere wäre natürlich komplett sinnlos, wenn man das FPGA hauptsächlich für genau die genannten Multiplexer einsetzt. Bevor hier entsprechende Einwände kommen: JA, es ist mir bekannt, dass im Moment des Umschaltens solcher Multiplexer Glitches, ungültige Datenmuster oder Timingverletzungen entstehen können, wenn die Ansteuerung und die Datenquellen nicht synchron zueinander sind. In meinem konkreten Fall wäre das aber kein Problem, da zum einen während des Umschaltens "Funkstille" auf den gemultiplexten Signalen herrscht und zum anderen die Prüflinge nach solch einer Konfigurationsänderung zurückgesetzt bzw. überhaupt erst eingeschaltet werden. > Ich habe damit noch nie ein Problem gehabt. Dann hattest Du bisher einfach nur das Glück, keine asynchronen Signale durch ein FPGA routen zu müssen. > Hier die Aussage von einem, der es wissen muß: > The LUT is not glitch free. Genau das war doch eh schon meine Kernaussage. Trotzdem vielen Dank für das Heraussuchen der Originalpublikation.
:
Bearbeitet durch User
Schlumpf schrieb: > Man beschreibt: > Q = f(A,B) > Q1 = f(A,C,D) Solange dies nur direkt aufeinanderfolgende Quellcodezeilen beträfe, wäre das zwar schon ärgerlich, aber noch halbwegs zu berücksichtigen. Wesentlich übler wird es dann, wenn sich die Anweisungen in verschiedenen Modulen befindet und z.B. das Signal A ein globales Reset- oder Enable-Signal für eine Schaltmatrix darstellt.
Andreas S. schrieb: > und z.B. das Signal A ein globales Reset- > oder Enable-Signal für eine Schaltmatrix darstellt. ... oder Q die Adresse eines gemultiplexten asynchronen Bus ist und diese dann während des Zugriffs nicht stabil ist. Ich sehe da in der Tat auch ein Problem, welches nicht von der Hand zu weisen ist. Glitches innerhalb eines logischen (und auch so codierten Pfades) kann man beherrschen, weil man einfach weiss, dass beim Signalwechsel der Eingänge der Ausgang für eine Zeit Glitchen kann. Aber dann ist nach einer maximalen Zeit auch Ruhe und dan erfolgt die Weiterverarbeitung oder Übernahme der Daten. Das lässt sich einstellen. Z.B über Waitstates etc.. Wenn dann aber Schaltvorgänge auf komplett anderen logischen Pfaden dazu führen, dass es zu Glitches auf dem Pfad kommt, wo diese Eingänge funktional gar nicht "beteiligt" sind, wird es richtig hässlich. Diese mögliche "Kopplung" war mir bisher nicht bewusst. Aber sie stellt meines Erachtens eine Problem dar, das man definitiv im Hinterkopf behalten sollte, wenn man solche Designs macht.
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.