Nicht-Spezifische Latch-Warnung

[engineer_on_tour (Gast)]

Hallo zusammen,

ich arbeite mit einem XILINX Spartan 6 und bekommen bei einem scheinbar 
einfachen STateMachine-Code eine Warnung, dessen grund und Ursache ich 
nicht finden kann.

Die Warnung lautet:

Xst:3002 - This design contains one or more registers/latches that are 
directly
   incompatible with the Spartan6 architecture. The two primary causes 
of this is
   either a register or latch described with both an asynchronous set 
and
   asynchronous reset, or a register or latch described with an 
asynchronous
   set or reset which however has an initialization value of the 
opposite
   polarity (i.e. asynchronous reset with an initialization value of 1).


Könnt ihr euch einen Reim auf die Warnung machen und/oder mir sagen, was 
ich anders machen sollte?

(eine Reset aller:
if reset = '1' then
 state <= PART_1;
elsif (rising_edge(in_SPI_CS)) then ...

brings nicht)




Der entsprechende VHDL-Auszug lautet:

type   int_t_AllStates is (PART_1,PART_2_READ,PART_2_WRITE);
signal int_s_CurrentState: int_t_AllStates;


STATEMACHINE:process(in_SPI_CS)
begin
  if rising_edge(in_SPI_CS) then 
  
    case int_s_CurrentState is
    
      when PART_1 =>
        if int_DataRX = x"0060" then
          int_s_CurrentState <= PART_2_READ;
        else
          int_s_CurrentState <= PART_2_WRITE;
        end if;
      when PART_2_READ =>
        int_s_CurrentState <= PART_1;
      when PART_2_WRITE =>
        int_s_CurrentState <= PART_1;
      when OTHERS =>
        int_s_CurrentState <= PART_1;
    end case;
    
  end if;    
end process;

SIGNALMANIPULATION:process (int_s_CurrentState,i_FIFO_DataOut)
begin  
  case int_s_CurrentState is
  
    when PART_1 =>
      int_SlaveOut <= x"1234";
    when PART_2_READ =>
      int_SlaveOut <= i_FIFO_DataOut;
    when PART_2_WRITE =>
      int_SlaveOut <= x"5678";
    when OTHERS =>
      int_SlaveOut <= x"0000";      
  end case;
end process;

[Joe (Gast)]

Versuch mal

SIGNALMANIPULATION:process (int_s_CurrentState,i_FIFO_DataOut)
begin
  int_SlaveOut <= x"0000";

  case int_s_CurrentState is
    when PART_1 =>
      int_SlaveOut <= x"1234";
    when PART_2_READ =>
      int_SlaveOut <= i_FIFO_DataOut;
    when PART_2_WRITE =>
      int_SlaveOut <= x"5678";     
  end case;
end process;

Joe

[engineer_on_tour (Gast)]

Hi Joe,

das hat leider keine Änderung gebracht :(

[abcd (Gast)]

Ich hab keine Ahnung von VHDL, nur Verilog, also haut mich bitte nicht 
:-)

Der Prozess "SIGNALMANIPULATION" ist doch kombinatorisch. D.h. alle 
signale die sich ändern müssen in die Sensitivity list, sonst wirds ein 
latch.

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

engineer_on_tour schrieb:
> rising_edge(in_SPI_CS)
Sorgenfalten machen sich auf der Stirn breit...
Wieviele Takte hast du? Wie synchronisiertst du die Übergänge?

> bekommen bei einem scheinbar einfachen STateMachine-Code eine Warnung,
> dessen grund und Ursache ich nicht finden kann.
Ich vermute stark, der Fehler liegt ausserhalb des geposteten 
Codeausschnittes...

> or a register or latch described with an asynchronous set or reset
> which however has an initialization value of the opposite polarity
> (i.e. asynchronous reset with an initialization value of 1).
> Könnt ihr euch einen Reim auf die Warnung machen...?
Das ist sowas:

   signal s : std_logic := '1';

   if reset='1' then
      s <= '0';
   else
      :
      :
   end if;

abcd schrieb:
> Der Prozess "SIGNALMANIPULATION" ist doch kombinatorisch. D.h. alle
> signale die sich ändern müssen in die Sensitivity list, sonst wirds ein
> latch.
Falsch.
In die Sensitivliste müssen alle die Signale, die eine Änderung eines 
andere Wertes bewirken. Dann berechnet der Simulator bei einer 
Änderung des Wertes in der Sensitivliste die Ergebnisse des Prozesses 
neu.
Der Synthese (die oben die Warnung erzeugt) schert sich einen feuchten 
Kehrricht um eine unvollständige Sensitivliste. Sie erweitert diese 
Leiste einfach eigenständig.
Mit der Sensitivliste kann also das Verhalten des FPGAs in keiner Weise 
gesteuert werden.

