Removing warning FF/Latch trimming

synthesisvhdlxilinx

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?

Best Answer

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.

Related Topic