Lattice Diamond - Fehlermeldung - State machine - Verilog - Brauche Hilfe

[Steffen H. (avrsteffen)]

Hallo liebe Gemeinde
Ich bin mit meinem Latein erstmal am Ende.
Folgendes:
Arbeitsumgebung - Windows10
Tool - Lattice Diamond V3.12
FPGA - XP-Serie LFXP3C-3T144C

Problem - Ich arbeite gerade an einer State-machine für ein 6800er 
Interface zum FPGA. Darin enthalten eine State machine um Kommandos auf 
einem 8bit Interface (6800er) mit /RW, /CD, /E, /CS entgegen zu nehmen, 
auszuwerten und entsprechende Aktionen durchzuführen.

Ich habe mal die betreffende Source beigegeben.

Auf einem anderen FPGA läuft das ganze schon. Leider meckert Diamond mir 
folgendes an.

ERROR - CL172 :"M6800_interface.v":64:10:64:18|Only one always block can 
assign a given variable cmd_stage[2:0]

Ich habe doch aber nur einen Prozess wo cmd_stage etwas zugewiesen 
wird.
Ich sehe leider den Wald vor Bäumen nicht mehr.

Wer kann mir da helfen und sagen woran es etwa liegen könnte?
Ob Lattice Diamond mit task nicht klar kommt oder bin ich es - ooh.

Wäre echt toll diesen Fehler gelöst zu bekommen.

[Steffen H. (avrsteffen)]

Jetzt hat der mal wieder das Projekt als .zip nicht genommen..

[User (Gast)]

Schau mal, du schreibst auf cmd_stage von verschiedenen tasks, das lässt 
sich leider nicht synthetisieren.

[Steffen H. (avrsteffen)]

Danke für deine Antwort User.
Ja das stimmt. Ich schreibe von vielen Task's auf cmd_stage. Allerdings 
werden diese task's doch nur aus einem always Block aufgerufen. Das 
dürfte doch für die Synthese nicht verboten sein.

Synopsis bemängelt ja genau dies - das es von mehr als einem always 
Bloch auf cmd_stage zugegriffen wird.

Aber ich sehe nicht wo!?

[Tim (Gast)]

Konstanten identisch zu Tasks nennen, ist auch nicht empfehlenswert.

[Steffen H. (avrsteffen)]

Tim schrieb:
> Konstanten identisch zu Tasks nennen, ist auch nicht empfehlenswert.

Wo denn?
-> Ah, okay - ich hab es gesehen. Ich werde dies umbenennen. Task -> mit 
task_ davor.

Aber dies ist trotzdem nicht der Grund. Nur etwas unschön vielleicht.
Trotzdem Danke Tim

[Steffen H. (avrsteffen)]

So, ich glaub ich habe den Fehler gefunden!

// =============================================================================
// command stages one-clocked always block
// =============================================================================
always @(posedge i_clk)
  if (i_reset) 
    begin
    cmd_stage <= (STAGE_CMD_IDLE);  
    sig_wr_en <= FALSE;      
    col_start_addr <= 'd0;    
    col_end_addr <= HORZ_VISIBLE;    
    row_start_addr <= 'd0;    
    row_end_addr <= VERT_VISIBLE;    
    col_addr <= 'd0;    
    row_addr <= 'd0;    
    r_control <= 8'b0000_0000;
    end 
  else 
    begin
      
      case (cmd_stage)
        STAGE_CMD_IDLE:    begin task_stage_cmd_idle();     r_led <= LOW;   end
        STAGE_SET_COL_ADDR: begin task_stage_set_col_addr();   r_led <= HIGH;  end
        STAGE_SET_ROW_ADDR: begin task_stage_set_row_addr();   r_led <= HIGH;  end
        STAGE_READ_RAM:   begin task_stage_read_ram();     r_led <= HIGH;   end
        STAGE_WRITE_RAM:   begin task_stage_write_ram();     r_led <= HIGH;   end      
        STAGE_SET_PAGE:    begin task_stage_set_page();     r_led <= HIGH;   end
        STAGE_DISP_CONTROL:  begin task_stage_disp_control();  r_led <= HIGH;   end
        STAGE_SET_FUNCTION:  begin task_stage_set_function();  r_led <= HIGH;  end
        default:      task_stage_cmd_idle();
      endcase        
    end

Ich habe hier eine State Machine um über das Command Register die 
entsprechende Aktion auszuführen. Genau da war alles okay! Obwohl gerade 
dies ( cmd_stage ) Synplify angemeckert und mit einer ERROR Meldung 
abgebrochen hat.

