Timing FT2232H

[Christian (Gast)]

Hallo,

Zur Zeit versuche ich Daten von einem Spartan 6 über einen FT2232H an 
einen PC zu schicken.
Als ersten Test habe ich in einer Endlosschleife 0-255 übertragen. Das 
hat praktisch auf Anhieb funktioniert.

...
signal counter : unsigned (7 downto 0):="00000000";
begin
Process (CLKUSB) is begin
  if rising_edge(CLKUSB) then
    if TXE='0' then
      counter<=counter + 1;
      WR<='0';
      LED(3)<='1';
    else
      WR<='1';
      LED(3)<='0';
    end if;
  end if;
end process;

Databus<=std_logic_vector(counter);
...

Danach habe ich versucht Daten aus einem Ram zu übertragen. Dabei kommt 
es allerdings immer wieder zu Aussetzern, d.h. einzelne Bytes gehen 
verloren.

Da das Design aber eigentlich identisch ist denke ich, dass es am Timing 
liegt.

Dort beginnen jetzt meine Schwierigkeiten. Entweder hat der FT2232H ein 
extrem strammes Timing oder ich habe nicht verstanden, wie man die 
Timing-Constraints eingibt.

Aus dem Datenblatt entnehme ich eine WR# Setup Time von 11ns. Daraus 
mache ich folgendes Constraint:

NET "WR" OFFSET = OUT 5 ns AFTER "CLKUSB" RISING;

Ist das korrekt? Ist 11 ns Setup bei 60MHz Takt nicht ziemlich viel? 
Jedenfalls kann dieses Constraint nicht eingehalten werden. Vielleicht 
auch ein Hinweis darauf, dass ich es falsch habe?

Dann ist im Datenblatt angegeben Clockout to TXE: 1 ns(min) 7,25ns 
(max). Daraus mache ich das Constraint:

NET "TXE" OFFSET = IN 9 ns VALID 9 ns BEFORE "CLKUSB" RISING;

Ist das korrekt?

Hat sonst jemand Erfahrungen mit dem Chip?

Schöne Grüße,
Christian

[Christian R. (supachris)]

Das ist ja genau die fiese Stelle am FT2232H. Die beiden Zeiten zusammen 
ergeben ja schon mehr als die 16.66ns Takt. Und da ist noch nicht mal 
die Laufzeit im FPGA drin, die das WR# sperrt, wenn der FIFO voll ist. 
Ist doch klar, dass das nicht eingehalten werden kann. Aber eigentlich 
dürfte das nicht so ins Gewicht fallen, die Hauptsache ist, dass dir die 
9ns nach dem TXE# reichen, um die Tatemaschine anzuhalten, bzw. das 
Lesen aus dem RAM zu stoppen. Wenn du dann dem FT2232H zu spät meldest, 
dass jetzt kein Schreiben mehr stattfindet, geht im schlimmsten Fall das 
letzte Byte verloren. Aber da du ja intern gestoppt hast, ist das eh 
nochmal das gleiche wie das, was den FIFO hat voll werden lassen. Wenn 
es mit dem simplen test funktioniert, dann müsstes auch beim RAM 
auslesen gehen, wenn du wie geschrieben das Lesen stoppst, sobald TXE# 
auf 1 geht.

[Christian R. (supachris)]

Hab mir das eben nochmal durchdacht. Das Problem ist nicht das 
Vollwerden des Fifo sondern das wieder verfügbar werden. Wenn das TXE 
wirklich 7ns braucht, und WR seine 11ns Setup haben willst, hast du 
verloren....da ist Datenverlust vorprogrammiert. Deswegen arbeite ich 
immer noch mit dem Cypress FX2, der hat auch so ein sinnloses Timing, 
aber kann mit extermem Takt betrieben werden. Bei kleiner 30MHz schafft 
man die Zeiten dann langsam.

[Christian (Gast)]

Mit dem FX2 habe ich auch schon mal was gemacht. Was ich am FT schöner 
finde ist, dass das ganze drum herum deutlich weniger Arbeit erfordert.
Das schreiben des Programms für den USB Chip entfällt beim FT ja ganz, 
beim PC-Programm ist man beim FT auch schneller beim Ergebnis...
Zeit ist leider ein zu wertvolles Gut.

