Forum: FPGA, VHDL & Co. Erfahrung mit SPI Slave und Spartan 6 FPGA?

Sowas macht man indem man den SCLK einsychronisiert und bei der 
entsprechenden Flanke ein Clock Enable für den internen Takt erzeugt. 
Geht natürlich nur, wenn die Frequenz des SCLK ein ganzes Stück 
niedriger (Faktor 4) ist als die interne Taktfrequenz, was ja aber in 
den allermeisten Fällen passen sollte.

Andi P. schrieb:
> process(reset,sclk, CS)
Vorneweg: CS gehört hier nihct in die Sensitivliste.

> Nach der ständig wiederholten Warnung:
> (i.e. asynchronous reset with an initialization value of 1).
Dann mach doch den asynchronen Reset raus. Wofür brauchst du denn 
überhaupt?

> Ich wäre für Tipps zur weiteren Umsetzung zum SPI Slave oder eben warum
> der Spartan 6 Probleme mit den anderen Designs haben könnte, sehr
> dankbar.
Wie schnell ist dein FPGA-Quarztakt?
Wie schnell ist dein SPI?

Als Tipp: sieh dir an, wie Mikrocontroller das machen. Da geht der SCLK 
nicht direkt auf den Takteingang eines Flipflops, sondern es wird eine 
Flankenerkennung darauf gemacht und dann das Datenbit übernommen.
So etwa:

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

4

entity ParalellToSerial is

5

6

generic( n : integer := 16);

7

      Port (   

8

          clk100MHz : in STD_LOGIC;

9

          sclk      : in std_logic;

10

          CS        : in std_logic;

11

          data_in   : in  STD_LOGIC_VECTOR (n-1 downto 0);

12

          data_out  : out STD_LOGIC_VECTOR (n-1 downto 0);

13

          MISO  :  out STD_LOGIC;

14

          MOSI  :  in STD_LOGIC

15

         );

16

end ParalellToSerial;

17

18

architecture Behavioral of ParalellToSerial is

19

        signal DST     : STD_LOGIC_VECTOR (n-1 downto 0):=(others=>'0');

20

        signal sclkSR  : STD_LOGIC_VECTOR (1 downto 0):=(others=>'0');

21

        signal sclkCS  : STD_LOGIC_VECTOR (1 downto 0):=(others=>'0');

22

begin

23

24

  process begin

25

     wait until rising_edge(clk100MHz);    -- der einzige Mastertakt für ALLES im ganzen FPGA!

26

     sclkSR  <= sclkSR(0) & sclk;

27

     sclkCS  <= sclkCS(0) & CS;

28

29

     if CS = '0' then

30

       if sclkSR="01" then                 -- steigende Flanke am SCLK

31

         DST  <= DST(n-2 downto 0) & MOSI; -- Daten ins SR einlesen

32

       end if;

33

     else

34

       if sclkSR="01" then                 -- steigende Flanke am CS

35

         data_out <= DST;                  -- Übertragung fertig: Daten übergeben

36

       end if;

37

       DST <= data_in;                     -- neue Daten übernehmen

38

     end if;

39

  end process;

40

41

  -- Ausgangstreiber für MISO umschalten

42

  data_out <= DST(n-1) when CS = '0' else 'Z';           

43

44

end Behavioral;

Christian R. schrieb:
> Sowas macht man indem man den SCLK einsychronisiert

Vielen Dank, kann ich beim einsynchronisieren der beiden Clocks vorgehen 
wie im Beispiel von Lothar Miller?

www.lothar-miller.de/s9y/categories/35-Einsynchronisieren

bit blaser schrieb:

> Das http://www.lothar-miller.de/s9y/categories/26-SPI-Slave ist zwar in
> VHDL allerdings für eine CPLD-Architektur und ohne Systemtakt.

Das Beispiel habe ich mir auch schon angeschaut aber ist eben für CPLD 
und ohne Systemtakt, genau. :-)

> Statt den SPI-clk alles mit dem FPGA-systemtakt erzeugen respektive
> abtakten.
> Hier in verilog: http://www.fpga4fun.com/SPI2.html

Werde ich mir anschauen, vielen Dank!

bit blaser schrieb:
> Das http://www.lothar-miller.de/s9y/categories/26-SPI-Slave ist zwar in
> VHDL allerdings für eine CPLD-Architektur und ohne Systemtakt.
Ich werde das nochmal ausdrücklich vermerken...

