Ich hänge jetzt seit mehreren Tagen an einem Problem mit meinem FPGA
Design. Ich habe eine Statemachine programmiert und dabei dem Signal
direkt einen Initialen Wert verpasst:
1
type DDRCState is (DDRC_INIT, DDRC_IDLE, DDRC_ACTIVE, DDRC_READ, DDRC_WRITE, DDRC_POST_WRITE);
2
signal ram_state : DDRCState := DDRC_INIT;
In der Simulation funktioniert alles wie gewünscht aber in Hardware
passiert einfach nichts. Komischerweise funktioniert es wenn ich den
Startwert auf DDRC_IDLE gesetzt habe.
Nach tagelanger Fehlersuche scheint das Problem nun darin zu liegen,
dass das Synthesetool (Lattice Synthesis Engine) diese Art der
Initialisierung nicht oder fehlerhaft unterstützt. Nach meinen
Experimenten scheint das Problem erst ab einer gewissen Komplexität der
Statemachine aufzutreten, bei kleinen Test Statemachines hat alles wie
gewünscht funktioniert. Das Problem tritt auch nur bei One-Hot
Encodierten States auf, was ja zumindest Sinn macht wenn alle Bits auf 0
starten.
Was ich nun eigentlich Suche ist eine Quelle in der nicht unterstützen
Features zu finden sind. Irgendwie kann es ja nicht sein das bei so
einer groben Einschränkung nichtmal eine Warnung oder Hinweis aus dem
Synthese Tool kommt. Ich habe den gesamten Log mehrfach studiert und die
einzige etwas merkwürdige Zeile ist diese hier, die direkt nach dem
Extrahieren der Statemachine kommt:
Scheint fast so als ob dort irgendeine Warnung ausgegeben werden sollte,
aber das irgendwie nicht richtig funktioniert hat.
Sind eigentlich nur die Lattice Tools so voller Stolperfallen oder ist
das auch bei anderen Herstellern so? Vor diesem Fehler hab ich eine
Woche gesucht um herauszufinden, dass das Synthesetool das CS von der
SPI Komponente auf das globale Reset Netz gemappt hat und mir dann die
IPs von Lattice resettet hat, obwohl diese an einem anderen Reset
angeschlossen waren.
Von Lattice gibt's ja je nach Familie ein eigenes
Synt.Tool. Ich kenne nur wenige der Lattice-FPGAs,
aber Dein Problem mit FSMs bzw. deren Kodierung
kann ich nicht nachvollziehen. Wann immer ein
Problem auftrat, dann lag's eindeutig an meinem
Code bzw. fehlerhafter Umsetzung.
Auch "lange" FSMs werden nach meiner bescheidenen
Erfahrung korrekt umgesetzt.
Meines Wissens sind Initialzuweisungen grundsätzlich nicht so richtig
synthesefähig. Gib dem Ding lieber ein Reset-Signal, was du beim Start
triggerst, oder codiere den initialen Zustand mit Nullbits.
Sigi schrieb:> Auch "lange" FSMs werden nach meiner bescheidenen> Erfahrung korrekt umgesetzt.
Bei meinen Tests bedeutet "lang" jetzt, dass die Synthese die
Statemachine erkennt und diese extrahiert. Im Log taucht dann ein
"Extracted state machine for register xxx" auf. Für die Test
Statemachines kam das nicht.
S. R. schrieb:> Meines Wissens sind Initialzuweisungen grundsätzlich nicht so> richtig> synthesefähig. Gib dem Ding lieber ein Reset-Signal, was du beim Start> triggerst, oder codiere den initialen Zustand mit Nullbits.
Mit Reset ist bisher auch die einzige Variante wie ich es ans Laufen
gekriegt habe. Eigentlich schade, denn der FPGA kann initiale
Registerwerte beim Start laden.
S. R. schrieb:> Meines Wissens sind Initialzuweisungen grundsätzlich nicht so richtig> synthesefähig
Kenne bei weitem nicht alle Tools, aber
sowohl Xilinx', Altera's, Lattice' als auch
Microsemi's Synt.Tools beherschen seit Jahren
(>10?) die Initialisierung von Signalen.
Sigi schrieb:> Kenne bei weitem nicht alle Tools, aber> sowohl Xilinx', Altera's, Lattice' als auch> Microsemi's Synt.Tools beherschen seit Jahren> (>10?) die Initialisierung von Signalen.
Trifft das auch auf alle Typen von Signalen zu? Ich habe zumindest
verifiziert das die Initialisierung von std_logic richtig synthetisiert
wird. Bei einem Integer Signal
1
signal refresh_counter : integer range 0 to 65536 := 15;
wird beim Synthetisieren zumindest eine Warnung ausgegeben:
1
35001779 WARNING - Initial value found on instance \com/ram_ctl/refresh_counter_i0 will be ignored.
Hab es nicht in Hardware getestet aber ich denke mal der Counter wird
bei 0 starten. Wenn ich Synplify statt LSE für die Synthese benutzt
gibts eine ähnliche Warnung für die Statemachine. Hier
(Beitrag "Re: Warnung bei Statemachine (Synplify / IspLever)") wird behauptet,
dass wäre eine Einschränkung der kostenlosen Version.
Kenne das Verhalten von Lattice Diamond/Synplify Pro L-* für Mach XO2
Bausteine. Synplify erzeugt dazu dann Meldungen wie:
Initial value is not supported on state machine
STATE_MACHINE_REGISTER_NAME.
Behelfe mir in der Regel mit einem expliziten reset auf den gewünschten
"INIT-Zustand"
Bei anderen/"normalen" Registern funktioniert die Initialisierung
definitiv.
Sebastian V. schrieb:> Trifft das auch auf alle Typen von Signalen zu?
Für LSE würde ich mal ja sagen. Hab's gerade mal
mit Synplify versucht (XO und XO2), sowohl bei
std_logic, integer als auch FSM wird der initiale
Wert korrekt gesetzt (im physical Viewer nachgeprüft
und im Report nachgelesen).
Mit XO/XO2 kenne ich mich jetzt nicht so aus,
aber mit ECP (1/2/3) gab's eiglich nie Probleme,
wenn doch dann lag's immer an mir.
Sigi schrieb:> Hab's gerade mal> mit Synplify versucht (XO und XO2)
Hast du auch die Free Version? Zumindest bei mir gibt es von Synplify
direkt die gleiche Warnung die ah-ed.de schon genannt hat.
Sigi schrieb:> im physical Viewer nachgeprüft> und im Report nachgelesen
In welchem Report kann man das Nachlesen und wo sieht man das im
Physical Viewer?
Sebastian V. schrieb:> Hast du auch die Free Version?
Ja, zZ habe ich keinen Zugriff auf eine
Prof.Lizenz.
Sebastian V. schrieb:> In welchem Report kann man das Nachlesen und wo sieht man das im> Physical Viewer?
Z.B. unter Reports, auf <Process Reports\SynplifyPro>.
Als Beispiel bei mir:
@N: FX493 |Applying initial value "10" on instance state_reg[1:0]
@N: FX493 |Applying initial value "0101" on instance buffer1_reg[3:0]
Im Phys.Viewer steht's nicht direkt drin, Du musst Dir
die Werte per "Hand" rauslesen: Jedes Bit wird in einem
Slice abgelegt, am jeweiligen FF steht entweder SET oder
RESET. Je Signalgruppe erhält man so den Initwert.
Sigi schrieb:> Z.B. unter Reports, auf <Process Reports\SynplifyPro>.> Als Beispiel bei mir:>> @N: FX493 |Applying initial value "10" on instance state_reg[1:0]> @N: FX493 |Applying initial value "0101" on instance buffer1_reg[3:0]
Kann ich hier so nicht nachvollziehen. Bei mehreren Statemachines
erhalte ich hier nur eine "Initial value is not supported on state
machine ram_state" Warnung. Ich gebs jetzt auf und baue einfach einen
Reset ein.
Moin,
Sebastian V. schrieb:> Mit Reset ist bisher auch die einzige Variante wie ich es ans Laufen> gekriegt habe. Eigentlich schade, denn der FPGA kann initiale> Registerwerte beim Start laden.
Hmm, auch so ein VHDL-Klassiker, der immer wieder auftaucht.
Wie die Altera-Leute immer den asynchronen Reset propagieren (weil sie
es so gelernt haben), hast du mit den Xilinxern die Diskussion, warum
Initialwerte 'verboten' sind..
Dem Ganzen kann man via MyHDL etwas aus dem Weg gehen. Aber das ist auch
so ein Thema..
Auf jeden Fall empfiehlt es sich, die Initialwerte bei grossen Designs
komplett zu vermeiden, wenn mal plätzlich einer das Ding in nen ASIC
kloppen will. Ausser natürlich bei nem synthetisierten Boot-ROM :-)
Strubi schrieb:> wenn mal plätzlich einer das Ding in nen ASIC kloppen will.
Dann kannst du aber auch gleich den Lottoschein auspacken. Denn solche
Glücksträhnen muss man ausnutzen... ;-)
Prinzipiell können die Lattice-FPGA aufgrund ihrer SRAM basierten
Struktur natürlich beliebige Initialwerte, allerdings braucht es den
richtigen Synthesizer dafür. Augenscheinlich machen die freien Tools das
nicht.
Lothar M. schrieb:> Prinzipiell können die Lattice-FPGA aufgrund ihrer SRAM basierten> Struktur natürlich beliebige Initialwerte, allerdings braucht es den> richtigen Synthesizer dafür. Augenscheinlich machen die freien Tools das> nicht.
SRAM-Basiert ist ja nicht das Problem, sondern
ob die FFs der jeweiligen FPGAs (CPLDs?) auch
initialisieren lassen. Meine ersten Schritte
waren auf FPGAs ohne Initialisierungmöglichkeiten
(weiss aber nicht, ob es am FPGA selber lag oder
das Synt-Tool das so beschränkte). Das liegt
aber schon ewig zurück, zum Glück!
Sigi schrieb:> SRAM-Basiert ist ja nicht das Problem, sondern> ob die FFs der jeweiligen FPGAs (CPLDs?) auch> initialisieren lassen.
Ich wüsste keines, bei dem das prinzipiell nicht ginge. Nur die
Synthesizer unterstützen das auch nach langer Zeit Joch nicht alle. Den
Grund kennen allein die Hersteller...