OpenCores
URL https://opencores.org/ocsvn/socgen/socgen/trunk

Subversion Repositories socgen

[/] [socgen/] [trunk/] [doc/] [src/] [guides/] [reset_sys_design.html] - Blame information for rev 27

Go to most recent revision | Details | Compare with Previous | View Log

Line No. Rev Author Line
1 19 jt_eaton 
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
2 
<html>
3 
<head>
4 27 jt_eaton 
  <meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
5 
  <title>Reset System Design</title>
6 19 jt_eaton 
  <meta name="GENERATOR" content="OpenOffice.org 3.0  (Linux)">
7 
  <meta name="CREATED" content="0;0">
8 
  <meta name="CHANGED" content="20100309;9305300">
9 
  <meta name="KEYWORDS" content="start">
10 
  <meta name="Info 3" content="">
11 
  <meta name="Info 4" content="">
12 
  <meta name="date" content="2008-01-08T12:01:41-0500">
13 
  <meta name="robots" content="index,follow">
14 
  <style type="text/css">
15 
        <!--
16 
                H3.western { font-family: "Albany", sans-serif }
17 
                H3.cjk { font-family: "HG Mincho Light J" }
18 
                H3.ctl { font-family: "Arial Unicode MS" }
19 
        -->
20 
        </style>
