The Xilinx XC9000 library contains all component symbols used by the Xilinx XC9500 and XC9500XL device families. While most symbols of the library are common to all families, there are some symbols which are specific to CPLDs.
Physically, each major Xilinx device family (3000, 4000, 9000, etc.) has its own schematic library, implemented for each of the supported schematic entry tools. For each tool, there is a library directory for the XC9000 device family, which supports XC9500 and XC9500XL devices. When a library component is supported by multiple device families, its symbol appears in each of the corresponding library directories.
When a component of the same name appears in multiple family libraries, it has the same functionality and graphic symbol body, and similarly named pins. However, the component's implementation, including whether the symbol is a primitive or macro (with underlying schematic), may vary between families. Maintaining consistent functionality and "footprint" facilitates retargeting existing schematic designs between Xilinx device families. The Libraries Guide shows the applicability of each library symbol to each of the Xilinx device families.
When drawing a schematic representing a CPLD device, or any sub-sheet in a CPLD design, you should not use any symbols from any other library than the one for your target device family. For example, be careful not to use symbols that belong to a CAE tool's simulation modelling library.
To make your design device-independent, use only the symbols common to all Xilinx device families in which you are interested. The design implementation software automatically maps the symbols in your design onto the chosen target device. Creating a device-independent design allows you to easily test your design with different Xilinx devices.
For example, if you want to create a schematic which can be migrated to different Xilinx device families without modification, you should use the generic IBUF symbol instead of device-specific input buffers (like BUFGSR) and allow the fitter to automatically allocate global set/reset resources.
The following types of symbols can appear in your schematic:
The library contains the first two types of components: primitives and library macros. Primitives are those symbols recognized directly by the implementation software such as pads, gates, flip-flops and buffers. Library macros are symbols functionally defined by macro schematics contained in the library. Macro schematics contain primitives and sometimes other macros. Library macros have pre-defined functionality, but often their implementation is subject to the optimizations performed by the fitter software. Macros are always expanded into the netlist during schematic-to-netlist translation before the netlist is read by the fitter. EDIF netlists may either be in hierarchical or flattened form; this has no impact on the fitter's performance.
User macros are custom symbols generated by the user which are functionally defined by user-generated macro schematics. User macro symbols and schematics can be stored in your project directory or in a user library directory that you create. User macro schematics can consist of any mixture of the four types of symbols listed above.
You can create user macros to represent frequently used logic functions and instantiate them in one or more designs. It is often convenient to copy a Xilinx CPLD library macro symbol and schematic to your project directory as a template, then rename the symbol and schematic, and modify the symbol pins and schematic to suit your needs. You should not, however, modify any of the Xilinx CPLD library macros themselves or store new user macros in the Xilinx CPLD library directory.
You can add hierarchical structure to a large design by partitioning your logic into multiple schematic sheets. You then create user symbols to represent the schematic sub-sheets in the same manner as you would create user macro symbols. Your schematic partitioning has no effect on the implementation or optimization of your design by the fitter.
Behavioral modules are user-generated custom symbols functionally defined by some logic description other than a schematic. Typically, logic descriptions defining behavioral modules are expressed in Boolean equations or HDL, and processed by a PLD compiler (like XABEL) or a synthesis tool prior to running the fitter. Behavioral modules are discussed later in this chapter.
LogiBLOX modules are high-level, customizable library macros that are available for some schematic entry tools. LogiBLOX modules are described later in this chapter.
Unused inputs on symbols should not be left unconnected. You should never assume a default value for any unconnected symbol input except basic logic gates such as AND or OR, or asynchronous clear (CLR) or preset (PRE) inputs on flip-flops and other registered macros. Unconnected AND-gate, OR-gate, CLR and PRE inputs are simply discarded, as if the component had fewer inputs.
If a control input to a library macro is left unconnected, the resulting behavior may be different than what you would expect. In some cases, the resulting behavior may be different than if the input were tied either High or Low. If you leave a macro input unconnected, the fitter is usually able to detect it and issue a warning. Timing simulation after fitting will exhibit the actual resulting behavior.
Unused inputs should be tied to a constant High or Low logic level in the schematic. Use the VCC or GND symbol from the library to source a constant logic High or Low value.
