Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
15385 Discussions

multiple drivers due to conflicting nodes

SparkyNZ
New Contributor II
578 Views

I cannot find any documentation on the "multiple drivers due to conflicting nodes" error.

Which handbook/guide would this be documented inside?

I'm using Quartus Prime Lite Edition Version 20.1.0 Build 711 06/05/2020

0 Kudos
1 Solution
Kenny_Tan
Moderator
523 Views

Thanks for your design.qar files.


This seems to be a bug in the standard where the error does not report the correct place.


If you use pro edition, you will see the error more accurate.


The Error mention is because you have multiple driver toward dataIN. In your SystemVerilogTest1.sv, go to line 142, comment out //assign dataBus  = ( chipSelectRAM ) ? dataOut  : 16'bZZZZZZZZZZZZZZZZ;   // Do I need to include iSDRAMWriteRequest here??


You will see that the synthesis passed.


How do you check if this datain have multiple driver, you can run elaboration. Go to rtl viewer, look for the signal datain and you will see there are two driver driving it. Attached screenshot.


View solution in original post

5 Replies
Kenny_Tan
Moderator
559 Views

Usually when you right click the error message, it will show you the details in a link.


Can you copy and paste the full error message here?


this might due to when you are assigning the same signal on 2 different edges. Doing something like:


always @(posedge clk)

foo<=value


always @(posedge other_signal)

foo<=other_value


will quite likely result in such an error, because foo is a single flip-flop and it can be clocked from one source. You could do some additional logic that will take clk and other_signal and generate single write strobe out of those two, but then you will quite possibly run into warnings concerning usage of general routing resources as clock signals. If you add something like this:


Code: [Select]

always @ (a, b, c)

if(a)

foo=b;

else

foo=c;

(this should synthesize to a mux)


then you will most definitely get that error, since mux will result in non-registered value, and the clocked part will produce a registered value.


SparkyNZ
New Contributor II
555 Views

Hi @Kenny_Tan . Sure, the error I get is (using right-click and Copy):

Error (13076): The node "VGAController:vgaController|dataH" has multiple drivers due to the conflicting nodes "dataBus[8]" and "SDRAMController8Bit:sdramController|ioData[8]"

I'll attach my project - probably easier - it also relates to all of the many questions I had in my previous post too.

SystemVerilogTest1.sv is my top level file. There's a lot of unfinished rubbish in it's state machine but hopefully it will help. I really do need to move to non-blocking assignments too but.. I haven't.. yet.

 

Kenny_Tan
Moderator
524 Views

Thanks for your design.qar files.


This seems to be a bug in the standard where the error does not report the correct place.


If you use pro edition, you will see the error more accurate.


The Error mention is because you have multiple driver toward dataIN. In your SystemVerilogTest1.sv, go to line 142, comment out //assign dataBus  = ( chipSelectRAM ) ? dataOut  : 16'bZZZZZZZZZZZZZZZZ;   // Do I need to include iSDRAMWriteRequest here??


You will see that the synthesis passed.


How do you check if this datain have multiple driver, you can run elaboration. Go to rtl viewer, look for the signal datain and you will see there are two driver driving it. Attached screenshot.


Kenny_Tan
Moderator
521 Views
SparkyNZ
New Contributor II
507 Views

Thanks @Kenny_Tan . I will mark your response as the accept solution. The more I look at my code, the more ridiculous it is.. but that's what happens when you get confused about what you can and cannot do.

I still don't understand why some of those registers were removed from my design. I can only assume it's Quartus attempting to optimise redundant logic and throwing it away.

Now that I understand what  the basic problem is, I can move forward. My VGAController is doing  the wrong thing anyway. I've replaced the chipSelectRAM and chipSelectVGA with a 2-bit value of enums so chipSelect is mutually exclusive for my modules. Having 2 separate logic flags I ran the risk of both chipSelectXXX flags being high at the same time.

Thanks again for your help.

Reply