Prozess Problem, ausgabe FPGA entspricht nicht der Simulation

[fragender (Gast)]

Hallo erst mal mein coder:

STATE: process(SYS_CLK)
begin
  if SYS_CLK'event and SYS_CLK = '0' then
    if M_CS='0' then --cs ist nicht da!
      
    else --cs aktive es geht los  
      S_MCLK_OLD <= M_CLK;
      if S_MCLK_OLD /= M_CLK and M_CLK='0' then
        M_TMP <= MOSI;
        if S_BIT_CNT = 0 then
          RX_FINISH <= '1';
          S_BIT_CNT <= BIT_LAENGE-1;
        else
          S_BIT_CNT <= S_BIT_CNT-1;
          RX_FINISH <= '0';
        end if;
      else
        
      end if;
    end if;
  end if;
end process STATE;

SYS_CLK ist mein Systemclk 150 MHz
M_CLK ist mein SPI CLK 8 MHz vom Master
M_CS das Chipselect von Master.
BIT_LAENGE ist 8.

Ich warte auf eine steigende Flanke  vom SYS_CLK.
Danach warte ich einen Flankenwechsel von Masterclk.
Dann schreibe ich die Daten vom Master auf ein TMP regester.
RX_FINISH dient hier nur als Test und gibt zurück wenn S_BIT_CNT null 
erreicht hat.

Ok nun zu meinem Problem. Das ganze ist mega instabil. Ohne die innere 
if schleife sehe ich an M_TMP die Daten vom Master. Mit der inneren 
schleife wird alles instabil weder RX_FINISH zeigt das ende des zählen 
an und der M_TMP macht nur Schwachsinn.
Wenn ich das Ding Simuliere , sieht alles so aus wie ich es mit gedacht 
habe.

Daher bitte helft mir.

Danke.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

fragender schrieb:
> Ich warte auf eine steigende Flanke  vom SYS_CLK
Das tust nur du. Aber dein FPGA wartet da auf gar nichts, sondern die 
beteiligten Flipflops übernehmen einfach mit der entsprechenden 
Taktflanke ihre Eingangsdaten auf ihre Ausgänge. Die Ursache  des 
Problems ist also einfach: du denkst in Software, wo alles hübsch 
nacheinander passiert.

> Ohne die innere if schleife
Es gibt keine if-Schleifen...

Das eigentliche Problem bei diesem Design ist ein klassischer 
Anfängerfehler: asynchrone Eingänge. Hier gleich 3 davon: der M_CS, der 
M_CLK und auch MOSI. Da passiert dann sowas:
http://www.lothar-miller.de/s9y/categories/35-Einsynchronisieren

[fragender (Gast)]

Hi danke für deine Antwort. Ich denke auch das ich noch zu nah an der c 
Programmierung bin. Ober das Problem haben sicher viele :) danke für den 
Hinweis du hast natürlich recht das es sich um eine Anweisung und nicht 
um eine Schleife handelt.
Ich versuche mal deine Beschreibung auf mein Problem anzuwenden. Hätte 
zwar nie gedacht das es bei den Frequenzen schon Probleme gibt. Aber wie 
in deinem Artikel beschrieben wird hier das Hauptproblem beim den 
eingang master CLK liegen.

Vielen dank

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

fragender schrieb:
> Hätte zwar nie gedacht das es bei den Frequenzen schon Probleme gibt
Für "das Problem" reichen 2 Flipflops, 1 Taktflanke, und 1 Signal. Der 
Takt kann also beliebig langsam sein. Es tritt dann nur nicht "so 
häufig"  auf...

[J. S. (engineer)]

Die "Clocks" sind hier nicht so  das Problem, weil sie keine FFs 
erzeugen. Allerdings sollte man sich dennoch lieber von dem "Warten" 
verabschieden.

Du hast es dennoch - Zufall oder nicht - fast richtig gemacht. 
Allerdings:

fragender schrieb:
> Danach warte ich einen Flankenwechsel von Masterclk.
Nein, Du "wartest" auf die fallende Flanke. Du muss entweder den neueren 
Wert auf 1 oder den alten auf 0 abprüfen.

Sauber und sicher schreibt man das lieber ausdrücklich hin:

if (sig_m_clk_new = 1) and (sig_m_clk_old= 0) then

Eine kleine Frage: Wie willst Du eigentlich die Bits einsammeln?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

fragender schrieb:
> Ich warte auf eine steigende Flanke  vom SYS_CLK.

> if SYS_CLK'event and SYS_CLK = '0' then

Sieht aber eher nach fallend aus

[T. K. (tntbc)]

Hallo ich habe mich mal eingeloggt fragender(ICH),

ich danke euch für eure  super Beiträge. Ich habe jetzt den code 
geändert und eure Vorschläge eingearbeitet.

Lothar M. schrieb:
>> Hätte zwar nie gedacht das es bei den Frequenzen schon Probleme gibt
> Für "das Problem" reichen 2 Flipflops, 1 Taktflanke, und 1 Signal. Der
> Takt kann also beliebig langsam sein. Es tritt dann nur nicht "so
> häufig"  auf...

Ich habe jetzt diesen process vorab erzeugt der die Signale einsynct:

SYNC: process
begin
wait until rising_edge(SYS_CLK);
  S_CLK_SYNC <= S_CLK_SYNC(0) & M_CLK;
  S_MISO_SYNC <= S_MISO_SYNC(0) & MOSI;
  S_CS_SYNC <= S_CS_SYNC(0) & M_CS;
end process SYNC;

damit ist das Problem in der tat weg :/ Aber eine frage dazu:
Muss ich das ebenfalls mit Signalen zwischen Architekturen machen? In 
deinem Artikel steht alles unter 200 Mhz ist unkritisch.

Jürgen S. schrieb:
> Nein, Du "wartest" auf die fallende Flanke. Du muss entweder den neueren

Richtig! Ich habe auch deine Vorschlag eingearbeitet.



Jürgen S. schrieb:
> Eine kleine Frage: Wie willst Du eigentlich die Bits einsammeln?

JA will ich :) aber ein schritt nach dem anderen
der process sieht jetzt so aus:

STATE: process
begin
  wait until rising_edge(SYS_CLK);
    S_MCLK_OLD <= S_CLK_SYNC(1);
    if S_CS_SYNC(1)='0' then --cs ist nicht da!
      S_BIT_CNT <= BIT_LAENGE-1;
    else --cs aktive es geht los  
      if (S_MCLK_OLD = '1') and (S_CLK_SYNC(1)='0') then --fallende Flanke wird gesucht!
        S_RXDATEN <= S_RXDATEN(BIT_LAENGE-2 downto 0) & S_MISO_SYNC(1);
        M_TMP <= S_MISO_SYNC(1);
        if S_BIT_CNT = 0 then 
          RX_FINISH <= '1';
          S_BIT_CNT <= BIT_LAENGE-1;
        else
          S_BIT_CNT <= S_BIT_CNT-1;
          RX_FINISH <= '0';
        end if;
      else
        
      end if;
    end if;
end process STATE;

jetzt sehe ich auf dem oszi keine fehler mehr!

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

T. K. schrieb:
> damit ist das Problem in der tat weg
War ja einfach...

> Muss ich das ebenfalls mit Signalen zwischen Architekturen machen? In
> deinem Artikel steht alles unter 200 Mhz ist unkritisch.
Nicht ganz richtig. Dort steht, dass bis 200Mhz Metastabilität kein 
Problem machen wird. Deshalb reicht dort zum Synchronisieren 1Flipflop 
aus.

Du musst das Einsynchronisieren aber immer überall dort machen, wo du 
Taktdomänen überbrückst. Also auf jeden Fall bei externen Signalen, die 
asynchron zum FPGA Takt sind. Das sind z.B. immer irgendwelche Taster 
oder Sensoren.

[T. K. (tntbc)]

Hallo Lothar,

Lothar M. schrieb:
> Problem machen wird. Deshalb reicht dort zum Synchronisieren 1Flipflop
> aus.

Ok das bedeutet also wenn ich das richtig verstehe. Ich benötige kein 
Schieberegister. Jedoch ist ein process wo die Eingänge mit der SYSCLK 
sync auf Architektur Signal gemapt werden nicht schlecht? Siehe Code:

entity bla is
port(
CLK: in std_logic;
hallo: in std_logic;
);
end bla;

architecture VERHALTEN of bla is
signal S_HALLO_SYNC: std_logic := '0';
begin


SYNC: process
wait until rising_edge(CLK);
S_HALLO_SYNC <= hallo;
end VERHALTEN;


MAIN: process
begin
 wait until rising_edge(CLK);
 if S_HALLO_SYNC = '0' then
..

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

T. K. schrieb:
> Jedoch ist ein process wo die Eingänge mit der SYSCLK sync auf
> Architektur Signal gemapt werden nicht schlecht?
Nein was soll daran "schlecht" sein?

Die Fragenstellung an sich deutet allerdings darauf hin, dass du immer 
noch "programmierst"...

Der richtige Ansatz wäre aber, zu sehen, dass da 1 Flipflop nötig ist. 
Und ab hier gibt es mehrere Wege, so ein Ding zu beschreiben. Einen 
davon hast du verwendet, man könnte auch ohne Prozess so schreiben:
S_HALLO_SYNC <= hallo when rising_edge(clk);

Oder du machst das einfach mit im MAIN Prozess:

MAIN: process
begin
  wait until rising_edge(CLK);
  S_HALLO_SYNC <= hallo
  if S_HALLO_SYNC = '0' then
    ...

[T. K. (tntbc)]

Lothar M. schrieb:
> Nein was soll daran "schlecht" sein?

Ok das war auch so gemeint das es nicht schlecht sein kann das zu 
machen.

Vielen dank an alle 16Mbit/s gehen jetzt ohne Probleme. Sich jedoch von 
der Programmierwelt zu verabschieden und in anderen Dimensionen zu denke 
fällt noch etwas schwer.  :)

[Weltbester FPGA-Pongo (Gast)]

T. K. schrieb:
> Sich jedoch von der Programmierwelt zu verabschieden
Musst du gar nicht, du musst eine Dimension ignorieren, nämlich die Zeit 
und damit die Position eines Befehls.