Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

WARNING:Xst:1898 - Due to constant pushing

Status
Not open for further replies.

rfjhh

Newbie level 4
Joined
Jun 14, 2012
Messages
6
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,327
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

Advanced Member level 5
Joined
Mar 31, 2005
Messages
5,354
Helped
1,137
Reputation
2,286
Reaction score
1,154
Trophy points
1,393
Location
California, USA
Activity points
29,264
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

Advanced Member level 3
Joined
Jul 16, 2010
Messages
923
Helped
295
Reputation
590
Reaction score
268
Trophy points
1,343
Activity points
8,543
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

Newbie level 4
Joined
Jun 14, 2012
Messages
6
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,327
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.
 

Attachments

  • Prueba01_PID_x.rar
    260.1 KB · Views: 1

mrflibble

Advanced Member level 5
Joined
Apr 19, 2010
Messages
2,724
Helped
679
Reputation
1,360
Reaction score
651
Trophy points
1,393
Activity points
19,551
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

Newbie level 4
Joined
Jun 14, 2012
Messages
6
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,327
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

Advanced Member level 3
Joined
Jul 16, 2010
Messages
923
Helped
295
Reputation
590
Reaction score
268
Trophy points
1,343
Activity points
8,543
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

Advanced Member level 5
Joined
Apr 19, 2010
Messages
2,724
Helped
679
Reputation
1,360
Reaction score
651
Trophy points
1,393
Activity points
19,551
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

Newbie level 4
Joined
Jun 14, 2012
Messages
6
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,281
Activity points
1,327
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.
 

Attachments

  • Prueba01_PID_x.rar
    260.1 KB · Views: 1

barry

Advanced Member level 5
Joined
Mar 31, 2005
Messages
5,354
Helped
1,137
Reputation
2,286
Reaction score
1,154
Trophy points
1,393
Location
California, USA
Activity points
29,264
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

Advanced Member level 5
Joined
Apr 19, 2010
Messages
2,724
Helped
679
Reputation
1,360
Reaction score
651
Trophy points
1,393
Activity points
19,551
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. :p


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.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Top