Das die Zeiten gar keinen Sinn ergeben ist mir gar nicht aufgefallen. 
Hast du FTDI deswegen mal kontaktiert?
Beim Starten eines Schreibvorgangs könnte man es so handhaben, dass man 
ein internes FF umschaltet, wenn TXE low ist, und WR low setzt, wenn das 
FF gesetzt ist. So würde man einen Takt verschenken, aber das Timing 
könnte zumindest theoretisch eingehalten werden.
Im Prinzip so, wie es auch in den Timingdiagrammen im FT-Datasheet 
gemacht ist.

Habe ich die Timing-Angaben denn richtig in Constraints umgesetzt?

Das Timing com FT232H ist interessanterweise etwas entspannter. 
Allerdings werden 100 ps für den FPGA auch nicht außreichend Zeit sein 
um zu schalten.

Gibt es sonst noch High-Speed USB-Chips? Oder vielleicht sogar schon 
welche für usb 3.0?
Für 2.0 High speed muss es doch noch was anderes geben, oder nicht? Es 
ist doch nicht in allen Geräten ein FX2 drin?!?


Ganz Aufgegeben habe ich den FT2232H noch nicht. Denkst du mein Ansatz 
könnte funktionieren?

[Christian R. (supachris)]

Also wir wollten eventuell mal umschwenken vom FX2 auf den FTDI. Aber 
die Timings haben mich abgeschreckt. Das war beim FX2 schon Kampf genug. 
Zuerst hatte ich 40MHz externen ICLK und den 270° verschoben ausgegeben, 
damit man die Hold.Zeiten einhalten kann. Das ging sehr gut, nachdem ich 
lange am Ablauf der Signale gefummelt habe. Jetzt fahre ich 
sicherheitshalber nur noch mit 20MHz und geb den Takt negiert aus, da 
kommt man dicke hin mit den Zeiten und erreicht trotzdem 40MB/s. Der 
Treiber ist da viel schlimmer, aber alle Probleme haben sich in Luft 
aufgelöst, seit wir auf WinUSB umgestiegen sind. Der FX2 ist nun mal DER 
USb 2.0 HighSpeed Controller und war der einzige bis der FT2232H kam. 
Mittlerweile gibts für USB 3.0 den FX3 als Enigeering Sample. Ich hab 
eins der raren Demo-Boards von Cypress geliehen bekommen. Geht an sich 
erst mal gut, hat aber wieder das gleiche Problem. Maximaler IFCLK beim 
Slave FIFO Modus 100MHz, aber 8ns Flags Propagation und 2ns Setup für 
R/W. Na toll. Kann man real also dann mit 60...70MHz vielleicht 
betreiben. mal schauen, wie der sich so in der Praxis macht. Der Treiber 
ist schon mal genauso schlimm wie der vom FX2. Hoffentlich kommt mit 
Windows 8 dann auch USB SuperSpeed im WinUSB Treiber. Ansonsten 
vielleicht Jungo....mal schauen. Vom Treiber programmieren haben die 
Jungs jedenfalls keine Ahnung. Bluescreens, überschriebene 
Speicherbereiche, Einfrieren des PC. Alles möglich. Kriegt man nie und 
nimmer durch WHQL ohne Tricksen.
FTDI ist da auch nicht besser, fragt man sich, wie die den WHQL Test 
bestehen.

Was die Lösung mit dem extra FF bringen soll, weiß ich nicht. Das 
verschiebt die Sache nur einen Takt nach hinten.

[Johann (Gast)]

Ich verwende den FT2232H bereits schon eine Zeit in einigen Produkten 
von uns.

Bei Timing hatte ich auch meine Kopfschmerzen. Dann hatte ich meinen 
Logikanalysator benutzt um die Timings mal nachzumessen. Wir habe ein 
eigenes Board gemacht. Ich habe zwischen dem FPGA und den FTDI-Chip 
Messpunkte implmentiert.

