Ich habe ein Digilent Basys2 FPGA und implementiere die EPP-Schnittstelle, die in http://www.digilentinc.com/Data/Products/ADEPT/DpimRef%20programmers%20manual.pdf beschrieben ist . Dadurch kann ein Programm namens Adept Bytes von einem FPGA-Design über das USB-Kabel senden und empfangen.
Nachdem ich diese Anweisungen befolgt hatte, hatte ich etwas, das zu funktionieren schien. Ich könnte Bytes von Adept senden und sie würden erfolgreich auf der Sieben-Segment-Anzeige angezeigt. Als ich eine 100-Byte-Datei zum Speichern im Register-Array schickte, kamen leider nur 83 Bytes an. (In dieser Situation ist das Debuggen etwas schwierig, da es nur so viele einfache Ausgänge auf dem FPGA gibt und die Verwendung von Adept zum Zurücklesen der Bytes vom FPGA die Möglichkeit eröffnet, dass die Leseimplementierung fehlerhaft ist. Am Ende habe ich das hinzugefügt Fähigkeit, durch das Array zu gehen und jedes Byte der Reihe nach anzuzeigen.)
Ich habe meine Implementierung ein paar Mal umgeschrieben und mir die Beispiele anderer Leute angesehen (sie waren meistens in VHDL), aber sie ist immer noch nicht zuverlässig. Einige Schreibvorgänge, sogar einzelne Bytes einzeln, werden vom Design einfach nicht aufgegriffen, obwohl Adept keinen Fehler meldet.
Update – VHDL-Beispieldesign ausprobiert
Ich habe es jetzt geschafft, den Code und das Design hier auszuführen: http://hamsterworks.co.nz/mediawiki/index.php/Digilent_EPP_Performance
Es funktioniert, aber ein einfacher Zähler, den ich hinzugefügt habe, zeigt, dass etwas mehr Schreibvorgänge durchgeführt werden als erwartet, in einigen wiederholten Tests, die ich durchgeführt habe (das Design neu laden, dann eine Datei mit Adept senden):
Expected Got
50 51 to 55
100 105 to 108
200 206 to 215
Für das kompilierte C++-Programm aus diesem Tutorial wurden 1440000 = 0 (mod 256) Bytes gesendet, aber die geschriebene Zahl war 32 (mod 256) (ich habe nur 8 LEDs!). In einem anderen waren die Zahlen 1430000 = 240 (mod 256) gegenüber 253 (mod 256).
Also denke ich immer noch, dass es eine Timing-Sache gibt. Kann jemand mit einem Basys 2 dasselbe Experiment ausprobieren? Meine leicht veränderte VHDL ist unter https://gist.github.com/ejrh/6ba768499319e9945bd0
Kleiner Testfall, bevor ich VHDL gelernt habe
Ich endete mit einem kleinen Testfall für das WRITE-Signal von EPP:
input wire usb_write; // in constraints file: NET "usb_write" LOC = "C2";
reg prev_write = 1; // assume initially high
reg [9:0] write_count = 0;
always @(posedge mclk) begin
if (usb_write != prev_write) begin
write_count <= write_count + 1;
end
prev_write <= usb_write;
end
// display write_count on SSD
// display prev_write on LED 0
Wenn ich normalerweise ein Byte mit Adept sende, write_countwird es wie erwartet um 2 erhöht. (WRITE geht auf Low, um ein Adressbyte und ein Datenbyte zu schreiben, und kehrt dann auf High zurück). Die LED leuchtet zwischen den Operationen und zeigt damit an, dass sie prev_writehoch ist.
Aber manchmal wird die Zählung nur um 1 erhöht, während die LED immer noch auf High zurückkehrt. Es ist, als würden verschiedene Teile meines always @(posedge mclk)Blocks unterschiedliche Werte von verwenden usb_write.
Muss ich diese Eingangs-/Ausgangsleitungen irgendwie puffern? Ich habe keine Beispiele dafür gefunden.
Später heute werde ich die Frage mit einem Teil des tatsächlichen EPP-Codes aktualisieren, mit dem ich arbeite. Ich möchte auch eines der VHDL-Beispiele ausprobieren, obwohl ich neu bei VHDL bin.
Folgen Sie dieser Seite https://embeddedmicro.com/tutorials/mojo/metastability-and-debouncing
Ich habe die vom Host gesendeten Steuersignale gepuffert. Sie waren nicht in meiner ursprünglichen Frage enthalten, da ich selbst mit nur seltsame Ergebnisse hatte usb_write.
always @(posedge clk) begin
astb_buf <= usb_astb;
dstb_buf <= usb_dstb;
end
Das Puffern nur dieser beiden hat die Datenprobleme behoben. Die anderen Signale sind usb_writeund usb_data[7:0], aber diese scheinen an dieser Stelle nicht gepuffert zu werden.
Ich konnte 100 Bytes senden und 100 Bytes ohne Hinzufügungen, Verluste oder Mutationen empfangen, worüber ich erleichtert bin, da ich jetzt kein Fehlerkorrekturprotokoll implementieren muss.