State machine für SPI

[Samer A. (Firma: Personal) (thedestroyer)]

Hallo Leute :),

für mein Spartan 3AN Starter Kit, habe ich einen SPI code geschrieben. 
Als Anfänger, fand ich die Aufgabe schwer, und habe es vorgezogen es als 
eine State-Machine zu codieren, damit ich einfach die Fehler finde.

Das User Guide findet man unter dieser Verbindung:

http://www.xilinx.com/support/documentation/boards_and_kits/ug334.pdf

Auf seite 76, findet man was ich codieren will (Figure 9-6 und 9-7).

Ich habe drei Fragen, und noch später werde ich mehr Fragen haben über 
diesen Code. Und wäre es sehr nett von euch, sie mir zu erkläre :)

1- Ist es eine gute Idee, den Code als State Machine zu schreiben?

2- Meine State Machine funktioniert leider nicht. Die States ändern sich 
nicht. Ich kann es nicht auf der Simulation zum laufen kriegen. Ich will 
erstmal die Entwicklung von SPI_SCK und AD_CONV sehen, wie sie im User 
Guide beschrieben wurden.

3- Warum sagt das Synthesiswerkzeug, dass es Latches geben wird, obwohl 
alle Variablen schon in Allen states definiert wurden?

Vielen Dank!!!

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use WORK.COMPONENTS.ALL;

-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity ADCModule is
   Generic(BarSteps : Integer := 8; regBits : Integer := 14);
    Port ( AD_CONV : OUT  STD_LOGIC;
           SPI_SCK : OUT  STD_LOGIC;
           AD_DOUT : IN  STD_LOGIC;
        BarOut : OUT STD_LOGIC_VECTOR(BarSteps-1 downto 0);
        CLK : IN STD_LOGIC        
        );
end ADCModule;

architecture Behavioral of ADCModule is
  CONSTANT AD_CONV_PULSE_LENGTH : INTEGER := 2; --constants defining number of pulsess for each state
  CONSTANT AD_CONV_WAIT_LENGTH : INTEGER := 1;
  CONSTANT SPI_CLK_EN_LENGTH : INTEGER := 2;
  CONSTANT DATA_AC1_LENGTH : INTEGER := 14;
  CONSTANT DATA_AC_WAIT_LENGTH : INTEGER := 3;
  CONSTANT DATA_AC2_LENGTH : INTEGER := 14;
  CONSTANT SPI_CLK_END_LENGTH : INTEGER := 3;
  CONSTANT SPI_END_WAIT_LENGTH : INTEGER := 3;


  SIGNAL DATA_AC_EN : STD_LOGIC := '0';
  TYPE states is (START_STATE, AD_CONV_PULSE_STATE, AD_CONV_WAIT_STATE, SPI_CLK_EN_STATE, DATA_AC1_STATE, DATA_AC_WAIT_STATE, DATA_AC2_STATE, SPI_CLK_END_STATE, SPI_END_WAIT_STATE);
  SIGNAL pr_state : states := START_STATE;
  SIGNAL nx_state: states;
  SIGNAL SPI_CLK_EN, AD_CONV_EN : STD_LOGIC; --bits defining the state of SPI_CLK and AD_CONV being enabled or disabled. Usage is defined in StateControl process.
  SIGNAL dataBuffer1, dataBuffer2 : STD_LOGIC_VECTOR(regBits-1 downto 0) := (others => '0');
  SIGNAL temp : INTEGER := 0;
  
  
  -- states description:
  
  -- I defined here a Zero state as the state where both SPI_SCK and AD_CONV = 0.
  
  -- START_STATE: I wrote this state since the problem was with moving to successive states. I thought the problem was from the initial value. This state has no significant function.
  -- AD_CONV_PULSE_STATE: State defined in Fig. 9-6 by the pulse, whose length is minimum equals 4 ns.
  -- AD_CONV_WAIT_STATE: State defined in Fig. 9-6, by the Zero state between the pulse of AD_CONV and the first pulse of SPI_SCK.
  -- SPI_CLK_EN_STATE: Stated that has SPI_SCK enabled till the beginning of data reception.
  -- DATA_AC1_STATE: State that receives the first bunch of data.
  -- DATA_AC_WAIT_STATE: Stated defined in Fig. 9-6 by the Zero state between the reception of the two bunches of data.
  -- DATA_AC2_STATE: State that receives the second bunch of data.
  -- SPI_CLK_END_STATE: State that keeps the remenant of SPI_CLK pulses there.
  -- SPI_END_WAIT_STATE: A Zero state till the repetition of the whole operation.