[user (Gast)]

ich würde mal das Signal i_FIFO_DataOut genauers anschauen

das wird aufjedenfall hier zugewiesen

 when PART_2_READ =>
      int_SlaveOut <= i_FIFO_DataOut;

[engineer_on_tour (Gast)]

user schrieb:
> ich würde mal das Signal i_FIFO_DataOut genauers anschauen
>
> das wird aufjedenfall hier zugewiesen
>
>  when PART_2_READ =>
>       int_SlaveOut <= i_FIFO_DataOut;

Wird diese Zuweisung nicht verwendet, tritt die Wranung dennoch auf.



Lothar Miller schrieb:
> Ich vermute stark, der Fehler liegt ausserhalb des geposteten
> Codeausschnittes...

Dann poste ich einfach mal den gesamten Code. Es handelt sich um eine 
Erweiterung einer funtionierenden SPI-Slave-Instanz. Diese soll immer 
mit zwei Nachrichten (Befehl + Daten) oder (Anfrage + Antwort) 
angesprochen werden und je nach Befehl/Anfrage reagieren. Daher wird 
nach dem ersten empfangenen Datenpaket getestet:

if int_DataRX = x"0060" then
          int_s_CurrentState <= PART_2_READ;
        else
          int_s_CurrentState <= PART_2_WRITE;

Der komplette Code hier:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;



entity cSPI is
  port
  (
    in_SPI_Clock            :   in    STD_LOGIC;
    in_SPI_Mosi              :   in   STD_LOGIC;
    out_SPI_Miso            :   out  STD_LOGIC;
    in_SPI_Cs              :   in   STD_LOGIC;  
    
    i_FIFO_DataOut            :   in    STD_LOGIC_VECTOR (16-1 downto 0);    
      
    o_SPI_ReceivedData        :   out  STD_LOGIC_VECTOR (16-1 downto 0);
    o_SPI_Wr_Clk            :   out   STD_LOGIC;    
    o_SPI_Rr_Clk            :   out   STD_LOGIC  
  );
end cSPI;




architecture VERHALTEN of cSPI is
----------------------------------
signal int_DataRx   : STD_LOGIC_VECTOR (16-1 downto 0); 
signal int_DataTx   : STD_LOGIC_VECTOR (16-1 downto 0);
signal int_SlaveOut   : STD_LOGIC_VECTOR (16-1 downto 0);



type   int_t_AllStates     is   (    
                          PART_1,                          
                          PART_2_READ,                          
                          PART_2_WRITE
                      );
signal int_s_CurrentState      :     int_t_AllStates:=PART_1;


----------------------------------
begin
-----------------------------------------------------------------------------
RX:process(in_SPI_Clock,in_SPI_CS)
begin
  if falling_edge(in_SPI_Clock) then                  
    if (in_SPI_CS = '0') then                  
      int_DataRx <= int_DataRx(16-2 downto 0) & in_SPI_MOSI;
    end if;
  end if;
end process;
-----------------------------------------------------------------------------
TX:process(in_SPI_CS, in_SPI_Clock,int_SlaveOut)   
begin
  if (in_SPI_CS='1') then
    int_DataTx <= int_SlaveOut;
  elsif rising_edge(in_SPI_Clock) then                  
    int_DataTx <= int_DataTx(16-2 downto 0) & '0';
  end if;
end process;
-----------------------------------------------------------------------------
out_SPI_Miso <= int_DataTx(15) when in_SPI_Cs='0' else 'Z';  
-----------------------------------------------------------------------------
RXCS:process(in_SPI_CS)
begin
  if rising_edge(in_SPI_CS) then 
    o_SPI_ReceivedData <= int_DataRX;    
  end if;
end process;
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
STATEMACHINE:process(in_SPI_CS)
begin
  if rising_edge(in_SPI_CS) then

    case int_s_CurrentState is

      when PART_1 =>
        if int_DataRX = x"0060" then
          int_s_CurrentState <= PART_2_READ;
        else
          int_s_CurrentState <= PART_2_WRITE;
        end if;
      when PART_2_READ =>
        int_s_CurrentState <= PART_1;
      when PART_2_WRITE =>
        int_s_CurrentState <= PART_1;
      when OTHERS =>
        int_s_CurrentState <= PART_1;
    end case;

  end if;
