[CALU] Re: Reset in COMB-Logik

  • From: Elshuber Martin <e9825286@xxxxxxxxxxxxxxxxxxxx>
  • To: calu-ss2010-tuwien@xxxxxxxxxxxxx
  • Date: Fri, 07 May 2010 10:36:34 +0200

Am 07.05.2010 10:17, schrieb Günther Wimpassinger:
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.
ich kenne mich da nicht wirklich aus, klingt aber alles logisch, ich denke mit der negativen flanke sollte wir auf der sicheren seite sein
ich werd meinen teil umbauen

g martin

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




Other related posts: