www.mikrocontroller.net

Forum: FPGA, VHDL & Co. Datenübertragung: USB Controller Chip <-> FPGA


Autor: Marcel C. (arcticus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits

Habe eine Frage bezüglich USB Device Controller Chips. Ich würde gerne 
einen FPGA über USB ansprechen, also im Grunde Daten hin- und 
herübertragen. An JTAG über USB bin ich proformer erstmal nicht 
interessiert.

Ich habe bisher nur diesen FTDI 2232x gefunden, den man verschiedenes 
konfigurieren kann und diesen oft erwähnten Chip: Cypress FX2...

Beide im Detail doch komplex und vorallem der FTDI-Chip doch sehr 
dürftig dokumentiert... und beide benötigen spezielle Windows-Treiber..

Daher meine beiden Fragen:

1. Ich würde gerne wissen ob es einen simplen Chip gibt mit dem man die 
volle High-Speed USB Übertragungsrate erreichen kann (zb. als paralleler 
Anschluß an den FPGA oder gibt es da sogar ne bessere Art ihn 
anzuschließen ?)?

2. Gibt es auch einen Chip der ohne große Treiberinstallation über den 
USB Host erkannt werden kann (zb. wie bei USB Mass Storage Devices) oder 
ist bei einer solchen Verwendung eines USB-Geräts eine 
Treiberinstallation unabingbar?

Danke schonmal für die Hilfe

lg arcticus

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1. Also die beiden Kandidaten hast du schon genannt. FT2232*H* und 
Cypress FX2. Beide können USb 2.0 HighSpeed und sind relativ leicht 
beschaffbar und konfigurierbar. Der FTDI hat den Vorteil, dass du keine 
Firmware für den Controller schreiben musst. Der schafft allerdings nur 
etwa so 25MB/s laut Datenblatt. Der Cypress ist ein 8051 µC mit USB 
Hardware dran. Da muss man eine Firmware laden und dann macht der fast 
alles alleine. Die Firmware sind im Prinzip nur Register-Einstellungen. 
Ist etwas komplexer, aber damit erreicht man echte 40MB/s. Mehr geht 
nicht mit HighSpeed.

2. Das wird schwierig. Du kannst den FX2 als MSD programmieren, da gibts 
auch eine Beispiel-Firmware von Cypress, dann verlangt der keinen 
Treiber. Ist dann allerdings ein ATA-Controller mit ATA Interface. Da 
musst du im FPGA einen ATA Slave implementieren und den aus Windows 
heraus als BlockDevice oder ganz unten über die IO Controls des Treibers 
ansprechen. Dazu brauchst du allerdings Admin-Rechte. Ob das so sinnvoll 
ist? Für den Cypress hast du nur eine einzige Treiber-Datei, gibts auch 
als x64 mittlerweile. Wir setzen den erfolgreich ein, privat hab ich 
auch damit gebastelt. Eine Beispiel-Firmware von mir findest du im Forum 
hier.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ob ein hostseitiger USB-Gerätetreiber geschrieben/bereitgestellt werden 
muss, hängt vor allem von der zu unterstützenden Geräteklasse ab. Für 
HID (Human Input Device wie Maus, Tastatur, Joystick), Mass Storage und 
einige Varianten von CDC (Communication Device Class) kann man die 
Standardtreiber des Betriebssystems verwenden. Jedoch ist bei älteren 
Windows-Versionen die Host-Implementierung des CDC ACM so schlecht, dass 
die meisten Hersteller von USB-/Seriell-Wandlern lieber auf eigene 
Implementierungen eines USB-basierten Protokolls setzen (FTDI, Prolific, 
Moschip, usw.).

Wenn man ein FPGA verwendet, bietet sich - je nach Anwendung - die 
Verwendung eines internen USB-Blocks an, je nach FPGA mit oder ohne 
externen reinen USB PHY. Jedoch benötigt man im Allgemeinen noch einen 
Prozessorkern für das "High Level"-Protokoll, z.B. einen Picoblaze oder 
8051-/Z80-Softcore.

Auf Opencores befindet sich ein aktiv gepflegter USB-Block für Host und
Function, jedoch nur für USB 1.1:

http://opencores.org/project,usbhostslave

Mit einem USB-/Seriell-Wandler wird man nicht ansatzweise auf eine für 
Nutzdatenrate von >10MBit/s kommen.

Geht es bei dem Projekt um eine private Bastelei oder ein kommerzielle 
Produktentwicklung?

Gruß
Andreas Schweigstill

Autor: Marcel C. (arcticus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ne es geht um meine Diplomarbeit ;)

Grob geht es um eine externe FPGA Lösung, die man auch mal irgendwo hin 
mitnehmen kann, um "Kunden" etwas zu demonstrieren, wozu zb. ein PCIe 
Interface net so gut kommt -> ala "Machen se doch mal den Rechner auf" 
...

daher wäre natürlich eine Lösung vorteilhaft, in der nicht zuviel an 
Zusatztreibern installiert wird...

---------
Beispiel-Firmware von Cypress, dann verlangt der keinen
Treiber. Ist dann allerdings ein ATA-Controller mit ATA Interface. Da
musst du im FPGA einen ATA Slave implementieren und den aus Windows
heraus als BlockDevice oder ganz unten über die IO Controls des Treibers
ansprechen. Dazu brauchst du allerdings Admin-Rechte.
---------

Also nehm ich mal an eine Lösung ohne Treiberinstallation zielt primär 
nur auf MSD ab (ich nehme mal an als HID wird das erst recht nicht 
klappen) mit den oben genannten Einschränkungen...

Ganz allgemein stehen im Raum halt:

1) USB 2.0; 40 MB/s max. Performance mit den oben genannten Chips

2) Gigabit-Ethernet; 80 MB/s ungefähr mit TCP, kann auch mit einem Chip 
vor dem PFGA implementiert werden...ist eher Cluster-fähig

Das steht so ungefähr zur Debatte und die Frage bleibt, was wäre für den 
obigen Kundenbesuch quasi eher von Vorteil... ich glaube Ethernet könnte 
da Treiberseitig besser sein ;)

lg arcticus

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine GbE Implementierung in Hardware incl. Protokollstack auf einem 
MicroBlaze oder PowerPC da im FPGA ist in einer Diplomarbeit nicht zu 
schaffen. Das ist ein enormer Aufwand und für "mal schnell beim Kunden 
zeigen" überhaupt nicht geeignet. Der muss dann erst sein Firmennetz 
abklemmen, IP eventuell umstellen, ein Cross-Kabel anschließen. Das ist 
viel mehr Aufwand als einen Treiber zu installieren.
HID und CDC ist schnarchlangsam, das bringt dich nicht weiter. MSD ist 
wieder nicht dafür gedacht.
Da es eine Diplomarbeit ist, würde ich den FT2232H empfehlen. Alleine 
aus Zeitgründen.

Autor: Marcel C. (arcticus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin nicht allein und würde das GbE auch nicht selbst im FPGA 
implementieren wollen sondern eher nen Chip davorsetzen mit Phy und MAC, 
der nurnoch die Daten weiterleitet, aber das andere Argument ist auch 
gut...

Also würdest du sagen man könnte eher nen Treiber installieren als nen 
Gerät per Ethernet anschließen ?

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Christian R. schrieb:
> Eine GbE Implementierung in Hardware incl. Protokollstack auf einem
> MicroBlaze oder PowerPC da im FPGA ist in einer Diplomarbeit nicht zu
> schaffen. Das ist ein enormer Aufwand und für "mal schnell beim Kunden
> zeigen" überhaupt nicht geeignet.

Exakt. Eine gewisse Restchance bestünde noch, wenn man auf eine fertige 
Referenzimplementierung zugreifen kann. Vermutlich wird dann aber das 
FPGA schon so voll sein, dass kaum noch Platz für das eigene IP frei 
ist.

> Der muss dann erst sein Firmennetz
> abklemmen, IP eventuell umstellen, ein Cross-Kabel anschließen. Das ist
> viel mehr Aufwand als einen Treiber zu installieren.

Vor allem wird es so mancher Kunde (oder die Sicherheitsrichtlinien des 
Unternehmens) nicht mögen, dass Dritte einfach so Netzwerkkomponenten 
mitbringen und in ihrem Netz anklemmen wollen. Man kann ja nicht ohne 
weiteres erkennen, ob es sich dabei nicht um einen "Hardware-Trojaner" 
handelt, dessen eigentlicher Zweck darin besteht, einen Netzwerkscan 
durchzuführen und ggf. Daten abzusaugen. Bei einem mitgebrachten 
Gerätetreiber oder Anwendungsprogramm besteht diese Gefahr natürlich 
auch, genauer: sie ist noch deutlich höher.

> HID und CDC ist schnarchlangsam, das bringt dich nicht weiter. MSD ist
> wieder nicht dafür gedacht.

Oh, auf MSD-Basis kann man sehr schöne Dinge machen, z.B. das 
Installationsmedium für Treiber und Anwendung mitbringen, so wie es 
heutzutage viele UMTS-Schniepel machen. Ich habe auch schon Anwendungen 
gesehen, bei denen die Nutzdaten einer Erfassungseinrichtung als 
virtuelle Speicherblöcke eines MSD abgelegt wurden. Bei SAN-Komponenten 
(Storage Area Network) ist es häufig auch so, dass die Steuer- und 
Konfigurationsdaten nicht über einen zeichenbasierten Kanal oder 
entsprechende SCSI-/Fiberchannel-Befehle übertragen werden, sondern über 
ein kleines blockbasiertes Speichergerät. Kommandos werden dadurch 
abgesetzt, dass sie in bestimmte "Sektoren" dieses Geräts geschrieben 
werden. Hierbei werden keine Dateien angelegt!

http://www.tek-tips.com/viewthread.cfm?qid=756438&...

Einen dateibasierten Ansatz kann man aber auch gelegentlich finden, d.h. 
auf der Host und das Gerät greifen gemeinsam z.B. auf ein 
FAT-Dateisystem zu, das sich in einer Ramdisk des Geräts befindet. Für 
Kommandos oder schnelle Datentransfers ist dies aber nicht geeignet, 
sondern eher für die Übertragung von Konfigurationsdateien.

Im Linux-Kernel befindet sich hierfür die sog. "USB Gadget"- 
Unterstützung, bei der man ein virtuelles MSD (neben CDC (ACM, 
"Ethernet"), Remote NDIS, usw.) realisieren kann.

Apropos RNDIS: Dies wäre natürlich auch noch eine Möglichkeit. Es 
handelt sich dabei um ein Paar virtueller Netzwerkkarten, von denen eine 
auf dem PC sichtbar wird. Darauf aufsetzend kann man dann TCP/IP 
benutzen. Der Entwicklungsaufwand ist aber nur dann erträglich, wenn man 
schon auf einem geräteseitigen Linux-System aufsetzen kann.

> Da es eine Diplomarbeit ist, würde ich den FT2232H empfehlen. Alleine
> aus Zeitgründen.

Ich kenne den Baustein zwar noch nicht, aber das dürfte vermutlich der 
Weg mit dem erträglichsten Entwicklungsrisiko sein.

Gruß
Andreas Schweigstill

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Marcel C. schrieb:
> Ich bin nicht allein und würde das GbE auch nicht selbst im FPGA
> implementieren wollen sondern eher nen Chip davorsetzen mit Phy und MAC,
> der nurnoch die Daten weiterleitet,

Und wer konfiguriert den Ethernet-Chip und stellt das 
Übertragungsprotokoll bereit? Für eine kleine FSM im FPGA dürfte das 
etwas zu heftig werden, so dass es dann schon auf einen Softcore 
hinausliefe. Und wenn man einen solchen verwenden will, bietet es sich 
eher an, das Ethenet-MAC gleich mit ins FPGA zu packen statt eine PCI- 
oder PCIe-Schnittstelle zum externen Ethernet-Baustein vorzusehen.

Gruß
Andreas Schweigstill

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, über MSD kann man sowas abfackeln. Aber wenn man kein virtuelles 
Datei-System benutzt, muss man zwingend Admin sein, um Blockweise 
zugreifen zu können. Die Idee wollten wir auch schon mal umsetzen, aber 
haben es dann zugunsten des Cypress FX2 fallen lassen.

Nochmal zu GbE: Schlag dir das aus dem Kopf. An sich eine feine Sache, 
aber der Aufwand für eine gesicherte, zuverlässige Datenübertragung 
(incl. aller nötigen Protokolle) ist einfach für den 
bearbeitungszeitraum zu hoch. Wir haben das mal angefangen, mit dem 
ML405 Board, auch als Diplomarbeit. Zum Glück hatte der Diplomand schon 
10 Jahre Programmier-Erfahrung, da hat er zumindest am Ende der DA eine 
halbwegs stabile Datenübertragung aus dem SDRAM zum PC hinbekommen. 
Allerdings nut UDP, feste IP usw.
Der mitgelieferte LW IP-Stack ist ein guter Einstiegspunkt, allerdings 
nicht performant genug. Die Einarbeitung in die MAC-Funktionalität, den 
PowerPC, den DMA Controller usw. ist einfach zu lang für eine DA. 
Außerdem war selbst der Virtex 4 FX20 dann fast voll mit MAC, PPC, DMA 
und ordentlichen Puffern für den MAC, damit die Datenübertragung auch 
schnell geht. Vom Preis mal ganz zu schweigen.

Ich rate dir dringend zum FTDI oder Cypress, damit kommst du am 
schnellsten zum Ziel. Kannst ja den Cypress nehmen, zunächst mit der 
normalen Firmware, die den cyUSB Treiber benutzt, und wenn noch zeit 
ist, oder nach der DA das auf die MSD Variante umbauen.

Autor: Marcel C. (arcticus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kenn mich mit Netzwerk nicht so genau aus, mein DA Partner aber 
schon... aber da die Diplomarbeit nicht nur daraus besteht diesen Chip 
zu implementieren würde ich schon die simpelste Alternative wählen 
wollen ;)

Aber noch kurz zu Ethernet:

Also die Idee ist eine externe Lösung, d.h. quasi ein Board mit RJ45 -> 
GbE-Chip -> FPGA, also nicht über PCI oder Ähnliches, und es gibt keinen 
Chip der das TCP Protokoll unterstützt, die Daten 
auseinanderschnürt/zusammenschnürt und einfach zum FPGA und zum am 
Ethernet-Kabel angeschlossenen PC schickt, ohne groß im FPGA 
rumzuprogrammieren ?

Z.B. (mal ganz weg von dem Kundengedanken) um mehrere FPGA-Karten über 
Netzwerk zu clustern...

---

Zum USB-Chip:

1. Wie schaut denn bei den bei den Chips (FTDI, Cypress) die Verbindung 
zwischen Chip und FPGA aus um eine max. Bandbreite zu erzielen, einfach 
parallele Leitungen?... im FTDI-Guide steht was von "FT245-style syncr. 
FIFO interface", was soll das bitte sein ?

2. Wie schauts mit vorgefertigten Programmierung für den Cypress-Chip 
aus, gibts da vll schon nen Code für Datenübertragung mit max. 
Bandbreite zu finden ?

3. Bei dem FTDI-Chip ist ja scheinbar nen EEPROM notwendig, um die 
Konfiguration zu speichern, sind beim Cypress-Chip auch irgendwelche 
externen Bauteile nötig (außer den Offensichtlichen) ?

4. Wie schauts mit der Syncronisierung der Clock aus zwischen Chip und 
FPGA, ich nehme mal an In und Output sollten beide mit der selben 
Frequenz getaktet werden?

Danke euch beiden schonmal, wart ne große Hilfe bisher ;)

