Xilinx ConstraintSystem:59

R

Richard

Guest
Hi all,

I have a very simple statemachine that sets some control signals to
interact with a third party IP. The code looks roughly as follows:

entity testip is
port (
...
fifo_dataout : in std_logic_vector(0 to 31);
ip_dataout : in std_logic_vector(0 to 31);
ip_ce : out std_logic;
ip_we : out std_logic;
ip_datain : out std_logic_vector(0 to 31);
);

end entity testip;

architecture imp of testip is

signal ip_ce_ns : std_logic;
signal ip_we_ns : std_logic;
signal ip_ce_cs : std_logic;
signal ip_we_cs : std_logic;
signal ip_dataout_i : std_logic_vector(0 to 31);
...

begin

COMB : process (...)
begin
ip_ce_ns <= ip_ce_cs;
ip_we_ns <= ip_we_cs;

case ip_nstate_cs is
when IDLE =>
...

end case;
end process COMB;

REG: process (Clk) is
begin
if (Clk'event and Clk = '1') then
if (Rst = '1') then
ip_ce_cs <= '1';
ip_we_cs <= '1';
...
else
ip_ce_cs <= ip_ce_ns;
ip_we_cs <= ip_we_ns;
...
end if;
end if;
end process REG;

S0: ip_ce <= ip_ce_cs;
S1: ip_we <= ip_we_cs;
S2: ip_datain <= fifo_dataout;
S3: ip_dataout_i <= Ip_dataout;

end architecture imp;

Sythesis works fine, however, when applying the following constraint
file I get ERROR:ConstraintSystem:59 - NET "testip/ip_we" not found.
The same occurs for testip/ip_datain and testip/ip_ce.

Net testip/ip_datain<*> MAXDELAY = 2 ns;
Net testip/ip_ce MAXDELAY = 2 ns;
Net testip/ip_we MAXDELAY = 2 ns;

I checked the netlist, and indeed there is neither a testip/ip_we, a
testip/ip_ce nor a testip/ip_datain net. I checked the sythesis log and
it does not say that the signals have been trimmed! Anyone an idea why
these signals are not in the netlist, all very confusing.

Many thanks for any feedback!
 
On Nov 1, 4:22 pm, Richard <Rich...@yahoo.com> wrote:
Hi all,

I have a very simple statemachine that sets some control signals to
interact with a third party IP. The code looks roughly as follows:

entity testip is
   port (
     ...
     fifo_dataout        : in  std_logic_vector(0 to 31);
     ip_dataout          : in  std_logic_vector(0 to 31);
     ip_ce               : out std_logic;
     ip_we               : out std_logic;
     ip_datain           : out std_logic_vector(0 to 31);
     );

end entity testip;

architecture imp of testip is

   signal ip_ce_ns     : std_logic;
   signal ip_we_ns     : std_logic;
   signal ip_ce_cs     : std_logic;
   signal ip_we_cs     : std_logic;
   signal ip_dataout_i : std_logic_vector(0 to 31);
   ...

begin

COMB : process (...)
       begin
             ip_ce_ns <= ip_ce_cs;
             ip_we_ns <= ip_we_cs;

          case ip_nstate_cs is
             when IDLE      =
             ...

          end case;
end process COMB;

REG: process (Clk) is
        begin
           if (Clk'event and Clk = '1') then
              if (Rst = '1') then
                   ip_ce_cs <= '1';
                   ip_we_cs <= '1';
                   ...
              else
                   ip_ce_cs <= ip_ce_ns;
                   ip_we_cs <= ip_we_ns;
                   ...
              end if;
         end if;
end process REG;

S0:     ip_ce <= ip_ce_cs;
S1:     ip_we <= ip_we_cs;
S2:     ip_datain <= fifo_dataout;
S3:     ip_dataout_i <= Ip_dataout;

end architecture imp;

Sythesis works fine, however, when applying the following constraint
file I get ERROR:ConstraintSystem:59 -  NET "testip/ip_we" not found.
The same occurs for testip/ip_datain and testip/ip_ce.

Net testip/ip_datain<*> MAXDELAY = 2 ns;
Net testip/ip_ce MAXDELAY = 2 ns;
Net testip/ip_we MAXDELAY = 2 ns;

I checked the netlist, and indeed there is neither a testip/ip_we, a
testip/ip_ce nor a testip/ip_datain net. I checked the sythesis log and
it does not say that the signals have been trimmed! Anyone an idea why
these signals are not in the netlist, all very confusing.

Many thanks for any feedback!
Click to expand...
The signals are (probably) there with a new (and somewhat confusing)
name.

Every synthesis tool I have ever used has been loose and free about
renaming signals.

RK.
 
The signals are (probably) there with a new (and somewhat confusing)
name.

Every synthesis tool I have ever used has been loose and free about
renaming signals.
Click to expand...
And is there any good way to find out in what they have been renamed?

Thanks
 
On Nov 1, 6:07 pm, Richard <Rich...@yahoo.com> wrote:
The signals are (probably) there with a new (and somewhat confusing)
name.

Every synthesis tool I have ever used has been loose and free about
renaming signals.

And is there any good way to find out in what they have been renamed?

Thanks
Click to expand...
Unless the signal has been merged into the middle of a LUT the name is
usually the highest level net name. In this case it would likely be
the net that is connected to the ip_we and ip_ce ports on this core.

Ed McGettigan
--
Xilinx Inc.
 
On Mon, 01 Nov 2010 23:22:05 +0000, Richard <Richard@yahoo.com> wrote:

Hi all,

I have a very simple statemachine that sets some control signals to
interact with a third party IP. The code looks roughly as follows:
....
Sythesis works fine, however, when applying the following constraint
file I get ERROR:ConstraintSystem:59 - NET "testip/ip_we" not found.
The same occurs for testip/ip_datain and testip/ip_ce.

Net testip/ip_datain<*> MAXDELAY = 2 ns;
Net testip/ip_ce MAXDELAY = 2 ns;
Net testip/ip_we MAXDELAY = 2 ns;

I checked the netlist, and indeed there is neither a testip/ip_we, a
testip/ip_ce nor a testip/ip_datain net. I checked the sythesis log and
it does not say that the signals have been trimmed! Anyone an idea why
these signals are not in the netlist, all very confusing.
Click to expand...
Combinational net names can get sliced, diced, absorbed and further
processed so it might be difficult to find out what they've become, if
indeed they've survived at all. So my suggestion would be to set your
constraints based on clock period and chip IOs instead of trying to
set delays on nets.
One helpful note might be that register names are almost always
preserved so you might be able to refer to ip_we_cs etc more easily.
--
Muzaffer Kal

DSPIA INC.
ASIC/FPGA Design Services

http://www.dspia.com
 
Combinational net names can get sliced, diced, absorbed and further
processed so it might be difficult to find out what they've become, if
indeed they've survived at all. So my suggestion would be to set your
constraints based on clock period and chip IOs instead of trying to
set delays on nets.
One helpful note might be that register names are almost always
preserved so you might be able to refer to ip_we_cs etc more easily.
Click to expand...
Thanks for all your feedback, is there any way that with some kind of
options I can make sure that the name of the nets is preserved? The
problem is that these nets interact with a third party IP, and the
constraints on these nets are apparantly mandotory, so in other words
I have to contrain these particular signals to make the whole design
working.
 
On Tue, 02 Nov 2010 09:02:40 +0000, Richard <Richard@yahoo.com> wrote:

Combinational net names can get sliced, diced, absorbed and further
processed so it might be difficult to find out what they've become, if
indeed they've survived at all. So my suggestion would be to set your
constraints based on clock period and chip IOs instead of trying to
set delays on nets.
One helpful note might be that register names are almost always
preserved so you might be able to refer to ip_we_cs etc more easily.

Thanks for all your feedback, is there any way that with some kind of
options I can make sure that the name of the nets is preserved? The
problem is that these nets interact with a third party IP, and the
constraints on these nets are apparantly mandotory, so in other words
I have to contrain these particular signals to make the whole design
working.
Click to expand...
There are various attributes you can attach to nets in VHDL, to preserve them.
If life were simple, they would actually preserve the net names you need.

Unfortunately there is a mysterious set of rules determining when the tools will
preserve a net, and when they will simply ignore the attribute (and maybe print
a message in the synthesis report).

Some of the useful ones are "keep", "syn_keep", "preserve_signal" (in some
synthesis tools, not sure about XST), "equivalent_register_removal=no", and
"don't_optimise".

For example, if you use "keep" on a signal that is being removed by equivalent
register removal, the signal will be deleted anyway, and the warning buried in a
megabyte of synthesis report.

Some apply during synthesis, but there are further optimisation stages in Map,
and these may need different constraints.

See the Constraints Guide for more information, and try searching the answers
database.

http://www.xilinx.com/support/answers/25016.htm
shows a case where a specific combination of three constraints are required on
the same signal...

attribute syn_keep: boolean;
attribute keep: boolean;
attribute preserve_signal: boolean;

Also, from AR#23990
http://www.xilinx.com/support/answers/23990.htm
# The KEEP attribute does not block trimming - A common misconception is that
KEEP properties can be used to block signal trimming. The KEEP property can be
used to prevent a signal from being absorbed into a component, but it has no
effect on trimming behavior. The correct attribute to block trimming is "S" (AKA
Save, SAVESIG, NOCLIP).
# Beginning with ISE version 10.1, the S attribute not only blocks trimming, but
also constant optimization. The S property can be applied directly to a logical
block, or to a net attached to a logical block to prevent both constant
optimization or trimming.

Ed: How about a white paper entitled "Help: my signal disappeared!" or "You are
lost in a maze of optimization constraints; all different" with a comprehensive
list of such constraints and their interactions?

- Brian
 
On Nov 2, 7:03 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
On Tue, 02 Nov 2010 09:02:40 +0000, Richard <Rich...@yahoo.com> wrote:
Combinational net names can get sliced, diced, absorbed  and further
processed so it might be difficult to find out what they've become, if
indeed they've survived at all. So my suggestion would be to set your
constraints based on clock period and chip IOs instead of trying to
set delays on nets.
One helpful note might be that register names are almost always
preserved so you might be able to refer to ip_we_cs etc more easily.

Thanks for all your feedback, is there any way that with some kind of
options I can make sure that the name of the nets is preserved? The
problem is that these nets interact with a third party IP, and the
constraints on these nets are apparantly mandotory, so in other words
I have to contrain these particular signals to make the whole design
working.

There are various attributes you can attach to nets in VHDL, to preserve them.
If life were simple, they would actually preserve the net names you need.

Unfortunately there is a mysterious set of rules determining when the tools will
preserve a net, and when they will simply ignore the attribute (and maybe print
a message in the synthesis report).

Some of the useful ones are "keep", "syn_keep", "preserve_signal" (in some
synthesis tools, not sure about XST), "equivalent_register_removal=no", and
"don't_optimise".

For example, if you use "keep" on a signal that is being removed by equivalent
register removal, the signal will be deleted anyway, and the warning buried in a
megabyte of synthesis report.

Some apply during synthesis, but there are further optimisation stages in Map,
and these may need different constraints.

See the Constraints Guide for more information, and try searching the answers
database.

http://www.xilinx.com/support/answers/25016.htm
shows a case where a specific combination of three constraints are required on
the same signal...

attribute syn_keep: boolean;
attribute keep: boolean;
attribute preserve_signal: boolean;

Also, from AR#23990http://www.xilinx.com/support/answers/23990.htm
# The KEEP attribute does not block trimming - A common misconception is that
KEEP properties can be used to block signal trimming. The KEEP property can be
used to prevent a signal from being absorbed into a component, but it has no
effect on trimming behavior. The correct attribute to block trimming is "S" (AKA
Save, SAVESIG, NOCLIP).
# Beginning with ISE version 10.1, the S attribute not only blocks trimming, but
also constant optimization. The S property can be applied directly to a logical
block, or to a net attached to a logical block to prevent both constant
optimization or trimming.

Ed: How about a white paper entitled "Help: my signal disappeared!" or "You are
lost in a maze of optimization constraints; all different" with a comprehensive
list of such constraints and their interactions?

- Brian
Click to expand...
Another point on the final net name. Some of it depends on the
settings for
synthesis. "keep hierarchy" and "hierarchy separator" options both
affect
the final net names. Also you can use wildcard characters in
your .ucf
file. So for example if you know the hierarchy but not the hierarchy
separator
character you could change your lines to:

Net "testip?ip_datain<*>" MAXDELAY = 2 ns;
Net "testip?ip_ce" MAXDELAY = 2 ns;
Net "testip?ip_we" MAXDELAY = 2 ns;

or if you only know part of the hierarchy but not the top level
instantiation you might have:

Net "*/testip/ip_datain<*>" MAXDELAY = 2 ns;
Net "*/testip/ip_ce" MAXDELAY = 2 ns;
Net "*/testip/ip_we" MAXDELAY = 2 ns;

For any particular build, you could remove your constraints to get an
error-free build and
then search through the nets in the FPGA editor to see where they
went.

Regards,
Gabor
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top