Coding style for CPLD vs FPGA

[Analog Guy]

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.

 

[Mike Treseler]

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

 

[Tim Hubberstey]

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

 

[Klaus Falser]

In article <FkfYd.27073$fW4.859699@news20.bellglobal.com>,
analog_guy@hotmail.com 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