Tatsächlich scheint es aber an der Zweiten State Machine (für den 
Interface FiFo) zu liegen! Denn da ist mir tatsächlich ein Fehler 
unterlaufen als ich die default Klausel in der FULL-CASE Anweisung 
noch nachgetragen habe, da Synplify auch dies angemeckert hat. Dabei 
habe ich den IDLE-STATE von der 1. State Machine verwendet.

FALSCH:

// =============================================================================
// FiFo stages one-clocked always block
// =============================================================================
always @(posedge i_clk)
  if (i_reset) begin
    fifo_stage <= STAGE_FIFO_IDLE;  
    fifo_rd_en <= FALSE;  
    sdr_wr_request <= FALSE;    
    sdr_wr_mask <= 2'b11;
  end else

    case (fifo_stage)
      STAGE_FIFO_IDLE:    stage_fifo_idle();
      STAGE_FIFO_RD_PIPE:   stage_fifo_rd_pipe();
      STAGE_FIFO_RD_DATA:   stage_fifo_rd_data();
      STAGE_FIFO_WR_SDRAM:   stage_fifo_wr_sdram();    
      default:        stage_cmd_idle(); // <---------- FALSCHER Task Aufruf 2.Always Block wo cmd_stage zugewiesen wird
    endcase

RICHTIG:

// =============================================================================
// FiFo stages one-clocked always block
// =============================================================================
always @(posedge i_clk)
  if (i_reset) begin
    fifo_stage <= STAGE_FIFO_IDLE;  
    fifo_rd_en <= FALSE;  
    sdr_wr_request <= FALSE;    
    sdr_wr_mask <= 2'b11;
  end else

    case (fifo_stage)
      STAGE_FIFO_IDLE:    stage_fifo_idle();
      STAGE_FIFO_RD_PIPE:   stage_fifo_rd_pipe();
      STAGE_FIFO_RD_DATA:   stage_fifo_rd_data();
      STAGE_FIFO_WR_SDRAM:   stage_fifo_wr_sdram();    
      default:        stage_fifo_idle(); // <---------- RICHTIGER Task Aufruf
    endcase

Danke nochmal an Tim, denn erst durch die Änderung der Tasknamen gab 
eine Fehlermeldung in der 2. State Machine mit hinweis auf einem nicht 
definierten Task (stage_cmd_idle) da ich den ja umbenannt hatte.

[Sigi (Gast)]

Also jetzt sollte ja wohl klar sein, dass ein Fehler
ausgegeben werden muss. MMn ist aber die Fehlermeldung
falsch/total irreführend, ich hatte als Tools auf die
Mehrfachverwendung des Namens  und nicht auf die des
Signals aufmerksam gemacht.
(rein aus Interesse teste ich Morgen mal das Beispiel
von Oben aus, mal sehen was ISE/Vivado und Quartus
ausspucken)

[Steffen H. (avrsteffen)]

Sigi schrieb:
> (rein aus Interesse teste ich Morgen mal das Beispiel
> von Oben aus, mal sehen was ISE/Vivado und Quartus
> ausspucken)

Das wäre toll. Das interessiert mich auch mal.

[Sigi (Gast)]

Ich habe gerade mal dein Modul in eine TB eingebunden,
die fehlenden Module MULTI, DATA_FIFO und ADDRESS_FIFO
habe ich durch Dummy-Varianten ersetzt.
Läuft ohne Syntax/etc.-Fehler unter ISE14.5 durch.

[Steffen H. (avrsteffen)]

Da hätte die ISE doch eigentlich einen Fehler melden müssen. Denn der 
Zugriff auf "cmd_stage" in einem zweiten Always Block findet ja in der 
fehlerhaften Version definitiv statt.

Das ist aber auch Komisch.

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

Steffen H. schrieb:
> Das ist aber auch Komisch.
Wenn ich da TB lese: in der Simulation juckt das erst mal nicht. Denn 
bei einer Kollision kommt beim std_logic dann einfach die 
Auflösungstabelle zum Einsatz. Und schlimmstenfalls kommt dann ein X 
dabei raus.
Nur die Implementierung wird schiefgehen, weil der Synthesizer die 
"Multiple Drivers" eben nicht zum X auflösen kann.

[Sigi (Gast)]

Stimmt, hast recht: ich hatte Gestern ja nur ein
TB drumrum gebaut, Mehrfachzugriffe werden dort
ja ignoriert. Für ein synthesefähiges Beispiel
war ich zu faul, ausserdem fehlen ja noch drei
Untermodule (MULTI, **_FIFO).

[Duke Scarring (Gast)]

Lothar M. schrieb:
> Denn
> bei einer Kollision kommt beim std_logic dann einfach die
> Auflösungstabelle zum Einsatz. Und schlimmstenfalls kommt dann ein X
> dabei raus.
Deswegen nutze ich für interne Signale sehr gerne std_ulogic. Da wird 
schon vorher gemeckert. Auch in der Simulation...

Duke