Leider ist es wirklich so das sich der Wert von der TXE Leitung 
gegenüber dem 60MHz Clock stark verzögert verändert. Den genauen Wert 
habe nicht mehr im Kopf.

Ich habe es denn wie folgt gelöst:

Man erzeugt aus dem 60MHz CLK mit einem DCM einen CLOCK der um 180° oder 
270° Grad verschoben ist. Mit diesem Clock wird dann das THX Signal 
abgetastet.

Mit dem normalen 60MHz Clock gegebe ich immer die Daten aus dem BlockRAM 
aus. Ich benutze eine RESEND FLAG um zu signalisieren das der FT2232H 
frei war oder nicht.

Falls der FT2232H nicht bereit war sende ich so lange den gleichen Wert 
erneut bis dieser wieder frei war.

Dies kann man über einen zusätzlich FLIPFLOP erreichen der als 
Ausgangsbuffer benutzt wird.

[Christian (Gast)]

zur Idee mit dem FF:
Ich denke der Punkt ist, dass man auf das FF ein Constraint von einer 
Setuptime von 7 ns angeben kann, im übernächsten Takt das Signal des FFs 
aber schon von Anfang an zur Verfügung steht. Man könnte also die 11 ns 
für das WR Signal einhalten.
Vielleicht habe ich aber auch nicht genügend drüber nachgedacht. Am 
Wochenende werde ich mal versuchen das ganze umzusetzen. Vielleicht sehe 
ich dann, dass es gar nichts bringt...

@Johann:
klingt interessant. Wenn meine idee nicht funktioniert probiere ich es 
mal so. Was für einen FPGA verwendet ihr?

[Christian (Gast)]

P.S.

@Johann:
Wie ausführlich habt ihr deine Lösung verifiziert? Ich könnte mir 
vorstellen, dass das Timing auch eine gewisse Temperaturabhängigkeit 
hat...

[Johann (Gast)]

Ich verwende einen Spartan 3.

Zum richtigen ausführlichen Test bin ich leider noch nicht gekommen. Ich 
habe es mir einfacher gemacht.

Ich habe die Firmware modifiziert, indem ich den AD-Wandler abgeklemmt 
habe und einen Counter benutze der hochzählt. Dadurch habe ich ein 
eindeutiges Testsignal. Der Counter-Wert wird somit in den FIFO 
geschrieben. Dadurch kann ich die Ausgabe so lassen und testen.

Am PC habe ich eine Kontroll-Software geschrieben. Falls eine 
Datenübertragungsfehler auftritt würde diese es mitzählen. Dies habe ich 
dann eine Tage laufen lassen.

Ich habe nur noch leider Probleme mit der PC-Software. Vielleicht kann 
mir da ja einer weiterhelfen. Der PC-Inputbuffer ist leider nur 65k 
groß. Deshalb muss ich leider immer ständig den Bufferinhalt pollen, 
damit dieser nicht überläuft. Ich kann leider diesen Buffer nicht größer 
stellen. FTDI meint das ist ein altes Win 2000 Problem. Dadruch kommt es 
machnmal vor das mein Buffer überläuft, wenn meine Anwendung nicht 
wieder rechtzeitig dran kommt. Dies kann ich leider nocht nicht 
verhindern. Windows ist leider kein Echtzeitbetriebssystem. Ich habe es 
unter Win XP und Win 7 64 Bit getestet. Bei beiden gibt es keinen 
Unterschied. Demnach geht manchmal nicht ein Byte sondern größere 
Datenmengen verloren.

Aber vielleicht kann FTDI dies mit einen Treiberupdate bald ändern. 
Darauf warte ich schon eine Weile. Wenn mehrere Leute diesen Wunsch 
äußern wird dies sicherlich auch umgesetzt.

[Christian R. (supachris)]

Wieso geht da was verloren? Das darf doch bei BULK Transfer nicht 
passieren. Wenn du denn Buffer nicht schnell genug leerst, muss der FTDI 
die TXE# Leitung auf inaktiv setzen, und deine Logik das Schreiben 
stoppen. So jedenfalls funktioniert das beim FX2. Wenn ich vom PC aus 
die Puffer nicht leere, gibt der mir Full und ich hör auf mit Schreiben. 
Da geht nix verloren. Sowas hätte man höchstens bei ISO-Transfer.

