mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP 100Ms/s mit 100MHz, AD Wandler Daten speichern. Wie am besten?


Autor: hfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

kurz vor meiner DiplomArbeit stehe ich vor einem Rätsel. Es soll eine 
Datenaufnahme von 100MS/s erreicht werden. Es wurde mir empfohlen, einen 
kleinen FPGA zu verwenden. Dieser soll den AD Ansprechen und die Daten 
in einem externen RAM speichern. Diese augenommenen Daten (ca 20µs 
Aufnahmezeit) sollen dann mit einem DSP verarbeitet werden (Hilbert 
Transformation -> Demodulation, einige andere kleine Rechnungen).
So, weiterhin soll der AD eine Bandbreite > 100Mhz aufweisen. am besten 
sollen 500Mhz sein.... Der Kracher.

Ein kleiner Atmega soll dann die Kontrolle übernehmen, Tasten eingabe, 
Display, Kommunikation mit Rechner...

Daten zusammengefasst:
 - 100MS/s AD Wandler
 - 20µs Aufnahmezeit
 - > 100Mhz Bandbreite des AD Wandlers
 - DSP für Hilbert/Berechnung
 - FPGA für Datenaufnahme
 - externer RAM

Meine Rechnung:
 - 100 MS/s = 100 S/µs
 - somit ergibt sich 2000 Samples bei 20µs
 - Eine Speichertiefe von mind 8 Bit -> 2000 Samples*8Bit

 => 16kbit=2kByte Daten

Jetzt ist das ja nicht allzuviel an Daten. Gibt es nicht eine 
Möglichkeit den FPGA einzusparen und direkt in einem RAM zu speichern 
auf der der DSP direkten Zugriff hat?
ist das Projekt so realisierbar?

mfg,

für Anregungen bin ich dankbar

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: hfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: hfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke Helmut,

das System soll standalone laufen. Also ohne PC.

Ich verstehe jetzt richtig, nur den FPGA und einen externen der die 
Daten verarbeitet.

Der FPGA macht folgendes:

- AD Wandler steuern
- Daten aufnehmen in den internen RAM des FPGA
- Daten bereitstellen für den externen
- Kontaktaufnahme mit Ergebnis nach aussen (möglichwerweise Display, 
RS232, ..)

Der externe macht folgendes:

- Daten vom FPGA aufnehmen
- Daten auswerten
- Ergebnis zurückgeben

Welcher DSP erlaubt ist weiß ich noch nicht. Man ist dort recht 
unbeleckt was das Thema angeht. Ob man einen 32Bit µC ist denke ich mal 
ebenfalls egal. Ich denke, da nehme ich lieber das, was besser 
dokumentiert ist. Ich bin an und für sich ja HFler, kein Programmierer 
:-)
Selbst aufbauen würde ich mir zutrauen. Habe schon einiges unter altium 
gebaut. Aber wenn es ein fertiges Board mit allen drum und dran gibt, 
dann nehm ich lieber das. Der Flashy AD hat leider keine 100MS/s.


mfg

Autor: avr (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schau doch mal bei den üblichen Verdächtigen.
(Analog, TI, Linear ..)

Die meisten haben zu ihren Wandlern auch fertige
Boards. Auch wenn du ein solches nicht einsetzen
darfst ist es eine Hilfe.

z.B. hier ein AD von Linear, oben in der Liste geht es dann
zu den Boards:
http://www.linear.com/pc/productDetail.jsp?navId=H...

avr

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

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

Autor: Markus K. (markus-)
Datum:

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

Autor: schalter_walter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Markus,

ja das denke ich ja auch. Wieso sollte ein DSP das nicht mit aufnehmen 
können? Ich suche, aber die DBs zu lesen ist schon recht mühselig :-)


mfg

