Grundlegendes Problem oder nur Stilfrage?

[Breti (Gast)]

Hi,

ich habe mir ein VHDL Modul für den OPB geschrieben, bei dem das Timing 
nicht 100%ig korrekt ist und somit Fehler verursacht. Ich habe den 
Fehler leider noch nicht gefunden. Ich habe häufig folgneden Schreibstil 
verwendet und frage mich, ob die Synthese (XST) damit evt. Probleme 
haben könnte oder ob das vom Stil her ok ist:


signal bla: std_logic;
signal state: irgendeine aufzählung von states

process (clk) is
begin
  if rising_edge(clk) then
    if reset='1' then
       bla <= '0';
    else
      bla <= '0';
      case state is
        when a =>
          state <= b;
        when b =>
          bla <= '1';
          state <= c;
        when c =>
          state <= a;
      end case;
    end if;
  end if;
end process;

Ich setzte bla also in jedem Takt auf '0' außer, wenn state = b gilt. 
Ich spare mir hir also das setzen von bla <= '0' in jedem einzelnen 
state, indem ich es an den anfang vor das case setze. Ich bin mir aber 
unsicher, ob das nicht ein Problem gibt, wenn das dann später im 
gleichen clock zyklus "überschrieben" bzw. doch auf '1' gesetzt wird 
sobald der state b erreicht wird. Was macht die Synthese daraus?

Ganz konkret ist mein Problem, dass das signal bla ein read-enable für 
einen fifo ist und manchmal offenbar ein wert zuviel aus der fifo 
gelesen wird.

Was sagt ihr dazu?

Gruß,
Thomas

[Stefan H. (stefanhanke)]

Breti wrote:
> Ich setzte bla also in jedem Takt auf '0' außer, wenn state = b gilt.
> Ich spare mir hir also das setzen von bla <= '0' in jedem einzelnen
> state, indem ich es an den anfang vor das case setze. Ich bin mir aber
> unsicher, ob das nicht ein Problem gibt, wenn das dann später im
> gleichen clock zyklus "überschrieben" bzw. doch auf '1' gesetzt wird
> sobald der state b erreicht wird. Was macht die Synthese daraus?
Nein, das ist ok. Es gilt: die letzte Signalzuweisung gewinnt ;-)

 -- stefan

[Joerg W. (joergwolfram)]

Wenn das if wahr ergibt, dann wird der else-Zweig (oder auch ein elsif) 
nicht mehr abgearbeitet, also sollte es daran nicht liegen.

Jörg

[Breti (Gast)]

@Jörg: In innersten IF-Zweig ist noch ein bla <= '0'. Dieses wird 
manchmal durch ein bla <= '1' in der CASE Anweisung ersetzt.

[Spartanne (Gast)]

Grundsätzlich OK. Mache meine State-Machines eigentlich auf dieselbe Art 
mit der Defaultzuweisung vor dem case. Das machte bei mir bisher keine 
Probleme.

Ich vermisse aber in deiner SM ein "when others".
Außerdem wird in deinem Reset kein Reset-State definiert.. was aber 
eigentlich egal ist (irgendeiner wirds schon sein).
Probieren kannst du auch noch das Encoding der SM einzustellen bei den 
Optionen von XST.

Wenn das alles nicht hilft denke ich eher der Fehler kommt von dem 
Schaltungsteil, der die States definiert...und vermute stark dass 
asynchrone Signale dortreinspucken, die den State b öfters erzwingen als 
du willst.

Oder ist deine SM wirklich so wie du sie gepostet hast?? Dann wärs ja 
keine SM, sondern eigentlich ein Zähler!? (nach der Synthese)
Sinnvoll wäre also vielleicht eher dein richtiger Code.


Gruß

[Breti (Gast)]

Hi,

ich hatte die Statemachine nur so grob skizziert, um die Frage zu 
erklären. Natürlich hat meine noch ein "when others" und ein reset-state 
gibt es auch.

Ich habe auch mittlerweile den Fehler gefunden: Die Fifo Statemachines 
sind ok. Was den Fehler macht ist die Statemachine, die die Daten vom 
Fifo liest und auf den ISA Bus schreibt. Aus irgendeinem Grund wird dort 
der Lesezyklus manchmal doppelt Mal durchlaufen. Eigentlich sollte das 
nicht sein, da die Statemachine nach jedem Zugriff so lange wartet, bis 
"/IOR" wieder auf logisch 1 ist. Passieren tuts aber trotzdem und ich 
weiß nicht wieso.

Gruß,
Thoams