multiple drivers due to the non-tri-state driver

[SparkyNZ]

Can someone please help me with this error.

Warning (13035): Inserted always-enabled tri-state buffer between "VGAController:vgaController|dataH" and its non-tri-state driver.

Error (13076): The node "VGAController:vgaController|dataH" has multiple drivers due to the non-tri-state driver "SDRAMController8Bit:sdramController|ioData[8]"

Does this mean that there is more than one thing trying to drive ioData or dataH? I read the error as saying that more than one  thing is trying to drive dataH because ioData is a driver. Either way, it makes no sense to me in my Verilog code:

module SDRAMController8Bit #( parameter ADDR_WIDTH=21, DATA_WIDTH=16 )
(
  // ioData is wired to dataBus wire in my top module
  inout  wire  [DATA_WIDTH-1 : 0 ] ioData,
..

module VGAController #( parameter ADDR_WIDTH=20, DATA_WIDTH=16 )
(
  // iData is wired to dataBus wire in my top module
  input  wire  [DATA_WIDTH-1 : 0 ] iData,
  input  logic                     iDataAvailable,
..
  byte unsigned dataH = 0;
..
  logic [15 : 0 ] iDataCopy    = 0;

always @( posedge iClk )
..
  if( iDataAvailable )
  begin
    iDataCopy = iData;

    dataH = iDataCopy[ 15 : 8 ];

There must be something wrong with that last if() statement? To me, dataH is not directly assigned or connected to iData because it is assigned what's in iDataCopy.

Can somebody please help me out here?

[SparkyNZ]

Well.. I may have resolved my issue. If I have, I don't think the error message was very helpful in this case. The error appears to be caused by this line, which neither mentions dataH or ioData:

    iDataCopy = iData; // Caused by this

    dataH = iDataCopy[ 15 : 8 ];

I know that ioData is connected to iData, so that's one part of the puzzle, but I still don't know why the assignment to dataH from iDataCopy would be a problem??

I've changed the code as follows so that iData is only connected to dataIncoming when the chipSelect is high or HiZ otherwise.

logic [15 : 0 ] dataIncoming = 0;
assign dataIncoming = ( chipSelect ) ? iData : 16'bZZZZZZZZZZZZZZZZ;
..
//iDataCopy = iData; // This will give "multiple drivers due to the non-tri-state driver" error
iDataCopy = dataIncoming;
dataH = iDataCopy[ 15 : 8 ];

So why did Quartus give me the error? Is is because the incoming iData/ioData wire was driving iDataCopy and another register in another module? If so, why does the error refer to dataH and not iDataCopy?

Update: No, the above didn't work either..

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

Why do I have conflicting nodes? Is this because VGAController takes data from an input wire and SDRAMController uses an inout wire? The dataBus wire is declared as inout in my top module

Google has no results for "multiple drivers due to the conflicting nodes". I'm completely stumped.

[SparkyNZ]

I'm further confused again.. I now have a problem in my Top level module:

// Shared buses
wire  [15 : 0 ] dataBus;
// Registers to be switched onto the bus
logic [15 : 0 ] dataRAM;

//bit[ 15:0 ] dataVal;
logic[ 15:0 ] dataVal;  // logic or bit? Made no difference
..
assign dataBus    = ( chipSelectRAM ) ? dataRAM    : 16'bZZZZZZZZZZZZZZZZ;
..
always_ff @( posedge clk  )
..
  dataVal       = dataBus;   // Error here

Error (13076): The node "dataVal" has multiple drivers due to the non-tri-state driver "SDRAMController8Bit:sdramController|ioData[8]"

dataBus is connected to sdramController's ioData wire

dataRAM was being used for outgoing data.

So I modified the code further, renaming dataRAM to dataOut and adding a dataIn and now it compiles:

logic [15 : 0 ] dataOut;
logic [15 : 0 ] dataIn;

assign dataBus    = ( chipSelectRAM ) ? dataOut    : 16'bZZZZZZZZZZZZZZZZ;      // Do I need to include iSDRAMWriteRequest here??
assign dataIn     = ( chipSelectRAM ) ? dataBus    : 16'bZZZZZZZZZZZZZZZZ;      // Do I need to include ~iSDRAMWriteRequest here??

Question: If using dataBus for incoming and outgoing data, do I always need to provide a separate register for incoming and outgoing as I have done above?

[KhaiChein_Y_Intel]

Hi,

This link explains the cause of Error (13076)

https://www.intel.com/content/www/us/en/programmable/quartushelp/current/index.htm#msgs/msgs/emls_opt_tri_bus_multiple_drivers.htm

If it doesn't help, kindly share the design QAR for investigation. To create the QAR file, click on Project > Archive Project > Archive.

Thanks

Best regards,

KhaiY

[SparkyNZ]

Hi @KhaiChein_Y_Intel . I've just shared my project with @Kenny_Tan on my other post about the "due to conflicting nodes" error. It may be easier to see where I'm completely going wrong with that.. and perhaps you guys can work together so you don't solve the same problem twice. Sorry about that.

See here:

https://community.intel.com/t5/Intel-Quartus-Prime-Software/multiple-drivers-due-to-conflicting-nodes/m-p/1218868/highlight/false#M66674 

[KhaiChein_Y_Intel]

Hi,

The design failed synthesis stage with error below:

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

In the design dataH is connected to

dataH >iData (vgaController) > dataBus 

In SystemVerilogTest1.sv, dataBus receives input from ioData and dataOut. Here is where the conflict is. I tried to comment out Line142 and the compilation is successful.

Line 142: assign dataBus  = ( chipSelectRAM ) ? dataOut  : 16'bZZZZZZZZZZZZZZZZ;  

Line 180:  .ioData(     dataBus ),

Thanks

Best regards,

KhaiY

[SparkyNZ]

Hi @KhaiChein_Y_Intel . Thank you for looking into this. I still do not understand how dataH becomes connected to iData.

VGAController.sv only has the below line:

dataH = iDataCopy[ 15 : 8 ];

My understanding will be wrong, but I am thinking that dataH is driven by the iDataCopy registers. iDataCopy is fed by the dataIncoming registers. This would mean that iData and dataH are seperated by 2 registers:

dataH <-- iDataCopy <-- dataIncoming <-- iData (dataBus/ioData)

Can you please explain to me how iData is a multiple driver of dataH? If iData was connected directly to dataH, I could understand this.

Sorry, but there is something small and fundamental here that I am not seeing/understanding.

[SparkyNZ]

@KhaiChein_Y_Intel I have looked at the RTL Viewer (something I tend to avoid) and I can see why the compiler error has been created. However.. the iDataCopy and dataIncoming registers are missing!

According to my VGAController.sv file, there should be a chain of components like this:

a) dataH <-- iDataCopy <-- dataIncoming <-- iData

But what I see inside the RTL Viewer is this:
b) dataH <-- iData