begin
  StateContol:
  process(clk)
  begin
    if (rising_edge(clk)) then
      AD_CONV <= AD_CONV_EN;
      SPI_SCK <= clk AND SPI_CLK_EN;
      if (pr_state = START_STATE) then
        pr_state <= AD_CONV_PULSE_STATE;        
      else
        pr_state <= nx_state;
      end if;
    end if;
  end process;
  StateFunctionsDefinitions:
  process(pr_state)
    --VARIABLE dataBuffer1_VAR, dataBuffer2_VAR : STD_LOGIC_VECTOR(regBits-1 downto 0) := (others => '0');
    VARIABLE AD_CONV_EN_VAR, SPI_CLK_EN_VAR : STD_LOGIC := '0';
    VARIABLE CONV_PULSE_COUNTER_VAR : INTEGER := 0; -- counter for every state for timing
    VARIABLE AD_CONV_WAIT_COUNTER_VAR : INTEGER := 0;
    VARIABLE SPI_CLK_EN_COUNTER_VAR : INTEGER := 0;
    VARIABLE DATA_AC1_COUNTER_VAR : INTEGER := 0;
    VARIABLE DATA_AC_WAIT_COUNTER_VAR : INTEGER := 0;
    VARIABLE DATA_AC2_COUNTER_VAR : INTEGER := 0;
    VARIABLE SPI_CLK_END_COUNTER_VAR : INTEGER := 0;
    VARIABLE SPI_END_WAIT_COUNTER_VAR : INTEGER := 0;
  begin
    case pr_state is -- in every state, all counters are reset to avoid having latches, but not the one getting counted over in the current state
      when START_STATE =>
        AD_CONV_WAIT_COUNTER_VAR := 0;
        SPI_CLK_EN_COUNTER_VAR := 0;
        DATA_AC1_COUNTER_VAR := 0;
        DATA_AC_WAIT_COUNTER_VAR := 0;
        DATA_AC2_COUNTER_VAR := 0;
        SPI_CLK_END_COUNTER_VAR := 0;
        SPI_END_WAIT_COUNTER_VAR := 0;
      
        AD_CONV_EN_VAR := '0';
        SPI_CLK_EN_VAR := '0';      
        nx_state <= AD_CONV_PULSE_STATE;
        
        
      when AD_CONV_PULSE_STATE =>
        AD_CONV_WAIT_COUNTER_VAR := 0;
        SPI_CLK_EN_COUNTER_VAR := 0;
        DATA_AC1_COUNTER_VAR := 0;
        DATA_AC_WAIT_COUNTER_VAR := 0;
        DATA_AC2_COUNTER_VAR := 0;
        SPI_CLK_END_COUNTER_VAR := 0;
        SPI_END_WAIT_COUNTER_VAR := 0;
        
        AD_CONV_EN_VAR := '1';
        SPI_CLK_EN_VAR := '0';
        if (CONV_PULSE_COUNTER_VAR < AD_CONV_PULSE_LENGTH) then
          CONV_PULSE_COUNTER_VAR := CONV_PULSE_COUNTER_VAR + 1;
        else
          nx_state <= AD_CONV_WAIT_STATE;
        end if;
        
        
      when AD_CONV_WAIT_STATE =>
        CONV_PULSE_COUNTER_VAR := 0;
        SPI_CLK_EN_COUNTER_VAR := 0;
        DATA_AC1_COUNTER_VAR := 0;
        DATA_AC_WAIT_COUNTER_VAR := 0;
        DATA_AC2_COUNTER_VAR := 0;
        SPI_CLK_END_COUNTER_VAR := 0;
        SPI_END_WAIT_COUNTER_VAR := 0;    
        
        AD_CONV_EN_VAR := '0';
        SPI_CLK_EN_VAR := '0';
        if (AD_CONV_WAIT_COUNTER_VAR < AD_CONV_WAIT_LENGTH) then
          AD_CONV_WAIT_COUNTER_VAR := AD_CONV_WAIT_COUNTER_VAR + 1;
        else
          nx_state <= SPI_CLK_EN_STATE;
        end if;
        
        
      when SPI_CLK_EN_STATE =>
        CONV_PULSE_COUNTER_VAR := 0;
        AD_CONV_WAIT_COUNTER_VAR := 0;
        DATA_AC1_COUNTER_VAR := 0;
        DATA_AC_WAIT_COUNTER_VAR := 0;
        DATA_AC2_COUNTER_VAR := 0;
        SPI_CLK_END_COUNTER_VAR := 0;
        SPI_END_WAIT_COUNTER_VAR := 0;          
      
        AD_CONV_EN_VAR := '0';
        SPI_CLK_EN_VAR := '1';
        if (SPI_CLK_EN_COUNTER_VAR < SPI_CLK_EN_LENGTH) then
          SPI_CLK_EN_COUNTER_VAR := SPI_CLK_EN_COUNTER_VAR + 1;
        else
          nx_state <= DATA_AC1_STATE;
        end if;
      
      
      when DATA_AC1_STATE =>
        CONV_PULSE_COUNTER_VAR := 0;
        AD_CONV_WAIT_COUNTER_VAR := 0;
        SPI_CLK_EN_COUNTER_VAR := 0;
        DATA_AC_WAIT_COUNTER_VAR := 0;
        DATA_AC2_COUNTER_VAR := 0;
        SPI_CLK_END_COUNTER_VAR := 0;
        SPI_END_WAIT_COUNTER_VAR := 0;          
      
        AD_CONV_EN_VAR := '0';
        SPI_CLK_EN_VAR := '1';
        if (DATA_AC1_COUNTER_VAR < DATA_AC1_LENGTH) then
          if (DATA_AC1_COUNTER_VAR < regBits) then
            dataBuffer1(regBits - DATA_AC1_COUNTER_VAR) <= AD_DOUT;
          end if;
          DATA_AC1_COUNTER_VAR := DATA_AC1_COUNTER_VAR + 1;
        else
          nx_state <= DATA_AC_WAIT_STATE;
        end if;
      
      
      when DATA_AC_WAIT_STATE =>
        CONV_PULSE_COUNTER_VAR := 0;
        AD_CONV_WAIT_COUNTER_VAR := 0;
        SPI_CLK_EN_COUNTER_VAR := 0;
        DATA_AC1_COUNTER_VAR := 0;
        DATA_AC2_COUNTER_VAR := 0;
        SPI_CLK_END_COUNTER_VAR := 0;
        SPI_END_WAIT_COUNTER_VAR := 0;    
        
        AD_CONV_EN_VAR := '0';
        SPI_CLK_EN_VAR := '1';
        if (DATA_AC_WAIT_COUNTER_VAR < DATA_AC_WAIT_LENGTH) then
          DATA_AC_WAIT_COUNTER_VAR := DATA_AC_WAIT_COUNTER_VAR + 1;
        else
          nx_state <= DATA_AC2_STATE;
        end if;
      
      
      when DATA_AC2_STATE =>
        CONV_PULSE_COUNTER_VAR := 0;
        AD_CONV_WAIT_COUNTER_VAR := 0;
        SPI_CLK_EN_COUNTER_VAR := 0;
        DATA_AC1_COUNTER_VAR := 0;
        DATA_AC_WAIT_COUNTER_VAR := 0;
        SPI_CLK_END_COUNTER_VAR := 0;
        SPI_END_WAIT_COUNTER_VAR := 0;    
        
        AD_CONV_EN_VAR := '0';
        SPI_CLK_EN_VAR := '1';
        if (DATA_AC2_COUNTER_VAR < DATA_AC2_LENGTH) then
          if (DATA_AC2_COUNTER_VAR < regBits) then
            dataBuffer2(regBits - DATA_AC2_COUNTER_VAR) <= AD_DOUT;
          end if;
          DATA_AC2_COUNTER_VAR := DATA_AC2_COUNTER_VAR + 1;
        else
          nx_state <= SPI_CLK_END_STATE;
        end if;
        
        
      when SPI_CLK_END_STATE =>
        CONV_PULSE_COUNTER_VAR := 0;
        AD_CONV_WAIT_COUNTER_VAR := 0;
        SPI_CLK_EN_COUNTER_VAR := 0;
        DATA_AC1_COUNTER_VAR := 0;
        DATA_AC_WAIT_COUNTER_VAR := 0;
        DATA_AC2_COUNTER_VAR := 0;
        SPI_END_WAIT_COUNTER_VAR := 0;          
      
        AD_CONV_EN_VAR := '0';
        SPI_CLK_EN_VAR := '1';
        if (SPI_CLK_END_COUNTER_VAR < SPI_CLK_END_LENGTH) then
          SPI_CLK_END_COUNTER_VAR := SPI_CLK_END_COUNTER_VAR + 1;
        else
          nx_state <= SPI_END_WAIT_STATE;
        end if;
        
      when SPI_END_WAIT_STATE =>
        CONV_PULSE_COUNTER_VAR := 0;
        AD_CONV_WAIT_COUNTER_VAR := 0;
        SPI_CLK_EN_COUNTER_VAR := 0;
        DATA_AC1_COUNTER_VAR := 0;
        DATA_AC_WAIT_COUNTER_VAR := 0;
        DATA_AC2_COUNTER_VAR := 0;
        SPI_CLK_END_COUNTER_VAR := 0;
      
        AD_CONV_EN_VAR := '0';
        SPI_CLK_EN_VAR := '0';
        if (SPI_END_WAIT_COUNTER_VAR < SPI_END_WAIT_LENGTH) then
          SPI_END_WAIT_COUNTER_VAR := SPI_END_WAIT_COUNTER_VAR + 1;
        else
          nx_state <= AD_CONV_PULSE_STATE;
        end if;
    end case;
    temp <= CONV_PULSE_COUNTER_VAR;
    AD_CONV_EN <= AD_CONV_EN_VAR;
    SPI_CLK_EN <= SPI_CLK_EN_VAR;
  end process;
