Signale verzögern IDELAY

[Gustl B. (-gb-)]

Mojn,

ich habe eine generelle Frage, aber auch eine konkrete Anwendung.

Das ist eine Platine mit ADC und SPI, zwischen der Platine und dem FPGA 
sitzt ein Digitalisolator. Der verzögert die Signale um ein paar ns. 
Jetzt geht also die SPI_CLK und das SPI_CONV vom FPGA zum ADC und die 
SPI_DO gehen vom ADC zum FPGA, aber eben deutlich verzögert und leider 
nicht konstant verzögert. Das sind 4 ADCs in einem Stein, also habe ich 
4 SPI_DO Leitungen die durch Layout und Sontiges nicht synchron sind, 
sprich ich möchte die im FPGA einzeln verzögern so dass ich da schön die 
Daten abgreifen kann. Ich habe das schon mit einem schnelleren Takt 
versucht im FPGA um so den Zeitpunkt des Abgriffs etwas feiner 
verschieben zu können, aber das reicht nicht. Also ja, es funktioniert, 
auch ohne Fehler, aber das ist dann sehr filigran und sobald es dann 
wärmer oder kälter wird liefert einer der ADCs keine brauchbaren Daten.

Ich möchte jetzt also viele IDELAYs verwenden und zwar konfigurierbar.

So, wenn ich diesen Wizard dann durchklicke bekomme ich folgendes 
Template:

component selectio_wiz_0
generic
 (-- width of the data for the system
  SYS_W       : integer := 1;
  -- width of the data for the device
  DEV_W       : integer := 1);
port
 (
  -- From the system into the device
  data_in_from_pins       : in    std_logic_vector(SYS_W-1 downto 0);
  data_in_to_device       : out   std_logic_vector(DEV_W-1 downto 0);

-- Input, Output delay control signals
  delay_clk               : in    std_logic;
  in_delay_reset          : in    std_logic;                    -- Active high synchronous reset for input delay
  in_delay_data_ce        : in    std_logic_vector(SYS_W -1 downto 0);                    -- Enable signal for delay 
  in_delay_data_inc       : in    std_logic_vector(SYS_W -1 downto 0);                    -- Delay increment (high), decrement (low) signal
  in_delay_tap_in         : in    std_logic_vector(5*SYS_W -1 downto 0); -- Dynamically loadable delay tap value for input delay
  in_delay_tap_out        : out   std_logic_vector(5*SYS_W -1 downto 0); -- Delay tap value for monitoring input delay
  delay_locked            : out   std_logic;                    -- Locked signal from IDELAYCTRL
  ref_clock               : in    std_logic;                    -- Reference Clock for IDELAYCTRL. Has to come from BUFG.
 
-- Clock and reset signals
  clk_in                  : in    std_logic;                    -- Fast clock from PLL/MMCM 
  io_reset                : in    std_logic);                   -- Reset signal for IO circuit
end component;

Wofür ist delay_clk? Braucht das dieser IDLAY Baustein im FPGA?
Was ist in_delay_data_inc? Die Beschreibung ist "Delay increment (high), 
decrement (low) signal", aber was soll ich dann mit dem IO machen? Lege 
ich ihn konstant auf eine '1' wird das Delay dauernd erhöht, lege ich 
das fest auf eine '0' wird es verringert. Offen lassen?
in_delay_tap_in ist klar, das ist der Wert für die Verzögerung, aber 
wofür hat der Baustein noch ein in_delay_tap_out? Das kann ich offen 
lassen?
Und noch eine Clock ref_clock und noch eine clk_in. Kann ich alle drei 
Clocks verbinden, also meine 100 MHz Clock im FPGA mit allen Clocks 
delay_clk, ref_clock und clk_in verbinden?

Vielen Dank!

Edit:
Wie kann ich eigentlich die maximale Verzögerung berechnen? Wenn meine 
Clock im FPGA 100 MHz hat, wie groß ist das Delay von einem Tap? Hängt 
die von dder Clock ab? Kann ich das Signal mit den 31 Taps um einen 
vollen Takt der 100 MHz Clock verzögern oder nur um deutlich weniger?

In einem Datenblatt zum Spartan6 habe ich was von etwas über 50 ps je 
Tap gelesen aber von maximal 63 Taps, bei der Serie 7 steht was von 31 
Tpas aber knapp über 70 ps je Tap. Das ist ziemlich gering das Delay 
wenn das so fest ist und nicht vom Takt abhängt.

[Christian R. (supachris)]

Ja das Delay ist nicht viel. Bei der 7er Serie muss der Referenz Clock 
200 oder 300MHz haben, das ergibt dann max. 63*78.125ps Delay bei 
200MHz.
Für deine Anwendung sind diese IDELAY nicht gedacht, die sind für DDR 
Speicher und sowas.
Ansonsten musst du bei solchen komplexen Dingen die entsprechenden 
Kapitel im User Guide lesen, für die IDELAY wäre das der SelectIO 
UserGuide.

[Gustl B. (-gb-)]

Christian R. schrieb:
> Für deine Anwendung sind diese IDELAY nicht gedacht, die sind für DDR
> Speicher und sowas.

Naja, aber ich kann die auch als SDR konfigurieren. Wie sollte ich mein 
Problem denn sonst lösen? Einen noch höheren Takt im FPGA und damit dden 
Abtastzeitpunkt feiner wählen?

Oder einen MMCM den ich dann umkonfiguriere und die Abtastclock 
verschiebe?

[Achim S. (Gast)]

Gustl B. schrieb:
> Das ist ziemlich gering das Delay
> wenn das so fest ist und nicht vom Takt abhängt.

Das Delay ist primär nicht vom Takt abhängig. (Na ja, bei einigen 
Devices ist es geringfügig über den RefCLK verstellbar. Aber das ist 
nicht dazu gedacht, das Delay eines Taps zu verstimmen. Sondern es ist 
im Gegenteil dazu gedacht, das Delay eines Taps konstant auf einem 
definierten Wert zu halten wenn die Temperatur oder die Spannung sich 
ändern).