Where did iDataCopy and dataIncoming go??

Has the compiler has optimized my design in such a way that it no longer works?? How can I ensure that my chain is synthesized as I expected it to be in (a) above?

[KhaiChein_Y_Intel]

Hi,

If you are using SystemVerilog HDL language, I would suggest you to use Pro edition of the Intel Quartus Prime software as Lite/Standard edition have limited language support (Ref: https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/po/ss-quartus-comparison.pdf)

Thanks

Best regards,

KhaiY

[KhaiChein_Y_Intel]

Hi,

We do not receive any response from you to the previous question/reply/answer that I have provided. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

Best regards,

KhaiY

[SparkyNZ]

Hi @KhaiChein_Y_Intel 

Thank you for the additional information. However, I'm afraid my question still has not been answered:

According to my VGAController.sv file, there should be a chain of components like this:

"a) dataH <-- iDataCopy <-- dataIncoming <-- iData

But what I see inside the RTL Viewer is this:
b) dataH <-- iData

Where did iDataCopy and dataIncoming go??

Has the compiler has optimized my design in such a way that it no longer works?? How can I ensure that my chain is synthesized as I expected it to be in (a) above?"

[KhaiChein_Y_Intel]

Hi,

I tried to compile the design in the Pro edition and the errors below occurred. These errors are not captured in the Standard edition where I believe this is due to the limited SystemVerilog language support in the Standard edition software. I will file a case to engineering team and report the inconsistent behavior between the two editions. Please upgrade the software to Pro edition as Standard edition has limited language support.

Error(13386): Verilog HDL Procedural Assignment error at SDRAMController8Bit.sv(1304): object "sd_D" on left-hand side of assignment must have a variable data type 

Error(13363): Verilog HDL error at SDRAMController8Bit.sv(1574): module "SDRAMController8Bit" ignored due to previous errors 

Error(17232): Verilog HDL error at VGAController.sv(142): variable dataIncoming is written by both continuous and procedural assignments 

Error(13363): Verilog HDL error at VGAController.sv(399): module "VGAController" ignored due to previous errors 

Thanks

Best regards,

KhaiY

[KhaiChein_Y_Intel]

Hi,

We do not receive any response from you to the previous question/reply/answer that I have provided. This thread will be transitioned to community support. If you have a new question, feel free to open a new thread to get the support from Intel experts. Otherwise, the community users will continue to help you on this thread. Thank you.

Best regards,

KhaiY

[SparkyNZ]

Hi @KhaiChein_Y_Intel . I cannot afford the Pro edition. So yes please, move to the community.