end Behavioral;

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

Samer Afach schrieb:
> 1- Ist es eine gute Idee, den Code als State Machine zu schreiben?
Ich denke, das ist sinnvoll. Fast alles, das einen Ablauf hat, muß in 
einer oder mehreren Statemachines umgesetzt werden.

> 2- Meine State Machine funktioniert leider nicht.
Das ist schade.

> Die States ändern sich
> nicht. Ich kann es nicht auf der Simulation zum laufen kriegen.
Wie sieht deine Testbench aus?

> 3- Warum sagt das Synthesiswerkzeug, dass es Latches geben wird, obwohl
> alle Variablen schon in Allen states definiert wurden?
Darum z.B.:

 if (CONV_PULSE_COUNTER_VAR < AD_CONV_PULSE_LENGTH) then
       CONV_PULSE_COUNTER_VAR := CONV_PULSE_COUNTER_VAR + 1;   -- kombinatorische Schleife!!!
 else
       nx_state <= AD_CONV_WAIT_STATE;
 end if;

Das ist übrigens eigentlich kein Latch, sondern viel schlimmer:
Eine kombinatorische Schleife!!!
http://www.lothar-miller.de/s9y/categories/36-Kombinatorische-Schleife
Das passiert Anfängern bei der Zwei-Prozess-Schreibweise gern...   :-/
Ich empfehle dann imerr sich mal die Ein-Prozess-Schreibweise anzusehen:
http://www.lothar-miller.de/s9y/archives/43-Ein-oder-Zwei-Prozess-Schreibweise-fuer-FSM.html

Ein paar echte Latches hast du natürlich trotzdem noch:

        if (DATA_AC1_COUNTER_VAR < DATA_AC1_LENGTH) then
          if (DATA_AC1_COUNTER_VAR < regBits) then
            dataBuffer1(regBits - DATA_AC1_COUNTER_VAR) <= AD_DOUT; -- Ein Latch, weil kein Defaultwert für dataBuffer1
          end if;
          DATA_AC1_COUNTER_VAR := DATA_AC1_COUNTER_VAR + 1;
        else

BTW:
> AD_DOUT : IN  STD_LOGIC;
Sehr naheliegend...

Es ist schlecht, unnötig Variablen zu verwenden.
Wo lernt man diesen üblen Stil (Zweiprozessschreibweise mit Variablen)?

Samer Afach schrieb:

  if (rising_edge(clk)) then         -- eine STEIGENDE Flanke von clk
     SPI_SCK <= clk AND SPI_CLK_EN;  -- --> was meinst du: welchen Pegel hat clk an dieser Stelle IMMER?

Mir ist dein Code undurchschaubar (und das mag was heißen...).
DIE GROSSGESCHRIEBENEN VARIABLENNAMEN KRATZEN MIR DAS AUGE RAUS.
Daher mein Vorschlag: Sieh dir mal meinen SPI-Master an...
http://www.lothar-miller.de/s9y/categories/45-SPI-Master
Das ist sogar einen kleine Stimuli-Testbench dabei.

Alles in allem würde ich mal ein Blinklicht
http://www.lothar-miller.de/s9y/archives/80-Hello-World!.html
und dann ein Lauflicht für den Anfang empfehlen
http://www.lothar-miller.de/s9y/archives/61-Lauflicht.html

[Samer A. (Firma: Personal) (thedestroyer)]

Vielen Dank für die Erklärung. Ich glaube es wird mir lange dauern bis 
ich das alles lese. Ich tue das während des Wochenendes.

Ich habe manche Fehler kontrolliert, wie den einen mit rising_edge, den 
du erklärt hast. Ich wollte das nur als Verbindung zwischen dem Signal 
und dem Output stellen. Ich habe es außer der Prozesse wiedergestellt.

Gibt es ein gutes Standard für Variablennamen, Funktionen und andere 
Namen auf VHDL? auf C++ gibt es viele, wie

counterLimit -> für variable
getValue -> für member funktionen
SeparateVars -> unabhängige funktionen
Vector3D -> Klassen
usw...

Weil diese sprache case insensitive ist, konnte ich kein Standard 
benutzen. Hast du einen Vorschlag dafür?

Würdest du meine Neue Posts hier merken, wenn ich sie in einem oder zwei 
Tage poste?

Vielen Dank

[Matthias N. (vbchaos)]

Ich finds in VHDL angenehm, signale und variablen klein, constante, 
typen und generics groß zu schreiben. Daran erkenne ich immer obs etwas 
veränderliches oder konstantes ist.
Ist in VHDL ein bisschen geschmacksache weil case insensitive, aber 
allgemein schreibt man variablen/signals klein, schon du Umschalt-taste 
und die DEL taste :)

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

Samer Afach schrieb:
> Würdest du meine Neue Posts hier merken, wenn ich sie in einem oder zwei
> Tage poste?
Ja.

> Weil diese sprache case insensitive ist, konnte ich kein Standard
> benutzen. Hast du einen Vorschlag dafür?
Es gibt keinen Standard, aber man (wie erwähnt) die Groß- und 
Kleinschreibung sinnvoll nutzen. Auf jeden Fall ist komplett 
großegeschriebener längerer Text unlesbar.

