Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > VHDL > Bulletproofing CPLD Design

Reply
Thread Tools

Bulletproofing CPLD Design

 
 
Benjamin Todd
Guest
Posts: n/a
 
      08-02-2005
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


 
Reply With Quote
 
 
 
 
Arash Salarian
Guest
Posts: n/a
 
      08-02-2005
"Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPIT ALS.ch>
wrote in message news:dcnc8n$2c8$(E-Mail Removed)...
> 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!


 
Reply With Quote
 
 
 
 
Benjamin Todd
Guest
Posts: n/a
 
      08-02-2005
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" <(E-Mail Removed)> wrote in message
news:42ef4620$(E-Mail Removed)...
> "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPIT ALS.ch>
> wrote in message news:dcnc8n$2c8$(E-Mail Removed)...
>> 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!
>
>



 
Reply With Quote
 
Mike Treseler
Guest
Posts: n/a
 
      08-02-2005
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!


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
 
Reply With Quote
 
usenet_10@stanka-web.de
Guest
Posts: n/a
 
      08-03-2005
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

 
Reply With Quote
 
Benjamin Todd
Guest
Posts: n/a
 
      08-03-2005
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;


<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) oups.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
>



 
Reply With Quote
 
Jonathan Bromley
Guest
Posts: n/a
 
      08-03-2005
On Wed, 3 Aug 2005 13:02:30 +0200, "Benjamin Todd"
<benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPIT ALS.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:(E-Mail Removed)
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.
 
Reply With Quote
 
Benjamin Todd
Guest
Posts: n/a
 
      08-03-2005
interesting!
I'll give it a go.

"Jonathan Bromley" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> On Wed, 3 Aug 2005 13:02:30 +0200, "Benjamin Todd"
> <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPIT ALS.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:(E-Mail Removed)
> 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.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Asynchronous Tri-state Bus in VHDL (I/O): optimizing for CPLD design. D0tcom VHDL 0 01-28-2011 11:40 AM
FPGA/CPLD Design Group on LinkedIn cpld-fpga-asic VHDL 0 12-30-2008 02:26 PM
Link for Joining the FPGA/CPLD Design Group on LinkedIn cpld-fpga-asic VHDL 0 11-17-2008 11:32 AM
FPGA/CPLD Design Group on LinkedIn cpld-fpga-asic VHDL 1 08-23-2008 12:12 PM
Link for Joining the FPGA/CPLD Design Group on LinkedIn cpld.fpga.asic@gmail.com VHDL 0 06-11-2008 09:50 PM



Advertisments