Forum: FPGA, VHDL & Co. Anbindung FPGA an USB2.0/3.0


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Andreas M. (amesser)


Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich möchte über längere Zeiträume kontinuierlich 4 analoge Signale 
aufzeichnen um diese später am Computer analysieren zu können. 
Samplerate soll 1MS/s sein, wichtig ist, das die Signale gleichzeitig 
gesampelt werden, da die Phaseninformation benötigt wird. Ich plane im 
Moment dafür 4 separate 12 Bit ADC Wandler (SPI) zu nutzen. Es sieht 
nicht so aus, als ob es Mirkocontroller gibt, die genügend SPI Hardware 
und vorallendingen schnelles USB haben um das kontinuierlich zu 
bewerkstelligen. Theoretisch könnte man die Daten auch auf eine SD Karte 
wegspeichern, aber bei dann müsste man die Daten vorher reduzieren (so 
eine Art Trigger auf Signalpegel), da ich etwa 1 Stunde lang aufzeichnen 
möchte. Ich glaube nicht das die Performance in einem Mikrocontroller 
dafür reicht. Die SD Karte muss eventuell auch noch mehrere 100 ms 
gepuffert werden (wear-leveling). Bisher habe ich noch keine Erfahrungen 
mit FPGAs gemacht, aber das scheint mir der bessere Ansatz dafür zu 
sein.
Ich habe mal ein bischen mit Quartus gespielt und etwas für den MAX10 
von Altera hingebasteltet. Nun geht es noch um die konkrete USB 
Anbindung. Ich hatte eigentlich geplant einen FX2 von Cypress zu nehmen, 
da könnte ich dann weite USB Endpoints mit mit dem 8051 bedienen um z.B. 
Einstellungen zu übertragen. Allerdings habe ich gelesen das USB2 
größere FIFOs benötigt um verlässlich zu funktionieren. Datenrate wären 
so etwa 8MB/s (inklusive Zeitstempel)
Platinenlayout mache ich selber, habe aber bisher nur ein- und 
zweilagige Designs gemacht. Folgende Möglichkeiten habe ich jetzt:

Cypress FX2 + Altera 10M08:
+ Vermutlich Zweilagige Platine ausreichend
+ FX2 Firmware simpel
+ FPGA Code per USB über FX2 laden
+ Günstig
- Intern max etwa 300kb FIFO. Bandbreite wird eventuell nicht erreicht,
  Daten gehen verloren
? Eventuell SD-RAM dran pappen. Das ist aber in VHDL für mich als
Anfänger vermutlich nicht so einfach. Oder doch?

Cypress FX3 + Altera 10M08:
+ USB3 hat wohl das Problem mit dem Streaming nicht so sehr, FIFOs
  werden nicht gebraucht
+ FPGA Code per USB über FX3 Laden
- FX3 Firmware aufwändig (Allerdings kenne ich mich mit ARM926
  von Berufs wegen gut aus)
- FX3 ist sehr teuer (~30 EUR)
? USB3 mit zweilagiger Platine

FTDI FT600Q + Altera 10M08:
+ USB3
+ FT600Q sogar günstiger als FX2
- Programmieradapter für FPGA notwendig (JTAG?)
- FT600Q FIFO Interface ist komplizierter zu bedienen
  als das des Cypress FX.
- Steuerfunktionen müssen mit im FPGA erledigt werden
  (Bedienung zusätzlicher Endpoints)
? USB3 mit zweilagiger Platine

Was meint Ihr ist der bessere Ansatz? Achso, der aktuelle VHDL code ist 
recht simpel: 4 Schieberegister, 8kB FIFO, kleine Statemachine.

Vielen Dank für Anregungen!

Gruß
Andreas

von pcrom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke der Cypress PSOC5LP kann das alles mit on-board peripherals.
Auf jeden fall 2x schneller ADC und er hat auch Sample/Hold 
moeglichkeiten. Der sollst du unbedingt mal bestudieren.

Patrick