[Samer A. (Firma: Personal) (thedestroyer)]

Hallo wieder :-),

ich habe viele änderungen gemacht, nachdem ich die Seiten gelesen habe,
die du mir vorgeschlagen hast :-).

Im bezug von kombinatorischen Schleifen, ich habe es gesehen, dass das
Synthesiswerkzeug automatisch die auf einen Addierer konvertiert. Es
sagt während des Synthesisprozess:

"Found 32-bit adder for signal <conv_pulse_counter_var$addsub0000>
created at line 115."

Alle kombinatorische Schleifen bekommen diese Behandlung.

Vorher, als ich eine Frage über einen Counter hier gestellt habe, hat
jemand diese Webseite mir gegeben>

http://www.lothar-miller.de/s9y/archives/2-Tastene...

damit ich einen Counter mit Switch machen kann ohne Prellen. Darin gibt
es eine kombinatorische Schleife. Ich verstehe nicht warum dort es
erlaubt ist, und hier nicht. Kannst du bitte erklären?

Ich habe auch das State machine in einem Process geschrieben, nicht mehr
zwei :-), und die großgeschriebene Namen habe ich korrigiert :-), nur
konstante haben großgeschriebene Buchstaben.

Kannst du bitte einen Augenblick auf dem neuen Code haben, und mir sagen
ob solcher Code für den SPI funktionieren würde, den man im User Guide
auf Seite 76 findet? Die Simulation zeigt gute Ergebnisse. Ich mache mir
sorge nur um das erste Input von Analog voltage Vin1. Das BarOut ist der
Ergebnis, den ich als Bar graph auf 8 leds sehen möchte, für jeden
Analog input.

Hier ist das User Guide:

http://www.xilinx.com/support/documentation/boards...

Ich bekomme gute Ergebnisse auf Simulation (angeblich), aber trotzdem
gibt das Synthesiswerkzeug komische Warnungen. Es sagt dass, z.B.,
BarOut_0 ein Konstant ist. Und auch dataBuffer1_VAR unverbunden ist...
ich verstehe nicht wie das konstant sein kann, wenn es durch ein State
geändert werden würde!!!

WARNING:Xst:1710 - FF/Latch <BarOut_0> (without init value) has a
constant value of 0 in block <ADCModule>. This FF/Latch will be trimmed
during the optimization process.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_2> of sequential type is
unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_0> of sequential type is
unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_1> of sequential type is
unconnected in block <ADCModule>.
...

Vielen Dank.

Hier ist der Code und das Test Bench:

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use STD.textio.all;
use IEEE.std_logic_textio.all;

-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.NUMERIC_STD.ALL;

-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;

entity ADCModule is
   Generic(BarSteps : Integer := 8; regBits : Integer := 14);
    Port ( ad_conv : OUT  STD_LOGIC;
           SPI_SCK : OUT  STD_LOGIC;
           AD_DOUT : IN  STD_LOGIC;
        BarOut : OUT STD_LOGIC_VECTOR(BarSteps-1 downto 0);
        CLK : IN STD_LOGIC        
        );
end ADCModule; 

architecture Behavioral of ADCModule is
  CONSTANT AD_CONV_PULSE_LENGTH : INTEGER := 0; --constants defining number of pulsess for each state
  CONSTANT AD_CONV_WAIT_LENGTH : INTEGER := 0;
  CONSTANT SPI_CLK_EN_LENGTH : INTEGER := 0;
  CONSTANT DATA_AC1_LENGTH : INTEGER := 14;
  CONSTANT DATA_AC_WAIT_LENGTH : INTEGER := 0;
  CONSTANT DATA_AC2_LENGTH : INTEGER := 14;
  CONSTANT SPI_CLK_END_LENGTH : INTEGER := 0;
  CONSTANT SPI_END_WAIT_LENGTH : INTEGER := 3;

 
  TYPE states is (ad_conv_pulse_state, ad_conv_wait_state, spi_clk_en_state, data_ac1_state, data_ac_wait_state, data_ac2_state, spi_clk_end_state, spi_end_wait_state);
  SIGNAL pr_state : states := ad_conv_pulse_state;
  SIGNAL nx_state: states;
  SIGNAL spi_clk_en, ad_conv_en : STD_LOGIC; --bits defining the state of SPI_CLK and ad_conv being enabled or disabled. Usage is defined in StateControl process.
  SIGNAL dataBuffer1, dataBuffer2 : STD_LOGIC_VECTOR(regBits-1 downto 0) := (others => '0');
  SIGNAL temp : INTEGER := 0;

  
  
  -- states description:
  
  -- I defined here a Zero state as the state where both SPI_SCK and ad_conv = 0.
  
  -- ad_conv_pulse_state: State defined in Fig. 9-6 by the pulse, whose length is minimum equals 4 ns.
  -- ad_conv_wait_state: State defined in Fig. 9-6, by the Zero state between the pulse of ad_conv and the first pulse of SPI_SCK.
  -- spi_clk_en_state: Stated that has SPI_SCK enabled till the beginning of data reception.
  -- data_ac1_state: State that receives the first bunch of data.
  -- data_ac_wait_state: Stated defined in Fig. 9-6 by the Zero state between the reception of the two bunches of data.
  -- data_ac2_state: State that receives the second bunch of data.
  -- spi_clk_end_state: State that keeps the remenant of SPI_CLK pulses there.
  -- spi_end_wait_state: A Zero state till the repetition of the whole operation.
