0
\$\begingroup\$

I have a 16 bit signal, for me only the last 4 bits are important and the first 12 bits are always "0", so I'm doing nothing with the first 12 bits and in the end it goes out of my component to next component like this :

my16bitsignal <= x"000"& my4bitsignal;

In my VHDL component I do lots of operations etc. with my4bitsignal but in the end when I synthesize Xilinx gives me these warnings:

WARNING:Xst:1710 - FF/Latch <my16bitsignal_4> (without init value) has a constant value of 0 in block <MYCOMPONENT>. This FF/Latch will be trimmed during the optimization process.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch <my16bitsignal_5> (without init value) has a constant value of 0 in block <MYCOMPONENT>. This FF/Latch will be trimmed during the optimization process.
.
.
WARNING:Xst:1895 - Due to other FF/Latch trimming, FF/Latch <my16bitsignal_15> (without init value) has a constant value of 0 in block <MYCOMPONENT>. This FF/Latch will be trimmed during the optimization process.
WARNING:Xst:2404 -  FFs/Latches <my16bitsignal<15:4>> (without init value) have a constant value of 0 in block <MYCOMPONENT>.

How can I avoid these warnings? Create a temporary 12 bit signal with zeros and then assign it to first 12 bits? This solution seems very lame to me, is there another way?

\$\endgroup\$
5
  • \$\begingroup\$ Accept that these are warnings, not errors. If you ever use Xilinx's own IP you will find it generates hundreds of such warnings, and there is nothing you can do about that (except avoiding vendor IP). \$\endgroup\$ Jun 17, 2014 at 11:20
  • \$\begingroup\$ @BrianDrummond what do you mean with own IP? Our prof says I don't like latches thus I have to remove it somehow ... \$\endgroup\$
    – Anarkie
    Jun 17, 2014 at 11:21
  • \$\begingroup\$ Read the warning : it tells you the FF or latch is being removed (trimmed) for you. \$\endgroup\$ Jun 17, 2014 at 11:23
  • \$\begingroup\$ @BrianDrummond you have a point =) thanks! I can give him this argument, but still I would be glad to know if there is a way of removing it. \$\endgroup\$
    – Anarkie
    Jun 17, 2014 at 11:27
  • 1
    \$\begingroup\$ Only this : make my16bitsignal the correct width ... 4 bits ... and fix its name! \$\endgroup\$ Jun 17, 2014 at 11:28

1 Answer 1

2
\$\begingroup\$

The one sure way to eliminate those warnings is to not generate the extraneous latches/FFs in the first place, by sizing your buses appropriately. Unfortunately, this is often at odds with other system-level goals, such as modular design and "standardized" interfaces. So, most of us just live with the warnings.

In some specific cases, it is possible to eliminate the latches without too much hassle. For example, in your specific instance, it would seem your assignment statement is inside a clocked process, which is why it creates latches in the first place. You could split it into two separate statements, with only the 4 LSBs assigned inside the process, and the 12 MSBs assigned outside the process.

I agree, this makes the source code messier and harder to follow, and it may not even eliminate the problem altogether — very often, it just pops up somewhere else. It's almost impossible to eliminate all such warnings, so going to extreme lengths to get rid of some of them just isn't worth it.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.