TimeQuest Analyzer - Was sehe ich da überhaupt?

[Holger K. (holgerkraehe)]

Hallo Zusammen

Ich versuche gerade die Timinganalyze für mein SDRAM durchzuführen.
Leider bin ich neu in dem Gebiet, und so ergeben sich ein paar Fragen.

Im Anhang befindet sich ein Bild der Timinganalyse für das Signal WE_bo

Mein Problem ist, dass ich nicht verstehe, was ich dort sehe.
Ich habe ja ein Outputdelay min von 1ns und ein max von -1.5ns.
Diese Angabe finde ich irgendwie nicht im Bild.
Zudem gibt mir die Analyse an ich hätte einen Slack von 12.8ns
nun aber nach 12.8ns scheinen die Daten wieder bereits sein zu müssen. 
Die Zeiten von 1 und 1.5ns müssten doch mindesten abgezogen werde?

Vielleicht kann mir jemand ein paar Erklärungen geben?
Vielen Dank!

Ich habe folgendes im SDC File Definiert:

# FPGA timing constraints
set sdram_input_delay_min        2.5
set sdram_input_delay_max        6
set sdram_output_delay_min       1
set sdram_output_delay_max      -1.5

set_output_delay \
  -clock $ram_clk \
  -min $sdram_output_delay_min \
  [get_ports {sdWe*}]

set_output_delay \
  -clock $ram_clk \
  -max $sdram_output_delay_max \
  [get_ports {sdWe*}]

[Markus F. (mfro)]

Dir ist schon bewußt, daß Du Hold Timing - also die "andere Flanke" - 
anguckst?

[Holgerkraehe (Gast)]

Markus F. schrieb:
> Dir ist schon bewußt, daß Du Hold Timing - also die "andere
> Flanke" - anguckst?

Nein ist es mir nicht. Ich sag ja, ich weiss njcht was ich da sehe...

Das input timing steht ja auch noch da.
Ich verstehe das diagramm wirklich nicht

[Schlumpf (Gast)]

Letztendlich wird in diesen Diagrammen Folgendes dargestellt:

Zum einen den Phasenbezug zwischen Signalerzeugender Taktflanke und der 
Flanke, die das Signal übernimmt.
zum Anderen die Laufzeit des Signals zwischen den beiden Registern und 
dann noch den Skew der Takte an den Registern.

So wie das aussieht, generierst du ein Signal mit einem Takt aus der PLL 
und übernimmst es mit einem anderen Takt aus der PLL.
Timequest weiss, wie die Takte in der PLL zueinander stehen und kann 
daher analysieren, ob das Signal zum Zeitpunkt der Übernahmeflanke am 
Zielregister stabil ist (Setup und Hold Zeiten eingehalten werden) unter 
Berücksichtigung der o.g. Parameter.

[Markus F. (mfro)]

Holgerkraehe schrieb:
> Nein ist es mir nicht. Ich sag ja, ich weiss njcht was ich da sehe...

Erstmal für die Grundlagen hier: 
https://de.wikipedia.org/wiki/Flipflop#Timing_der_Flipflops lesen.

TimeQuest betrachtet Register-zu-Register-Pfade (die - abhängig davon, 
was Du als Kombinatorik dazwischen gebaut hast - mal länger und mal 
kürzer sein können) mit den dazugehörigen Clock-Pfaden (die - je 
nachdem, wo Du auf der Chipfläche gerade unterwegs bist - auch mal 
länger und mal kürzer sein können) und kontrolliert, ob die Daten am 
Zielregister rechtzeitig vor der Taktflanke ankommen (Setup) und lang 
genug danach "stehen bleiben" (Hold) um bei allen möglichen 
Kombinationen (Temperaturvarianz, z.B.) zuverlässig zum richtigen 
Zeitpunkt bereitzustehen.

In deinem Bildchen siehst Du zum einen die "Launch"- und die 
"Latch"-clock (also den Takt des Quell- und des Zielregisters), (weil Du 
die "Hold"-Analyse gemacht hast) "Data Required" (also in dem Fall den 
Zeitpunkt, bis zu dem die Daten am Zielregister mindestens stehen 
bleiben müssen) und "Data Arrival" (den Zeitpunkt, bis zu dem sie 
tatsächlich stehen bleiben).

Die Differenz ist der Slack (die Zeitspanne, um die die Timing Margin 
besser ist als sie mindestens sein müsste), die "Reserve" also.
In dem Fall ist "genügend Luft", also grün.

TimeQuest betrachtet immer "worst case", deswegen kommt von deinen 
Constraints in diesem Fall (Hold) nur der "Minimum Output Delay" vor.

[Frank S. (schroederde)]

Holger K. schrieb:
> set sdram_output_delay_min       1
> set sdram_output_delay_max      -1.5

Bist Du sicher, dass Du min und max nixht vertauscht hast? max ist der 
Offset des Beginns des DataValid Fensters bezogen auf die Latchclock. 
HIER ERSCHEINT MIR EIN NEGATIVER Wert eher ungewöhnlich.
Für ein MT48LC128M4A2 wäre zB. max=1.5 und min=-0.8