
Lattice Semiconductor
Lattice Semiconductor Design Floorplanning
16-3
Figure 16-1. Floorplanning May be Able to Help Bring These Registers Closer
Figure 16-2. Floorplanning is Not Needed Here Because the Routing is Efficient
Floorplan to Improve Design Performance
Properly applied, design floorplanning not only preserves, but improves design performance. Floorplanning meth-
odologies can be used to place modules, entities, or any group of logic to regions in a device’s floorplan. Because
floorplanning assignments can be hierarchical, designers can have more control over the placement and perfor-
mance of modules and groups of modules.
In addition to hierarchical blocks, like grouping an entire VHDL entity or Verilog module, designers can floorplan
individual nodes (e.g., instantiate a library element for a function in the critical path and then group the library ele-
ment). This technique is useful if the critical path spans multiple design blocks.
Note: Although floorplanning can increase performance, it may also degrade performance if it is not applied cor-
rectly within software limitations.
Floorplan to Preserve Module Performance
Floorplanning with design constraints maintains design performance by grouping the placement of nodes in a
device, i.e., the relative placement of logic within a grouped region remains constant. The ispLEVER software then
places the grouped region into the top-level design with these constraints. When placing logic in a region, the isp-
LEVER software does not preserve the routing information. This approach provides more flexibility when the soft-
ware imports the region into the top-level design and helps fitting.
Floorplan for Design Reuse
Floorplanning facilitates design reuse by its ability to reproduce the performance of a module designed in a differ-
ent project. For frequently used modules, designers can create a library of verified designs that can be incorpo-
rated into other larger designs. The library only has to contain the VHDL or Verilog source code along with grouping
attributes and some comments detailing useful information to the user, such as performance and size. With a
parameterized module, in-code assignments can specify the module’s size and grouping assignments.
Targeting the same device used in the original design likely achieves the best results, although other devices in the
same family will likely work well. When using a different device in the same family, the exact placement of the
region may not be possible. Similar performance, however, may be possible by moving or floating regions. A float-
ing region groups the logic together and guides the ispLEVER software toward achieving a placement that meets
the performance requirements of the module. A similar approach can also be taken if exact placement of a module
is not applicable because of multiple instantiations of a module in a top-level design.
Logical Details:
Cell type
Pin type
Cell name
(clock net +/-)
Source:
FF
Q
ibuf/reg_init_start (from clk_ib+)
Destination:
FF
Data in
ibuf/sd/reg_new_state (to clk_ib +)
Delay:
8.062ns
(18.2% logic, 81.8% route), 2 logic levels.
Logical Details:
Cell type
Pin type
Cell name
(clock net +/-)
Source:
FF
Q
mem_if_tx_address_8 (from clk_c +)
Destination:
FF
Data in
mem_if_tx_address_17 (to clk_c +)
Delay:
7.358ns
(61.2% logic, 38.8% route), 4 logic levels.