21 
</head>
22 
<body dir="ltr" lang="en-US">
23 
<div id="toc__header" dir="ltr">
24 
<p><br>
25 
</p>
26 
</div>
27 
<h1><a name="socgen_project"></a>Design considerations for Reset
28 
Systems<br>
29 
</h1>
30 
<p><br>
31 
<br>
32 
</p>
33 
<p>In a world as fast moving as the semiconductor industry&nbsp; it is
34 
essential that all designers continuously update their knowledge as the
35 
technology changes. It is very easy to become complacent and then
36 
suddenly discover that the techniques that have served you for many
37 
years no longer work.&nbsp; <br>
38 
<br>
39 
</p>
40 
<p>This paper was written to explore some of the mistakes that reset
41 
system designers have made over the years and why they are no longer
42 
true.<br>
43 
</p>
44 
<h3 class="western"><br>
45 
</h3>
46 
<h3 class="western"></h3>
47 
<h3 class="western">Do we really need a reset system? <br>
48 
</h3>
49 
<p>Actually you don't. It is a good design practice to ensure that
50 
there are no dead end states in your logic and that any state will
51 
eventually lead into a valid operating mode. For many years designs
52 
were simple and robust enough that they would function even if they
53 
were enabled without a reset. Then along came embedded processors and
54 
the world became much more complex. I have seen some pretty audacious
55 
attempts to create a watchdog&nbsp; to detect and restart a lost system
56 
but the best that they can do is to improve the odds that the system
57 
will recover. None of them were 100%.<br>
58 
</p>
59 
<p>It is possible that you do not need to reset all the storage
60 
elements in a design. In many cases the data is reloaded shortly before
61 
it is needed and it doesn't care what it was before that time. Some
62 
designers will leave certain storage elements off of the power on reset
63 
because it has no effect on the operation.<br>
64 
</p>
65 
<p>BUT.<br>
66 
</p>
67 
<p>There was a mathematician named Fermat who came up with a theorem
68 
that eventually became known as Fermat's last theorem. It was a simple
69 
little equation that worked in every test case that&nbsp; they threw at
70 
it and they threw a lot of test cases at it. But it took over 350 years
71 
before someone could prove that it would really work in all cases.</p>
72 
<p><br>
73 
If you allow your designers the option to leave storage elements off
74 
the power on reset system then they will come up with these wonderful
75 
little designs that appear to work and they will work in any test case
76 
that you throw at it. But it will take you FOREVER to fully verify that
77 
it will work in all cases.<br>
78 
</p>
79 
<p>You do not need a power on reset system for your logic to work. You
80 
need it&nbsp; in order to verify that your logic works.&nbsp; It takes
81 
longer to verify a design than it does to create it and not providing a
82 27 jt_eaton 
100% known start up condition will make the verification effort that
83 19 jt_eaton 
much harder. All storage elements must be on a reset if only for test
84 
and verification purposes. If you have logic that must function during
85 
a power up reset then put it on a special reset that is only active in
86 
test mode.<br>
87 
</p>
88 
<br>
89 
<h3 class="western">All components must come out of reset on exactly
90 
the same clock<br>
91 
</h3>
92 27 jt_eaton 
That's true, or at least it was back in the 60's.&nbsp; Back then every
93 19 jt_eaton 
component would come out of reset and start "componenting". The reset
94 
system acted like a conductor&nbsp; so that everybody started on the
95 
same beat. Those types of systems are rare today. Most major chips have
96 
one or more microprocessors in side so components come out of reset
97 
only to sit there waiting for the cpu to configure them and get them
98 
started.&nbsp; It doesn't matter what cycle you come out of reset on as
99 
long as you are up and ready&nbsp; before someone else asks you to do
100 
something. <br>
101 
<br>
102 
This has led to two prong approach to reset system design.&nbsp; The
103 
majority of the chip is on a large slow reset distribution&nbsp;
104 
tree&nbsp; that doesn't even try&nbsp; to get&nbsp; everybody reset on
105 
the&nbsp; same cycle.&nbsp; Then you have a second&nbsp; smaller and
106 
faster tree that only resets the cpu and anything else that can&nbsp;
107 
initiate activity.&nbsp; The fast reset is delayed long enough to
108 
ensure that the slow reset is finished before starting the cpu. In
109 
modern designs this can be a significant number of clock cycles. I have
110 
seen repairable memories where you had to hold off starting the cpu for
111 
3000 clocks to ensure that any repair would be finished before the cpu
112 
started.<br>
113 
<br>
114 
<br>
115 
<h3 class="western">You must design an asynchronous reset system<br>
116 
</h3>
117 
Absolutely. Most of the time your mission mode requirements will
118 
dictate that the power on reset system works even in the absence of
119 
clock. If it doesn't then the test engineer will require that all pads
120 
must respond to an async reset in case a board is built missing it's
121 
clock. Asynchronous reset design is essential.&nbsp; A power up monitor
122 
will drive the reset input&nbsp; active&nbsp; as the power is ramping
123 
up. You will not have a clock at this time so the reset system must be
124 
able to work without one.<br>
125 
<br>
126 
<br>
127 
<br>
128 
<h3 class="western">You must design your logic using synchronous design
129 
methods<br>
130 
</h3>
131 27 jt_eaton 
Absolutely. Today's chips are huge. The only way that you can close
132 19 jt_eaton 
timing on a large design is if everyone follows strict synchronous
133 
design rules.&nbsp; The mistake that many of todays designers make is
134 
that they think that because they have to design an asynchronous reset
135 
system that they get an exemption from following the rules for
136 
synchronous design.&nbsp; Sorry guys, it not one or the other its BOTH.
137 
You have to design a asynchronous reset system but you cannot use any
138 
flip flops with an asynchronous reset port.<br>
139 
<br>
140 
The funny thing is that synchronous design methodology is quite
141 
capable&nbsp; of&nbsp; creating an asynchronous reset&nbsp; system and
142 
will actually&nbsp; give you&nbsp; a smaller and faster design that
143 
either of the traditional&nbsp; async only or sync only solutions.<br>
144 
<br>
145 
<br>
146 
<h3 class="western">Don't worry about making the reset system
147 
testable.The test engineer has a tool that will fix any problem in the
148 
back end<br>
149 
</h3>
150 
That used to be true. The first thing a vendor does when they get a net
151 
list is to run a full drc that looks for dft issues. If anybody has any
152 
signals crossing between&nbsp; the async reset port on a flipflop and
153 
either a D or a Q port then it flags it as a violation. So you can
154 
either send it back to the customer and wait a week for them to find
155 27 jt_eaton 
it, fix it, and re-synthesizes or you can eco in a test mux at the flop
156 19 jt_eaton 
and have it fixed in 5 minutes. Everyone took the easy way out.<br>
157 
<br>
158 
But then along came Logic equivalence checking (LEC).&nbsp; The final
159 
routed net list will be sent back and compared with the customers
160 
golden net list and all of these ecos will show up&nbsp; in the report.
161 
Now somebody has check out each and every item in the report&nbsp;
162 
before you can release the masks. It now&nbsp; becomes easier for the
163 
customer to find and fix these errors before synthesis than it is to
164 
deal with thousands of lec errors.<br>
165 
<br>
166 
Besides with the newer processes the days when you could eco in a small
167 
tweak on a routed net list and not have it break something are fast
168 
disappearing.&nbsp; You will eco the rtl code and then re-synthesis and
169 
reroute.<br>
170 
<br>
171 
<br>
172 
<br>
173 
&nbsp;<br>
174 
<br>
175 
<h3 class="western">You must use a sync_reset pragma if you design a
176 
synchronous reset system<br>
177 
</h3>
178 
I cringe whenever I hear someone&nbsp; say this. If you do a
179 
synchronous reset design then you will find that your gate simulations
180 
will not run. Many of your flipflops will never reset to a known value.
181 
They will get a valid clock and the reset in the block will be valid
182 
but synthesis will have combined the reset logic in with the mission
183 
mode logic and it will be distributed throughout the logic cone feeding
184 
the D input. It also uses the flops current state in order to compute
185 
the next state.&nbsp; It creates a situation where if the flop has a 0
186 
or 1 in it then the logic will compute the next state as 0 when reset
187 
is active. However if the flop is unknown as it is at power up then
188 
verilog is unable to figure out the correct next state and it remains
189 
at x.<br>
190 
<br>
191 
This is a simulation only issue as flops in real silicon will always
192 
resolve to a valid state.<br>
193 
<br>
194 
Tool vendors created the sync_reset pragma so that you could tell the
195 
tool not to combine the reset logic with the mission mode logic. You
196 
place it at the very tip of the logic cone and it will remain there in
197 
gates.<br>
198 
<br>
199 
So whats wrong with that?<br>
200 
<br>
201 
The synthesis tool will make a list of all signals that enter the logic
202 
cone along with the relative time it enters before the next clock
203 
edge.&nbsp; If it finds a early arriving signal entering the cone
204 
closer to the tip than a late arriving one&nbsp; then it&nbsp; will try
205 
to remap the logic&nbsp;&nbsp; and swap them so that the late
206 
arrival&nbsp; can&nbsp;&nbsp; move closer to tip.&nbsp; Ideally the
207 
latest signals are moved towards the tip and the early ones are moved
208 
to the rear. <br>
209 
<br>
210 
The reset from a properly designed distribution tree and the feedback
211 
signal from the flop that you are working on will always be two of the
212 
earliest signals. They will get pushed up away from the tip of the cone
213 
simply to make room for the mission critical late signals. This is a
214 
good thing, you want this to happen. <br>
215 
<br>
216 
The problem is that designers think that they must prove that the reset
217 
system works in gate sims. Verilog is a great tool when every node is
218 
in a known state but it is lousy when dealing with unknowns. There are
219 
times like this when it is possible to resolve a X into a known
220 
value&nbsp; and it can't. There are also times when it will resolve an
221 
X to a known value when it shouldn't. The only way to use verilog is to
222 
start with everything in a known state and stop it when anything goes
223 27 jt_eaton 
X.&nbsp; That means there's a problem and nothing downstream from that
224 
X
225 19 jt_eaton 
can be trusted.<br>
226 
<br>
227 
<br>
228 
You do not prove your reset system design in gates sims. You prove the
229 
design in rtl sims and use LEC to prove that gates matches the design
230 
that works.&nbsp; Then you use initial statements to force all flops to
231 27 jt_eaton 
a known state at start up and use gates sims to prove that everything
232 19 jt_eaton 
else works. Verilog gates is the wrong tool to use to verify the reset
233 
system.<br>
234 
<br>
235 
You never use the sync_reset pragma unless you really like big slow
236 
designs.<br>
237 
<br>
238 
<br>
239 
<br>
240 
<br>
241 
<br>
242 
<br>
243 
<br>
244 
<br>
245 
<br>
246 
<h3 class="western">Doing a synchronous reset design adds logic in the
247 
D pathway and will slow down the design<br>
248 
</h3>
249 
<br>
250 
Wrong. Adding logic in the critical path will slow down the design.
251 
Adding it into a non-critical path simply reduces slack in that path.
252 
If you put the reset logic at the very tip of the logic cone then you
253 
are adding it into the critical path and the synthesis tool will move
254 
it up the cone&nbsp; until&nbsp; it is in a&nbsp; safe location.<br>
255 
<br>
256 
Adding a synchronous reset system doesn't really add much logic to the
257 
design. The tools will first locate any mission mode logic that also
258 
forces the flop into the reset state and it will piggyback the reset
259 
system with that logic. You don't add gates , you bump a gate up to add
260 
an extra input.<br>
261 
<br>
262 
<br>
263 
<br>
264 
<h3 class="western">A component must perform&nbsp; reset in one clock
265 
cycle<br>
266 
</h3>
267 
The power on reset is really a slow operation.&nbsp; A typical system
268 
could see:<br>
269 
<br>
270 
<ul>
271 
  <li>Ramp time for power rails</li>
