[CALU] Re: Reset in COMB-Logik

  • From: Günther Wimpassinger <e0525147@xxxxxxxxxxxxxxxxxxxx>
  • To: calu-ss2010-tuwien@xxxxxxxxxxxxx
  • Date: Fri, 7 May 2010 10:17:30 +0200

Zitat von Elshuber Martin <e9825286@xxxxxxxxxxxxxxxxxxxx>:

Ich habs jetzt mal ins comb gegeben, da das reset signal ja synchron
ist. Das reset wird also erst bei der nächsten taktflanke übernommen.
ein a reset würde ins sync kommen und sofort ausgeführt

Da wir keinen expliziten externen Reset haben, bleibt mir nichts
anderes übrig, als einen synchronisierten Reset zu erzeugen. Ich
versuche hier zwischen synchronen und synchronisierten Reset zu
unterscheiden. Ein synchronisierter Reset ist ein Signal, dass mit
steigender Taktflanke gesetzt wird.
e.g. "if rising_edge(clk) then reset_signal <= reset_next end if;"

Unter sychronen/asynchronen Reset versteh ich, wann das Resetsignal
übernommen wird.
Synchron:
if rising_edge(clk) then
 if reset=RESET_ACTIVE then
   -- init
 else
   -- clock process
 end if;
end if;

Asynchron:
if reset=RESET_ACTIVE then
 -- init
elsif rising_edge(clk) then
 -- clock process
end if;

das problem beim sync in der jetzigen logik sehe ich dahingehend, das
es im moment (zimindest mit der jetzigen reset logik) nicht ganz klar
ist wann das reset endet
bei dem takt an dem das reset runter geht oder einen takt danach.

ich würde die reset logic noch dahingehend ändern das sie bei der
fallenden flanke auf 0 geht. und das reset im sync machen

Das Problem ist, dass wir (und Quartus) nicht wissen, welches Signal
schneller am "Ziel" ist. Der Takt oder der synchronisierte Reset. Wenn
wir das Problem Quartus überlassen wollen, müssen wir den Reset
ebenfalls bei "rising_edge(clk)" übernehmen, also einen synchronen
Reset (dann muss auch nur clk in der process sensivity list sein).

Wenn wir einen asynchronen Reset haben wollen, sollte dass natürlich
noch so adaptiert werden, dass das Reset-Signal rechtzeitig vor der
nächsten Taktflanke überall inaktiv ist. Da ist die von dir
vorgeschlagene negative Taktflanke die wohl beste Lösung.

wir sollten uns aber auf jeden fall auf eine einheitliche
vorgehensweise einigen.

Sollten wir, jedoch ist die Lösung über den "comb" process nicht
üblich. Auch hier wissen wir nicht, ob die Taktflanke kommt, nachdem
oder bevor das Resetsignal seinen neuen Wert bereits angenommen hat.
Dabei geht es um die Laufzeitunterschiede zwischen Reset-Signal und
Taktsignal von den jeweiligen Quellen zu den Zielen.

Ich hatte mal eine längere Diskussion mit J. Lechner über diese Thema.
Und wenn wir wirklich sicher gehen wollen, dass die Timings passen,
bleibt uns nur ein synchronisierter synchroner Reset.

g martin

ps.: wie ist es die in sigsys2 gegangen?
Danke, hervorragend, und selbst?


Other related posts: