Hallo zusammen, ich möchte grad ne "SPI"-Verbindung zwischen nem Spartan 3E und nem ATmega realisieren. In Anführungszeichen, weil das ganze ne Art 3-Leitung SPI mit WR/RD- und Mode-Signalen ist. In der Simulation funktioniert das auch. Auf dem FPGA allerdings nicht immer. (Der AVR-Code funktioniert übrigens definitiv.) Kann mir jemand vielleicht sagen warum das nicht funktioniert?!?
Gast
#744463
Ganz spontan würde ich sagen es liegt hier dran:
1 | |
Du hast hier 2 verschiedene Takte in deinem FPGA. Das ist meistens keine sonderlich gute Idee. Lies dir am besten das hier mal durch: http://www.mikrocontroller.net/articles/Taktung_FPGA/CPLD
Gast
#744598
Schau mal her:
ProTimeOut:process(CLK_50MHZ)
begin
if rx_timeout < 65535 then
rx_timeout <= rx_timeout + 1;
end if;
if tx_timeout < 65535 then
tx_timeout <= tx_timeout + 1;
end if;
end process ProTimeOut;
was soll das sein? Wo ist Dein Takt? Wie schnell soll denn Dein Zähler
werden? Klar funktioniert das in der Simulation, weil da CLK_50MHZ
Erreignisse kommen, in Hardware ist es...äh... wie soll ich sagen...
Müll :-)
Das ist das erste, was ich gesehen habe
Grüße,
Kest
@ Andreas Weschenfelder (rupplyn) >ich möchte grad ne "SPI"-Verbindung zwischen nem Spartan 3E und nem >ATmega realisieren. >In Anführungszeichen, weil das ganze ne Art 3-Leitung SPI mit WR/RD- und >Mode-Signalen ist. Warum willst du das Rad neu erfinden? Was spricht gegen eine klassiche SPI? >In der Simulation funktioniert das auch. Auf dem FPGA allerdings nicht >immer. (Der AVR-Code funktioniert übrigens definitiv.) >Kann mir jemand vielleicht sagen warum das nicht funktioniert?!? Wie der Vorposter schon bemerkte ist dein Timeout Prozess Sülze. Da fehlt ein Takt. Ausserdem solltest du das mit den Variablen rx_data und tx_data lassen, das ist Murks. Nimm Signale. Das tut auch gar nicht weh. Und was soll den sowas?
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
Wo hast du dennn das her? Und ausserdem wird dadurch dein tx_data(7) immer So macht man das. Sieht doch gleich viel besser aus, oder?
1 | |
2 | |
3 | |
MFG Falk
Gast
#744810
@ all Danke erst mal für die Anregungen, ist leider nur eine Hobby-Arbeit und kann sie erst heut Abend umsetzen. @ Kest Klar, jetzt wo du das sagst, seh ich das auch. @ Falk Brunner Ich habe mit vhdl praktisch keine Erfahrung und versuche mir das gerade selbst bei zu bringen. möchte daher erst mal selbst verschiedene module erstellen. Dein 3-Zeiler sieht übrigens natürlich besser aus.
Gast
#745010
Wenn Du Dich mit dem schematic-Editor abquälen willst, kannst Du auch den folgenden Link nutzen: http://www.ibrtses.com/electronics/fpgabasic.html -> Using serial registers to interface to the external world Der ist auch für das grundlegende Verständnis ganz gut. Rick
Echte Hardware kennt auch keine globalen Variablen, d.h. du kannst keine zwei Ausgänge parallel schalten. Dies passiert in VHDL, wenn du ein Signal in zwei Prozessen schreibst, hier rx_timeout und tx_timeout. Da dies einen Fehler bei Synthese erzeugt, frage ich mich, wie du zu einen Bitstream gekommen bist. Bye Tom
Die Antwort von Mike hat mir am meisten geholfen. Es läuft jetzt recht
stabil.
Allerdings erhalte ich am Parallel-Ausgang (LEDs) zuerst kurz 0xFF,
anschließend die richtigen Daten.
Ich wollte das ganze noch auf die Main-Clk (50MHz) synchronisieren. Hab
das folgendermaßen realisiert:
if falling_edge(CLK_50MHZ) then
--Flankenerkennung, sync auf CLK50MHZ
if AT_CLK = '1' then
flankenbit <= '1';
end if;
if (flankenbit = '1') and (AT_CLK = '0') then
flankenbit <= '0';
--Das hier war eine fallende Flanke... -> Auswertung
end if;
end if;
Kommt mir allerdings selbst ein bisschen umständlich vor. Gibt's da ne
bessere Lösung?