Introduction. Design Hierarchy. FPGA Compiler II BLIS & the Quartus II LogicLock Design Flow

Transcription

1 FPGA Compiler II BLIS & the Quartus II LogicLock Design Flow February 2002, ver. 2.0 Application Note 171 Introduction To maximize the benefits of the LogicLock TM block-based design methodology in the Quartus II software, you can partition a new design into a hierarchy of electronic design interchange format (EDIF) files during synthesis. The benefit of using the LogicLock design methodology is better control over place-and-route results. The LogicLock design methodology supports Stratix TM, APEX TM II, APEX 20KC, APEX 20KE, and APEX 20K device families and ARM - based Excalibur TM embedded processor solutions. This application note describes how to automate the creation of multiple EDIF netlist files for a given hierarchy using the Synopsys FPGA Compiler II software s block-level incremental synthesis (BLIS) feature. 1 For more information on LogicLock regions and the LogicLock design flow, see AN 161: Using the LogicLock Methodology in the Quartus II Design Software. This application note assumes that you have installed and licensed the FPGA Compiler II software. To obtain the FPGA Compiler II software, go to the Synopsys web site at Design Hierarchy Different modules can be defined in different files, and instantiated in a top-level file. For larger designs, like those used for Stratix devices, many designers can work on different modules of a design at the same time. Figure 1 shows an example of a design hierarchy. Altera Corporation 1 AN

2 Figure 1. Design Hierarchy for Block-Based Designs Designer 1 A B C D E F Designer 2 Designer 3 In Figure 1, the top level of a design (A) can be assigned to one engineer (designer 1), while two engineers work on the lower levels of the design. Designer 2 works on B and its submodules (D and E) while designer 3 works on C and its submodules (F). Block-Level Incremental Synthesis The BLIS feature is provided with the Synopsys FPGA Compiler II software. This feature manages a design hierarchy for incremental synthesis. The BLIS feature allows different netlist files to be created for different sections of a design hierarchy. It also ensures that only those sections of a design that have been updated will be re-synthesized when the design is compiled, reducing synthesis run time. A designer can change and re-synthesize their section of a design without affecting other sections of a design. The BLIS feature utilizes design units called blocks to create this functionality. 1 For more information on blocks, see FPGA Compiler II Design Block on page 3. 2 Altera Corporation

3 FPGA Compiler II Design Block A block is a module or a group of modules used for incremental synthesis. Each block will have its own netlist file after synthesis. A block can be a Verilog HDL module, a VHDL entity, an EDIF netlist file, or a combination of the three. To combine these modules into a block, they should form a single tree in the design. Figure 2 shows a block design hierarchy. Figure 2. Blocks & Block Roots in a Design Hierarchy block 1 A block 2 B C block 3 D E F In Figure 2, sections B, D and E can be in a single block because they form a tree. Sections A, D and F cannot form a block because they are not on the same branch of the hierarchy. FPGA Compiler II & Quartus II Synthesis Using the BLIS feature in the FPGA Compiler II software, a designer can re-synthesize a netlist file for each block independently. Using the LogicLock design capability, each block s netlist file can be placed into a region on an Altera device. The region may be stationary or floating. A designer can maintain the performance and placement of a block if the region is not back annotated. If a region is fixed, the placement of that portion of the design will remain the same even if other parts of a design are added. 1 For more information on the LogicLock incremental design capability, see AN 161: Using the LogicLock Methodology in the Quartus II Design Software. Altera Corporation 3

