Yes. Perhaps better, activate clock enable(s) afterwards.
Either way, you may need a hierarchy of clock activation; after reset, you don't want your main clock generator to wait for several cycles of a (stopped) clock...
- Brian
this
For
set/reset).
Guys,
You don't need to stop the clock at all. The reset deassert to clock edge spec only applies when you are trying to change state. So if you reset the flop to 0 and have a 1 sitting on the D input then you must meet timing or it will go metastable. If you have a 0 on the D input then it doesn't matter if you meet timing. The flop will stay at 0.
Most designs already do this. When an ethernet interface comes out of reset
it doesn't suddenly start ethernetting, It waits for the CPU to write setup
and other data before it does anything. That means that once all of its flops
are in reset state then they all have that reset state applied to their D inputs until the first cpu write.
You can deassert a asynchronous reset at any time as long as your asynchronous reset system is backed up with a synchronous one provided by the mission mode logic. You do have to be careful with the cpu or any other block that self starts but thats easy to deal with.
John Eaton
--------------------------------------- Posted through
I know. But I was being a little facetious, after one occasion when I shot myself in the foot with a synchronous reset for a DLL...
- Brian
I know. But I was being a little facetious, after one occasion when I shot myself in the foot with a synchronous reset for a DLL...
- Brian
(snip)
More specifically, if your FFs have a clock enable input, and you can be sure that they are not enabled as they come out of reset, then you don't have to worry about the clock timing.
There has to be at least one FF with the enable determined though outside logic, but that should be usual in the case of a processor.
-- glen
Okay, long post - this should probably go somewhere else, but here's my reponse - it's some ideas that I've often thought of when seeing this advice like this, but never get "pen to paper" as it were.
Thinking about resets are good, and having a good strategy, very important, but I disagree with a lot of this advice. And this type of advice been coming out of the FPGA companies for a while.
But here's my 4 cents. (Too long for just 2 cents.)
I come from an ASIC background - where logic's cheap. ( I know this is an FPGA newsgroup - bare with me. )
There, for all of our designs we used a global resets streategy, which ASYNCHRONOUSLY reset FFs.
i.e. in verilog:
Example 1.
reg foo; always @( posedge clk or negedge reset_n ) if( ~reset_n ) foo
Mark,
Nice write-up! In the end, if you count up all the time (money) spent deter= mining AND VERIFYING what does not NEED to be reset, you'd have been better= off resetting everything to start with, and only pulling out the reset whe= re it kills your utilization (by kill, I don't mean raises util from 85% to= 86%, I mean it doesn't fit!).=20
The pipe-lining/retiming trick for handling fanout on the synchronous reset= also works great for synchronously deasserted asynchronous resets!
When coding a process that has some registers reset and others not, if you = use the familiar "reset ... elsif clock ..." structure, your fanout on rese= t may not be reduced, because every register that saved a reset, added a cl= ock enable (or another input to existing clock enable logic).=20
When I have both reset and non-reset signals/variables in the same process = (e.g. ram arrays, etc.), I use the following structure to avoid clock disab= le on non-reset signals/variables:
process (clk, rst) is begin clocked: if rising_edge(clk) then -- logic assignments here end if clocked; reset: if rst then=20 -- reset assignments here end if reset; end process;
Although this style works fine for the general case (when everything is res= et), I do not use this style unless I actuall need it. The reason is, in th= e conventional reset elsif clock structure, you will get synthesis warnings= (from synplify at least) about feedback multiplexers on non-reset register= s. You won't get those warnings for them if you use the method above. This = also makes the above approach rarer, which stands out for the reviewer, whe= re it gets extra attention to make sure that everything that should (can?) = be reset is reset.
The same clock enable problem also happens when you use an "if reset else l= ogic" structure for a synchronous reset. Nothing after that "else" executes= when reset is true, which results in extra clock enable logic on non-reset= registers. Use a similar approach to the above, by moving the (synchronous= ) reset assignments to their own if-statement just before the end of the cl= ocked if-statement:
process (clk) is begin if rising_edge(clk) then -- logic assignments here if rst then -- reset assignments here -- to avoid clock enables -- on non-reset registers end if; end if; end process;
Strange how I didn't see any of this in that white paper written by the "ex= perts"...
Andy
Awesome, thanks! Seems to me this makes it a lot easier to reason about: you just give every variable or signal an initial value which is loaded during bitstream load and let the configuration-clock-based GSR handling deal with the rest. Make sure PLLs and DCMs start up after GSR is deasserted and that everything uses a clock downstream of a PLL or DCM (and perhaps introduce some BUFGCEs) and everything should be OK?at least, for my application it?s easy enough to things that way. Clock domain crossings might come up in either order, but that?s pretty easy to deal with.
Chris
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.