Welche Bausteinfamilie und welche Wizard-Version hast du verwendet, um 
den obigen Code zu erzeugen? Die Implementierungsdetails hängen davon 
ab.

Gustl B. schrieb:
> Wofür ist delay_clk? Braucht das dieser IDLAY Baustein im FPGA?
> Was ist in_delay_data_inc?

Ich würde es folgendermaßen erwartet: wenn bei einer Taktflanke auf 
delay_clk das Signal in_delay_data_ce high ist, dann wird der Delay um 
einen Schritt erhöht (falls in_delay_data_inc high ist) oder erniedrigt 
(falls in_delay_data_inc low ist).

Um den Delay-Wert festzuhalten muss also in_delay_data_ce low sein.

Du hast jetzt offenbar gleichzeitig noch die Möglichkeit, den Delay-Wert 
über in_delay_tap_in parallel zu laden. Ich bin nicht sicher, wie das 
gesteuert wird (vielleicht über in_delay_reset?) Wie gesagt: die 
Implementierungsdetails hängen von der Bauteilfamilie ab, und die 
verschiedenen Wizard-Versionen können sich ebenfalls unterscheiden.

Gustl B. schrieb:
> Wie sollte ich mein
> Problem denn sonst lösen?

Um wie viel liegen die Signale vom ADC denn auseinander? Mit einer ns 
kann man ja schon ziemlich gewaltige Layoutunterschiede ausgleichen.

[Gustl B. (-gb-)]

Achim S. schrieb:
> Welche Bausteinfamilie und welche Wizard-Version hast du verwendet, um
> den obigen Code zu erzeugen? Die Implementierungsdetails hängen davon
> ab.

Artix7 und 5.1

Achim S. schrieb:
> Um den Delay-Wert festzuhalten muss also in_delay_data_ce low sein.

OK, vielen Dank! Jetzt will ich da ladbare Werte, ich habe also noch den 
in_delay_tap_in. Muss ich da auch das in_delay_data_ce auf '1' setzen um 
den Wert zu laden? Finde ich seltsam, weil ich ja nur den Wert laden 
möchte aber kein inc/dec gleichzeitig passieren soll.

Achim S. schrieb:
> Um wie viel liegen die Signale vom ADC denn auseinander? Mit einer ns
> kann man ja schon ziemlich gewaltige Layoutunterschiede ausgleichen.

Gute Frage. Ich sollte das natürlich erstmal messen, aber ich habe die 
Hardware nicht hier. Nach dem Verhalten sind das glaube ich sogar 
mehrere ns, kann aber irgendwie nicht sein. Das Layout macht das nicht 
so schlimm, aber der Digitalisolator hat diese Eckdaten:

• Precise timing (typical):
• 10 ns propagation delay
• 1.5 ns pulse width distortion
• 0.5 ns channel-channel skew
• 2 ns propagation delay skew
• 5 ns minimum pulse width

Ich werde da auch nicht schlau draus wie ich da jetzt den Worst-Case 
errechne. Betrieben wird das Interface mit 100 MHz SPI_CLK.

Jedenfalls, der MMCM kann die Phase verschieben, das ist schonmal gut. 
Ich brauche dann aber eben viele unterschiedliche Clocks. Vielleicht ist 
höher Takten sinnvoller. Bisher bin ich selten über die 100 MHz 
rausgegangen. Welchen Takt kann so ein Artix wenn der Takt nicht zum 
Rechnen verwendet wird? Also nur Daten in ein Register übernehmen.

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

Gustl B. schrieb:
> der Digitalisolator
Welcher denn?

> hat diese Eckdaten:
> • Precise timing (typical)
Der scheint mir schon von den typischen Werten her überaus 
grenzwertig. Zumindest die 5ns minimale Pulsdauer lässt sich bei 100MHz 
nur einhalten, wenn das TV genau 50% ist...

[Achim S. (Gast)]

Gustl B. schrieb:
> Jetzt will ich da ladbare Werte, ich habe also noch den
> in_delay_tap_in. Muss ich da auch das in_delay_data_ce auf '1' setzen um
> den Wert zu laden? Finde ich seltsam, weil ich ja nur den Wert laden
> möchte aber kein inc/dec gleichzeitig passieren soll.

Ich finde es auch seltsam. Denn eigentlich würde ich erwarten, dass es 
auch noch einen load-Eingang geben sollte, der die parallele Übernahme 
der Delay-Werte steuert. Siehe S. 121 von 
https://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf

Das wird aber tatsächlich beim Wizard-Lauf nicht miterzeugt. Ich kann 
dir leider auch nicht sagen, was da los ist.

Gustl B. schrieb:
> aber der Digitalisolator hat diese Eckdaten

Ok: mit dem Clock in die eine Richtung mit einem Delay von mehr als 
einem Taktzyklus, und dann mit den Daten in die Gegenrichtung nochmal 
das selbe. Diesen Gesamtdelay kannst du auf keinen Fall über idelays 
ausgleichen.

Ich würde versuchen:
- den SPI-Takt in Vorwärtsrichtung nur über einen Kanal übertragen 
(selbst wenn mehrere ADCs dranhängen sollten - sonst bekommst du hier 
schon vermeidbaren skew)
- in der Logik einen oder zwei Takte Latenz einfügen, um die grob 20ns 
Hin- und Rücklaufzeit zu berücksichtigen (Die Daten kommen also nicht, 
wenn du die SPI-Taktflanke abschickst, sondern erst ein oder zwei Takte 
später)
- eine phasenverschobene Clock aus dem Clock-Manager nehmen, um grob ins 
mittlere Datenauge aller ADC-Datenpins zu treffen.
- wenn dann noch nötig kannst du ggf. noch idelays einsetzen, um den 
Skew zwischen den ADC-Datenpins auszugleichen. Ich könnte mir aber 
vorstellen, dass das gar nicht mehr nötig sein wird (weil der Skew 
deutlich unter der Bitzeit liegt).

Wenn du wirklich den Abtastzeitpunkt mit idelays fein einstellen musst, 
ist die Methode mit einzelnen inc-Schritten gar nicht so verkehrt. Man 
fährt den Delay erst in die eine Richtung bis Bitfehler kommen (also 
falsche ADC-Werte angezeigt werden). Dann macht man das selbe in die 
Gegenrichtung. Und dann setzt man sich auf den Mittelwert der beiden 
Fehlergrenzen.