4 Block Root A is the top module (or level) in a block s hierarchy. In Figure 2, A, B and F are s. When a is declared, every module, entity, or netlist file below the in the heirarchy becomes part of the same block. If a new is declared below an existing block root, then a new block is formed. For example, in Figure 2, A is a block root. A is above B, C, D, E and F in the design hierarchy, but only C is a part of A s block. B and F were declared s and have formed new blocks in the design hierarchy. Table 1 summarizes the structure of Figure 2. Table 1. Synthesis in Block-Level Methodology Block Block Root Member Elements Netlist Filename block 1 A A, C A.edf block 2 B B, D, E B.edf block 3 F F F.edf For each defined block in the FPGA Compiler II software, a separate optimized netlist file will be created. The name of the new netlist file for each block is the same as the module, entity, or netlist file that is declared as the block s root. For example, the of block 1 is A. Therefore, the netlist filename after block 1 is synthesized is A.edf. How the BLIS Feature Works with the LogicLock Feature When code for any module or entity defined in a block changes, then the entire block is resynthesized. Refer to Figure 2 for the following example: If C changes, block 1 (which includes both A and C) is re-synthesized. Block 2 and block 3 (including B, D, E and F) are not recompiled. Since each block in a design has its own netlist file, an updated netlist file is created only for block 1 resulting in a few A.edf file. 4 Altera Corporation

5 Each block in the FPGA Compiler II software creates an independent netlist file after synthesis, so you can control the placement of the netlist file in LogicLock regions. Each netlist file can be placed into a separate LogicLock region in the Quartus II software. If a design region changes, only the block associated with the changed region is affected. An updated netlist file will be created in the FPGA Compiler II software for the affected block only. During place and route in the Quartus II software, a LogicLock region associated with the changed netlist file will be re-run through place and route. You may need to remove previous backannotated assignments for the modified block because the node names may be different in the newly synthesized version. The placement and assignments for unchanged netlist files assigned to different LogicLock regions will not be affected. One designer can make changes to a piece of code that exists in an independent block and not interfere with another designer s changes. With the LogicLock design methodology, separate pieces of a design can evolve from development to testing without affecting other areas of a design. Hierarchy Considerations Designers must plan their design s structure in order to use the BLIS and LogicLock features effectively. When planning a design using the BLIS and LogicLock features, keep in mind the following: Scope of design elements Organization of design elements Number of elements created In order to ensure the proper functioning of the synthesis tool, design elements smaller than modules, entities, and netlist files cannot be declared as self-contained blocks. Each module or entity must have its own design file. If two different modules are in the same design file but are defined as being part of different blocks, both blocks are resynthesized when any module in the file is changed. Figure 3 illustrates this example. Altera Corporation 5

6 Figure 3. Shared Source File Causes Re-Synthesis of multiple Blocks block 1 A shared.vhd block 2 B C block 3 D E F In Figure 3 A, D, E and F are contained in their own source files, as recommended. However, B and C share a source file, called shared.vhd. If C is modified in shared.vhd, not only are A and C updated according to the block designations in Table 1, but B, D, and E are updated as well. To use the BLIS feature you must have the following: Design elements defined as blocks must be smaller than modules, entities, or netlist files Each entity, module, or netlist file must be in its own file At least two blocks must be a part of the design Time Stamp Synthesis The resynthesis of a particular block is controlled by the time stamps of its member source files. In Figure 3, when C is modified, the time stamp of shared.vhd is updated. The software sees that shared.vhd has been updated and does not know if it was module B or C that was changed. Therefore it will resynthesize blocks 1 and 2. In incremental design synthesis, only the portion of the design that was modified should be resynthesized. If you had previously verified B and later made changes to C, then B will be resynthesized, triggered by the updated time stamp of shared.vhd. This could change the results of any verification performed earlier on B. When a design is planned properly using the BLIS feature, each block has a separate netlist file after synthesis, and each netlist file is updated only when its associated code is changed. This is enforced through time stamps of independent source files. 6 Altera Corporation

