Quartus II Optimierung von Gattern deaktivieren

[Johannes R. (ro_johannes)]

Hallo zusammen,

ich versuche für meine Bachelorarbeit Butterfly Zellen (zwei 
Rückgekoppelte D-Latches mit Preset und Reset) auf einen Altera Cyclone 
II FPGA zu implementieren. Dafür verwende ich Quartus II Version 13.0.

Aber das Porgramm optimiert immer meine Butterfly Zellen weg und legt 
die Pins, die mit den Ausgang der Zellen verbunden sind, auf GND. Weiß 
jemand, wie man diese Optimierung abschalten kann?
Mit einen Spartan3e FPGA von Xilinx konnte ich die Butterfly Zellen mit 
denselben vhdl-Dateien implementieren.

Im Anhang findet ihr mein Quartus II Projekt. Ich freue mich auf eure 
Antworten.

Gruß

Johannes

[Lothar M. (lkmiller) (Moderator)]

Johannes R. schrieb:
> Im Anhang findet ihr mein Quartus II Projekt.
Damit kann ich mangels Software leider nichts anfangen, aber welche 
Fehlermeldungen/Warnungen/Infos bekommst du denn?

> Im Anhang findet ihr mein Quartus II Projekt.
Könntest du nicht einfach die paar VHDL-Datein einzeln hier anfügen? 
Dann hätten auch die mit Handy eine Chance, dir zu helfen.

> und legt die Pins, die mit den Ausgang der Zellen verbunden sind, auf
> GND. Weiß jemand, wie man diese Optimierung abschalten kann?
Ich vermute, das hängt irgendwie mit der sehr eigenwilligen Beschreibung 
des Flipflops zusammen...

Und auch die rustikale Takterzeugung mit dem slow_clock wird so in einem 
FPGA nicht gemacht. Da sollte eine Warnung zum Thema "clock skew" ganz 
hell aufleuchten. Korrekterweise nimmt man da einen Clockmanager her, 
die hat man schließlich beim Kauf des FPGAs auch bezahlt.
Oder besser noch: sieh dir das Thema "Taktteilung mit Clock Enables" an.

> Ich freue mich auf eure Antworten.
Ein Thread zum Thema reicht eigentlich... Welchen soll ich löschen?

[Markus F. (mfro)]

Johannes R. schrieb:
> Aber das Porgramm optimiert immer meine Butterfly Zellen weg und legt
> die Pins, die mit den Ausgang der Zellen verbunden sind, auf GND. Weiß
> jemand, wie man diese Optimierung abschalten kann?

So wie ich das sehe, verschwinden deine Flipflops schlicht deswegen, 
weil ihr Clock-Eingang nicht getaktet wird.

Was soll ohne Takt passieren?

[C. A. Rotwang (Gast)]

Johannes R. schrieb:
> Aber das Porgramm optimiert immer meine Butterfly Zellen weg und legt
> die Pins, die mit den Ausgang der Zellen verbunden sind, auf GND. Weiß
> jemand, wie man diese Optimierung abschalten kann?

Das Thema wurde zuletzt im Sommer hier diskutiert, die Lösung liegt in 
der Verwendung des richtigen (Synthese)-Attributes:
Beitrag "Verilog attribut "keep" in Quartus"
Beitrag "Altera SignalTap: Wegoptimieren von Signalen verhindern"

[Markus F. (mfro)]

C. A. Rotwang schrieb:
> Johannes R. schrieb:
>> Aber das Porgramm optimiert immer meine Butterfly Zellen weg und legt
>> die Pins, die mit den Ausgang der Zellen verbunden sind, auf GND. Weiß
>> jemand, wie man diese Optimierung abschalten kann?
>
> Das Thema wurde zuletzt im Sommer hier diskutiert, die Lösung liegt in
> der Verwendung des richtigen (Synthese)-Attributes:
> Beitrag "Verilog attribut "keep" in Quartus"
> Beitrag "Altera SignalTap: Wegoptimieren von Signalen verhindern"

Ich denke, das ist bloß die halbe Miete.

