Iodelay (Slack Optimierung)

[Abel (Gast)]

Hallo liebes Forum,

Ich habe eine Frage zu Timingconstraints.

Folgendes Szenario:
Ein DDR-Datensignal & entsprechendes Clk-Signal liegt am FPGA an
und soll eingelesen werden. Genutzt wird ein IDDR

Daten --> FPGA Pads --> IOBUFDS --> IDDR
Clk --> FPGA Pads --> IOBUFDS --> BUFR --> IDDR

Das Post Place & Route Static timing (.twx) ergibt Folgendes:

-------------------------------------------------------------------------------- 
  
 Hold Paths: TIMEGRP "RXA_SIGS" OFFSET = IN 1.75 ns VALID 3.5 ns BEFORE COMP "CLKAB_P" 
         "RISING"; 
 -------------------------------------------------------------------------------- 
  
 Paths for end point Inst_FMC104_ADC_PHY/GEN_IDDR_A[5].IDDR_inst (ILOGIC_X0Y143.DDLY), 2 paths 
 -------------------------------------------------------------------------------- 
 Slack (hold path):      0.089ns (requirement - (clock path + clock arrival + uncertainty - data path)) 
   Source:               CHA_P<5> (PAD) 
   Destination:          Inst_FMC104_ADC_PHY/GEN_IDDR_A[5].IDDR_inst (FF) 
   Destination Clock:    CLKAB_OUT rising at 0.000ns 
   Requirement:          1.750ns 
   Data Path Delay:      5.638ns (Levels of Logic = 1) 
   Clock Path Delay:     7.274ns (Levels of Logic = 2) 
   Clock Uncertainty:    0.025ns

Frage: Das Constraint wird zwar noch erfüllt, aber ich wollte mal Fragen 
ob es Möglichkeiten gibt den Slack zu verbessern (größer werden lassen) 
indem man die Daten über ein IODelay schickt.

Mir stechen dabei diese beiden Zeilen ins Auge:

Data Path Delay:      5.638ns (Levels of Logic = 1) 
Clock Path Delay:     7.274ns (Levels of Logic = 2)

Da müsste doch eigentlich "nur" der Data Path verzögert werden?!
Wie geht man hier am Besten vor um die Werte zu optimieren. Gibt es da 
einen Ansatz im .UCF File entsprechend zu optimieren oder fügt man ein 
IO-Delay ein...?

Gruß
Abel

[daniel__m (Gast)]

hi,

da wirst du selber aktiv werden müssen. Je nach FPGA Familie sind die 
IODELAYs aber auch temperaturabhängig, daher ist evtl. ein permanentes 
nachregeln nötig.

Besser wäre, wenn man der Quelle (z.b. ADC) mitteilen kann, wie der 
Bezug CLK->DATA auszusehen hat, dann hilft diese Angabe:

Worst Case Data Window 1.942; Ideal Clock Offset To Actual Clock -0.027;

Zu Finden im *.twr unter "Data Sheet report"

grüße

[Sigi (Gast)]

Abel schrieb:
> Da müsste doch eigentlich "nur" der Data Path verzögert werden?!

Ja, entweder per IDelay (hängt aber stark von der Familie ab, zu
der du aber nichts schreibst), oder du schleifst deine ADC-CLK
durch eine PLL/DLL/etc. und generierst darüber eine neue
Data-CLK. Der PLL-Ansatz hat bei "kleineren/billigeren" Familien
den Vorteil einer sehr feinen Phasensteuerung, den IDelays nicht
haben, dafür aber Jitter von >100ps. Bei z.B. bei Virtex5/6 hast
dagegen schon IDelays mit Phasen-Taps von 50ps. Da hilft nur
Abwägen und ein Blick in die Datasheets.