[Christian (Gast)]

Johann schrieb:
> Ich verwende einen Spartan 3.
3 ohne E A oder AN? Welches Speedgrade?
Ich schaffe es in einem S6 Speedgrade 2 nicht das Timingconstraint 
einzuhalten dass die Daten 5,66 ns nach Clock vorhanden sein müssen.
Und im FPGA ist sonst nichts drin. Nichmal ein Lesezugriff auf den Chip.
Mit Speedgrade 3 würde es momentan laufen. Ich setze nie wieder einen 
langsameren Speedgrade auf einen Prototypen!



> Zum richtigen ausführlichen Test bin ich leider noch nicht gekommen. Ich
> habe es mir einfacher gemacht.
>
> Ich habe die Firmware modifiziert, indem ich den AD-Wandler abgeklemmt
> habe und einen Counter benutze der hochzählt. Dadurch habe ich ein
> eindeutiges Testsignal. Der Counter-Wert wird somit in den FIFO
> geschrieben. Dadurch kann ich die Ausgabe so lassen und testen.
>
> Am PC habe ich eine Kontroll-Software geschrieben. Falls eine
> Datenübertragungsfehler auftritt würde diese es mitzählen. Dies habe ich
> dann eine Tage laufen lassen.

Mutig. Ich hätte dann schon Sorge, dass es nicht mehr über den ganzen 
Temperaturbereich funktionioert oder Probleme über den Spannungsbereich 
geben könnte.


>
> Ich habe nur noch leider Probleme mit der PC-Software. Vielleicht kann
> mir da ja einer weiterhelfen. Der PC-Inputbuffer ist leider nur 65k
> groß. Deshalb muss ich leider immer ständig den Bufferinhalt pollen,
> damit dieser nicht überläuft. Ich kann leider diesen Buffer nicht größer
> stellen. FTDI meint das ist ein altes Win 2000 Problem. Dadruch kommt es
> machnmal vor das mein Buffer überläuft, wenn meine Anwendung nicht
> wieder rechtzeitig dran kommt. Dies kann ich leider nocht nicht
> verhindern. Windows ist leider kein Echtzeitbetriebssystem. Ich habe es
> unter Win XP und Win 7 64 Bit getestet. Bei beiden gibt es keinen
> Unterschied. Demnach geht manchmal nicht ein Byte sondern größere
> Datenmengen verloren.
>
> Aber vielleicht kann FTDI dies mit einen Treiberupdate bald ändern.
> Darauf warte ich schon eine Weile. Wenn mehrere Leute diesen Wunsch
> äußern wird dies sicherlich auch umgesetzt.

Das Problem kann ich nicht bestätigen. Wenn der 64k Puffer gefüllt ist 
kann anfangs noch rein geschrieben werden. Allerdings kann ich dann in 
der Software auch mehr als 64k auslesen. Ob die Daten noch stimmen habe 
ich noch nicht exakt kontrolliert, auf den ersten Blick sieht es aber 
gut aus.
Nach einiger Zeit geht dann auch die TXE-Leitung auf High und bleibt es 
bis ich in der Software gelesen habe.

Ich stimme Christian R. zu, dass das für einen Bulk-Transfer auch gar 
nicht anders sein kann. Wenn da Daten verloren gehen wäre es für mich 
ein Ausschlusskriterium für den Chip.

Abgesehen von den Timing-Problemen in ISE habe ich nur noch das Problem, 
dass das 510. Byte des Transfers zwei mal übertragen wird. Ansonsten 
wird alles richtig übertragen. Ich habe keine Idee, was ich noch 
ausprobieren kann.
Den FTDI Supprot habe ich mal angeschrieben, aber die haben nicht 
geantwortet (Firmenemail mit Steuernummer und Handelsregistereintrag. 
Sie können sich also denken, dass ich nicht nur privat bastle).

Außerdem bereitet mit Bauchschmerzen, dass man einen Bluescreen bekommt, 
wenn man im PC-Programm das Device schließt, es aber schon herausgezogen 
hat. Momentan umschiffe ich das mit einer Statusabfrage vor dem 
schließen, nur wenn die erfolgreich war wird der Befehl zum schließen 
aufgerufen.