Lothar M. schrieb:
> umindest die 5ns minimale Pulsdauer lässt sich bei 100MHz
> nur einhalten, wenn das TV genau 50% ist...

Stimmt: der ADUMxxx ist für diese Anwendung schon grenzwertig..

[Gustl B. (-gb-)]

So, ich habe ja Ferien, also Simulator angeworfen und den IDELAY 
reingeworfen. Den TAP kann man auch über das CE schön laden. Also gehe 
ich den einfach durch von 0 bis 31 und gucke in der 
poss-synthesis-timing-simulation nach wie das verschoben wird. Aber das 
funktioniert irgendwie nicht. Das Delay bleibt konstant.

Lothar M. schrieb:
> Welcher denn?

https://www.mouser.de/datasheet/2/368/Si866x-1223680.pdf

Achim S. schrieb:
> Ich finde es auch seltsam. Denn eigentlich würde ich erwarten, dass es
> auch noch einen load-Eingang geben sollte, der die parallele Übernahme
> der Delay-Werte steuert. Siehe S. 121 von
> 
https://www.xilinx.com/support/documentation/user_guides/ug471_7Series_SelectIO.pdf
>
> Das wird aber tatsächlich beim Wizard-Lauf nicht miterzeugt. Ich kann
> dir leider auch nicht sagen, was da los ist.

Danke! Dann werde ich das Teil mal nativ bespaßen müssen ...

Achim S. schrieb:
> Stimmt: der ADUMxxx ist für diese Anwendung schon grenzwertig..

Ne, ist kein ADUM sondern 
https://www.mouser.de/datasheet/2/368/Si866x-1223680.pdf

Achim S. schrieb:
> Diesen Gesamtdelay kannst du auf keinen Fall über idelays
> ausgleichen.

Sehe ich jetzt auch ein.

> Ich würde versuchen:
> - den SPI-Takt in Vorwärtsrichtung nur über einen Kanal übertragen
> (selbst wenn mehrere ADCs dranhängen sollten - sonst bekommst du hier
> schon vermeidbaren skew)

Das ist ein LTC2325, also mehrere ADCs in einem Stein, aber nur eine 
Clock dorthin. Ja, der Stein liefert auch eine verzögerte Clock zurück, 
aber die habe ich nicht angeschlossen, da die IOs voll waren und ich 
dachte die fixe Verzögerung bekomme ich auch anders hin.

> - in der Logik einen oder zwei Takte Latenz einfügen, um die grob 20ns
> Hin- und Rücklaufzeit zu berücksichtigen (Die Daten kommen also nicht,
> wenn du die SPI-Taktflanke abschickst, sondern erst ein oder zwei Takte
> später)

Klar, habe ich ja auch gemacht. Funktioniert ja prinzipiell, ist aber 
nicht robust gegen Temperaturschwankungen und so.

> - eine phasenverschobene Clock aus dem Clock-Manager nehmen, um grob ins
> mittlere Datenauge aller ADC-Datenpins zu treffen.

Das werde ich mal testen.

> - wenn dann noch nötig kannst du ggf. noch idelays einsetzen, um den
> Skew zwischen den ADC-Datenpins auszugleichen. Ich könnte mir aber
> vorstellen, dass das gar nicht mehr nötig sein wird (weil der Skew
> deutlich unter der Bitzeit liegt).

Darum geht es mir eigentlich. Von den vier SPI_DOs der vier ADCs bekomme 
ich die Daten. So wie das jetzt ist, bekomme ich die Daten korrekt. Aber 
wenn ich auf die Platine fasse bekomme ich die Daten von einem der ADCs 
nichtmehr sauber. Wenn ich dann so einstelle, dass diese Daten robust 
erfasst werden und ich auf die Platine fasse, dann bekomme ich die Daten 
der anderen 3 ADCs nichtmehr sauber. Mit meiner 200 MHz Sampleclock kann 
ich mit steigender und fallender Flanke auf 2.5 ns genau einstellen. So 
wie es jetzt ist bekomme ich alle Daten. Wenn ich 2.5 ns in eine 
Richtung gehe bekomme ich die von einem ADC super robust, aber die der 
anderen ADCs weniger robust. Gehe ich 2.5 ns in die andere Richtung 
bekomme ich die Daten der 3 ADCs robust, die des einen ADCs aber weniger 
robust. In der Mitte ist es jetzt optimal, aber auch nicht super. Ich 
würde das also gerne für jedes einzelne SPI_DO getrennt bauen wollen.

> Wenn du wirklich den Abtastzeitpunkt mit idelays fein einstellen musst,
> ist die Methode mit einzelnen inc-Schritten gar nicht so verkehrt. Man
> fährt den Delay erst in die eine Richtung bis Bitfehler kommen (also
> falsche ADC-Werte angezeigt werden). Dann macht man das selbe in die
> Gegenrichtung. Und dann setzt man sich auf den Mittelwert der beiden
> Fehlergrenzen.

Stimmt. Aber woran erkenne ich Fehler auf einer SPI-Verbindung? Im FPGA 
erstmal garnicht. Der kann das also nicht irgendwie bei jedem Boot oder 
einmal die Stunde autotunen. Daher hätte ich gerne einen händisch 
getunten Wert den ich dann reinladen kann. Wobei das wäre ja dann ein 
fixed Delay, das ist einstellbar. Hm, also mal händisch hoch und runter 
fahren und dann den Wert irgendwie auslesen und hart einbauen. Mal 
gucken. Vermutlich mache ich die Sampleclock für jeden der SPI_DOs 
einzeln verstellbar.

[Achim S. (Gast)]

Gustl B. schrieb:
> Ja, der Stein liefert auch eine verzögerte Clock zurück,
> aber die habe ich nicht angeschlossen, da die IOs voll waren und ich
> dachte die fixe Verzögerung bekomme ich auch anders hin.

