Guten Abend zusammen, im Rahmen eines Projektes, in dem eine bestehende Schaltung mit einer Reihe an diskreten Logikbausteinen vereinfacht werden soll, stehe ich gerade vor der Entscheidung welche Technologie hier wohl die Richtige ist. Leider drehe ich mich hier derzeit aufgrund der Flut an Informationen und der Menge an unterschiedlichen Lösungen etwas im Kreise... und hoffe dass ihr mir hier eventuell weiterhelfen könnt. DER STAND: Konkret geht es um die angehängte Struktur in der ein AD-Wandler (120 kS/s Abtastrate) automatisiert via SPI ausgelesen wird und die Werte (4 x 24 Bit) über eine recht komplexe Schaltung in einem FIFO Speicher gepuffert werden. Die Abfrage erfolgt schließlich alle 200 us über einen seriellen 2-Draht Bus mit einer Taktrate von >100 Mhz. DAS ZIEL: Um flexibler zu sein und um die komplexen Schaltungen zu entschlacken, soll nun das Puffergerüst mit Hilfe eines Mikrocontrollers, DSP oder DSC abgebildet und ersetzt werden. Doch die Wahl welche Technologie die richtige für meinen Anwendungsfall ist fällt mir nicht leicht. DIE ANFORDERUNGEN: - Programmierung am besten in C - Kostengünstige Werkzeuge - Preis sollte max. 25€ / IC nicht übersteigen DIE SCHNITTSTELLEN-ANFORDERUNGEN: - SPI Master zur Kommunikation mit ADC: 10 - 40 MHz CLK - Interner Speicher für Programm (Software FIFO, Bissle Logik,...) - Interner Datenspeicher mind. 4k (Software FIFO) - 2 Wire Interface zum Austausch gepufferter Daten mit FPGA: > 100 Mhz - SPI Slave als zusätzl. Kommunikationskanal mit FPGA: ab 100 kHz CLK - I2C Slave als zusätzl. Kommunikationskanal mit FPGA MEINE RECHERCHE: - Eignung Micro-Controller: Die meisten Controller 16/32 Bit werden wohl Probleme mit der Abbildung der hohen Taktfrequenzen haben. FÄLLT DAMIT VERMUTLICH WEG! Meine bisherigen Recherchen laufen auf einen DSC oder DSP hinaus: z.B. die BLACKFIN Serie von ANALOG DEVICES. Leider sind die Entwicklungswerkzeuge VisualDSP++ hier sehr teuer... > 3000€!! Lässt sich das ganze vielleicht doch mit einem kleinen MCU realisieren? Welche Lösungen kommen euch hier noch in den Sinn? Herzliche Grüße und schon mal Danke für eure Unterstützung, Jogi
Angehängte Dateien:
-
Aufbau.png
21 KB
Joachim H. schrieb: > mit Hilfe eines Mikrocontrollers, DSP oder DSC abgebildet und ersetzt > werden FPGA hast du noch vergessen.
Hallo Wolfgang, danke für deine schnelle Anwort. Das ist richtig - den hatte ich bis jetzt außen vor gelassen, da mir das wirklich etwas wild für die eigentlich kleine Aufgabe vorkommen würde. Wobei es hier mittlerweile auch sehr günstige Varianten am Markt gibt. Auf Systemebene kümmert sich derzeit ein XILINX Zynq 7 um die weitere Datenverarbeitung - aber vielleicht wäre ein kleinerer Spartan oder so an dieser Stelle ja auch für die Arbeit geeignet... Empfand es bislang als "too much", aber lasse mich da gerne korrigieren.
Musst du das dazwischen bauen als Produkt, oder musst du es schlussendlich einfach im FPGA haben? Wenn letzteres, würde ich es im FPGA lösen. Grund: 1. ist er schon da und 2. dafür sind sie (unter anderem) genau für solche Sachen geschaffen.
ähm, warum schließt du die AD-Wandler nicht direkt am FPGA an? Die FIFOs sind ja nicht wirklich groß und du hast dann voll Flexibilität.
Joachim H. schrieb: > meine bisherigen Recherchen laufen auf einen DSC oder DSP hinaus: z.B. > die BLACKFIN Serie von ANALOG DEVICES. Leider sind die > Entwicklungswerkzeuge VisualDSP++ hier sehr teuer... > 3000€!! Tach, der Blackfin wird auch von GCC unterstützt, aber für das was Du vorhast, kommen die Chips an ihre Grenzen, ab 60-80MHz System-Clock wirds eng bzw. recht experimentell. Ich würde das alles ins FPGA verfrachten. Gruss, - Strubi
Zunächst einmal vielen Dank für die Rückmeldungen! Danke auch zur Einschätzung zu den Blackfins - hatte das so noch nicht auf dem Schirm. Vom Prinzip habt ihr recht - auch ich würde den bzw. die ADCs lieber direkt am FPGA anschließen... das ist in dem Fall leider nicht möglich, da die ADCs zusammen mit weiteren DACs und ein paar MCUs an einem gemeinsamen SPI Bussystem hängen. Das heißt z.B. 5-6 ADCs, 2-3 DACs und 2 MCUs teilen sich ein Bussystem. Da die ADCs und DACs nicht immer im richtigen Moment (EOC falling edge) abgefragt werden können, müssen die Ergebnisse irgendwo gepuffert werden um sie dann mit einem schnellern Takt (> 100 MBit/s) im Paket abzufragen. Das ist der Gedanke dahinter... Nachdem ich noch einmal ein wenig bei den FPGAs geschaut habe, gefällt mir die Variante mit einem 8€ Spartan-3 oder 20€ Spartan-6 doch sehr gut. Insbesondere da ich bereits mit der XILINX 7er Serie arbeite. Dadurch würden sich zugleich noch ein paar andere Bauelemente sparen und Funktionen vereinfachen lassen... wodurch ich mit FPGA inkl. Beschaltung (RAM, Flash, Quarz,...) doch noch immer günstiger als die momentane LÖsung fahren würde.
Joachim H. schrieb: > Vom Prinzip habt ihr recht - auch ich würde den bzw. die ADCs lieber > direkt am FPGA anschließen... das ist in dem Fall leider nicht möglich, .. etwas später > Nachdem ich noch einmal ein wenig bei den FPGAs geschaut habe, gefällt > mir die Variante mit einem 8€ Spartan-3 oder 20€ Spartan-6 doch sehr > gut. Ja was nun??? FPGA geht oder FPGA geht nicht - In einem FPGA kann man auch locker eine 4kx18 FIFO aus den internen Speicherblöcken realisieren. auch einen SPI mulitplexer . Was für ein FPGA steckt den in deinem Blockbild?
@ Joachim Heck (joooooooooogi) >Vom Prinzip habt ihr recht - auch ich würde den bzw. die ADCs lieber >direkt am FPGA anschließen... Dann tu es! > das ist in dem Fall leider nicht möglich, >da die ADCs zusammen mit weiteren DACs und ein paar MCUs an einem >gemeinsamen SPI Bussystem hängen. Das ist auf deinem Blockschaltbild ab nicht dargestellt! >Das heißt z.B. 5-6 ADCs, 2-3 DACs und 2 MCUs teilen sich ein Bussystem. Ja und? Das wird auch mit dem FPGA nicht schlechter. Wozu eigentlich 2 MCUs? Klingt nach einem schlechten Konzept, das wie eine Kleckerburg gewachsen ist. >Da die ADCs und DACs nicht immer im richtigen Moment (EOC falling edge) >abgefragt werden können, müssen die Ergebnisse irgendwo gepuffert werden >um sie dann mit einem schnellern Takt (> 100 MBit/s) im Paket >abzufragen. Auch das alles macht ein KLEINES FPGA spielend, wenn man es schon nicht in das große FPGA integrieren kann oder will. Spartan3 & Co. >Das ist der Gedanke dahinter... Der möglicherweise das Ergebnis eines Tunnelblicks ist. >Nachdem ich noch einmal ein wenig bei den FPGAs geschaut habe, gefällt >mir die Variante mit einem 8€ Spartan-3 oder 20€ Spartan-6 doch sehr >gut. Eben. Und ich vermute immer noch, dass die vollständige Integration in das große FPGA sowohl möglich als auch vorteilhaft ist.
Hallo Falk und Bitwurstler, danke auch für eure Beiträge. Bitte nicht vorschnell schießen, wenn das Konzept - das hier übrigens nicht zur Diskussion steht (weshalb es auch nicht im Blockbild aufgeführt wurde) - nicht korrekt verstanden wurde. Da das System einen modularen Aufbau hat (Plug-and-Play), in dem je nach gewählten Modulen der Funktionsumfang des Gesamtsystems bestimmt wird, bin ich nicht der Meinung, dass es hier ein Tunnelblick war, der zum entsprechenden Design geführt hat. Ich habe zudem von einem zentralen FPGA (Zynq 7 = groß und teuer) gesprochen der bisher die in den Einzelmodulen gepufferten Daten batchweise ausgelesen hat. Die Timings zur Lese-Synchronisierung von den aufgeführten Einzel-Komponenten (ADC, DACs, MCU), die übrigens derzeit über einen einzelnen 4-Draht-Bus abgefragt und beschrieben werden können,... sind ohne Pufferung nicht zu realisieren. Sonst würden einzelne Datenpakete möglicherweise verloren gehen. (Hier muss jeweils das End-Of-Conversion abgewartet und dann bis zum nächsten EOC ausgelesen werden) Die weiteren, verteilten FPGAs (Spartan 3 = klein und billig), als Konterpart zu DSP/MCU/DSC war bei Threaderstellung noch nicht angedacht. Widerspricht sich aber an keiner Stelle des Thread. => Die zusätzlichen, verteilten Spartan-3 scheinen mir hier wirklich eine solide Lösung darzustellen.
Joachim H. schrieb: > => Die zusätzlichen, verteilten Spartan-3 scheinen mir hier wirklich > eine solide Lösung darzustellen. Also ist die Threadfrage "Was soll ich nur wählen: DSC/DSP/MCU?" jetzt mit "keines der drei, sondern ein weitere FPGA" beantwortet? Und dieser neue FPGA wird direkt mit den AD-wandler und dem (alten) FPGA gesetzt und ersetzt alles zwischen ADC und altem FPGA? Wobei ein ZYNQ (der jetzt als "alter" FPGA enthüllt würde) kein FPGA sondern ein SoC ist also FPGA und CPU und peripherals ist. Also quasi umsonst den SPI-master aus dem rechten Bild mitbringt?
Ja, die Frage dürfte so als beantwortet zählen! Keines der drei, sondern zusätzliche FPGAs als ersatz für die bestehenden Logikelemente dient. Ja, prinzipiell stehen diese dann irgendwo zusätzlich zwischen dem ADC/DAC/MCUs und dem zentralen FPGA/SOC. Der SPI Master wird dann von den zusätzlichen FPGAs zur Kommunikation mit den ADC/DAC geliefert (vermutlich ein VHDL SPI Master). Zwischen den neuen, zusätzlichen Modul-FPGAs und zentralem SOC läuft dann eine SPI-Abwandlung mit Adressierungsinformationen zur Ansteuerung der einzelnen Module. Besten Dank, der Thread kann von meiner Seite aus geschlossen werden.
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.