Lothar Miller schrieb:
> Andi P. schrieb:
>> process(reset,sclk, CS)
> Vorneweg: CS gehört hier nihct in die Sensitivliste.

Ahja, ok. könntest du mir das eventuell kurz erklären wieso nicht? Ich 
ging davon aus in der Sensitivliste die Signale stehen auf die auch 
reagiert werden soll?

>> Nach der ständig wiederholten Warnung:
>> (i.e. asynchronous reset with an initialization value of 1).
> Dann mach doch den asynchronen Reset raus. Wofür brauchst du denn
> überhaupt?

Du hast Recht nach der Übertragung ist das SR eh "leer" also mit 0 
besetzt.

>> Ich wäre für Tipps zur weiteren Umsetzung zum SPI Slave oder eben warum
>> der Spartan 6 Probleme mit den anderen Designs haben könnte, sehr
>> dankbar.
> Wie schnell ist dein FPGA-Quarztakt?
> Wie schnell ist dein SPI?

Meinen Takt den ich in mein System rein geben werde sind 40 MHZ oder 
auch mehr. Auf jedenfall wird dieser dann auf 400 MHZ erhöht durch eine 
PLL die mit vier phasenverschobenen Takten dann vier Zähler taktet. 
Bestimmte Zählerstände werden irgendwann ausgegeben und diese sollen 
dann eben "gebündelt" durch diesen SPI Slave auf ein 
Mikrocontroller(SPI) Interface übertragen werden.

Der Takt des SPI Interface ist 8 MHz.

>DST  <= DST(n-2 downto 0) & MOSI; -- Daten ins SR einlesen

Wahrscheinlich doofe Frage :-/: Kann MOSI nicht auch mit '0' ersetzt 
werden?

Andi P. schrieb:
> Meinen Takt den ich in mein System rein geben werde sind 40 MHZ oder
> auch mehr. Auf jedenfall wird dieser dann auf 400 MHZ

> Der Takt des SPI Interface ist 8 MHz.

Dann passt das ja locker mit der Abtastung.

Andi P. schrieb:
> Wahrscheinlich doofe Frage :-/: Kann MOSI nicht auch mit '0' ersetzt
> werden?

Klar, aber dann liest der Slave ja keine Daten mehr ein, sondern nur 0. 
Wo liegt da der Sinn? An MOSI (Master Out Slave In) kommen doch die 
Daten von deinem µC.

Andi P. schrieb:
> Wahrscheinlich doofe Frage :-/: Kann MOSI nicht auch mit '0' ersetzt
> werden?
Wenn der Master nichts zu senden und der Slave nichts zu empfangen hat, 
dann schon. Aber im Normalfall ist der eigentlich Vorteil ja der, dass 
mit jedem SCLK Takt ein Bit vom Master zum Slave und gleichzeitig ein 
Bit vom Slvae zum Master übertragen wird:
http://www.lothar-miller.de/s9y/archives/15-SPI.html

> Ahja, ok. könntest du mir das eventuell kurz erklären wieso nicht? Ich
> ging davon aus in der Sensitivliste die Signale stehen auf die auch
> reagiert werden soll?
Die Sensitivliste sagt dem Simulator, wann er den Prozess neu 
berechnen muss. Und er muss in deinem Fall den Prozess nur berechnen, 
wenn sich der Takt ändert. Denn wenn sich CS ändert und SCLK keine 
steigende Flanke hat, dann wird sich auch das Ergebnis des Prozesses 
nicht ändern.

Der Synthese ist die Sensitivliste eh' komplett schnuppe!

> Meinen Takt den ich in mein System rein geben werde sind 40 MHZ oder
> auch mehr. Auf jedenfall wird dieser dann auf 400 MHZ erhöht durch eine
> PLL die mit vier phasenverschobenen Takten dann vier Zähler taktet.
> Bestimmte Zählerstände werden irgendwann ausgegeben und diese sollen
> dann eben "gebündelt" durch diesen SPI Slave auf ein
> Mikrocontroller(SPI) Interface übertragen werden.
Dann nimm die 40MHz zum Abtasten der SPI Signale.
BTW: es wird sicher spannend, wie du die Zählerstände konsistent aus der 
400MHz-Domäne herausbekommst. Durch die Phasenverschiebung wird der 
virtuelle "Takt" sogar noch höher (oder andersrum: die Marge zur 
Übergabe an die 40MHz-Flipflops wird knapper). Dort musst du dir also 
auch noch irgendeinen Synchronisationsmechanismus ausdenken.

