Previous

Special I/O Ports

Ordinarily, you need only to declare ports in your top-level entity to represent all the I/O pins on the CPLD device. The Synopsys set_port_is_pad and insert_pads commands automatically infer IBUF, OBUF, OBUFE and IOBUFE cells from XC9000 library to represent the I/O ports in the netlist.

The following sections describe special global control pins on CPLD devices that can be used for register clocking, tristate control and register set/reset, instead of ordinary IBUF inputs. Unless otherwise specified, the fitter automatically allocates these special global pins, if possible, when input ports in your design are used to perform these control functions.

Clock Inputs

To use a device input as a clock source, you can simply refer to a top-level input port as the clock condition in a process. For example:

entity xyz is
port (CLOCK:in std_logic; ...
...
process (CLOCK)
begin
if (CLOCK'event and CLOCK='1') then
...

The fitter automatically uses one of the global clock pins (GCK for XC9000) whenever possible.

For XC9000 devices, a global clock input signal may perform negative-edge clocking. For example:

process (CLOCK)
begin
if (CLOCK'event and CLOCK='0') then
...

The same clock input may even be used both as both positive-edged and negative-edged to clock different processes on opposite edges of the clock signal. Global clock inputs may also be used as ordinary input signals to other logic elsewhere in the design.

If an input port signal passes through any logic function (other than an inverter) before it is used as a clock by any flip-flop, the input will not be routed to any flip-flops in the design using the global clock path. Instead, that clock signal will be routed through the logic array.

There are a limited number of global clock pins on each CPLD device (consult the device data sheet). If you need to explicitly control the use of global clock pins, you can specify the set_pad_type command in your dc_shell script with the parameter “-exact BUFG,” and reference an input port of your design. For example:

set_pad_type -exact BUFG clock1


NOTE

The cell name BUFG must be upper case. The set_pad_type command must be executed before the insert_pads command.


The global clock pins provide much shorter clock-to-output delays than clocks routed through the logic array. Routing a clock through the logic array also uses up one extra p-term for each flip-flop.

If you want to prevent the fitter from automatically using the global clock pins, go to the Implementation Options template of the Design Manager and remove the check mark from Use Global Clock(s) as follows:

  1. Design Implement

  2. Press the Options softkey.

  3. Select Edit Template

  4. Select the Basic tab.

  5. Remove the check mark from Use Global Clock(s).

Using command line you can also prevent the fitter from automatically using the global clock pins. To do this, specify the "-nogck" parameter on the cpld command line as follows:

cpld -nogck design_name

If -nogck is specified, input ports used as clocks will pass through the array. You can still use the set_pad_type command to explicitly specify global clock inputs.

If you use an internal signal as a clock, it will be routed to the flip-flops through the logic array.

Output Enable Signals

To use a device input to control tristate device outputs, you can simply refer to a top-level input port signal as a tristate condition in your design. For example:

entity xyz is
port (ENABLE:in std_logic; ...
...
Q <= Q_VALUE when (ENABLE='1') else `Z';

The fitter automatically uses one of the global tristate control pins (GTS for XC9000) whenever possible.

For XC9000 devices, a global tristate control input signal may perform an active-low output-enable. For example:

Q <= Q_VALUE when (ENABLE='0') else `Z';

The same tristate control input may even be used both active-high and active-low to enable alternate groups of device outputs. Global tristate control inputs may also be used as ordinary input signals to other logic elsewhere in the design.

If an input port signal passes through any logic function (other than an inverter) before it is used as an output enable by any output port, the input will not be routed to device output drivers in the design using the global tristate control path. Instead, the output enable signal will be routed through the logic array.

There are a limited number of global tristate control pins on each CPLD device (consult the device data sheet). If you need to explicitly control the use of global tristate control pins, you can specify the set_pad_type command in your dc_shell script with the parameter “-exact BUFGTS”, and reference an input port of your design. For example:

set_pad_type -exact BUFGTS enable1


NOTE

The cell name BUFGTS must be upper case. The set_pad_type command must be executed before the insert_pads command.


The global tristate control pins provide much shorter input-to-output-enable delays than tristate controls routed through the logic array. Routing a tristate control signal through the logic array also uses up one extra p-term for each output.

If you want to prevent the fitter from automatically using the global tristate control pins, go to Implementation Options template of the Design Manager and remove the check mark from Use Global Output Enable.

  1. Design Implement

  2. Press the Options softkey.

  3. Select Edit Template

  4. Select the Basic tab.

  5. Remove the check mark from Use Global Output Enable(s).

Using the command line, if you want to prevent the fitter from automatically using the global tristate control pins, specify the -nogts parameter on the cpld command line as follows:

cpld -nogts design_name

If -nogts is specified, input ports used for tristate control will pass through the array. You can still use the set_pad_type command to explicitly specify global tristate control inputs.

If you use an internal signal as an output enable, it will be routed to the outputs through the logic array.

Asynchronous Clear and Preset

To use a device input as an asynchronous clear or preset source, you can simply refer to a top-level input port as the set or reset condition in a clocked process. For example:

entity xyz is
port (CLOCK, RESET : in std_logic; ...
...
process (CLOCK, RESET)
begin
if (RESET='1') then Q <= `0';
elsif (CLOCK'event and CLOCK='1') then

...

For XC9000 designs, the fitter automatically uses the global set/reset pin (GSR) whenever possible. A global set/reset input signal may also perform active-low clear or preset. For example:

process (CLOCK, PRESET)
begin
if (PRESET='0') then Q <= `1';
elsif (CLOCK'event and CLOCK='1') then
...

A global set/reset inputs may also be used as an ordinary input signal to other logic elsewhere in the design.

If an input port signal passes through any logic function (other than an inverter) before it is used as an asynchronous clear or preset on any flip-flop, the input will not be routed to any flip-flops in the design using the global set/reset path. Instead, the clear/preset signal will be routed through the logic array. Routing a clear or preset through the logic array uses up one extra p-term for each flip-flop.

There is only one global set/reset pin on each XC9000 device. If you need to explicitly control the use of the global set/reset pin, you can specify the set_pad_type command in your dc_shell script with the parameter “-exact BUFGSR” and reference an input port of your design. For example:

set_pad_type -exact BUFGSR reset1


NOTE

The cell name BUFGSR must be upper case. The set_pad_type command must be executed before the insert_pads command.


If you use an internal signal as a set or reset, it will always be routed through the logic array.


NOTE

If a flip-flop has both a clear and preset condition and you assert both the clear and preset concurrently, its Q-output is unpredictable. This is because the fitter may arbitrarily invert the logic stored in a flip-flop to achieve better logic optimization. Individual clear and preset operations still produce the correct final logic state as dictated by the user design. Functional simulation does not accurately predict the ultimate behavior of the chip when clear and preset are asserted concurrently. Timing simulation, however, is performed after logic optimization and behaves exactly as the chip will when programmed.


Clock Enable

If you express a synchronous clock-enable condition in a clocked process, and FDCE_X or FDPE_X primitive will be inferred from the XC9000 library. For example:

process (CLOCK)

begin

if (CLOCK'event and CLOCK='1') then

if (CLOCK_EN='1') then Q<=D;

These FDCE_X or FDPE_X primitives are always expanded into an ordinary D-type flip-flop with its Q-feedback multiplexed into its D-input.

FDCE_X is an edge-triggered D-type flip-flop with asynchronous clear and clock enable. The synthesizer uses this component for all functions that require D-type registers with clock-enable, provided no asysnchronous preset condition is specified. FDCE_X is not intended to be instantiated into any design.

FDCE is also an edge-triggered D-type flip-flop primitive with clear and clock enable. But, FDCE is never inferred. Users must explicitly instantiate it or explicitly replace an FDCE_X cell that is inferred in the design. For XC9500XL devices, the FDCE unconditionally uses the clock-enable product-term of the macrocell to implement the CE input. For XC9500 devices, FDCE is always expanded into a simple D-type flip-flop with its Q-feedback multiplexed into its D-input, just like the FDCE_X cell.

FDPE_X is an edge-triggered D-type flip-flop with asynchronous preset and clock enable. The synthesizer uses this component for all functions that require D-type registers with preset and clock-enable. FDPE_X is not intended to be instantiated into any design.

FDPE is also an edge-triggered D-type flip-flop primitive with preset and clock enable. But, FDPE is never inferred. Users must explicitly instantiate it or explicitly replace an FDPE_X cell that is inferred into the design. For XC9500XL devices, the FDPE unconditionally uses the clock-enable product-term of the macrocell to implement the CE input. For XC9500 devices, FDPE is always expanded into a simple D-type flip-flop with its Q-feedback multiplexed into its D-input, just like the FDPE_X cell..

If you use FDCE or FDPE cells and target an XC9500XL device, you may find that the logic connected to the clock enable input in some designs may not get optimized into the same macrocell as the flip-flop. The XC9500XL macrocell contains only a single product-term to implement clock enable input logic. The CPLD fitter does not attempt transform your clock enable input logic onto the D-input of the flip-flop if it cannot be completely implemented using the clock enable p-term. In general, only primary inputs (device input pins or macrocell feedbacks), their complements or positive-logic AND-gate functions of primary inputs or their complements can be completely implemented using the p-term. If you connect a more complex logic function to the clock enable input of an FDCE or FDPE cell and it does not get completely implemented on the clock enable p-term, your design may incur extra macrocell resources and combinational macrocell feedback delays.

Next