Autor: Thomas R. (tinman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hfritze schrieb:

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

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

Autor: Florian Thevissen (fthevissen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Volker Zabe (vza)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rene B. (themason) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 
;-)

Autor: Gast13165 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Rene Böllhoff (themason)

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

Wenn Du schon nicht lesen und Dich an die Regeln fuer dieses Forum 
halten kannst - es sei Dir verziehen.

Wichtige Regeln - erst lesen, dann posten!

    * Groß- und Kleinschreibung verwenden


Aber wenn es dann absolut FALSCH wird, dann ist das eines Technikers
(im Sinne von: jemand, der sich mit technischen Dingen beschaeftigt) 
unwuerdig.

Gast

Autor: hfritze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal an allen. Ja, richtig es muss keine Echtzeit Verarbeitung 
durchgeführt werden. Primär erstmal vom FPGA DAten aufnehmen und 
speichern.

Da ich in der Materie noch nicht bewandert bin, bitte ich euch etwas 
genauer zu werden.

@Rene Böllhoff:

Welchen Xilinx meinst du? Spartan 3-50 ? Die Nutzinformation liegt zw. 
12-19Mhz, die Bandbreit von 100Mhz gibt eine Norm vor.

Ich möchte das Board gerne selbst layouten. Daher sind mir Bsp sehgr 
lieb. Als AD Wandler habe ich mir den 8Bit ADC082000 -> 
http://cache.national.com/ds/DC/ADC08200.pdf
ausgesucht.

mfg

Autor: Strubi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

die Schmalspur-DSPs von ADI und TI (Blackfin, C6000er, etc.) schaffen 
die Verarbeitung von 100 MS/s nicht so ohne weiteres, ausser, es sind 
8-Bit-Samples und koennen in 16 bit bei der halben Taktfrequenz (50 MHz) 
gemultiplext werden.
Wuerde in dem Fall auch eher zu einem FPGA greifen, wenn die Datenmenge 
nicht ausartet. Allerdings ist ein SDRAM-Controller nicht 
ohne...vielleicht geht's aber noch besser mit einem schnellen SRAM.
Die TigerSHARCs kaemen mit der Datenrate gut zurecht, aber die HW 
entsprechend teuer. Da ist das Entwickeln einer FPGA-Loesung ev. etwas 
aufwaendiger von der Entwicklung her, dafuer kann bei der Hardware nicht 
allzuviel schiefgehen (nach meiner Meinung).

Gruesse,

- Strubi

Autor: Roland Bumm (rolandb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hansilein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
bei 2 kB brauchst Du keinen externen Speicher. Du kannst den im FPGA 
verwenden.

Autor: Roland Bumm (rolandb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Was ich nicht brauche, lasse ich einfach weg.

mfg

Autor: icke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: icke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ok für dein Beispiel keine Fragen.
In der ursprünglichen Problemstellung sehe ich nur keine dergearteten 
Bandbegrenzungen. Sogar eine geforderte BandBREITE die nicht wirklich 
ein Pappenstiel ist.
Bei deinem Signal wäre es vielleicht für den Aufbau an sich eine 
Überlegung früh runter zu mischen?
Vielleicht mal drüber schlafen und morgen noch mal lesen.

Autor: icke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roland Bumm (rolandb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: icke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.

Autor: Roland Bumm (rolandb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: icke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte nicht gesehen, daß du der op bist. Schweinegrippe. Vielleicht 
rede ich daher wirr....

Ich finde schon daß das ein ordentliches Pensum ist. Ob nun zu viel oder 
nicht kann am besten der Betreuer einschätzen.
Ich würde mich ohne die Erfahrung was die hdl und sonstige 
programmierung angeht da wohl nicht rantrauen.


Schon angemeldet die Arbeit? Zumeist checkt man ja erst genauer ab, wie 
der zeitplan sich entwickelt. da würde ich dem Bertreuer der Arbeit auch 
noch mal auf den Zahn fühlen, denn der sollte ja selber überblicken was 
wann geschafft werden kann/soll. und wenn du das Gefühl hast, daß das 
nciht gegeben ist, wär (ich persönlich wie gesagt) bischen vorsichtig.

Wodurch soll die Aufnahme des Signals eigentltich gestartet werden? 
Externes Triggersignal oder irgendetwas wie Schwellwert Triggerung?

Der Kontrollzweig ist irgendwie auch noch offen. Wenn da eine schnelle 
Visualisierung dran hängt also so 50 Hz o.ä. finde ich das auch schon 
nicht ganz schnell erledigt - Beispiel: da hängt das zusammenfassen der 
2k Punkte drin usw. usw. Ohne Framebuffer und double Buffer flimmert dir 
das wie Sau.
Was meinst du mit externen Schnittstellen? Ethernet/usb? dann ufert das 
langsam wirklich aus... Dann kommt ja noch eine Unbekannte nach dem dsp.

Frage an alle: gibt es etwas in Richtung usb als fertige Komponente für 
fpga? Etwas analog zu den usb Oszilloskopen wäre vielleicht auch eine 
Idee. Sprich Auswertung/Anzeige/Berechnungen/Speichern auf einem 
schnöden PC und Übertragung der datenblöcke über usb. Im grunde die 
pc104 Sache weiterverfolgt.

Halte uns unbedingt auf dem Laufenden und viel Erfolg :-)

Autor: Sebastian Wendel (coffee_engineer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bruno We (brunowe) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Sebastian Wendel (coffee_engineer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roland Bumm (rolandb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roland Bumm (rolandb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Roland Bumm (rolandb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke an alle.

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



mfg

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.