Der TO sollte sich zunächst mal anschauen, wie man in HDL ein Register 
beschreibt. So, wie er das bislang versucht hat, kommt da - wenn 
überhaupt - lediglich kombinatorische Logik raus.

[Lothar M. (lkmiller) (Moderator)]

C. A. Rotwang schrieb:
> die Lösung liegt in der Verwendung des richtigen (Synthese)-Attributes
Das wäre bestenfalls ein böser Work-Around.
Die Lösung liegt (neben dem wegen der statisch anliegenden '1' durch 
"xAlwaysTrue" fehlenden Takt) darin, das Flipflop so zu beschreiben, 
dass der Synthesizer was damit anfangen kann. Wie das für die jeweilige 
Toolchain aussehen muss, das steht im Handbuch zum Synthesizer.

Aber sobald man ein Flipflop anders beschreibt als der Rest der Welt, 
wird die Portierbarkeit leiden.

Hier kommt noch dazu, dass D eigentlich nicht in die Sensitivliste 
gehört:

architecture Behavioral of D_FlipFlop is begin process(CLK, PRE, CLR, D) begin if(CLR = '1') then Q <= '0'; elsif (PRE = '1') then Q<='1'; elsif (CLK='1') then Q<= D; end if; end process; end Behavioral;

Es "schadet" zwar nicht, es deutet aber drauf hin, dass der, der das 
gemacht hat, noch Verständnisprobleme hat... ;-)

[Markus F. (mfro)]

Wenn ich etwas "CLK" nenne, heißt das noch lange nicht, daß das deswegen 
auch eine ist .