lg marcel

Autor: Uwe Bonnes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit FT2232H, eigenen FPGA Code und abgewandelten fastftdi.c
svn.navi.cx/misc/trunk/nds/dsi/ram.../fastftdi.c

Code habe ich 28 MByte/sec erreicht.

Ansonsten sind das FTDI Datenblatt und die App-Notes Dein Freund.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal zu deinem "GbE-Chip": Den gibts leider nicht. Mir ist kein 
derartiger Chiop bekannt. Sowas wie WizNet für GbE hab ich nirgends 
gefunden.

Zur Verbindung des FX2 zum FPGA: Am besten alle Leitungen anschließen, 
dann kannst du sychrones Slave-FIFO Interface machen. Das bringt den 
maximalen Durchsatz. Takt kannst du aus dem FX2 bereitstellen oder 
extern vom FPGA, kann man umschalten.

Die Firmware kannst du aus einem externen EEPROM laden (das gescheiht 
automatisch), oder bei jedem Anstecken über USB reinladen lassen, geht 
auch  automatisch, wenns einmal im Inf-File des Treibers drin is. Ein 
kleiner externer EEPROM am FX2 ist dann trotzdem erforderlich, um die 
Vender/Device ID zu speichern.

Beispielcode für synchrones Slave-FIFO Interface gibts hier von mir 
getestet: Beitrag "Re: USB-Port auf Spartan 3E für Anwendung nutzen" das 
erreicht 40MB/s bei 16 Bit breiter Anbindung. Die VHDL-Seite im FPGA 
musst du dir selber schreiben.