Naja. Wenn ich bis Ende nächster Woche keine Lösung habe wird es wohl 
doch der FX2 Chip. Auch wenn ich da vermutlich alleine zum 
zusammensuchen der Software die ich brauche genau so lange brauchen 
werde wie bisher für den FT-Chip ;)

[Christian (Gast)]

Kurzes Update von mir:

Jetzt läuft es. Ich hatte einen Fehler in der Statemachine.
Das Timing wird zwar immer noch nicht eingehalten aber nur um 600 ps. 
Knackpunkt hier war die Clock zuerst auf einen DCM zu geben. Ohne werden 
die Constraints um 2,5 ns nicht eingehalten. Aber auch damit läuft es 
momentan.

Eine invertierte oder 270° phasenverschobene Clock brauche ich nicht. 
Wenn ich das Signal diekt drauf gebe geht es auch.

Ich habe es jetzt so gemacht, die TXE Leitung in ein FF eingelesen wird 
und dessen Ausgang in der Statemachine verwendet wird. Dann Springe ich 
zwei Positionen zurück und nicht nur eine. Bei einem Speedgrade 3 FPGA 
lassen sich so alle Constraints einhalten. Also Clock to Data von Daten 
und WR und Setup von TXE.
Vielleicht habe ich bei dem vielen Nackdenken über den Takt aber auch 
einen Knoten im Kopf bekommen und das ist unnötig. Aber ich denke dass 
das so die einzige saubere Lösung ist, bei der das TXE-Signal irgendwann 
zwischen 1 und 7,15 ns nach steigender Flanke auftreten kann.

[Christian R. (supachris)]

Christian schrieb:
> Außerdem bereitet mit Bauchschmerzen, dass man einen Bluescreen bekommt,
> wenn man im PC-Programm das Device schließt, es aber schon herausgezogen
> hat. Momentan umschiffe ich das mit einer Statusabfrage vor dem
> schließen, nur wenn die erfolgreich war wird der Befehl zum schließen
> aufgerufen.

Für BlueScreens sind die FTDI Treiber ja bekannt. Lässt der sich 
eventuell auch über WinUSB ansprechen? Dann bist du die Probleme 
los...WinUSB haben wir trotz umfangreicher Versuche noch nicht zum 
BlueScreen oder aufhängen bekommen.

Kannst du mal einen Simulations-Screenshot von deiner Realisierung 
zeigen? Nur mal interessehalber, die beiden Stellen, also wenn der FIFO 
voll wird (TXE# geht high) und wenn er wieder verfügbar wird (TXE# wird 
low). Würde mich mal interessieren, ich hab da wohl zu wenig Fantasie, 
das aus deiner Lösungsbeschreibung abzuleiten.
Aber ich vermute, das ist so ähnlich wie ich das beim FX2 gemacht habe. 
Wenn FIFO voll wird, wird das Schreiben natürlich sofort gestoppt, die 
Setup-Zeit des Flags reicht dicke, um die internen Abläufe anzuhalten. 
Wenn der FIFO wieder Daten aufnehmen kann, schreibe ich nicht sofort im 
nächsten Takt, sondern erst nach 2...3 Takten wieder los. Somit halte 
ich auch die ewig lange geforderte Setup-Zeit ein. Die WR und RD 
Steuersignale hab ich in IOBs gepackt, damit das ordentlich schnell 
geht.

[Christian (Gast)]

Christian R. schrieb:
> Für BlueScreens sind die FTDI Treiber ja bekannt. Lässt der sich
> eventuell auch über WinUSB ansprechen? Dann bist du die Probleme
> los...WinUSB haben wir trotz umfangreicher Versuche noch nicht zum
> BlueScreen oder aufhängen bekommen.
Am FTDI Treiber fand ich so gut, dass es ihn praktisch identisch für 
verschiedene Betriebssysteme gibt. Ohne irgendwas über WinUSB zu wissen, 
würde ich mal vom Namen her vermuten, dass es den nur für Windows gibt.
>
> Kannst du mal einen Simulations-Screenshot von deiner Realisierung
> zeigen?
Welche? Behavioural? Oder Post-Translate  Route  Map? Bisher habe ich 
zu diesem Projekt nur die Behavioural angeschaut.