Christian R. schrieb :
> Andi P. schrieb:
>> Wahrscheinlich doofe Frage :-/: Kann MOSI nicht auch mit '0' ersetzt
>> werden?
>
> Klar, aber dann liest der Slave ja keine Daten mehr ein, sondern nur 0.
> Wo liegt da der Sinn? An MOSI (Master Out Slave In) kommen doch die
> Daten von deinem µC.

Wenn ich aber später über MOSI, Daten vom SPI Interface an den FPGA 
übergebe dann sollen die ja anders im FPGA verwendet werden und nicht in 
dieses Register eingelesen werden.

Lothar Miller schrieb:
>> Ahja, ok. könntest du mir das eventuell kurz erklären wieso nicht? Ich
>> ging davon aus in der Sensitivliste die Signale stehen auf die auch
>> reagiert werden soll?
> Die Sensitivliste sagt dem Simulator, wann er den Prozess neu
> berechnen muss. Und er muss in deinem Fall den Prozess nur berechnen,
> wenn sich der Takt ändert. Denn wenn sich CS ändert und SCLK keine
> steigende Flanke hat, dann wird sich auch das Ergebnis des Prozesses
> nicht ändern.
>
> Der Synthese ist die Sensitivliste eh' komplett schnuppe!

Sehr gute Erklärung! Vielen Dank. :-)

> BTW: es wird sicher spannend, wie du die Zählerstände konsistent aus der
> 400MHz-Domäne herausbekommst. Durch die Phasenverschiebung wird der
> virtuelle "Takt" sogar noch höher (oder andersrum: die Marge zur
> Übergabe an die 40MHz-Flipflops wird knapper). Dort musst du dir also
> auch noch irgendeinen Synchronisationsmechanismus ausdenken.

Alles klar, wird ich beachten.

Andi P. schrieb:
> Wenn ich aber später über MOSI, Daten vom SPI Interface an den FPGA
> übergebe dann sollen die ja anders im FPGA verwendet werden und nicht in
> dieses Register eingelesen werden.

Hm, das versteh ich jetzt nicht. SPI sind im einfachsten Fall 2 
gekoppelte Schieberegister. Eins im Master, eins im Slave. Beim Transfer 
werden die Inhalte der beiden Register ausgetauscht. Die Daten, die der 
Master (Bei der der µC) an das FPGA (den Slave) senden will, muss er aus 
seinem Schieberegister in das das Slave-Schieberegister schieben (über 
den MOSI), anders gehts nicht. Wenn der Transfer abgeschlossen ist, 
kannst du mit den parallelen Daten ja machen was du willst.
Will der Master was vom Slave lesen, muss der Slave die Daten in seinem 
Schieberegister bereitstellen und beim Transfer raus schieben. Bei jedem 
SPI Transfer wird vom Master sowieso das Register des Slave ausgelesen 
(über MISO).
Du musst also immer über die zwei Schieberegister gehen.

Andi P. schrieb:
> Wenn ich aber später über MOSI, Daten vom SPI Interface an den FPGA
> übergebe dann sollen die ja anders im FPGA verwendet werden und nicht in
> dieses Register eingelesen werden.
Machst du dann für jedes Register einen eigenen Slave-Select?

Christian R. schrieb:
> Hm, das versteh ich jetzt nicht. SPI sind im einfachsten Fall 2
> gekoppelte Schieberegister ...

Du hast Recht, da stand ich wohl auf dem Schlauch! -.- Ich glaub ich 
brauch erst mal ne Kaffeepause :-D.

Lothar Miller schrieb:
> Andi P. schrieb:
>> Wenn ich aber später über MOSI, Daten vom SPI Interface an den FPGA
>> übergebe dann sollen die ja anders im FPGA verwendet werden und nicht in
>> dieses Register eingelesen werden.
> Machst du dann für jedes Register einen eigenen Slave-Select?

Nein passt schon, ich war da durcheinander. Das Problem nagte nun schon 
zu lange an meinen Nerven. ;-) Danke euch!

Lothar Miller schrieb:
>

1

> library IEEE;

2

> use IEEE.STD_LOGIC_1164.ALL;

3

> 

4

> entity ParalellToSerial is