begin
  ad_conv <= ad_conv_en;
  SPI_SCK <= clk AND spi_clk_en;  
  StateContol:
  process(clk)
    VARIABLE dataBuffer1_VAR, dataBuffer2_VAR : STD_LOGIC_VECTOR(regBits-1 downto 0) := (others => '0');
    VARIABLE ad_conv_en_var, spi_clk_en_var : STD_LOGIC := '0';
    VARIABLE conv_pulse_counter_var : INTEGER := 0; -- counter for every state for timing
    VARIABLE ad_conv_wait_counter_var : INTEGER := 0;
    VARIABLE spi_clk_en_counter_var : INTEGER := 0;
    VARIABLE data_ac1_counter_var : INTEGER := 0;
    VARIABLE data_ac_wait_counter_var : INTEGER := 0;
    VARIABLE data_ac2_counter_var : INTEGER := 0;
    VARIABLE spi_clk_end_counter_var : INTEGER := 0;
    VARIABLE spi_end_wait_counter_var : INTEGER := 0;
    
    variable my_line : line;
  begin

    if (rising_edge(clk)) then

      pr_state <= nx_state;
      
      
      case pr_state is -- in every state, all counters are reset to avoid having latches, but not the one getting counted over in the current state
      when ad_conv_pulse_state =>
        ad_conv_wait_counter_var := 0;
        spi_clk_en_counter_var := 0;
        data_ac1_counter_var := 0;
        data_ac_wait_counter_var := 0;
        data_ac2_counter_var := 0;
        spi_clk_end_counter_var := 0;
        spi_end_wait_counter_var := 0;
        
        ad_conv_en_var := '1';
        spi_clk_en_var := '0';
        if (conv_pulse_counter_var < AD_CONV_PULSE_LENGTH) then
        --write(my_line, conv_pulse_counter_var);
        --writeline(output, my_line);        
          conv_pulse_counter_var := conv_pulse_counter_var + 1;
        --write(my_line, conv_pulse_counter_var);
        --writeline(output, my_line);            
        else
          nx_state <= ad_conv_wait_state;
        end if;
        
        
      when ad_conv_wait_state =>
        conv_pulse_counter_var := 0;
        spi_clk_en_counter_var := 0;
        data_ac1_counter_var := 0;
        data_ac_wait_counter_var := 0;
        data_ac2_counter_var := 0;
        spi_clk_end_counter_var := 0;
        spi_end_wait_counter_var := 0;    
        
        ad_conv_en_var := '0';
        spi_clk_en_var := '0';    
        if (ad_conv_wait_counter_var < AD_CONV_WAIT_LENGTH) then
          --write(my_line, ad_conv_wait_counter_var);
          --writeline(output, my_line);
          ad_conv_wait_counter_var := ad_conv_wait_counter_var + 1;
        else
          nx_state <= spi_clk_en_state;
        end if;
        
          --write(my_line, string'("Hello"));
          --writeline(output, my_line);

          
      when spi_clk_en_state =>
        conv_pulse_counter_var := 0;
        ad_conv_wait_counter_var := 0;
        data_ac1_counter_var := 0;
        data_ac_wait_counter_var := 0;
        data_ac2_counter_var := 0;
        spi_clk_end_counter_var := 0;
        spi_end_wait_counter_var := 0;          
      
        ad_conv_en_var := '0';
        spi_clk_en_var := '1';
        if (spi_clk_en_counter_var < SPI_CLK_EN_LENGTH) then
          spi_clk_en_counter_var := spi_clk_en_counter_var + 1;
        else
          nx_state <= data_ac1_state;
        end if;
      
      
      when data_ac1_state =>
        conv_pulse_counter_var := 0;
        ad_conv_wait_counter_var := 0;
        spi_clk_en_counter_var := 0;
        data_ac_wait_counter_var := 0;
        data_ac2_counter_var := 0;
        spi_clk_end_counter_var := 0;
        spi_end_wait_counter_var := 0;    
      
        ad_conv_en_var := '0';
        spi_clk_en_var := '1';
        if (data_ac1_counter_var < DATA_AC1_LENGTH) then
          --if (data_ac1_counter_var < regBits) then
--            write(my_line, data_ac1_counter_var);
--            writeline(output, my_line);
--            write(my_line, DATA_AC1_LENGTH);
--            writeline(output, my_line);
--            write(my_line, DATA_AC1_LENGTH);
--            writeline(output, my_line);
--            
            dataBuffer1_VAR(regBits - data_ac1_counter_var - 1) := AD_DOUT;
          --end if;
          data_ac1_counter_var := data_ac1_counter_var + 1;
        else
          nx_state <= data_ac_wait_state;
        end if;
      
      
      when data_ac_wait_state =>
        conv_pulse_counter_var := 0;
        ad_conv_wait_counter_var := 0;
        spi_clk_en_counter_var := 0;
        data_ac1_counter_var := 0;
        data_ac2_counter_var := 0;
        spi_clk_end_counter_var := 0;
        spi_end_wait_counter_var := 0;    
        
        ad_conv_en_var := '0';
        spi_clk_en_var := '1'; --here switch back to 1 during tests
        if (data_ac_wait_counter_var < DATA_AC_WAIT_LENGTH) then
          data_ac_wait_counter_var := data_ac_wait_counter_var + 1;
        else
          nx_state <= data_ac2_state;
        end if;
      
      
      when data_ac2_state =>
        conv_pulse_counter_var := 0;
        ad_conv_wait_counter_var := 0;
        spi_clk_en_counter_var := 0;
        data_ac1_counter_var := 0;
        data_ac_wait_counter_var := 0;
        spi_clk_end_counter_var := 0;
        spi_end_wait_counter_var := 0;    
        
        ad_conv_en_var := '0';
        spi_clk_en_var := '1';
        if (data_ac2_counter_var < DATA_AC2_LENGTH) then
          --if (data_ac2_counter_var < regBits) then
            dataBuffer2_VAR(regBits - data_ac2_counter_var - 1) := AD_DOUT;
          --end if;
          data_ac2_counter_var := data_ac2_counter_var + 1;
        else
          nx_state <= spi_clk_end_state;
        end if;
        
        
      when spi_clk_end_state =>
        conv_pulse_counter_var := 0;
        ad_conv_wait_counter_var := 0;
        spi_clk_en_counter_var := 0;
        data_ac1_counter_var := 0;
        data_ac_wait_counter_var := 0;
        data_ac2_counter_var := 0;
        spi_end_wait_counter_var := 0;          
      
        ad_conv_en_var := '0';
        spi_clk_en_var := '1';
        if (spi_clk_end_counter_var < SPI_CLK_END_LENGTH) then
          spi_clk_end_counter_var := spi_clk_end_counter_var + 1;
        else
          nx_state <= spi_end_wait_state;
        end if;
        
      when spi_end_wait_state =>
        conv_pulse_counter_var := 0;
        ad_conv_wait_counter_var := 0;
        spi_clk_en_counter_var := 0;
        data_ac1_counter_var := 0;
        data_ac_wait_counter_var := 0;
        data_ac2_counter_var := 0;
        spi_clk_end_counter_var := 0;
      
        ad_conv_en_var := '0';
        spi_clk_en_var := '0';
        if (spi_end_wait_counter_var < SPI_END_WAIT_LENGTH) then
          spi_end_wait_counter_var := spi_end_wait_counter_var + 1;
        else
          nx_state <= ad_conv_pulse_state;
        end if;
    end case;
      temp <= conv_pulse_counter_var;
      ad_conv_en <= ad_conv_en_var;
      spi_clk_en <= spi_clk_en_var;
      if(pr_state = spi_end_wait_state) then
        dataBuffer1 <= dataBuffer1_VAR;
        dataBuffer2 <= dataBuffer2_VAR;
      end if;
    end if;
  end process;
  process(ad_conv_en)
    VARIABLE barVec : STD_LOGIC_VECTOR(barSteps-1 downto 0) := (others => '0');
    VARIABLE count : INTEGER := 0;
  begin
    if (rising_edge(ad_conv_en)) then
    For count in 0 to barSteps - 1 loop
      if (unsigned(dataBuffer1) < (2048*count)) then
        barVec(count) := '1';
      else
        barVec(count) := '0';
      end if;
    end loop;
    BarOut <= barVec;
    end if;
  end process;
end Behavioral;

-----------------Test Bench-----------------------

LIBRARY ieee;
USE ieee.std_logic_1164.ALL;
use STD.textio.all;
use IEEE.std_logic_textio.all;

-- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
USE ieee.numeric_std.ALL;
 
ENTITY ADCModuleTestBench IS
END ADCModuleTestBench;
 
ARCHITECTURE behavior OF ADCModuleTestBench IS 
 
    -- Component Declaration for the Unit Under Test (UUT)
 
    COMPONENT ADCModule
    PORT(
         AD_CONV : OUT  std_logic;
         SPI_SCK : OUT  std_logic;
         AD_DOUT : IN  std_logic;
         BarOut : OUT  std_logic_vector(7 downto 0);
         CLK : IN  std_logic
        );
    END COMPONENT;
    

   --Inputs
   signal AD_DOUT : std_logic := '0';
   signal CLK : std_logic := '0';

   --Outputs
   signal AD_CONV : std_logic;
   signal SPI_SCK : std_logic;
   signal BarOut : std_logic_vector(7 downto 0);
  constant numtoconv : std_logic_vector(13 downto 0) := std_logic_vector(to_unsigned(10922,14));

   -- Clock period definitions
   constant CLK_period : time := 20 ns;
 
BEGIN
 
  -- Instantiate the Unit Under Test (UUT)
   uut: ADCModule PORT MAP (
          AD_CONV => AD_CONV,
          SPI_SCK => SPI_SCK,
          AD_DOUT => AD_DOUT,
          BarOut => BarOut,
          CLK => CLK
        );

   -- Clock process definitions
   CLK_process :process
   begin
    CLK <= '0';
    wait for CLK_period/2;
    CLK <= '1';
    wait for CLK_period/2;
   end process;
 

   -- Stimulus process
   stim_proc: process(AD_CONV,SPI_SCK)
    variable clk_count : integer := 0;
    variable indexcount : integer := 14;
    variable my_line : line;    
   begin    
      -- hold reset state for 100 ns.
  if(rising_edge(ad_conv))then
    clk_count := 0;
    indexcount := 14;
  end if;
  if(rising_edge(spi_sck))then
  write(my_line, clk_count);
  writeline(output, my_line);
  write(my_line, indexcount);
  writeline(output, my_line);
  
  If (clk_count < 2) then
    clk_count := clk_count + 1;
  else 
    if (indexcount = 0) then
      --clk_count := 0;
      --indexcount := 14;
    else
      AD_DOUT <= numtoconv(indexcount - 1);
      indexcount := indexcount - 1;
    end if;
  end if;

      -- insert stimulus here 
  end if;
   end process;

END;

Ich bedanke mich sehr bei deinem Geduld :-)

