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
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
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
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.
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
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=H0,C1,C1155,C1001,C1150,P13693 avr
Gibts denn keinen DSP, der die 100MSPS abkann? Dann könnte man doch den FPGA und das externe RAM einsparen.
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
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 ;-)
@ 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
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
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
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
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.
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.
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.
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.
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
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.
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
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 :-)
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
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
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
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.