5

> 

6

> generic( n : integer := 16);

7

>       Port (

8

>           clk100MHz : in STD_LOGIC;

9

>           sclk      : in std_logic;

10

>           CS        : in std_logic;

11

>           data_in   : in  STD_LOGIC_VECTOR (n-1 downto 0);

12

>           data_out  : out STD_LOGIC_VECTOR (n-1 downto 0);

13

>           MISO  :  out STD_LOGIC;

14

>           MOSI  :  in STD_LOGIC

15

>          );

16

> end ParalellToSerial;

17

> 

18

> architecture Behavioral of ParalellToSerial is

19

>         signal DST     : STD_LOGIC_VECTOR (n-1 downto 0):=(others=>'0');

20

>         signal sclkSR  : STD_LOGIC_VECTOR (1 downto 0):=(others=>'0');

21

>         signal sclkCS  : STD_LOGIC_VECTOR (1 downto 0):=(others=>'0');

22

> begin

23

> 

24

>   process begin

25

>      wait until rising_edge(clk100MHz);    -- der einzige Mastertakt für 

26

> ALLES im ganzen FPGA!

27

>      sclkSR  <= sclkSR(0) & sclk;

28

>      sclkCS  <= sclkCS(0) & CS;

29

> 

30

>      if CS = '0' then

31

>        if sclkSR="01" then                 -- steigende Flanke am SCLK

32

>          DST  <= DST(n-2 downto 0) & MOSI; -- Daten ins SR einlesen

33

>        end if;

34

>      else

35

>        if sclkSR="01" then                 -- steigende Flanke am CS

36

>          data_out <= DST;                  -- Übertragung fertig: Daten 

37

> übergeben

38

>        end if;

39

>        DST <= data_in;                     -- neue Daten übernehmen

40

>      end if;

41

>   end process;

42

> 

43

>   -- Ausgangstreiber für MISO umschalten

44

>   data_out <= DST(n-1) when CS = '0' else 'Z';

45

> 

46

> end Behavioral;

47

>

Ich habe 2 Fragen zu der SPI-Slave Beschreibung:

1. wofür ist den sclkCS drin, das wird ja gar nicht weiter verwendet.

2. und wie kann ich mit
sclkSR  <= sclkSR(0) & sclk;
if sclkSR="01" then
...
eine steigende Flanke von SLK erkennen?

Danke
Thorsten

berndl schrieb:
> Thorsten F. schrieb:
>> 1. wofür ist den sclkCS drin, das wird ja gar nicht weiter verwendet.
> ich denke mal, da hat der Lothar einfach geschlampt! sclkCS ist das
> einsynchronisiert chip-select, er hat in der Abfrage aber das 'rohe'
> Eingangssignal verwendet. Sollte im Normalfall wurscht sein

hatte ich mir schon gedacht aber nicht gewagt zu äussern. ;)

>>
>> 2. und wie kann ich mit
>> sclkSR  <= sclkSR(0) & sclk;
>> if sclkSR="01" then
>> ...
>> eine steigende Flanke von SLK erkennen?
> Naja, wenn du die 'sclk' in deinen FPGA Takt einsynchronisierst
> (Schieberegister mit FPGA Takt), dann erkennst du in dem Schieberegister
> mit dem Pattern "01" eine steigende, mit dem Pattern "10" eine fallende
> Flanke von 'sckl' (halt mit etwas zeitlicher Verzoegerung)

Aber wie kann denn aus
sclkSR  <= sclkSR(0) & sclk;
"10" werden, sage ich nicht mit (0), dass der erste Wert eine 0 ist?
Es könnte noch "00" sein, aber dann könnte ich auch direkt sclk 
abfragen.

Ich frage mich halt wie ich bei meinem schnellen Takt sauber erkennen 
kann, jetzt hat sich was am sck von SPI getan und reagiere erst wieder 
beim nächten High werden vom sck.

Thorsten

berndl schrieb:

> Denkfehler! sclkSR ist ein Schieberegister mit 2 Bit. Schieberegister
> heisst, du hast einen Eingang am ersten FF (Bit 0), das wird in jedem
> Clock-Cycle mit sclk neu gesetzt. Gleichzeitig uebertraegst du den Wert
> von Bit 0 in das Bit 1 deines SR. In den beiden FFs des SR ist also der
> zeitverzoegerte Wert (gesampled mit deiner Clock) des Eingangssignals.
> Wenn du also in deinem SR eine Wertefolge "01" findest, dann heisst das,
> dass sich dein Eingangssignal in den letzten beiden Clockzyklen von 0
> auf 1 geaendert hat. Dito fuer alle anderen 2-Bit Kombinationen...

