XST giving wrong/unrelated errors...bug?

I'm still using Xilinx ISE (just found out it's discontinued).

Here's a scenario I have in VHDL:

Entity PinDriver with the following two outputs:
OutPinA
OutPinB

Architecture looks like this:
{process with some FSM that does things with OutPinA}
OutPinB <= '0'; -- active low

XST gives the following error:
ERROR:Xst:528 - Multi-source in Unit <PinDriver> on signal <OutPinB>; this signal is connected to multiple drivers.

Obviously there's only one driver for OutPinB... That identifier is used in the design only once and does not appear anywhere else. This looks like an obvious problem in software.

I'm thinking XST is having trouble synthesizing the FSM, but it does not drive the pin in question, does not appear in FSM. If I comment out the FSM the entity will synthesize correctly, nevertheless it doesn't change the fact that it's giving a completely wrong and unrelated error, a bug basically.

Original design had more pins, and it was saying that a pin has multiple drivers. I would remove that pin from the design, then it would complain about the next pin (which again had just one statement and single driver).

Anybody else encounter this before?

- - - Updated - - -

Bug confirmed.

I found the problem in my FSM, but it was on another pin. The synthesizer was having a problem after which the parser was grabbing the next thing it sees and throwing that in the error, which results in an error message that makes no sense.

Without the code - difficult for us to make any comments....
For All ISE's bad reputation, I would still think this is likely a code bug rather than ISE bug.

TrickyDicky said:

Without the code - difficult for us to make any comments....
For All ISE's bad reputation, I would still think this is likely a code bug rather than ISE bug.

Click to expand...

I did have a problem in the code, just with another pin. Error listed the wrong pin, in fact it always listed the first thing parser encounters after the process with the problem. It's a bug in synthesizer error printout code.

Good you located your code error and apparently found the bug in ISE error reporting.

For future threads of this kind, I strongly suggest to post meaningful code, to allow others to help or to learn from your observations respectively.

If I posted code then you would complain that it's too long. You would complain either way, so there is no middle ground here. I suppose I could have written a shorter version to reproduce this error, but, you know, is that a sane way to spend my time, looking for bugs in a software that's both not up to date and discontinued? I'm running 14.2 and latest is 14.7

Quite possible that Xilinx also knew of the bug and corrected it in the updates that followed.

If I posted code then you would complain that it's too long.

Click to expand...

I can't guarantee that nobody complains, but I surely won't. There's also a big difference between code shown for informational purposes, as in this case, and requests for homework projects review. In the latter case, a comment like "do you really expect us to go through the code" are not unusual.

Not sure, how easy the relevant statement can be identified in your code. In any case, posted code examples should be enclosed in code or syntax tags, or appended as a file.

I am suspicious.

The issue with mulitple driver errors in older tools is that software devs are not users of the tool. This means a list of drivers > 1 should print out one for an error message and that seems fine...

The early versions of Vivado also had this. Where a clock net would be named O_1 when presented to a user. This makes so much sense as "O" sorts lower than "SysClk"...

This can often be a point of confusion -- a reported net is either an odd choice or an internal synthesis net.

I assure you, that was not the case here. In the actual code I was working on FSM that switches memory control signals. In the FSM I had a mistake where one case was driving the port directly instead of the signal associated with it, which resulted in a synthesizer error of type "multiple drivers", and after that is where it goes wrong.

It complained about one of the LED outputs that was driven a constant '0' in the architecture that I was not using it for anything was having the multiple drivers. As it happens that also was the first line of code right after the process with the problem. I removed the port definition for that LED and removed it in the constraints file. The parser for the synthesizer then picked the next line of code after it. I suspect if I left no lines of code after that the parser would then try to read token array out of bounds and blow up.

I didn't have memory logic driving any LEDs either way. The error as it was printed was quite insane.

Still - without any code - we only have your word for it..

whack said:

If I posted code then you would complain that it's too long. You would complain either way, so there is no middle ground here.

Click to expand...

I went and looked back at your posting history, and you've only posted code in 1 thread ever and no one complained about it?

So unless you've got multiple accounts and the other one has received a bunch of infractions for not enclosing your code in code/syntax tags, I don't understand why you don't post code. The only valid excuse for not posting your code is you aren't allowed to because it is under NDA or is proprietary to your work and would divulge some confidential information. In those cases I've resorted to creating testcases for submission to vendor support channels.

FYI, I am okay with looking at 500+ lines of code as long as you've formatted the code nicely with spaces (no tabs) and have useful comments. Without either of those I'll complain. If you did post that many lines it's best to post using syntax tags, code tags makes you have to scroll the window as you can't expand the code to show all the lines at once.

whack said:

Quite possible that Xilinx also knew of the bug and corrected it in the updates that followed.

Click to expand...

If you post the code I can synthesize it with my Xilinx ISE 14.7 and see if it is true.

Regretfully I got suckered into writing code to demonstrate this bug on obsolete software. I told myself to resist the urge. Should have listened.

I have spent an hour piecing it together and have not yet built up an FSM complex enough to make the parser grab an identifier outside of the process. And at this point I spent more time than I allocated to this. So no more time. I have no intention to revisit this again.

Ok. In my experience, there is a reason for the misleading error. Either some net name resolution issue where the name is not the expected one or an issue where a net is optimized to be the same as another and then this name is used. Either a way, is is old and won't be used in a few years.

whack said:

Regretfully I got suckered into writing code to demonstrate this bug on obsolete software. I told myself to resist the urge. Should have listened.

Click to expand...

Instead of trying to make a new testcase why didn't you just post original 100,000 line file that has the error, I would have been more than willing to try it out on 14.7 just like CataM was offering to do. You never gave an adequate reason for not having done so, other than the comment people will complain either way.

Instead you waste time with writing demonstration code, when you already have code that exhibits the bug...:roll: