Global Reset using Global Buffer
rgame...@gmail.com
I´ve read a lot about resets and I´ve decided that for my designs, an
asynchronous solution with a synchronous source is a better solution.
No discussions here, this is a personal (almost religious) choice.
Now, what I´ve read about using a global line as reset line, i think
it was on a discussion "on no, reset again" (something like that). So
I had tried several times to use a Global Buffer for my Global reset.
I can use the buffer, but instead of using the global lines, it uses
regular route lines wich ends ina a great reset skew.
Giving more details, I instantiate the buffer, I can see it on FPGA
Editor but it do not use the global lines. The fpga is an Spartan3,
for information.
Does anyone knows how to force the use of one global buffer (and the
global lines) for my async reset?
austin
The tools realize there is no way to route a logic signal on the global
clock line, so it does it the best way it can.
In V5, we added the necessary mux wiring so a global line could be used
for a logic signal.
As far as "global reset" is concerned, there is a nice series of
articles by Ken Chapman on the subject, but right now we are moving them
to a new location.
it is still cached on google, read it.
a smaller length link.
Austin
Rgamer
Thanks for your reply.
Well, just like I said before, reset, global or not, sync or async is
not a point here. I humbly ask that this discussion to be in an
appropriante topic (there are several good discussions about it).
Back to my original question: sou, in V5 you're able to route logic
through the global lines, by instantiating the BUFG is that right?
I've done this. But the problem is: after the buffer, it still uses
regular routing lines and do not use the global ones.
Be a reset or not, can that be done to Spartan3? Can I force de route
after the BUFG to use globallines?
Regards,
On Nov 27, 1:59 pm, austin <aus...@xilinx.com> wrote:
> You can't use a global clock line as a reset,
>
> The tools realize there is no way to route a logic signal on the global
> clock line, so it does it the best way it can.
>
> In V5, we added the necessary mux wiring so a global line could be used
> for a logic signal.
>
> As far as "global reset" is concerned, there is a nice series of
> articles by Ken Chapman on the subject, but right now we are moving them
> to a new location.
>
> http://209.85.173.104/search?q=cache:kUSKmhw7emUJ:www.xilinx.com/xlnx...
austin
No, you cannot use global resources for a logic signal in S3.
Yes, you can use a global clock for a logic signal in V5, but the entry
into the resource, and the exit from that resource may use additional
local routes (depending on what the logic signal is connected to/from).
You missed the entire issue of Ken's note: asynchronous resets may
"break" synchronous circuits. Since we don't support any asynchronous
circuits in the FPGA (everything assumes a synchronous logic design
flow, and we support no asynchronous logic synthesis), I think you may
be confused.
Austin
Eric Smith
> No, you cannot use global resources for a logic signal in S3.
I've heard you say that before, and I don't dispute it, but I'm curious
as to the reason. How does the S3 "know" whether the signal I've got
driving a global clock net is actually a clock? Is there a minimum
frequency for the clock net? I don't see one in the datasheet.
Eric
Ed McGettigan
It's not a case of classifying the input as a "clock", but one of "you
can't get there from here". The global clock nets go to clock pins, if
your destination is something other than a clock pin then it has to
"hop off" and use the regular routing resources to get there.
Ed McGettigan
--
Xilinx Inc.
Eric Smith
> It's not a case of classifying the input as a "clock", but one of "you
> can't get there from here". The global clock nets go to clock pins, if
> your destination is something other than a clock pin then it has to
> "hop off" and use the regular routing resources to get there.
Thanks for the explanation; that's certainly a very good reason to not
try to use the clock net for something else.
Rgamer
my application DO require both. By the way, I´m not confused about
reset.
It's not an issue about using the buffer. It does route my signal,
whatever it´s source it is, to a global buffer (I can see that on FPGA
EDITOR) but then, it indeed "jumps" to regular lines after the buffer.
So, I thought that might there is someway to force the route through
global lines, because be it a clock or not, every signal connects to
CLB using a matrix. It could do that for anysignal. Couldn't it?
No, but it seems to me that this is imposed by the PAR tool. My point
that the clock input for every FF on the FPGA can be any signal on the
design, a bad, but possible design pratice. The same for enable and
reset.
So, the limitation is not on the interconnect matrix, because ALL
signals that enter a LUT or FF comes from there.
John_H
> I thought 2 uses for a global line, as reset and clock enable, because
> my application DO require both. By the way, I´m not confused about
> reset.
>
> It's not an issue about using the buffer. It does route my signal,
> whatever it´s source it is, to a global buffer (I can see that on FPGA
> EDITOR) but then, it indeed "jumps" to regular lines after the buffer.
> So, I thought that might there is someway to force the route through
> global lines, because be it a clock or not, every signal connects to
> CLB using a matrix. It could do that for anysignal. Couldn't it?
>
> No, but it seems to me that this is imposed by the PAR tool. My point
> that the clock input for every FF on the FPGA can be any signal on the
> design, a bad, but possible design pratice. The same for enable and
> reset.
> So, the limitation is not on the interconnect matrix, because ALL
> signals that enter a LUT or FF comes from there.
In FPGA Editor, if you click on the interconnect matrix where the global
lines feed each CLB, each bubble that connects to a global line - when
clicked on - will highlight the paths that connection can feed. They
are all clock lines, no reset. If you highlight the bubble connected to
the slice clock lines, you'll see where the clock can get its signal.
Through the CLB interconnect matrix, the global lines can only feed
clocks (at least in families before V5).
The limitation IS the interconnection matrix. Why do you believe otherwise?
Jim Wu
> lines feed each CLB, each bubble that connects to a global line - when
> clicked on - will highlight the paths that connection can feed. They
> are all clock lines, no reset. If you highlight the bubble connected to
> the slice clock lines, you'll see where the clock can get its signal.
>
> Through the CLB interconnect matrix, the global lines can only feed
> clocks (at least in families before V5).
Using global lines for reset should work in Virtex4 as well.
Cheers,
Jim
austin
The global clock network on Virtex, Virtex E, Virtex II, Spartan 3, and
Virtex 4, has dedicated IOB locations to get onto the global tree
easily, which then goes to a clock switchbox in the center of the die,
and then on to the H-tree which then goes to every CLB/IOB/BRAM/DSP/DCM
tile's clock input (it goes nowhere else).
The switchbox also is able to "see" clock outputs from the DCM tiles
which have been connected to drive a global clock resource.
So, if you place a logic signal on the global clock resource, it has
only one possible destination: the clock inputs of the tiles.
In V5 we added the ability of the global signal to "get off" the H-tree
at the destination, and re-enter local interconnect.
Austin
Rgamer
So, I can't use a global line for reset and like all Xilinx guys say,
I shouldn't use it.
IMHO the lack of reset circuitry is a serious flaw.
I have a global enable too, that must get everypart of the design.
Again, no way to use it as global. This is even a more serious flaw,
since enable is the best design pratice regarding FPGAs.
I think I'll have to prey that PAR meet my timing constraints, as they
are somewhat tight... Does anyone have a better idea than using low
skew lines?
Can it be done with any other FPGA that can route a common signal to a
global net, without being a clock? I´ve read that both Altera and
Lattice support reset signals, *maybe* they support other signals too.
Regards,
Andrew FPGA
Bold statement :) More likely we don't know or understand their
reasons for not including it. Every new thing added has a cost. I can
guess at some reasons:
-global routing networks are expensive, clearly they are justified for
clocks, but reset?
-this is reconfigurable hardware so following power up the FPGA is put
into a known state following configuration - so is reset really
required?
-Reset can be coded into your design where needed. Providing resets on
the inputs and outputs, and waiting for the pipeline/intermediate
registers to flush gives the appearance of, and has the same effect as
a design wide reset.
Regards
Andrew
Eric Smith
to drive FF resets:
> Every new thing added has a cost. I can guess at some reasons:
> -global routing networks are expensive, clearly they are justified for
> clocks, but reset?
I don't think anyone was proposing adding additional global nets. The
question is how expensive would it be to add either:
1) Additional routing resources within the CLB to allow an existing
global clock net to drive the FF reset
2) Additional routing resources within the CLB to allow an existing
global clock net to drive local lines, which could then be used
for logic and/or to drive the FF reset
Apparently the Virtex 4 and 5 have done one of these, so the answer
is that the cost isn't too high to preclude doing it in high-end FPGAs.
Maybe the cost is too much for Spartan series FPGAs, or maybe it will
appear in a future part, i.e., the 65nm Spartan-4 parts that Wim Roelandts
said we'd get in 2007. Time's running out, guys! :-)
http://www.ednasia.com/article-2591-itisamyththatxilinxhasnolowkproduct-Asia.html
Rgamer
they are justified for clocks, but reset?"
Yes, reset! Lets say I have a computational block, that must be
cleared after computaion and I must save older values. I won´t
reprogram the FPGA every time.
Or let me say that one can use partial reconfiguration. The other
parts of the system are always allowed to keep an unkown state?
But some will say: "use a sync reset". And I tell: same problem. I
wish it global!
And how about a global enable signal? Or somekind of global control?
I still find that the lack of global lines for logic is even a serious
flaw, worst then the reset one.
Regarding to Erics comments, as follow:
> I don't think anyone was proposing adding additional global nets. The
> question is how expensive would it be to add either:
Agreed. And even if its expensive, global generic nets would be
useful. Be for reset or not. Like I said, I'd like to use a global
enable too.
> 1) Additional routing resources within the CLB to allow an existing
> global clock net to drive the FF reset
>
> 2) Additional routing resources within the CLB to allow an existing
> global clock net to drive local lines, which could then be used
> for logic and/or to drive the FF reset
>
> Apparently the Virtex 4 and 5 have done one of these, so the answer
> is that the cost isn't too high to preclude doing it in high-end FPGAs.
> Maybe the cost is too much for Spartan series FPGAs, or maybe it will
> appear in a future part, i.e., the 65nm Spartan-4 parts that Wim Roelandts
> said we'd get in 2007. Time's running out, guys! :-)
> http://www.ednasia.com/article-2591-itisamyththatxilinxhasnolowkprodu...
But I´m still looking for a FPGA that has global generic nets.
Brian Drummond
wrote:
>I understood. And thanks for all for the replies.
>
>So, I can't use a global line for reset and like all Xilinx guys say,
>I shouldn't use it.
>IMHO the lack of reset circuitry is a serious flaw.
>I have a global enable too, that must get everypart of the design.
>Again, no way to use it as global. This is even a more serious flaw,
>since enable is the best design pratice regarding FPGAs.
>
>I think I'll have to prey that PAR meet my timing constraints, as they
>are somewhat tight... Does anyone have a better idea than using low
>skew lines?
If you control your design from some central state machine, add several
states between the "reset" state and the central despatcher state (e.g.
"idle" where you wait for inputs to react to and depatch to states that
do the work).
That guarantees that nothing else in your design will be active for
those several cycles; therefore reset to anything OUTSIDE these states
can be constrained as a multicycle path.
- Brian
Rgamer
wrote:
> On Wed, 28 Nov 2007 08:59:30 -0800 (PST), Rgamer <rgamer1...@gmail.com>
I thought another solution for either global reset and global enable:
I kept the global buffer, since it has more strength (greater fanout)
and I added the attribute for low skew lines. That should do a good
job.
Regards,
RCIngham
>But I'm still looking for a FPGA that has global generic nets.
>
>
them.
(If my memory is wrong, I apologise in advance for the waste of time).
nei...@pipstechnology.co.uk
Yes Actel does have this facility, the ProAsic family anyway. They
also have the ability to split a single global net into lots of little
local global nets, or spines as they call them. I have previously
used this on the APA devices and found it very useful for things like
enables. The PA3 and fusion devices give you even more global nets to
play with.
Depending on your design complexity, they are well worth a look at.
My only problem with them is the lack of dedicated multipliers.
Carl
http://www.fpga-dev.com/resets-make-them-synchronous-and-local/
jt_eaton
>
>I=B4ve read a lot about resets and I=B4ve decided that for my designs, an
>No discussions here, this is a personal (almost religious) choice.
>
that has zero scientific evidence to support it?
What you are looking for is called a synchronous reset distribution tree.
Google that and you find some papers on it on Cliff Cumming's web site. It
is the only way to distribute an asynchronous assert/synchronous deassert
reset without skew.
Global resources are used when you have to deal with fast signals. PowerOn
reset is very very slow. Don't waste resources on it.
Remember that the reset system only has two requirements.
1) Force the chip into a known good state while the reset button is
pressed.
2) Do nothing while the reset button is not pressed.
Most designers obsess over making sure the first condition is met while
barely considering the second one. This is odd because if you screw up
either one then your product will fail. Which one should keep you awake at
night?
Your product will spend 99.999999% of its power on time running and
susceptible to esd induced resets but it is only possible to have a power
on reset failure during the 0.000001% of the time that it is powering up.
Modern digital tool flows can easily catch design errors that would prevent
a chip reset in the RTL phase. Simulating esd events is a lot harder and
most of this is done by QA testing.
These failures are asymmetric. If an esd event can get into your chip and
change state on a flop then your product is crap. If your power on reset
fails to reach a flop it will simply take on the next state value provided
by the mission mode logic. What will that be? It will almost always be the
same as the reset state.
The power on reset system has a good deal of redundancy.Everybody first
puts in a power on reset system and then adds their mission mode logic that
backs up the power on reset with the mission mode soft reset systems. You
can forget to connect a flop into the power on system and it will likely
still work.
It is almost impossible to screw up the reset system so that your product
fails to power up AND to do so in a way that your verification suite won't
catch it.
But it is very easy to have a esd entry path and not catch it till you get
the customer returns. You should first worry about preventing phantom
resets and after you have solved that then worry about getting power on
reset into your chip.
If you do that then you will never run an asynchronous reset signal down to
the core flops. Read Xilinx WP-231.
John Eaton
---------------------------------------
Posted through http://www.FPGARelated.com
glen herrmannsfeldt
>>Hello Group
>>
>>I=B4ve read a lot about resets and I=B4ve decided that for my designs, an
>>asynchronous solution with a synchronous source is a better solution.
>>No discussions here, this is a personal (almost religious) choice.
> Religious choice is an apt description. How else can you
> justify something that has zero scientific evidence to support it?
> What you are looking for is called a synchronous reset distribution tree.
> Google that and you find some papers on it on Cliff Cumming's web site. It
> is the only way to distribute an asynchronous assert/synchronous deassert
> reset without skew.
some way to get from configuration reset to operation.
> Global resources are used when you have to deal with fast signals.
> PowerOn reset is very very slow. Don't waste resources on it.
> Remember that the reset system only has two requirements.
> 1) Force the chip into a known good state while the reset button is
> pressed.
> 2) Do nothing while the reset button is not pressed.
> Most designers obsess over making sure the first condition is met while
> barely considering the second one. This is odd because if you screw up
> either one then your product will fail. Which one should keep you awake at
> night?
then there should be no problem. Otherwise, yes, you do have to be
very careful about the transition.
-- glen
Christopher Head
this is any mention whatsoever of the FPGA’s built-in reset
capabilities. For Xilinx Spartan FPGAs anyway, this is called
“GSR” (global set/reset). It’s certainly global, and I believe it’s
asynchronous. I don’t know what kind of skew it typically has, but it
has one wonderful benefit when it’s usable: it’s absolutely 100% free.
The GSR network is built into the chip whether you use it or not, so
using it to reset all your FFs costs absolutely nothing in terms of
LUTs and routing, something no other solution can claim. When dealing
with a nearly-full FPGA, that’s a very attractive property.
As far as issues of different FFs leaving reset on different clock
cycles are concerned, could one not solve these issues by asserting GSR
for long enough to reset all FFs, deassert it, then activate the clocks
afterwards? Using BUFGCEs (in Xilinx parlance) one could do this with a
very small chunk of logic, far less than the overhead of building
synchronous resets by routing the reset signal around the chip and then
feeding it into all the LUTs that make up feedback loops (increasing
LUT count in, say, one sixth of such cases where the LUT was already
populated by six inputs). Driving the ENABLE input of a canned
oscillator off a shift register of sufficient length clocked by the
internal configuration clock would probably achieve something similar.
Am I missing something about this proposed solution?
I really wish someone would write one of these articles about system
reset that acknowledges the existence of GSR and compares it to other
reset mechanisms and points out the advantages and disadvantages of
each. Unfortunately “someone” won’t be me, because I’m nowhere near an
FPGA expert and couldn’t hope to give it a proper treatment. Maybe
someone has written such an article, but I haven’t seen it.
Chris
Brian Drummond
> On Tue, 18 Sep 2012 07:31:18 -0700 (PDT)
> Carl <car...@gmail.com> wrote:
>
>> An article on the local/global and synchronous/asynchronous aspects of
>> resets:
>>
>> http://www.fpga-dev.com/resets-make-them-synchronous-and-local/
>
> Something that always seems to be missing when I read articles like this
> is any mention whatsoever of the FPGA’s built-in reset capabilities. For
> Xilinx Spartan FPGAs anyway, this is called “GSR” (global set/reset).
>
> cycles are concerned, could one not solve these issues by asserting GSR
> for long enough to reset all FFs, deassert it, then activate the clocks
> afterwards?
Either way, you may need a hierarchy of clock activation; after reset,
you don't want your main clock generator to wait for several cycles of a
(stopped) clock...
- Brian
jone...@comcast.net
>If you do that then you will never run an asynchronous reset signal down to the core flops. Read Xilinx WP-231.
If we are trying to avoid religion, "never" is a very long time and is almost certainly untrue.
There are many valid reasons to use an asynchronous reset, and many valid reasons to use a synchronous reset. Let's just leave it at that, without all the pontifications invoking "never" (or "always").
Besides, the OP's Q has nothing to do with async vs sync reset; both usually need to meet timing anyway.
Andy
jt_eaton
You don't need to stop the clock at all. The reset deassert to clock edge
spec only applies when you are trying to change state. So if you reset
the flop to 0 and have a 1 sitting on the D input then you must meet
timing or it will go metastable. If you have a 0 on the D input then
it doesn't matter if you meet timing. The flop will stay at 0.
Most designs already do this. When an ethernet interface comes out of
reset
it doesn't suddenly start ethernetting, It waits for the CPU to write
setup
and other data before it does anything. That means that once all of its
flops
are in reset state then they all have that reset state applied to their D
inputs until the first cpu write.
You can deassert a asynchronous reset at any time as long as your
asynchronous reset system is backed up with a synchronous one provided
by the mission mode logic. You do have to be careful with the cpu or any
other block that self starts but thats easy to deal with.
Brian Drummond
>>On Wed, 19 Sep 2012 00:15:52 -0700, Christopher Head wrote:
>>> As far as issues of different FFs leaving reset on different clock
>>> cycles are concerned, could one not solve these issues by asserting
>>> GSR for long enough to reset all FFs, deassert it, then activate the
>>> clocks afterwards?
>>
>>Yes. Perhaps better, activate clock enable(s) afterwards.
>>
>>Either way, you may need a hierarchy of clock activation; after reset,
>>you don't want your main clock generator to wait for several cycles of a
>>(stopped) clock...
>>
>>- Brian
>>
>>
> Guys,
>
> You don't need to stop the clock at all. The reset deassert to clock
> edge spec only applies when you are trying to change state.
shot myself in the foot with a synchronous reset for a DLL...
- Brian
Brian Drummond
>>> As far as issues of different FFs leaving reset on different clock
>>> cycles are concerned, could one not solve these issues by asserting
>>> GSR for long enough to reset all FFs, deassert it, then activate the
>>> clocks afterwards?
>>
>>Yes. Perhaps better, activate clock enable(s) afterwards.
>>
>>Either way, you may need a hierarchy of clock activation; after reset,
>>you don't want your main clock generator to wait for several cycles of a
>>(stopped) clock...
>>
>>- Brian
>>
>>
> Guys,
>
> You don't need to stop the clock at all. The reset deassert to clock
> edge spec only applies when you are trying to change state.
jt_eaton
>
>I've read WP-231, and it best be taken with a big dose of salt, like most
generalizations. Please note the date, and the applicable series of FPGAs.
>
>
It's dated 2006. While that is considered old in some parts of this
industry it is very modern when it comes to reset systems. The global async
assert/sync
deassert reset that is prevalent through out the IC world has been around
since the 1980's and was derived from the board level reset systems used
back
in the days of disco.
The important thing about WP-231 is that it was written by the engineers
that
are the experts on the silicon and tools and provides very specific
examples
of why decades old design practices are not optimal for todays deep
submicron processes
A lot of advice that you hear from component designers is out of date and
should be ignored, but when the people who wear bunny suits at work give
you advice then you really need to listen.
glen herrmannsfeldt
(snip)
> You don't need to stop the clock at all. The reset deassert to clock edge
> spec only applies when you are trying to change state. So if you reset
> the flop to 0 and have a 1 sitting on the D input then you must meet
> timing or it will go metastable. If you have a 0 on the D input then
> it doesn't matter if you meet timing. The flop will stay at 0.
can be sure that they are not enabled as they come out of reset,
then you don't have to worry about the clock timing.
> Most designs already do this. When an ethernet interface comes out of
> reset it doesn't suddenly start ethernetting, It waits for the
> CPU to write setup and other data before it does anything.
> That means that once all of its flops are in reset state then
> they all have that reset state applied to their D inputs until
> the first cpu write.
outside logic, but that should be usual in the case of a processor.
> You can deassert a asynchronous reset at any time as long as your
> asynchronous reset system is backed up with a synchronous one provided
> by the mission mode logic. You do have to be careful with the cpu or any
> other block that self starts but thats easy to deal with.
HT-Lab
> On Tuesday, September 18, 2012 9:02:29 PM UTC-5, jt_eaton wrote:
>> If you do that then you will never run an asynchronous reset signal down to the core flops. Read Xilinx WP-231.
>
> I've read WP-231, and it best be taken with a big dose of salt, like most generalizations. Please note the date, and the applicable series of FPGAs.
>
> If we are trying to avoid religion, "never" is a very long time and is almost certainly untrue.
>
> There are many valid reasons to use an asynchronous reset, and many valid reasons to use a synchronous reset.
http://microelectronics.esa.int/asic/fpga_001_01-0-2.pdf
Skip to section 3.1.
In a nutshell, the Nasa Wire satellite was lost due to the use of a
synchronous reset.
Hans
www.ht-lab.com
Mark Curry
>An article on the local/global and synchronous/asynchronous aspects of resets:
>
>http://www.fpga-dev.com/resets-make-them-synchronous-and-local/
my reponse - it's some ideas that I've often thought of when seeing this
advice like this, but never get "pen to paper" as it were.
Thinking about resets are good, and having a good strategy,
very important, but I disagree with a lot of this advice.
And this type of advice been coming out of the FPGA companies for
a while.
But here's my 4 cents. (Too long for just 2 cents.)
I come from an ASIC background - where logic's cheap. ( I know this
is an FPGA newsgroup - bare with me. )
There, for all of our designs we used a global resets streategy, which
ASYNCHRONOUSLY reset FFs.
i.e. in verilog:
Example 1.
reg foo;
always @( posedge clk or negedge reset_n )
if( ~reset_n )
foo <= 0;
else
foo <= bar;
The reset_n input to the module was generated near the
top level of the chip. At the top level, the main system
reset would have it's de-assertion edge synchronized to each
clock domain - effectively creating a per-clock reset
signal. (I'm leaving out a LOT of qualifiers for this
including control of reset during test, etc. But the
key, the resets are generated at the top-level globally).
Furthermore, we reset EVERTHING that could be reset.
The requirements for the reset to work:
1. The input reset needs to be appropriately de-glitched
to avoid false assertions or de-assertions.
2. It's pulse width large enough to be capture by
the async input (on the order of nanoseconds)
That's it. You meet the above requirements, you'll safely enter the
reset state. You'll succesfully exit the reset state - once the reset
de-asserts AND THE CLOCK is running. If the clocks not running, you'll
stay reset.
The advantage of this approach:
Point 1. - You're always right. You can't hurt anything be resetting
a FF.
Point 2. - Simulating bringup is faster - perhaps MUCH faster. I've
spent sometimes weeks chasing the "sea-of-red" bring ups in
simulation - the results of X-Pessimism. I've seen all sorts of
kludge "demeta" tricks in simulation to work around these issue - and
there just that - Kludge testbench work that usually offers nothing
towards to the reliability of the design.
Point 3. - Reducing X's in simulation (by resetting everything) also
reduces the chances of X-Optimism. A much lower occuring problem,
but one with a larger penalty if missed (RTL sim vs. gates
mismatch).
The disadvantages - it's not optimal. You may waste resources
distributing the resets, and meeting the timing of the
reset recovery path. Note that all modern STA tools have
no trouble checking this timing.
Ask any business manager if this is the correct priority:
1. Correct, and Reliable.
2. Faster debug and verification.
3. Optimal
You won't get much argument. And that 3rd objective will probably be
MUCH lower that the first two.
The amount of logic "wasted" on this strategy, is tiny in this deep
sub-micron age. We even used the same clock tree methodology for
distributing the resets. Wasteful - sure. But who cares?
After a while of that I came over to FPGAs. FPGA's haven't been
designed to waste a global low-skew route on this async reset.
So, I switched to using synchronous resets:
Example 2.
reg foo;
always @( posedge clk )
if( ~reset_n )
foo <= 0;
else
foo <= bar;
Again the reset is generated globally, with de-assertion edge
synchronized to respective clock.
The requirements for reset to work : same as above PLUS:
3. You're clock must be running to enter reset.
A normally simple-to-meet requirement, but can lead to perplexing debug
in areas around non-free running clocks (i.e. around PLLs, and other
clock-management logic).
Again, I reset EVERYTHING that can be reset.
This strategy is not too different that the first. Some extra
head-scratching to be sure we're okay with extra reset requirement.
But in general it works.
The advantages and disadvantages of this approach are similar to the
first case. The back end tools must meet timing on all reset
paths. All FPGA tools will check this - the reset's basically just
like any other signal, albeit usually with a larger fanout.
To alleviate the large fanout - if it's even a problem, I can just
pipeline it (at the top level - globally!) a few times. Then allow
the tool to do any neccesary register duplication and perhaps register
balancing. The back end tools have solved this problem for me.
This leads my next evolution in resets: "Selective" reseting.
As many designers are apt to point out, EVERYTHING does not need
to be reset. This is true. Datapath logic is probably safe to leave
un-initialized.
Example 3.
reg [ 7 : 0 ] foo_data;
reg foo_control;
always @( posedge clk )
if( ~reset_n )
begin
foo_control <= 0;
//foo_data <= 0;
end
else
begin
foo_control <= bar;
foo_data <= some_data;
end
Here the control signal "foo_control" is reset. The datapath element
"foo_data" is not. And I usually code it just as above with the
reset clause explicity commented out.
The advantage of this approach - we can pick up a lot of optimizations
over reseting everything. Especially in targetting delay shift
registers (i.e. SRL16s in Xilinx).
But the disadvantages - slower coding, and the risk of missing a needed
reset. When I'm coding a low-level module - possible one that's going
to be shared across many FPGAs- I need to stop and think a bit more on
what must be reset, and what's safe to leave uninitialized. Do I know
of all use cases of this module? Will it be safe in all cases to not
reset this signal? This is often a hard requirement to decide. You
aften don't have all the information at the time of the coding to
make this decision.
So often I punt and leave the reset in - especially when
I bringup first testbenches and see that dreaded "sea-of-red".
If I suspect its got ANYTHING to do with that uninitialized signal -
that reset's going back in. I can always go back in and re-comment
out the reset assignement, to be more optimal.
But once the design is right how often will a designer be given the
time to go back in and make it more "optimal"? Probably only when
pushed into a corner.
The last style, often touted by FPGA companies, basically boils down
to - don't reset at all. The design comes up out of FPGA configuration
in a known, default state. Often the synthesis tools can be configured
to adjust this default state with init values:
Example 4.
reg [ 7 : 0 ] foo_data = 0;
reg foo_control = 0;
always @( posedge clk )
begin
foo_control <= bar;
foo_data <= some_data;
end
I.e. the synthesis tool uses the verilog init value as the configuration
time value. Here, reset's are the exception not the rule. Only reset
those very few elements that explicitly require it, and must see that
edge.
Advantages of this : an optimal design.
The biggest drawback... FPGA Configuration is usaully NOT equal to
RESET. Most of my boards have at least some kind of push-button reset,
probably another controlled by some sort of processor. This reset is
a distinct operation - quite seperate from FPGA "CONFIG".
Plus, well, I'm very hesitant with this approach. Reset and
initialization problems can lie hidden for a long time. During bringup,
often a lot of things are in flux, and a random init problem is often
written off as some random event, and ignored. "Hey I just ran it
again it worked this time."
So the problem lies hidden much longer. Months down the line when
my manufacturing line ( or worse - customer ) comes back to be and
says, "Hey I sometimes have to reset this thing twice to get it to
work". I'd be MUCH more comfortable in this situation knowing that
I had a solid reset in my FPGA design.
"Correct and Reliable" has priority over "Optimal" for me.
Regards,
Mark
jone...@comcast.net
Nice write-up! In the end, if you count up all the time (money) spent determining AND VERIFYING what does not NEED to be reset, you'd have been better off resetting everything to start with, and only pulling out the reset where it kills your utilization (by kill, I don't mean raises util from 85% to 86%, I mean it doesn't fit!).
The pipe-lining/retiming trick for handling fanout on the synchronous reset also works great for synchronously deasserted asynchronous resets!
When coding a process that has some registers reset and others not, if you use the familiar "reset ... elsif clock ..." structure, your fanout on reset may not be reduced, because every register that saved a reset, added a clock enable (or another input to existing clock enable logic).
When I have both reset and non-reset signals/variables in the same process (e.g. ram arrays, etc.), I use the following structure to avoid clock disable on non-reset signals/variables:
process (clk, rst) is
begin
clocked: if rising_edge(clk) then
-- logic assignments here
end if clocked;
reset: if rst then
-- reset assignments here
end if reset;
end process;
Although this style works fine for the general case (when everything is reset), I do not use this style unless I actuall need it. The reason is, in the conventional reset elsif clock structure, you will get synthesis warnings (from synplify at least) about feedback multiplexers on non-reset registers. You won't get those warnings for them if you use the method above. This also makes the above approach rarer, which stands out for the reviewer, where it gets extra attention to make sure that everything that should (can?) be reset is reset.
The same clock enable problem also happens when you use an "if reset else logic" structure for a synchronous reset. Nothing after that "else" executes when reset is true, which results in extra clock enable logic on non-reset registers. Use a similar approach to the above, by moving the (synchronous) reset assignments to their own if-statement just before the end of the clocked if-statement:
process (clk) is
begin
if rising_edge(clk) then
-- logic assignments here
if rst then
-- reset assignments here
-- to avoid clock enables
-- on non-reset registers
end if;
end if;
end process;
Strange how I didn't see any of this in that white paper written by the "experts"...
Andy
Christopher Head
about: you just give every variable or signal an initial value which is
loaded during bitstream load and let the configuration-clock-based GSR
handling deal with the rest. Make sure PLLs and DCMs start up after GSR
is deasserted and that everything uses a clock downstream of a PLL or
DCM (and perhaps introduce some BUFGCEs) and everything should be OK—at
least, for my application it’s easy enough to things that way. Clock
domain crossings might come up in either order, but that’s pretty easy
to deal with.
Chris