Danke berndl für die Erklärung.
Das bedeutet also slk ist 0, dann steht "00" im Schieber, wenn sclk dann 
von 0 auf 1 geht steht da "01" drin, dann bei den nächsten Systemtakten 
"11" bis sclk auf 0 geht und ein mal "10" drin steht um dann beim 
nächsten Systemtakt wieder "00" zu schieben.

Das ist ja einfach. ;)


Thorsten

Lothar Miller schrieb:
>

1

>      if CS = '0' then

2

>        if sclkSR="01" then                 -- steigende Flanke am SCLK

3

>          DST  <= DST(n-2 downto 0) & MOSI; -- Daten ins SR einlesen

4

>        end if;

5

>      else

6

>        if sclkSR="01" then                 -- steigende Flanke am CS

7

>          data_out <= DST;                  -- Übertragung fertig: Daten 

8

> übergeben

9

>        end if;

10

>        DST <= data_in;                     -- neue Daten übernehmen

11

>      end if;

12

>

dazu noch 2 Fragen.
"-- steigende Flanke am CS" müsste aber
"-- steigende Flanke am SCLK" heissen, oder?

und dann diese Zeile:
DST  <= DST(n-2 downto 0) & MOSI; -- Daten ins SR einlesen

da werden die "Slave in"-Daten ja in DST Schieber geladen. aber warum 
DST(n-2 downto 0), also warum n-2. Müsste es nicht auch in den ersten FF 
rein um die anderen Werte weiter zu schieben, also DST(0)?

Thorsten

Lothar Miller schrieb:

1

    if sclkSR="01" then                 -- steigende Flanke am CS

2

      data_out <= DST;                  -- Übertragung fertig: Daten übergeben

3

    end if;

4

    DST <= data_in;                     -- neue Daten übernehmen

Irgendwie ist diese Anweisung nicht zielführend. Zunächst müsste es doch

1

if sclkCS="01" then

heißen.

Die Zeile

1

 DST <= data_in;

 sollte in diesem Zusammenhang auch nicht genutzt werden. Würde ja 
bedeuten, dass data_in quasi direkt in data_out geschrieben würde. 
Lothar trifft bestimmt keine Schuld, dafür wird hier eindeutig zu viel 
VHDL code gepostet. Aber merkt das kein Anderer?

Bis auf diese zwei Zeilen ist der Code recht gut geeignet als SPI Slave, 
der wirklich nur Daten empfängt und parallel ausgibt. Allerdings habe 
ich nach Lothars Kunst die Eingangssignale durch zweimaliges Schieben 
einsynchronisiert. Die SPI Kommunikation ist mit 180 kHz recht langsam, 
da mir eine sichere Übertragung wichtiger ist als eine schnelle 
Übertragung. System-Clock ist 50Mhz.

>      if CS = '0' then
>        if sclkSR="01" then                 -- steigende Flanke am SCLK
>          DST  <= DST(n-2 downto 0) & MOSI; -- Daten ins SR einlesen
>        end if;
>      else
>        if sclkSR="01" then                 -- steigende Flanke am CS
>          data_out <= DST;                  -- Übertragung fertig: Daten
> übergeben
>        end if;
>        DST <= data_in;                     -- neue Daten übernehmen
>      end if;
>

Und vor allem sind die Kommentare nicht vollständig bzw sinnlos und 
unnötig.
Außerdem musst du COPY und PASTE üben.

sclkSR != sclkCS

Gruß Jonas

Jonas Biensack schrieb:
> sclkSR != sclkCS
Da habe ich mal wirklich saublöde Namen ausgedacht...  :-/

Sinnvollerweise heißen die Signale natürlich sclkSR und csSR, weil es 
jeweils Schieberegister (SR) zum Eintakten und für die Flankenerkennung 
sind. Und dann nenne ich das Daten-Schieberegister auch gleich noch dSR:

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

4

entity ParalellToSerial is

5

6

generic( n : integer := 16);

7

      Port (   

8

          clk100MHz : in STD_LOGIC;

9

          SCLK      : in std_logic;

10

          CS        : in std_logic;

11

          data_in   : in  STD_LOGIC_VECTOR (n-1 downto 0);

12

          data_out  : out STD_LOGIC_VECTOR (n-1 downto 0);

13

          MISO  :  out STD_LOGIC;

14

          MOSI  :  in STD_LOGIC

15

         );

16

end ParalellToSerial;

17

18

architecture Behavioral of ParalellToSerial is

19

        signal dSR     : STD_LOGIC_VECTOR (n-1 downto 0):=(others=>'0');

20

        signal sclkSR  : STD_LOGIC_VECTOR (1 downto 0):=(others=>'0');

21

        signal csSR    : STD_LOGIC_VECTOR (1 downto 0):=(others=>'0');

22

begin

23

24

  process begin

25

     wait until rising_edge(clk100MHz);    -- der einzige Mastertakt für ALLES im ganzen FPGA!

26

     sclkSR  <= sclkSR(0) & SCLK;          -- Eintakten der

27

     csSR    <= csSR(0) & CS;              -- asynchronen Signale

28

29

     if csSR(0)='0' then

30

       if sclkSR="01" then                 -- steigende Flanke am SCLK

31

         dSR  <= dSR(n-2 downto 0) & MOSI; -- Daten ins SR einlesen

32

       end if;

33

     else

34

       if csSR="01" then                   -- steigende Flanke am CS

35

         data_out <= dSR;                  -- Übertragung fertig: Daten übergeben

36

       end if;

37

       dSR <= data_in;                     -- neue Daten übernehmen

38

     end if;

39

  end process;

40

41

  -- unabhängig vom Takt: Ausgangstreiber für MISO umschalten

42

  data_out <= dSR(n-1) when CS = '0' else 'Z';           

43

44

end Behavioral;

Lothar Miller schrieb:
>

1

>        if csSR="01" then                   -- steigende Flanke am CS

2

>          data_out <= dSR;                  

3

>        end if;

4

>        dSR <= data_in;                     -- neue Daten übernehmen

5

>      end if;

6

> end Behavioral;

7

>

Eine Frage, wenn csSR 01 entspricht, dann wird data_in zu data_out 
direkt geschaltet oder nicht? Ich kann mir nicht vorstellen, dass es 
funktioniert. Tut es bei mir auch nicht.

data_out <= dSR;

gegen

dSR <= data_in;

Kann nicht gehen, weil die Übergabe mit CS ungeschickt gelöst ist. Also 
einen Schritt zurückgetreten und das Original nochmal angeschaut 
(Achtung: jetzt wirds rekursiv!):
http://www.lothar-miller.de/s9y/archives/32-Einfacher-SPI-Slave.html

Dann ein klein wenig nachgedacht (!!) und das Nötige geändert (es ist 
ja nur die Umstellung der direkten Flanken- und Pegelabhängigkeit auf 
synchrone eingetaktete Signale). Und heraus kommt dann das hier:

1

library IEEE;

2

use IEEE.STD_LOGIC_1164.ALL;

3

use IEEE.NUMERIC_STD.ALL;

4

5

entity SPI_Slave is

6

    Port ( clk    : in  STD_LOGIC;

7

           SSn    : in  STD_LOGIC;

8

           SCLK   : in  STD_LOGIC;

9

           MOSI   : in  STD_LOGIC;

10

           MISO   : out STD_LOGIC;

11

           Dout : out  STD_LOGIC_VECTOR (15 downto 0);

12

           Din  : in  STD_LOGIC_VECTOR (15 downto 0));

13

end SPI_Slave;

14

15

architecture Behavioral of SPI_Slave is

16

        signal dSR     : STD_LOGIC_VECTOR (15 downto 0):=(others=>'0');

17

        signal sclkSR  : STD_LOGIC_VECTOR (1 downto 0):=(others=>'0');

18

        signal ssSR    : STD_LOGIC_VECTOR (1 downto 0):=(others=>'0');

19

begin

20

21

  sclkSR  <= sclkSR(0) & SCLK when rising_edge(clk); -- Eintakten der

22

  ssSR    <= ssSR(0) & SSn    when rising_edge(clk); -- asynchronen Signale

23

24

  -- Parallel-Eingänge --> MISO

25

  process begin

26

     wait until rising_edge(clk);

27

     if (ssSR="11") then                        -- solange deselektiert: immer Daten vom Din übernehmen

