FSM in illegal state

[Peter Alfke]

Let me get back to the fundamental problem:
We distribute a (p)reset signal all over the chip. The problem is not the
activating edge of this signal, it's the release of (p)reset. No matter how
we distribute and phase it (unless there is only a single user clock of
relatively low frequency) the trailing edge will not appear at every
flip-flop in the same clock period. Whether the (p)reset is asynchronous or
synchronous does not matter. I do not see a way to solve this dilemma on the
chip-hardware-design level.
I suppose the software could be made smart enought to handle this, same as
smart designers can design around this. Especially with an elegant construct
like SRL16.
Peter Alfke

From: Jim Lewis <Jim@SynthWorks.com
Organization: Posted via Supernews, http://www.supernews.com
Newsgroups: comp.arch.fpga,comp.lang.vhdl
Date: Wed, 14 Jul 2004 12:01:13 -0700
Subject: Re: FSM in illegal state (conclusion)

Rick,
These circuits are typically FSM, counters and the like.
Normally the data path does not care about reset since it
will immediately go to the correct state on the next clock.
I am a former ASIC designer. I think I understand this
part well. I do have a couple concerns. First I want a
reset methodology that is device independent and
simulates well for any ASIC or FPGA technology not
just specific to Xilinx. Hence, everything that requires
reset will need the synchronized reset. I agree most
data path does not need reset (except for on some ASIC designs
to get the device to pass vectors more easily on the tester).

My second concern is that selective reset is not for
everyone. For some this methodology will cause chaos.
For a design review with selective reset, this is just
one more item that needs to be reviewed in detail.


One circuit you can add to any FSM to provide a sync reset is just one
or a pair of FFs which work just like a metastability reduction
circuit. Have the GSR hold these FFs in the '1' state and wire the D
input of the first one to a '0'. The last output will be your sync
reset. The sync reset will be held for one or two clock edges after the
release of GSR. This will only need to be used by the first two bits of
a one-hot FSM, the first changed bit of a gray coded counter, the first
bit of a JRC or even the first bit of a binary counter (assuming it
starts at 0); and so will not overly complicate them and slow them
down.
To me this seems like Chaos**n. Not that it will not work,
it just adds more details you need to manage.

This methodology would have to buy me something significant
(speed or device size) for me to want to do additional
analysis and verification to prove that a circuit designed
as above actually works under all conditions.


If this is possible, is there a VHDL coding methodology
that you can recommend? The big missing piece for me
is how do I access the output of GSR?


This is something that should be added to Peter's app note.


#1: Explicitly through instantiation?
#2: Implicitly through initializing the VHDL
signals that create the registers?
Although this technique seems possible in XST,
would it also work the same in other synthesis tools?
#3: Put the reset logic in a separate hierarchical
block and explicitly code an asynchronous reset, but
at the next level of the design tie the asynchronous
reset to a constant inactive value?


You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This sounds like it would address my needs nicely.
What do you connect reset to? Do you just leave
it floating? What do you do with it in simulation?

If there is something here that would work with
XST, Synplicity, and Mentor, without changing the
code, this would make me happy. Especially if
the only thing I needed to change for each FPGA/ASIC
technology is the reset block and where the power-on
reset comes from.


You can learn a lot about it by reading how the end of configuration
works. But the main thing is to stop assuming that the end of GSR is a
synchronous event. On other chips we get used to the reset just working
(like magic). In the FPGA we need to give it a little thought, even if
it is not really hard.
On ASICs reset is explicit. On your flow above with Xilinx,
I code reset on the register, hook it to ?? or leave it
unconnected, and then "magically" it gets connected to GSR.

Is there a datasheet, manual, or appnote you recommend reading
on configuration.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[rickman]

Jim Lewis wrote:

