Getting Started with Xilinx M1

Contents:

1. Setting Up Your Environment
2. Learning about the Xilinx M1 Tools
3. Important Xilinx M1 Tools
4. Advanced Xilinx M1 Techniques
   • Merging Viewlogic and Synopsys Designs
   • Building and Using RPMs with Synopsys VHDL
   • Using balance_registers with Synopsys VHDL and Xilinx XC4000 parts

Setting Up Your Environment

Viewlogic Setup

setenv WDIR ~/viewlog:/tools/viewlogic/standard
setenv QUADHOME /tools/viewlogic/quad
setenv QUADBIN /tools/viewlogic/quad/exec
setenv XLM /cad/xilinx
if( $?LM_LICENSE_FILE ) then
	setenv LM_LICENSE_FILE ${LM_LICENSE_FILE}:/tools/viewlogic/standard/license.dat
else
	setenv LM_LICENSE_FILE /tools/viewlogic/standard/license.dat
endif
set path = (/tools/viewlogic /tools/viewlogic/quad/exec $path)
setenv VIPC_KILL_PRE_60_VNSD TRUE

set path=(/fpga3/cad/viewlogic /cad/xact/powerview/bin/hppa $path)
setenv WDIR {$HOME}/viewlog:/fpga3/cad/viewlogic/standard:/fpga3/cad/viewlogic/standard/53'

1. powerview.ini
2. workview.ini
3. viewdraw.ini (Created for use with Xilinx 4000EX/XL FPGAs. Must be modified for other parts.)

Synopsys Setup

If you are new to Synopsys and/or Xilinx M1, follow these steps to setup a project for synthesis:

1. Create your project directory, e.g., myproject. Your project directory should be the place where your VHDL designs reside.
2. Copy the template.synopsys_vss.setup into your project directory, renaming it .synopsys_vss.setup. This file defines the environment for simulating VHDL designs.
3. Create a subdirectory named WORK in your project directory. This is the place where the Synopsys temporary files for synthesis and simulation are put.
4. Copy the template.synopsys_dc.setup_fc into your project directory, renaming it .synopsys_dc.setup (assuming you will be using the FPGA Compiler for synthesis). This file defines the environment for synthesizing VHDL designs.
5. Use the synlibs command to add the appropriate libraries to your .synopsys_dc.setup file. To use synlibs you must first source the /cad/xilinx/setup file mentioned earlier. The template.synopsys_dc.setup file found in /cad/xilinx/synopsys/examples does not include the libraries required for synthesis, so these libraries should be appended to the end of the template.synopsys_dc.setup to make a complete .synopsys_dc.setup file. The following example uses synlibs to add the synthesis libraries to the .synopsys_dc.setup file for use with the FPGA Compiler and a Xilinx XC4036EX-3 FPGA:

   synlibs -fc 4036ex-3 >> .synopsys_dc.setup

   The following is an example for adding the synthesis libraries for the same Xilinx FPGA, except the libraries are intended for the Design Compiler instead:

   synlibs -dc 4036ex-3 >> .synopsys_dc.setup

   If you need additional help with synlibs, refer to the Xilinx M1 on-line documentation, or type synlibs -help. You should only add one set of libraries to a .synopsys_dc.setup file.

Learning about the Xilinx M1 Tools

Important Xilinx M1 Tools

xgen

This is a script generation tool which has been newly added to the M1 tool suite. The xgen script will prompt you for the relevant information required for processing your design. The script created by xgen can then be used to process your design without having to write your own script or having to use the Design Manager.

Design Manager

This is the "shell" that can be used to manage the translation of designs from netlists (EDIF,XNF,etc.) to bitstreams. It can be started by executing the dsgnmgr command.

Flow Engine

This is the program which processes the design project from netlist to bitstream. It will be started by the Design Manager. It can be executed using the floweng command.

Ngdbuild

This does much of the translation from the input netlist format to the internal netlist format used by the new tools. See the Development System Reference Guide for a more detailed explanation. It can be executed using the command ngdbuild.

Map

This command performs some logic optimization and design mapping to the given technology. See the Development System Reference Guide for a more detailed explanation. It can be executed using the command map.

Par

This command performs the actual placing and routing of the design onto a specified FPGA. See the Development System Reference Guide for a more detailed explanation. It can be executed using the command par.

Trace

This program performs the timing analysis for designs. It can be used to estimate design performance before and after placing and routing the design. See the Development System Reference Guide for a more detailed explanation. It can be executed using the command trce(this is correctly spelled).

Advanced Xilinx M1 Techniques

Merging Viewlogic and Synopsys Designs

component mymult
    port(
          A: in std_logic_vector(15 downto 0);
          B: in std_logic_vector(15 downto 0);
          Prod: out std_logic_vector(31 downto 0)
         );
end component;

mymult0: mymult port map(A=>a_in,B=>b_in,Prod=>prod_out);

	bus_naming_style = "%s%d"
	bus_dimension_separator_style = ""
        bus_inference_style = "%s%d"

