At this point in the tutorial, you have created or edited the following four schematic files: calc, alu1, andblk2, and orblk2. You can use the design, at this point, for only an XC4000E or XC4000EX device because these devices have several advanced features not found in other Xilinx device families. Two of these advanced features include the on-chip memory built into the XC4000E CLB and wide-edge decoders.
The incomplete calc_sch design is configured for an XC4003E-PC84 part. If you want to target a demonstration board with this device, go to the “RAM Stack Implementation” section. If targeting the tutorial design for an XC95108-PC84 (no demonstration board available) or other device family, you must convert the design to reference the XC9500 library instead of the XC4000E library.
The procedure provided below allows you to change every Xilinx component in the Calc design from the XC4000E library to the XC9500 library. Because design creation used the Unified Libraries, the parts in the XC4000E and XC9500 libraries have identical footprints and pinouts. You can easily retarget designs to a different device family. However, you must use only library parts common to the two families. You must manually replace any library parts not common to both families. The following example shows such a situation.
Although an XC4000E-to-XC9500 conversion appears here, you can use this procedure to retarget from any family to any other family.
To retarget the Calc design to the XC9500 family, use the following procedure.
file_type = master_library;
"xce9000" '/xilinx/cadence/data/xce9000/xce9000.lib';
"xcepads" '/xilinx/cadence/data/xcepads/xcepads.lib';
end. The default property PINTYPE (with value IN) is no longer on the body OBUF.When you write the schematic again, these warnings disappear.
To target the XC3000A, XC3100A, or XC5200 family, follow the previous procedure for the XC9500 family to retarget the design. Simply substitute “xce3000” or “xce5200” where you see “xce9000” in the procedure.
The RAM stack implements using a 16x4 RAM macro from the XC4000E library. Although the stack is 4x4, RAM and ROM are only available in 16x1 or 32x1 increments, using only one fourth of the
memory addresses. A stack four times as deep can implement using only two CLBs. An equivalent flip-flop implementation requires 64 flip-flops or 32 CLBs. In this case, with a stack only four words deep, using the static memory feature of the XC4000E CLB reduces the stack from eight CLBs to two CLBs.
To view the XC4000E stack implementation, follow these steps.
If targeting a Spartan or non-XC4000 family, the RAM16X4S does not display in the schematic because it does not exist in the target library. See the “Using the Device-Independent Register File” section for instructions on replacing this missing part.
The schematic for RAM16X4S appears in the following figure.
Figure 9.32 RAM16X4S, XC4000E Implementation |  |
The device-independent stack implements by replacing the RAM16X4S with a register file that emulates a synchronous RAM with a set of flip-flops and multiplexers. You can use this implementation for any Xilinx device, even one from the XC4000E family.
If targeting an XC4000E device, you can skip this section to take advantage of the RAM feature of the XC4000E.
Make the stack a device-independent schematic as the following procedure describes.
If you changed the libraries to non-4000 or non-Spartan libraries, the RAM16X4S does not appear in the schematic. In this case, click on the empty space between the dangling DATA<3..0> and STACKOUT<3..0> wires to place the RAM4_9K component.
Figure 9.33 Replacing RAM with REG_9K | |
If targeting the Calc design to an XC9500 or other device outside the XC4000 or Spartan family, you must also remove the CLOCKGEN circuitry. This circuitry includes the OSC4 component, and you must replace it with an external source.
The XC3000 and XC5200 families also have internal, on-chip oscillators. See the CLKGEN3K and CLKGEN5K components to see how to use these. You can replace the CLOCKGEN component with one of these alternative macros with the replace command, instead of using the instructions that follow.
Because a signal now sources the CLK signal, it must generate externally.
Figure 9.34 Device-Independent Clock Source | |