Sehr schade: das hätte viel Arbeit gespart und wäre um Klassen robuster, 
als alles, was du ohne den rückgeführten Clock bauen kannst.

Gustl B. schrieb:
> Gehe ich 2.5 ns in die andere Richtung
> bekomme ich die Daten der 3 ADCs robust, die des einen ADCs aber weniger
> robust.

der Channel-Channel-Skew deines Isolators kann bis zu 2,5ns betragen. 
Kommt also grob hin.

Dagegen helfen die idelays schon. Wenn die Werte aber mit der Temperatur 
weglaufen, hast du ein Problem.

[Sigi (Gast)]

Mach doch mal Folgendes: Taste deine DO-Signal mit
hoher Frequenz (400MHz, DDR-IOs) ab und lass dir
das Ergebnis z.B. per Vivado-LogicAnalyzer (siehe
Vivado Design Suite Tutorial: Programming and Debugging)
anzeigen. Dann siehst du ja die Abweichungen im
Realbetrieb (Platine "anfassen", bewegen, Temperatur
ändern usw.), ob z.B. alle DOs "gleichzeitig" ankommen
etc. Sind die Verzögerungen nur ein paar ns, dann
kannst du IDELAYs einsetzen, wenn grösser dann mit
eigener PLL/DCM/etc. je DO. Ist die Varianz in der
jeweiligen Verzögerung zu gröss, dann wird dir wohl
nichts anderes übrig bleiben, als das SPI-Interface
mit niedrigerem Takt zu betreiben.

(Schade für dich ist, dass die Clock nicht auch über die
Digitalisolatoren verzögert zurückgeliefert werden,
aber bei zu unterschiedlichen Verzögerungen zwischen
den einzelnen DOs hätte dir das auch nichts gebracht,
in diesem Fall bräuchtest du dann je DO eine eigene
Clock inkl. Digitalisolator-Kanal.)

[Christian R. (supachris)]

Gustl B. schrieb:
> Daher hätte ich gerne einen händisch
> getunten Wert den ich dann reinladen kann. Wobei das wäre ja dann ein
> fixed Delay, das ist einstellbar. Hm, also mal händisch hoch und runter
> fahren und dann den Wert irgendwie auslesen und hart einbauen.

So mache ich das üblicherweise, wenn ich die IDELAYs einsetze, z.B. hier 
an einem 500MS/s ADC. Mit dem ILA Core kann man das in der 
Prototypenphase ganz gut ausprobieren, am besten noch einen VIO Core 
dazu, da kann man das Delay gleich per JTAG einstellen. Vielleicht hat 
dein ADC ja auch so einen Test Pattern Mode? Das ist sehr hilfreich für 
sowas.

[Schlumpf (Gast)]

Ich werde das Gefühl nicht los, dass das Verzögern der Signale nicht 
zielführend ist.

SPI schreibt mit der einen und liest mit der entgegengesetzen Flanke.
Deine SDOs haben also ca 1/2 Takt Zeit, beim FPGA "anzukommen".
Sie müssen nicht gleichzeitig ankommen, aber sie müssen zum Zeitpunkt 
der Übernahmeflanke des SCK stabil und konsistent sein.

Ohne dein konkretes Problem genauer zu kennen würde ich vermuten, dass 
du hier eine eher unpassende Lösung anstrebst.

[Achim S. (Gast)]

Schlumpf schrieb:
> SPI schreibt mit der einen und liest mit der entgegengesetzen Flanke.
> Deine SDOs haben also ca 1/2 Takt Zeit, beim FPGA "anzukommen".

Die SDOs brauchen dafür aber tatsächlich mehr als 2 volle Taktzyklen, 
weil die Signale zwei mal über die Digitalisolatoren mit ihren langen 
propagation delays müssen (der SPI-Takt in eine Richtung, die SPI-Daten 
in die Gegenrichtung, macht >= 20ns delay).

Und selbst der Skew zwischen den einzelnen Datensignalen kann schon 1/2 
Takt oder mehr betragen. Um wenigstens den Skew auszugleichen können die 
idelays schon sinnvoll sein.

Schlumpf schrieb:
> Ohne dein konkretes Problem genauer zu kennen

Das konkrete Problem ist der lange und schlecht definierte delay der 
Digitalisolatoren.

[Schlumpf (Gast)]

Achim S. schrieb:
> Die SDOs brauchen dafür aber tatsächlich mehr als 2 volle Taktzyklen,

Ok, diese Info hab ich dann vermutlich irgendwo überlesen, oder du hast 
sie nicht angegeben.

Ich sehe es als extrem kritisch an, das per Delays hinzuschubsen.

Du wirst z.B. beim ADC im Datenblatt ziemlich sicher keine Angabe über 
den minimalen tco finden. Sondern nur einen Maximalwert.

So wirst du das nicht 100% sauber dimensionieren können, indem du 
irgendwelche Delays einbaust.

Hast du mal die Typenbezeichnung des ADC und des Isolators?

Spricht was dagegen, den SPI Takt langsamer zu machen?

[Christian R. (supachris)]

Hinzu kommt, dass die Hersteller extrem ungerne das Part-to-Part Skew 
angeben. Es kann also gut sein dass es mit einer Platine dann gerade so 
läuft und mit der nächsten nicht.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Schlumpf schrieb:
> Hast du mal die Typenbezeichnung des ADC und des Isolators?

Diese Informationen hat der TE doch schon vor langem gegeben: LTC2325 
und Si866x.

> Spricht was dagegen, den SPI Takt langsamer zu machen?

5MS/s * 16Bit ergeben schon eine Nettodatenrate von 80MBit/s pro Kanal. 
Und zwischendurch muss ja /CS auch mal kurz inaktiv werden. Also werden 
schon die vollen 100MS/s benötigt, und das auf allen vier Kanälen 
gleichzeitig.

Letztendlich muss man sich da entscheiden, ob DDR mit 50MHz oder SDR mit 
100MHz besser sind.

Die größte Fehlerentscheidung war dabei offenbar die fehlende 
Taktrückführung vom ADC zum FPGA, auch wenn dafür eigentlich kein Pin 
mehr zur Verfügung stand.

[Achim S. (Gast)]