Rick,
These circuits are typically FSM, counters and the like.
Normally the data path does not care about reset since it
will immediately go to the correct state on the next clock.
I am a former ASIC designer. I think I understand this
part well. I do have a couple concerns. First I want a
reset methodology that is device independent and
simulates well for any ASIC or FPGA technology not
just specific to Xilinx. Hence, everything that requires
reset will need the synchronized reset. I agree most
data path does not need reset (except for on some ASIC designs
to get the device to pass vectors more easily on the tester).

My second concern is that selective reset is not for
everyone. For some this methodology will cause chaos.
For a design review with selective reset, this is just
one more item that needs to be reviewed in detail.

I don't design huge devices. I also normally need to conserve gates.
So I typically am working close to the hardware. This selective reset
(as you call it) is just SOP for me. I don't use test vectors (can't
you provide don't cares?) and the chaos is only if you don't use it
correctly.

But all of this is only to save gates and/or improve speed. Trying to
route a chip wide sync reset can end up running into the same timing
issues as the async reset if the fanout is too large. I once worked on
an Altera design where we had CEs with large fanouts at 80 MHz. The
timing analysis software did not work correctly for these signals and we
had a he77 of a time getting the chip to actually work on the bench when
the software said all was well. Being 80% full didn't help much
either. But my point is that chip wide, large fanout signals can be
problematic. So I make sure I understand what my chip needs to startup
correctly and deal with that. Of course ASIC design requires a whole
different level of confidence, but the method is not any different for
an ASIC. You just have to make sure you did your homework, just like
when you design your FSM in the first place. A small mistake in the FSM
can work great in simulation and even on the test bench, but end up
failing in the field and lock up the whole thing. I can vouch for
that.

One circuit you can add to any FSM to provide a sync reset is just one
or a pair of FFs which work just like a metastability reduction
circuit. Have the GSR hold these FFs in the '1' state and wire the D
input of the first one to a '0'. The last output will be your sync
reset. The sync reset will be held for one or two clock edges after the
release of GSR. This will only need to be used by the first two bits of
a one-hot FSM, the first changed bit of a gray coded counter, the first
bit of a JRC or even the first bit of a binary counter (assuming it
starts at 0); and so will not overly complicate them and slow them
down.
To me this seems like Chaos**n. Not that it will not work,
it just adds more details you need to manage.

Yes, more details, but each one is separate. If you have startup
dependancies between your FSMs, that has to be managed even if you have
a global sync reset. This does not change that.

This methodology would have to buy me something significant
(speed or device size) for me to want to do additional
analysis and verification to prove that a circuit designed
as above actually works under all conditions.

Speed is just what it is about. If you have to add another input to
every FF on the chip (some of which don't have a lut if they are just
delay registers) I can assure you that many of them will end up adding a
layer of logic and therefore another increment of delay. If your design
is not timing critical, then this is not an issue.

If this is possible, is there a VHDL coding methodology
that you can recommend? The big missing piece for me
is how do I access the output of GSR?


This is something that should be added to Peter's app note.


#1: Explicitly through instantiation?
#2: Implicitly through initializing the VHDL
signals that create the registers?
Although this technique seems possible in XST,
would it also work the same in other synthesis tools?
#3: Put the reset logic in a separate hierarchical
block and explicitly code an asynchronous reset, but
at the next level of the design tie the asynchronous
reset to a constant inactive value?


You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This sounds like it would address my needs nicely.
What do you connect reset to? Do you just leave
it floating? What do you do with it in simulation?

That depends on the target and tools. Many HDL packages will detect the
async reset and connect it to the GSR, similar to the way they detect
clock signals and use the global clock buffers. Some may still require
instantiation of an internal async reset signal source. Check with your
tool/chip vendor.

If there is something here that would work with
XST, Synplicity, and Mentor, without changing the
code, this would make me happy. Especially if
the only thing I needed to change for each FPGA/ASIC
technology is the reset block and where the power-on
reset comes from.

The above style is what I learned to use before anyone was providing any
automatic support. You used to need to instantiate the driver for this
signal or even provide it at a schematic level at the top of the
design. As far as I know all vendors support this, but check with the
tool vendor to be sure. Don't they have style guides?

