Bulletproofing CPLD Design

Discussion in 'VHDL' started by Benjamin Todd, Aug 2, 2005.

  1. 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, Aug 2, 2005
    #1
    1. Advertising

  2. "Benjamin Todd" <>
    wrote in message news:dcnc8n$2c8$...
    > 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!
     
    Arash Salarian, Aug 2, 2005
    #2
    1. Advertising

  3. 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" <> wrote in message
    news:42ef4620$...
    > "Benjamin Todd" <>
    > wrote in message news:dcnc8n$2c8$...
    >> 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!
    >
    >
     
    Benjamin Todd, Aug 2, 2005
    #3
  4. 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
     
    Mike Treseler, Aug 2, 2005
    #4
  5. Benjamin Todd

    Guest

    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
     
    , Aug 3, 2005
    #5
  6. 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;


    <> wrote in message
    news:...
    > 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
    >
     
    Benjamin Todd, Aug 3, 2005
    #6
  7. On Wed, 3 Aug 2005 13:02:30 +0200, "Benjamin Todd"
    <> 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:
    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.
     
    Jonathan Bromley, Aug 3, 2005
    #7
  8. interesting!
    I'll give it a go.

    "Jonathan Bromley" <> wrote in message
    news:...
    > On Wed, 3 Aug 2005 13:02:30 +0200, "Benjamin Todd"
    > <> 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:
    > 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.
     
    Benjamin Todd, Aug 3, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. guille
    Replies:
    0
    Views:
    590
    guille
    Dec 19, 2003
  2. cpld-fpga-asic

    FPGA/CPLD Design Group on LinkedIn

    cpld-fpga-asic, Aug 23, 2008, in forum: VHDL
    Replies:
    1
    Views:
    494
    jacko
    Aug 23, 2008
  3. cpld-fpga-asic
    Replies:
    0
    Views:
    533
    cpld-fpga-asic
    Nov 17, 2008
  4. cpld-fpga-asic

    FPGA/CPLD Design Group on LinkedIn

    cpld-fpga-asic, Dec 30, 2008, in forum: VHDL
    Replies:
    0
    Views:
    438
    cpld-fpga-asic
    Dec 30, 2008
  5. D0tcom
    Replies:
    0
    Views:
    1,470
    D0tcom
    Jan 28, 2011
Loading...

Share This Page