28

        dsr <= Din;

29

     elsif (sclkSR="01") then                   -- mit der steigenden SCLK-Flanke 

30

        dsr <= dsr(dsr'left-1 downto 0) & MOSI; -- wird MOSI eingetaktet

31

     end if;

32

  end process;

33

34

  MISO <= dsr(dsr'left) when SSn='0' else 'Z';  -- Richtungsteuerung MISO direkt über SSn

35

36

  -- Parallel-Ausgänge übernehmen mit steigender SS-Flanke 

37

  process begin

38

     wait until rising_edge(clk);

39

     if (ssSR="01") then    -- steigende Flanke am SS: Device wird deselektiert

40

        Dout <= dsr;        -- Ausgangssignale an Dout ausgeben

41

     end if;

42

  end process;

43

44

end Behavioral;

Das war ja einfach...

Und zusammen mit der Testbench im Anhang kommt dann die Waveform im 
Anhang raus. Voila, funktioniert tadellos (etwas verwirrend ist evtl. 
dass sich nach der letzten steigenden Flanke nochmal der Pegel vom MISO 
ändert, aber das passt schon und ist dem Geiz zuverdanken: es wird nur 1 
Schieberegister für Senden und Empfang verwendet).

chris schrieb:
> Warum die Simulation nicht?
In der Waveform der Simulation meines Codes im 
Beitrag "Re: Erfahrung mit SPI Slave und Spartan 6 FPGA?" ändert sich das 
MISO doch wie erwartet mit der steigenden Taktflanke...


Und die Simulation von ElKo zeigt doch genau das Verhalten, das dein 
Code im Beitrag "Re: Erfahrung mit SPI Slave und Spartan 6 FPGA?" mit

1

   if ( sclkSR="10" ) then -- mit der fallenden Flanke an MISO ausgeben

2

    misoLoc <= dsr(dsr'left);

3

   end if;

4

  end process;

5

6

  --MISO <= dsr(dsr'left) when SSn='0' else 'Z';  -- Richtungsteuerung MISO direkt über SSn

7

  MISO <= misoLoc when SSn='0' else 'Z';  -- Richtungsteuerung MISO direkt über SSn

beschreibt.

Soweit also alles im grünen Bereich...


> Meine Messung zeigt das
Dank den nicht dargestellten "Mastertaktes" könnte sein, dass die zwei 
Takte Verzögerung durch das Flankenschieberegister dazu führen, dass der 
Wechsel erst zusammen mit der nächsten Taktflanke stattfindet. Aber eben 
nicht wegen dieser Taktflanke!

Wie schon gefragt: welche FPGA-Takt- und SCLK-Takt-Frequenzen hast du?

ElKo schrieb:
> Eine Variante ist es, auf die fallende Flanke zu schreiben.
Das ist die "reine Lehre", die aber nur von sehr wenigen SPI-Devices 
tatsächlich eingehalten wird. Denn dadurch "verschenkt" man quasi die 
halbe Taktfrequenz, weil ja für die Setup-Zeit nur die halbe Bitzeit 
übrig bleibt.

> Eine andere (Lothars) Variante ist, das neue Bit direkt nach
> der steigenden Flanke zu schreiben.
Das ist quasi die "Schieberegister" Variante.
Und auf solchen "verketteten" Schieberegistern basiert ja der SPI(*): 
Daten liegen an und werden mit der nächsten aktiven (= entweder steigend 
oder fallend) Taktflanke weitergeschoben. Sie müssen (wie üblich) 
rechtzeitig vor der nächsten aktiven Taktflanke stabil am nächsten 
Flipflop sein.

(*) siehe http://www.lothar-miller.de/s9y/archives/15-SPI.html

Das hat man jetzt vom Herauskramen alter Threads...  :-/
Der aktuelle beginnt erst beim 
Beitrag "Re: Erfahrung mit SPI Slave und Spartan 6 FPGA?"

Weltbester FPGA-Pongo schrieb im Beitrag #5196420:
> dann gehört es durchaus da rein
In diese (drei Jahre alte) Sensitivliste aber eben nicht.
Wenn mich bei reinstem Sonnenschein einer fragt: "wie ist das Wetter?" 
dann sage ich ja auch "die Sonne scheint!" und nicht "die Sonne scheint, 
es hätte aber genausogut regnen können, wenn die Wetterlage entsprechend 
wäre"...  ;-)