Bulletproofing CPLD Design

B

Benjamin Todd

Guest
Hi Everyone!

I just read Xilinx Application Note 784...
http://www.xilinx.com/bvdocs/appnotes/xapp784.pdf

About bulletproofing CPLD Design. I consider myself to be pretty
experienced with Xilinx CPLDs, particularly 9500 devices, so I was quite
surprised to find the reccomendation 3. Using Strict Synchronous Design.

Ok, I know the principles of synchronous design, but I sometimes use
Asynchronous Resets in my designs, i.e. if RESET = '1' OR CLEAR = '1' then
blah blah

So, from you Xilinx Chaps, i'd be interested to know what you think, what
are the phenomena that mean I shouldn't use an Asynchronous Reset in CPLD
design, I never saw problems before, or is this XAPP being a little strict?

Thanks!
Ben
 
"Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
wrote in message news:dcnc8n$2c8$1@sunnews.cern.ch...
Hi Everyone!

I just read Xilinx Application Note 784...
http://www.xilinx.com/bvdocs/appnotes/xapp784.pdf

About bulletproofing CPLD Design. I consider myself to be pretty
experienced with Xilinx CPLDs, particularly 9500 devices, so I was quite
surprised to find the reccomendation 3. Using Strict Synchronous Design.

Ok, I know the principles of synchronous design, but I sometimes use
Asynchronous Resets in my designs, i.e. if RESET = '1' OR CLEAR = '1' then
blah blah

So, from you Xilinx Chaps, i'd be interested to know what you think, what
are the phenomena that mean I shouldn't use an Asynchronous Reset in CPLD
design, I never saw problems before, or is this XAPP being a little
strict?

Thanks!
Ben
Click to expand...
Strictly speaking, async set or reset like any other async input to a state
machine can produce meta-stability and related conditions. This can happen
specially when NOT all of the registers in the design have a reset and some
are purely driven by the clock. Consider this: You issue an async reset a
few ps before the rising clock edge. Now somewhere in your design you have a
D flip flop that receives only an input and a clock signal. By poor chance,
that input is driven by another register that uses this async signal for
reset. The effect? You're violating the setup/hold time of our innocent D
flip flop that has now suddenly is being fed by an async signal!
 
Ok, I understand the consequences, but I assumed place and route would
ensure I shouldn't worry about this.
So, in the CPLD world, is this more important than the FPGA world?

I've seen loads of designs using ASYCH reset, surely if this was a problem,
they'd all be throwing up rubbish every now and again!

Ben

"Arash Salarian" <arash.salarian@epfl.ch> wrote in message
news:42ef4620$1@epflnews.epfl.ch...
"Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch
wrote in message news:dcnc8n$2c8$1@sunnews.cern.ch...
Hi Everyone!

I just read Xilinx Application Note 784...
http://www.xilinx.com/bvdocs/appnotes/xapp784.pdf

About bulletproofing CPLD Design. I consider myself to be pretty
experienced with Xilinx CPLDs, particularly 9500 devices, so I was quite
surprised to find the reccomendation 3. Using Strict Synchronous Design.

Ok, I know the principles of synchronous design, but I sometimes use
Asynchronous Resets in my designs, i.e. if RESET = '1' OR CLEAR = '1'
then blah blah

So, from you Xilinx Chaps, i'd be interested to know what you think, what
are the phenomena that mean I shouldn't use an Asynchronous Reset in CPLD
design, I never saw problems before, or is this XAPP being a little
strict?

Thanks!
Ben

Strictly speaking, async set or reset like any other async input to a
state machine can produce meta-stability and related conditions. This can
happen specially when NOT all of the registers in the design have a reset
and some are purely driven by the clock. Consider this: You issue an async
reset a few ps before the rising clock edge. Now somewhere in your design
you have a D flip flop that receives only an input and a clock signal. By
poor chance, that input is driven by another register that uses this async
signal for reset. The effect? You're violating the setup/hold time of our
innocent D flip flop that has now suddenly is being fed by an async
signal!
Click to expand...
 
Benjamin Todd wrote:
Ok, I understand the consequences, but I assumed place and route would
ensure I shouldn't worry about this.
So, in the CPLD world, is this more important than the FPGA world?

I've seen loads of designs using ASYCH reset, surely if this was a problem,
they'd all be throwing up rubbish every now and again!
Click to expand...
The trick is to drive the asynch reset pin
with a synchronized pulse only during
initialization. It is also a good idea
to depend as little as possible on
the initialization values in the design.

-- Mike Treseler
 
Hi,

I use the wording "synchronous design" also for designs with
asynchronous reset unless it is explicitly otherwise defined.

The discussion which reset to prefer is a bit driven by personal
preferences. There are good reasons for prefering synchronous reset
and good reasons for an asynchronous reset.

The safest position is a asynchronous set of the reset and an
synchronous release of the reset.

bye Thomas
 
ok, thanks for the comments..
I remember having this discussion in this newsgroup before: i should have
some synchroniser releasing the reset...
One question referring back to the CPLD domain: (particularly 9500
technology)

