Ich habe einen 16 bit 80MSps ADC parallel am fpga. Das ist ein Pipelined ADC und wird mit ständiger clock aus der DCM versorgt. Welche constraint brauche ich nun um den 16bit bus, der vom ADC kommt mit dem clocksignal zu verknüpfen? Es gibt ja die offset in constraint aber die sind nach meinem Verständnis nur sinnvoll wenn die clock auch von extern kommt. Die wird bei mir ja aber intern generiert. Es geht um einen spartan 6.
Ralph N. schrieb: > 16 bit 80MSps ADC Welcher genau? Die meisten ADC geben eine Echo-Clock wieder mit den Daten aus. Ralph N. schrieb: > Es gibt ja die offset in constraint aber die sind nach > meinem Verständnis nur sinnvoll wenn die clock auch von extern kommt. Das geht auch mit der internen Clock. Es gibt ja auch hier einen festen zeitlichen Zusammenhang zwischen einer Taktflanke der internen Clock und den eintreffenden Daten.
Beitrag #7088219 wurde von einem Moderator gelöscht.
Dennis E. schrieb im Beitrag #7088219:
> Was hast du gesoffen?
Der Taktausgang heißt DCO. Und dass dieser ADC einen Taktausgang hat
steht sogar auf der ersten Seite des Datenblatts.
Als Hinweis, Seite 26 vom Datenblatt, unter "Jitter Consideration" da ist eine Formel zu finden was an SNR bei welchem Jitter über bleibt. Mal ins dunkle geraten... so ein DCM-Clk dürfte wohl den SNR deutlich reduzieren. Mein Rat, einen guten Oszillator mit eigenem Rauscharmen LDO, mit diesem CLK zum ADC und vom ADC zum FPGA. Gruß
frickel schrieb: > Mein Rat, einen guten Oszillator mit eigenem Rauscharmen LDO, mit diesem > CLK zum ADC und vom ADC zum FPGA. Wir schließen das FPGA in der Regel mit einem Buffer parallel an, weil viele ADCs den DCO erst raus bringen wenn man den aktiviert hat. Den ADC aus einem MMCM füttern ist denkbar schlecht für das SNR.
Christian R. schrieb: > Den ADC aus einem MMCM füttern ist denkbar schlecht für das SNR. Habe ich jetzt leider so gemacht weil die 40MHz aus 20MHz erzeugt werden und kein extra oscillator dafür vorgesehen war. Werde ich mir in der Revision mal zu Herzen nehmen.
20 MHz ist eine eher untypische Taktfrequenz auf FPGA Boards. Kann natürlich sein, dass da nur ein 20 MHz Oszillator drauf sitzt. Aber rein aus Interesse: Welches FPGA Board verwendest du?
Das ist ein eigenes design. Die 20 MHz dienen nur für die Referenz der DCM
Moin Ralph N. schrieb: > Christian R. schrieb: >> Den ADC aus einem MMCM füttern ist denkbar schlecht für das SNR. > > Habe ich jetzt leider so gemacht weil die 40MHz aus 20MHz erzeugt werden > und kein extra oscillator dafür vorgesehen war. Werde ich mir in der > Revision mal zu Herzen nehmen. Das vervielfachen macht die Sache noch mal deutlich schlechter was den Jitter betrifft, da bleiben am ende von 16Bits nicht mehr viel brauchbare Bits über. Ich hatte vor längerer zeit mal mit dem Spektrumanalysator geschaut was da so raus kommt aus den FPGAs, Spartan-3/E/A, Spartan-6. Das Ergebnis war erschreckend! Die angaben in den Datenblättern kann man eventuell noch trauen wenn nichts weiter als der DCM + das notwendigste am laufen ist, kommt dann aber noch mal reichlich Logik dazu... wird es unvorhersehbar sehr dreckig. So im Nachhinein leuchtet das Problem ja auch ein, schaut man sich mal an was für ein Aufwand getrieben wird um Rauscharme bzw. Jitterarme Oszillatoren und deren Stromversorgung zu frickeln, dann ist so eine DCM (oder wie immer sie genannt werden) in so einem FPGA am schlechtesten Ort, unsaubere Stromversorgung, rauschen aus dem Umfeld, Temperatur... das ist am ende in etwa so als ob man Beethovens Sinfonie neben einen laufenden Schiffsdiesel hören will. Selbst ohne DCM, also nur rein/raus aus dem FPGA ist meiner Meinung nach für einen 16Bit ADC vollkommen unbrauchbar. Gruß
Die Frage ist wie viel von 16bit bleiben. Wohl kaum nur noch 12bit. Denke bei der Revision spendiere ich den ADCs mal einen eigenen Oszillator mit clockbuffer. Die Idee war eben das im fpga zu machen, da ich triggern möchte und der trigger mit einem Zähler im delay variiert wird.
Ob 12Bit über bleiben... da würde ich jetzt keine aussage zu machen wollen, zu viele unbekannte im spiel. In deinem Fall (bei einem neuen Design) würde ich dennoch die Daten vom ADC mit dem Dco-Clk an den FPGA IO-Register übernehmen, da ist man vom Timing her deutlich besser dran, dafür ist der Dco-Clk ja auch da. Clockbuffer zusätzlich, klar kann man machen. Im FPGA noch mit DCM oder wie auch immer verwursteten, dann intern nach den Dco-Clk/Io-Registern synchronisieren, ab da hat man ja wieder alle Freiheitsgrade die man sich ausdenken kann. Schauen würde ich noch das die IOs vom ADC alle an der selben Io-Bank liegen, ist zwar vom Timing jetzt nicht wirklich kritisch, verbraucht aber unnötig Clk-Netze wen es über mehrere Io-Bänke hinweg geht. Gruß
Um auf die eigentliche Frage zu kommen: Meines Wissens geht das dann über ein in delay constraint bezogen auf einen virtuellen Clock. Wir gut die STA dann ist, weiß ich aber nicht. Bei 40MHz ist das aber alles entspannt, das ist ja aufgeregter Gleichstrom...
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.