100Ms/s mit 100MHz, AD Wandler Daten speichern. Wie am besten?

Ein 100MHz Symchronzähler plus RAM auf einem Board ist nicht trivial.

Das mit dem FPGA ist doch Klasse und professionell. Da hast du alles in 
dem FPGA: Zähler, Logik, RAM, Schnittstellen zum Auslesen u.s.w..

Das wärs z. B. .
http://www.fpga4fun.com/digitalscope.html
http://www.knjn.com/Flashy.html

hfritze schrieb:
> Danke Helmut,
>
> verstehe ich dich richtig auf einen DSP zu verzichten und alles in den
> FPGA reinzubraten? Speichercontroller, DSP,...?
>
> Oder meinst du der FPGA macht die "Datenaufnahme" und der DPS die
> Datenverarbeitung?
>
>
> mfg

Den DSP würde ich extern lassen. Schon allein wegen der 
Entwicklungstools (Assembler, Compiler, Debugger). Welche DSP sind denn 
erlaubt? Oft haben die Betreuer/Institute da ihre Vorlieben. Je nach 
Komplexität der Algorithmen und dem Dynamikbereich der zu erwartenen 
Zahlen während der Berechnung sollte man, falls erlaubt, auch an einen 
Fließkomma-DSP oder 32bit-uP denken. Das macht die Softwareentwicklung 
bestimmt einfacher. Diese Entscheidungen hängen natürlich auch davon ab, 
ob du selber das Teil aufbauen musst. Dann fallen Lösungen mit 
Bausteinen im BGA-Gehäuse oft schon flach. Die könnte nur ein Bestücker 
verarbeiten. Extraaufwand mit DSP bringt nur Vorteile, wenn 
Echtzeitfähigkeit gefordert wird. Ansonsten ist es einfacher mit einem 
32bit uP-controller zu arbeiten.

Falls du keine Echtzeit-Anforderungen hast, dann ist es sogar noch 
besser statt im DSP oder uP auf dem PC zu rechnen.

http://openhpsdr.org/mercury.html
ein Kurzwellenempfänger mit LTC2208 und CycloneIII-FPGA

Gibts denn keinen DSP, der die 100MSPS abkann? Dann könnte man doch den 
FPGA und das externe RAM einsparen.

hfritze schrieb:

> Der Flashy AD hat leider keine 100MS/s.
>

der kann doch 60MSs, 100MSs und 200MSs je nach version.

Mh interessantes Projekt, werde sicher mitlesen hier :).

Am Rande.. nen DSP ist doch nen (mehr oder weniger) einfacher uC mit 
extra Mathefunktionalitaet in Form von extra Instruktionen, oder?

Dann klingen 100MS/s schon viel; nen uC braeuchte dann doch nur um die 
Daten aufzunehmen mindestens (!!) nen Takt von 200Mhz. Nun soll noch 
gerechnet werden mit jedem Sample, was sicherlich doch auch nicht in 30 
cycles erledigt sein wird? Damit wuerden wir doch bei 30 * 200Mhz 
ankommen...oder? 6Ghz... ouch!

Denke ich da richtig?
Gruss,
Flo

So wie es sich liesst muss er die Daten nicht Online (in 20µs) 
verarbeiten.
Vorschlag:
DSP (blackfin .... etc) liest die Daten per DMA ein und verarbeittet sie 
anschliessend.
Die meisten DSP haben interne Komunikationskontroller (mindestens 
Serielle Schnittstelle)
Also alles einen (schnellen mit DMA) DSP machen lassen.

@hfritze

also fpga wäre die lösung der wahl, weil :

- internes ram (2kbyte blöcke, zumindest bei xilinx)
- 100mhz nur zum erfassen des ad-wertes und wegspeichern -> klacks für 
den fpga
- späteres auslesen des speicherinhaltes durch geeignete schnittstellen 
-> klacks, da die xilinx-blockrams als dual port ausgeführt sind