[berndl (Gast)]

Samer Afach schrieb:
> process(clk)
>     VARIABLE dataBuffer1_VAR, dataBuffer2_VAR : STD_LOGIC_VECTOR(regBits-1 
downto 0) := (others => '0');
>     VARIABLE ad_conv_en_var, spi_clk_en_var : STD_LOGIC := '0';
>     VARIABLE conv_pulse_counter_var : INTEGER := 0; -- counter for every state 
for timing
>     VARIABLE ad_conv_wait_counter_var : INTEGER := 0;
>     VARIABLE spi_clk_en_counter_var : INTEGER := 0;
>     VARIABLE data_ac1_counter_var : INTEGER := 0;
>     VARIABLE data_ac_wait_counter_var : INTEGER := 0;
>     VARIABLE data_ac2_counter_var : INTEGER := 0;
>     VARIABLE spi_clk_end_counter_var : INTEGER := 0;
>     VARIABLE spi_end_wait_counter_var : INTEGER := 0;

OMG, dir ist hoffentlich klar, dass du hier 8 counter mit einer Breite 
von 32bit generierst? Du kannst auch in jedem state den gleichen counter 
wieder verwenden! Und dieses Gedoens mit Variablen hat Lothar ja schon 
angesprochen: Warum macht man sowas? Man hat den Eindruck, dass die 
Leute von 'echter' HW keine Ahnung haben...

[Samer A. (Firma: Personal) (thedestroyer)]

ich habe schon in meinem Code ranges gestellt. Ich benutze viele 
Variablen nur sicher zu sein dass keine Probleme passieren können, weil 
ich ein Anfänger bin. Später wenn es richtig funktioniert, schritt für 
schritt, kann man es optimieren bis es super Optimum ist :)

Findet ihr was falsches noch Leute? :)

[Samer A. (Firma: Personal) (thedestroyer)]

Ich habe viele Änderungen gemacht, und ich habe eine andere State 
Machine hinzufügt für den Amplifier in Seite 74.

Ich bekomme viele Warnungen mit latches on trimms von variable. Könnt 
Ihr bitte den Code checken und mir sagen wie man diese Fehler reparieren 
kann?

Die Arbeite ist fast fertig. Es wäre sehr schön wenn ihr mir helfen 
könntet :)

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

Samer Afach schrieb:
> Vorher, als ich eine Frage über einen Counter hier gestellt habe, hat
> jemand diese Webseite mir gegeben>
Das war ich.
> http://www.lothar-miller.de/s9y/archives/2-Tastene...
Meintest du den da:
http://www.lothar-miller.de/s9y/archives/2-Tastenentprellung.html
> damit ich einen Counter mit Switch machen kann ohne Prellen.
Ich meine aber geschrieben zu haben dass man diese Code nicht verwenden 
soll, denn damit

kommt oft eine unangenehme Überraschung: der Zähler zählt viel zu viele 
Impulse, die State-Machine springt wild hin- und her.
Mit einer Beschreibung wie dieser wird das unausweichlich passieren: ...

