simpler SPI Slave Problem

Frage: wo kommt dein Reset her? Ist er einsyncronisiert?
Beitrag "Re: Reset für mehrere Komponenten"

>    process(CLK, RESET)
>
>  variable sck_act, sck_prev, sck_prev_2, sck_prev_3: std_logic := '0';
>  variable cycle_count: natural range 0 to 7;
>  variable start_transmission: std_logic := '0';
>
>  begin
>
>      if RESET = '0' then
>
>        MISO <= '0';
>      TEST_DATA <= "01101001";
>
>      cycle_count := 0;

Hallo!

Reset kommt von einem Button auf dem Board und ist asynchron.

Thomas Reinemann schrieb:
> Achso, ein synchrones Design braucht keine *Timing*-Simulation.

Das wiederum halte ich fuer eine gewagte These...

Lothar Miller schrieb:
> Warum diese überaus ausgiebige Verwendung von Variablen?

Das duerfte dann auch wohl fuer die Probleme sorgen, vor allem 
folgendes:

1

sck_act := SCK;

2

if sck_prev_3='1' and sck_prev_2='1' and sck_prev='0' and sck_act='0' then

Mit 'sck_act' bist du hier nicht am FF-Ausgang, sondern du verwendest 
den FF-Eingang (da variable)! Viel Spass mit Setup-Violations. Mach' das 
ganze mal mit signal und am besten noch mit einem std_logic_vector (x 
downto 0) und synchronisiere mit

1

sck_sr <= sck_sr (x-1 downto 0) & SCK

ein.

Lothar Miller schrieb:
> Ist dir eigentlich klar, dass SPI nur gekoppelte Schieberegister sind?
> Dass da also kein Zähler und kein Multipexer drin vorkommt?

PS: Es kommt haeufig vor, dass man mit den seriellen Daten auf dem MOSI 
irgendwas dekodieren muss; also der MISO stream muss dynamisch aufgebaut 
werden. Dann geht es mit 'dummem' Schieberegister nicht mehr. Ist hier 
zwar Overkill, aber nicht grundsaetzlich falsch oder ungewoehnlich

Achja, und selbst wenn du diese Zeile:

1

if sck_prev_3='1' and sck_prev_2='1' and sck_prev='0' and sck_act='0' then

mit einem signal und Schieberegister machst, also z.B.:

1

sck_sr <= sck_sr (2 downto 0) & SCK;

2

if sck_sr = b"1100" then ...

dann kannst du dir boese Probleme einfangen. Warum: Du kommst von einem 
stabilen SCK und willst einen Flankenwechsel detektieren (das steht da 
oben). Wenn du jetzt aber Stoerungen (z.B. Ringing durch falsche 
Impedanzanpassung) hast, dann koennte dein SR auch den Wert b"1101" 
haben (ein Spike auf SCK). Ich frage beim SR immer so ab, dass ich das 
geaenderte Signal nur in einem FF habe, also z.B.:

1

if sck_sr (3 downto 1) = b"110"

 oder auch

1

if sck_sr (3 downto 0) = b"1110"

Du bist dann weniger empfindlich ggue. Spikes...

berndl schrieb:
> Thomas Reinemann schrieb:
>> Achso, ein synchrones Design braucht keine *Timing*-Simulation.
>
> Das wiederum halte ich fuer eine gewagte These...

Nein ist nicht gewagt. Für synchrone Designs braucht man in 99,9% der 
Fälle eine *Verhaltens*-simulation und eine statische Timinganalyse.

Klaus schrieb:
>>> Achso, ein synchrones Design braucht keine *Timing*-Simulation.
>>
>> Das wiederum halte ich fuer eine gewagte These...
>
> Nein ist nicht gewagt. Für synchrone Designs braucht man in 99,9% der
> Fälle eine *Verhaltens*-simulation und eine statische Timinganalyse.

ups, das hatte ich oben falsch gelesen/interpretiert/getraeumt, sorry 
Thomas+Klaus. Ihr habt natuerlich recht.