06-05-2014 04:13 PM
This is a solved problem, but I want to get it into the forum so others searching for it will be spared the hours I spent trackign this one down.
I was working on an evolving project for Spartan 6 in Plan Ahead 14.7 using Verilog. All of a sudden a seeminly inocuous changed caused two errors to occur, neither of which seemed to bear any relationship to what I had just done, to the error message itself, or to the line in the verilog file that it referenced.
What I had done was to create a verilog module in a separate file to add to the project. I then instantiated it into the top level file and began making the connections. The first issue I ran into was:
"Signal <net_name> in unit <top_module> is connected to the following multiple drivers:"
The confusing part of it was that the line in the file referenced was the beginning of the instantiation of the mew module, and the signal referenced wasn't even part of that module or connected to it!
To make a long story short, the signal referenced was an unused output of the top level module that was temporarily tied low by a statement:
"assign <signal_name = 1'b0;"
there were a dozen such statements for various things that were still stubbed out. Unfortunately two of them were signals I had just tied to outputs in module I had just instantiated, so they were indeed tied to two different sources--the intended one--and the tempory ground. In a convoluted chain of events that only a synthesis tool designer could fully appreciate, I had created a short between a buffer driving the signal low and another signal source. That same buffer was driving ten other signals low--basically placing them all in the same net (that now had two drivers). Instead of reporting the signal that was in error, it reported the first signal it saw that was part of the net, leading me on a wild goose chase. I commented out the assignment of that signal, only to see the error pop up on another unrelated signal. Only when I went to the log where the names of the drivers were called out was I led to the real cause of the problem.
There was a warning message issued as a result of this, that was also confusing, because I didn't recognize it as being related. The warning said:
"Empty module <top_module> remains a black box."
and was accompanied by ucf errors about not being able to find any of the pins called out in the .ucf file that were part of the top module interface. Again the log was my friend. The Messages window only shows the first line of each message. The log file went on to say that it was empty because of synthesis errors, so when I resolved the first problem the second oen went away.
All of this is stupid stuff, but stuff that anyone who doesn't do this every day (and maybe some who do) could run into. Without the detailed information in the log, the messages were misleading enough that it could take a LONG time to get to the bottom of it, particularly if you aren't sure which came first, the chicken or the egg. Development is a dynamic process and there can often be more than one change that occurs in a short time span, as well as additional changes made to try to identify the problem. Then there is the issue of what changes triggered re-doing what steps, resulting in new messages that may not all appear at the same time. It doesn't take long to completely lose track of what might have been the original cause. Hopefully anyone searching for either of these messages will be spared the pain of figuring out why they occurred and why they don't make any sense at all.
06-05-2014 10:46 PM
thanks for sharing your experience. It will help others