Schlumpf schrieb:
> Ok, diese Info hab ich dann vermutlich irgendwo überlesen, oder du hast
> sie nicht angegeben.

Ich bin nicht der TO, ich hab die Info aus seinen Beschreibungen.

Schlumpf schrieb:
> Hast du mal die Typenbezeichnung des ADC und des Isolators?

Ja, hat der TO alles schon angegeben:

Gustl B. schrieb:
> https://www.mouser.de/datasheet/2/368/Si866x-1223680.pdf

Gustl B. schrieb:
> Das ist ein LTC2325

Schlumpf schrieb:
> Spricht was dagegen, den SPI Takt langsamer zu machen?

Ich vermute mal, dass er in seinem Messsystem eine möglichst hohe 
Abtastrate hinbekommen will (ist aber wie gesagt nur meine Vermutung).

Christian R. schrieb:
> Hinzu kommt, dass die Hersteller extrem ungerne das Part-to-Part Skew
> angeben.

Wenn ich es richtig sehe können alle skew-empfindlichen Signale über 
einen Isolator laufen - es zählt also nur der Channel-Channel Skew (der 
aber ebenfalls schon kritisch sein kann). Nur wenn er eine Serie von 
Messkarten erstellen würde müsste er sich Gedanken über den Part-to-Part 
Skew machen.

[Duke Scarring (Gast)]

Andreas S. schrieb:
> die fehlende Taktrückführung vom ADC zum FPGA,
Prinzipiell kann der ADC das.

Bei diesen Datenraten würde ich eher auf das LVDS-Interface setzen.

Duke

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Andreas S. schrieb:
> Und zwischendurch muss ja /CS auch mal kurz inaktiv werden.

Argh, das ist natürlich Unsinn. Die Ansteuerung erfolgt natürlich 
mittels /CNV. Aber trotzdem wird das den einen oder anderen Taktzyklus 
kosten.

[Schlumpf (Gast)]

Andreas S. schrieb:
> Diese Informationen hat der TE doch schon vor langem gegeben: LTC2325
> und Si866x.

Huch, das habe ich überlesen. Sorry.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Duke Scarring schrieb:
> Bei diesen Datenraten würde ich eher auf das LVDS-Interface setzen.

Ja, der Hauptgrund für LVDS bestünde bei der hohen Wandlerauflösung aber 
darin, dass die Stromaufnahme zwar höher, aber deutlich weniger vom 
ausgegebenen Bitmuster abhinge, so dass das entsprechende "Klingeln" auf 
den Versorgungsleitungen geringer wäre. Und der deutlich geringere 
Spannungshub ist auch nicht von Nachteil.

Da ich zu faul zum Suchen bin: gibt es schon Isolatoren mit 
LVDS-Eingängen?
Sind sie ausgangsseitig unabhängig davon auf LVDS oder Single Ended 
einstellbar?

[-gb- (Gast)]

Das scheint euch zu interessieren, vielen Dank! Also, ich verwende 
diesen ADC sehr gerne und ohne Isolator habe ich den Clockout nie 
gebraucht. Mit Isolator brauche ich den auch nicht, es funktioniert ja. 
Der Clockout wäre ja auch von dem Skew betroffen, also wenig hilfreich.

LVDS habe ich nicht gemacht weil das a) noch mehr IOs braucht und b) wie 
bekomme ich das über einen Isolator? Wären dann die zwei Kondensatoren 
der AC Kopplung die Isolation?

Ich habe /CNV und die SPI_clock unter meiner Kontrolle, das sollte 
eigentlich genügen. Jetzt suche ich einen Weg wie ich für jedes einzelne 
Datensignal den Erfassungszeitpunkt einstellen kann. Ich werde jetzt 
erstmal gucken wie hoch ich takten kann und dann einstellbar machen im 
wievielten Takt die Daten übernommen werden.

[Achim S. (Gast)]

-gb- schrieb:
> LVDS habe ich nicht gemacht weil das a) noch mehr IOs braucht und b) wie
> bekomme ich das über einen Isolator?

so:
https://www.analog.com/en/parametricsearch/11058

Reduziert dein Problem schon mal deutlich, und mit rückgeführter Clock 
wäre es dann ein sehr zuverlässiges und robustes System.

-gb- schrieb:
> Mit Isolator brauche ich den auch nicht, es funktioniert ja.

Na ja, nur dass du halt die falschen Daten einliest. Oder zumindest die 
Gefahr dafür besteht, sobald der delay sich aufgrund der Temperatur... 
verschiebt.

[Schlumpf (Gast)]

Andreas S. schrieb:
> Diese Informationen hat der TE doch schon vor langem gegeben: LTC2325
> und Si866x.

Huch, das habe ich überlesen. Sorry.

Also du führst die 4 SDOs über einen Koppler.
Damit sollte der Skew der 4 SDOs untereinander kleiner als 2,5ns sein.
(Channel-Channel-Skew des Kopplers = typ: 0,4ns / max: 2,5ns)

Hinzu kommt noch ein Skew, den dein ADC macht. Aber den Wert habe ich 
auf die Schnelle nicht gefunden.

Ein weiterer Skew entsteht natürlich auch im FPGA vom Pin zu den vier 
Sampleregistern.
Hast da mal geschaut, wie groß der ist?

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

-gb- schrieb:
> Der Clockout wäre ja auch von dem Skew betroffen, also wenig hilfreich.

Wenn man Clockout verwendet, entfällt aber eine der Signallaufzeiten 
durch den Isolator.

> LVDS habe ich nicht gemacht weil das a) noch mehr IOs braucht und b) wie
> bekomme ich das über einen Isolator? Wären dann die zwei Kondensatoren
> der AC Kopplung die Isolation?

LVDS ist nicht gleichspannungsfrei, so dass es nicht ausreicht, 
Koppelkondensatoren zu verwenden.

[Schlumpf (Gast)]

Wenn du den angepassten Takt des ADCs nicht verwendest, hat du ein 
prinzipielles Problem.

Verwendest du ihn, gehen in deine Betrachtung ausschließlich die Skews 
ein, die recht gering sind.