ich würd für die reine erfassung der werte den kleinsten fpga (spartan 
3-50) nehmen. der hat glaub ich 4 x 2kbyte rams (organisation fast 
beliebig), hat dcm's (digitale pll bzw frequenzvervielfachung) und 
beitet noch genug platz für eine schnittstelle zum verarbeitenden 
controller hin (es bietet sich z.b. spi an). das ganze dürfte der fpga 
ziemlich locker packen, wenn sich mit der reinen erfassung nicht sogar 
noch hörere datenraten realisieren lassen.
nicht ganz so trivial sind die 100mhz analogseitig bzw der analogteil 
generell. hier dürfte mit die meiste arbeit drin stecken.

hoffe ich konnte eine anregung geben.

ps. bevor wieder gemunkelt wird .... mhz = MHz ... und nicht milli hertz 
;-)

Habe mich mal angemeldet,

aha der Spartan den  Rene Böllhoff meinte ist der Spartan3 XC3S50AN. Den 
gibt es als TQFP, also auch auflötbar. Ich habe da aber bisher gar kein 
Gefühl was die Speichergröße betrifft. Folgendes muss realisiert werden:

FPGA <-> AD Wanndler via Paralleles interface D0..7, zzgl. PD und Clock 
pin für den AD Wandler ADC082000. Kommt der Clock auch aus dem FPGA für 
den AD Wandler? Der PD Pin ist nur für PowerDown.

FPGA<->ext SRAM... Was bietet sich da an? Ich denke ein 8Bit 
Datenbreites SRAM genügt ebenfalls. Weiterhin bei 2kByte Daten würden ja 
11 Adressleitungen ausreichen. 8Bit x 2^11 muss der externe Speicher 
groß sein. Ich sehe aber in vielen Forumsbeiträgen das dort wohl der 
Hase begraben liegt? Ist das so schwer, ein SRAM anzuschließen?

Dann kommt noch die Kommunikation nach außen. Zum externierten DSP vlt 
auch ein einfacher Atmega (1280?) der dann ausreicht? Diese 
Schnittstelle kann dann auch Parallel erfolgen. Also auch 8Bit + 3 
Steuerleitungen.

Sehe ich das alles falsch, oder soll ich lieber einen seriellen Bus für 
die Kommunikation zum DSP/Atmega herstellen?

mfg

Der XC3S50AN  hat 54K Block-RAM. Das sind mehr als 6KByte. Da brauchst 
du doch gar kein externes RAM.

A/D-Wandler taktet man nicht aus dem FPGA heraus wegen dem Timing-Jitter 
der FPGA-Ausgänge.

Aha, danke euch! Jetzt langsam lese ich mich hinein. Als Schematic Bsp 
kann ich ja dieses Spartan 3AN Board hier nehmen:

http://www.xilinx.com/support/documentation/boards_and_kits/s3astarter_schematic.pdf

Was ich nicht brauche, lasse ich einfach weg.

mfg

Angenommen du hast ein bandbgrenztes Signbal mit f=200MHz bis 220MHz.
Wenn du das jetzt mit 100MHz abtastest, dann liegt das nach der 
Abtastung bei 0 bis 20MHz (220MHz-2*100MHz).
Man kann diesen Wandler somit bei Unterabtastung auch für Frequenzen 
größer Fa/2 einsetzen.

icke schrieb:
> Kann mir jemand mal die 500 MHz Bandbreite des ad Wandlers erklären?
> Also der Verstärker soll 500 (!) MHz Bandbreite haben oder was verstehst
> du unter der Bandbreite des AD Wandlers? Wandlungsrate bei 100 MHz?
> Ich habe offenbar ein Brett vorm Kopf, da sonst bestimmt schon jemand
> anders im Hinblick auf Abtasttheorem gepostet hätte.
> Erklär doch mal, warum das so Sinn macht - danke.

Gerne, dies ist ein Wert der die Norm  vorschreibt. Es müssen 
normalerweise Oszilloskope mit dieser Bandbreite (-3dB) verwendet werden 
um Normkonform zu messen

