Synchroner Reset vom Flip Flop wird nicht verwendet

Sebastian V. schrieb:
> Ich habe auch mal mit verschiedenen VHDL schreibweisen rumprobiert.
> Anfangs sah mein Reset wie folgt aus: ...
> Testweise habe ich dann auch noch folgendes ausprobiert: ...
> Meiner Meinung nach sollten beide Varianten identisch sein
Sieh dort die letzten paar Zeilen:
http://www.lothar-miller.de/s9y/archives/52-Kompakte-Flankenerkennung.html

> Wenn ich auf Area optimiere kommt als maximale Frequenz 35MHz raus,
> statt 32MHz wie wenn ich auf Timing optimiere.
Warum so langsam? Umständliche Beschreibung? Viel Logik, wo eine 
Pipeline angesagt wäre?

Sebastian V. schrieb:
> Dazu finde ich auch die Einstellungen zur Optimierung des Systhese Tools
> sehr merkwürdig.
Was macht das alternative Synopsys-Tool?

> Ich frage mich nun warum nicht der synchrone Reset Eingang des FF
> benutzt wird, denn das sollte vom Timing ja schneller sein als
> irgendwelche Logik davor.
Das ist letztlich egal, denn wenn dein ganzes Design durch das 
Umverdrahten nicht schneller wird, bringt es auch nichts, den Reset 
schneller zumachen. Denn der hat beim synchronem Design ja die selbe 
Taktfrequenz wie das restliche Design...

Lothar M. schrieb:
> Sieh dort die letzten paar Zeilen:
> http://www.lothar-miller.de/s9y/archives/52-Kompakte-Flankenerkennung.html
Na toll. Ist ja super sinnlos was das Sythesetool dort macht.

Lothar M. schrieb:
> Warum so langsam? Umständliche Beschreibung? Viel Logik, wo eine
> Pipeline angesagt wäre?
Gute Frage. Das versuche ich ja gerade heraus zu finden. Mit LSE als 
Synthesetool haben die langsamsten Pfade 6 Logik Level. Das scheint mir 
jetzt nicht besonders viel, wobei ich hier auch die Low Power Variante 
von den MachXO2 habe und dann auch noch den langsamsten Speed Grade.

Lothar M. schrieb:
> Was macht das alternative Synopsys-Tool?
Dabei kommen deutlich bessere Werte raus. Hier mal die Werte von 
Synplify Pro:

1

Performance Summary

2

*******************

3

4

5

Worst slack in design: 10.827

6

7

@N: MT286 |System clock period 0.000 stretches to negative invalid value -- ignoring stretching.

8

                             Requested     Estimated     Requested     Estimated                Clock        Clock              

9

Starting Clock               Frequency     Frequency     Period        Period        Slack      Type         Group              

10

--------------------------------------------------------------------------------------------------------------------------------

11

gbc_main|spi_clk             42.0 MHz      239.2 MHz     23.810        4.181         10.827     inferred     Inferred_clkgroup_0

12

pll|CLKOS_inferred_clock     42.0 MHz      129.9 MHz     23.810        7.697         16.113     inferred     Inferred_clkgroup_1

13

System                       42.0 MHz      168.5 MHz     23.810        5.934         17.875     system       system_clkgroup    

14

================================================================================================================================

Und von LSE:

1

Timing Report Summary

2

--------------

3

--------------------------------------------------------------------------------

4

Constraint                              |   Constraint|       Actual|Levels

5

--------------------------------------------------------------------------------

6

                                        |             |             |

7

create_clock -period 23.809524 -name    |             |             |

8

clk501 [get_nets spi_clk_c]             |   42.000 MHz|   70.942 MHz|     3  

9

                                        |             |             |

10

create_clock -period 23.799999          |             |             |

11

-waveform { 0.000000 11.900000 } -name  |             |             |

12

clk [ get_nets { clk } ]                |   42.016 MHz|   33.321 MHz|     6 *

13

                                        |             |             |

14

--------------------------------------------------------------------------------

Wenn ich mir die langsamsten Pfade bei Synplify Pro anschaue, dann haben 
die teilweise 10 Logik Level. Irgendwie müssen die beiden Tools deutlich 
unterschiedliche Werte zum Berechnen des Timings benutzen. Ich glaub ich 
muss das Timing mal nach dem Place & Route anschauen und nicht nur nach 
der Synthese. Dann komme ich hoffentlich dahinter welches der Synthese 
Tools richtig rechnet, oder ob überhaupt eins einigermaßen sinnvolle 
Werte liefert.

C. A. Rotwang schrieb:
> Ja musst du, synthese timings sind bestenfalls best case und nicht
> zwingend realistisch.

Habe ich mal gemacht. Dabei kamen die etwas verwunderlichen Werte von 
45MHz bei LSE und 43MHz bei Synplify raus. Besonders merkwürdig finde 
ich dabei das der Wert von LSE nach dem Place and Route besser geworden 
ist als nach der Synthese. Die Werte nach der Synthese hab ich jetzt so 
verstanden, dass das die maximale Frequenz angibt die bei optimalem 
Routing vielleicht erreicht werden kann. Scheinbar sind die Werte aber 
völlig nutzlos...

C. A. Rotwang schrieb:
> Für die Resets an FF beschriebt
> https://www.xilinx.com/support/documentation/white_papers/wp275.pdf m.E.
> recht gut warum scheinbar funktional identische VHDL-Konstrukte
> unterschiedlich viel resourcen benötigen.

Werde ich mir mal anschauen.

Sebastian V. schrieb:
> Verwendeter FPGA ist der Lattice MachXO2 mit LSE als Synthese Tool.
Aber auch da gibt es für die Flipflops einen synchronen oder einen 
asynchronen Modus. Insofern trifft das WP von Xilinx auch hier zu.

Bitwurschtler schrieb:
> WS schrieb:
>> Soweit Ich weiss, ist der asynch_reset Eingang beim FPGA extra und
>> belastet nicht die Resourcen.
>
> Dann weisst Du falsch ->
> https://www.xilinx.com/support/documentation/white_papers/wp275.pdf S. 5

Richtig, bei den meisten FPGAs wird das nicht vorgesehen, weil es kaum 
einen Vorteil bringt. Da FPGAs erst mal laden, muss man sich ohnehin 
Gedanken über das Verhalten während der Ladephase machen, wenn der FPGA 
"noch nicht in der Schaltung ist", weil das Sekunden sein können. Da 
machen ein paar Takte bis zu einer eingeschwungenen PLL und voller 
Kontrolle der Ausgänge nichts aus.

Bei einem ASIC ist das anders: Der ist praktisch mit dem Einschalten 
aktiv und würde einige Takte benötigen, bis alle synchronen Register 
durch Propagieren der Information gesetzt werden. Also braucht ein ASIC 
a) einen reset und hat b) einen Vorteil von einem asynchronen Reset.

Viele verzichten aber auch bei ASICs inzwischen auf aresets, weil die 
PLLs heute derart flot sind, dass sie binnen z.B. 10 Takten sicher da 
sind.