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...
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.
> 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.
> 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