Verwendest du ihn nicht, dann geht zusätzlich die Differenz zwischen 
minimalem und maximalem Propagation Delay ein und zusätzlich noch die 
Differenz zwischen minimalem und maimalem tco.

Damit ist es dann m.E. ausgeschlossen, das System für hohe Taktraten 
sauber zu dimensionieren.

Es ist dann lediglich noch eine Dimensionierung mit sehr langsamen 
Taktraten möglich, wo die Summe der Propagation Delays in eine halbe 
Taktperiode "passen". Und das wäre dann extrem langsam.

Mein Fazit wäre:
Du MUSST den Clockout mit verwenden, sonst wird es dir nicht gelingen, 
ein garantiert stabiles System mit hohen Taktraten zu dimensionieren.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Achim S. schrieb:
> https://www.analog.com/en/parametricsearch/11058
>
> Reduziert dein Problem schon mal deutlich, und mit rückgeführter Clock
> wäre es dann ein sehr zuverlässiges und robustes System.

Ja, die Bausteine sind interessant:
- 100 ps maximum pulse skew
- 600 ps maximum part to part skew

Selbst wenn man also die Datensignale auf mehrere Bausteine (2*ADN4650 
für die Daten, 1*ADN4651 für Takt hin und zurück, /CNV fehlt noch...) 
aufteilt, ist der Skew offenbar deutlich geringer als bei einem 
einzelnen Si866x.(*)

> -gb- schrieb:
>> Mit Isolator brauche ich den auch nicht, es funktioniert ja.
>
> Na ja, nur dass du halt die falschen Daten einliest. Oder zumindest die
> Gefahr dafür besteht, sobald der delay sich aufgrund der Temperatur...
> verschiebt.

Genau.

Zu (*): Dies soll kein Si866x-Bashing werden! Ich habe Bausteine dieser 
Baureihe schon für etliche Baugruppen (auch mit langsamem SPI) 
eingesetzt und bisher damit nur gute Erfahrungen gemacht.

[Gustl B. (-gb-)]

Andreas S. schrieb:
> Wenn man Clockout verwendet, entfällt aber eine der Signallaufzeiten
> durch den Isolator.

Ja, aber die ist für alle Datensignale dann konstant und somit im FPGA 
ausgleichbar und habe ich ausgeglichen.

Achim S. schrieb:
> so:
> https://www.analog.com/en/parametricsearch/11058
>
> Reduziert dein Problem schon mal deutlich, und mit rückgeführter Clock
> wäre es dann ein sehr zuverlässiges und robustes System.

Das kannte ich nicht, danke.

Andreas S. schrieb:
> LVDS ist nicht gleichspannungsfrei, so dass es nicht ausreicht,
> Koppelkondensatoren zu verwenden.

OK.

Schlumpf schrieb:
> Verwendest du ihn nicht, dann geht zusätzlich die Differenz zwischen
> minimalem und maximalem Propagation Delay ein und zusätzlich noch die
> Differenz zwischen minimalem und maimalem tco.

Ja, aber das Delay das konstant ist, ist mir egal. Das kann ich im FPGA 
ausgleichen und habe ich auch ausgeglichen. Das Problem jetzt ist, dass 
ich derzeit alle Detensignale zum gleichen Zeitpunkt erfasse und da 
manche eher knapp getroffen werden. Daher möchte ich die einzeln zu 
einem jeweils optimalen Zeitpunkt erfassen. Ich dachte da an die IDELAY 
Bausteine weil die halt schon da sind, werde das aber jetzt mal mit 
einer schnellen Clock versuchen.

[Schlumpf (Gast)]

Gustl B. schrieb:
> Ja, aber das Delay das konstant ist, ist mir egal.

Das Delay im Isolator ist aber nicht konstant.. Und da liegt der Hase im 
Pfeffer.

[Gustl B. (-gb-)]

Das Delay von der Clock und CNV hin zum ADC und das Delay im ADC bis die 
SDOs vom ADC zum Isolator kommen ist aber einheitlich. Das verschiebt 
mir die SDOs gegenüber der Clock und dem CNV um eine Zeit die für alle 
SODs gleich ist. Dann kann ich diese also immer noch zum gleichen 
Zeitpunkt abgreifen. Wie ich das verstehe kommen alle SDOs gleichzeitig 
vom ADC am Isolator an. Hinter dem Isolator zum FPGA kommen sie aber 
nichtmehr gleichzeitig an. Da habe ich nurnoch ein kurzes Fenster in dem 
die gleichzeitig korrekt sind, ich suche daher nach einer Möglichkeit 
wie ich die einzeln optimal erfasse. Aber vielleicht meinst du auch 
etwas Anderes.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Gustl B. schrieb:
> Ja, aber das Delay das konstant ist, ist mir egal. Das kann ich im FPGA
> ausgleichen und habe ich auch ausgeglichen.

Das Delay ist nicht konstant, sondern natürlich temperatur-, spannungs- 
und mondphasenabhängig. Bei Verwendung der Taktrückführung über 
denselben (oder zumindest einen baugleichen elektrisch und thermisch 
gekoppelten) Baustein hebt sich nicht nur das Delay auf, sondern auch 
dessen Drift. Der Skew spielt im Vergleich dazu kaum eine Rolle, sondern 
lenkt Dich nur von dem eigentlichen Problem ab.

Folglich solltest Du irgendwie die Taktrückführung hinbekommen. 
Sinnvollerweise solltest Du auch /CNV zurückführen und einlesen, um 
dessen Phasenlage zu bestimmen, und sei es nur testweise mittels ILA.

[Schlumpf (Gast)]

Gustl B. schrieb:
> Das Delay von der Clock und CNV hin zum ADC und das Delay im ADC bis die
> SDOs vom ADC zum Isolator kommen ist aber einheitlich

Richtig... nahezu einheitlich.

Dann macht der Isolator einen Skew von wenigen ns dazu.

Würdest du den Takt auch über den Isolator führen, dann wäre dieser auch 
nur von diesem Skew betroffen.


Die LATENZ aber ist hochgradig abhängig von Temperatur, Prozess, 
Spannung etc..