> Nur mal interessehalber, die beiden Stellen, also wenn der FIFO
> voll wird (TXE# geht high) und wenn er wieder verfügbar wird (TXE# wird
> low). Würde mich mal interessieren, ich hab da wohl zu wenig Fantasie,
> das aus deiner Lösungsbeschreibung abzuleiten.
Meine Erklärung war sicher auch nicht die Beste.

> Aber ich vermute, das ist so ähnlich wie ich das beim FX2 gemacht habe.
> Wenn FIFO voll wird, wird das Schreiben natürlich sofort gestoppt, die
> Setup-Zeit des Flags reicht dicke, um die internen Abläufe anzuhalten.
> Wenn der FIFO wieder Daten aufnehmen kann, schreibe ich nicht sofort im
> nächsten Takt, sondern erst nach 2...3 Takten wieder los. Somit halte
> ich auch die ewig lange geforderte Setup-Zeit ein.
Ja, ich beginne auch nciht direkt.

> Die WR und RD
> Steuersignale hab ich in IOBs gepackt, damit das ordentlich schnell
> geht.
Kann man das irgendwie erzwingen? Ich meine irgendwo in den 
Optimierungseinstellungen gesehen zu haben, dass er das macht, wenn es 
geht. Aber keine Ahnung ob er es wirklich getan hat.

[Christian R. (supachris)]

Ja, WinUSB geht natürlich nur unter Windows. Dafür aber extrem 
zuverlässig und für alle USB Geräte (außer ISO-Streaming).
Behavioral reicht. Nur mal interessehalber, wie gesagt wir nehmen den 
FX2 und demnächst den FX3. Aber dieses komische Timing kam mir schon 
immer seltsam vor, in Kombination mit dem nicht änderbaren Takt.
IOB kannst du erzwingen für das entsprechende Signal bzw. den Port:

attribute IOB : string;
attribute IOB of USB_FF : Signal is "true";
attribute IOB of USB_EF : Signal is "true";

[Christian (Gast)]

Bild ist im Anhang. Ich habe mal alle irrelevanten Signale entfernt. Ich 
hoffe keins zuviel. Wenn doch bitte beschweren.

Wer weiß, vielleicht nehme ich ja auch noch den FX2 oder 3.

100% sicher ob mein Design richtig läuft muss sich auch erst noch 
zeigen.

[Christian R. (supachris)]

Aha, ja, so ähnlich hab ich das am FX2 auch. Nur, dass ich das WR direkt 
vor dem Ausgangs-FF nochmal mit dem Full verknüpfe. Aber da die Daten 
bei vollem FIFO eh verloren gehen, sollte das auch gehen. Der Wert 0xAB 
wird ja bei dir noch 2 mal ins FIFO geschrieben, wenn der schon voll 
meldet. Sollte aber kein problem geben. Beim FX2/3 ist man halt bissl 
flexibler, was die Firmware auf dem Chip an sich angeht. Allerdings ist 
da etwas Einarbeitung erforderlich. Beim FX3 noch etwas mehr, denn das 
ist kein einfacher 8051 mehr, sondern ein ARM9, der da drin werkelt. 
Aber mit dem RTOS-API von Cypress geht das erst mal ganz gut, zumindest 
die Beta-Sachen.

[Johann (Gast)]

Ich habe mnicht freiwillig mit dem Projekt aufgehört, sondern es wurde 
als abgeschlossen eingestufft und das nicht von mir.

Ich wurde wie es so oft ist anderen Projekten zugeteilt. Man kann das 
ganze ja immer noch fixn wenn es nicht geht. Das finde ich leider auch 
immer sehr schade da es mich auch sehr interessiert hat.

Die Annahme von Christian R. ist falsch. Du denkst Du hälst das Timing 
ein. Ich habe mit einem Logikanalysator nachgemessen. Auch wenn ich 
keine Daten übertrage und THX sagt das der IC bereit ist kann es 
trotzdem vorkommen das plötzlich das THX flag den Zustand auf besetzt 
ändert.

