Gecko3 - CCC Event Weblog
Gecko3 - CCC Event Weblog
Gecko3 - CCC Event Weblog
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