Probleme mit der Erstellung eines Automaten

[Lst (Gast)]

Hallo.

Ich bin VHDL-Neuling und habe zwei Probleme beim unten stehenden 
Automaten. Ich nutze folgenden Baustein: Xilinx XC9572XL.

1. Kommen mehrere Warnungen darüber, dass ich Latches eingebaut habe:
Found 8-bit latch for signal <data_to_CPLD>. Latches may be generated 
from incomplete case or if statements. We do not recommend the use of 
latches in FPGA/CPLD designs, as they may lead to timing problems.

Bei dem ersten Problem weiß ich nicht ob das wirklich zum nicht 
Funktionieren meines Automaten führt oder ob der Fehler woanders liegt.

2.Zum Testen habe ich einen Ausgang angelegt (test_data_out) und auf 
LEDs gelegt. Nur leider scheint noch irgendwtwas nicht zu funktionieren, 
denn Ich sehe nicht die gewünschten Bytes die ich generiere.

Meine Frage nun also: Wenn ihr euch den Automaten anschaut, seht ihr 
irgendwelche groben Fehler?
Wie ihr seht habe ich den Ablauf in 2 Prozesse geteilt, wovon einer 
nicht taktflankengesteuert ist aber laut einigen Quellen soll das 
trotzdem gehen.

Ich würde mich sehr über Antworten von euch freuen, weil ich grad 
absolut nicht drauf komm, was da schiefläuft.

MfG Laura

LIBRARY ieee;
USE ieee.std_logic_1164.all;

ENTITY usb_automat IS
    PORT (
      clk : IN STD_LOGIC;
      reset : IN STD_LOGIC;
      RXF : IN STD_LOGIC; --RXF low: at least 1 byte in recieve buffer
      TXE : IN STD_LOGIC;  --TXE hight: transmit buffer full
      in_data : in STD_LOGIC_VECTOR(7 downto 0); -- data_to_PC
      data : INOUT STD_LOGIC_VECTOR(7 DOWNTO 0);

      WR : OUT STD_LOGIC;  --When taken from a high to a low state, WR reads the 8 data lines and writes the byte into the FIFO's transmit buffer.
      RD : OUT STD_LOGIC; --When pulled low, RD# takes the 8 data lines from a high impedance state to the current byte in the FIFO's receive buffer.
      test_data_out : OUT STD_LOGIC_VECTOR(7 DOWNTO 0) -- Output connected to LEDs 
    );
END usb_automat;

ARCHITECTURE BEHAVIOR OF usb_automat IS
    TYPE type_fstate IS (start,toPC1,toCPLD1,toPC2,toPC3,waitstate,toCPLD2);
   
   -- state signals
    SIGNAL fstate : type_fstate;
    SIGNAL next_state : type_fstate;
   
   -- output signals
    SIGNAL reg_WR : STD_LOGIC := '0';
    SIGNAL reg_RD : STD_LOGIC := '0';
   
   -- data signals
   SIGNAL data_to_PC : STD_LOGIC_VECTOR(7 DOWNTO 0); 
   SIGNAL data_to_CPLD : STD_LOGIC_VECTOR(7 DOWNTO 0) := "00000000";
   