You can learn a lot about it by reading how the end of configuration
works. But the main thing is to stop assuming that the end of GSR is a
synchronous event. On other chips we get used to the reset just working
(like magic). In the FPGA we need to give it a little thought, even if
it is not really hard.
On ASICs reset is explicit. On your flow above with Xilinx,
I code reset on the register, hook it to ?? or leave it
unconnected, and then "magically" it gets connected to GSR.

Is there a datasheet, manual, or appnote you recommend reading
on configuration.

I don't know which app note would be good, but Xilinx has lots of them.
Do a doc search on their web site on the line of chips you are using and
the word "startup" or "configuration".

--

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX

 

[Jim Lewis]

Peter,
As an ASIC designer, I understand the fundamental issues
with propagating signals - including reset deassertion.
I also understand VHDL quite well.

What is not clear to me is the relationship between
my code, my reset, and Xilinx GSR after synthesis.
The following code specifies a single reset:

process (Clk, nReset)
begin
if nReset = '0' then
Y <= '0' ;
elsif rising_edge(Clk) then
Y <= A ;
end if ;
end process ;

What I think I am hearing is that after synthesis
targeting Xilinx technology, the reset of the register
is connected to both GSR and my nReset signal. My
nReset signal typically comes from a block which
resynchronizes it similar to how Ken Chapman recommends.

Am I right so far? I am scanning through your Basic
VHDL document. Since I know VHDL quite well, I would
not normally read this document. I see the above
conclusions in the resulting logic equations, however,
I do not see it in written text. Is there another
document that explains this?

Going further, how do I write VHDL that will reset a
register using GSR, but not an require external reset?
It sounds like what I am hearing (rickman) is
that I code it like above and tie the nReset
signal to '1' (or leave it unconnected?) and GSR will
remain connected to the FF after synthesis.

Is this part right?
I am not real comfortable with this part of the process
as in ASIC synthesis, if you tie the nReset signal
inactive then it is likely to remove that function
from the register. If this is what you really do,
it is so foreign to me that I need to hear it again
and again in your documentation.

Once I know the correct method for the above, I
too can be as smart as the other smart designers
dealing with this issue.

Best Regards,
Jim

Let me get back to the fundamental problem:
We distribute a (p)reset signal all over the chip. The problem is not the
activating edge of this signal, it's the release of (p)reset. No matter how
we distribute and phase it (unless there is only a single user clock of
relatively low frequency) the trailing edge will not appear at every
flip-flop in the same clock period. Whether the (p)reset is asynchronous or
synchronous does not matter. I do not see a way to solve this dilemma on the
chip-hardware-design level.
I suppose the software could be made smart enought to handle this, same as
smart designers can design around this. Especially with an elegant construct
like SRL16.
Peter Alfke


From: Jim Lewis <Jim@SynthWorks.com
Organization: Posted via Supernews, http://www.supernews.com
Newsgroups: comp.arch.fpga,comp.lang.vhdl
Date: Wed, 14 Jul 2004 12:01:13 -0700
Subject: Re: FSM in illegal state (conclusion)

Rick,

These circuits are typically FSM, counters and the like.
Normally the data path does not care about reset since it
will immediately go to the correct state on the next clock.

I am a former ASIC designer. I think I understand this
part well. I do have a couple concerns. First I want a
reset methodology that is device independent and
simulates well for any ASIC or FPGA technology not
just specific to Xilinx. Hence, everything that requires
reset will need the synchronized reset. I agree most
data path does not need reset (except for on some ASIC designs
to get the device to pass vectors more easily on the tester).

My second concern is that selective reset is not for
everyone. For some this methodology will cause chaos.
For a design review with selective reset, this is just
one more item that needs to be reviewed in detail.



