Sehr seltsames Verhalten eines VHDL-Designs, Bitte um Hilfe

[noips (Gast)]

Hallo zusammen,

ich stosse auf ein für mich ganz unverständliches Verhalten eines 
VHDL-Codes in einem Lattice-FPGA.
Das Design ist zum Ansteuern eines (oder mehrerer im Chain-Mode) 
AD-Wandlers per SPI gedacht. Es kann mehrere SPIs haben, darum diese 
for-Schleifen.

So wie die angehängten Dateien jetzt sind geht alles wie erwartet. Wenn 
man aber in der Zeile hier(Zeile 7 der Datei types_p.vhd)

constant SPI_DATA_LENGTH  : integer := 120;

für die Datenpaketgröße statt 120 z.B. 56 schreibt, dann funktioniert 
plötzlich diese Stelle im Code (ab Zeile 532 in interface.vhd) nicht 
mehr zuverlässig. Die sChanNum wird um 2 (statt 1) erhöht.

if state = START and next_state = CONVERT then --and sChanSelFlag = '1' then
  
  --if sChanNum2 < 7 then
  --  sChanNum2 <= sChanNum2 + 1;
  --  sPackStart <= '1';
  --else
  --  sChanNum2 <= 0;
  --  sPackStart <= '0';
  --end if;
  if sChanNum2 = 7 then--"0111" then
    sChanNum2 <= 0;--"0000";
    sPackStart <= '0';
  else
    sChanNum2 <= sChanNum2 + 1;
    sPackStart <= '1';
  end if;
    
  --sChanSelFlag <= '0';
end if;

Dabei hängt die Paketgröße SPI_DATA_LENGTH eigentlich gar nicht mit dem 
Code-Teil zusammen. Was auch noch seltsam ist, der auskommentierte Teil 
des Codes hier, soll ja das gleiche Verhalten beschreiben, wenn ich aber 
den jetzt aktiven Code auskommentiere und den auskommentierten aktiv 
mache, bleibt die State Machine hängen. Was ist da falsch?

Weiterhin habe ich gemerkt, dass wenn ich in diesem Teil

when SAMPLE =>    if cnt = SAMPLE_DELAY and rts_master_ar_s(0) = '1' then next_state <= START;
          else next_state <= SAMPLE;
          end if;

im Ausdruck "if cnt = SAMPLE_DELAY" das '=' in '>=' ändere, bleibt die 
Zustandsmaschine im Zustand SAMPLE hängen.

Hat jemand eine Erklärung für dieses Verhalten? Wie kriege ich das in 
den Griff?

Ich bin dankbar für jeden Tipp!

[O_o (Gast)]

Du kriegst auf jeden Fall einen Preis für deinen unleserlichen 
Code-Aufbau!

Ich tippe mal dein Problem liegt im Prozess

"ns_decoder : process (RST, rts_master_ar_s, cnt, rx_rdy_rising_ar_s, 
state, sSpiWait) begin"

Ich würde die FSM erstmal komplett neu aufbauen, so wie man es gelernt 
hat (Ein-, Zwei- oder Dreiprozess-Schreibweise), aber nicht so wie bei 
dir^^ Danach alles sauber durchsimulieren und dann nochmal auf die 
Hardware.

(BTW: hast du das Simuliert?)

[noips (Gast)]

O_o schrieb:
> (BTW: hast du das Simuliert?)

Ja, in der Simulation läuft alles wie erwartet! Das ist es ja.

[O_o (Gast)]

noips schrieb:
> O_o schrieb:
>> (BTW: hast du das Simuliert?)
>
> Ja, in der Simulation läuft alles wie erwartet! Das ist es ja.

Ich habe mal die Sensitivity List von dem angesprochenen Prozess durch 
Emacs (das geht damit automatisch!) neu erstellen lassen:

ns_decoder : process (RST, cnt, rts_master_ar_s(0), state) begin

Wobei ich eher an dem generellen Aufbau arbeiten würde, anstatt das 
jetzt auf Teufel komm raus zum laufen zu kriegen!

[noips (Gast)]

O_o schrieb:
> so wie man es gelernt
> hat (Ein-, Zwei- oder Dreiprozess-Schreibweise),

so habe ich es auch gelernt. Es ist die Zweiprozess-Schreibweise.


O_o schrieb:
> aber nicht so wie bei dir^^

Was ist denn da falsch, deiner Meinung nach?

[Geeeerd (Gast)]

Das geht auf jeden Fall schonmal garnicht:

use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use ieee.numeric_std.all;

arith und unsigned sind nicht genormt und dürfen nicht mit numeric std 
zusammen benutzt werden!

[noips (Gast)]

Geeeerd schrieb:
> arith und unsigned sind nicht genormt und dürfen nicht mit numeric std
> zusammen benutzt werden!

Lattice Diamond hat mir aber nicht mal eine Warnung angezeigt. Der kommt 
wohl damit zurecht.

[noips (Gast)]

Jetzt ist es wieder in Ordnung, eine kleine Änderung im Code und die 
Hardware läuft wieder wie gewollt. Hab jetzt in Zeile 384

statt 'if cnt >= 2' nur 'if cnt = 2' geschrieben und das war es. 
Hoffentlich! Auf jeden Fall läuft das ganze jetzt schon eine Weile so 
wie ich es mir vorstelle.

Danke für eure Mühe!