icke schrieb:
> edit: es geht nicht um einen Stream von 100 Mhz oder? also die 2 k
> Sample Blöcke müssen nicht mit 100 MHz aus dem "fifo".
> Das würde die Frage nach der Aktualisierungsrate aufwerfen, aber
> zumindest den Flaschenhals in den dsp entschärfen.
> Die dual core blackfins haben zumindestens 2 schnelle Schnittstellen,
> über die du 2 50 MHz Signale übertragen könntest - falls doch nötig. 100
> MHz sind meines Wissens sonst nicht drin.

Aus dem fifo müssen Sie nicht so schnell, nur hinein :-) Ein FPGA sollte 
das doch schaffen?


mfg

icke schrieb:
> danke dir. Bist du in die Aufgabenstellung eingebunden, denn daß diese
> unter eine Norm für Oszilloskope fällt ist mir nicht klar gewesen. Lohnt
> vielleicht mal reinzugucken.
> Verstehe ich es richtig, daß die 500 MHz dann gar kein nennenswertes
> Problem wird? Die Hersteller dürften sich ja darauf einstellen und mit
> den entsprechenden Bandbreiten reagieren - ich hab die Angabe auf das zu
> untersuchende Signal bezogen.

Ich bin in der Aufgabenstellung eingebunden. Die Frage verstehe ich 
jetzt nicht.

> Darauf, daß man ja schließlich auf ein fifo zurückgreift bin ich
> explizit noch mal eingegangen, weil die Übertragung in einen dsp als
> problematisch auftauchte. Ein fpga mit integriertem
> konfigurationsspeicher mit dsp hört sich für mich nun schon sinnvoll an.
> Da es sich um eine Diplomarbeit handelt, wo ja üblicherweise eher
> irgendwelche mathematischen Probleme im Fokus stehen - was passiert dann
> mit der hilbert Transformierten eigentlich? Vielleicht könnte man
> darüber nachdenken ob anstelle des dsp eine pc104 Lösung sinnvoll wird?
> Im hinblick auf Weitergabe  Berechnung  Schnittstellen / speichern am
> einfachsten.

Die Hilbert Transformation gibt mir das modulierte Informationssignal 
zurück. Also ein Demodulator. Da ich keine logische Auswertung vornehme, 
sondern eine physikalische Überprüfung (Impulslängen, Steig- 
Fallzeiten...) muss ich ein Signal möglichst Detailgetreu abtasten und 
auswerten können (daher die 100MS/s, welche eine 5fache Überabtastung 
des Trägersignales). In meiner DA steht nicht die Mathematik sondern das 
Funktionieren/Aufbau des Systems.

Gibt es eine Verknüpfung zw. analoger Bandbreite 500Mhz und der 
Abtastrate vonn 100MS/s?

Ich habe jetzt so einiges gelesen und ich muss eigentlich folgendes 
machen:

1. Layout erstellen in Altium (4lagig, AD Wandler, FPGA, 
Versorgungsspannung, Kommunikationsschnittstellen, ...)
2. Aufbau/löten des Systems
3. Programmieren des Systems
4. Testen des Systems

Schon 1. ist verdammt schwer, habe aber eine gute Vorlage im Netz 
gefunden.
link: http://www.hdl.co.jp/en/spc/XCM/xcm-303/index.html

2. Sollte kein Prblem sein..
3. VHDL kann ich net, C nur etwas, Assambler schon eher
4. Die Zeit wird knap :-)

Wenn ich mir das so anschaue ist das richtig fett. Ist es vlt zu viel?


mfg

Hallo,

Sorry das ich das mal so drastisch sagen muss, die Diplomarbeit ist 
Schwachsinn. Kauf ein Rigol Scope, die haben einen CycloneIII drin und 
einen Blackfin, das ganze zu einem Preis das schaffst Du mit deiner 
Diplomarbeit nicht.