Entsprechend erzeugt der Prozeß (ohne clk'event) auch kein Flipflop, 
sondern bloß (ziemlich unnütze) Kombinatorik.

[Lothar M. (lkmiller) (Moderator)]

Markus F. schrieb:
> Entsprechend erzeugt der Prozeß (ohne clk'event) auch kein Flipflop,
> sondern bloß (ziemlich unnütze) Kombinatorik.
Richtig, da fehlt ja das 'event. Böse, böse. Aber Johannes will ja 
(obwohl das Konstrukt irreführend "Flipflop" heißt") tatsächlich Latches 
haben, denn
Johannes R. schrieb:
>>> ich versuche für meine Bachelorarbeit Butterfly Zellen
>>> (zwei Rückgekoppelte D-Latches mit Preset und Reset)
Allein, ich vermute, dass das Design dadurch grundlegend zum Scheitern 
verurteilt ist. So ein Hingebastel habe ich vor langer Zeit mal zufällig 
gemacht. Das Resultat: eine kombinatorische Schleife...


Ich habe die paar VHDL-Dateien nochmal angeschaut: darf ich die als 
schlechte Beispiele für meine 
Praktikanten/Studenten/Abschlussarbeitschreibende hernehmen?

process(Fast_Clock) variable iCount : integer := 0; begin if(Fast_Clock'event and Fast_Clock='1') then iCount := iCount +1; end if; if(iCount > 24999) then Slow_Clock <= '1'; else Slow_Clock <= '0'; end if; if(iCount = 49999) then iCount :=0; end if; end process;

Ein getakteter Prozess mit einem kombinatorischen Ende. Wo lernt man 
denn sowas?  :-O

Johannes R. schrieb:
> Mit einen Spartan3e FPGA von Xilinx konnte ich die Butterfly Zellen mit
> denselben vhdl-Dateien implementieren.
Glaube ich nicht.
Mit genau dieser Beschreibung wird einfach der "Excite" Eingang auf 
den Augang gemappt. Denn dq_1 ist immer '0'. Und dq_2 ist entweder dq_1 
(also '0'), wenn Excite '0' ist. Und es ist wegen PRE ='1' ebenfalls 
'1', wenn Excite '1' ist.

Was soll dieser ganze irreführende Konstrukt denn letztlich tun?

Die "Buttterfly"s haben übrigens ihren Namen genausowenig verdient wie 
die "D-Flipflops".

[Markus F. (mfro)]

Lothar M. schrieb:
> Was soll dieser ganze irreführende Konstrukt denn letztlich tun?

Das hätte wohl ein PUF 
(https://en.wikipedia.org/wiki/Types_of_physical_unclonable_function , 
siehe dort "Butterfly PUF") werden sollen.

Also so eine Art "gerätespezifischer Fingerabdruck".

[Dussel (Gast)]

Lothar M. schrieb:
> Hier kommt noch dazu, dass D eigentlich nicht in die Sensitivliste
> gehört:
Genaugenommen doch. Wenn CLR und PRE 0 sind und CLK 1, ändert sich Q mit 
jeder Änderung von D. Ohne D in der Liste sieht es in der Simulation 
sonst wirklich aus, als wäre es getaktet (auf beide Flanken). Für sich 
genommen stimmt da alles. Ob es gewollt ist, ist die andere Frage. ;-)

[Lothar M. (lkmiller) (Moderator)]

Dussel schrieb:
> Wenn CLR und PRE 0 sind und CLK 1, ändert sich Q mit jeder Änderung von D
Korrekt. In dieser Beschreibung eines Latches durchaus. Nur darf das 
Ding dann wie schon einige Male erwähnt nie&nimmer "D-Fiplflop" heißen.

Dussel schrieb:
> Ob es gewollt ist, ist die andere Frage. ;-)
Irgendwie habe ich da so einen Verdacht, dass wir das nicht herausfinden 
werden...

[C. A. Rotwang (Gast)]

Lothar M. schrieb:
> C. A. Rotwang schrieb:
>> die Lösung liegt in der Verwendung des richtigen (Synthese)-Attributes
> Das wäre bestenfalls ein böser Work-Around.


Nicht, wenn man den TO beim Wort nimmt, das das Konstrukt bei Xilinx 
Spartan-3E das gewünschte "rückgekoppelte D-Latch" liefert.

Was die Goldenen Regel " only fools and real experts uses latches" im 
Falle des TO bedeutet, soll der TO mal besser selbst herausfinden. So 
ist der Lerneffekt am grössten und nachhaltige Erkenntniss am ehesten zu 
erwarten.

[Markus F. (mfro)]

C. A. Rotwang schrieb:
> Nicht, wenn man den TO beim Wort nimmt, das das Konstrukt bei Xilinx
> Spartan-3E das gewünschte "rückgekoppelte D-Latch" liefert.

Das würde mich sehr wundern.

process(CLK, PRE, CLR, D) begin if (CLR = '1') then Q <= '0'; elsif PRE = '1' then Q <='1'; elsif CLK = '1' then Q <= D; end if; end process;

Mit CLK = xAlwaysTrue steht da eigentlich

process(CLK, PRE, CLR, D) begin if (CLR = '1') then Q <= '0'; elsif PRE = '1' then Q <='1'; else Q <= D; end if; end process;

und das ist kein Latch.

[Lothar M. (lkmiller) (Moderator)]

C. A. Rotwang schrieb:
> Nicht, wenn man den TO beim Wort nimmt, das das Konstrukt bei Xilinx
> Spartan-3E das gewünschte "rückgekoppelte D-Latch" liefert.
Wobei "Flipflop" bei mir mental diametral zum "Latch" angeordnet ist... 
;-)

> Nicht, wenn man den TO beim Wort nimmt, das das Konstrukt bei Xilinx
> Spartan-3E das gewünschte "rückgekoppelte D-Latch" liefert.
Tut es tatsächlich. Zusammen mit der Warnung:

WARNING:Xst:737 - Found 1-bit latch for signal <Q>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.

Allerdings ist genau dieses Bauteil überaus herstellerspezifisch. Mich 
würde doch sehr interessieren, was Quartus daraus macht. Vermutlich 
packt der das Ganze in zwei LUTs (oder gar nur eine) und fertig.

Denn ich kann ohne die explizite Verwendung von Latches das ganze Design 
funktionell auf zwei Zeilen reduzieren:

dq_1 <= dq_2 when Excite='0' else '0'; dq_2 <= dq_1 when Excite='0' else '1';

Das macht auch Quartus, denn mit dieser Beschreibung kommt auch Xilinx 
zum Ergebnis, dass dq_1 entfällt und dq_2 fest auf '1' gelegt wird.

Die Verwendung des Keep-Attribus hilft da auch nicht viel weiter, denn 
mit

signal dq_1, dq_2: std_LOGIC; attribute KEEP : string; attribute KEEP of dq_1 : signal is "true"; attribute KEEP of dq_2 : signal is "true";

wird dann Kombinatorik und eine kombinatorische Schleife (mit der 
passenden  WARNING:Xst:2170 - Unit Butterfly : the following signal(s) 
form a combinatorial loop: dq_2, dq_1) daraus.

Ob man letzlich das "Oszillieren" dieser Kombinatorik für einen 
sinnvollen "Fußabdruck" verwenden kann, lässt sich in Frage stellen...

Markus F. schrieb:
> Mit CLK = xAlwaysTrue steht da eigentlich
> ....
> und das ist kein Latch.
Nein, diese Beschreibung wird nur dazu zweckentfremdet, dass der 
Synthesizer erkennt, dass da so ein spezielles Latch verwendet werden 
soll. Quartus erkennt ein solches "Xilinx-Latch" natürlich nicht. 
Entweder muss das für Quartus ganz anders beschrieben sein, oder das 
FPGA kann gar keine Latches, weil es keine hat.

[Johannes R. (ro_johannes)]

Danke für die vielen Antworten.

Ja, man sollte ein Latch eigentlich auch Latch nennen und nicht 
FlipFlop. Das werde ich noch anpassen.

Danke für den Tipp mit den Clockmanager. Das habe ich nicht gewusst.

Lothar M. schrieb:
> Nein, diese Beschreibung wird nur dazu zweckentfremdet, dass der
> Synthesizer erkennt, dass da so ein spezielles Latch verwendet werden
> soll. Quartus erkennt ein solches "Xilinx-Latch" natürlich nicht.
> Entweder muss das für Quartus ganz anders beschrieben sein, oder das
> FPGA kann gar keine Latches, weil es keine hat.

Ja, das kann sein. Ich habe in einem Projekt in einem Schematic File 
einmal ein D-Latch mit PRE und CLR aus der Quartus Bibliothek verwendet 
und geschaut, wie es auf dem FPGA umgesetzt wird. Das Latch wird 
tatsächlich mit einfachen Logik-Gattern nachgebildet (siehe Bilder)
Tja, das kommt davon, wenn man das billigste FPGA Board auf dem Markt 
kauft...

Gruß

Johannes

[Lothar M. (lkmiller) (Moderator)]

Johannes R. schrieb:
> Tja, das kommt davon, wenn man das billigste FPGA Board auf dem Markt
> kauft...
Du kannst jedes andere kaufen. Nur Xilinx hat Flipflops, die sich zu 
Latches umschalten lassen. Im Handbuch des Cyclone II 
(https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyc2/cyc2_cii5v1.pdf) 
findest du dann auch den Aufbau einer Logikzelle und die Fähigkeiten der 
darin enthaltenen Speicherelemente. Ein Latch ist da nicht dabei.

Du könntest für deine PUF-Versuche einen Ringoszillator nehmen (das ist 
das Ganze sowieso). Der kommt mit den Durchlaufzeiten der LUT aus. Und 
die sind prinzipiell ja auch spezifisch für jeden Baustein (und abhängig 
von Spannungsversorgung und Temperatur und sonstwas):
http://www.lothar-miller.de/s9y/categories/29-Ringoszillator
http://www.lothar-miller.de/s9y/archives/35-Ringoszillator-im-S3.html

Dazu brauchst du dann wieder das keep-Attribut. Siehe dort Seite 
16-44ff: 
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/qts/qts_qii51008.pdf

[C. A. Rotwang (Gast)]

Markus F. schrieb:
> Mit CLK = xAlwaysTrue steht da eigentlich
> process(CLK, PRE, CLR, D)
> begin
>     if (CLR = '1') then
>         Q <= '0';
>     elsif PRE = '1' then
>         Q <='1';
>     else
>         Q <= D;
>     end if;
> end process;
>
> und das ist kein Latch.

Das ist die Kernfrage "Was ist ein Latch?" . Da sich die Lehrbücher 
darin auch nicht einig sind (Im "Seifart" ist eine vom Taktimpuls 
gesteuerte 1 bit speicherzelle ein data Latch, FF und Latch werden also 
gleich benutzt - ich sehe allerdings ein Latch auch eher "diametral" zum 
FF) mal hier ne umgangssprachliche Beschreibung von Latch:

Wird der Schalter "Eins" gedrückt wird der Ausgang "Eins"
wird dieser schalter losgelassen bleibt der Ausgang auf "Eins"
Wird der Scahlt "Null" gedrückt wird der Ausgang "Null"
wird dieser schalter losgelassen bleibt der Ausgang auf "Null"
-> das Latch speichert also den vorher Gesetzten Zustand. Zu 
Transitorzeiten hat man das wohl "bistabiler Multivibrator" genannt

Der TO spricht des weiteren von einer rückkopplung also verbindung von 
Ausgang Q mit Eingang D . Damit wird das oben genannte schon zum Latch, 
es wird asynchron ein 1-bit wert eingespeichert.

>Du kannst jedes andere kaufen. Nur Xilinx hat Flipflops, die sich zu
>Latches umschalten lassen. Im Handbuch des Cyclone II
>(https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature>/hb/cyc2/cyc2_cii5v1.pdf)
>findest du dann auch den Aufbau einer Logikzelle und die Fähigkeiten der
>darin enthaltenen Speicherelemente. Ein Latch ist da nicht dabei.

Ich stimme zu, das bei Xilinx "Latch" explizit genannt wird, bei Altera 
dagegen nicht. Schaut man sich Fig 2-3 auf p.30 von 
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyc2/cyc2_cii5v1.pdf
an, könnte man zumindest ein "Latch" realisieren, das bei Aktivierung 
vom CLRN den Ausgang asynchron auf '0' schaltet und nach Aktivierung 
dort belässt (wenn der clock disabled) ist. Das wäre wenigstens m.E. ein 
"halbes Latch", das man auch zum "Einfangen" kurzer Pulse verwenden, 
-die  typische Anwendung für Latches- benutzen kann.

[Lothar M. (lkmiller) (Moderator)]

C. A. Rotwang schrieb:
> an, könnte man zumindest ein "Latch" realisieren, das bei Aktivierung
> vom CLRN den Ausgang asynchron auf '0' schaltet und nach Aktivierung
> dort belässt (wenn der clock disabled) ist.
Das ist doch ein übliches Flipflop mit asynchronem Reset.

Ein Latch ist beim "nichtspeichernden" Pegel des Latch-Enable-Eingangs 
transparent, und behält beim "speichernden" Pegel den letzten Zustand:
http://ranger.uta.edu/~carroll/cse2341/summer99/html%20files/chapter_6/sld029.htm

> Im "Seifart" ist eine vom Taktimpuls gesteuerte 1 bit speicherzelle
> ein data Latch, FF und Latch werden also gleich benutzt
Das ist eine sprachliche Unsauberkeit. Denn natürlich kann man 
umgangssprachlich auch mit Flipflops etwas "latchen", so werden auch 
heute noch z.Adressen oder auch Daten oft mit D-Flipflops "gelatcht".
Das kommt aber daher, dass diese "Latch"-Flipflops ursprünglich wirklich 
kombinatorische Latches waren (weil so ein Latch mit weniger 
Siliziumfläche realisierbar war als ein D-Flipflop).

> Damit wird das oben genannte schon zum Latch, es wird asynchron ein
> 1-bit wert eingespeichert.
Richtig, aber für diese Speicherfunktion ist eben kein Latch-Baustein 
nötig. Deshalb hat Altera/Intel sowas gar nicht als eigenes Bauteil, 
sondern setzt die Funktion direkt in einer rückgekoppelten LUT um.

[Markus F. (mfro)]

Lothar M. schrieb:
> Deshalb hat Altera/Intel sowas gar nicht als eigenes Bauteil,
> sondern setzt die Funktion direkt in einer rückgekoppelten LUT um.

So sehe ich das auch. Und deswegen auch keinen Grund, warum sich die 
"PUF-Funktionalität" damit nicht genauso implementieren lassen sollte?