| Line 1... |
Line 1... |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
<html>
|
<HTML>
|
<head>
|
<HEAD>
|
<meta http-equiv="CONTENT-TYPE" content="text/html; charset=UTF-8">
|
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
|
<title>Reset System Design</title>
|
<TITLE>Reset System Design</TITLE>
|
<meta name="GENERATOR" content="OpenOffice.org 3.0 (Linux)">
|
<META NAME="GENERATOR" CONTENT="LibreOffice 3.5 (Linux)">
|
<meta name="CREATED" content="0;0">
|
<META NAME="CREATED" CONTENT="0;0">
|
<meta name="CHANGED" content="20100309;9305300">
|
<META NAME="CHANGED" CONTENT="20120817;10052500">
|
<meta name="KEYWORDS" content="start">
|
<META NAME="KEYWORDS" CONTENT="start">
|
<meta name="Info 3" content="">
|
<META NAME="Info 3" CONTENT="">
|
<meta name="Info 4" content="">
|
<META NAME="Info 4" CONTENT="">
|
<meta name="date" content="2008-01-08T12:01:41-0500">
|
<META NAME="date" CONTENT="2008-01-08T12:01:41-0500">
|
<meta name="robots" content="index,follow">
|
<META NAME="robots" CONTENT="index,follow">
|
<style type="text/css">
|
<STYLE TYPE="text/css">
|
<!--
|
<!--
|
H3.western { font-family: "Albany", sans-serif }
|
H3.western { font-family: "Albany", sans-serif }
|
H3.cjk { font-family: "HG Mincho Light J" }
|
H3.cjk { font-family: "HG Mincho Light J" }
|
H3.ctl { font-family: "Arial Unicode MS" }
|
H3.ctl { font-family: "Arial Unicode MS" }
|
-->
|
-->
|
</style>
|
</STYLE>
|
</head>
|
</HEAD>
|
<body dir="ltr" lang="en-US">
|
<BODY LANG="en-US" DIR="LTR">
|
<div id="toc__header" dir="ltr">
|
<DIV ID="toc__header" DIR="LTR">
|
<p><br>
|
<P><BR><BR>
|
</p>
|
</P>
|
</div>
|
</DIV>
|
<h1><a name="socgen_project"></a>Design considerations for Reset
|
<H1><A NAME="socgen_project"></A>Design considerations for Reset
|
Systems<br>
|
Systems</H1>
|
</h1>
|
<P><BR><BR>
|
<p><br>
|
</P>
|
<br>
|
<P>In a world as fast moving as the semiconductor industry it
|
</p>
|
is essential that all designers continuously update their knowledge
|
<p>In a world as fast moving as the semiconductor industry it is
|
as the technology changes. It is very easy to become complacent and
|
essential that all designers continuously update their knowledge as the
|
then suddenly discover that the techniques that have served you for
|
technology changes. It is very easy to become complacent and then
|
many years no longer work.
|
suddenly discover that the techniques that have served you for many
|
</P>
|
years no longer work. <br>
|
<P>This paper was written to explore some of the mistakes that reset
|
<br>
|
|
</p>
|
|
<p>This paper was written to explore some of the mistakes that reset
|
|
system designers have made over the years and why they are no longer
|
system designers have made over the years and why they are no longer
|
true.<br>
|
true.</P>
|
</p>
|
<H3 CLASS="western"><BR><BR>
|
<h3 class="western"><br>
|
</H3>
|
</h3>
|
<H3 CLASS="western">Do we really need a reset system?
|
<h3 class="western"></h3>
|
</H3>
|
<h3 class="western">Do we really need a reset system? <br>
|
<P>Actually you don't. It is a good design practice to ensure that
|
</h3>
|
|
<p>Actually you don't. It is a good design practice to ensure that
|
|
there are no dead end states in your logic and that any state will
|
there are no dead end states in your logic and that any state will
|
eventually lead into a valid operating mode. For many years designs
|
eventually lead into a valid operating mode. For many years designs
|
were simple and robust enough that they would function even if they
|
were simple and robust enough that they would function even if they
|
were enabled without a reset. Then along came embedded processors and
|
were enabled without a reset. Then along came embedded processors and
|
the world became much more complex. I have seen some pretty audacious
|
the world became much more complex. I have seen some pretty audacious
|
attempts to create a watchdog to detect and restart a lost system
|
attempts to create a watchdog to detect and restart a lost
|
but the best that they can do is to improve the odds that the system
|
system but the best that they can do is to improve the odds that the
|
will recover. None of them were 100%.<br>
|
system will recover. None of them were 100%.</P>
|
</p>
|
<P>It is possible that you do not need to reset all the storage
|
<p>It is possible that you do not need to reset all the storage
|
elements in a design. In many cases the data is reloaded shortly
|
elements in a design. In many cases the data is reloaded shortly before
|
before it is needed and it doesn't care what it was before that time.
|
it is needed and it doesn't care what it was before that time. Some
|
Some designers will leave certain storage elements off of the power
|
designers will leave certain storage elements off of the power on reset
|
on reset because it has no effect on the operation.</P>
|
because it has no effect on the operation.<br>
|
<P>BUT.</P>
|
</p>
|
<P>There was a mathematician named Fermat who came up with a theorem
|
<p>BUT.<br>
|
that eventually became known as Fermat's last theorem. It was a
|
</p>
|
simple little equation that worked in every test case that they
|
<p>There was a mathematician named Fermat who came up with a theorem
|
threw at it and they threw a lot of test cases at it. But it took
|
that eventually became known as Fermat's last theorem. It was a simple
|
over 350 years before someone could prove that it would really work
|
little equation that worked in every test case that they threw at
|
in all cases.</P>
|
it and they threw a lot of test cases at it. But it took over 350 years
|
<P><BR>If you allow your designers the option to leave storage
|
before someone could prove that it would really work in all cases.</p>
|
elements off the power on reset system then they will come up with
|
<p><br>
|
these wonderful little designs that appear to work and they will work
|
If you allow your designers the option to leave storage elements off
|
in any test case that you throw at it. But it will take you FOREVER
|
the power on reset system then they will come up with these wonderful
|
to fully verify that it will work in all cases.</P>
|
little designs that appear to work and they will work in any test case
|
<P>You do not need a power on reset system for your logic to work.
|
that you throw at it. But it will take you FOREVER to fully verify that
|
You need it in order to verify that your logic works. It
|
it will work in all cases.<br>
|
takes longer to verify a design than it does to create it and not
|
</p>
|
providing a 100% known start up condition will make the verification
|
<p>You do not need a power on reset system for your logic to work. You
|
effort that much harder. All storage elements must be on a reset if
|
need it in order to verify that your logic works. It takes
|
only for test and verification purposes. If you have logic that must
|
longer to verify a design than it does to create it and not providing a
|
function during a power up reset then put it on a special reset that
|
100% known start up condition will make the verification effort that
|
is only active in test mode.</P>
|
much harder. All storage elements must be on a reset if only for test
|
<P><BR><BR>
|
and verification purposes. If you have logic that must function during
|
</P>
|
a power up reset then put it on a special reset that is only active in
|
<H3 CLASS="western">All components must come out of reset on exactly
|
test mode.<br>
|
the same clock</H3>
|
</p>
|
<P>That's true, or at least it was back in the 60's. Back then
|
<br>
|
every component would come out of reset and start "componenting".
|
<h3 class="western">All components must come out of reset on exactly
|
The reset system acted like a conductor so that everybody
|
the same clock<br>
|
started on the same beat. Those types of systems are rare today. Most
|
</h3>
|
major chips have one or more microprocessors in side so components
|
That's true, or at least it was back in the 60's. Back then every
|
come out of reset only to sit there waiting for the cpu to configure
|
component would come out of reset and start "componenting". The reset
|
them and get them started. It doesn't matter what cycle you
|
system acted like a conductor so that everybody started on the
|
come out of reset on as long as you are up and ready before
|
same beat. Those types of systems are rare today. Most major chips have
|
someone else asks you to do something. <BR><BR>This has led to two
|
one or more microprocessors in side so components come out of reset
|
prong approach to reset system design. The majority of the chip
|
only to sit there waiting for the cpu to configure them and get them
|
is on a large slow reset distribution tree that doesn't
|
started. It doesn't matter what cycle you come out of reset on as
|
even try to get everybody reset on the same cycle.
|
long as you are up and ready before someone else asks you to do
|
Then you have a second smaller and faster tree that only resets
|
something. <br>
|
the cpu and anything else that can initiate activity. The
|
<br>
|
fast reset is delayed long enough to ensure that the slow reset is
|
This has led to two prong approach to reset system design. The
|
finished before starting the cpu. In modern designs this can be a
|
majority of the chip is on a large slow reset distribution
|
significant number of clock cycles. I have seen repairable memories
|
tree that doesn't even try to get everybody reset on
|
where you had to hold off starting the cpu for 3000 clocks to ensure
|
the same cycle. Then you have a second smaller and
|
that any repair would be finished before the cpu started.<BR><BR><BR>
|
faster tree that only resets the cpu and anything else that can
|
</P>
|
initiate activity. The fast reset is delayed long enough to
|
<H3 CLASS="western">You must design an asynchronous reset system</H3>
|
ensure that the slow reset is finished before starting the cpu. In
|
<P>Absolutely. Most of the time your mission mode requirements will
|
modern designs this can be a significant number of clock cycles. I have
|
|
seen repairable memories where you had to hold off starting the cpu for
|
|
3000 clocks to ensure that any repair would be finished before the cpu
|
|
started.<br>
|
|
<br>
|
|
<br>
|
|
<h3 class="western">You must design an asynchronous reset system<br>
|
|
</h3>
|
|
Absolutely. Most of the time your mission mode requirements will
|
|
dictate that the power on reset system works even in the absence of
|
dictate that the power on reset system works even in the absence of
|
clock. If it doesn't then the test engineer will require that all pads
|
clock. If it doesn't then the test engineer will require that all
|
must respond to an async reset in case a board is built missing it's
|
pads must respond to an async reset in case a board is built missing
|
clock. Asynchronous reset design is essential. A power up monitor
|
it's clock. Asynchronous reset design is essential. A power up
|
will drive the reset input active as the power is ramping
|
monitor will drive the reset input active as the power is
|
up. You will not have a clock at this time so the reset system must be
|
ramping up. You will not have a clock at this time so the reset
|
able to work without one.<br>
|
system must be able to work without one.<BR><BR><BR><BR>
|
<br>
|
</P>
|
<br>
|
<H3 CLASS="western">You must design your logic using synchronous
|
<br>
|
design methods</H3>
|
<h3 class="western">You must design your logic using synchronous design
|
<P>Absolutely. Today's chips are huge. The only way that you can
|
methods<br>
|
close timing on a large design is if everyone follows strict
|
</h3>
|
synchronous design rules. The mistake that many of todays
|
Absolutely. Today's chips are huge. The only way that you can close
|
designers make is that they think that because they have to design an
|
timing on a large design is if everyone follows strict synchronous
|
asynchronous reset system that they get an exemption from following
|
design rules. The mistake that many of todays designers make is
|
the rules for synchronous design. Sorry guys, it not one or the
|
that they think that because they have to design an asynchronous reset
|
other its BOTH. You have to design a asynchronous reset system but
|
system that they get an exemption from following the rules for
|
you cannot use any flip flops with an asynchronous reset port.<BR><BR>The
|
synchronous design. Sorry guys, it not one or the other its BOTH.
|
funny thing is that synchronous design methodology is quite capable
|
You have to design a asynchronous reset system but you cannot use any
|
of creating an asynchronous reset system and will
|
flip flops with an asynchronous reset port.<br>
|
actually give you a smaller and faster design that either
|
<br>
|
of the traditional async only or sync only solutions.<BR><BR><BR>
|
The funny thing is that synchronous design methodology is quite
|
</P>
|
capable of creating an asynchronous reset system and
|
<H3 CLASS="western">Don't worry about making the reset system
|
will actually give you a smaller and faster design that
|
testable. The test engineer has a tool that will fix any problem in
|
either of the traditional async only or sync only solutions.<br>
|
the back end</H3>
|
<br>
|
<P>That used to be true. The first thing a vendor does when they get
|
<br>
|
a net list is to run a full drc that looks for dft issues. If anybody
|
<h3 class="western">Don't worry about making the reset system
|
has any signals crossing between the async reset port on a
|
testable.The test engineer has a tool that will fix any problem in the
|
flipflop and either a D or a Q port then it flags it as a violation.
|
back end<br>
|
So you can either send it back to the customer and wait a week for
|
</h3>
|
them to find it, fix it, and re-synthesizes or you can eco in a test
|
That used to be true. The first thing a vendor does when they get a net
|
mux at the flop and have it fixed in 5 minutes. Everyone took the
|
list is to run a full drc that looks for dft issues. If anybody has any
|
easy way out.<BR><BR>But then along came Logic equivalence checking
|
signals crossing between the async reset port on a flipflop and
|
(LEC). The final routed net list will be sent back and compared
|
either a D or a Q port then it flags it as a violation. So you can
|
with the customers golden net list and all of these ecos will show
|
either send it back to the customer and wait a week for them to find
|
up in the report. Now somebody has check out each and every
|
it, fix it, and re-synthesizes or you can eco in a test mux at the flop
|
item in the report before you can release the masks. It now
|
and have it fixed in 5 minutes. Everyone took the easy way out.<br>
|
becomes easier for the customer to find and fix these errors before
|
<br>
|
synthesis than it is to deal with thousands of lec errors.<BR><BR>Besides
|
But then along came Logic equivalence checking (LEC). The final
|
with the newer processes the days when you could eco in a small tweak
|
routed net list will be sent back and compared with the customers
|
on a routed net list and not have it break something are fast
|
golden net list and all of these ecos will show up in the report.
|
disappearing. You will eco the rtl code and then re-synthesis
|
Now somebody has check out each and every item in the report
|
and reroute.<BR><BR><BR><BR> </P>
|
before you can release the masks. It now becomes easier for the
|
<H3 CLASS="western">You must use a sync_reset pragma if you design a
|
customer to find and fix these errors before synthesis than it is to
|
synchronous reset system</H3>
|
deal with thousands of lec errors.<br>
|
<P>I cringe whenever I hear someone say this. If you do a
|
<br>
|
synchronous reset design then you will find that your gate
|
Besides with the newer processes the days when you could eco in a small
|
simulations will not run. Many of your flipflops will never reset to
|
tweak on a routed net list and not have it break something are fast
|
a known value. They will get a valid clock and the reset in the block
|
disappearing. You will eco the rtl code and then re-synthesis and
|
will be valid but synthesis will have combined the reset logic in
|
reroute.<br>
|
with the mission mode logic and it will be distributed throughout the
|
<br>
|
logic cone feeding the D input. It also uses the flops current state
|
<br>
|
in order to compute the next state. It creates a situation
|
<br>
|
where if the flop has a 0 or 1 in it then the logic will compute the
|
<br>
|
next state as 0 when reset is active. However if the flop is unknown
|
<br>
|
as it is at power up then verilog is unable to figure out the correct
|
<h3 class="western">You must use a sync_reset pragma if you design a
|
next state and it remains at x.<BR><BR>This is a simulation only
|
synchronous reset system<br>
|
issue as flops in real silicon will always resolve to a valid
|
</h3>
|
state.<BR><BR>Tool vendors created the sync_reset pragma so that you
|
I cringe whenever I hear someone say this. If you do a
|
could tell the tool not to combine the reset logic with the mission
|
synchronous reset design then you will find that your gate simulations
|
mode logic. You place it at the very tip of the logic cone and it
|
will not run. Many of your flipflops will never reset to a known value.
|
will remain there in gates.<BR><BR>So whats wrong with that?<BR><BR>The
|
They will get a valid clock and the reset in the block will be valid
|
synthesis tool will make a list of all signals that enter the logic
|
but synthesis will have combined the reset logic in with the mission
|
|
mode logic and it will be distributed throughout the logic cone feeding
|
|
the D input. It also uses the flops current state in order to compute
|
|
the next state. It creates a situation where if the flop has a 0
|
|
or 1 in it then the logic will compute the next state as 0 when reset
|
|
is active. However if the flop is unknown as it is at power up then
|
|
verilog is unable to figure out the correct next state and it remains
|
|
at x.<br>
|
|
<br>
|
|
This is a simulation only issue as flops in real silicon will always
|
|
resolve to a valid state.<br>
|
|
<br>
|
|
Tool vendors created the sync_reset pragma so that you could tell the
|
|
tool not to combine the reset logic with the mission mode logic. You
|
|
place it at the very tip of the logic cone and it will remain there in
|
|
gates.<br>
|
|
<br>
|
|
So whats wrong with that?<br>
|
|
<br>
|
|
The synthesis tool will make a list of all signals that enter the logic
|
|
cone along with the relative time it enters before the next clock
|
cone along with the relative time it enters before the next clock
|
edge. If it finds a early arriving signal entering the cone
|
edge. If it finds a early arriving signal entering the cone
|
closer to the tip than a late arriving one then it will try
|
closer to the tip than a late arriving one then it will
|
to remap the logic and swap them so that the late
|
try to remap the logic and swap them so that the late
|
arrival can move closer to tip. Ideally the
|
arrival can move closer to tip. Ideally the
|
latest signals are moved towards the tip and the early ones are moved
|
latest signals are moved towards the tip and the early ones are moved
|
to the rear. <br>
|
to the rear. <BR><BR>The reset from a properly designed distribution
|
<br>
|
tree and the feedback signal from the flop that you are working on
|
The reset from a properly designed distribution tree and the feedback
|
will always be two of the earliest signals. They will get pushed up
|
signal from the flop that you are working on will always be two of the
|
away from the tip of the cone simply to make room for the mission
|
earliest signals. They will get pushed up away from the tip of the cone
|
critical late signals. This is a good thing, you want this to happen.
|
simply to make room for the mission critical late signals. This is a
|
<BR><BR>The problem is that designers think that they must prove that
|
good thing, you want this to happen. <br>
|
the reset system works in gate sims. Verilog is a great tool when
|
<br>
|
every node is in a known state but it is lousy when dealing with
|
The problem is that designers think that they must prove that the reset
|
unknowns. There are times like this when it is possible to resolve a
|
system works in gate sims. Verilog is a great tool when every node is
|
X into a known value and it can't. There are also times when it
|
in a known state but it is lousy when dealing with unknowns. There are
|
will resolve an X to a known value when it shouldn't. The only way to
|
times like this when it is possible to resolve a X into a known
|
use verilog is to start with everything in a known state and stop it
|
value and it can't. There are also times when it will resolve an
|
when anything goes X. That means there's a problem and nothing
|
X to a known value when it shouldn't. The only way to use verilog is to
|
downstream from that X can be trusted.<BR><BR><BR>You do not prove
|
start with everything in a known state and stop it when anything goes
|
your reset system design in gates sims. You prove the design in rtl
|
X. That means there's a problem and nothing downstream from that
|
sims and use LEC to prove that gates matches the design that works.
|
X
|
Then you use initial statements to force all flops to a known state
|
can be trusted.<br>
|
at start up and use gates sims to prove that everything else works.
|
<br>
|
Verilog gates is the wrong tool to use to verify the reset
|
<br>
|
system.<BR><BR>You never use the sync_reset pragma unless you really
|
You do not prove your reset system design in gates sims. You prove the
|
like big slow designs.<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
|
design in rtl sims and use LEC to prove that gates matches the design
|
</P>
|
that works. Then you use initial statements to force all flops to
|
<H3 CLASS="western">Doing a synchronous reset design adds logic in
|
a known state at start up and use gates sims to prove that everything
|
the D pathway and will slow down the design</H3>
|
else works. Verilog gates is the wrong tool to use to verify the reset
|
<P><BR>Wrong. Adding logic in the critical path will slow down the
|
system.<br>
|
design. Adding it into a non-critical path simply reduces slack in
|
<br>
|
that path. If you put the reset logic at the very tip of the logic
|
You never use the sync_reset pragma unless you really like big slow
|
cone then you are adding it into the critical path and the synthesis
|
designs.<br>
|
tool will move it up the cone until it is in a safe
|
<br>
|
location.<BR><BR>Adding a synchronous reset system doesn't really add
|
<br>
|
much logic to the design. The tools will first locate any mission
|
<br>
|
mode logic that also forces the flop into the reset state and it will
|
<br>
|
piggyback the reset system with that logic. You don't add gates , you
|
<br>
|
bump a gate up to add an extra input.<BR><BR><BR><BR>
|
<br>
|
</P>
|
<br>
|
<H3 CLASS="western">A component must perform reset in one clock
|
<br>
|
cycle</H3>
|
<br>
|
<P>The power on reset is really a slow operation. A typical
|
<h3 class="western">Doing a synchronous reset design adds logic in the
|
system could see:</P>
|
D pathway and will slow down the design<br>
|
<UL>
|
</h3>
|
<LI><P STYLE="margin-bottom: 0in">Ramp time for power rails
|
<br>
|
</P>
|
Wrong. Adding logic in the critical path will slow down the design.
|
<LI><P STYLE="margin-bottom: 0in">clock start up time
|
Adding it into a non-critical path simply reduces slack in that path.
|
</P>
|
If you put the reset logic at the very tip of the logic cone then you
|
<LI><P>pll lock time
|
are adding it into the critical path and the synthesis tool will move
|
</P>
|
it up the cone until it is in a safe location.<br>
|
</UL>
|
<br>
|
<P>You are looking at activity that is measured in the milliseconds
|
Adding a synchronous reset system doesn't really add much logic to the
|
on a system clock that is measured in the nanoseconds. Performing a
|
design. The tools will first locate any mission mode logic that also
|
reset in one clock cycle requires adding logic to every single
|
forces the flop into the reset state and it will piggyback the reset
|
flipflop<BR>to provide nanosecond resolution to an event that is
|
system with that logic. You don't add gates , you bump a gate up to add
|
measured in microseconds. A designer should only add reset logic as a
|
an extra input.<br>
|
last resort. The preferred method is to use the existing mission mode
|
<br>
|
logic to perform the reset. If you have a computational block with a
|
<br>
|
fifty stage deep pipeline then reset should force it's inputs to 0
|
<br>
|
and open all the gates so that every flipflop will be flushed out in
|
<h3 class="western">A component must perform reset in one clock
|
50 clocks. Better yet would be to have the block feeding your input
|
cycle<br>
|
force it's output to all 0's during reset.<BR><BR>Every design should
|
</h3>
|
spec a multicycle reset and give the designers the freedom to reset
|
The power on reset is really a slow operation. A typical system
|
any way they want as long as it's finished by the end of the reset
|
could see:<br>
|
pulse.<BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>
|
<br>
|
</P>
|
<ul>
|
<DIV ID="Section1" DIR="LTR">
|
<li>Ramp time for power rails</li>
|
<P><A NAME="toc__header"></A><BR><BR>
|
<li>clock start up time</li>
|
</P>
|
<li>pll lock time</li>
|
</DIV>
|
</ul>
|
<H1><A NAME="socgen_project1"></A>How to design the Reset System</H1>
|
You are looking at activity that is measured in the milliseconds on a
|
<P><BR><BR>
|
system clock that is measured in the nanoseconds. Performing a reset in
|
</P>
|
one clock cycle requires adding logic to every single flipflop<br>
|
<H3 CLASS="western">1) Write a mission statement</H3>
|
to provide nanosecond resolution to an event that is measured in
|
<P>The first step in any design task is to write a statement that
|
microseconds. A designer should only add reset logic as a last
|
sums up what the thing you are designing will do. This is
|
resort. The preferred method is to use the existing mission mode logic
|
important because everything after this point must be traceable back
|
to perform the reset. If you have a computational block with a fifty
|
to this statement. The statement will tell you
|
stage deep pipeline then reset should force it's inputs to 0 and open
|
what steps you must follow. Anything that you cannot trace back
|
all the gates so that every flipflop will be flushed out in 50 clocks.
|
to something in the mission statement is not part of the design<BR><BR><BR>The
|
Better yet would be to have the block feeding your input force it's
|
mission statement for the reset system is:<BR><BR><BR><BR>The reset
|
output to all 0's during reset.<br>
|
system will force all the nodes in a system or subsystem into a known
|
<br>
|
good state while a reset trigger is active.<BR><BR><BR><BR>
|
Every design should spec a multicycle reset and give the designers the
|
</P>
|
freedom to reset any way they want as long as it's finished by the end
|
<H3 CLASS="western">2) Define the reset triggers</H3>
|
of the reset pulse.<br>
|
<P>We must now make a list of all the events that will cause us to
|
<br>
|
reset all or part of the system. Our list is:</P>
|
<br>
|
<UL>
|
<br>
|
<LI><P>The design has a power monitor chip that provides a low
|
<br>
|
signal when the supply rails have not been above the limit for
|
<br>
|
a long enough period of time
|
<br>
|
</P>
|
<br>
|
</UL>
|
<br>
|
<UL>
|
<br>
|
<LI><P>The design has a soft reset block that can reset any sub
|
<br>
|
block if its reset flop is set to 1.
|
<br>
|
</P>
|
<div id="toc__header" dir="ltr">
|
</UL>
|
<p><br>
|
<UL>
|
</p>
|
<LI><P>The clocks must run during reset but the divider has a
|
</div>
|
special reset input for simulation and testing
|
<h1><a name="socgen_project"></a>How to design the Reset System<br>
|
</P>
|
</h1>
|
</UL>
|
<br>
|
<UL>
|
<br>
|
<LI><P>The design has ieee 1149.1 test logic with a active low trst*
|
<h3 class="western">1) Write a mission statement<br>
|
pin.
|
</h3>
|
</P>
|
The first step in any design task is to write a statement that sums up
|
</UL>
|
what the thing you are designing will do. This is important
|
<UL>
|
because everything after this point must be traceable back to this
|
<LI><P>The reset signal has a metastable filter to sync it
|
statement. The statement will tell you what
|
with the clock.</P>
|
steps you must follow. Anything that you cannot trace back to something
|
</UL>
|
in the mission statement is not part of the design<br>
|
<P>The last is important because some designers will forget that the
|
<br>
|
filtered output is actually it's own separate reset domain<BR><BR><BR><BR><BR>
|
<br>
|
</P>
|
The mission statement for the reset system is:<br>
|
<H3 CLASS="western">3) Define a known good state</H3>
|
<br>
|
<P>We now look at every storage element in the design and
|
<br>
|
define a safe state for each element of either 1 or 0. Don't
|
<br>
|
cares are not allowed. If you cannot pick a value then one will be
|
The reset system will force all the nodes in a system or subsystem into
|
assigned for you. This task is best performed after the system and
|
a known good state while a reset trigger is active.<br>
|
board designers have defined the known good state for the PCA.
|
<br>
|
They will define the state for all of the pads, the ic design team
|
<br>
|
must define the states for all internal nodes.</P>
|
<br>
|
<H3 CLASS="western">4) Assign storage elements to triggers</H3>
|
<h3 class="western">2) Define the reset triggers<br>
|
<P>Once we have a list of all storage element we list any and all
|
</h3>
|
triggers that will force them into a safe mode.<BR>A typical list
|
We must now make a list of all the events that will cause us to reset
|
would list all the flipflops in timer module u12.r567 would be reset
|
all or part of the system. Our list is:<br>
|
by:</P>
|
<br>
|
<UL>
|
<ul>
|
<LI><P>an active high on soft reset bit #23
|
<li>The design has a power monitor chip that provides a low signal
|
</P>
|
when the supply rails have not been above the limit for a long
|
</UL>
|
enough period of time</li>
|
<UL>
|
</ul>
|
<LI><P>an active low on the power monitor input
|
<ul>
|
</P>
|
<li>The design has a soft reset block that can reset any sub block if
|
</UL>
|
its reset flop is set to 1.</li>
|
<UL>
|
</ul>
|
<LI><P>an active low on the simulation/test reset
|
<ul>
|
</P>
|
<li>The clocks must run during reset but the divider has a special
|
</UL>
|
reset input for simulation and testing</li>
|
<UL>
|
</ul>
|
<LI><P>an active low on the output of the metastable filter
|
<ul>
|
</P>
|
<li>The design has ieee 1149.1 test logic with a active low trst* pin.</li>
|
</UL>
|
</ul>
|
<P><BR>The jtag reset is not included because it doesn't reset the
|
<ul>
|
timer. Once this step is complete it will provide a map for the
|
<li>The reset signal has a metastable filter to sync it with
|
reset distribution tree that you will need. The best way to
|
the clock.<br>
|
distribute the reset over a large design is to use what is called a
|
</li>
|
"synchronous reset tree".<BR><BR><BR><BR><BR><BR>
|
</ul>
|
</P>
|
The last is important because some designers will forget that the
|
<H3 CLASS="western">5) Select between synchronous or asynchronous
|
filtered output is actually it's own separate reset domain<br>
|
reset system</H3>
|
<br>
|
<P>At this point it is easy to see if we need a synchronous or
|
<br>
|
|
<br>
|
|
<br>
|
|
<h3 class="western">3) Define a known good state<br>
|
|
</h3>
|
|
We now look at every storage element in the design and define a
|
|
safe state for each element of either 1 or 0. Don't cares are not
|
|
allowed. If you cannot pick a value then one will be assigned for you.
|
|
This task is best performed after the system and board designers have
|
|
defined the known good state for the PCA. They will define the
|
|
state for all of the pads, the ic design team must define the states
|
|
for all internal nodes.<br>
|
|
<br>
|
|
<h3 class="western">4) Assign storage elements to triggers<br>
|
|
</h3>
|
|
Once we have a list of all storage element we list any and all triggers
|
|
that will force them into a safe mode.<br>
|
|
A typical list would list all the flipflops in timer module u12.r567
|
|
would be reset by:<br>
|
|
<br>
|
|
<ul>
|
|
<li>an active high on soft reset bit #23</li>
|
|
</ul>
|
|
<ul>
|
|
<li>an active low on the power monitor input</li>
|
|
</ul>
|
|
<ul>
|
|
<li>an active low on the simulation/test reset</li>
|
|
</ul>
|
|
<ul>
|
|
<li>an active low on the output of the metastable filter</li>
|
|
</ul>
|
|
<br>
|
|
The jtag reset is not included because it doesn't reset the
|
|
timer.
|
|
Once this step is complete it will provide a map for the reset
|
|
distribution tree that you will need. The best way to distribute the
|
|
reset over a large design is to use what is called a "synchronous reset
|
|
tree".<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<h3 class="western">5) Select between synchronous or asynchronous reset
|
|
system<br>
|
|
</h3>
|
|
At this point it is easy to see if we need a synchronous or
|
|
asynchronous reset system. If your trigger is asynchronous then you
|
asynchronous reset system. If your trigger is asynchronous then you
|
must design a asynchronous reset system. If the trigger can occur
|
must design a asynchronous reset system. If the trigger can occur
|
without a clock then you must be able to reset the system without a
|
without a clock then you must be able to reset the system without a
|
clock.<br>
|
|
<br>
|
|
If the trigger is synchronous then you may design a synchronous reset
|
|
system or you may also choose to design a asynchronous one. The
|
|
async one will enter reset one cycle before the sync one
|
|
but they will both exit on at the same time. <br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<h3 class="western">6) Select reset style for each flip/flop<br>
|
|
</h3>
|
|
We now need to select a reset "Style" for each flip/flop from the four
|
|
possible reset styles.<br>
|
|
<br>
|
|
<br>
|
|
<ul>
|
|
<li>Synchronous</li>
|
|
<li>Synchronous with output override</li>
|
|
<li>Asynchronous</li>
|
|
<li>Both Synchronous and Asynchronous</li>
|
|
</ul>
|
|
<br>
|
|
If the reset system is synchronous then you may choose any of the four
|
|
styles. If it is asynchronous then you cannot use the synchronous style.<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<img style="width: 800px; height: 600px;" alt=""
|
|
src="../png/reset_fig1.png"><br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<h3 class="western">7) Apply DFT fixes to all asynchronous ports<br>
|
|
</h3>
|
|
All paths from the Q output of a flip/flop to the asynchronous
|
|
reset/preset port of a flip/flop must be disabled during scan testing.
|
|
The use of a test mux to do this is not recommended because anytime you
|
|
use a test mux you are not testing the circuit as it is used in mission
|
|
mode. There will always be at least one point of failure inside the
|
|
test mux where scan tests will pass but the IC will not function.<br>
|
|
<br>
|
|
The recommended method is to gate off the synchronous path with a atg
|
|
test signal and then recombine it with an asynchronous reset so that
|
|
the async reset it self is still testable. The lib module
|
|
cde_asyncdisable is available for this purpose. DO NOT CREATE YOUR OWN
|
|
TEST LOGIC. Checking the rtl code to ensure that all asynchronous
|
|
resets are testable requires a fairly sophisticated and expensive tool.
|
|
Checking the rtl to ensure that all asynchronous resets are properly
|
|
connected to a cde_asyncdisable module takes a simple perl script.<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<br>
|
|
<img style="width: 800px; height: 600px;" alt=""
|
|
src="../png/reset_fig2.png"><br>
|
|
<br>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
</p>
|
|
<h3 class="western">8) Seperate Synchronous and Asynchronous
|
|
resets<br>
|
|
</h3>
|
|
Asynchronous
|
|
resets connect to the asynchronouse reset/preset ports of a flip/flop.
|
|
Synchronous resets connect through the logic cone to the D flip/flop
|
|
port. They are the logicaly the same signal in mission mode but must be
|
|
sperate during scan testing. It is very easy to make a mistake in
|
|
rtl coding. The recomendation is the use active low signals for
|
|
all asynchronous resets and active high signals for all synchronous
|
|
ones.<br>
|
|
<p><br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
<p><br>
|
|
<br>
|
|
</p>
|
|
</body>
|
|
</html>
|
|
|
|
No newline at end of file
|
No newline at end of file
|
|
clock.<BR><BR>If the trigger is synchronous then you may design a
|
|
synchronous reset system or you may also choose to design a
|
|
asynchronous one. The async one will enter reset one
|
|
cycle before the sync one but they will both exit on at
|
|
the same time. <BR><BR><BR><BR>
|
|
</P>
|
|
<H3 CLASS="western">6) Select reset style for each flip/flop</H3>
|
|
<P>We now need to select a reset "Style" for each flip/flop
|
|
from the four possible reset styles.<BR><BR><BR>
|
|
</P>
|
|
<UL>
|
|
<LI><P STYLE="margin-bottom: 0in">Synchronous
|
|
</P>
|
|
<LI><P STYLE="margin-bottom: 0in">Synchronous with output override
|
|
</P>
|
|
<LI><P STYLE="margin-bottom: 0in">Asynchronous
|
|
</P>
|
|
<LI><P>Both Synchronous and Asynchronous
|
|
</P>
|
|
<LI><P>Multicycle</P>
|
|
</UL>
|
|
<P><BR>If the reset system is synchronous then you may choose any of
|
|
the four styles. If it is asynchronous then you cannot use the
|
|
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>
|
|
</P>
|
|
<H3 CLASS="western">7) Apply DFT fixes to all asynchronous ports</H3>
|
|
<P>All paths from the Q output of a flip/flop to the asynchronous
|
|
reset/preset port of a flip/flop must be disabled during scan
|
|
testing. The use of a test mux to do this is not recommended because
|
|
anytime you use a test mux you are not testing the circuit as it is
|
|
used in mission mode. There will always be at least one point of
|
|
failure inside the test mux where scan tests will pass but the IC
|
|
will not function.<BR><BR>The recommended method is to gate off the
|
|
synchronous path with a atg test signal and then recombine it with an
|
|
asynchronous reset so that the async reset it self is still testable.
|
|
The lib module cde_asyncdisable is available for this purpose. DO NOT
|
|
CREATE YOUR OWN TEST LOGIC. Checking the rtl code to ensure
|
|
that all asynchronous resets are testable requires a fairly
|
|
sophisticated and expensive tool. Checking the rtl to ensure that all
|
|
asynchronous resets are properly connected to a cde_asyncdisable
|
|
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>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<H3 CLASS="western">8) Seperate Synchronous and Asynchronous
|
|
resets</H3>
|
|
<P>Asynchronous resets connect to the asynchronouse reset/preset
|
|
ports of a flip/flop. Synchronous resets connect through the logic
|
|
cone to the D flip/flop port. They are the logicaly the same signal
|
|
in mission mode but must be sperate during scan testing. It is
|
|
very easy to make a mistake in rtl coding. The recomendation is
|
|
the use active low signals for all asynchronous resets and active
|
|
high signals for all synchronous ones.</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
<P><BR><BR>
|
|
</P>
|
|
</BODY>
|
|
</HTML>
|
No newline at end of file
|
No newline at end of file
|