[Johann (Gast)]

Mit Blue Screens habe ich zum Glück noch keine Probleme, da die neuen 
Treiber da deutlich besser geworden sind.

[Johann (Gast)]

Wie groß ist eigentlich euer Zwischenspeicher im FPGA? Benutzt Ihr nur 
den internen Block RAM oder habt Ihr externen DDR2 RAM?

Ich benutze einen SPARTAN 3A mit dem langsamen Speedgrade.

[Christian R. (supachris)]

Das klingt ja gruselig. Was passiert denn, wenn du Daten sendest, wenn 
TXE# kurzzeitig auf High geht? Wenn du schnell genug im FPGA stoppen 
kannst, sollte es doch kein Problem geben, vorausgesetzt, der FTDI 
verwirft die Daten wirklich, wenn FIFO voll ist. Oder gibts dann bei dir 
Datenverlust?
Gut, dass wir beim FX2 geblieben sind. Mit dem WinUSB Treiber läuft das 
jetzt problemlos.

[steffen (Gast)]

@Christian

kannst du deinen VHDL Code mal posten?

danke

[Christian (Gast)]

Momentan benutzen wir nur den Blockram im FPGA. Ziel ist überhaupt erst 
mal einen funktionieren Datentransfer zu stande zu bringen. Alles andere 
kommt danach.


Zuerst eine Anmerkung zum Code: Ich will einen 20 Bit breiten Speicher 
versenden, daher die drei Sendezustände. Zum Test ob alle Daten richtig 
rauskommen habe ich den Ram zwischenzeitig rausgenommen und durch
Hier ist mein Code:

Process(DCLK270) is begin
  if rising_edge(DCLK270) then
    resend<=TXE;
  end if;
end process;
  
Process(DCLK) is begin
  if rising_edge(DCLK) then
    TXEFF<=TXE;
  end if;
end process;


if rising_edge(DCLK)then
  case(SSnd) is
    when WaitingForSendFlag =>
      If AquisitionDone='1' then 
        SSnd<=WaitForInitialTXELow;
        FinalAddress<=unsigned(WAddress);
        Counter<=unsigned(WAddress)+1;
      end if;
    when WaitForInitialTXELow=>
      if TXEFF='0' then
        SSnd<=Send1;
      end if;
      
    when Send1 =>
      if resend='1' then
        ResumeState<=Send3;
        counter <=counter-1;
        SSnd<=WaitForResume;
        WR<='1';
      else
        WR<='0';
        Databus<=X"AB";
        SSnd<=Send2;
      end if;
      
    when Send2 =>
      if resend='1' then
        ResumeState<=Send1;
        counter <=counter-1;
        SSnd<=WaitForResume;
        WR<='1';
      else
        WR<='0';
        
        Databus<=X"CD";
        SSnd<=Send3;
      end if;
      
    when Send3 =>
      if resend='1' then
        ResumeState<=Send2;
        SSnd<=WaitForResume;
        WR<='1';
      else
        WR<='0';
        Databus<=X"EF";
        counter<=counter+1;
        if counter=FinalAddress then 
          SSnd<=Done;      
        else
          SSnd<=Send1;
        end if;
      end if;
      
    when WaitForResume =>
      if TXEFF='0' then
        SSnd<=ResumeState;
      end if;
    when Done=>
      WR<='1';
    when others =>
      SSnd <=WaitingForSendFlag;
  end case;
end if;

Damit wird momentan immer ein Byte zuviel übertragen. Langsam bin ich es 
leid. Ich denke ich werde als letztes noch einen Versuch machen, bei dem 
ich nicht die drei Zustände habe. Wenn es dann nicht funktioniert wird 
es der FX2.
Das schlimme ist, dass ich das eigentlich alles schonmal gemacht hatte 
aber meine Dokumentation davon nicht mehr vorhanden ist. Ich erinnere 
mich, dass es sogar ein einziger Krampf war auf der Cypress Seite 
überhaupt die Dokumentation zu finden...