> Darin gibt es eine kombinatorische Schleife.
Dort gibt es sicher keine kombinatorische Schleife, weil nur in 
getakteten Prozessen gezählt wird. Getaktete Prozesse können keine 
kombinatorischen Schleifen haben!
> Ich verstehe nicht warum dort es erlaubt ist, und hier nicht.
Wie gesagt: die kombinatorische Schleife ist nicht "erlaubt", sondern 
nicht vorhanden.
> Kannst du bitte erklären?
Mir fällt kein Fall ein, wo eine kombinatorische Schleife "erlaubt" sein 
könnte...

Samer Afach schrieb:
> Findet ihr was falsches noch Leute? :)
Die Denkweise:
> Ich benutze viele Variablen nur sicher zu sein dass keine Probleme
> passieren können, weil ich ein Anfänger bin.
Viele Probleme passieren WEGEN Variablen.

[Samer A. (Firma: Personal) (thedestroyer)]

Ah ja! dann heißt das, dass wie ich es jetzt benutze (mit getaktete 
Prozesse) macht keine kombinatorische Schleifen! danke für die 
Erklärung.

Jetzt bekomme ich Warnungen nur wegen "dataBuffer1", "dataBuffer1_var" 
und BarOut_0, die Counters Variablen machen keine Probleme mehr.

Kannst du bitte den Code angucken und synthesieren lassen und mir sagen, 
wie ich diese Warnungen vermeiden kann? das wäre sehr nett von dir :-). 
Ich habe schon alles versucht was ich kann!

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

Samer Afach schrieb:
> Jetzt bekomme ich Warnungen nur wegen "dataBuffer1", "dataBuffer1_var"
> und BarOut_0,
Siehe den Beitrag "Re: State machine für SPI" ab
>>>>> Ein paar echte Latches hast du...

dataBuffer1(regBits - DATA_AC1_COUNTER_VAR) <= AD_DOUT; -- Latch

Das ist ein Latch, weil dataBuffer1 nicht getaktet ist. Oder auch, weil 
kein Defaultwert für dataBuffer1 angegeben wurde (was aber auch sinnlos 
wäre...).

[Samer A. (Firma: Personal) (thedestroyer)]

Vielen Dank für deine Antwort.

Ich kann noch nicht verstehen wie ich dataBuffer1 takten lassen kann :(. 
Es liegt schon unter rising_edge(clk). Was könnte man noch takten?

Soll ich den Befehl in einem anderen Prozess stellen? bitte schreib 
einen kleinen Code, darin sieht man wie ich dataBuffer1 takten lassen 
kann.

Ich weiß ich frage schon viel an, aber das ist mein erster echter Code 
mit echten Anwendung :)

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

Samer Afach schrieb:
> Ich kann noch nicht verstehen wie ich dataBuffer1 takten lassen kann :(.
> Es liegt schon unter rising_edge(clk).
Richtig. Das habe ich übersehen... :-/

> Jetzt bekomme ich Warnungen nur wegen "dataBuffer1", "dataBuffer1_var"
> und BarOut_0, die Counters Variablen machen keine Probleme mehr.
Ich habe das mal synthetisiert (Xilinx ISE13.1) und bekomme folgende 
Warnungen:

WARNING:Xst:646 - Signal <dataBuffer2> is assigned but never used. This unconnected signal will be trimmed during the optimization process.
WARNING:Xst:1710 - FF/Latch <BarOut_0> (without init value) has a constant value of 0 in block <ADCModule>. This FF/Latch will be trimmed during the optimization process.
WARNING:Xst:1710 - FF/Latch <BarOut_0> (without init value) has a constant value of 0 in block <ADCModule>. This FF/Latch will be trimmed during the optimization process.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_0> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_1> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_2> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_5> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_3> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_4> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_8> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_6> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_7> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_9> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_VAR_10> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_0> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_1> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_2> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_3> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_4> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_5> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_6> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_7> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_8> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_9> of sequential type is unconnected in block <ADCModule>.
WARNING:Xst:2677 - Node <dataBuffer1_10> of sequential type is unconnected in block <ADCModule>.

Daran ist nichts Schlimmes. Hier sagt der Synthesizer einfach, dass 
diese signale im Design nicht verwendet werden und daher entweder gar 
nicht erzeugt oder wegoptimiert werden.

[Samer A. (Firma: Personal) (thedestroyer)]

Danke sehr für deine Antwort.

Also mit dataBuffer2, ist es mir egal. Es ist nicht verbunden und ich 
brauche es nicht. Aber die anderen sind verwirrend. Schau mal die 
Simulation Ergebnisse (ich habe sie schonmal gepostet hier). Man sieht 
das BarOut_0 und dataBuffer1/_var ändern sich, und eigentlich sind sie 
wichtig, weil sie kontrollieren die Ergebnisse vom ADC!

Wie kann das Synthesiswerkzeug sagen, dass sie unverbunden sind, und die 
Simulation gibt die richtigen Ergebnisse durch diese 2 Variablen?

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

Samer Afach schrieb:
> Man sieht das BarOut_0 und dataBuffer1/_var ändern sich
Nein. BarOut(0) ändert sich nie!

   For count in 0 to barSteps - 1 loop                  -- count = 0..7
      if (unsigned(dataBuffer1) < (2048*count)) then    -- ein unsigned Wert kann nie kleiner als 0 (0*2048) sein!
         barVec(count) := '1';
      else                      
         barVec(count) := '0';                          -- deshalb ist barVec(0) immer '0'
      end if;
   end loop;
   BarOut <= barVec;

> dataBuffer1/_var
Ist nicht weiter verwendet und wird deshalb rausoptimiert.
>> Node <dataBuffer1_VAR_0> ... is unconnected in block <ADCModule>

[Johann (Gast)]

Ist das nicht alles ein wenig too much für eine SPI-Verbindung?

Wenn ich einen Sender bauen möchte dann benötigt man ja nur einen CLK, 
eine Datenleitung und eine CS Leitung.

Dann baut man ein Modul wo man 8Bit parallel reingibt ein seriell wieder 
rauskommt. Man kann dann noch eine Busy Leitung oder einen zusätzlich 
Buffer integrien.

Jedoch ist es nur ein Schieberegister.

SPI_DATA <= SPI_BUFFER(7);

SPI_BUFFER <= SPI_BUFFER(6 downto 0) & SPI_BUFFER(7);

Dann benötigt man noch einen Counter der bis 8 läuft. Den SPI-Clock muss 
man nicht mal unterbrechen der kann immer laufen

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

Johann schrieb:
> Ist das nicht alles ein wenig too much für eine SPI-Verbindung?
Na gut, da ist die Verwaltung auch noch mit drin, aber ich hatte im 
Beitrag "Re: State machine für SPI" schon angemerkt, 
dass das kürzer gehen würde.

> Den SPI-Clock muss man nicht mal unterbrechen der kann immer laufen
Davor sollte man aber das Datenblatt genau lesen, bei manchen Devices 
darf der Takt erst nach dem CS anfangen. Zumindest ist ein 
durchlaufender Takt im DB nicht spezifizert...

[PittyJ (Gast)]

Meinen Senf auch noch mal dazu:

Ich hatte mal Probleme, als ich SPI-Takt und Daten gleichzeitig 
behandelt habe. Wenn der SPI-Takt steigt, dann mussten aber schon die 
SPI-Daten gültig anliegen.
Also habe ich noch eine Schicht darunter implementiert, der mit 4fachen 
SPI-Takt arbeitet, und dann die Daten schon eine 4tel Impuls vorher auf 
die Leitung gelegt hat, und dann erst den Takt aktivierte.

Das Verfahren konnte ich in dem Wust der Variablen und States hier nicht 
erkennen.

Mein Verfahren kamm dann auch mit weniger States und ohne Variablen aus.

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

PittyJ schrieb:
> Ich hatte mal Probleme, als ich SPI-Takt und Daten gleichzeitig
> behandelt habe.
Das ist vom SPI auch anders vorgesehen... :-o

An der einen Flanke werden Daten übernommen, an (besser wegen) der 
anderen werden sie geändert:
http://www.lothar-miller.de/s9y/categories/17-SPI
Soweit die Idee, aber in der Praxis ist SPI ja nur gekoppelte 
Schieberegister, und dei reagieren auf die selbe Flanke. Also wird mit 
der Taktflanke das vorher anliegende Datum übernommen und wegen der 
Taktflanke das am Ausgang ausgegeben.
Der ungünstigste Fall ist, wenn die Daten erst ein paar ns vor dem Takt 
(oder gar erst gleichzeitig mit dem Takt) stabil sind. Dann wird 
zwingend die Setup-Zeit des Flipflops verletzt.

> Wenn der SPI-Takt steigt, dann mussten aber schon die SPI-Daten gültig
> anliegen.
Dann werden Sie entweder:
- mit der fallenden Flanke ausgegeben
oder:
- einen Takt früher mit der steigenden Flanke ausgegeben

[Samer A. (Firma: Personal) (thedestroyer)]

Vielen Dank für eure Erklärungen :)