Der FT2232H hat den Vorteil, dass du keine eigene vendor-ID benötigst, 
du darfst die von FTDI nutzen.

Autor: Marcel C. (arcticus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah zum Ethernet nochmal:

Genau sowas meinte ich, wir hatten den WizNet Chip im Hinterkopf...wie 
ist es denn bei dem Chip (zb. dem WizNet W5300), kann man da noch 
irgendwie DHCP implementieren oder geht das nur mit dem etwas größeren 
Chip inkl. MCU ?...

Zum USB-Chip:

Ich find die FTDI Doku relativ nichtssagend, daher hatte ich auch hier 
nachgefragt...die Cypress Doku ist wenigstens detaillierter...

Wie ist das mit den Vendor-IDs, gibts da sonne Art Lizensierung oder wie 
muss ich mir das vorstellen ?

lg marcel

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, WizNet kann ja nur 100MBit maximal.

Zur FTDI Doku. Da ist doch alles wichtige beschrieben. Der synchrone 
FIFO-Modus ist das sinnvollste für FPGA würde ich denken. Alle 
Ablauf-Diagramme mit Timings sind angegeben (Sektion 4.4 im datenblatt), 
also wo ist das Problem?

Jedes USB Gerät braucht eine Vendor ID und eine Produkt ID. Willst du 
Geräte verkaufen, musst du eine eigene Vendor ID beantragen. Das kostet 
einmalig 2000 USD bei der USB.org und man darf dann 65536 
verschiedenartige Geräte verkaufen.
FTDI ist da eine löbliche Ausnahme. Auf Anfrage bekommt man von denen 
einen Block von 8 Product IDs, die man zusammen mit deren Vendor ID und 
nur zusammen mit FTDI Chips benutzen darf. Man darf also 8 
verschiedenartige Geräte bauen/verkaufen damit und auch das Inf-File des 
Treibers auf die eigene Firma anpassen.

Gleiche Geräte untereinander unterscheiden sich in der Seriennummer, die 
kann man als String in die Firmware des USB Controllers eintragen. Geht 
bei FTDI mit dem MPROG Utility.

Autor: Marcel C. (arcticus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Naja, WizNet kann ja nur 100MBit maximal.

Das ist mir durchaus bewusst... ob das Ding jetzt 8 MB/s oder 28 MB/s 
hat ist für unsere Anwendung relativ egal, schneller ist zwar meistens 
besser, Ethernet hat aber nen paar andere Vorteile, daher trotzdem die 
Frage zu dem WizNet Chip ;)


----


Aber ich seh es schon richtig, dass bei 245 FIFO sync Mode der zweite 
Channel nicht mehr anderweitig verwendet werden kann, z.b. für JTAG?

lg marcel

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, du kannst die beiden Kanäle bündeln oder einzeln betreiben:

# USB to parallel FIFO transfer data rate up to 10Mbyte/sec.
# Single channel synchronous FIFO mode for transfers > 25 Mbytes/sec.

Autor: Christoph Z. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wollte für unser Projekt auch unbedingt, dass unser FPGA Modul einer 
USB Standard Klasse angehört, damit wir keine Treiber entwickeln bzw. 
auf verschiedenen Plattformen PFLEGEN müssen.

Für den USB Chip gabs damals keine Evaluation, es stand schon fest den 
Cypress FX2 zu nehmen.

Aus verschiedenen Gründen, die nicht unbedingt nachvollziehbar sein 
müssen :-), habe ich mich für USBTMC (Test and Measurement Class) 
entschieden, ist im Prinzip das USB basierte physical layer zu IEEE488 
(vielleicht als GPIB geläufig, die Ethernet Variante heisst LXI).

