mikrocontroller.net

Forum: FPGA, VHDL & Co. Interpretation Synthese report


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Erik M. (delay_lama)
Datum:

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

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

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Erik M. (delay_lama)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

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

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

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

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

Autor: Schlumpf (Gast)
Datum:

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

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

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

Autor: Erik M. (delay_lama)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
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:
•Two arbitrarily defined Boolean functions of 3 and 2 inputs or less

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

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Schlumpf (Gast)
Datum:

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

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

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

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

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

Autor: Schlumpf (Gast)
Datum:

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

Autor: Duke Scarring (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß:
The LUT is not glitch free.

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.

Austin Lesea
Principal Engineer

Quelle: 
https://forums.xilinx.com/t5/Simulation-and-Verification/Glitches-in-combinational-logic/td-p/133786

Duke

Autor: Schlumpf (Gast)
Datum:

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

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

Bewertung
0 lesenswert
nicht lesenswert
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
Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

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

Autor: Schlumpf (Gast)
Datum:

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

Antwort schreiben

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

Wichtige Regeln - erst lesen, dann posten!

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

Formatierung (mehr Informationen...)

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




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

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