Here is a summary of the steps for the integration process:

1. In the VHDL, create a dummy component with the exact same name as your Viewlogic design, naming the ports exactly as found in the Viewlogic design.
2. Next, instance the component using "named" (as opposed to the "positional") association method. (Actually, positional would probably work since the component declaration defines the meaning of the positions in the port map).
3. Generate your .sxnf (or .sedif) as usual. You will get the usual "unresolved references" warnings.
4. Generate the .edn (the EDIF) of your Viewlogic design.
5. To create a bitstream of your design, make sure that both the .sxnf (or .sedif) and .edn files are in the same directory so that ngdbuild can resolve the references to the Viewlogic design(s). Then, you can either use dsgnmgr or a script file, as usual, to process the top-level design.

Building and Using RPMs with Synopsys VHDL

First of all, to allow RLOCs to be used in a design, the following Synopsys variables must be set as shown:

edifout_netlist_only = true
edifout_power_and_ground_representation = cell
edifout_write_properties_list = "instance_number pad_location part RLOC"
edifout_no_array = true

Building Your Own RPM with Synopsys

• For each element you use from the library, create a corresponding component declaration having the same name as the component from the Xilinx library, naming the ports identically. (Basically, the same "black box" strategy mentioned in Merging Viewlogic and Synopsys Designs above.)
• Or, you can use the predefined components found in $XILINX/synopsys/libraries/sim/src/xc4000e/ftgs.

The only "gotcha" to creating RPMs with Synopsys VHDL and the Xilinx synthesis libraries is that RLOC attributes cannot be placed on the FMAP_PLC/PLU/PUC/PLO/PUO primitives in the library. (These are only mentioned in the old documentation though they do exist in the current synthesis libraries. The map program complains if you put RLOC attributes on these primitives. About all they can be used for is packing logic into LUTs, but no relative placement can be done, from what I can tell.) To get around this "gotcha", create your own FMAP component, having the same inputs and outputs as the FMAP component described in the Libraries Guide. Specifically, the following can be used for instancing "normal" FMAPs:

  component fmap
    port(i4,i3,i2,i1:in std_logic;
	 o:out std_logic
	 );
  end component;

  component gnd
    port(ground: out std_logic);
  end component;

Setting the RLOC Attributes for RPMs under Synopsys

set_attribute myinstance RLOC -type string "R1C2.F"

Realize that the RLOC attributes can only be applied directly to FMAPs at the top-level of a design's hierarchy. For instance, if you have an RPM written in VHDL called mymult which is instanced in a design named top, you can only set the RLOC attributes for the FMAPs in the design mymult. If you try to set the attributes directly in the top design by traversing the design hierarchy, those attributes will not be written to the resulting EDIF file. In other words, you can only set the RLOC attributes on instances at the top-level of a design---you cannot set the attributes on instances within other instances in a design.

Similarly, if you want to set RLOC attributes on RPMs, the attributes must be set at the design level which immediately instances the RPMs, otherwise, the attributes will not be written out properly. For example, assume you have the RPM named mymult which is instanced by a design named almost_top and almost_top is instanced by the design top. The RLOC attribute should be placed on the instance of mymult in the almost_top design and not by traversing the hierarchy of top to set the attribute on the instance of mymult within the almost_top instance contained in top.

Examples of Setting RLOC Attributes for RPMs under Synopsys

In the first example, the VHDL design named hybrid instances twice a Viewlogic-created signed multiplier RPM, mult16x16s, that resides in the file EDIF file mult16x16s.edn. To experiment with this first example, you can copy the hybrid.vhd file and the mult16x16s.edn file into a directory and use the synthesis script compile_hybrid.dc to synthesize the hybrid design. The synthesis script places RLOC attributes on the multipliers so that they are placed relative to one another. I have also provided the .synopsys.dc_setup used to synthesize the design. Make sure that the Xilinx part you map to is at least a 4028EX since the multipliers take up a lot of room.

The next two VHDL examples that I have provided use an RPM created in Synopsys VHDL. The first example is simply a complete RPM of an AND gate and NAND gate. I have manually included the IBUFs and the OBUFs so that it can be independently synthesized and placed on a chip by itself. The VHDL example is provided in ands.vhd and the accompanying sythesis script is included in compile_ands.dc. The .synopsys_dc.setup file from above will work for this example as well as the next example.

The third VHDL example shows how to apply RLOC attributes at the appropriate levels of the hierarchy. The top-level design is called andinst and is included in the file andinstd.vhd. The andinst design instances a version of the ands design which does not have the IBUFs and the OBUFs included. The modified ands design is found in ands2.vhd. The synthesis script compile_andinst.dc places the RLOC attributes on the FMAPs of the ands design as its read in. As I mentioned before, the RLOCs are applied to instances at the top-level of a design and not on instances within other instances of a design. Next, the script sets the "dont_touch" attribute on the ands design so that later synthesis stages do not effect the "hand" placed design. Once this is done, the script reads in the andinst design and synthesizes it normally. With the synthesis complete, the script places the RLOCs on the instances of the ands design which are in the andinst design. Again, only RLOC attributes applied to top-level instances in a design are written out to the EDIF file; if the attributes are applied to an instance within an instance, they will not be written to the EDIF file at the end of the synthesis script.

