WARNING:Xst:1898 - Due to constant pushing

[rfjhh]

I'm working with ISE Project Navigator and, in a project I have:

WARNING:Xst:1898 - Due to constant pushing, FF/Latch <controlar/controlas/integro/tsint_p_0> is unconnected in block <PruebaPID_01>.

I've synthesized each block separately and they work well, with no problems, no warnings, but when I tie them together the warning message appears.

The signal of reference is properly connected.

 

[barry]

Without seeing all your code (which I don't really want to!), it sounds like you've got some constant declared (intentional or unintentional) and, thus, a register is being eliminated for being unnecessary. You might want to do a post-route simulation to verify that your code still does what you expect.

 

[permute]

rfjhh -- this is probably fine. The synthesis tools will provide warnings even for useful optimizations.

check to see if the warning is correct -- that tsint_p_0 (possibly the 0 bit of ts_int_p) is not used/connected. (eg, a counter that counts 0, 2, 4, 6, 8 ... will not use the lsb of the counter as it will always be 0) Likewise, if a module only uses bits N downto 1 of an input, the 0 bit will not be used. if no other modules use that input, then the driving module will be seen as having an unconnected output (as in your warning). Because that bit is unused, the tools will not generate logic for it (unless used internal to the driving module).

This is one of the large failings of existing tools. the tools will just tell you what they removed and a very short reason why. This makes it more difficult to tell the tools that certain signals must exist (not to keep them if otherwise unused, but to flag an error if the optimizer outright removes them). Likewise, when things are removed, the actual reason can be difficult to track down.

 

[rfjhh]

The tsins_p is a vector (43 downto 0). It is not a counter, it's the result of a successive addition.

Barry, I send the whole project attached and the report where the warnings are included.

 

[mrflibble]

In which case it's most likely this:

... if no other modules use that input, then the driving module will be seen as having an unconnected output (as in your warning). Because that bit is unused, the tools will not generate logic for it (unless used internal to the driving module).

So nothing to worry about, just a warning that this LSB has been optimized away because it not driving any logic.

 

[rfjhh]

In which case it's most likely this:



So nothing to worry about, just a warning that this LSB has been optimized away because it not driving any logic.

The problem is that I have the same warning from tsint_p_0 to tsint_p_28.

 

[permute]

check where tsint_p gets used. You'll probably see some control signal (or possibly a clock) which is either unconnected, or connected to an unfavorable constant. If you simulated the submodules, a good first-effort is to just make sure the modules are connected correctly. probably 50% of issues like this result from copy/paste errors where module-A has ports ordered differently from module B. The second most common issue would be modules instantiated, but the outputs never used. This can also be a copy-paste issue if the signals are copy/pasted and declarations are made from that. in such cases, several inputs will be connected to signals without drivers. Incorrectly connected clock/reset lines are also a common issue, especially when the design has a mix of active-high and active-low resets.

In anycase, you should be able to trace through the design to see where the problem is. look for other warnings about removed logic and look at the code to see if you agree with the removal, or disagree.

 

[mrflibble]

The problem is that I have the same warning from tsint_p_0 to tsint_p_28.

In which case presumably these lower bits do not get used either by the following logic.

The tsins_p is a vector (43 downto 0).

So maybe you only use the 15 or 16 MSB of your adder result? Either that, or just oopsie unconnected by accident as permute said.

Even if you connected all the 44 bits, but then the module after it only depends on the say 15 MSB, then for that module the LSB are just don't cares. And as such they get optimized away.

 

[rfjhh]

Without seeing all your code (which I don't really want to!), it sounds like you've got some constant declared (intentional or unintentional) and, thus, a register is being eliminated for being unnecessary. You might want to do a post-route simulation to verify that your code still does what you expect.

The tsins_p is a vector (43 downto 0). It is not a counter, it's the result of a successive addition.

Barry, I send the whole project attached and the report where the warnings are included.

 

[barry]

rfjhh,

I don't really have the time to try and debug your entire project. Have you tried contacting Xilinx tech support about this? They might be able to help you with this.

As I suggested before, have you tried a post-route simulation to verify that you really DO have a problem? As others have suggested here, this is most likely NOT a problem, unless, of course, your code written incorrectly. This is a WARNING, not an ERROR.

 

[mrflibble]

Alright, this is what I did ...

- opened project in ISE 14.1
- got an error for 17 missing project files. (all .vhd)
- verified they were not there in the provided .rar. Nope, not there
- closed project

Thought I'd give it a quick whirl, but not on an incomplete project.


Regardless, the older advise still stands. Either it's legit and the optimization is what you want. OR you have not connected everything and it's not working.

You can check the design in fpga editor to see if connections are what they are supposed to be. Or do the same in planahead. Or use some post-PAR simulation as barry said.