272 
  <li>clock start up time</li>
273 
  <li>pll lock time</li>
274 
</ul>
275 
You are looking at activity that is measured in the milliseconds on a
276 
system clock that is measured in the nanoseconds. Performing a reset in
277 
one clock cycle&nbsp; requires adding logic to every single flipflop<br>
278 
for no good reason. A designer should only add reset logic as a last
279 27 jt_eaton 
resort. The preferred method is to use the existing mission mode logic
280 19 jt_eaton 
to perform the reset. If you have a computational block with a fifty
281 
stage deep pipeline then reset should force it's inputs to 0 and open
282 
all the gates so that every flipflop will be flushed out in 50 clocks.
283 
Better yet would be to have the block feeding your input force it's
284 
output to all 0's during reset.<br>
285 
<br>
286 
Every design should spec a multicycle reset and give the designers the
287 
freedom to reset any way they want as long as it's finished by the end
288 
of the reset pulse.<br>
289 
<br>
290 
<br>
291 
<br>
292 
<br>
293 
<br>
294 
<br>
295 
<br>
296 
<br>
297 
<br>
298 
<br>
299 
<br>
300 
<div id="toc__header" dir="ltr">
301 
<p><br>
302 
</p>
303 
</div>
304 
<h1><a name="socgen_project"></a>How to design the Reset System<br>
305 
</h1>
306 
<br>
307 
<br>
308 
<h3 class="western">1) Write a mission statement<br>
309 
</h3>
310 
The first step in any design task is to write a statement that sums up
311 
what the thing you are designing&nbsp; will do.&nbsp; This is important
312 
because everything after this point must be traceable back to this
313 
statement.&nbsp; The statement will&nbsp; tell you&nbsp; what&nbsp;
314 
steps you must follow. Anything that you cannot trace back to something
315 
in the mission statement is not part of the design<br>
316 
<br>
317 
<br>
318 
The mission statement for the reset system is:<br>
319 
<br>
320 
<br>
321 
<br>
322 
The reset system will force all the nodes in a system or subsystem into
323 
a known good state while&nbsp; a reset trigger is active.<br>
324 
<br>
325 
<br>
326 
<br>
327 
<h3 class="western">2) Define the reset triggers<br>
328 
</h3>
329 
We must now make a list of all the events that will cause us to reset
330 
all or part of the system. Our list is:<br>
331 
<br>
332 
<ul>
333 
  <li>The design has a power monitor chip that provides a low signal
