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:
in_delay_reset:instd_logic;-- Active high synchronous reset for input delay
16
in_delay_data_ce:instd_logic_vector(SYS_W-1downto0);-- Enable signal for delay
17
in_delay_data_inc:instd_logic_vector(SYS_W-1downto0);-- Delay increment (high), decrement (low) signal
18
in_delay_tap_in:instd_logic_vector(5*SYS_W-1downto0);-- Dynamically loadable delay tap value for input delay
19
in_delay_tap_out:outstd_logic_vector(5*SYS_W-1downto0);-- Delay tap value for monitoring input delay
20
delay_locked:outstd_logic;-- Locked signal from IDELAYCTRL
21
ref_clock:instd_logic;-- Reference Clock for IDELAYCTRL. Has to come from BUFG.
22
23
-- Clock and reset signals
24
clk_in:instd_logic;-- Fast clock from PLL/MMCM
25
io_reset:instd_logic);-- Reset signal for IO circuit
26
endcomponent;
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.
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.
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?
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.
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.
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...
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..
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.pdfAchim 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.pdfAchim 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.
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.
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.)
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.
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.
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.
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?
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.
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.
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.pdfGustl B. schrieb:> Das ist ein LTC2325Schlumpf 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.
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. 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.
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?
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.
-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.
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?
-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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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.
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
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.
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.
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.
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.
@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 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...
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?
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):
1
sync:process(i_clk,i_reset)
2
begin
3
if(i_reset='1')then
4
i_data_s<=(others=>'0');
5
elsif(rising_edge(i_clk))then
6
if(i_enable='1')then
7
i_data_s<=i_data;
Sollte im "Design-Summary" dann in etwa so im Anhang aussehen:
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.