7 Creating & Maintaining a Design To create and compile a project using the FPGA Compiler II software, perform the following steps: 1. Start the FPGA Compiler II software. 2. Select New Project (File menu). 3. Enter a project name and create a working directory. 4. Specify the source files in your design. 5. Select the top level design. 6. Select the target device (Create Implementation box) 7. Un-check Skip Constraint Entry and set the desired preferences. 8. Click OK. An elaborated implementation of your design appears in the Chips view. Opening the Modules Constraint Table & Labeling Block Roots To label a, perform the following steps: 1. Right-click on an elaborated implementation of your design (Chips window). 2. Select Edit Constraints. 3. Click the Modules tab. 4. Specify subdesigns as s in the Block Partition column 5. Click OK. 6. Right-click on an elaborated implementation and select Optimize Chip to resynthesize the design. Figure 4 illustrates how to label s. Altera Corporation 7

8 Figure 4. Labeling Block Roots in the Edit Constraints Window Exporting Block-Level Netlist Files Once your design has been segmented into blocks and re-implemented, you can export netlist files. To export netlist files, perform the following steps: 1. Check that there are no red question marks over elements in the Design Sources or Chips views. The question marks indicate that a change has been made since the last update. If there are red question marks, right-click on the icons to resynthesize the design. For more information, see Changing Source Within a Block on page Right-click on an optimized implementation and select Export Netlist Only (see Figure 5). 3. Click OK after selecting a directory for output. One netlist file for each block is created in the directory you specified. The EDIF netlist files have the same name as their corresponding s. 8 Altera Corporation

9 Figure 5. Export Netlist File Command Changing Source Within a Block If you make changes to the source of a block during your design cycle, you must update your design. When you make a change to the source of a block, a red question mark will appear in the Design Sources window. To make a change, perform the following steps: 1. Right-click on the question mark and select Update Chip. Question marks will appear over the Elaborated Implementation and the Optimized Implementation icons in the Chips window. 2. Right-click the red question mark to update Elaborated Implementation. 3. Right-click the red question mark to update Optimized Implementation. 1 You must update Elaborated Implementation first, followed by Optimized Implementation. When you update all of the parts of the design, new netlist files will be created for only those parts that have been changed. You can check the time stamps of the new files to confirm this. Altera Corporation 9

10 Removing a Block Root If a design evolves and portions of your design are no longer needed, s can be easily removed. To remove a perform the following steps: 1. Right-click on the Elaborated Implementation (Chips window). 2. Select Edit Constraints. 3. Click on the Modules tab and highlight the that you would like to remove in the Block Partition column. 4. Select Remove in the drop-down menu (see Figure 6). Figure 6. Removing a Block Root The top level of your design is always a and appears in the constraints editor. You cannot remove the block. Using BLIS Shell Commands You can designate s using a shell with the command set_module_block followed by the option true and the path to the module, entity, or netlist file. For example, to set the module F as a block root, perform the following step: fc2_shell> set_module_block true c:\alteradesigns\logiclock\f r You can also remove a block designation using the false option. fc2_shell> set_module_block false c:\alteradesigns\logiclock\f r 10 Altera Corporation

11 You cannot designate a for top-level entities since this is the default. You also cannot designate any primitive (such as AND) as a block root because primitives are too small in scope. Conclusion The LogicLock block-based design flow uses module-based design to help designers preserve performance of modules and have control over placement. By tagging which modules are to have separate EDIF files associated with them, multiple EDIFs can be made for use with the Quartus II software and the LogicLock block-based design feature from a single FPGA Compiler II software project. 101 Innovation Drive San Jose, CA (408) Applications Hotline: (800) 800-EPLD Literature Services: lit_req@altera.com Copyright 2002 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, the stylized Altera logo, specific device designations, and all other words and logos that are identified as trademarks and/or service marks are, unless noted otherwise, the trademarks and service marks of Altera Corporation in the U.S. and other countries. All other product or service names are the property of their respective holders. Altera products are protected under numerous U.S. and foreign patents and pending applications, maskwork rights, and copyrights. Altera warrants performance of its semiconductor products to current specifications in accordance with Altera's standard warranty, but reserves the right to make changes to any products and services at any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any information, product, or service described herein except as expressly agreed to in writing by Altera Corporation. Altera customers are advised to obtain the latest version of device specifications before relying on any published information and before placing orders for products or services. 11 Altera Corporation