334 
when the supply rails have&nbsp; not been above the limit for a long
335 
enough period of time</li>
336 
</ul>
337 
<ul>
338 27 jt_eaton 
  <li>The design has a soft reset block that can reset any sub block if
339 19 jt_eaton 
its reset flop is set to 1.</li>
340 
</ul>
341 
<ul>
342 
  <li>The clocks must run during reset but the divider has a special
343 
reset input for simulation and testing</li>
344 
</ul>
345 
<ul>
346 
  <li>The design has ieee 1149.1 test logic with a active low trst* pin.</li>
347 
</ul>
348 
<ul>
349 
  <li>The reset signal&nbsp; has a metastable filter to sync it with
350 
the clock.<br>
351 
  </li>
352 
</ul>
353 
The last is important because some designers will forget that the
354 27 jt_eaton 
filtered output is actually it's own separate reset domain<br>
355 19 jt_eaton 
<br>
356 
<br>
357 
<br>
358 
<br>
359 
<h3 class="western">3) Define a known good state<br>
360 
</h3>
361 
We&nbsp; now look at every storage element in the design and define a
362 
safe state for each&nbsp; element of either 1 or 0. Don't cares are not
363 
allowed. If you cannot pick a value then one will be assigned for you.
364 
This task is best performed after the system and board designers have
365 
defined the known good state for the PCA.&nbsp; They will define the
366 
state for all of the pads, the ic design team must define the states
367 
for all internal nodes.<br>
368 
<br>
369 
<h3 class="western">4) Assign storage elements to triggers<br>
370 
</h3>
371 
Once we have a list of all storage element we list any and all triggers
372 
that will force them into a safe mode.<br>
373 
A typical list would list all the flipflops in timer module u12.r567
374 
would be reset by:<br>
375 
<br>
376 
<ul>
377 
  <li>an active high on soft reset bit #23</li>
378 
</ul>
379 
<ul>
380 
  <li>an active low on the power monitor input</li>
381 
</ul>
382 
<ul>
383 
  <li>an active low on the simulation/test reset</li>
384 
</ul>
385 
<ul>
386 
  <li>an active low on the output of the metastable filter</li>