One circuit you can add to any FSM to provide a sync reset is just one
or a pair of FFs which work just like a metastability reduction
circuit. Have the GSR hold these FFs in the '1' state and wire the D
input of the first one to a '0'. The last output will be your sync
reset. The sync reset will be held for one or two clock edges after the
release of GSR. This will only need to be used by the first two bits of
a one-hot FSM, the first changed bit of a gray coded counter, the first
bit of a JRC or even the first bit of a binary counter (assuming it
starts at 0); and so will not overly complicate them and slow them
down.

To me this seems like Chaos**n. Not that it will not work,
it just adds more details you need to manage.

This methodology would have to buy me something significant
(speed or device size) for me to want to do additional
analysis and verification to prove that a circuit designed
as above actually works under all conditions.



If this is possible, is there a VHDL coding methodology
that you can recommend? The big missing piece for me
is how do I access the output of GSR?


This is something that should be added to Peter's app note.



#1: Explicitly through instantiation?
#2: Implicitly through initializing the VHDL
signals that create the registers?
Although this technique seems possible in XST,
would it also work the same in other synthesis tools?
#3: Put the reset logic in a separate hierarchical
block and explicitly code an asynchronous reset, but
at the next level of the design tie the asynchronous
reset to a constant inactive value?


You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This sounds like it would address my needs nicely.
What do you connect reset to? Do you just leave
it floating? What do you do with it in simulation?

If there is something here that would work with
XST, Synplicity, and Mentor, without changing the
code, this would make me happy. Especially if
the only thing I needed to change for each FPGA/ASIC
technology is the reset block and where the power-on
reset comes from.



You can learn a lot about it by reading how the end of configuration
works. But the main thing is to stop assuming that the end of GSR is a
synchronous event. On other chips we get used to the reset just working
(like magic). In the FPGA we need to give it a little thought, even if
it is not really hard.

On ASICs reset is explicit. On your flow above with Xilinx,
I code reset on the register, hook it to ?? or leave it
unconnected, and then "magically" it gets connected to GSR.

Is there a datasheet, manual, or appnote you recommend reading
on configuration.

Cheers,
Jim
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Jonathan Bromley]

On Wed, 14 Jul 2004 12:01:13 -0700,
Jim Lewis <Jim@SynthWorks.com> wrote:

[rickman:]

You don't need to access the GSR signal explicitly. If you provide an
async reset control that is common to most/all of your sequential logic,
I believe the tools will infer the GSR.

run_en_reg: PROCESS (sysclk, reset) BEGIN
IF (reset = '1') THEN
run_en <= '0';
ELSIF (rising_edge(sysclk)) then
run_en <= '1';
END IF;
END PROCESS;

This sounds like it would address my needs nicely.
What do you connect reset to? Do you just leave
it floating? What do you do with it in simulation?

If there is something here that would work with
XST, Synplicity, and Mentor, without changing the
code, this would make me happy. Especially if
the only thing I needed to change for each FPGA/ASIC
technology is the reset block and where the power-on
reset comes from.
[...]
On ASICs reset is explicit. On your flow above with Xilinx,
I code reset on the register, hook it to ?? or leave it
unconnected, and then "magically" it gets connected to GSR.

I've always tied-off my global reset to FALSE at the
top level, and tools then seem to infer configuration
values but I'm not sure whether it's the
"recommended" style.

Synth tool vendors could do us a great service by
legitimising VHDL signal initialisation,
*for flip-flops only*, to imply the configuration or power-up
state of a register. You could still use an explicit reset if
you so wish, but the design would then simulate correctly
even if reset was held false throughout. There was quite
a lot of discussion of this in 1076.6 and 1364.1 (VHDL
and Verilog synthesis subset standards) and ISTR it was
eventually rejected on the grounds that not all devices
support it. This mystified me, because there are plenty
other things in the synthesisable subset that are not
universally available (for example, BOTH asynch preset
AND asynch reset on the same register); if you use such a
construct and your target device can't implement it, the
tool must throw at least a warning to inform you.

XST experts please confirm, but I think XST accepts signal
initialisation, and infers configuration value from it.

