Forum Discussion
Altera_Forum
Honored Contributor
15 years agoHi,
Your understanding is more concise than my post. In principle: vendors provide the asynch reset for all registers and provided you disable powerup don't care it will be applied setting registers to zeros except those that you explicitely apply your own values at reset. Additionally designers add reset to most or (in my case) all registers so that they override afterwards. When you apply your own reset you have the option of applying it to async port(in effect Q output) or the the D input(called synchronous). In either case the reset signal should be presynchronised to its clk. To protect a powrup reset counter from reset release timing problems, I will do this: pass pll_lock through two registers on the clk then use last stage tas enable
clked process:
pll_locked_1d <= pll_locked;
pll_locked_2d <= pll_locked_1d;
if pll_locked_2d = '1' then
if count < 3 then
count <= count + 1;
end if;
if count = 3 then
reset <= '0';
else
reset <= '1';
end if;
end if; The pll_locked may act as any async signal, hence it is synchronised first. Thus the counter is protected away from any async reset which could disturb the initial release as bit(0) changes from 0 to 1 One obvious bug is when you apply reset to pll: if the reset depends on pll output clk then the design dies in waiting. my full reset plan road map is this: vendor reset ----> user powre up .....above counter ........................> user feedback .... run time from modules ........................> soft reset ...optional ........................> Hw reset ...optional (use for PLL reset) all four resets then ORed together as master reset then synchronised by two stages per clk domain ---> reset clk1 ---> reset clk2 ...etc finally apply reset at registers either to D (synchronous and requires extra resource) or to asynch port(requires extra routing mainly). The demand on timing would be recovery/removal domain for async application but moves to tsu/th of clk domain if you apply it synchronously.