end process;
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
SIGNALMANIPULATION:process (int_s_CurrentState,i_FIFO_DataOut)
begin

  case int_s_CurrentState is
    when PART_1 =>
      int_SlaveOut <= x"1234";
    when PART_2_READ =>
      int_SlaveOut <= i_FIFO_DataOut;
    when PART_2_WRITE =>
      int_SlaveOut <= x"5678"; 
   when OTHERS =>
    int_SlaveOut <= x"FFFF";     
  end case;
end process;

-------------------------------------------------------------------------------

o_SPI_Wr_Clk <= in_SPI_Cs; 

o_SPI_Rr_Clk <= in_SPI_Cs when int_s_CurrentState=PART_2_READ else '1'; 

end VERHALTEN;

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

engineer_on_tour schrieb:
> Dann poste ich einfach mal den gesamten Code.

Wichtige Regeln - erst lesen, dann posten!
    Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Seis drum...

> when PART_2_READ =>
>   int_SlaveOut <= i_FIFO_DataOut;
> Wird diese Zuweisung nicht verwendet, tritt die Wranung dennoch auf.
Weil int_SalveOut verwendet wird. Ich hab ihn:

  if (in_SPI_CS='1') then
    int_DataTx <= int_SlaveOut;
  elsif rising_edge(in_SPI_Clock) then                  
    :

Ein nicht konstanter Resetwert. Sowas ist mit den Flipflops in einem 
FPGA nicht möglich...

[engineer_on_tour (Gast)]

Lothar Miller schrieb:
> Wichtige Regeln - erst lesen, dann posten!
>     Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Aso, dann weiß ich für die Zukunft bescheid :)

Lothar Miller schrieb:
> Weil int_SalveOut verwendet wird. ... Ein nicht konstanter Resetwert.

Verstehe ich das richtig (leider habe ich nicht die Zeit, in aller ruhe 
VHDL zu lernen und muss es "leaning by doing" im Schnellverfahren 
lernen), dass sich der Wert int_SlaveOut theoretisch während des 
TX-Prozesses veränden kann und so zu diesem Fehler führt?

Anders gefragt: Wie kann ich es realisieren, dass je nach Zustand ein 
anderer Wert über den MISO-Kanal gesendet wird?

[Fpgakuechle K. (Gast)]

engineer_on_tour schrieb:
> Lothar Miller schrieb:
>> Wichtige Regeln - erst lesen, dann posten!
>>     Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
>
> Aso, dann weiß ich für die Zukunft bescheid :)
>
> Lothar Miller schrieb:
>> Weil int_SalveOut verwendet wird. ... Ein nicht konstanter Resetwert.
>
> Verstehe ich das richtig (leider habe ich nicht die Zeit, in aller ruhe
> VHDL zu lernen und muss es "leaning by doing" im Schnellverfahren
> lernen), dass sich der Wert int_SlaveOut theoretisch während des
> TX-Prozesses veränden kann und so zu diesem Fehler führt?

In Hardware denken bitte!

Die Fehlermeldung besagt, das kein Flipflop beschrieben wurde sondern 
ein Latch.
Verkürzt dargestellt
Ein FF hat einen D- Eingang , dessen wert wird beim Eintreffen der 
taktflanke ( rising_edge() abgespeichert und an FF-Ausgang Q 
wiedergegeben.

IN VHDL beschrieben sieht das (verkürzt) so aus

 if rising_edge(clk) then
  Q <= D;

Daneben hat es noch RESET/SET- Eingänge, die bewirken das unabhängig von 
D die Speicherzelle auf '0' (when RESET Eingang aktiv) oder auf '1' 
(when SET eingang aktiv) gesetzt wird.
in VHDL sieht das so aus:

IF    R = '1' then Q <= '0' ;
elsif S = '1' then Q <= '1';
end if;

was du dagegen beschreibst ist kein FF (flankensensitiv) sondern ein 
Latch (zustandsgesteuert) deswegen warnt dich die Synthese.
Willst du ein Latch oder ein Flipflop hier?

MfG,

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

engineer_on_tour schrieb:
> dass sich der Wert int_SlaveOut theoretisch während des TX-Prozesses
> veränden kann und so zu diesem Fehler führt?
Nein, es liegt primär daran, dass es keinen "Load"-Eingang an einem 
FPGA-Flipflop gibt.

> Anders gefragt: Wie kann ich es realisieren, dass je nach Zustand ein
> anderer Wert über den MISO-Kanal gesendet wird?
Entweder baust du das gesamte Design auf eine synchrone Datenübertragung 
um oder du akzeptierst diese "Unsauberkeit" an dieser Stelle. Du weißt 
ja, woher der Fehler kommt...

engineer_on_tour schrieb:
> eine Erweiterung einer funtionierenden SPI-Slave-Instanz.
Schön, dass die funktioniert, die kommt mir bekannt vor...   ;-)
Und was wurde erweitert? Trat vor der Erweiterung diese Warnung nicht 
auf? Was war da anders?