Ich kenne auch andere Firmen die auf dem Trip sind. :-)"Wir sind die 
Super Hardwerker, wir machen alles selbst",.... aber Budget,Time to 
Market,... No Way Dude!!! SSieh dir mal Wittig an die brutal gescheitert 
sind. Analog Frontends sind nicht einfach, Taktung der ADC's,.... .

Ich bin sicher einer der wengen die bei Rigol schon vor Ort waren, hatte 
einen guten Eindruck. Sag deinem Chef er soll mal da anrufen und keine 
Aussichtslose Diplomarbeiten ausschreiben. Im Zeifelsfall zum Spielen 
mal n Wittig kaufen.

Grüße

Coffee

Hallo,

als einer der Akteure beim open-source Projekt Welec W2000a DSO, bin ich 
durch den Suchbegriff "Wittig" auf eure Posts gestossen.

Zum einen muss ich sagen: Respekt für dieses DA- Thema, da hast du dir 
ja was aufgehalst!!!
Meinem Vorredner stimme ich soweit zu, es gibt fertige Lösungen für 
diese Problemstellungen (auch das Wittig, Respektive Welec- Scope kann 
das ohne Probleme). Billiger oder besser wirst du das auf keinen Fall 
hin bekommen.
Doch manchmal geht es bei einer DA auch nicht darum....

Du schreibst des Weiteren du hast keine Ahnung von VHDL?!- Dann kann ich 
dir nur dringendst raten, die Finger vom FPGA zu lassen. VHDL ist nichts 
was man mal so nebenher lernt, auch nicht die Grundzüge. Von dem her 
halte ich die Aufgabenstellung ohne fundierte VHDL Kenntnisse mit einem 
FPGA für nicht lösbar. (Ansonsten ist es natürlich das Mittel der Wahl!- 
am Besten die DSP- Funktionalität und einen Softcore mit in den FPGA, 
internen M4K Ram nutzen und du brauchst "nur" noch die Analogseite mit 
externe Bauteile aufbauen.)

