Parallel ADC - Daten einlesen (-> Timing?!)

[Alexander K. (chessat2002)]

Hallo Kollegen!

Es geht um ein Standardproblem:
Ich arbeite mit einem Spartan3AN Starter Kit von Digilant und möchte 
über den FX2 - Connector den parallelen Datenausgang eines ADCs 
einlesen. Der ADC selbst bietet schon einen Taktausgang (100 MHz) an 
(den ich auch über den SMA - Connector ins Borad einspeise und 
verwende), welcher so positioniert ist, dass die Daten bei einer 
Taktflanke bereits stabil anliegen und problemlos gecaptured werden 
können. Die Taktflanke ist also mittig im "Capture - Fenster" platziert.
Soweitsogut. Jetzt frage ich mich natürlich, bzw stelle mir vor, dass 
das Clocksignal und die parallelen Daten jeweils eine unterschiedliche 
Verzögerung bis zu den ersten Registern aufweisen / aufweisen könnten. 
Leider kann ich nicht abschätzen, ob diese Unterschiede relevant sind 
oder nicht. Jedoch denke ich mir, dass ich nach dem P&R ja eigentlich 
jedes Delay im Xlinx Synthesetool (verwende V11.4) "händisch ausmessen" 
können müsste?!
Hat hierfür vielleicht jemand einen Ansatz?

Beste Grüße von Alex'

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Alexander Klinkan schrieb:
> Hat hierfür vielleicht jemand einen Ansatz?
Probiers doch einfach mal mit einem passenden Timing-Constraint:
http://www.xilinx.com/support/documentation/sw_manuals/xilinx11/ug612.pdf
Hier der Abschnitt "OFFSET IN"...

[Alexander K. (chessat2002)]

Hallo!

Besten Dank für deine schnelle Antwort! Hab mal den ganzen Abschnitt 
gelesen und mir ist nun einiges klarer bzw. jetzt hab ich endlich einen 
Plan, wie vorzugehen ist. Der Abschnitt in dem die "SOURCE SYNCHRONOUS" 
- System vorgestellt sind, passt perfekt auf meinen Fall.
Leider bin ich mir trotzdem noch ein wenig unsicher, da ich an den 
externen Clock - Eingang in einem ersten Schritt eine DCM angehängt 
habe.
Von dieser DCM nutze ich den CLK0180 - Ausgang und den CLK2V (halber 
Takt) - Ausgang. So, und das CLK0180 - Signal ist dann genau jenes, mit 
dessen steigender Flanke ich die Daten capture.
Der andere halbe Takt wird für einen anderen Teil der Schaltung 
benötigt, welcher jedoch nichts mit dem Einleseschaltungsteil zu tun 
hat. Dieser andere Teil hat auch Eingangssignale z.B. von einer serielle 
Kommunikation usw. Die Kommunikation der beiden Schaltungsteile 
untereinander erfolgt über einen True-Dual-Ported-RAM.
Ich möchte darauf hinaus, dass meine Constraints jetzt ja eigentlich so 
gesetzt werden müssen, dass klar ist, dass nur der "schnelle" (180° 
versetzte) Takt und die Eingänge die vom "schnellen" Takt eingelesen 
werden, von diesen Constraints betroffen sind.

-> Folglich müsste eigentlich eine einzige Zeile reichen, wobei als 
Bezugs - Clock der Signalname der "schnelle" Clock verwendet wird, also 
z.B:

OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;

CLK_FAST ist in diesem Fall der Name des Signals, dass den Ausgang der 
DCM mit dem Eingang der Capture-Komponente verbindet.

-> Die Capture - Komponente hat auch Eingänge kommend vom RAM, diese 
sind jedoch nicht extern sondern intern (Block - RAMs). Für diese 
Eingänge gilt natürlich nicht das, was für die Daten vom ADC gilt, 
jedoch dürften diese Eingänge ja keine Rolle spielen, da sie ja nicht 
von einem externen Pin kommen _> richtig?.
Trotzdem könnte man ja genau die Dateneingänge spezifizieren, auf die 
die Constraints angewandt werden sollen, z.B. so:

NET “ADC_DATA<0>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
NET “ADC_DATA<1>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
NET “ADC_DATA<2>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
NET “ADC_DATA<3>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
NET “ADC_DATA<4>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
NET “ADC_DATA<5>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
NET “ADC_DATA<6>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
NET “ADC_DATA<7>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
NET “ADC_DATA<8>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
NET “ADC_DATA<9>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;

-> Was sagt ihr dazu? Habe ich irgendwo noch einen brutalen 
Verständnisfehler drinnen oder wäre mein Ansatz so OK?

-> Im Anhang ist noch eine kleine Skizze + ein Ansatz zu meinem UCF - 
File.

Besten Dank für eure Tipps schon im Voraus & Grüße von Alex'

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

> CLK_FAST ist in diesem Fall der Name des Signals, dass den Ausgang der
> DCM mit dem Eingang der Capture-Komponente verbindet.
Spezifizier einfach die Signale, so wie sie an den Pins angeschlossen 
sind. Wenn du intern einen DCM verwendest, kann die Toolchain die 
"internen" Timings zurückrechnen und kontrollieren, ob das zu den Werten 
am Pin passt. Denn ab den Pins kennen die Tolls ja das komplette FPGA. 
Du mußt "nur" das drumrum spezifizieren...

BTW:
> NET “ADC_DATA<0>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
> :
> NET “ADC_DATA<9>” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;
Das liesse sich mit Wildcards etwas abkürzen:
NET “ADC_DATA*” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;

[Alexander K. (chessat2002)]

OK, also könnte ich die Zeile auch folgendermaßen formulieren:

NET “ADC_DATA*” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_SMA” FALLING;

Die DCM invertiert "CLK_SMA" zu "CLK_FAST" (180°). Wäre in diesem Fall 
dann der Toolchain klar, dass es bezogen auf "CLK_FAST" dann nicht mehr 
um "FALLING" sondern um "RISING" geht?

Meine Intuition, die Constraints auf "CLK_FAST" zu beziehen war, dass 
ich für den Teil der mit "CLK_SLOW" betrieben wird, keine Input - 
Constraints angeben möchte. OK, aber da ich ja die Nets direkt angegeben 
habe, auf die sich die Constraints beziehen (ADC_DATA), dürften sowieso 
keine Eingänge zu CLK_SLOW - getakteten  - registern betroffen sein, 
richtig?

Wenn ich alles richtig verstanden habe, müsste es jetzt eigentlich 
folgende 2 möglichkeiten für mich geben:

1) NET “ADC_DATA*” OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_SMA” 
FALLING;
2) OFFSET = IN 5 ns VALID 10 ns BEFORE “CLK_FAST” RISING;

Beides müsste äquivalent umgesetzt werden, oder?
Jedoch ist mir natürloich klar, dass Variante (1) die klarere und 
sauberere sein müsste. Oder ist Variante 2 überhaupt nicht möglich?

Grüße von Alex'