I see a much higher Function Block input use (~15% bigger) when I switch to
synchronous resets (i.e. the second example below.

Does that mean the fabric of the 9500 is not well suited to the use of
synchronous reset?

-- |Macrocells| Pterms |Registers| Pins |FB Input|
-- 5/288 8/1440 4/288 7/168 12/576

--counting : process (clock, reset, clear)
--begin
--if reset = '1' OR clear = '1' then
--icount <= iCount0;
--elsif rising_edge (clock) then
--icount <= icount + iCount1;
--end if;
--end process;

-- |Macrocells| Pterms |Registers| Pins |FB Input|
-- 4/288 7/1440 4/288 7/168 14/576

--counting_asynch : process (clock, reset)
--begin
-- if reset = '1' then
-- icount <= iCount0;
-- elsif rising_edge (clock) then
-- if clear = '1' then
-- iCount <= iCount0;
-- else
-- icount <= icount + iCount1;
-- end if;
-- end if;
--end process;


<usenet_10@stanka-web.de> wrote in message
news:1123051577.968796.164450@z14g2000cwz.googlegroups.com...
Hi,

I use the wording "synchronous design" also for designs with
asynchronous reset unless it is explicitly otherwise defined.

The discussion which reset to prefer is a bit driven by personal
preferences. There are good reasons for prefering synchronous reset
and good reasons for an asynchronous reset.

The safest position is a asynchronous set of the reset and an
synchronous release of the reset.

bye Thomas
Click to expand...
 
On Wed, 3 Aug 2005 13:02:30 +0200, "Benjamin Todd"
<benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> wrote:

I remember having this discussion in this newsgroup before: i should have
some synchroniser releasing the reset...
One question referring back to the CPLD domain: (particularly 9500
technology)

I see a much higher Function Block input use (~15% bigger) when I switch to
synchronous resets
Click to expand...
Indeed; because the reset signal now must be incorporated into the
logic fabric, whereas an asynchronous reset has a dedicated
distribution path that doesn't consume other logic resources.

Does that mean the fabric of the 9500 is not well suited to the use of
synchronous reset?
Click to expand...
No, I don't think so; it just means that there is a dedicated, and
therefore "free", asynch reset network.

Often, though, it's not as bad as that.

The big problem is: if an asynch reset is released too close
to a clock edge, some FFs may be clocked and others may not be
clocked. It is VERY likely that this doesn't matter, except
in a very small number of places in your design - usually the
controlling state machines. So you may be able to reach a
good compromise like this:

- Datapaths, configuration registers etc have simple asynch reset.
- Sequence-control state machines have asynch reset, but also have
synchronous reset signal that holds them in their idle state.
- Arrange one small dedicated piece of logic that is reset by
asynch reset, and holds the synch reset signal active for
two clocks after asynch reset has been released.

Now, your sequence controllers will remain in their idle state
for two clocks after the end of asynch reset. While they are
in the idle state, no other activity will run in the other parts
of the design. Consequently, it doesn't matter what happens
to the other flip-flops immediately after the end of asynch reset.
But the synchronous reset is applied only to a small part of the
design (the sequence control FSMs) so it consumes very little
extra logic.

The synch-reset generator is very easy:

process (clock, asynch_reset)
begin
if asynch_reset = '1' then
synch_reset_1 <= '1';
synch_reset <= '1';
elsif rising_edge(clock) then
synch_reset_1 <= '0';
synch_reset <= synch_reset_1;
end if;
end process;

HTH
--
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.
 
interesting!
I'll give it a go.

"Jonathan Bromley" <jonathan.bromley@doulos.com> wrote in message
news:gga1f1lk3ebpqtecj3flmiavu4305fuh5o@4ax.com...
On Wed, 3 Aug 2005 13:02:30 +0200, "Benjamin Todd"
benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> wrote:

I remember having this discussion in this newsgroup before: i should have
some synchroniser releasing the reset...
One question referring back to the CPLD domain: (particularly 9500
technology)

I see a much higher Function Block input use (~15% bigger) when I switch
to
synchronous resets

Indeed; because the reset signal now must be incorporated into the
logic fabric, whereas an asynchronous reset has a dedicated
distribution path that doesn't consume other logic resources.

Does that mean the fabric of the 9500 is not well suited to the use of
synchronous reset?

No, I don't think so; it just means that there is a dedicated, and
therefore "free", asynch reset network.

Often, though, it's not as bad as that.

The big problem is: if an asynch reset is released too close
to a clock edge, some FFs may be clocked and others may not be
clocked. It is VERY likely that this doesn't matter, except
in a very small number of places in your design - usually the
controlling state machines. So you may be able to reach a
good compromise like this:

- Datapaths, configuration registers etc have simple asynch reset.
- Sequence-control state machines have asynch reset, but also have
synchronous reset signal that holds them in their idle state.
- Arrange one small dedicated piece of logic that is reset by
asynch reset, and holds the synch reset signal active for
two clocks after asynch reset has been released.

Now, your sequence controllers will remain in their idle state
for two clocks after the end of asynch reset. While they are
in the idle state, no other activity will run in the other parts
of the design. Consequently, it doesn't matter what happens
to the other flip-flops immediately after the end of asynch reset.
But the synchronous reset is applied only to a small part of the
design (the sequence control FSMs) so it consumes very little
extra logic.

The synch-reset generator is very easy:

process (clock, asynch_reset)
begin
if asynch_reset = '1' then
synch_reset_1 <= '1';
synch_reset <= '1';
elsif rising_edge(clock) then
synch_reset_1 <= '0';
synch_reset <= synch_reset_1;
end if;
end process;

HTH
--
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.
Click to expand...
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top