25.12.2013 Aufrufe

Gecko3 - CCC Event Weblog

Gecko3 - CCC Event Weblog

Gecko3 - CCC Event Weblog

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

4. Kommunikation zwischen EZ-USB und FPGA<br />

lesen will. Momentan kommunizieren wir noch über einen Loopback Core im FPGA (siehe<br />

Kapitel 5.1), das heisst die Datenmenge, die gesendet wird, kommt auch wieder zurück.<br />

Somit wissen wir natürlich wieviel der Host lesen will. Bei einer anderen Konfiguration muss<br />

er aber vor der Übertragung wissen wieviele Daten der FPGA senden will.<br />

Diese Aufgabe soll später ein Protokoll eine Ebene über dem Handshaking übernehmen.<br />

Dieses Protokoll existiert noch nicht, doch erste Überlegungen haben uns mehrere Möglichkeiten<br />

aufgezeigt:<br />

• Die Firmware teilt dem Host vor jedem Transfer den FIFO Füllstand mit einem Vendor<br />

Request mit.<br />

• Der FPGA versieht den Datenstrom mit einer Endmarke. Der Host liest dann immer<br />

den gesammten Inhalt des FIFO Buffers und sucht nach der Endmarke.<br />

• Es wird eine feste Länge der Datenpakete definiert. Der FPGA würde dann nicht<br />

gefüllte Datenpakete mit Dummy-Informationen ergänzen.<br />

Die zwei letzten Möglichkeiten sind ähnlich, wobei die dritte Variante einen höheren Aufwand<br />

für den FPGA bedeutet. Doch die beste Lösung für dieses Problem zu finden ist Teil<br />

einer nächsten Arbeit.<br />

Die Signalisation des Datenendes durch eine Regelverletzung haben wir wegen der fehlenden<br />

RDY-Leitung realisiert. Diese Leitungen sind neben den zwei internen Flags die einzigen<br />

Inputs die vom GPIF eingelesen werden können. Da wir auf dem <strong>Gecko3</strong> die kleinste Version<br />

des EZ-USB FX2 einsetzen, haben wir nur zwei RDY-Leitungen zur Verfügung, welche aber<br />

schon von unserem Handshaking genutzt werden. Somit bleiben keine weiteren Eingänge,<br />

die vom GPIF genutzt werden können.<br />

Eine weitere Möglichkeit wäre eine Endsignalisation mit Hilfe eines Interrupts zu realisieren<br />

und das GPIF somit manuell aus der Firmware abzubrechen. Diese Lösung erschien<br />

uns jedoch als unstrukturiert, weil der Mikrokontroller in den Kommunikationsablauf eingreifen<br />

müsste. Diese Unabhängikeit von der Firmware bezahlen wir jedoch mit einem etwas<br />

aufwändigerem Handshaking, das am Ende der Übertragung etwas länger ist und somit<br />

die Datenrate etwas dämpft. Je grösser aber die Datenpakete sind, desto seltener werden<br />

die Endsignalisationen. Somit wird auch deren negativer Einfluss auf die Datenrate immer<br />

kleiner.<br />

12 Matthias Zurbrügg

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!