BEGIN
  data_to_PC <=in_data;
    -- set connection between internal output signals and output ports
    PROCESS (clk,next_state,reg_WR,reg_RD, data_to_CPLD, data_to_PC, data)
    BEGIN
        IF rising_edge(clk) THEN
            fstate <= next_state;
            WR <= reg_WR;
            RD <= reg_RD;
            test_data_out <= data_to_CPLD;
        END IF;
    END PROCESS;
   
    PROCESS (fstate,reset,RXF,TXE,clk, data_to_PC, data)
    BEGIN
        -- implement reset
      IF (reset='1') THEN
        next_state <= start;
        reg_WR <= '0';
        reg_RD <= '0';
      ELSE
        reg_WR <= '0'; -- ist das gut? Fallende Flanke wird produziert
        reg_RD <= '0'; -- genauso hier.
        CASE fstate IS
          WHEN start =>
              IF ((NOT((TXE = '1')) AND (RXF = '1'))) THEN
                next_state <= toPC1;
              ELSIF (((RXF = '1') AND (TXE = '1'))) THEN --TXE hight: transmit buffer full
                next_state <= start;
              ELSIF (NOT((RXF = '1'))) THEN --RXF low: at least 1 byte in recieve buffer
                next_state <= toCPLD1;
              ELSE
                next_state <= start;
              END IF;
              
          WHEN toPC1 =>
              reg_WR <= '1';
              next_state <= toPC2;
              
          WHEN toCPLD1 =>
              reg_RD <= '0';
              data_to_CPLD <= data;
              next_state <= toCPLD2;
              
          WHEN toPC2 =>
              next_state <= toPC3;
              
          WHEN toPC3 =>
              data <= data_to_PC; -- Setup data 
              reg_WR <= '0';
              next_state <= waitstate;
              
          WHEN waitstate =>
              next_state <= start;                
              
          WHEN toCPLD2 =>
              reg_RD <= '1';
              next_state <= waitstate;
              
          WHEN OTHERS =>   
              reg_WR <= 'X';
              reg_RD <= 'X';
              report "Reach undefined state";
              
        END CASE;
      END IF;
    END PROCESS;
END BEHAVIOR;

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

Lst schrieb:
> PROCESS (clk,next_state,reg_WR,reg_RD, data_to_CPLD, data_to_PC, data)
>     BEGIN
>         IF rising_edge(clk) THEN

Dieser Prozess ist nur auf clk sensitiv. Deshalb muss auch nur clk 
in die Liste...

Lst schrieb:
> WHEN OTHERS =>
>               reg_WR <= 'X';
>               reg_RD <= 'X';
>               report "Reach undefined state";
Unnötig. Weil du alle definierten Zustände verwendet hast, kann dieser 
Zustand NIEMALS erreicht werden.

> reg_WR <= '0'; -- ist das gut? Fallende Flanke wird produziert
Warum wird hier eine fallende Flanke produziert?

> Found 8-bit latch for signal <data_to_CPLD>.
Das ist klar, denn da wird in einem nicht getakteten Prozess was 
gespeichert:
          WHEN toCPLD1 =>
              data_to_CPLD <= data;

> Meine Frage nun also: Wenn ihr euch den Automaten anschaut, seht ihr
> irgendwelche groben Fehler?
Ausser den gemeldeten Latches nicht. Allerdings deuten Latches, die du 
nicht UNBEDINGT WILLST, gern auf eine Designschäche. Und zwar nicht 
wegen des VHDL-Codes, sondern wegen der zugrundeliegenden Überlegungen.

Ich würde dir raten:
Mach einfach mal eine Simulation. Das ist eine schöne übersichtliche 
FSM, also das ideale Beispiel, mal mit einer Simulation anzufangen.

OT: warum schreibst du deine Kommentare nicht einfach auf Deutsch in den 
Code?

BTW:
> RD : OUT STD_LOGIC; --When pulled low, RD# takes
Wenn ein Signal LOW-aktiv ist, dann solltest du dieses Signal auch so 
benennen. Hier würde sich nRD oder RDn anbieten...

[Lst (Gast)]

Lothar Miller schrieb:

> Dieser Prozess ist nur auf clk sensitiv. Deshalb muss auch nur clk
> in die Liste...
Jo stimmt, die anderen kann man rausnehmen. Mach ich auch gleich mal

