Tips & Hints

Synplify Pro Software

Q. Are port/generic maps supported in Configurations in the Synplify Pro tool?

A. Yes. Beginning with the Synplify Pro software version 8.6, support for port maps, generic maps, and mapping of multiple entity names to the same component is allowed inside configuration specification and declaration.

Generic maps: Generics can have a different name/size when they are defined at the entity level and at the component level. Using configuration, we can bind them together either through “specification” or “declaration”.

Port maps: Ports can have different names when they are defined at the entity level and at the component level. Using configuration, we can bind them together either through “configuration specification” or “configuration declaration”.

Multiple Entity binding: Multiple entities can exist for a single component and using configuration, we can bind them accordingly. (Usage of “for label” clause)

Binding Rules (As per LRM):
1. Configuration specification.
2. Component instantiation.
3. Component declaration
i.e the values specified in the “configuration specification” would override the one specified in “component instantation” and “component declaration”.

Here are some examples regarding the same.

Example 1 related to generic/port map

Library ieee;
use ieee.std_logic_1164.all;
entity sub1 is
generic (size1: integer:= 6; size2: integer:= 6);
port ( a : in std_logic_vector(size1 -1 downto 0);
       b : in std_logic_vector(size1 -1 downto 0);
       c : out std_logic_vector(size2 -1 downto 0));
end sub1;

architecture rtl of sub1 is
begin
       c <= a and b;
end rtl;

architecture rtl2 of sub1 is
begin
       c <= a or b;
end rtl2;

Library ieee;
use ieee.std_logic_1164.all;
entity test is
generic ( range1 : integer := 1);
port ( ta, ta1 : in std_logic_vector( range1 - 1 downto 0);
       tb, tb1 : in std_logic_vector( range1 - 1 downto 0);
       tc, tc1 : out std_logic_vector( range1 - 1 downto 0));
end test;

architecture test_a of test is

component submodule1
generic ( my_size1 : integer := 6; my_size2 : integer := 6);
port ( d : in std_logic_vector(my_size1 -1 downto 0);
       e : in std_logic_vector(my_size1 -1 downto 0);
       f : out std_logic_vector(my_size2 -1 downto 0));
end component;

for UUT1 : submodule1
use entity work.sub1(rtl)
           generic map (size1 => my_size1, size2 => my_size2)
           port map ( a => d, b => e, c => f);

for UUT2 : submodule1
use entity work.sub1(rtl2)
           generic map (size1 => my_size1, size2 => my_size2)
           port map ( a => d, b => e, c => f);

begin
UUT1 : submodule1 generic map (my_size1 => 1, my_size2 => 1)
           port map ( d => ta, e => tb,f => tc);

UUT2 : submodule1 generic map (my_size1 => 1, my_size2 => 1)
           port map ( d => ta1, e => tb1,f => tc1);
end test_a;

Example 2 related to multiple entity binding

---sub1
Library ieee;
use ieee.std_logic_1164.all;
entity sub1 is
generic (size1: integer:= 6; size2: integer:= 6);
port ( a : in std_logic_vector(size1 -1 downto 0);
       b : in std_logic_vector(size1 -1 downto 0);
       c : out std_logic_vector(size2 -1 downto 0));
end sub1;

architecture rtl of sub1 is
begin
       c <= a and b;
end rtl;

----sub2
Library ieee;
use ieee.std_logic_1164.all;
entity sub2 is
generic ( width1 : integer; width2 : integer);
port ( a1 : in std_logic_vector(width1 -1 downto 0);
       b1 : in std_logic_vector(width1 -1 downto 0);
       c1 : out std_logic_vector(width2 -1 downto 0));
end sub2;

architecture rtl of sub2 is
begin
       c1 <= a1 xor b1;
end rtl;

---test
Library ieee;
use ieee.std_logic_1164.all;
entity test is
generic ( range1 : integer := 1);
port ( ta, ta1 : in std_logic_vector( range1 - 1 downto 0);
       tb, tb1 : in std_logic_vector( range1 - 1 downto 0);
       tc, tc1 : out std_logic_vector( range1 - 1 downto 0));
end test;

architecture test_a of test is
component submodule
generic ( my_size1 : integer := 6; my_size2 : integer := 6);
port ( d,e : in std_logic_vector(my_size1 -1 downto 0);
       f : out std_logic_vector(my_size2 -1 downto 0));
end component;
begin

UUT1 : submodule generic map (1, 1) port map ( d => ta, e => tb, f => tc);
UUT2 : submodule generic map (1,1) port map ( d => ta1, e => tb1,f => tc1);

end test_a;

configuration my_config of test is
for test_a

   for UUT1 : submodule
              use entity work.sub1(rtl)
              generic map (my_size1, my_size2)
              port map ( d, e, f);
   end for;

   for others : submodule
                use entity work.sub2(rtl)
                generic map (my_size1, my_size2)
                port map ( d, e, f);
   end for;
end for;
end my_config;

Synplify Premier Software

Q. How should the UCF file be used in Synplify Premier flow?

A. Since the physical synthesis flow in the Synplify Premier software involves synthesis, placement, and routing, it is necessary to have the same set of constraints applied during synthesis and the place-and-route stage. However, since the Synplify Premier tool does not read the Xilinx UCF file, it’s essential to provide the UCF constraints in the SDC format.

The UCF constraints can be translated to the SDC format either manually, or by using the stand-alone utility ucf2sdc.exe provided in the ‘bin’ directory of the Synplify Premier software installation.

Usage:
<installation directory>/bin/ucf2sdc.exe –iucf <filename>.ucf –osdc <filename>.sdc

NOTE: This utility supports most of the common timing and physical constraints. Unsupported constraints that do not get translated will be indicated in the generated SDC as ‘unsupported’.

The generated SDC file needs to be added to the Premier project in place of the UCF. It is important that the UCF file is not included as part of the project, neither is it available in the implementation directory.

Identify Software

Q. What is the Skew-Resistant Hardware option in the Identify software?

A. Identify uses a JTAG connection to communicate with the device. In some cases, all the clock buffers may be utilized on the device and there are no clock buffers available for the JTAG clock.

In such cases, select the Use skew-resistant hardware option. This option incorporates skew-resistant master/slave hardware to allow the instrumentation logic to operate without requiring an additional global clock buffer resource for the JTAG clock.

The JTAG clock may drive a large amount of loads and is particularly susceptible to clock skew. Users who have no available clock resources have the option to build skew-resistant hardware. By replacing each flip-flop with a master-slave implementation, the design is able to withstand up to half of a clock cycle in skew. At the slow speeds of JTAG, this is quite acceptable. Therefore, if using skew-free hardware, no clock buffer is needed for the debug logic. The trade-off is area. The master-slave implementation effectively doubles the amount of flip-flops used for the debug JTAG scan.

Figure 1: IICE logic before use of Skew-Resistant Hardware option.

Figure 2: Equivalent IICE logic after use of Skew-Resistant Hardware option.