One last comment on this last example. I noticed warnings about how the FMAPs and the logic in the Synopsys RPMs are "driving" the same nets. This is to be expected and is a good sign. The warnings specifically mentioned how Synopsys is assuming that the nets are being driven by wired-AND logic. Since FMAPs are really not true components, these warnings can be ignored as long as they only apply to FMAPs.

Additionally, as far as simulation of these gate level RPMs are concerned you have two options:

• Write your own simulation models--this one is probably quite easy for some of the primitives.
• Use the simulation models provided in $XILINX/synopsys/libraries/sim/lib/xc4000e/ftgs

Using balance_registers with Synopsys VHDL and Xilinx XC4000 parts

Balance_registers on FPGA libraries

         QUESTION: 

Does retiming or Balance_registers work with FPGA libraries?

ANSWER: 

Yes, it does work with all Look Up Table  based technologies like 
Xilinx XC3000,XC5200 .., Altera Flex family, AT&T ORCA and non-LUT-
based technologies like Actel. The only exception is the Xilinx 
XC4000 family which uses CLBs and IOBs models which consist of both
combinational and sequential devices embedded within each instead of
LUTs. Running  "balance_registers" on a XC4000 design will give you
the following error : RTDC-24 Retiming not supported with XC4000

The methodology for performing Balance_registers on XC4000 design is 
as follows:

        - Compile the design in the normal method till replace_fpga
        - Perform replace_fpga
        - Remove the xfpga_40XX.db from the link and target_library
       (else optimzation during the balance_registers will result 
           in regrouping modules as CLBs & IOBs and Balance_registers won't work)
        - Balance_registers

The improvement that you get from Balance_Registers of XC4000 QoR may not be as
dramatic as compared to other FPGA families since the timing after replace_fpga is
much less accurate (since the packing of the logic inside the CLB is not considered
at this stage).

Using balance_registers and the Xilinx XC4000 series

PROBLEM:

When using balance_registers with the Xilinx XC4000 architecture, I receive
the following error:

Error: Design contains generic logic.  Cannot balance registers. (RTDC-16)

However, my design is completely mapped and has no generic logic.

EXPLANATION:

balance_registers checks your target_library before starting.  In the 
case of the XC4000 architecture, it sees the xfpga library in the 
target_library list.  The xfpga library (i.e. xfpga_4005-5.db) contains 
the CLB and IOB primitives.  balance_registers considers these cells to 
be "generic" logic.

WORKAROUND:

Before running the balance_registers command, reset the target_library to
exclude the xfpga library, then balance_registers will complete.  See the
following example script.

link_library = {xfpga_4005-5.db xprim_4000-5.db xprim_4005-5.db}
target_library = {xfpga_4005-5.db xprim_4000-5.db xprim_4005-5.db}
read -f verilog test.v
compile
replace_fpga
target_library = {xprim_4000-5.db xprim_4005-5.db}
balance_registers

NOTE: Reoptimizing your design after replace_fpga will cause all CLB 
grouping information to be lost.

Why do I get the error RTDC-10 when I use balance_registers?

 Q. I am attempting to implement a multiplier followed by two
 registers, and cannot determine why balance_registers will not retime
 the design and move the registers to make the design meet timing with
 my create_clock constraints.

I get the error RTDC-10(error) No moveable flip-flops in design.
Nothing to retime.

process(reset,pnclk)

begin
if (reset='0') then
 mult_out <= "00000000000000000000000000000000";
 mult_int1 <= "00000000000000000000000000000000";
elsif(pnclk='1' and pnclk'event) then
 mult_int1 <= in1 *in2;
 mult_out <= mult_int1;
end if;
end process;



A. The cause is the asynchronous reset, the tool considers these
registers unmoveable.

Hints and Restrictions for Flip-Flops

The balance_registers command will treat any flip-flop that has an
asynchronous set/reset as dont_touched and will not move it. This
restriction is enforced because balance_registers does not currently
determine the initial state of the flip-flop when it is asynchronously
set through the set/reset pins.

Balance_registers will try to decrease the clock cycle, but might not
be able to produce optimal cycle-times for the same reasons given
earlier in the first two sections of the article (dont_touching
flip-flops, maintaining hierarchy through dont_touches etc.). For this
reason, it is important that the dont_touch attribute be used sparingly
when using balance_registers.
 

Good luck.

Go to the CCL Tutorials Page

Go to the CCL Home Page

Please send comments to: grahamp@fpga.ee.byu.edu