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 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.
|
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 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 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 in order to verify that your logic works. 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. Back then
|
84 |
|
|
every component would come out of reset and start "componenting".
|
85 |
|
|
The reset system acted like a conductor 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. It doesn't matter what cycle you
|
90 |
|
|
come out of reset on as long as you are up and ready before
|
91 |
|
|
someone else asks you to do something. <BR><BR>This has led to two
|
92 |
|
|
prong approach to reset system design. The majority of the chip
|
93 |
|
|
is on a large slow reset distribution tree that doesn't
|
94 |
|
|
even try to get everybody reset on the same cycle.
|
95 |
|
|
Then you have a second smaller and faster tree that only resets
|
96 |
|
|
the cpu and anything else that can initiate activity. 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. A power up
|
109 |
|
|
monitor will drive the reset input active 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. 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. 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
|
124 |
|
|
of creating an asynchronous reset system and will
|
125 |
|
|
actually give you a smaller and faster design that either
|
126 |
|
|
of the traditional 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 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). 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 in the report. Now somebody has check out each and every
|
142 |
|
|
item in the report before you can release the masks. It now
|
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. You will eco the rtl code and then re-synthesis
|
148 |
|
|
and reroute.<BR><BR><BR><BR> </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 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. 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. If it finds a early arriving signal entering the cone
|
171 |
119 |
jt_eaton |
closer to the tip than a late arriving one then it will
|
172 |
|
|
try to remap the logic and swap them so that the late
|
173 |
19 |
jt_eaton |
arrival can move closer to tip. 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 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. 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.
|
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 until it is in a 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 reset in one clock
|
211 |
|
|
cycle</H3>
|
212 |
|
|
<P>The power on reset is really a slow operation. 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 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 will do. This is
|
247 |
|
|
important because everything after this point must be traceable back
|
248 |
|
|
to this statement. The statement will tell you
|
249 |
|
|
what 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 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 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 now look at every storage element in the design and
|
321 |
|
|
define a safe state for each 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.
|
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. 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 |
|
|
"synchronous reset tree".<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. The async one will enter reset one
|
363 |
|
|
cycle before the sync one but they will both exit on at
|
364 |
|
|
the same 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 "Style" 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. 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 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 during scan testing. It is
|
415 |
|
|
very easy to make a mistake in rtl coding. 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>
|