AM335x FPGA-Speicherintegration

Ich entwerfe gerade ein digitales Mischpult. Wir haben eine ziemlich große Anzahl von ADCs und DACs (mehr als der serielle Mehrkanal-Audioanschluss am Prozessor verarbeiten kann). Wir haben entschieden, dass die Lösung hierfür darin besteht, ein FPGA als Schnittstelle zu den Datenkonvertern zu verwenden und den Prozessor über das RAM im FPGA auf die Daten zugreifen zu lassen. Wir haben uns noch nicht für ein FPGA entschieden.

Nach dem, was ich gelesen habe, können wir den FPGA-RAM als NOR-nicht gemultiplextes 16-Bit-Gerät über die GPMC konfigurieren. Ist das richtig? Und meine andere Frage ist, dass es wahrscheinlich zu langsam wäre, die Daten im RAM des FPGA zu halten. Wäre es also möglich, eine DMA-Übertragung vom FPGA-RAM zu einem anderen Speicher im Prozessor einzurichten, auf den einfacher und schneller zugegriffen werden kann? Oder müssten wir eine PRU verwenden, um die Daten zu kopieren?

GPMC, PRU? Wie hängt diese Frage mit TI zusammen? Wie hängen NOR und Non-Multiplexing mit dem RAM in einem FPGA zusammen? FPGAs haben interne SRAMs. Dieser RAM (BlockRAM, Embedded BlockRAM oder Distributed RAM) ist sehr schnell, zumindest schneller als ein ARM verarbeiten kann. Die Frage ist: Welche Schnittstelle werden Sie verwenden? Der limitierende Faktor ist Ihre ARM-FPGA-Schnittstelle und ihre Latenz.
Der TI AM335x-Prozessor verfügt über einen GPMC (Allzweck-Speichercontroller und 2 PRUs (programmierbare Echtzeiteinheiten). SRAM ist schneller, aber ich kann nicht schnell genug darauf zugreifen, glaube ich nicht, über die GPMC-Schnittstelle. Ich frage, wie ich eine Schnittstelle habe mit dem SRAM auf dem FPGA.
Sie könnten also eine Speicherschnittstelle im FPGA implementieren, sodass es wie ein normaler Speicherchip fungiert. Der Vorteil könnte darin bestehen, dass der SRAM des FPGAs im globalen Adressraum von ARMs sichtbar ist, was DMA ermöglicht. Haben Sie andere Schnittstellen: PCIe, parallele Busse, AMBA .... ? Welche Speicherschnittstellen werden von der GPMC unterstützt: (S)SRAM, DRAM, Flash, SD-Karte (QuadSPI) .. ?
Die GPMC unterstützt NOR, NAND und SRAM. Aber in dem von TI angebotenen Pin-Mux-Tool gibt es Optionen für NOR und NAND, gemultiplext und nicht gemultiplext, und ich habe irgendwo gelesen, dass SRAM-Schnittstellen wie NOR sind.
Ich kenne diesen ARM nicht, aber die übliche parallele NOR-Schnittstelle, die von CPUs bereitgestellt wird, ist mit parallelen SRAMs kompatibel. Was Sie wahrscheinlich verwenden möchten. Serielle NORs und serielle SRAMs kommen völlig außer Frage (es handelt sich normalerweise um SPI-Schnittstellen mit einem oder mehreren Datenbits), ebenso wie die NAND-Schnittstelle, und es ist sehr unwahrscheinlich, dass Sie mit Ihrem FPGA für den ARM einen DRAM emulieren möchten. Ob Sie eine Multiplex- oder eine Nicht-Multiplex-Schnittstelle verwenden: Das hängt von der Anzahl der verfügbaren Pins und der Geschwindigkeit ab, die Sie erreichen möchten.
Ja, ich plane eine parallele 16-Bit- oder 8-Bit-Schnittstelle zu verwenden. Danke für die Klarstellung!

Antworten (1)

Ich werde einige Annahmen treffen: Da es sich um das Mischen von Audio handelt, möchten Sie alle ADCs nacheinander mit einer festen Synchronrate (z. B. 96 kHz) lesen und alle DACs nacheinander mit derselben Rate schreiben. Ich denke, die PRU wird der einfachste Weg sein, eine schnelle Datenleitung zu/von einem FPGA zu implementieren.

Es gibt zwei PRU-Prozessoren in einem AM335x Sitara-Prozessor, und jeder hat 32 Eingangspins und 32 Ausgangspins. Da Sie wahrscheinlich einige Steuersignale benötigen und wahrscheinlich 24-Bit-Codecs verwenden, sollte das gut funktionieren. Sie könnten eine PRU dem Empfang von Daten und die andere dem Senden von Daten zuweisen. Ich schätze, dass Sie mit straffem C-Code mindestens 10 Samples pro Mikrosekunde in jede Richtung (30 Megabyte/Sekunde) und mehr mit Assemblersprache erhalten könnten.

Ich habe mehrere I2S-Audioschnittstellen in ein FPGA gesteckt, und es ist nicht so schwer. Wie Sie sagten, könnten die Codecs Daten zum/vom FPGA-SRAM verschieben, und nach jedem Codec-Zyklus (alle 10,417 Mikrosekunden bei 96 kHz) könnten die PRUs die Daten als zusammenhängenden Block lesen/schreiben. Ein einfacher Sequenzer im FPGA könnte auf Strobes von der PRU reagieren, um den Datenblock zu durchlaufen. In der Sitara kann ein Linux-Prozess einen Speicherblock zur gemeinsamen Nutzung mit der PRU zuweisen. Ich habe C-Strukturen und -Arrays in den gemeinsam genutzten ARM/PRU-Speicher eingefügt, damit der Linux-Prozess und die PRU Daten als C-Variablen gemeinsam nutzen können.

Hoffentlich hilft das.

Ja das ist sehr hilfreich. Und deine Annahmen waren richtig. Ich habe über dasselbe nachgedacht wie Sie gesagt haben, gehe jedoch von linksbündigen Daten aus, da einer meiner ADCs I2S nicht unterstützt. Aber die Komplexität ist die gleiche. Und ich wusste auch nicht, ob ich die DMA-Übertragung vom FPGA-SRAM verwenden könnte. Wenn ich kann, werde ich das verwenden, wenn nicht, kann ich die PRUs verwenden, wie Sie angegeben haben. So oder so bin ich damit einverstanden.
Ja, I2S und Left-Justified sind fast identisch - ich habe meiner FPGA-Codec-Schnittstelle erlaubt, beides zu verarbeiten, indem ich einfach zwei D-Flops und einen 2: 1-Mux hinzugefügt habe.
Ich bin nur neugierig, welches FPGA hast du verwendet? Ich bin mir nicht ganz sicher, wie leistungsfähig mein FPGA sein muss.
Ich habe DMA nie auf der Sitara verwendet, weil die PRUs Daten direkt im Speicher der Linux-Anwendung ablegen können, ähnlich wie DMA (aber unter der Kontrolle eines C-Programms). Das Programmieren von DMA erscheint mir entmutigend.
Ich denke fast alle FPGAs werden schnell genug sein, es kommt eher auf die richtige Größe an. Ich habe einen Actel 42MX16 (ein Anti-Fuse-basiertes Teil) für die Codec-Schnittstelle verwendet (es hat auch viele andere Dinge getan, wie das Erfassen von Motorgeschwindigkeiten und -positionen). Ich habe alles auf 18,432 MHz getaktet, und das Teil hat bei dieser Geschwindigkeit gebummelt. Heute würde ich etwas Flash-basiertes verwenden, wie ein A3P-Teil. Actel ist jetzt MicroSemi.
DMA sieht entmutigend aus ... aber wenn ich es herausfinden kann, könnte es mein Leben leichter machen. Aber wenn ich es nicht sofort bekomme, muss ich mich wahrscheinlich für die PRU-Idee entscheiden. Ich wollte die PRU verwenden, um Ethernet-Protokolle mit einem externen Modul zu handhaben, aber wenn es nötig ist, kann ich das auch immer dem ARM-Kern überlassen.
Ich erhalte eine gute Leistung vom Standard-Linux-Ethernet-Treiber, der im ARM ausgeführt wird. Ich streame Daten mit bis zu 1000 Paketen pro Sekunde (nur 56 Byte Nutzdaten über UDP) mit 100M Ethernet und es geht nie ein Takt aus. Die PRU kann jedoch für 1G-Ethernet erforderlich sein.
Ich bin mit dem 100-MHz-Ethernet in Ordnung. Aber ich bin mir ziemlich sicher, dass ich das DMA-Transfer-Zeug herausgefunden habe. Ich bekomme nur 1 DMA-Kanal. Aber das sollte ausreichen, weil ich die ADC-Daten übertragen kann, dann eine Verbindung zu einer anderen DMA-Übertragungsparameterstruktur habe und dann automatisch die DAC-Datenübertragung startet, ich wechsle einfach zwischen den 2 mit Verbindungen und ich sollte nicht viel Overhead haben . Und wenn doch, habe ich immer noch PRUs. Jetzt muss ich nur noch den FPGA-Audio-Codec schreiben und herausfinden, wie ich mit dem SRAM koppeln kann.
AM335x FPGA-Speicherintegration
AntwortenHierDatenschutz-Bestimmungen1y, 0v