[engineer_on_tour (Gast)]

Hallo Lothar,

ich habe einen Workaround gefunden und denken, damit jetzt weiter 
arbeiten zu können.

Den problematischen Teil

 case int_s_CurrentState is
    when PART_1 =>
      int_SlaveOut <= x"1234";
    when PART_2_READ =>
      int_SlaveOut <= i_FIFO_DataOut;
    when PART_2_WRITE =>
      int_SlaveOut <= x"5678";
   when OTHERS =>
    int_SlaveOut <= x"FFFF";
  end case;
end process;


lasse ich vorläufig weg und werde diesen eventuell später anderweitig 
implementieren (zumindest versuche ich es). Aber da das nicht Prio 1 ist 
mache ich erst mal mit anderen Dingen weiter.

In jedem fall vielen Dank für deine Hilfe! ... So konnte ich schnell 
erkennen, was der Fehler ist und mich für ein weiteres Vorgehen 
entscheiden.

[engineer_on_tour (Gast)]

Hallo zusammen,

ich konnte das Problem nun auf die eigentliche SPI eingrenzen, die ein 
Problem hat, sobald die zu senden Daten (i_TxData) nicht mehr konstant 
sind (sondern sich je nach empfangenen Daten oder Zustand ändern 
sollen).

TX:process(in_CLK)--,i_TxData,in_CS)
begin
  if (in_CS='1') then
    int_DataTx <= i_TxData;
  elsif rising_edge(in_CLK) then
    int_DataTx <= int_DataTx(16-2 downto 0) & '0';
  end if;
end process;

Jetzt mache ich mich endweder auf die Suche nach einer anedren 
SPI-Implementierung oder muss selber eine schreiben.

[Fpgakuechle K. (Gast)]

engineer_on_tour schrieb:
> Hallo zusammen,
>
> ich konnte das Problem nun auf die eigentliche SPI eingrenzen, die ein
> Problem hat, sobald die zu senden Daten (i_TxData) nicht mehr konstant
> sind (sondern sich je nach empfangenen Daten oder Zustand ändern
> sollen).
>
> TX:process(in_CLK)--,i_TxData,in_CS)
> begin
>   if (in_CS='1') then
>     int_DataTx <= i_TxData;
>   elsif rising_edge(in_CLK) then
>     int_DataTx <= int_DataTx(16-2 downto 0) & '0';
>   end if;
> end process;
>
> Jetzt mache ich mich endweder auf die Suche nach einer anedren
> SPI-Implementierung oder muss selber eine schreiben.

Das ist IMHO keine reguläre Beschreibung eines Schieberegisters oder 
eines Registers überhaupt. Da steckt genau wieder der der nichtkonstante 
Reset drin. Rausstreichen aus der sensitive List bewirkt da keine 
Verbesserung.
Vorschlag: Zeichne ein Blockbild deines SPI-Interfaces. Vergleiche das 
mit Blockbildern anderer SPI-Interfaces und identifiziere so die 
Signale:

-systemtakt
-systemreset
-parallele Daten rein/raus

-SPI serielle Daten rein
-SPI serielle Daten raus
-SPI Chipselect
-SPI bit clock

Insbesonders der Unterschied zwischen SPI bit-takt und FPGA Systemtakt 
scheint dir nicht ganz bewußt zu sein.

Davon ausgehend schreibe eine Entity (portliste). Und erst dann kann man 
anfangen hinter dieser Portliste ein parallel zugreifbares 
Schieberegister zu beschreiben (den mehr ist SPI im Kern nicht).

MfG,

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

engineer_on_tour schrieb:
> ich konnte das Problem nun auf die eigentliche SPI eingrenzen, die ein
> Problem hat, sobald die zu senden Daten (i_TxData) nicht mehr konstant
> sind.
Ja, weil die Flipflops des FPGAs (wie oben schon erwähnt) keinen 
Load-Eingang haben. Aber weil dir der Grund bekannt ist kannst du die 
Warnung hier ignorieren.

> Jetzt mache ich mich endweder auf die Suche nach einer anedren
> SPI-Implementierung oder muss selber eine schreiben.
Mach dir die Ursache des Problems klar, dann wirst du erkennen: so 
richtig einfach wird das nicht, wenn der SPI-Takt tatsächlich gleich der 
Schiebetakt sein soll.
Wenn der SPI Takt hinreichend langsam ist, dann kannst du das übliche 
Verfahren mit Einsynchronisieren und schnellem Masterclock (3-4 mal 
höher) machen.