Dazu noch die DFU Klasse damit man ein Firmware update mit schon 
vorhandenen Tools (dfu-util) machen kann.

Schönes Konzept das nun auch endlich stabil funktioniert. War eine 
heiden Arbeit die verdammt viel Zeit gekostet hat. Der FX2 Codespeicher 
war viel früher voll als angenommen und bis am Schluss musste ich immer 
wieder Codeoptimier runden machen und hatte kaum platz für 3 bis 4 
printf's, was das überhaupt einzige war (Ausser meinem treuen USB 
analyser) was mir zum debuggen zur Verfügung stand.

Resultat ist mit linux usbtmc treiber (nicht der kernel treiber, der 
alte...) das ich mit ca. 23 MiB/s daten zum FPGA schaufle und der 
Treiber mir ein Bein stellt und ich nur 2,5 MiB/s daten vom FPGA lesen 
kann.

Nach all dem wünschte ich mir eine Evaluation gemacht zu haben, so 
hätten wir wahrscheinlich den FTDI Chip bei uns getestet und uns erst 
danach entschieden.

Für mich ist es eine grosse lehre, bei einem uC sehr genau darauf zu 
achten wie gut die Möglichkeiten sind nach Fehlern zu suchen. Der FX2 
hat mir keine Freude gemacht.