Und um diese keineswegs konstante Latenz willst du jetzt deinen 
Abtastzeitpunkt im FPGA um eine konstante Zeit verschieben.

Und das beißt sich schon strukturell.

[Gustl B. (-gb-)]

OK, verstanden. Aber an der Hardware werde ich jetzt nichts mehr ändern, 
funktioniert ja großteils. Ich werde da trotzdem im FPGA den 
Abtastzeitpunkt variabel bauen damit man das nachträglich anpassen kann 
in der Software.

[Andreas S. (Firma: Schweigstill IT) (schweigstill)]

Gustl B. schrieb:
> OK, verstanden. Aber an der Hardware werde ich jetzt nichts mehr ändern,

Dazu fällt mir nur ein:
http://www.roland-schaefer.de/totespferd.htm

[Gustl B. (-gb-)]

Ja schön, was würdest du denn jetzt machen? Hardware neu entwerfen? Die 
jetzige Hardware wird bereits verwendet, es ist nicht 
sicherheitsrelevant, die Temperatur ist dort in einem Keller in einem 
Labor ziemlich konstant und an der Hardware fasst auch keiner was an im 
Betrieb. Das funktioniert also alles. Das was ich machen möchte ist eben 
eine Verbesserung so dass es auch noch robust wird.

Edit:

Für overengeneering und das Reiten toter Pferde bin ich hier bekannt. 
Ich bin eben Amateur und mache Dinge die ich noch nie vorher gemacht 
habe. Da lerne ich jedes Mal dazu, das nächste Mal werde ich also auch 
Clockout anbinden, auch wenn ich dann einen weiteren IO und vielleicht 
einen weiteren Isolatorstein berauche.

[Schlumpf (Gast)]

Gustl B. schrieb:
> Das was ich machen möchte ist eben
> eine Verbesserung so dass es auch noch robust wird

Robust wird es aber nicht, wenn man den Abtastzeitpunkt auf eine Zeit 
legt, die einem unbekannt ist.

Handelt es sich um ein einziges Exemplar?

[Gustl B. (-gb-)]

Ja, Einzelstück.

Ja, der optimale Zeitpunkt ist unbekannt, stimmt, aber kann durch 
Probieren herausgefunden werden. Und wenn ich das jetzt variabel baue, 
dann kann der Benutzer das selber ausprobieren und so einstellen, dass 
es passt. Und zwar für jeden ADC einzeln.

[Schlumpf (Gast)]

m.E. hast jetzt mehrere Möglichkeiten:

1. HW so lassen, wie sie ist und mit nem Oszi messen, wie lange die 
Latenz wirklich ist und den Abtastzeitpunkt irgenwie passend für dieses 
Exemplar und diese Temperatur hin zu fummeln.

2. Zweiten Isolator huckepack auf den ersten setzen und das ClockOut 
Signal mit verwenden.

3. Überlegen, ob du den Isolator wirklich benötigst und falls nicht, 
dann weiter bei Lösung 1 oder 2 ohne Isolator

[Gustl B. (-gb-)]

Schlumpf schrieb:
> 1. HW so lassen, wie sie ist und mit nem Oszi messen, wie lange die
> Latenz wirklich ist und den Abtastzeitpunkt irgenwie passend für dieses
> Exemplar und diese Temperatur hin zu fummeln.

So ist es doch aktuell. Nur dass derzeit alle SDOs zeitgleich übernommen 
werden. Das will ich ändern so dass ich die 4 SDOs gertrennt zu 
unterschiedlichen Zeitpunkten übernehme.

Schlumpf schrieb:
> 2. Zweiten Isolator huckepack auf den ersten setzen und das ClockOut
> Signal mit verwenden.

Dadurch bekomme ich auch keinen zusätzlichen IO am FPGA.

Schlumpf schrieb:
> 3. Überlegen, ob du den Isolator wirklich benötigst und falls nicht,
> dann weiter bei Lösung 1 oder 2 ohne Isolator

Das hat schon einen Grund wieso ich das galvanisch getrennt habe.

[Schlumpf (Gast)]

Gustl B. schrieb:
> So ist es doch aktuell

Und du hast ja selbst festgestellt, dass das ne scheiss Lösung ist.
Ist halt ein Hingefummel ohne Garantie, dass es STABIL tut.
Also die schlechteste aller Lösungen, wenn man eine ROBUSTE Lösung 
anstrebt.
Und es wird auch nicht besser, wenn man die Kanäle einzeln verschieben 
kann.
Denn das prinzipielle Problem bleibt.

Gustl B. schrieb:
> Dadurch bekomme ich auch keinen zusätzlichen IO am FPGA.

Ok, wenn der FPGA bis auf den letzen Pin ausgeknautscht ist, dann ist 
das natürlich blöd.

Gustl B. schrieb:
> Das hat schon einen Grund wieso ich das galvanisch getrennt habe.

Ganz bestimmt...
Eventuell aber ähnlich gut durchdacht, wie der Grund für das Weglassen 
des ClockOut.

Du hast die Ursache für dein Problem ja jetzt erkannt und verstanden. 
Und damit wirst du dann auch die für dich beste Lösung finden können.
Von meiner Seite aus waren es nur Anregungen, was man tun könnte.

[Gustl B. (-gb-)]

Schlumpf schrieb:
> Ok, wenn der FPGA bis auf den letzen Pin ausgeknautscht ist, dann ist
> das natürlich blöd.

Das FPGA nicht, aber es ist ein FPGA-Modul, da sind alle IOs in 
Verwendung.

Schlumpf schrieb:
> Und es wird auch nicht besser, wenn man die Kanäle einzeln verschieben
> kann.
> Denn das prinzipielle Problem bleibt.

Wie oben beschrieben bekomme ich das durch Verschieben so hin, dass es 
für einzelne Kanäle robust ist, aber eben nur für einzelne und nicht für 
alle 4. Mit robust meine ich, dass ich ausser durch Abstecken der 
Platine keine Fehler produzieren konnte (im Rahmen der normalen 
Umgangsmethoden, ich hab da keinen krassen Sender danebengehalten oder 
so, aber schon mal mit dem Finger auf die Pins gelangt). Wenn ich die 
einzeln verstellen kann dann sollte es also möglich sein für alle 
Datenkanäle einen Zeitpunkt zu finden an dem die stabil sind.