Falls du wirklich an diesem Thema dran bleibst, dann setz dich doch mal 
mit einem der Entwickler des Welec Projekts in Verbindung 
(http://sourceforge.net/projects/welecw2000a/develop), da wird dir gern 
geholfen. Speziell findest du dort auch viel Interessantes zum 
Analogpart.


Gruß, brunowe

Ach ja noch was: bei den geringen Anforderungen lässt sich das ADC 
Timing ohne Probleme mit einem FPGA durchführen (der im Welec Scope 
verwendete FPGA hat z.B einen Jitter von max 200ps)

@ Bruno

"nur" die Analogseite? DC-500Mhz, Respekt wer das mal so schnell aus dem 
Ärmel schüttelt. Aber ja, gibt sicher Leute die das können.

Zur Signalverarbeitung, nimm nen DSP, der ist um Dimensionen günstiger 
als ein Softcore, falls der denn überhaupt noch rein passt.

Vielleicht ist ach ein PC basiertes Oszilloskop eine Alternative, oder 
eines mit LXI, z.B. das 1204 von Rigol, kann man mit Labview ansprechen. 
Wenn so eine Lösung in Frage hast Du etwas das funktioniert und kannst 
es schnell und kostengünstig umsetzen. COTS CostumOffTheShelf ist immer 
vorzuziehen wenn es technisch geht. Man entwickelt ja um Geld zu machen, 
nur Hobby ist just for fun.

Grüße

Coffee

Andi schrieb:
> Ich würde für diese Aufgabe auch den XMOS chip in Betracht ziehen.
> Der ist eine Art FPGA Ersatz, kann aber in C programmiert werden.
> 100 MHz sampling sollte er schaffen, und es bleiben immer noch 3..7
> parallele Threads zur Auswertung der Daten.
> http://www.xmos.com/
>
> Gruss
> Andi

Also wenn ich deren Datenblätter überfliege, dann stelle ich fest, dass 
dieses Teil total ungegeignet ist.

Das einzig Senkrechte ist die Lösung mit FPGA. Nicht umsonst ist das in 
jedem Digital-Oszi auch mit FPGA realisiert.

Danke an alle. Ich denke auch der XMOS wäre nichts für das projekt. Aber 
trotzdem danke!

Jetzt lese ich viel und ich frage mich, warum darf denn der FPGA nicht 
selbst rechnen? Es soll ja wie gesagt eine Hilbertrtransformation 
durchgeführt werden und braucht nicht Echtzeit sein, somit kann der FPGA 
die Daten vom AD Wandler aufnehmen, und die Daten dann selbst berechnen 
(ohne Softcore!). Sehe ich das richtig, dass ich den Filter (was ja eine 
Hilberttransformation nunmal ist) in VHDL selbst schreibe?


mfg

Roland Bumm schrieb:
> Danke an alle. Ich denke auch der XMOS wäre nichts für das projekt. Aber
> trotzdem danke!
>
> Jetzt lese ich viel und ich frage mich, warum darf denn der FPGA nicht
> selbst rechnen? Es soll ja wie gesagt eine Hilbertrtransformation
> durchgeführt werden und braucht nicht Echtzeit sein, somit kann der FPGA
> die Daten vom AD Wandler aufnehmen, und die Daten dann selbst berechnen
> (ohne Softcore!). Sehe ich das richtig, dass ich den Filter (was ja eine
> Hilberttransformation nunmal ist) in VHDL selbst schreibe?
>
>
> mfg

Du hast doch eh einen DSP. Dann mach das dort in Software. Das ist viel 
einfacher als in VHDL. Habe ich nicht gelesen, dass du noch keine Ahnung 
von VHDL hast? Dann macht das doch gar keinen Sinn unnötige Komplexität 
ins FPGA zu packen. Denk daran, du musst in kurzer Zeit fertig werden.

Helmut S. schrieb:
> Roland Bumm schrieb:
>> Danke an alle. Ich denke auch der XMOS wäre nichts für das projekt. Aber
>> trotzdem danke!
>>
>> Jetzt lese ich viel und ich frage mich, warum darf denn der FPGA nicht
>> selbst rechnen? Es soll ja wie gesagt eine Hilbertrtransformation
>> durchgeführt werden und braucht nicht Echtzeit sein, somit kann der FPGA
>> die Daten vom AD Wandler aufnehmen, und die Daten dann selbst berechnen
>> (ohne Softcore!). Sehe ich das richtig, dass ich den Filter (was ja eine
>> Hilberttransformation nunmal ist) in VHDL selbst schreibe?
>>
>>
>> mfg
>
> Du hast doch eh einen DSP. Dann mach das dort in Software. Das ist viel
> einfacher als in VHDL. Habe ich nicht gelesen, dass du noch keine Ahnung
> von VHDL hast? Dann macht das doch gar keinen Sinn unnötige Komplexität
> ins FPGA zu packen. Denk daran, du musst in kurzer Zeit fertig werden.

Danke Helmut,

den DSP habe ich nicht wirklich. Erst wenn ich das Projekt mit DSP 
definiere, habe ich einen DSP :-) Das System wird erstmal definiert 
(habe noch 3 Wochen Zeit). Wenn der FPGA das alles kann, dann brauch ich 
natürlich kein DSP mehr. Wenn ich mich in VHDL reinfuchse, brauche ich 
mich nicht zusätzlich noch in C reinfuchsen. Ich spiele gerade mit der 
ISE herum und finde die Hilfen recht ausführlich. Ich habe ein COE File 
(Filterkoeffizienten) bereits unter Matlab erzeugt und in meinem 
Testprojekt eingefügt. Bisher komme ich mit der ISE recht gut zurecht.

Ich lese im Netz noch viel und teste mit der ISE herum.


mfg

Danke an alle.

Das Projekt hat sich aufgrund der zu hohen Anforderungen erledigt. Das 
neue projekt ist etwas simpler. Mit einem Atxmega..



mfg