Hallo berndl:
> und wenn du dein ready dazu benutzt, dein Additionsergebnis zu
> validieren? Also etwa so: add_out <= add_result when ready='1' else
> x"00000000";
> Damit ist dein Ergebnis nur im richtigen Cycle validiert.
Aber das verlangt ja auch schon wieder, dass der richtige Zeitpunkt
validiert ist. Das ist ja dann das gleiche Problem.
> Abgesehen davon halte ich so einen Design fuer grenzwertig. Das versteht
> in einem halben Jahr kein Mensch mehr.
Doku, Doku, Doku. Dann kann man wieder rein kommen. Ich verstehe mein
Sachen schon selbst sehr viel früher nicht mehr. Dafür habe ich mir
angewöhnt die Beweggründe für einen Lösungsansatz und die Umsetzung gut
zu beschreiben.
> Wie faengst du denn den Fall ab,
> dass deine Adder-Inputs zum falschen Zeitpunkt flippen? Dann hast du
> auch erst wieder nach soundsovielen Zyklen ein gueltiges Ergebnis und
> damit deine FSM komplett auf's Kreuz gelegt (und der Simulator weiss
> davon auch wieder nichts...).
Die Eingänge einer Multicycle-Logik müssen auf jeden Fall gelatched
sein. Solle ein "interrupt" mitten in eine Berechnung fallen, dann muss
der Berechnungsschritt natürlich wieder von vorne beginnen. Das ganze
ist dann weder vom Timing noch von Gesamtsystem grenzwertig.
> Also ich wuerde das sauber pipelinen. Damit koennte z.B. der Adder auch
> einfacher/kleiner werden (Resource-sharing in den Pipeline-Zyklen)
Das geht leider von den Systemanforderungen nicht.
Hallo Duke,
> Ich würde mal ein after xx ns am Ausgang deines kombinatorischen
> Blockes mal probieren. Das sollte die Synthese nicht aus dem Tritt
> bringen.
Ich werde es mal probieren. Es sollte mich aber wundern wenn das geht.
Man bräuchte halt so ne Art
für VHDL.
Thread beobachten
Seitenaufteilung abschalten