Answers Database Metamor to Foundation Express 1.5 (Synopsys) VHDL Conversion Guide Record #5144 Product Family: Documentation Product Line: Foundation Product Part: Foundation Expr App Notes help Problem Title: Metamor to Foundation Express 1.5 (Synopsys) VHDL Conversion Guide Problem Description: Urgency: Standard General Description: A guide to converting projects and code from Metamor VHDL syntax to Foundation Express (Synopsys) VHDL synatax can be found in the Foundation Online Help: In the Project Manager select Help -> Foundation Help Contents -> Applications Notes (in the center under the heading Techniques) -> Metamor-to-Express Conversion Guide. The full text also appears below in this solution record. Solution 1: Introduction This document describes the process and recommendations for migrating VHDL designs from the XVHDL (Metamor) VHDL compiler to the Express VHDL compiler. XVHDL was the embedded VHDL compiler in Foundation 1.4 and earlier. Starting with the Foundation 1.5 release, Synopsys? FPGA Express VHDL and Verilog compilers are embedded within Foundation. It is important to note that one of the major differences between XVHDL and Express is IEEE VHDL-93 compliance. XVHDL is a fully IEEE VHDL-93 compliant tool. Express supports many of the most commonly used VHDL-93 synthesis constructs, but is not yet fully compliant, and remains officially compliant with the IEEE VHDL-87 standard. The following list shows the additional VHDL-93 constructs that Express supports in F1.5. end entity entity_name; end architecture architecture_name; end component component_simple_name; end configuration configuration_name; end package package_name; end package body package_body_name; end record record_simple_name; component component_name is [label:] process [(sensitivity-list)] is label: component component_name label: concurrent_signal_assignment; 'IMAGE(X); block declarations in a generate statement       (VHDL LRM section 9.7) alias keyword (type must be declared) rising_edge(CLK) falling_edge(CLK) bus(5 downto 2) <= (others => '0');       (array slices with others) If you feel that you would rather continue using the XVHDL compiler with Foundation 1.5 instead of migrating to Express, you may continue with this flow without making any modifications to your project. If you do wish to migrate to the new Express flow, you must first convert your project to a new project type to enable this feature. This process is described in the Project Type Conversion topic. Solution 2: Converting Attributes Express uses a Constraint GUI to enter design constraints and other architecture-specific features. Many of the attributes which were used in your XVHDL code will be implemented using the Express GUI. Express does not support attribute passing through the VHDL code. Foundation Base Express packages (FND-BSX) do not include the Express Constraint GUI, and therefore if you have the Base Express package, you will use alternative methods described below to implement these attributes. The following table lists some of the most commonly used XVHDL attributes and their Express Constraints GUI and UCF file equivalents. In the section following this table, other commonly used XVHDL attributes which do not have direct Constraint GUI or UCF equivalents are discussed. If you have any other XVHDL-specific attributes or constructs in your VHDL code which are not covered in this document, please contact Xilinx Technical Support for further guidance if necessary. Attribute XVHDL Syntax Express Constraint GUI UCF Tab | Heading | Value ----------------------------------------------------------------------------- pinnum attribute pinnum of Ports | Pad Loc | P15 NET My_Sig LOC=P15; My_Sig: signal is "15"; fast attribute fast of Ports | Slew Rate | FAST NET My_Sig FAST; My_Sig: signal is true; slow attribute slow of Ports | Slew Rate | SLOW NET My_Sig SLOW; My_Sig: signal is true; xilinx_bufg attribute xilinx_bufg Ports | Global Buffer | BUFG For CPLD: of My_Sig: signal is true; NET My_sig BUFG=CLK; For FPGA: N/A loc/rloc attribute loc of My_Sig: N/A INST My_Sig LOC=R1C1; signal is "R1C1"; optimize attribute optimize of Modules | Optimize For | Area INST My_Module My_Module: entity is "area"; Optimize=Area; Converting Other Attributes Other attributes to be converted from XVHDL to Express include:       TNM       Inhibit_buf       Critical       Xilinx_GSR       Enum_encoding       Xilinx_BUFG       Converting CPLD-Specific Attributes Solution 3: Converting Libraries The XVHDL compiler uses slightly different VHDL libraries than the Express compiler. Because of this, you must modify your library declarations to be consistent with the Express compiler. Use the chart below to modify your code appropriately. XVHDL Express ----- ------- Library Package Library Package ------------------------------------------------------------------ IEEE STD_LOGIC_1164 IEEE STD_LOGIC_1164 SYNOPSYS STD_LOGIC_ARITH IEEE STD_LOGIC_ARITH SYNOPSYS STD_LOGIC_UNSIGNED IEEE STD_LOGIC_UNSIGNED METAMOR ATTRIBUTES No equivalent N/A METAMOR ARRAY_ARITH BVARITHMETIC BV_ARITHMETIC The only library package from XVHDL which does not have an equivalent in Express is the Metamor ATTRIBUTES package. The next section in this guide will describe how to convert any Metamor attributes which you may be using in the VHDL code. Solution 4: Converting Project Type When migrating a design from the Foundation F1.4 XVHDL flow to the Foundation F1.5 Express flow, you must first convert the Foundation project type. The project type in Foundation defines, among other things, which synthesis tool (XVHDL or Express) will be used to compile your VHDL files. With Foundation 1.3 and 1.4, the project type was named ?XACTStep M1.? With Foundation F1.5, the new project type is named ?Foundation Series v1.5.? For top-level schematic designs, the differences in the overall flow between F1.4 and F1.5 are minimal. For top-level HDL designs, however, the overall flow, especially for synthesis, is quite a bit different. The difference is due to the upgrade from the XVHDL to Express compiler. We will discuss the differences in the flow throughout this Application Note. Follow these steps to convert your project type: 1. Open up your existing Foundation project. The project will be opened, and will be maintained as an XACTStep M1 project type. 2. From the File menu in the Project Manager, select Project Type. Use the pulldown menu to set the project type to Foundation Series v1.5, and then select Change. This will change the project type to enable the use of the new Foundation 1.5 features, including the Express VHDL compiler. For a summary of the new design flow for HDL projects with Foundation F1.5, please refer to the ?HDL Design Flow? chapter of the Foundation Series User Guide. Solution 5: Converting TNM Attribute Express does not support the passing of TNM attributes through the HDL code. However, adding timespecs is much simpler with Express through the use of the Express Constraints GUI. To modify your XVHDL code: 1. Remove the TNM attributes from the HDL file. 2. Implement the timespecs which are currently in the UCF file from within the Express Constraints GUI. You may create timegroups within the Constraints GUI by creating Subgroups. If you have an Express Base package, and therefore do not have access to the Express Constraints GUI, you will create your timespecs with the Xilinx Constraints Editor, or by using a UCF file (described in the Development System Reference Guide). Solution 6: Converting Critical Attribute There is no equivalent attribute or function in Express to replace the XVHDL critical attribute. Express has the ability to preserve blocks but not nets, which the critical attribute addressed. To preserve hierarchical blocks, go to the Modules tab in the Express Constraints GUI and select Preserve under the Hierarchy and/or Primitives heading. Solution 7: Converting Enum_encoding Attribute The enum_encoding attribute is used in XVHDL to define the encoding scheme of a state machine in the design. The enum_encoding attribute was declared in the Attributes package of the Metamor library when using XVHDL. The enum_encoding attribute may also be used with Express, although slightly differently. With XVHDL, one of the declared types of enum_encoding is ?one hot?. With Express, you cannot define this type as ?one hot?, but instead you must explicitly define the states. For example: In XVHDL: type STATE_TYPE is (S1, S2, S3); attribute enum_encoding of STATE_TYPE: type is "one hot"; In Express: type STATE_TYPE is (S1, S2, S3); ttribute enum_encoding of STATE_TYPE: type is "001 010 100"; Alternatively, you may define the encoding scheme in the Synthesis Options dialog box. FSM extraction is done automatically using the encoding scheme you specify with the dialog box?s FSM Synthesis: Default encoding radio buttons. To access the Synthesis Options dialog box, select Synthesis => Options from the Project Manager. Solution 8: Converting Xilinx_GSR Attribute The Xilinx_GSR attribute was used with XVHDL as a way to remove an unwanted Reset net from a design in order to enable the use of the Global Reset network. Express handles this situation slightly differently, and your code will need to be modified slightly. For XC3000 designs and designs where the Reset signal does not go to each and every flip-flop: 1. Remove the Xilinx_GSR attribute from the HDL file 2. Add a line to the code to ground the Reset signal (that is, Reset <= 0;) By grounding the Reset net, you enable the tools to trim out the net, giving the same functionality as the Xilinx_GSR attribute. For XC4000/XC5200 designs: 1. If the Reset signal goes to every flip-flop in the HDL code, Express will automatically infer the Startup block, which will allow the use of the Global Set/Reset network. In this case, the Xilinx_GSR attribute should be removed from the HDL code and the code should be left as is. The Reset net will be automatically attached to the Startup block by the Express compiler. Solution 9: Optimization The methodology for performing optimization is different in XVHDL and in Express. XVHDL did not provide any combinatorial logic reduction optimization or mapping in the synthesis. The Optimize strategy of Area, Balance, Speed, or Off which was set in the HDL Editor Synthesis Options was actually a flag which was passed to the MAP program in the implementation phase of the design flow. The XVHDL compiler did not do anything differently in the synthesis based on the optimization strategy selected; it merely passed the option through to the netlist for use later in MAP. Express offers the same type of optimization strategy, but the optimization is actually performed by Express in the synthesis stage of the flow as opposed to later in the MAP phase of the flow. Optimization strategy for the overall design is selected in the Synthesis Settings section of the Synthesis/Implementation dialog box. Here you may choose to optimize for Area or Speed, and with a High or Low effort level. The choices you choose here will apply to the entire design. If you wish to set optimization strategy and effort level on a per-module basis, you may do this using the Express Constraints GUI, as indicated in the Attribute Conversion table. If you have an Express Base package, and therefore do not have access to the Express Constraints GUI, you may place the setting in the UCF file, also indicated in the Attribute Conversion table. Be aware, however, that when the option is passed through the UCF file, it is invoking the optimization program in MAP, not the optimization by Express for the individual modules. The results should be very comparable regardless of whether Express or MAP does the per-module optimization. In summary, if you have a Foundation Base Express package, and you wish to do optimization on a per-module basis (that is, you wish to optimize some modules for Area and some for Speed), then you must use the UCF file to pass this optimization setting to MAP in the implementation phase of the flow. Solution 10: Converting CPLD-Specific Attributes XVHDL allowed several CPLD-specific attributes to be defined and passed from the VHDL source design. These include INIT, KEEP, PWR_MODE and BUFG for global clocks, global output enable and global set/reset. The KEEP attribute is intended to force the fitter to preserve an internal logic net and prevent collapsing across the net. However, Express does not have the ability to preserve internal logic nets, so there is generally no practical way to apply the KEEP attribute to an internal net to pass on to the fitter. The remaining attributes can all be applied using the UCF file, using the form:     NET signal_name attribute_name = attribute_value; For example:     NET My_reg INIT=S;     NET My_OE BUFG=OE; Solution 11: Converting Xilinx_BUFG Attribute The Xilinx_BUFG attribute is an XVHDL attribute which instructs the XVHDL compiler to insert a BUFG at the specified input port. With Express, you may use the Constraints GUI to specify BUFGs on specific ports, as shown in the attribute conversion table. If you have an Express Base package, and therefore do not have access to the Express Constraints GUI, then you must instantiate the BUFG at the desired port for FPGA designs. Please note that Express will automatically infer a BUFG on a clock port, so this method of instantiation should only be necessary when you wish to place a BUFG on a non-clock port. Example of BUFG instantiation: --(component declaration) component BUFG     port (I: in std_logic; O: out std_logic); end component; --(component instantiation) U1: BUFG port map (I=>my_port, O=>sig_int); Note: For CPLD designs, Express will not infer any BUFG buffers. Instead, the CPLD fitter automatically allocates input ports used as clocks to the available global clock (GCK) pins. If you want to explicitly assign an input port to a global clock pin and you have an Express Base package, use the following property in a UCF file:     NET My_sig BUFG=CLK; Solution 12: Converting Inhibit_buf Attribute The inhibit_buf attribute is used in XVHDL to prevent the compiler from inserting an IBUF or OBUF at an input or output port. You want to do this in XVHDL when you instantiated an I/O flip-flop or a global buffer at the I/O port. In these cases, there is no need for the I/O buffer. Express, however, does not need this attribute to implement the design properly. When instantiating either a global buffer or an I/O flip-flop with Express, you do not need to use the inhibit_buf attribute. To modify your XVHDL code: 1. Remove the inhibit_buf attributes from the HDL file. 2. You may retain the global buffer and I/O flip-flop instantiations. End of Record #5144 - Last Modified: 05/21/99 15:35

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