Also jetzt bekomme ich Warnung mit Place & Route. Ich weiß nicht ob man 
das ignorieren darf.

WARNING:Route:455 - CLK Net:ad_conv_en may have excessive skew because
      0 CLK pins and 1 NON_CLK pins failed to route using a CLK 
template.
WARNING:Route:455 - CLK Net:downClk6 may have excessive skew because
      0 CLK pins and 2 NON_CLK pins failed to route using a CLK 
template.

Ich habe danach gelesen:

http://www.xilinx.com/support/answers/21723.htm

es wurde vorgeschlagen, dass ich diese Warnung ignorieren darf, nur mit 
besonderer Bedingung:

"If the loads on the net shown in FPGA Editor are in accord with your 
design, the skew reported in the PAR report is not critical for the 
design, and the timing constraint requirement on that net is met, then 
this warning can be safely ignored."

Was heißt genau "in accord with your design"? ich habe den Kabeln 
verfolgen auf FPGA Editor, und habe nichts verstanden. Gibt es etwas, 
dass ich in meinem Code ändern soll diese Warnung vernichten zu können? 
oder muss ich was mit was anderes tun?

[Samer A. (Firma: Personal) (thedestroyer)]

Ich habe das Problem gelöst! ich habe dafür nur alle andere Prozesse in 
dem ersten Prozess gestellt. Also jetzt gibt es nur ein Prozess mit 
alllllleeeeeeeennnnn Befehlen zusammen!!!

Macht das sinn? warum kriege ich immer Probleme wenn ich mehr als ein 
Prozess benutze?

Vielen Dank!

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

Samer Afach schrieb:
> Also jetzt gibt es nur ein Prozess mit
> alllllleeeeeeeennnnn Befehlen zusammen!!!
> Macht das sinn?
Wenn klappt ist es ja gut, es wird eben mit einem Monsterprozess schnell 
ein wenig unübersichtlich...

> warum kriege ich immer Probleme wenn ich mehr als ein Prozess benutze?
Das hier kommt daher, dass du 2 Takte verwendest:
> WARNING:Route:455 - CLK Net:ad_conv_en may have excessive skew because
>       0 CLK pins and 1 NON_CLK pins failed to route using a CLK
> template.
> WARNING:Route:455 - CLK Net:downClk6 may have excessive skew because
>       0 CLK pins and 2 NON_CLK pins failed to route using a CLK
> template.
Ein Takt ist alles, was auf rising_edge() oder auf 'event reagiert. Und 
dann gelten meine Postulate:

Ein Design (insbesondere ein Anfängerdesign) hat genau 1 Takt, 
der immer auf dieselbe Flanke aktiv ist. 
Es gibt keinen (und schon gar keinen asynchronen) Reset.
Externe Signale werden über 2 Flipflops einsynchronisiert.
Jede Abweichung von diesen Regeln muß fundiert begründet werden können.

BTW:
zu deiner extensiven Verwendung von Variablen lies mal den 
Beitrag "Variable vs Signal"

[Samer A. (Firma: Personal) (thedestroyer)]

Vielen Dank man. Ich bedanke mich seeeeeeeeeeeehr bei dir :-)

ich habe zu viel von dir gelernt, seitdem ich mit VHDL angefangen habe 
:-)

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

Samer Afach schrieb:
> Vielen Dank
Keine Ursache. Nur nicht aufgeben...  ;-)

BTW: leih dir mal VHDL-Synthese von Reichardt&Schwarz aus...

[Samer A. (Firma: Personal) (thedestroyer)]

Ich habe schon The Designer's Guide to VHDL bestellt :-) (du hast mir 
über dieses Buch erzählt). Ich habe die PDF Version angeguckt und hat es 
mir gefallen!

Wenn du eine PDF Version dieses Buchs hast, wäre schön wenn du es mir 
schicken kannst :-). Leider habe ich keine Bibliothek bei mir (es ist 
kompliziert).

Danke wieder!

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

Samer Afach schrieb:
> Wenn du eine PDF Version dieses Buchs hast, wäre schön wenn du es mir
> schicken kannst :-)
Tut mir leid, habe ich nicht.