Schlumpf schrieb:
> Eventuell aber ähnlich gut durchdacht, wie der Grund für das Weglassen
> des ClockOut.

Mag sein. Messungen haben aber ergeben, dass das gegenüber einem 
Prototypen ohne galvanische Trennung etwas gebracht hat. Die zu 
messenden Signale kommen über Coax aus einem Messgerät und andere 
Signale die ich auch benötige kommen aus einem PC. Beide Massen zusammen 
machen Brumm, daher ist das jetzt getrennt und funktioniert.

Schlumpf schrieb:
> Von meiner Seite aus waren es nur Anregungen, was man tun könnte.

So habe ich das auch verstanden, vielen Dank! Im nächsten Design, 
vielleicht wird es sowas tatsächlich geben da ich mir jetzt zutraue 
FPGAs selber zu löten, wird clockout auf jeden Fall angeschlossen.

[Schlumpf (Gast)]

Gustl B. schrieb:
> Beide Massen zusammen
> machen Brumm, daher ist das jetzt getrennt und funktioniert.

Ok, das ist ein Argument...

So wie ich das Datenblatt des ADC verstehe, kommen alle SDOs 
gleichzeitig und synchronisiert zum ClockOut.

Wenn du die jetzt über deinen Koppler lässt, dann macht der einen 
maximalen Skew von 2,5ns.

Und offenbar liegt jetzt dein Abtastzeitpunkt genau innerhalb dieser 
Varianz.
Bevor du jetzt anfängst, den für jeden Kanal einzeln einstellbar zu 
machen, schiebe ihn doch mal um 3ns nach hinten. Dann solltest du auf 
jeden Fall außerhalb der Einschwingbereichs aller Kanäle sein.

[Bernhard K. (bkom)]

@GustlB.
Eine kleine Zwischenfrage:
  verwendest du Inputflipflops ?
Wenn nein, dann probier doch mal diese zu instanzieren
um zumindest den ungewissen Routindelay im FPGA wegzuhaben.

[Schlumpf (Gast)]

Schlumpf schrieb:
> Ein weiterer Skew entsteht natürlich auch im FPGA vom Pin zu den vier
> Sampleregistern.
> Hast da mal geschaut, wie groß der ist?

Bernhard K. schrieb:
> Eine kleine Zwischenfrage:
>   verwendest du Inputflipflops ?
> Wenn nein, dann probier doch mal diese zu instanzieren
> um zumindest den ungewissen Routindelay im FPGA wegzuhaben.

Das Thema steht auch noch offen...

[Gustl B. (-gb-)]

Schlumpf schrieb:
> Bevor du jetzt anfängst, den für jeden Kanal einzeln einstellbar zu
> machen, schiebe ihn doch mal um 3ns nach hinten.

Wie mache ich das mit den 3 ns? Genau wegen solcher Dinge hatte ich hier 
nach dem IDELAY gefragt. Geht das per Constraint?

Bernhard K. schrieb:
> @GustlB.
> Eine kleine Zwischenfrage:
>   verwendest du Inputflipflops ?
> Wenn nein, dann probier doch mal diese zu instanzieren
> um zumindest den ungewissen Routindelay im FPGA wegzuhaben.

Ich verwende das PerfOptimized_high als Strategie im Vivado. Wenn ich 
mir das im FPGA angucke, dann wird bei jedem SDO in dem IOB der IBUF 
verwendet. Ist das so richtig? Wo setzt man denn explizit diese FFs?

Edit:

Ich gebe zu, dass mich das mit den Constraints bisher wenig interessiert 
hat, ich habe die Clock beschrieben und das hat eigentlich immer 
gereicht. Gibt es irgendwo eine schöne Übersicht über die Constraints 
und auch Beispiele wie man diese verwendet? Das ist für mich ziemlich 
unübersichtlich, die Syntax ist auch nicht gerade das was ich schick 
finde. Nach der Implementierung sind dann auch viele Signale irgendwie 
umbenannt, da weiß ich nicht wie ich die sinnvoll wiederfinde. Am 
liebsten wäre mir überall die Namen verwenden zu können die auch im VHDL 
stehen. Was sind denn die Constraints die man auf jeden Fall beherrschen 
sollte?

[Bernhard K. (bkom)]

Gustl B. schrieb:
> Ich verwende das PerfOptimized_high als Strategie im Vivado. Wenn ich
> mir das im FPGA angucke, dann wird bei jedem SDO in dem IOB der IBUF
> verwendet. Ist das so richtig? Wo setzt man denn explizit diese FFs?

Wird hier für beschrieben:
https://www.xilinx.com/support/documentation/sw_manuals/xilinx11/pce_p_registers_in_iob.htm

Z.B. im UCF:
INST "i_data_s_7" IOB = FALSE; ohne IO-FF
INST "i_data_s_6" IOB = TRUE; mit IO-FF

Das VHDL-Beispiel dazu (hier mit pfui asyncronen reset):

sync : process(i_clk,i_reset)
  begin
    if (i_reset = '1') then
      i_data_s       <= (others => '0');
    elsif (rising_edge(i_clk)) then
      if (i_enable ='1') then
        i_data_s       <= i_data;

Sollte im "Design-Summary" dann in etwa so im Anhang aussehen:

[-gb- (Gast)]

Wie das im ISE ging ist mir klar, aber in Vivado ist das jetzt anders.

[Gustl B. (-gb-)]

set_property IOB true [get_ports <portname>]

So sieht das für Vivado .xdc aus. In der GUI finde ich nichts.

[Schlumpf (Gast)]

Ich kenne mich leider mit Xilinx nicht aus.

Aber lass doch einfach mal deine Sampling-Register mit der anderen 
Flanke takten, als du es jetzt tust.
Wenn du mit der jetzt gewählten Flanke genau den Umschaltpunkt der Daten 
triffst, dann solltest du ja mit der entgegengesetzen Flanke weit genug 
weg sein.