Clearly this style would not be strictly portable across
target technologies. However, if the tools handle it all
sensibly, you could imagine a coding style that used BOTH
signal initialisation (to represent power-up or config reset)
AND global asynch reset (which could be tied-off FALSE).
Then you need to declare just one global constant:

constant FF_Startup_Value: std_ulogic := '0';
...
architecture RTL of stuff is
signal FF: std_logic := [not] FF_Startup_Value;
process (clk, reset)
if reset='1' then
FF <= '1';
...
Then change the constant to 'U' when targeting a device
that doesn't have reliable power-up values.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL, Verilog, SystemC, Perl, Tcl/Tk, Verification, Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail:jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Michael Smith]

"Jim Lewis" <Jim@SynthWorks.com> wrote in message
news:40F5EA1D.4080808@SynthWorks.com...

Peter,
As an ASIC designer, I understand the fundamental issues
with propagating signals - including reset deassertion.
I also understand VHDL quite well.

What is not clear to me is the relationship between
my code, my reset, and Xilinx GSR after synthesis.
The following code specifies a single reset:

process (Clk, nReset)
begin
if nReset = '0' then
Y <= '0' ;
elsif rising_edge(Clk) then
Y <= A ;
end if ;
end process ;

What I think I am hearing is that after synthesis
targeting Xilinx technology, the reset of the register
is connected to both GSR and my nReset signal. My
nReset signal typically comes from a block which
resynchronizes it similar to how Ken Chapman recommends.

Am I right so far? I am scanning through your Basic
VHDL document. Since I know VHDL quite well, I would
not normally read this document. I see the above
conclusions in the resulting logic equations, however,
I do not see it in written text. Is there another
document that explains this?

Going further, how do I write VHDL that will reset a
register using GSR, but not an require external reset?
It sounds like what I am hearing (rickman) is
that I code it like above and tie the nReset
signal to '1' (or leave it unconnected?) and GSR will
remain connected to the FF after synthesis.

Is this part right?
I am not real comfortable with this part of the process
as in ASIC synthesis, if you tie the nReset signal
inactive then it is likely to remove that function
from the register. If this is what you really do,
it is so foreign to me that I need to hear it again
and again in your documentation.

Once I know the correct method for the above, I
too can be as smart as the other smart designers
dealing with this issue.

Best Regards,
Jim

Forgive me if I've someone's mentioned it already, but I understand that, in
Virtex and later devices, synthesis tools do NOT infer the use of the GSR
from the VHDL Reset signal. Instead the user's Reset is routed using general
routing resources. (So, timing constraints can be applied to it.) There is
of course still an issue if the external signal is truly asynchronous to the
clock.

The effect of the GSR on the design's flip-flops is inferred from the
behavior of the Reset signal.You can change this using UCF INIT constraints
(care!)

The GSR is still used - at configuration time. It is an internal signal
driven from the STARTUP block. You can't get rid of it (nor would you want
to!) You can connect an external reset to the STARTUP block and hence drive
the GSR if you want - you do this by instancing a STARTBUF component. You
can also connect an internal signal to the STARTUP block to drive the GSR.
If you do neither of these, the GSR is only used at configuration.

I recommend Xilinx's "Simulation and Verification Guide", which discusses
all this. It is available with ISE or from:
http://www.xilinx.com/support/sw_manuals/xilinx6/download/

Mike Smith, Doulos Ltd.
my.name@myemployer.com

 

[Duane Clark]

Michael Smith wrote:

Forgive me if I've someone's mentioned it already, but I understand that, in
Virtex and later devices, synthesis tools do NOT infer the use of the GSR
from the VHDL Reset signal. Instead the user's Reset is routed using general
routing resources. (So, timing constraints can be applied to it.) There is
of course still an issue if the external signal is truly asynchronous to the
clock.

I am puzzled by how that would work. In normal use, the reset would be
driven by an internal ROC (in VHDL), or be driven only by the testbench
(in Verilog). So what would be the source of the reset signal in the
cases you mention? Or are you referring to an asynchronous reset driven
from a pin?

