Coding style for CPLD vs FPGA

Discussion in 'VHDL' started by Analog Guy, Mar 11, 2005.

  1. Analog Guy

    Analog Guy Guest

    Hi,

    Are there any specific coding styles when coding for a CPLD implementation
    (i.e. to make better use of the AND-OR array structure) as opposed to an
    FPGA implementation. For instance, each macrocell can support only so
    many product terms ... so how do you deal with very large decodes. It
    appears
    that large decodes borrow product terms from adjacent macrocells via the
    internal feedback path, thus causing a timing penalty when it comes to
    fitting the CPLD.

    Are there any constructs one should use or avoid to make more optimized CPLD
    designs.


    Thanks for your help.
     
    Analog Guy, Mar 11, 2005
    #1
    1. Advertising

  2. Analog Guy wrote:

    > Are there any specific coding styles when coding for a CPLD implementation
    > (i.e. to make better use of the AND-OR array structure) as opposed to an
    > FPGA implementation. For instance, each macrocell can support only so
    > many product terms ... so how do you deal with very large decodes. It
    > appears
    > that large decodes borrow product terms from adjacent macrocells via the
    > internal feedback path, thus causing a timing penalty when it comes to
    > fitting the CPLD.


    To make a "fuse" map by hand, such things are very important.
    If you have a synthesis tool that targets the device,
    just write a clean hdl description, verify it by simulation,
    and let synthesis have a go at it. If it fits, and meets
    static timing, you are done. If it doesn't fit, you may
    need a larger device. If it doesn't meet timing, you can
    add constraints or pipeline.

    -- Mike Treseler
     
    Mike Treseler, Mar 11, 2005
    #2
    1. Advertising

  3. Analog Guy wrote:
    > Hi,
    >
    > Are there any specific coding styles when coding for a CPLD implementation
    > (i.e. to make better use of the AND-OR array structure) as opposed to an
    > FPGA implementation. For instance, each macrocell can support only so
    > many product terms ... so how do you deal with very large decodes. It
    > appears
    > that large decodes borrow product terms from adjacent macrocells via the
    > internal feedback path, thus causing a timing penalty when it comes to
    > fitting the CPLD.
    >
    > Are there any constructs one should use or avoid to make more optimized CPLD
    > designs.


    *Always* read the data sheet for your target part carefully.

    FPGA vendors push one-hot encoding for state machines because they are
    "register rich". CPLDs, OTOH, are register poor and, to some extent,
    optimized for counters, so I usually use binary encoding.

    Choose your internal signal states carefully. Those selectable
    inversions you took for granted in an FPGA may not exist in a CPLD. This
    particularly applies to resets, presets, and clock enables driven by logic.
    --
    Tim Hubberstey, P.Eng. . . . . . Hardware/Software Consulting Engineer
    Marmot Engineering . . . . . . . VHDL, ASICs, FPGAs, embedded systems
    Vancouver, BC, Canada . . . . . . . . . . . http://www.marmot-eng.com
     
    Tim Hubberstey, Mar 11, 2005
    #3
  4. Analog Guy

    Klaus Falser Guest

    In article <FkfYd.27073$>,
    says...
    > Hi,
    >
    > Are there any specific coding styles when coding for a CPLD implementation
    > (i.e. to make better use of the AND-OR array structure) as opposed to an
    > FPGA implementation. For instance, each macrocell can support only so
    > many product terms ... so how do you deal with very large decodes. It
    > appears
    > that large decodes borrow product terms from adjacent macrocells via the
    > internal feedback path, thus causing a timing penalty when it comes to
    > fitting the CPLD.
    >
    > Are there any constructs one should use or avoid to make more optimized CPLD
    > designs.
    >
    >
    > Thanks for your help.
    >
    >
    >

    There is no specific coding style since the compiler handles the
    mapping for you.
    There are however some details one should pay attention still in
    the design phase, one of them already discoverd by you.

    If you build a multiplexer which "overloads" the product term "or"-ing,
    then your multiplexer will become very slow. This is hardware dependend,
    you can not change anything by a different vhdl or verilog description.
    You can try (if possible) a different family. I would suppose Xilinx
    XC9500 behaves better then Coolrunner since they allow more product
    terms per macrocell.

    Another thing you probabely won't to use are large counters.
    It is much better to split up a 32-bit counter into a pipeline of 2
    16-bit counters, but in this case your counter will need 2 clock cycles
    and you have to adapt your design to tolerate this.

    Comparators are the same story. I have to use 2 16-bit comparators in my
    design and I would say it is nearly at the limit. They are using a LOT
    of product terms and intermediate signals, filling up your chip very
    fast.

    Hope this helps
    Klaus
     
    Klaus Falser, Mar 14, 2005
    #4
    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. Donato Pace
    Replies:
    3
    Views:
    634
    Andy Peters
    Jan 27, 2006
  2. Replies:
    6
    Views:
    7,248
  3. BC
    Replies:
    11
    Views:
    1,019
  4. axr0284

    Coding for CPLD vs FPGA

    axr0284, Feb 5, 2008, in forum: VHDL
    Replies:
    4
    Views:
    752
  5. Replies:
    2
    Views:
    633
Loading...

Share This Page