Für alle die unsere Arbeit interessiert:
http://labs.ti.bfh.ch/gecko/wiki/systems/gecko3com/start
http://opencores.org/project,gecko3

Alles was zum GECKO3 Projekt gehört ist opensource und im opencores.org 
SVN Repository zu finden (Altium, Gerber, VHDL, C files und libraries)

Das Bild auf opencores.org mit dem Modul Stack ist kein Fake, die Module 
sind wirklich so skalierbar!

Autor: Manfred Kraus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christoph Z. schrieb:
> Für mich ist es eine grosse lehre, bei einem uC sehr genau darauf zu
> achten wie gut die Möglichkeiten sind nach Fehlern zu suchen. Der FX2
> hat mir keine Freude gemacht.

Hallo Christoph,

Das kann ich gut verstehen. Weil der FX-2 teilweise schwer zu 
beherrschen ist haben wir aus der Not eine Tugend gemacht und liefern 
mit unseren FPGA boards eine selbst entwickelte FX-2 Firmware plus 
Treiber und API mit. Außerdem eine Beispiel Implemenierung einer 
Wishbone-FX2 Brücke. Dieses Paket heisst bei uns UDK (unified 
development kit)  und ist ziemlich ausgereift da es seit Jahren in 
vielen hundert Projekten eingesetzt wurde.

Die Schaltpläne der FPGA Karten mit FX-2 können kostenlos auf unserer 
webseite www.cesys.com runtergeladen werden. Das UDK gibt es aber leider 
nicht kostenlos sondern nur in Verbindung mit einer Cesys Karte.

Bevor es das UDK gab haben wir die FPGA-FX2 Verbindung per GPIF gemacht. 
Das hat zwar funktioniert, aber das GPIF-timing war im FPGA fast nicht 
hinzubekommen. Inzwischen läuft alles im slave-FIFO mode des FX-2 und 
funktioniert schnell und problemlos.

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]
  • [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.