>> reg_WR <= '0'; -- ist das gut? Fallende Flanke wird produziert
> Warum wird hier eine fallende Flanke produziert?
Das bezieht sich auf den FTDI, der da später mal dranhängen soll 
(http://www.ftdichip.com/Support/Documents/DataSheets/DLP/dlp-usb245mv15.pdf).
Dieses Kommentar hatte ich nicht speziell für diesen Forenbeitrag 
geschireben. Ich bin mir an der Stelle unsicher ob, wenn ich die 
Ausgänge an dieser Stelle low schalte ob dann nicht der FTDI in dem 
moment reagiert (sind ja Handshake-Signale) und Daten anlegt, die ich in 
dem moment verpasse.

>
>> Found 8-bit latch for signal <data_to_CPLD>.
> Das ist klar, denn da wird in einem nicht getakteten Prozess was
> gespeichert:
>           WHEN toCPLD1 =>
>               data_to_CPLD <= data;
>
Das ist ja interessant, daran liegt das also. Danke!
Wenn ich den Process taktgesteuert mache brauche ich mehr Macrozellen, 
deshalb war ich ganz froh, dass es auch so gehen soll. Meinst du ich 
sollte da doch nochmal drüber nachdenken an der Process-Struktur was zu 
ändern (z.B. den zweiten Process auch taktgesteuert machen)?

> Ich würde dir raten:
> Mach einfach mal eine Simulation. Das ist eine schöne übersichtliche
> FSM, also das ideale Beispiel, mal mit einer Simulation anzufangen.

Mach ich.

> OT: warum schreibst du deine Kommentare nicht einfach auf Deutsch in den
> Code?

Keine Ahnung. Dachte das ist besser so :). Ich geb den Signalen auch 
keine deutschen Namen. Man weiß ja nie ob man den Code z.B. mal in einem 
englischsprachigem Forum hochlädt.Zudem ich hab auch englischsprachige 
Mitarbeiter.

> BTW:
>> RD : OUT STD_LOGIC; --When pulled low, RD# takes
> Wenn ein Signal LOW-aktiv ist, dann solltest du dieses Signal auch so
> benennen. Hier würde sich nRD oder RDn anbieten...

Gut zu wissen.

Vielen Dank auch für deine schnelle Antwort. Ich mache mich jetzt ans 
simulieren.

[Lst (Gast)]

Bei der Simulation hab ich festgestellt:

test_data_out <= data_toCPLD <= "00001010" (Verbingundgsschema, kein 
VDHL-Code)
führt zum gewünschten Ergebnis, also dass in test_data_out mit der 
nächsten Taktflankte "00001010" steht.

Während
test_data_out <= data_toCPLD <= data <= "00001010"
dazu führt dass in test_data_out unknown (xxxxxxxx) steht. Und auch in 
data~result.

Jetzt bin ich am überlegen ob ich den inout port überhaupt richtig 
verwende.
Eigentlich muss ich bei CLPDs die Treiber doch nicht selber steuern wie 
bei einem Mikroprozessor die DDRs oder?

Momentan mach ich damit ja dies:

     -- in der Entity:
     data : INOUT STD_LOGIC_VECTOR(7 DOWNTO 0);

     -- architecture:
     SIGNAL data_to_PC : STD_LOGIC_VECTOR(7 DOWNTO 0); -- Daten, die über bidirektionalen Port an PC geschickt werden
     SIGNAL data_to_CPLD : STD_LOGIC_VECTOR(7 DOWNTO 0) := "00000000"; -- daten die vom PC in den CPLD geschrieben werden

     --im getakteten Prozess:
     test_data_out <= data_to_CPLD;

     -- Zustand in dem Daten vom inout Port entgegengenommen werden:
     WHEN toCPLD1 =>
          data_to_CPLD <= data;
          next_state <= toCPLD2;
     -- Zustand in dem Daten an den inout Port gelegt werden:
     WHEN toPC3 =>
          data <= data_to_PC; -- Setup data 
          next_state <= waitstate;

Ist daran irgendwas nicht richtig?

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

Lst schrieb:
> Eigentlich muss ich bei CLPDs die Treiber doch nicht selber steuern wie
> bei einem Mikroprozessor die DDRs oder?
Oh doch. Du mußt die Tristate-Treiber aktiv in den hochohmigen Zustand 
schalten.
Wenn das RDn- und das WRn-Signal von aussen kommen, sieht das etwa so 
aus:

:
port ( ...
       data :inout std_logic_vector(7 downto 0);
:      
:      
signal write   : std_logic;
signal datain  : std_logic_vector(7 downto 0);
signal dataout : std_logic_vector(7 downto 0);
:
architecture machwas ....
:
   datain <= data;
   data   <= dataout when write='1' else (others=>'Z'); -- IO-Treiber umschalten
end machwas;

[Lst (Gast)]

Oh man, das hat ich doch eigentlich auch so geplant...wieso habe ich das 
wieder ruasgeworfen?
Naja, ich probiers gleich mal aus. Danke nochmal für deine Hilfe!

[Lst (Gast)]

Funktioniert.
Sehr schön!