Hallo, bin über das Rigol Einsteiger Oszi auf die Technik der verschachtelten AD-Wandler gestolpert. Theoretisch kann ich mir vorstellen, wie es funktionieren müsste, praktisch kann ich mir aber nicht vorstellen, wie man es im FPGA umsetzen könnte. Wenn ich das Datenblatt vom Cyclon III richtig verstanden habe, kann das Teil per PLL intern bis zu 1,3 GHz takten. Prinzipiell wäre es also möglich, ein Schieberegister so einzutakten, dass 10 versetzte Taktquellen à 100 MHz entstehen. Der IO-Takt ist aber nicht annähernd schnell genug für 1 GHz - d.h. die erzeugte Phasenverschiebung wird über den IO-Takt wieder zunichte gemacht. Um das Prinzip umzusetzen müsste man quasi 10 verschiedene Clock-Domains erzeugen und denen die entsprechenden IO-Pins zuordnen. Soweit ich weiß, hat der Cyclon III 4 PLLs, d.h. man könnte 4 versetzte Takte erzeugen. Ja - und da setzt es bei mir aus. Wie kann man mit nur 4 PLLs 10 verschiedene AD-Wandler ansteuern, dass die Phasenverschiebung exakt passt? Offensichtlich hat Rigol einen Weg gefunden, das Problem zu lösen. Ob mir wohl jemand helfen könnte, eine mögliche Umsetzung zu verstehen? Bei der Speicheransteuerung ist das Problem ja das gleiche. Prinzipiell würden 100 MHz reichen (5ns Schreibpuls), aber das eben mehrfach versetzt ...
Was ist jetzt eigentlich Kern deiner Frage? Ich interpretiere: Du willst wissen, wie man aus einem 1 GHz Takt zehn 100MHz Takte machen kann, die um jeweils 36 Grad phasenverschoben sind..
Eine Möglichkeit bei Xilinx wäre, alle IOs mit der selben 200MHz CLK anzusteuern, und zwischen Register und Buffer sogenannte IODelays einzusetzen. (Wie die entsprechenden Elemente bei Altera heißen, kann ich dir leider nicht sagen). Beim Virtex5 z.B. erlauben die IODelays, den Ausgängen definierte Verzögerungen von je 78ps Schwrittweite zu geben. Mit einer einzigen 200MHz CLK kannst du also an den IOs 64 definiert phasenverschobene Ausgangssignale für die Ansteuerung der ADCs machen. Das selbe gilt für die Eingänge: du verzögerst die externen Signale mit Ihrer Phasenverschiebung jeweils individuell so lange (in 78ps Schritten), dass sie beim Eintakten mit der einzigen 200MHz CLK wieder alle phasengleich anliegen.
Danke für Eure Antworten. > Ich interpretiere: > Du willst wissen, wie man aus einem 1 GHz Takt zehn 100MHz Takte machen > kann, die um jeweils 36 Grad phasenverschoben sind.. Nö - das dürfte genauso mit einem entsprechend synchronisierten Schieberegister funktionieren ... Meine Frage zielt eher in die Richtung: wie bekomme ich den exakten Takt nach draußen, wenn der IO-Takt nur einen Bruchteil des internen Taktes darstellt. > Beim Virtex5 z.B. erlauben die IODelays Jo, ich meine, die IODelays hätte ich schon beim Cyclone IV gesehen. Allerdings sind die preislich doch schon deutlich anspruchsvoller. Wie kann man eine (mehr oder weniger) saubere Taktverscheibung erreichen, wenn man die tolle Möglichkeit der IODelays nicht hat?
du könntest versuchen, ein Schieberegister mit z.B. 10 Registern manuell sehr nahe an den Ports zu platzieren und durch dieses dann den Wert "0000011111" im kreis herum schieben. Dann routest du die einzelnen Registerausgänge auf ie Pins (ohne IO-Register). Sehr genau wird das nicht, aber es könnte funktionieren...
Guck du hier wie man so etwas macht: http://www.hittite.com/content/documents/presentations/hmcad1511_2gsps_oscilloscope_solution.pdf Übrigens die 1.3 GHz der Cyclone III PLL beziehen sich nur auf die VCO Frequenz. Output der PLL ist kleiner als 500 MHz, ausserdem ist die maximale Frequenz der Clocktrees im höchsten Speedgrade auch nur 500 MHz.
Ich versteh immernoch das Problem nicht. Je PLL lassen sich 5 verschiedene Takte generieren. Jeder davon individuell in der Phase einstellbar. 10 mit 100 MHz und jeweils anderer Phase ist doch ein Kinderspiel. Schnapp dir 2 PLLs setzt die Takte auf 100 MHz, gibt jedem nen anderen Phasenwinkel und gut ist. Dauert 5 Minuten.
ich kenn die Internas des Cyclone3 nicht, aber über die 1,3 GHz hab ich mich auch ein wenig gewundert ;-) Nun, aber wenn der natürlich 2 PLLs mit 5 Ausgängen "an Bord" hat, dann ist das doch über die zu bewerkstelligen.
..ups, zu schnell auf "senden" geklickt. Also was ich noch sagen wollte: Mit der Lösung mit den PLLs musst du halt schauen, wie du das ganze so geroutet bekommst, dass der Skew zwischen den Pfaden der einzelen PLL-Ausgängen zu den Ports einigermaßen gering ist. Sonst ist deine Phasenverschiebung beim Teufel
Habe gerade nochmal drüber nachgedacht. Das Problem mit den Skews, wenn du die PLLs auf die Ports routest, ist nicht trivial. Eventuell könnte die von mir angeprochene Schieberegisterlösung beherrschbarer sein, da du die Register manuell platzieren kannst. Ich weiss nicht, wie schnell IO-Register takten können, aber wenn die z.B. mit 250MHz klarkommen, dann könntest du vier Schieberegister machen, die mit vier 250 MHz Takten versorgt werden. Diese Takte kommen über die Clock-Trees von der PLL an die Register und sind 90 Grad Phasenverschoben. Wenn du nun die Register der Schieberegister als IO-Register ausführst, dann könntest du die geschachtelt anordnen, und ein Muster durchschieben. Vielleicht habe ich auch nen Denkfehler drin, aber ich glaube, das könnte ganz gut funktionieren.
Schlumpf schrieb: > Wenn du nun die Register der Schieberegister als IO-Register ausführst, > dann könntest du die geschachtelt anordnen, und ein Muster > durchschieben. > Warum nicht gleich die SERDES Funktion der IO Pins eines Spartan6 verwenden? GBit/s und damir eine Auflösung von 1 ns können die ohne weiteres. Davon abgesehen ist eine FPGA PLL als Clocksource für einen ADC alles andere als optimal.
Lattice User schrieb: > Warum nicht gleich die SERDES Funktion der IO Pins eines Spartan6 > verwenden? > GBit/s und damir eine Auflösung von 1 ns können die ohne weiteres. Ich denke, dass Problem wird sein, dass der ADC nicht schnell genug ist und er deswegen mehrere versetzt zueinander betreibt. Die Frage war, wie er mehrere zueinander phasenverschobene Takte am Ausgang generieren kann. Wenn das mit dem SERDES geht, dann kann er das machen. Ich wüsste jetzt aber auf Anhieb nicht, wie ich einen SERDES dazu bewegen kann, genau dies zu tun.
Moin moin, > Ich versteh immernoch das Problem nicht. Vielleicht liegt es daran, dass ich mein Problem nicht wirklich erfassen kann? Eigentlich möchte ich nur den Weg verstehen/nachvollziehen, den Rigol und Co bei der Datenerfassung verwenden. Ich folge auch gerne Links um mich dort weiter zu bilden. Wenn mir darüberhinaus jemand noch erklärt, wie man es besser machen könnte, würde mich das auch freuen. > 10 mit 100 MHz und jeweils anderer Phase ist doch ein > Kinderspiel. Schnapp dir 2 PLLs setzt die Takte auf 100 MHz, gibt jedem > nen anderen Phasenwinkel und gut ist. Dauert 5 Minuten. Ok, aber den Takt erzeugen ist ja nur die halbe Miete. Die Daten wollen ja auch verarbeitet (in Speicher geschrieben) werden. Um auf 32bit Datenbreite zu kommen, müsste ich 4mal ein Byte von jeweils unterschiedlichem Takt einsynchronisieren. Wenn ich jetzt mehrere Speicher nehmen würde, sodass ich pro Speicher-IC 4 AD-Werte schreibe, dann hätte ich das Problem der Phasenverschiebung wieder. Wäre es da nicht sinnig, man hätte einen Systemtakt, der alle Phasen kennt? Das wäre dann der interne Takt (Systemtakt) mit 1 GHz. > Guck du hier wie man so etwas macht: > ... > Warum nicht gleich die SERDES Funktion der IO Pins eines Spartan6 > verwenden? > GBit/s und damir eine Auflösung von 1 ns können die ohne weiteres. Klar ist es besser, wenn das ADC den PLL integriert hat. Aber das ist eine andere Geschichte ... Hm, vielleicht kann ich ja nicht rechnen. Wenn ich mir ein ADC vorstelle, welches 1 GS/s in 8Bit sampled und per SPI verschickt, dann sollte der SPI-Empfänger wenigstens 10GBit/s am seriellen Eingang vertragen, sonst fallen die Bits aus dem Kasten :O Wenn ich das jetzt noch mit der Anzahl möglicher Kanäle multipliziere, bin ich in einer (Frequenz-)Region, von der ich noch nie einen IC gehört habe. Aber vielleicht kannst Du mir meinen Denkfehler erklären? Ich war der Meinung, dass 100 MHz von mehreren Quellen leichter beherrschbar wäre (von Skew und anderen Nickligkeiten abgesehen) und preiswertere Bauteile ermöglichen würde. Jeder der mit FPGA und Co zu tun hat, lacht über 100 MHz. Warum sonst sollten die Chinesen an diesem Weg so fest halten? Gleiches sehe ich für Schnittstellen. Serielle Schnittstellen sind schwierig zu routen (LVDS) und wegen der hohen Frequenz auch schwierig zu verarbeiten (die Vorteile von LVDS lasse ich mal bewusst unter den Tisch fallen). Da sind parallele Daten mit Phasenverschiebung (zumindest auf den ersten Blick) deutlich leichter zu handhaben.
Schlumpf schrieb: > Ich wüsste jetzt > aber auf Anhieb nicht, wie ich einen SERDES dazu bewegen kann, genau > dies zu tun. Nur zur Klarstellung, ich rede nicht von den GT SERDES. Beim Spartan6 haben viele IO Pins eine SERDES Funktion eingbaut (ohne PLL). Für die 10 phasenverschobenen Clocks legts du am 1. Pin intern das Muster 0000011111, am 2. Pin 1000001111 etc an. Im Grunde das gleiche wie die Shiftregisterlöung, nur dass das Shiftregister 10 mal repliziert wird und dedizierte HW verwendet wird. Von da zu dem Pins ist der Skew vernachlässigbar.
Taktlos schrieb: > Eigentlich möchte ich nur den Weg verstehen/nachvollziehen, den Rigol > und Co bei der Datenerfassung verwenden. Ich folge auch gerne Links um > mich dort weiter zu bilden. Hast du meinen Link oben angeschaut, das ist eine APP Note wie man mit 2 Hittite ADCs ein billig Scope baut. Und wenn du genau hinschaust enthält jeder beiden ADCs intern 4 Stück. Sind also insgesamt 8 interleaved ADCs. > > Aber vielleicht kannst Du mir meinen Denkfehler erklären? > > Ich war der Meinung, dass 100 MHz von mehreren Quellen leichter > beherrschbar wäre (von Skew und anderen Nickligkeiten abgesehen) und > preiswertere Bauteile ermöglichen würde. Skew und die anderen Nickligkeiten sind aber keine Kleinigkeiten. Ein 100 MHz ADC ist natürlich billiger als ein 1 GHz ADC aber auf ZEHN 100 MHz ADC trifft das nicht zu. Zu den anderen Nickligkeiten gehöhrt ja dann auch dass man dise 10 ADCs genau aufeinander abstimmen muss, sie brauchen viel Platinenplatz, braucht auch mehr FPGA IO Pins, alles Preistreiber. > Jeder der mit FPGA und Co zu > tun hat, lacht über 100 MHz. > Warum sonst sollten die Chinesen an diesem Weg so fest halten? Tun sie so nicht. > > Gleiches sehe ich für Schnittstellen. Serielle Schnittstellen sind > schwierig zu routen (LVDS) und wegen der hohen Frequenz auch schwierig > zu verarbeiten (die Vorteile von LVDS lasse ich mal bewusst unter den > Tisch fallen). > Da sind parallele Daten mit Phasenverschiebung (zumindest auf den ersten > Blick) deutlich leichter zu handhaben. Aber nur auf den ersten Blick. Vom viel aufwendigerem Routing wegen der sehr viel mehr Leitungen abgesehen ist die Phasenverschiebung im FPGA ist alles andere als leicht handzuhaben, einfach 10 phasenverschobene Clocks innerhalb des FPGA geht nicht da dafür nicht genügend Clocktrees vorhanden sind.
> Hast du meinen Link oben angeschaut Selbstverständlich! Wenn Du mir schon Gelegenheit gibst, mich weiter zu bilden, dann nehme ich die auch an. > das ist eine APP Note wie man mit 2 Hittite ADCs ein billig Scope baut. Hm, also vom Prinzip her sehe ich keinen Unterschied zum AD9288 - den kann man auch so betreiben, dass beide Wandler das gleiche Eingangssignal zeitversetzt (mit einem externen Takt) erfassen und wandeln (selbstverständlich bei deutlich geringerer Samplingrate). Wenn ich das Rigol und Co richtig verstanden habe, wird das auch so gemacht. Also gibt es 5 phasenverschobene Takte vom FPGA und jedes ADC wandelt so, dass sowohl bei steigender Taktflanke, wie auch bei fallender Taktflanke ein Wert bereitsteht. Bei den Hittite Wandlern sehe ich es als Vorteil, dass die intern den Takt verzehnfachen. Dadurch kann ein ADC bereits 1GS/s liefern, ohne dass ein Takt von 1GHz erzeugt und auf dem PCB geroutet werden muss. Was ich - bei der Hittite-Variante - nicht verstehe, ist die Empfängerseite - der Spartan6 kann "nur" gut 1GBit/s - was nach meinem Verständnis nicht ausreicht, um die Daten von 1GS/s zu verarbeiten. Die 10 Werte von 5 AD9288 zu verarbeiten sehe ich als wesentlich einfacher an. > Aber nur auf den ersten Blick. Ich schrieb ja, dass ich das bewusst unter den Tisch fallen lasse. Klar, LVDS-Leitungen sind viel unempfindlicher gegen externe Störeinflüsse. Das ist mir durchaus bewusst. Ebenso wie der Umstand, dass skew keine Trivialität ist. Wenn ich einmal überfliege, was es so an FPGAs gibt, die 10 Gb/s (oder mehr) an Datenrate verarbeiten können, dann bin ich in der Größenordnung von 1k Teuronen per IC - nicht gerade das, was ich unter lowcost verstehe ;)
Lattice User schrieb: > Nur zur Klarstellung, ich rede nicht von den GT SERDES. Beim Spartan6 > haben viele IO Pins eine SERDES Funktion eingbaut (ohne PLL). Ah okay, das wusste ich nicht. Wieder was dazugelernt :-) Dann haben wir ja den gleichen Gedanken gehabt, was die prinzipielle Umsetzung angeht. Taktlos schrieb: > Vielleicht liegt es daran, dass ich mein Problem nicht wirklich erfassen > kann? Den Eindruck habe ich auch ;-) Du hast in deinem Eingangspost ein wenig konfus geschrieben, dass du nicht verstehst, wie es gelingt, recht flotte, phasenverschobene Takte an FPGA-Pins zu erzeugen. Antworten dazu hast du ja jetzt bekommen. Taktlos schrieb: > Wenn mir darüberhinaus jemand noch erklärt, wie man es besser machen > könnte, würde mich das auch freuen. Besser als was? Als Rigol? Taktlos schrieb: > Ok, aber den Takt erzeugen ist ja nur die halbe Miete. Sehr richtig! Aber nachdem du nur nach den Takten gefragt hast, wurde dir auch nur dazu eine Antwort gegeben. Dass die Takte zu erzeugen bei so einem System das kleinste aller Probleme ist, liegt auf der Hand. Taktlos schrieb: > Um auf 32bit Datenbreite zu kommen, müsste ich 4mal ein Byte von jeweils > unterschiedlichem Takt einsynchronisieren. > Wenn ich jetzt mehrere Speicher nehmen würde, sodass ich pro Speicher-IC > 4 AD-Werte schreibe, dann hätte ich das Problem der Phasenverschiebung > wieder. > Wäre es da nicht sinnig, man hätte einen Systemtakt, der alle Phasen > kennt? > > Das wäre dann der interne Takt (Systemtakt) mit 1 GHz. Taktlos schrieb: > Wenn ich mir ein ADC vorstelle, welches 1 GS/s in 8Bit sampled und per > SPI verschickt, klar, wenn du alle 4ns einen Samplewert hast und diesen per SPI auslesen willsts, dann wird das nichts. Das geht nur parallel. Für einen Messvorgang werden die Daten vom FPGA erfasst und parallel in das interne RAM geschrieben. Dazu müssen die RAMs auch auf den 4 verschiedenen Taktdomänen laufen. Am Ende der Messung hast du dann 4 RAMs voller Messwerte die folgendermaßen abgelegt sind: RAM-Nr. Byte-Nr. Samplezeitpunkt ---------------------------------- 0 0 0 ns 1 0 1 ns 2 0 2 ns 3 0 3 ns 0 1 4 ns 1 1 5 ns 2 1 6 ns 3 1 7 ns ..... Diese Werte kannst du dann nach Ablauf der Messung "gemütlich" aus dem RAMs auslesen, in EINE passende Taktdomäne schieben. In dieser werden die Daten dann verarbeitet und dargestellt. Du würdest also für das Beispiel 1 GHz Samplerate mit 4 AD-Wandlern nirgends auf dem FPGA einen 1GHz-Takt benötigen, sondern nur vier phasenverschobene 250MHz-Takte, auf denen das Dateninterface zum ADC und der zugehörige RAM laufen. Den Rest kannst du mehr oder weniger beliebig langsam machen.
Taktlos schrieb: >> Hast du meinen Link oben angeschaut > > Selbstverständlich! > > Wenn Du mir schon Gelegenheit gibst, mich weiter zu bilden, dann nehme > ich die auch an. > >> das ist eine APP Note wie man mit 2 Hittite ADCs ein billig Scope baut. > > Hm, also vom Prinzip her sehe ich keinen Unterschied zum AD9288 - den > kann man auch so betreiben, dass beide Wandler das gleiche > Eingangssignal zeitversetzt (mit einem externen Takt) erfassen und > wandeln (selbstverständlich bei deutlich geringerer Samplingrate). ist das mit dem AD9288 nur eine Vermutung, oder kannst du das konkrete Scope benennen? Das Prinzip ist schon ok und wird immer noch verwendet, ist aber bei 1 GS/s nicht mehr Stand der Technik. Geht heute billiger und besser. > Wenn ich das Rigol und Co richtig verstanden habe, wird das auch so > gemacht. Also gibt es 5 phasenverschobene Takte vom FPGA und jedes ADC > wandelt so, dass sowohl bei steigender Taktflanke, wie auch bei > fallender Taktflanke ein Wert bereitsteht. 5 Clockdomains sind im FPGA noch machbar, intern kann der hier mit 200 MHz laufen. > > Bei den Hittite Wandlern sehe ich es als Vorteil, dass die intern den > Takt verzehnfachen. Dadurch kann ein ADC bereits 1GS/s liefern, ohne > dass ein Takt von 1GHz erzeugt und auf dem PCB geroutet werden muss. > > Was ich - bei der Hittite-Variante - nicht verstehe, ist die > Empfängerseite - der Spartan6 kann "nur" gut 1GBit/s - was nach meinem > Verständnis nicht ausreicht, um die Daten von 1GS/s zu verarbeiten. > > Die 10 Werte von 5 AD9288 zu verarbeiten sehe ich als wesentlich > einfacher an. > Du kannst auch mit LVDS ein paralleles Interface machen, und wenn du genau hinschaust gehen in der Hittite Variante von jedem der beiden ADCs 8 LVDS Kanäle zum FPGA. Also kommen da die Daten mit 1 GBit/s ( x 16) an. Jeder moderne FPGA hat an seinen IO Pins Logik um diese Datenrate FPGA intern durch paralleisieren zu reduzieren. Der Spartan 6 kann an jedem Pin 1 GBit/s und diese mit 125 MHz intern 8 bit breit weiterreichen. Im Ergebniss heisst das das da mit 125 MHz immer 16 Samples gleichzeitig ankommen, und zwar in genau einer Clockdomain was die Verarbeitung vereinfacht. Das gilt insbesondere wenn man als Samplememory DDR2/3 RAM verwenden möchte (Preis!). 5 mal AD9288 plus Cyclone III womöglich noch mit statischem RAM ist der Stand von vor 8 Jahren.
> ist das mit dem AD9288 nur eine Vermutung, oder kannst du das konkrete > Scope benennen? Siehe hier: http://www.mikrocontroller.net/articles/Rigol_DS1052E Laut eevblog setzt Rigol in den Modellen 1052, 1102 und 1202 5x die 40 MS/s Variante von AD9288 ein und übertaktet die ADCs auf 100 MHz. Bei Hantek/Tekway und Co werden 4x die 100 MS/s Varianten des AD9288 eingesetzt, welche auf 125 MHz übertaktet werden. Wenn ich nix überlesen habe, dann trifft das auch heute noch zu. Owon scheint wohl ein neues Konzept auszuprobieren, ist aber mit dem Rest dermaßen hinterher, dass es nicht als ernst zu nehmende Konkurrenz zu obigen Modellen angesehen werden kann. > 5 mal AD9288 plus Cyclone III womöglich noch mit statischem RAM ist der > Stand von vor 8 Jahren. Das will ich nicht bestreiten. Allerdings - solange eine cashcow funktioniert und Rendite abwirft, gibt es ja keinen Grund, am Konzept etwas zu ändern :>> > Du kannst auch mit LVDS ein paralleles Interface machen, und wenn du > genau hinschaust gehen in der Hittite Variante von jedem der beiden ADCs > 8 LVDS Kanäle zum FPGA. Hm, da habe ich wohl das Timing-Diagramm im Datenblatt falsch verstanden. Ich habe nur gesehen, dass 8 verschiedene Messwerte "gleichzeitig" übertragen werden. Aber wenn man dann den Takt wieder berücksichtigt, dann hast Du recht! > Im Ergebniss heisst das das da mit 125 MHz immer 16 > Samples gleichzeitig ankommen, und zwar in genau einer Clockdomain was > die Verarbeitung vereinfacht. Muss mir das nochmal in Ruhe anschauen. Danke für Deine Geduld und Unterstützung!
Taktlos schrieb: > > Das will ich nicht bestreiten. Allerdings - solange eine cashcow > funktioniert und Rendite abwirft, gibt es ja keinen Grund, am Konzept > etwas zu ändern :>> > Stimmt natürlich. Ein Hersteller mit einer Produktpalette muss auch aufpassen dass nicht das Billprodukt in der Leistung die nächst teuerere Variante überholt. Wobei es die DS1000 auch bereits in neueren Versionen gibt: DS1xxxD mit 1 Mpts Points, DS1xxxCA mit 2 GS/s. Dann als nächste Klasse nur wenig teuerer die DS2000 teardown: http://www.eevblog.com/2012/09/26/eevblog-360-rigol-ds2000-oscilloscope-teardown/ Da ist es ganz klar LVDS zum FPGA.
ja, die china DSOs benutzen (immer noch) haufenweise AD9288 (oder andere, aber ähnlich kombination von mehreren ADCs). Man muss auch kein BWLer sein um zu verstehen warum: -den AD9288-40 kann man bis 133MHz übertakten -5 davon sind günstiger als jede andere alternative Rigol hat mit CA serie den versuch gemacht in richtugn ADC08Dxxxx. Die sind aber viel zu teuer gewesen, zu den besten DSO preisen war Rigol DS1062CA für Rigol schon verlustgeschäft. Es ging hier um etwas anderes, Rigol wollte 300MHz modele bauen. Mit 5x AD9288 (also 10 ADC mit je x pF) war das nciht mehr drin. Owon konnte (anfangs) mit SDS serie auf sehr günstige RuiFeng ADCs zugreifen - ohne dies gäbe es immer noch keine >1GSs Owon DSO. Jetzt wo die stückzahlen stimmen kaufen die auch ADC08Dxxx, die gibts mittlerweile palettenweise günstig von TI. Wie günstig die sind kann man anhand von ADC08D502 sehen (die im prinizp nix anderes als ADC08D500 sind - nur ohne DES mode umschaltung, also ohne clock inverter). Eins darf man dabei nicht vergessen, die ganzen china DSOs sind 2007 designed und seit 2008 in der produktion. Heute, mit den >1GSs DSOs, machen die es anders (aber nur weil stückzahlen/strassenpreis es erlaubt) Für die =< 1GSs DSOs könnte der HMCAD1511 eine gute alternative sein (technisch - da weniger gain und skew probleme durch internes interleaving),wäre nicht der preis gewesen - beim 5k kostet es immer noch 50USD. Nimmt man stattdessen 25k von AD9288-40 kostet eine 5x kombi unter 20USD. Das sind 16% des DSO preises (ab werk, 1k stk), da lohnt also zu rechnen.
Danke für den Link! Äußerst interessant. > Dann als nächste Klasse nur wenig teuerer die DS2000 "nur wenig teurer" - Hm, mal sehen: DS1102E 326 Öre DS2102 966 Teuronen DS1202CA 755 Öre DS2202 1376 Teuronen Hm, also bei "wenig teurer" hatte ich eine Steigerung im Bereich 10-15% erwartet. Fast Faktor 3 beim ersten Model und fast Faktor 2 beim zweiten Model ... ... weist für mich auf eine völlig andere Zielgruppe. Auch wenn der größere Speicher ein nicht zu unterschätzender Vorteil ist, denke ich nicht, dass ein Hobby-Elektroniker dafür mal eben das 3fache auf die Theke legen mag. Insofern sehe ich die Produktlinie als eher fragwürdig. Klar, sowohl mechanisch, als auch vom PCB ist das DS2000 ne andere Klasse. Aber ob das ausreicht, um entsprechende Profis anzusprechen? Ich denke, Profis werden eher bei den etablierten Namen bleiben - auch wenn das wieder eine andere Preisklasse ist. Bleibt als Zielgruppe nur noch die Schar der Pseudo-Profis, die selbst im Preisdruck stehen. Aber die werden wohl eher zu der DS1000 Klasse greifen. Ich kann mir auch nicht vorstellen, dass ein Hobby-Elektroniker, dem das DS1202 nicht mehr ausreicht, sich nach einem DS2202 umschaut. Ich denke, er wird eher nach einer Bandbreite > 300 MHz suchen. Also vielleicht was gebrauchtes, vielleicht sogar analoges ... Aber jetzt bin ich wohl zu weit abgeschweift. Eigentlich hat mich ja "nur" die Steuerung im FPGA interessiert.
Taktlos schrieb: > Klar, sowohl mechanisch, als auch vom PCB ist das DS2000 ne andere > Klasse. Aber ob das ausreicht, um entsprechende Profis anzusprechen? > Ich denke, Profis werden eher bei den etablierten Namen bleiben - auch > wenn das wieder eine andere Preisklasse ist. Und fallen rein :-) Die Agilent DSO1000, drauf steht Agilent, rate mal was drin ist.
Taktlos schrieb: > Eigentlich hat mich ja "nur" die Steuerung im FPGA interessiert. Ich muss mich allerdings korrigieren. beim Lattice ECP3 ist es durchaus möglich viele Kanäle mit eigener phasenverschobener Clock einzulesen. Es gibt Gruppen von jeweils 8-12 IOPins mit einen dedizierten Clockeingang. Das ist eigentlich für DDR2/3 Memory gedacht, lässt sich aber auch generisch verwenden. Die Clocks müssen dazu nur von einer der 8 Systemclocks abgeleitet sein. Und das schöne dabei ist, dass die Synchronsierung von der phasenverschobenen Inputclock auf die Systemclock bereits in der IO Logik der Datenpins gemacht wird. Altera und Xilinx FPGAs haben da garantiert ähnliche Möglichkeiten.
@tinman Kein Hersteller dessen Einkäufer etwas taugt zahlt Listenpreise für hochpreisige Bauteile. Und das gilt erst recht für Chinesen.
> Und fallen rein :-) > Die Agilent DSO1000, drauf steht Agilent, rate mal was drin ist. Hm, ich denke mal, dass sich der Entwicklungsaufwand im Lowcost-Bereich für die etablierten Hersteller nicht lohnt. Da wird dann zugekauft und umgelabelt. Wenn ich es recht weiß, ist Rigol auch als Auftragsfertiger aktiv, d.h. da wird ganz sicher auch Wissenstransfer stattfinden. Den Verkauf von umgelabelten Produkten halte ich weder für verwunderlich noch sehe ich es als Einzelfall. Ich durfte mal Meßfühler-Platinen (deutscher Produktion) sehen, die bei der Wafer-Produktion für die Tests verwendet werden. Ist zwar auch schon ein paar Tage her, aber ich war schon beeindruckt :O > beim Lattice ECP3 ist es durchaus möglich viele Kanäle mit eigener > phasenverschobener Clock einzulesen. Hm, könntest Du da bitte etwas ausführlicher werden? Das Thema interessiert mich doch zunehmend. Ich habe auch keine Präferenzen bzgl. der Hersteller - auch wenn ich denke, dass Altera eher bei hochwertigen Teilen eingesetzt wird, während Xilinx im lowbudget Bereich zu finden ist. Lattice dürfte eher Nischen besetzen und von Liebhabern eingesetzt werden. Ich schätze, ich habe mich bei den Hittite-Teilen verlesen. Wenn ich es jetzt richtig verstanden habe, dann haben die keinen PLL an Board, sondern erwarten einen externen Takt von 1 GHz =:O Spätestens an der Stelle ist Schluss mit lustig. Den Rest hätte ich mir (kraft großzügiger Selbstüberschätzung) vielleicht noch zugetraut, aber einen Takt von 1 GHz zwischen 3 ICs zu routen ... Wahnsinn. Bei der Frequenz funken doch bereits die IC-Beinchen von alleine und jede Leiterbahn ist eine Antenne ... nee, das ist nimmer lustig. > Kein Hersteller dessen Einkäufer etwas taugt zahlt Listenpreise für > hochpreisige Bauteile. Und das gilt erst recht für Chinesen. Das ist wohl wahr, aber die Verhältnisse dürften ähnlich liegen. Ich orientiere mich gerne bei digikey. Das ist ne gute Basis um Lieferbarkeit und ungefähre Preislage abzuklären. Die üblichen Verdächtigen kann man sich dann über Faktoren ableiten ;) Letztlich betreibt jeder irgendwie eine Mischkalkulation, sodass es immer auf Verhandlungen ankommt.
Taktlos schrieb: >> beim Lattice ECP3 ist es durchaus möglich viele Kanäle mit eigener >> phasenverschobener Clock einzulesen. > > Hm, könntest Du da bitte etwas ausführlicher werden? > Das Thema interessiert mich doch zunehmend. > Ich habe auch keine Präferenzen bzgl. der Hersteller - auch wenn ich Dachte das ganze war theoretisch, oder willst du dich selbst daran versuchen. > > Ich schätze, ich habe mich bei den Hittite-Teilen verlesen. > Wenn ich es jetzt richtig verstanden habe, dann haben die keinen PLL an > Board, sondern erwarten einen externen Takt von 1 GHz =:O > Spätestens an der Stelle ist Schluss mit lustig. > Den Rest hätte ich mir (kraft großzügiger Selbstüberschätzung) > vielleicht noch zugetraut, aber einen Takt von 1 GHz zwischen 3 ICs zu > routen ... > Wahnsinn. Bei der Frequenz funken doch bereits die IC-Beinchen von > alleine und jede Leiterbahn ist eine Antenne ... > nee, das ist nimmer lustig. Alles halb so wild, da LVDS. Nach meiner Meinung sogar einfacher zu entstören als 100 single ended Signale von 10 ADCs. Und entstört werden muss sehr sorgfältig, sonst mißt das ding nur Mist.
> Dachte das ganze war theoretisch, oder willst du dich selbst daran > versuchen. Naja - zuerst kommt das verstehen. Erst dann kann ich abschätzen, ob ich mich an so ein Projekt herantraue oder nicht. Mir ist schon bewusst, dass ich kein Oszi billiger wie Rigol und Co herstellen kann - aber das Thema reizt mich schon seit Jahren. Bislang fand ich allerdings keinen richtigen Zugang dazu, bzw. war immer anderweitig ausgelastet ... Inzwischen sieht die Ausgangslage etwas entspannter aus ;) Vor LVDS zu routen habe ich keine Angst. Routen liegt mir und macht mir Spaß - und mehrlagige PCBs sind manchmal sogar einfacher zu routen. Der Punkt ist - wenn ich ne Standard 4-lagige Platine in den Sand setze, dann verkraftet das die Hobbykasse. Wenn ich aber eine 6- oder 8-lagige HF-Platine, die auch noch bei den Abständen von (Billich-)Standards abweicht, in den Sand setze, dann geht das über den Hobbyetat hinaus und tut weh. Denn solche Platinen können von den üblichen Hobby-Lieferanten nicht mehr produziert werden, d.h. hier kommen dann professionelle Hersteller zum Zuge - was für mich heißt, dass die Kosten sich im Prototypenbereich bewegen - also eher die Hobbykasse sprengen. Deshalb muss ich mir da dann schon sicher sein, dass es der richtige Weg ist. Weiß nicht, ob ich sowas alleine packe. Derzeit bin ich noch nicht davon überzeugt, dass ich sowas stemmen könnte. Aber ok - ich lasse mich gerne belehren. ... doch zurück zum eigentlichen Thema: Ich denke, aus Sicht des FPGA macht es keinen Unterschied, ob ich mehrere ADCs parallel oder per LVDS anbinde. Sobald ich mehrere AD-Wandler auf einem Kanal verwende, habe ich die Phasenverschiebung sowohl im Takt, alsauch bei den Daten. Zumindest auf der Seite der AD-Wandler. Um nun auf der Speicherseite nicht unter Zeitdruck zu geraten, macht es Sinn, mehrere Messwerte zusammen zu fassen und die Datenbreite beim Speicher zu vergrößern. Spätestens wenn die Datenbreite die 32 Bit übersteigt (Beispiel AD9288), kommt die Phasenverschiebung auch auf der Speicherseite zum Einsatz. ... und hier fängt es an, für mich interessant zu werden. Daten aus unterschiedlichen Takten im FPGA einzusynchronisieren, dürfte Banane sein. Das muss ständig gemacht werden. Aber Phasenverschiebungen im FPGA vom Eingang bis zum Ausgang beizubehalten, evtl. sogar die Phasenverschiebung anzupassen, das sehe ich als nicht ganz trivial an. Bislang dachte ich immer, dass ich dazu intern einen Takt bräuchte, der mit allen verschobenen Vertretern die Flanken teilt - also das kleinste gemeinsame Vielfache - oder so ...
Taktlos schrieb: > Aber Phasenverschiebungen im FPGA vom Eingang bis zum Ausgang > beizubehalten, evtl. sogar die Phasenverschiebung anzupassen, das sehe > ich als nicht ganz trivial an. Wie ich ja bereits geschrieben habe, musst du nicht die komplette Verarbeitung phasenverschoben machen, sondern nur die Datenerfassung. Ich würde es so machen, dass ich die Schnittstellen zu den ADCs komplett auf phasenverschobenen Frequenzen laufen lasse. Also z.B. 4 Taktdomänen im FPGA erzeuge. Und genau auf diesen Taktdomänen liegen dann auch die Speicher, in die die Werte gesampelt werden. Innerhalb einer Taktdomäne bist du absolut synchron und die Synthese "kümmert" sich um die Timings, wenn du ihr nur die Taktfrequenz als Constraint mitgibst. Dann liegen dir nach einer Messung 4 Speicher mit Messwerten auf unterschiedlichen Taktomänen vor. Wenn du da z.B. DPRs nimmst, dann kannst du sogar einen unterschiedlichen Takt für die beiden Ports anlegen und hast damit den Transfer in den Systemtakt geschenkt dazubekommen. Per Adressdekoder kannst du dann nach und nach gemütlich die Speicher auslesen und die Daten wieder zusammensetzen. Klingt einfach, ist es vermutlich auch. Klar, die Probleme kommen dann mit den Details, aber grundsätzlich sehe ich hier erstmal nichts, was nicht mit relativ einfachen Methoden machbar wäre.
Angehängte Dateien:
-
Phaseshift.png
2,2 KB
> Innerhalb einer Taktdomäne bist du absolut synchron und die Synthese > "kümmert" sich um die Timings, wenn du ihr nur die Taktfrequenz als > Constraint mitgibst. Sorry, aber ganz so unbeleckt bin ich nicht. Dass es innerhalb einer Clockdomain keine Probleme gibt ist klar. Vielleicht reden wir ja an einander vorbei. Ich muss mir Dinge immer aufmalen - um sie zu verarbeiten. Deshalb ein Bild im Anhang. Um nicht eine halbe Datenbreite zu verschenken, habe ich 12 AD-Wandler angenommen. Die 12 Karos sind also der Takt der AD-Wandler und die grünen Kästen sind die Halbwellen, in denen die Daten bereitgestellt werden. Ferner habe ich angenommen, dass jeder AD-Wandler 8 Bit liefert. Jeweils 4 sind dann zu einer Datenbreite zusammengefasst (dickere horizontale Linie). Wenn ich dann noch berücksichtige, dass die Daten eine gewisse Zeit brauchen, bis sie stabil sind und ausgelesen werden können, lasse ich jeweils ein Zwölftel Takt verstreichen (eine Spalte) bevor ich die Daten im FPGA einlese und verarbeite. Für die ersten 4 AD-Werte wäre das in Spalte 5 - d.h. ab Spalte 6 könnte ich dann mit dem Schreiben des Speichers beginnen. Der Speicher könnte in der gleichen Frequenz beschrieben werden, mit der auch die AD-Wandler getaktet werden. Um wieder auf die Phasenverschiebung beim Speicher zurück zu kommen - der erste Speicher würde in Takt 5 die Daten lesen und danach schreiben, der zweite in Takt 9 die Daten lesen und der dritte in Takt 1 Wenn ich das so ansehe, wäre dann der Speichertakt meine Clockdomain? Andererseits ... wenn die AD-Wandler mit 100 MHz betrieben werden, sollte ein interner Takt von 300 MHz im FPGA doch genügen, um die ganze Logik in einer Clockdomain zu behandeln. Interne 300 MHz sollten auch die kleinen FPGA abkönnen. Nicht wahr? Somit bliebe "nur" noch die Phasenverschiebung am Clock-Out für die AD-Wandler als "Problem".
Taktlos schrieb: > Interne 300 MHz sollten auch die kleinen FPGA > abkönnen. Nicht wahr? Das wird schon sportlich. Aktuelle Designs auf dem Spartan6 laufen gut mit ca. 125 MHz. Beim Virtex6 geht es sicher noch etwa schneller. Und mit Handoptimierung läßt sich auch noch was rausholen. Aber für 300 MHz muß man schon etwas Erfahrung mitbringen. Da ist es einfacher die Datenbreite zu verdoppeln und die Taktrate zu halbieren. Duke
Taktlos schrieb: > Interne 300 MHz sollten auch die kleinen FPGA abkönnen. Nicht wahr? Garantiert nicht quer übers FPGA. Und nur mit simpelster Logik zwischen 2 Flipflops. Mehr als 1 LUT+Routing oder 2 LUTs dicht beinander wird da kaum drin sein...
Wenn du ernsthaft in Erwägung das durchzuziehen, solltest du erst noch mal einen Schritt zurücktreten und das Gesamtsystem betrachten. Die ADC -> FPGA Anbindung ist da nur ein kleines, wenn auch wichtiges Detail. Analog Frontend Trigger Unit ADC FPGA Tracememory **1 SoC als Systemcontroller. Display Netzteil **2 **1 wenn man sich auf eine Tracetiefe von 16k Punkte beschränkt reicht der FPGA interne Speicher. **2 Da ist ein angepasstes Design auch sehr wichtig, du willst ja keine Störungen aus dem Netzteil in den Traces sehen. (war übrigens ein Problem bei den als Agilent gelabelten Rigols, ein Rigolkäufer ist da i.A. toleranter als ein Agilent Kunde) 4 Lagen für ADC -> FPGA SoC wird nicht reichen, bedenke FPGA und SoC sind grosse BGAs, da braucht es mindestens einen eigenenen Layer jeweils für GND und VCC. Und mit nur 2 Signallagen hast an ein Problem an die inneren Pins zu kommen. Im Hobbyprojekt ist es eventuell sinnvoll es auf mehrere Platinen zu verteilen um das Risiko zu minimieren. Insbesondere den Analogteil wird man mindestens 2-3 mal in den Sand setzen, aber da reichen vielleicht sogar 2 Lagen. Ingesamt eine grosse Herausforderung, aber hey an solchen Dingen wächst man.
Ich glaube, dass ich wenigstens im Ansatz verstanden habe, was du vor hast. Du willst das Shifting der Takte direkt an den Ports machen und dann intern alles mehr oder weniger mit einem Takt wieder zusammenbauen und abspeichern. Kann man probieren, aber ich halte das nicht für den idealen Weg. Das von mir beschriebene Verfahren lässt sich natürlich auch auf mehr als 4 ADC anwenden in Abhängigkeit der Anzahl deiner PLLs und Clock-Trees.
> Wenn du ernsthaft in Erwägung das durchzuziehen, solltest du erst noch > mal einen Schritt zurücktreten und das Gesamtsystem betrachten. Keine Sorge - ich bin nicht blauäugig ;) ... manchmal vielleicht etwas zu mutig, aber irgendwo immer noch Realist. Das ganze in mehrere Platinen aufzuteilen - halte ich für selbstverständlich. Von den aufgeführten Modulen ist der erste Punkt definitiv nicht meine Baustelle. Analog und ich - wie Feuer und Wasser =:O Man sollte schon seine Stärken und Schwächen kennen. Ich weiß, dass ich einen Analog-Teil brauche - aber den muss nicht ich machen - zumindest nicht konzipieren. Routen und bestücken tue ich den gerne, aber analog was entwerfen - geht garnicht. Glücklicherweise habe ich Freunde, die in der Disziplin recht fit sind ;) Beim 2. Punkt denke ich, dass der vorwiegend analog sein dürfte - also auch nicht meine Baustelle. Die nächsten 3 Module sind die, die mich interessieren und mit denen ich mich auch auseinander setzen mag. Das ist für mich überschaubar und da fühle ich mich mehr oder weniger zuhause. Externen Speicher habe ich ja schon vorgesehen/angedacht - das ist ein Muss. Die letzten 3 Module sind (mir) wieder völlig nebensächlich. Ich will ja kein Verkaufsprodukt erstellen, deshalb wäre es für mich völlig in Ordnung, anfangs nur das Labornetzteil mit zu misbrauchen und Display interessiert mich auch nicht. Eher die Kommunikation zum PC o.ä. also Speicher nach der Messung auslesen und übertragen - ist wohl die leichteste Übung von allem. Hier wäre ich sogar geneigt, einen FPGA zu verwenden, der schon GBit Ethernet o.ä. kann ... Wenn ich die Module, die mich interessieren, realisiert habe, dann kann ich immer noch überlegen, was ich mit den restlichen Modulen mache. Ob ich mich dran mache oder mit dem zufrieden bin, was tut ... Vorher will ich mich damit nicht belasten. > 4 Lagen für ADC -> FPGA SoC wird nicht reichen, bedenke FPGA und SoC > sind grosse BGAs Klar, wenn ich die Hittite-Variante umsetzen will, dann komme ich um BGA nicht herum. Anders sehe ich das bei den AD9288 - dort könnte ich bei TQFP bleiben. Evtl. bräuchte ich dann 2 FPGA - das würde die Zeitschiene wieder etwas entspannen. Nicht dass ich Angst vor BGA hätte - nur wenn es sich vermeiden ließe, dann werde ich es mir freiwillig nicht antun. Ist doch eine deutliche Steigerung von Aufwand und Kosten ... Würde es bei 2 FPGA nicht Sinn machen, den/die ADC-Takte extern zu erzeugen (wie bei der Hittite Variante)? Gibt es ICs, die von einem Takt einstellbare/konfigurierbare Offsets erzeugen können? Wie gesagt - ich bin noch lange nicht soweit, dass ich sagen könnte, ich geh die Realisierung an oder hätte mich schon für eine Variante entschieden. Es sind noch etliche Variablen nicht bestimmt. Da muss ich noch ein paar Varianten durchspielen. Auf jeden Fall danke ich Euch allen für die Unterstützung!
Mann hatte ich ein fettes Brett vorm Kopp :O Die einfachste Lösung habe ich garnicht gesehen. Auch nicht als Duke mich darauf hinwies. Habe heute mit einem Kumpel die Kiste durchgekaut und da fiel es mir wie Schuppen aus den Haaren ... bin immer an der Datenbreite der Speicher-ICs hängen geblieben. Bis mich mein Kumpel drauf brachte, dass ich die Datenbreite ja durch mehrfache ICs vergrößern kann. Nun ja - jetzt sind alle Klarheiten beseitigt. Die AD9288-Variante ist vom Tisch. Wenn ich es anpacke, dann mach ich es richtig und entwerfe eine HF-Platine natürlich mit BGA ... Als Speicher werde ich mehrere asynchrone SRam mit Doppelport einsetzen. So kann ich die Datenerfassung völlig von der Datenverarbeitung trennen. Werde mich also etwas intensiver mit den Hittite-Teilen auseinander setzen und mein Quartus aktualisieren. Wünsche allerseits einen angenehmen Abend
Taktlos schrieb: > Als Speicher werde ich mehrere asynchrone SRam mit Doppelport einsetzen. Geld spielt bei deinem Design keine Rolex, oder wie?
Taktlos schrieb: > So kann ich die Datenerfassung völlig von der Datenverarbeitung trennen. Ach nee.. was hab ich die ganze Zeit schon geredet? gg
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.