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.
Jetzt hat der mal wieder das Projekt als .zip nicht genommen..
Gast
#6789301
Schau mal, du schreibst auf cmd_stage von verschiedenen tasks, das lässt sich leider nicht synthetisieren.
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!?
Gast
#6789848
Konstanten identisch zu Tasks nennen, ist auch nicht empfehlenswert.
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
So, ich glaub ich habe den Fehler gefunden!
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
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:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
RICHTIG:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
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.
Gast
#6790035
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)
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.
Gast
#6792927
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.
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.
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.
Gast
#6793777
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).
Gast
#6794174
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
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.