--
My real email is akamail.com@dclark (or something like that).

 

[Jim Lewis]

Jonathan,

I've always tied-off my global reset to FALSE at the
top level, and tools then seem to infer configuration
values but I'm not sure whether it's the
"recommended" style.
Thanks.

Synth tool vendors could do us a great service by
legitimising VHDL signal initialisation,
*for flip-flops only*, to imply the configuration or power-up
state of a register. You could still use an explicit reset if
you so wish, but the design would then simulate correctly
even if reset was held false throughout. There was quite
a lot of discussion of this in 1076.6 and 1364.1 (VHDL
and Verilog synthesis subset standards) and ISTR it was
eventually rejected on the grounds that not all devices
support it. This mystified me, ...
As a member of the working group, this type of situation

is frustrating for me. This is just evidence that not
enough people with specific knowledge (such as FPGA users/experts)
are participating in the working group (WG). Keep in mind,
WG activities (reflector, teleconference, meetings) are open
to all vested parties, so attend and speak up.

The next generation of 1076.6 has not started yet, but
there is no reason not to join the reflector and start
brain storming.
http://www.eda.org/siwg/

It would be nice also to see some Xilinx/Altera/Actel
AEs and developers join the working group.

Clearly this style would not be strictly portable across
target technologies. However, if the tools handle it all
sensibly, you could imagine a coding style that used BOTH
signal initialisation (to represent power-up or config reset)
AND global asynch reset (which could be tied-off FALSE).
Then you need to declare just one global constant:

constant FF_Startup_Value: std_ulogic := '0';
...
architecture RTL of stuff is
signal FF: std_logic := [not] FF_Startup_Value;
process (clk, reset)
if reset='1' then
FF <= '1';
...
Then change the constant to 'U' when targeting a device
that doesn't have reliable power-up values.
This would be interesting.

Best Regards,
Jim Lewis
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training mailto:Jim@SynthWorks.com
SynthWorks Design Inc. http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Just an Illusion]

Hi,

An other technique can be use in ASIC design too.
Because ASIC have commonly multi-clock domains, some of them can be
powered down when not required.
Clock gating logic are used to do it, and you have an enable input for
this logic; you can design this input to be active only after reset and
clocks input stability.

That give you a similar behavior than the FPGA proposal.

JaI

Jim Lewis wrote:

Hal,

What do ASIC/CPU designers do? My guess is that they don't
have a global-reset so their version of this problem is a bit
different.

In ASIC design, we would connect the asynchronous reset to the
circuit Ken showed (or one like it). Reset for each clock
domain is separately synchronized. Reset would need to settle
in a clock period. Routing generally allows this. If not,
you work it out (build a fanout tree with buffers or
registers). Going back some time, on my first ASIC we had
to manually balance the clock tree.

See my post. GSR would be generally alot more useful if
we could quantify in general that it settles in X to Y
amount of time and then apply its output to a circuit like
the one Ken shows to stabilize all logic or all control
logic. From the difference between Y and X we could calculate
how many states we needed to delay "critical" reset so that
it occurs last. Four registers is kind of ad-hoc and means
something much different for different clocks (20 MHZ vs
200MHZ).

Of course, going a step further, since synthesis tools can
and do recognize statemachines, and they know the clock
frequency of a particular clock, they could automatically
do the right thing for Xilinx (insert Ken's circuit).
However I like being in control of these type of things
and I am not sure I would like this solution.


Cheers,
Jim

 

[Sander Vesik]

In comp.arch.fpga Hal Murray <hmurray@suespammers.org> wrote:

What do ASIC/CPU designers do? My guess is that they don't
have a global-reset so their version of this problem is a bit
different.

a cpu "just" needs:
* known good value in the pc
* address translation and caches disabled

thats a very small amount of state that needs to be right. the rest can be
initiated to a known good state by software.

--
Sander

+++ Out of cheese error +++