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 128

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

powered by: WebSVN 2.1.0

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