Answers Database 1.5i, 2.1i 4K* Map - 'ERROR: baste:125 - The RLOC value of "R62C2.FFY" on CLB .... in RPM ....'. The design is too large for the given device and package (can't fit design). Record #2312 Product Family: Software Product Line: FPGA Implementation Product Part: map Product Version: 1.3. Problem Title: 1.5i, 2.1i 4K* Map - 'ERROR: baste:125 - The RLOC value of "R62C2.FFY" on CLB .... in RPM ....'. The design is too large for the given device and package (can't fit design). Problem Description: Urgency: Hot General Description: Map fails with the following error: <OUTPUT> The design is too large for the given device and package. Please check the Design Summary section for more information. If your design requires more CLBs and/or IOBs that the current target device, choose a new device accordingly. Alternatively, you may try to redesign your logic so that it does not require as many resources. </output> NOTE: Although the design will not fit the target device, an NCD file is still written out to allow the user to do preliminary timing and mapping analysis if desired. Solution 1: The other possibility is that your design contains logic with location constraints (either LOCs or RLOCs) that constrain its logic to some number of rows that exceeds the number of rows of CLBs available in your target device (for example, COREGEN or user modules with RLOCs or LOCs). In other words, the macro is too "tall" for the target device. Options: -------- 1. Target a "taller" part (one with more roews) 2. If the error is due to restrictions imposed by LOC constraints, remove these from the design and reprocess. (You may suffer a performance hit. In some cases this may make the design harder to route, as well. 3. If the error is due to restrictions imposed by RLOC (relative location) constraints, try specifying the -ir option when you run Map so that Map does not use the RLOCs to generate an RPM. Again, you will likely suffer a performance hit or make the design harder to route by doing this. 4. In some cases, there may be a way to implement the same functionality using two or more smaller cores of the same type and some additional logic. Example: multipliers can be split along their data widths and two or more smaller multipliers can process the data in parallel. Solution 2: If you must use the current target device, the following suggestions may help you fit the design. 1. Turn off register ordering by using the "-r" command-line option. Removing the need to physically map data-register flip-flops in order affords more mapping flexibility, which may allow more logic to fit into the design. 2. Set the environment variable LATE_BUS_PAIRS (e.g., <input> "setenv LATE_BUS_PAIRS" on SPARCstations). </input> This disables some of MAP's attempts to do flip-flop/TBUF alignment and defers the job to PAR. This may give MAP more flexibility. However, adding this burden to PAR may prevent PAR from running successfully. 3. Set the environment variable NOFMAPS (e.g., <input> "setenv NOFMAPS" </input> on SPARCstations). This tells MAP to disregard all user map information (FMAPs and HMAPs). NOFMAPS is not recommended if the design contains mapped carry logic. 4. Use the "-pr i|o|b" (e.g., "-pr b") option to merge flip-flops into IOBs (input, output, or both). This may decrease CLB usage. 5. Optimize the design for area with the "-os area" option.* 6. Optimize the design with high effort using the "-oe high" option.* 7. Use "-k" to map logic into five-input functions where applicable. *Suggestions 5 and 6 may cause some nets to be inaccessible in timing simulation. Bug reference #: 16845 r_stim/kl End of Record #2312 - Last Modified: 06/26/99 15:46

For the latest news, design tips, and patch information on the Xilinx design environment, check out the Technical Tips!