Hallo, ich hab eine "Statemaschine" geschrieben, um später eine Firmware auf ein BE, über ein FPGA zu laden. Kurz zur Erklärung des Programmcodes: Über ADDR werden die indirekten Adressen ausgewählt und mittels HDATA wird den Adressen ein Wert zugewiesen. Zunächst werden 2 Register ("PLL_HI" und "PLL_LO") beschrieben um danach in einen Wartezustand zu gehen. Dann werden weitere Register beschrieben, bis irgendwann ein Register "EIRQFLG" abgefragt wird (ob Bit 10 = 1 ist) usw. Die Zustände "wait" musste ich reinsetzen, da ansonsten ModelSim gleichzeitig lesen und schreiben wollte. Das "Problem" an der ganzen Sache ist das HDATA ein Tristate sein muss, da: 1. verschiedene Register über HDATA abgefragt werden 2. Das BE bei erfolgreichen Laden der Firmware , ein Signal zurückliefert und die "Statemaschine" dann erst weiterläuft. Nach einigen hin und her hab ich das ganze eigentlich auch zum laufen bekommen (dachte ich). Die "Behavioral Simulation" funktioniert auch wie gewollt --> wave1.do Wenn ich allerdings das ganze mittels "Post-Rout Simulation" durchlaufen lasse, macht die "Statemaschine" was sie will. ---> wave2.do Wenn die "Statemaschine" in bestimmten Zuständen ist, liegen die Adressen nicht an bzw. die Daten werden über HDATA bereits geschrieben bevor überhaupt die Adresse anliegt. Daher meine Frage. Was mach ich falsch? Ich hab in verschieden Foren u.a. auch hier gelesen, dass man Tristates, bevor man diese lesen möchte erst mit 'z' "hochohmisch" machen muss. Das ganze läuft wie gesagt bei der "normalen" Simulation ohne Probleme, allerdings bei dieser "Post-Route" Simulation überhaupt nicht. Ich bedanke mich schonmal im vorraus für die Hilfe. Gruss Andreas
@ Andreas Hofmann (forrester) >Was mach ich falsch? Ich hab in verschieden Foren u.a. auch hier >gelesen, dass man Tristates, bevor man diese lesen möchte erst mit 'z' >"hochohmisch" machen muss. Logisch, denn sonst treibt dein FPGA ja die Ports, und du liest die Werte zurück, die du ausgibst. >Das ganze läuft wie gesagt bei der "normalen" Simulation ohne Probleme, >allerdings bei dieser "Post-Route" Simulation überhaupt nicht. Vergiss die "Post-Rout" Simulation. Zeitverschwendung. Ein sauberes synchrones Design braucht nur die Behavioural Simulation. MFG Falk
sm_adv212_encode.vhd Zeile 85 : counter ist vom Typ std_logic- wieso ist das ein counter? Zeile 102 : wieso schreibst Du start in die Sensitivity-Liste? Zeile 103 : warum nimmst Du eine Variable ??? Zeile 155: warum nicht others=> ? Zeile 406: keine Konstanten direkt reincoden! 422, 429, 433 ebenso Deine FSM ist der Hammer! Leider ist das ganze Design asynchron. Bsp.: immer noch sm_adv212_encode.vhd: Zeile 451: if (VALID = '1') and (HOLD = '0') then Abfrage eines externen Signals in der FSM -> asynchron, da nicht eingetaktet. Und übrigens, alle Signale die in Deiner FSM generiert werden laufen teilweise über riesige Kombinatorik bis sie zum Ausgang gelangen. Ich würde dringend raten sämtliche Signale nochmal über Register zu führen.
@Mark Zeile 85: counter ist einfach nur ein Signalname oder worauf willst du hinaus? Zeile 102: Start steht deshalb in der Sensitivitätsliste, da es in einen anderen Process gesetzt wird und somit der process "zaehler" gestartet wird, d.h. wäre es nicht darin würde i nie hochgezählt werden. Zeile 103: hab ich mittlerweile zum Signal gemacht, allerdings das selbe Ergebnis > Zeile 155: warum nicht others=> ? > > Zeile 406: keine Konstanten direkt reincoden! 422, 429, 433 ebenso > Warum in Zeile 155 others=>? Hab es mittlerweile als extra Zustand eingefügt, leider immer noch das selbe Ergebnis Warum darf man keine festen Hex-Werte reinschreiben? Wäre mir neu Ich weiss, das es asynchron läuft, ist so gewollt. Das die Kombinatorik riesig ist, hab ich auch bereits festgestellt. Da allerdings die Register vom BE vorgegeben sind und ich direkt auf diese schreiben muss, weiss ich nicht was es bringen soll erst andere Register zu beschreiben.
Hi Andreas, OK, ich muss also weiter ausholen: "Ich weiss, das es asynchron läuft, ist so gewollt." Tut mir leid, an der Stelle brauch ich eigentlich nicht weiter schreiben, da Dein Design so vermutlich nie funktionieren wird. Ich versuchs trotzdem. 1) counter hat bei Dir genau 1 Bit. Ein Marketing-Experte würde natürlich sein Flip-Flop als Counter verkaufen, ich finde aber das das hier nicht passt. 2) bei 'start' liegst Du daneben. Du hast nicht verstanden was ein Prozeß ist und wie er funktioniert. 3) Zeile 155: wenn sich HDATA mal um 1 bit ändert (Datenbreite) musst Du hier Deinen Code ändern, mit others=>'Z' hast Du das ein für allemal erledigt 4) klar kannst Du Konstanten direkt reinschreiben, aber dann frage ich mich warum Du Dir die Mühe gemacht hast ein wunderschönes Package zu schreiben? 5) der letzte Punkt: wenn ich Dich richtig verstanden habe, sollen die Signale ADDR, RD, WE, CS usw. an Pins des FPGAs geführt werden und zu einem externen Bauelement gehen. Wie willst Du mit Deiner VHDL-Beschreibung das Timing einhalten? Bei 1 MHz Takt ist das sicher alles unproblematisch aber wenns mehr wird? Hast Du mal die Laufzeit von den FFs Deiner FSM zu den PADs gemessen? Es wäre ziemlich clever, ADDR, HDATA und die CTRL-Signale am Ende nochmal durch Flip-Flops zu jagen. Warum? Du hast dann das Timing mit nur einem CLock-Constraint im Griff. Und wenn die besagten Register alle im IOB liegen haben sogar alle Signale garantierte und gleiche Clock- to -Output Zeiten an den FPGA-Pins! Ist das nichts?
und was ist eigentlich im State <wait0_s> mit dem start-Signal? Das fehlt hier. Was soll das Synthesetool nun machen? Ein Latch?!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.