Hallo, es gibt zwar schon einige Threads zu dem Thema hier und im Internet zur Realisierung eines TDC( Time to digital Converter) in einem FPGA. Ich versuche gerade das Problem nicht über eine "carry chain" wie üblich sondern über die (temperaturkompensierte) IDELAY2 Primitive und einem Zynq und 200Mhz (78ps Auflösung) Referenzfrequenz zu lösen. Was anderes habe ich nicht. Ich habe 32 IDELAY2 parallel geschaltet und die jeweiligen Anzapfung auf 0,1,2 usw gesetzt. Ein Startereignis geht gleichzeitig auf alle Eingänge der Verzögerungsleitungen und die nächste Flanke meines Referenzclocks speichert die 32 Anzapfungen. Wie man auf den Bildern sieht ist alles im IO Bereich geroutet nur die Dekodierung der 32 Tabsignale in ein 5 Bit Ausgangssignal nicht. Jetzt meine Frage an die Spezialisten. Auf dem linken Teil ist das Speichersignal RefClk über ein lokales ClockNet geroutet und im Report ist ein Skew von 22ps angegeben. Das Startereignis lässt sich leider nicht auch auf einen lokale Clock Resource routen, weil das die IDELAY Eingänge nicht können. Wie kann ich max. die Laufzeitdifferenz der 32 auf dem rechten Bild verdrahteten Signale bekommen. Oder noch besser wäre die Laufzeitdifferenz zwischen RefClk und Start zu jeder einzelnen Zellen. Das ganze ist mit PlanAhead 14.7 erstellt.
Angehängte Dateien:
-
par_TDC.jpg
200 KB
Hallo das Projekt sieht gut aus. Ist es vielleicht besser die ideales weiter vom Pin weg zu nutzen? Da dürfen die Delays ähnlicher sein. Vielleicht geht auch ein constrain für das Skew (Data zu clock)und dann automatisch platzieren zu lassen. Michael
Michael schrieb: > Hallo das Projekt sieht gut aus. Ist es vielleicht besser die ideales > weiter vom Pin weg zu nutzen? Da dürfen die Delays ähnlicher sein. > Vielleicht geht auch ein constrain für das Skew (Data zu clock)und dann > automatisch platzieren zu lassen. > > Michael Hallo Michael, was meinst du mit weiter weg vom Pin ? IDELAY2 und das dazugehörige FF (ILOGIC) sitzen im IOB. Eine kürzere Verbindung gibt es nicht und die ist für alle 32 Zellen gleich. Aber ich sehe gerade es gibt noch ein anderes Problemchen ;) setup/hold vom FF = 0.02/0.33ns. Da muss ich den Router irgendwie dazu bringen ein ILOGICE3 mit aktiviertem ZHOLD_DELAY zu erzeugen. Das Startsignal ist ja asynchron und rauscht in 78ps Schritten durch die Delays und ich will wissen, wo es sich zum Zeitpunkt der Anstiegsflanke meines Referenzsignal befindet. Wenn es mal auf '1' ist bleibt es auch aber ein 0-> 1 Wechsel kann jederzeit passieren. Mit den 20ps setup Time muss ich leben, aber eine Hold Time von 330ps wäre viel zu lang. PS. ich frag hier so dumm weil das für mich komplettes Neuland ist. Ich habe mit VHDL +FPGA bisher nur privat und unkomliziertem Timing gearbeitet. Hauptberuflich habe ich: Hardwareentwicklung (TTL,CMOS) -> Softwareentwicklung -> Systementwicklung -> Rentner. Und jetzt darf ich machen was ich will ;)
Wenn die FF weiter weg sind ist es einfacher gleich lange Wege zu finden. Michael
Angehängte Dateien:
-
2.png
4 KB
Michael schrieb: > Wenn die FF weiter weg sind ist es einfacher gleich lange Wege zu > finden. > > Michael Hallo Michael, Ich gehe davon aus, das die IOB geometrisch identisch sind und der Router da keine Möglichkeit hat einen IOB intern anders zu verdrahten.
So jetzt habe ich mal verschiedene Varianten durchprobiert.
Der Ausgang der Delay Lines wird bei allen Varianten über die
Anstiegsflanke eines BUFIO direkt vom IDELAY2 ind ein
FF(ILOGIC)gesampled.
Für die Eingänge der Delay Lines habe ich folgende Varianten probiert.
( Alle delay Lines stehen auf 0 !)
a.) Lass das mal den Router machen.
b.) StartDelay über Inverter weit weg von den Delay Eingängen gelegt.
c.) StartDelay an der Bank gegenüber angeschlossen.
d.) Die Die 32 StartDelay direkt über PAD an IDELAY2.
Aber irgendwie habe ich Probleme mit dem interpretieren der TRC Reports.
NET OFFSET = IN 50 ps VALID 0.8 ns BEFORE "ref_clk" RISING; ergibt bei
Variante d:)
Slack Total-Delay
Setup 0,23 0,80
Hold -1,08 2,03
Wenn alle Ausgaben im Report in ns sind würde ich das folgendermassen
interpretieren:
Das Signal braucht vom PAD bis zum FF, das durch ref_clk getaktet wird,
0,8ns und du hast als Setup noch 0,23 ns Reserve -> PASS.
Beim Hold würde es plötzlich 2,03 ns laufen und müsste noch für 1,08 ns
anstehen bleiben -> deshalb FAIL
Kommen die Laufzeit Differenzen durch verschiedes Zeitverhalten der
Anstiegs und Abstiegsflanken im Signalweg ?
Wo sind da meine 50ps ?
Oder liege ich völlig falsch ?
> Hauptberuflich habe ich: > Hardwareentwicklung (TTL,CMOS) -> Softwareentwicklung -> > Systementwicklung -> Rentner. Und jetzt darf ich machen was ich will ;) So einen rüstiger Rentner. Die delays über LUTs? Ist das Temp Risiko dir zu hoch?
René D. schrieb: > Die delays über LUTs? Ist das Temp Risiko dir zu hoch? nicht über Luts sondern über die temperaturkompensierten delay lines in den IO-Blocks. Da steht im Datenblatt, bei 200Mhz Referenzfrequenz, 78ps +/- 5ps für ein TAP und dadurch erhoffe ich mir eine bessere diferenzielle Linearität und ein besseres Temperaturverhalten wie über LUT oder Carry Chain.
Das Idelay ist für das Ausgleichen von Laufzeiten von parallelen Daten gedacht. Da ich ausgehe, dass du hier ein Pulscatcher bauen willst. Habe ich eine Frage. du must von einem Pin über verschiedene IDelays zu den Flip flops. Pin-> idelay-> FF -> idelay-> FF -> idelay-> FF Ist so ein Routing überhaupt möglich? Ich würde einen Fehler von der Synthese erwarten.
Hans-Georg L. schrieb: > Da steht im Datenblatt, bei 200Mhz Referenzfrequenz, 78ps > +/- 5ps für ein TAP und dadurch erhoffe ich mir eine bessere > diferenzielle Linearität und ein besseres Temperaturverhalten wie über > LUT oder Carry Chain. Hallo Hans-Georg, diese Linearität wirst Du nicht bekommen. Diese 78ps(+-2ps) gelten für den Durchschnitt, d.h. nur im Mittel (über 5-10 Taps) kann man von 78ps ausgehen. Die Streuung der einzelnen IDelays ist aber beträchtlich (22-107ps), zumindest beim Virtex4. Die Jitter-Werte verschlechtern sich von Tap zu Tap. Sie sind abhängig vom Bit-Pattern. Die Verschlechterung ist linear. Ich hatte mal auf Basis der IDelays ein TDR-Messgerät gebaut. Das hat im cm-Bereich gut funktioniert, allerdings waren die Messkurven wegen der Nichtlinearität der IDeleays kaum brauchbar. Der Virtex4 hatte 63Taps zur Verfügung, bei späteren FPGAs sind es nur noch 16 Taps. Der Jitter war bei Nicht-Clock-Signalen einfach zu groß. Zumindest aus Sicht von Xilinx. Hackst Du die Plazierung im FPGA-Editor zusammen oder läßt Du das von ISE/Vivado machen? Gruß,
IDELAY2 lässt sich am Eingang auf einen Pin oder in die "fabric" routen. Da hast die Möglichkeit entweder alle 32 Pins extern zu verbinden oder 1 Pin in die "fabric" und von dort auf die 32 IDELAYS zu verteilen.
Ideengeber schrieb: > > diese Linearität wirst Du nicht bekommen. Diese 78ps(+-2ps) gelten für > den Durchschnitt, d.h. nur im Mittel (über 5-10 Taps) kann man von 78ps > ausgehen. Die Streuung der einzelnen IDelays ist aber beträchtlich > (22-107ps), zumindest beim Virtex4. > Ich hatte mal auf Basis der IDelays ein TDR-Messgerät gebaut. Das hat im > cm-Bereich gut funktioniert, allerdings waren die Messkurven wegen der > Nichtlinearität der IDeleays kaum brauchbar. Ich würde mir eine Auflösung von 100ps wünschen und die möglichst genau. > Der Virtex4 hatte 63Taps zur Verfügung, bei späteren FPGAs sind es nur > noch 16 Taps. Der Jitter war bei Nicht-Clock-Signalen einfach zu groß. > Zumindest aus Sicht von Xilinx. Vielleicht hat Xilinx in der Zwischezeit ja was dazu gelernt beim ARTIX (ZYNQ) sind es wieder 32 TAP. > Hackst Du die Plazierung im FPGA-Editor zusammen oder läßt Du das von > ISE/Vivado machen? Teilweise .. Ich habe mit der Hand die 32 IOB symetrisch, in 2 Gruppen, um den sample-clk Treiber, der die Delay im IOB FF speichert, plaziert. Dadurch habe ich ein Skew im clk von 59ps. Jetzt habe ich erst mal die externe Parallelschaltung, der IDELAY-Eingänge probiert und komme da auf Laufzeitdifferenzen von 250ps. Die Differenzen kommen hauptsächlich von den PIN->IOB Verbindungen. Theoretisch könnte man jetzt auch die FFs in den Gruppen hin und herschieben und die externe Verbindung optimieren aber das nützt mir alles nix ich habe ein fertiges Board. Die nächsten Variante lass ich mal vom Router machen mit Vorgaben über Constrains.
Hans-Georg L. schrieb: > Die nächsten Variante lass ich mal vom Router machen mit Vorgaben über > Constrains. Das wird nicht wirklich funktionieren. Die Reihenfolge ist die: 1. der Router routet 2. die STA prüft die Constraints Du kannst Placement-Constraints vergeben, die werden vom Router (bzw. vom Placer) beachtet. Duke
Vielleicht hilft https://github.com/jobisoft/jTDC weiter? Eigentlich fuer die ELB (http://www.elbonn.de/cms/) VME Boards gedacht, der TDC sollte aber auch anders nutzbar sein.
Uwe Bonnes schrieb: > Vielleicht hilft https://github.com/jobisoft/jTDC weiter? > > Eigentlich fuer die ELB (http://www.elbonn.de/cms/) VME Boards gedacht, > der TDC sollte aber auch anders nutzbar sein. Zitat: To obtain a resolution higher than the 5ns from sampling with the system clock, the jTDC implements the tapped-delay-line method using carry chains. Genau das wollte ich ja nicht und das ganze ist in Verilog und da bin ich im Moment zu faul das auch noch zu lernen ;) Mit den Carry Chains gibts schon ein ein paar Projekte aber da muss man immer aufpassen weil sich die Carry Chains im Laufe der Geschichte bei Xilinx geändert haben und das nicht unbedingt übertragbar auf eine andere (Xilinx) FPGA Familie ist.
Ich glaube viele Leute brauchen TDC mit vielen Kanälen. Da bietet sich die Carry-Chain-Methode an. Wenn ich Dich richtig verstanden habe, willst Du ja Dein Signal (intern oder extern) auf mehrere IDelays verteilen, d.h. Du bist auf sehr wenige Kanäle beschränkt. Duke
Duke Scarring schrieb: > Ich glaube viele Leute brauchen TDC mit vielen Kanälen. Da bietet sich > die Carry-Chain-Methode an. Full Ack. > Wenn ich Dich richtig verstanden habe, willst Du ja Dein Signal (intern > oder extern) auf mehrere IDelays verteilen, d.h. Du bist auf sehr wenige > Kanäle beschränkt. > Leider kommt man nur an ein IDelay TAB gleichzeitig und deshalb muss ich für 32 Delays auch 32 IOB verbraten. Also unbrauchbar für die reale Welt, aber ich lern was dazu ;). Meine erste "geniale" Idee einer "self-clocked-delay" hat leider einen kleinen Haken, denn dazu müsste der Clock Eingang vom IDELAY bei 78ps einen Takt von 13GHz vertragen und er kann nur 800Mhz. Aber zum dekodieren bräuchte ich nur die Stellung des MUX auslesen und alles würde in 1 IOB passen. Der Grund warum ich das mit den IDelay und nicht mit den CarryChains probiere war die automatische interne calibrierung der IDelays. Ich könnte natürlich auch den Refclock durch die Idelay jagen und die 32 Phasenverschobenen Signale in die "fabric" routen. Aber da frage ich mich ob ich mir da nicht wieder die Temperaturabhängigkeit einfange, weil ja nur die IOB compensiert werden. Hier noch ein Link wo die Calibrierung beschrieben ist: http://www.xilinx.com/support/documentation/application_notes/xapp707.pdf
:
Bearbeitet durch User
Hans-Georg L. schrieb: > Aber da frage ich > mich ob ich mir da nicht wieder die Temperaturabhängigkeit einfange, > weil ja nur die IOB compensiert werden. Ja, habe das mal bei Altera Stratix GX gemacht. Das muss permanent in einer Regelschleife kalibriert werden, will man interne Delays als Präzisionsschieber nutzen. Bei Xilinx wird es nicht anders sein :-) Eine Möglichkeit, den Kalibrationsaufwand in Grenzen zu halten, wäre, die FPGAs auf konstanter Wärme (-> Leistungsregelung) zu halten. Das kann der FPGA auch selber tun, indem er den Drift an einigen Stellen mit geeigneten Strujturen misst und dann seine eigene Leistung regelt. (Verbaucherschaltung mit Taktabschaltung). Das muss auch Zehntel-Grad genau gemacht werden. Meistens braucht es noch Kühltechnik von Außen, um das Umfeld des FPGAs temperaturstabil zu halten. Das alles ist aber ziemlich müßig, weil FPGAs für solche Sachen nicht so wirklich gut geeignet sind. Da gibt es antsprechende ASICS.
Jürgen S. schrieb: > Hans-Georg L. schrieb: >> Aber da frage ich >> mich ob ich mir da nicht wieder die Temperaturabhängigkeit einfange, >> weil ja nur die IOB compensiert werden. > > Ja, habe das mal bei Altera Stratix GX gemacht. Das muss permanent in > einer Regelschleife kalibriert werden, will man interne Delays als > Präzisionsschieber nutzen. Bei Xilinx wird es nicht anders sein :-) > Genau das ist ja bei den Artix schon eingebaut aber nur für die Delays der Ein und Ausgänge und mit diesem Feature wollte ich mal sehen wie weit ich komme. Bei einer Zeitmessung brauchst du das aber auch noch für Start und Stopsignal. Das wären schon 64 IO verbraten für einen Kanal und das ist für mehrere Kanäle in der Praxis nicht brauchbar. Aber ich habe dabei viel über IO-Struktur, clocking Resourcen und wie man interne "Verdrahtung" beinflussen oder direkt editieren kann gelernt. Für Frequenzmessung könnte man vielleicht mit einer IDelay auskommen. Da bin ich gerade dabei ;)
Kannst ja mal was posten, wenn Du magst. Welche board benutzt Du?
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.