387 
</ul>
388 
<br>
389 27 jt_eaton 
The jtag reset is not included because it doesn't reset the
390 
timer.&nbsp;
391 19 jt_eaton 
Once this step is complete it will provide a map for the reset
392 
distribution tree that you will need. The best way to distribute the
393 
reset over a large design is to use what is called a "synchronous reset
394 
tree".<br>
395 
<br>
396 
<br>
397 
<br>
398 
<br>
399 
<br>
400 
<h3 class="western">5) Select between synchronous or asynchronous reset
401 
system<br>
402 
</h3>
403 
At this point it is easy to see if we need a synchronous or
404 
asynchronous reset system. If your trigger is asynchronous then you
405 
must design a asynchronous reset system. If the trigger can occur
406 
without a clock then you must be able to reset the system without a
407 
clock.<br>
408 
<br>
409 
If the trigger is synchronous then you may design a synchronous reset
410 
system or you may also choose to design a asynchronous one.&nbsp; The
411 
async one will enter reset one&nbsp; cycle&nbsp; before the sync one
412 
but they will both exit on&nbsp; at the same&nbsp; time. <br>
413 
<br>
414 
<br>
415 
<br>
416 27 jt_eaton 
<h3 class="western">6) Select reset style for each flip/flop<br>
417 
</h3>
418 
We now need to select a reset "Style" for each flip/flop from the four
419 
possible reset styles.<br>
420 19 jt_eaton 
<br>
421 
<br>
422 27 jt_eaton 
<ul>
423 
  <li>Synchronous</li>
424 
  <li>Synchronous with output override</li>
425 
  <li>Asynchronous</li>
426 
  <li>Both Synchronous and Asynchronous</li>
427 
</ul>
428 19 jt_eaton 
<br>
429 27 jt_eaton 
If the reset system is synchronous then you may choose any of the four
430 
styles. If it is asynchronous then you cannot use the synchronous style.<br>
431 19 jt_eaton 
<br>
432 
<br>
433 
<br>
434 
<br>
435 
<br>
436 27 jt_eaton 
<img style="width: 800px; height: 600px;" alt=""
437 
 src="../png/reset_fig1.png"><br>
438 19 jt_eaton 
<br>
439 
<br>
440 
<br>
441 
<br>
442 
<br>
443 
<br>
444 
<br>
445 
<br>
446 27 jt_eaton 
<h3 class="western">7) Apply DFT fixes to all asynchronous ports<br>
447 
</h3>
448 
All paths from the Q output of a flip/flop to the asynchronous
449 
reset/preset port of a flip/flop must be disabled during scan testing.
450 
The use of a test mux to do this is not recommended because anytime you
451 
use a test mux you are not testing the circuit as it is used in mission
452 
mode. There will always be at least one point of failure inside the
453 
test mux where scan tests will pass but the IC will not function.<br>
454 19 jt_eaton 
<br>
455 27 jt_eaton 
The recommended method is to gate off the synchronous path with a atg
456 
test signal and then recombine it with an asynchronous reset so that
457 
the async reset it self is still testable. The lib module
458 
cde_asyncdisable is available for this purpose. DO NOT CREATE YOUR OWN
459 
TEST LOGIC.&nbsp; Checking the rtl code to ensure that all asynchronous
460 
resets are testable requires a fairly sophisticated and expensive tool.
461 
Checking the rtl to ensure that all asynchronous resets are properly
462 
connected to a cde_asyncdisable module takes a simple perl script.<br>
463 19 jt_eaton 
<br>
464 27 jt_eaton 
<br>
465 
<br>
466 
<br>
467 
<br>
468 
<br>
469 
<img style="width: 800px; height: 600px;" alt=""
470 
 src="../png/reset_fig2.png"><br>
471 
<br>
472 19 jt_eaton 
<p><br>
473 
<br>
474 
</p>
475 
<p><br>
476 
<br>
477 
</p>
478 
<p><br>
479 
<br>
480 
</p>
481 
<p><br>
482 
<br>
483 
</p>
484 
<p><br>
485 
<br>
486 
</p>
487 
<p><br>
488 
<br>
489 
</p>
490 
<p><br>
491 
<br>
492 
</p>
493 
<p><br>
494 
<br>
495 
</p>
496 
<p><br>
497 
<br>
498 
</p>
499 
<p><br>
500 
<br>
501 
</p>
502 
<p><br>
503 
<br>
504 
</p>
505 
<p><br>
506 
<br>
507 
</p>
508 
<p><br>
509 
<br>
510 
</p>
511 
<p><br>
512 
<br>
513 
</p>
514 
<p><br>
515 
<br>
516 
</p>
517 
<p><br>
518 
<br>
519 
</p>
520 
<p><br>
521 
<br>
522 
</p>
523 
<p><br>
524 
<br>
525 
</p>
526 
<p><br>
527 
<br>
528 
</p>
529 
<p><br>
530 
<br>
531 
</p>
532 
<p><br>
533 
<br>
534 
</p>
535 
<p><br>
536 
<br>
537 
</p>
538 
</body>
539 
</html>

powered by: WebSVN 2.1.0

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.