von Duke Scarring (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> kontinuierlich 4 analoge Signale
> aufzeichnen um diese später am Computer analysieren zu können.
> Samplerate soll 1MS/s sein
Wieviel Geld und wieviel Zeit darf denn das Ganze kosten?

Duke

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

gibt es keinen passenden STM32* dafür?


> Ich habe mal ein bischen mit Quartus gespielt und etwas für den MAX10
> von Altera hingebasteltet. Nun geht es noch um die konkrete USB
> Anbindung. Ich hatte eigentlich geplant einen FX2 von Cypress zu nehmen,
> da könnte ich dann weite USB Endpoints mit mit dem 8051 bedienen um z.B.
> Einstellungen zu übertragen. Allerdings habe ich gelesen das USB2
> größere FIFOs benötigt um verlässlich zu funktionieren. Datenrate wären
> so etwa 8MB/s (inklusive Zeitstempel)

Das schafft der FX2 gut, die Frage ist, welchen Mode du nimmst, und wie 
die Auswirkungen sein dürfen, wenn der Host grade mal stockt:

bulk: FIFO Overflow (du wirfst die Daten selber aufm FPGA weg)
isochron: Daten verloren, aber Strom geht beim nächsten Paket weiter

Bei isochron kommst du dann ohne FIFO-Logik aus. Ich nutze das für 
Bilddatentransfer bei ca. 24 MB/s, das geht, solange nix anderes den 
USB-Bus stört (wilde Mausbewegungen unter Windows stören schon).
Der Vorteil vom FX2 ist halt, dass es eine Menge Code gibt (siehe 
Gnu-Radio) und er ein gnädiges Timing hat, im Vergleich zu anderen 
FIFO-Bausteinen. Beim FX3 bin ich nicht up to date.

SDRAM ist nochmal etwas mühsam vom Timing her, aber mit nem fertigen 
Core machbar. Vielleicht passt ja auch ein SRAM.

Und beim Platinendesign kannst du gleich 4 Lagen nehmen, die Anzahl 
würde ich da weniger als Kriterium nehmen als die elektrische Stabilität 
und den Krampf, das noch sauber zu routen. Spätestens bei RAM kommst du 
da eh nicht drum herum.

Sonst: Viel Erfolg,

- Strubi

von Andreas M. (amesser)


Bewertung
0 lesenswert
nicht lesenswert
pcrom schrieb:
> Ich denke der Cypress PSOC5LP kann das alles mit on-board peripherals.
> Auf jeden fall 2x schneller ADC und er hat auch Sample/Hold
> moeglichkeiten. Der sollst du unbedingt mal bestudieren.

USB ist zu langsam und genug RAM um MMC/SD Wear-Leveling abzufedern hat 
er auch nicht

Strubi schrieb:
> gibt es keinen passenden STM32* dafür?

Naja ich brauche halt 4x SPI zum Lesen und USB2.0 zum wegschreiben. Da 
habe ich keinen gefunden der das bringt. Eventuell kann man noch I2S im 
TDM Mode dazu missbrauchen.

> Das schafft der FX2 gut, die Frage ist, welchen Mode du nimmst, und wie
> die Auswirkungen sein dürfen, wenn der Host grade mal stockt:

Das ist genau der Punkt. Ich würde Bulk nehmen und versuche so viel wie 
möglich von der FPGA Seite her zu puffern. Host wird ein Linux sein, 
wenn ich richtig gelesen habe ist es da nicht ganz so kritisch. Ich 
denke ich werde mir das mit dem SDRAM mal ansehen. Gibt ja schon ein 
paar fertige IP cores.

von Programmierer (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der SUMP auf GITHUB macht doch sowas fertig und passend. Muss man nur 
entsprechend triggern.

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
Du könntest einen Beaglebone Black nehmen.

Der hat nur 2 Hardware SPI-Ports, dafür aber die PRUs. Damit kannst Du 
locker die 4 SPIs in Software abwickeln und über das Shared Memory an 
die Haupt-CPU übergeben.

Dort kannst Du bei Bedarf gemütlich vorverarbeiten, auf SD Card 
speichern, oder sicher noch bequemer: übers Netzwerk gleich auf Deinem 
Fileserver ablegen.

von Zoom Zoom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
STM32 haben USB 2.0, Du musst halt nur den HS Phy dranbauen (was aber 
einfacher ist als ne Platine mit FPGA + FX2).
Die gibts natürlich auch mit 4 SPI Ports (sogar mit 6 + Quad SPI).
Musst aber halt schauen, dass von der Pinbelegung her genug frei sind.

von Andi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der PIC32MZ den ich kürzlich angeschaut habe hat z.B. 6 SPI Peripherals 
aber auch einen schnellen ADC mit bis zu 6 separaten Sample&Holds, so 
dass du wahrscheinlich gar keine externen ADCs brauchst.
Natürlich auch USB (Highspeed, OTG).
Ausserdem 512kB Ram fürs Zwischenspeichern, und 1 oder 2 MB Flash.
Erhältlich in TQFP64 oder TQFP100.
MIPS Prozessor mit bis zu 252 MHz.
Damit hast du alles in einem Chip anstatt FPGA + RAM + ADCs + USB Phy 
usw. zu einem Bruchteil des Preises eines mittleren FPGAs.

von Strubi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Du könntest einen Beaglebone Black nehmen.
>
> Der hat nur 2 Hardware SPI-Ports, dafür aber die PRUs. Damit kannst Du
> locker die 4 SPIs in Software abwickeln und über das Shared Memory an
> die Haupt-CPU übergeben.
>
> Dort kannst Du bei Bedarf gemütlich vorverarbeiten, auf SD Card
> speichern, oder sicher noch bequemer: übers Netzwerk gleich auf Deinem
> Fileserver ablegen.

In der Theorie hört sich das ja schön an, aber klappt das wirklich, hast 
Du das schon implementiert?
Da gibts doch schon noch eine lange TODO:
- Kerneltreiber machen
- (unabhängiger!) DMA-Support für alle 4 Kanäle
- Abrissfreie Datenverarbeitung verifizieren
- ..und offenbar noch einen sauberen Timestamp, wegen der Anforderungen 
bzgl. Phasenlage

Für letzteres alleine ist IMO schon ein FPGA nötig, wenn man nicht 
beliebigen jitter bzw. Aufwand mit RT-Extensions haben will. Schliesst 
allerdings das embedded Linux front end ja nicht aus.

Auf den OMAP/Sitaras und insbesondere den Beagles habe ich keine gute 
Erfahrungen mit Echtzeit-Datenacquisition gemacht, aber das lag v.a. am 
DMA und an der USB/Ethernet-Architektur. Wenn die Daten allerdings nicht 
roh rausmüssen und man deinem Vorschlag der Verarbeitung folgt, könnte 
es gehen.

Grüsse,

- Strubi

von Andreas M. (amesser)


Bewertung
0 lesenswert
nicht lesenswert
Gerd E. schrieb:
> Du könntest einen Beaglebone Black nehmen.
>
> Der hat nur 2 Hardware SPI-Ports, dafür aber die PRUs. Damit kannst Du
> locker die 4 SPIs in Software abwickeln und über das Shared Memory an
> die Haupt-CPU übergeben.

An sowas hatte ich noch gar nicht gedacht. Aber das "locker" glaube ich 
nicht ganz. Soweit ich das sehe gibt es in der PRU zwei Schieberegister, 
bleiben noch 2 SPI in Software übrig. Man müsste sehen das man das 
Timing der Schieberegister mit den Software SPIs synchronisiert bekommt? 
Bei den ADC die ich verwenden möchte muss das SPI dann mit 14 MHz 
laufen, da bleiben der PRU dann 14 Takte pro SPI Takt:

- 1 Takt alle 4 MISO Leitungen samplen
- 4 Takte schieben
- 1+1 Takt um SCLK zu zählen und auf pin legen
- 2 Takte CS Signal für ADCs generieren
- 1+4 Takte nach 14 SCLK Takten um die Schieberegister in andere
  Register zu sichern damit die zweite PRU die dann irgendwie in den
  Speicher legt und/oder per DMA fortschafft.

Eventuell kann man das ganze auch linear 14x runterprogrammieren um die 
Aufgaben zwischen den SPI Takten etwas zu verteilen.

Dann könnte die ARM das noch nachverwursten und auf eine SD-Karte 
speichern. USB würde ich dann nicht nehmen wollen. Was ich vergessen 
habe zu sagen, ist das die Lösung portabel sein muss. (Akkubetrieb, USB) 
Daher fällt "Schieben auf Dateiserver" aus. Und Stromversorgung über USB 
fällt beim BeagleBone auch flach wenns halbwegs stabil laufen soll.

Es gibt schon ein Cape mit 20 MS/s 2 Kanal ADC, allerdings mit 
paralleler Anschaltung der ADCs. Entspräche dann ~ 1.5MS/s mit SPI 
Bus/2Ch oder etwa 0.8 MS/s/4Ch bei SPI aus Sicht der PRU. Laut deren 
Doku ist die Sache dort wohl auch sehr knapp.

Also "locker" ist dann doch was anderes.

Zu den anderen Vorschlägen sage ich jetzt mal nichts. Es mag ja sein, 
das es STMs und PICs mit USB2.0 und genug SPI oder internen Wandlern 
gibt, das löst aber nicht das Problem des notwendigen FIFO Speichers um 
PC seitige USB2.0 "Stocker" oder auch SD/MMC abzupuffern. Wie sprechen 
hier von etwa 4MByte Ram.

Außerdem würde ich gerne mal was mit einem FPGA machen. Das Thema 
interessiert mich schon länger :-)

von Zoom Zoom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Andreas M. schrieb:
> Wie sprechen
> hier von etwa 4MByte Ram.

STM32er haben ein fertiges Speicherinterface für SRAM / SDRAM ;-P

von Ben (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kreative Lösung für viele SPI interfaces...

http://m.youtube.com/watch?v=XlKilhcP_ic

Sollte auch von der Datenrate noch zu machen sein

von Lars R. (lrs)


Bewertung
0 lesenswert
nicht lesenswert
Zoom Zoom schrieb:
> Andreas M. schrieb:
>> Wie sprechen
>> hier von etwa 4MByte Ram.
>
> STM32er haben ein fertiges Speicherinterface für SRAM / SDRAM ;-P

Kann ein STM32 gleichzeitig 4x SPI taktsynchron kontinuierlich lesend 
und schreibend bedienen und auf dem PC als virtuellen COM mit 40MByte/s 
zur Verfügung stellen? Dazu ein wenig Protokoll-Overhead zur Emulation 
von CTS/RTS? Inkl. Buffer auf SDRAM für das Senden an den PC.

: Bearbeitet durch User
von Zoom Zoom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Der TO braucht nur 8 MByte/s wie er selbst schon sagt. Das ist eine ganz 
andere Hausnummer.

von hm (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die Atmel SAM3U (Cortex-M3 statt nervigem 8051 im FX2) haben einen 
integrierten hi-speed USB transceiver (ist meine ich einer der wenigen 
Cortex-Ms mit integriertem Phy - die meisten brauchen einen externen 
ULPI), dazu 4x USARTs die sich als SPI nutzen lassen (maximal 16MHz SCK 
allerdings) + normales SPI. Externes RAM lässt sich auch z.B. in Form 
von (P)SRAM (z.B. IS66WVE4M16) anbinden.
(e)MMC mit 4 oder 8 Bit und S/MLC NAND Flash kann er auch ansteuern.

Knackpunkt ist da vielleicht die 16MHz auf den USARTs - bei 1MS/s mit 12 
Bit könnte das aber gerade so reichen.

von Lars R. (lrs)


Bewertung
0 lesenswert
nicht lesenswert
Zoom Zoom schrieb:
> Der TO braucht nur 8 MByte/s wie er selbst schon sagt. Das ist eine ganz
> andere Hausnummer.

Meine Frage war nicht als Kritik gemeint.

Was ist machbar für ein komfortables Interface FPGA<>PC auf Basis eines 
STM32-discovery/nucleo?

von Zoom Zoom (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Gute Frage, ich habe das für nen STM32 noch nie ausgereizt mangels 
Anwendung dafür.

Würde aber stark vermuten, dass man dann doch besser auf einen FTDI oder 
Cypress USB FIFO Chip setzen sollte wenn man das Maximum aus der USB 
Leitung rausholen möchte.

von Lars R. (lrs)


Bewertung
0 lesenswert
nicht lesenswert
Zoom Zoom schrieb:
> Würde aber stark vermuten, dass man dann doch besser auf einen FTDI oder
> Cypress USB FIFO Chip setzen sollte wenn man das Maximum aus der USB
> Leitung rausholen möchte.

Und welche Out-of-the-box-Lösung genau? Das USB-Problem mit dem 
Zwischenspeichern bleibt ja. Ein Problem, dass mit der jeweiligen 
FPGA-Applikation nichts zu tun hat. Ein Problem, dass immer wieder neu 
gelöst wird, nur von verschiedenen Personen und manchmal auch von den 
Selben. Eigentlich will man (ich) doch nur (paralleles, synchrones) UART 
am FPGA und virtuellen COM am PC.

USB3 hat nun getrennte Leitungen für Empfangen und Senden. Ob das die 
Sache mittelfristig vereinfacht?

> Gute Frage, ich habe das für nen STM32 noch nie ausgereizt mangels
> Anwendung dafür.

Tja...

von Ralph (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Lars R. schrieb:
> Zoom Zoom schrieb:
>> Würde aber stark vermuten, dass man dann doch besser auf einen FTDI oder
>> Cypress USB FIFO Chip setzen sollte wenn man das Maximum aus der USB
>> Leitung rausholen möchte.
>
> Und welche Out-of-the-box-Lösung genau? Das USB-Problem mit dem
> Zwischenspeichern bleibt ja. Ein Problem, dass mit der jeweiligen
> FPGA-Applikation nichts zu tun hat. Ein Problem, dass immer wieder neu
> gelöst wird, nur von verschiedenen Personen und manchmal auch von den
> Selben. Eigentlich will man (ich) doch nur (paralleles, synchrones) UART
> am FPGA und virtuellen COM am PC.

FTDI FT2232H im 245 FIFO Mode. Schafft so an die 40MB/s, virtueller COM 
bin ich mir nicht mehr sicher, ich glaube man braucht einen Treiber (der 
leicht selbst zu schreiben ist).

Für 8MB/s braucht man schon was besseres, das einfachste dafür ist der 
FTDI. Alternativ kannst du auch 100MBit Ethernet probieren, das kriegt 
die 8MB/s eigentlich auch gut hin...

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]
  • [vhdl]VHDL-Code[/vhdl]
  • [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.