Sehr seltsames Verhalten eines VHDL-Designs, Bitte um Hilfe

Gast #2573133
Lesenswert?

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)
1
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.
1
if state = START and next_state = CONVERT then --and sChanSelFlag = '1' then
2
  
3
  --if sChanNum2 < 7 then
4
  --  sChanNum2 <= sChanNum2 + 1;
5
  --  sPackStart <= '1';
6
  --else
7
  --  sChanNum2 <= 0;
8
  --  sPackStart <= '0';
9
  --end if;
10
  if sChanNum2 = 7 then--"0111" then
11
    sChanNum2 <= 0;--"0000";
12
    sPackStart <= '0';
13
  else
14
    sChanNum2 <= sChanNum2 + 1;
15
    sPackStart <= '1';
16
  end if;
17
    
18
  --sChanSelFlag <= '0';
19
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
1
when SAMPLE =>    if cnt = SAMPLE_DELAY and rts_master_ar_s(0) = '1' then next_state <= START;
2
          else next_state <= SAMPLE;
3
          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!
Angehängte Dateien:
Gast #2573225
Lesenswert?

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?)
Gast #2573246
Lesenswert?

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!
Gast #2573545
Lesenswert?

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!
Gast #2573662
Lesenswert?

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!

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren