multi-source errors

Any help is appreciated. I get errors of the following sort:

"Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is connected to multiple drivers."

The source for the entire unit in question is as follows:

module tst_1(
input rst,
input clk,
output [7:0] led
);
parameter s_0 = 2'b00;
parameter s_1 = 2'b01;
parameter s_2 = 2'b10;
parameter s_3 = 2'b11;

reg [1:0] state;
reg [7:0] ram[0:15];
reg [7:0] regs[0:7];

initial begin
state <= s_0;
end

always @(posedge clk) begin
if (rst == 1'b1)
state <= s_0;
else begin
case (state)
s_0: begin
ram[15] <= 8'h00;
state <= s_1;
end
s_1: begin
regs[0] <= ~ram[8];
ram[15][0] <= 1'b1;
ram[15][1] <= 1'b0;
state <= s_2;
end
s_2: begin
ram[7] <= regs[0];
ram[15][2] <= ~regs[0][7];
ram[15][3] <= regs[0][3];
state <= s_3;
end
s_3: begin
ram[8] <= ram[7] ^ ram[15];
state <= s_1;
end
default:
state <= s_0;
endcase
end
end
assign led = regs[0];
endmodule

For the interested, I get multi-source errors on ram[15][3], ram[15][2], and ram[15][0]... but not ram[15][1]. Since the signals in question are all driven from different states within the same FSM, I am not sure why this is considered multiple drivers. I am sure this is something obvious to the well-informed. Any ideas?

 

[Gabor]

On 9/23/2012 2:44 AM, smileforthecamerahotshot@gmail.com wrote:

Any help is appreciated. I get errors of the following sort:

"Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is connected to multiple drivers."

The source for the entire unit in question is as follows:

module tst_1(
input rst,
input clk,
output [7:0] led
);
parameter s_0 = 2'b00;
parameter s_1 = 2'b01;
parameter s_2 = 2'b10;
parameter s_3 = 2'b11;

reg [1:0] state;
reg [7:0] ram[0:15];
reg [7:0] regs[0:7];

initial begin
state <= s_0;
end

always @(posedge clk) begin
if (rst == 1'b1)
state <= s_0;
else begin
case (state)
s_0: begin
ram[15] <= 8'h00;
state <= s_1;
end
s_1: begin
regs[0] <= ~ram[8];
ram[15][0] <= 1'b1;
ram[15][1] <= 1'b0;
state <= s_2;
end
s_2: begin
ram[7] <= regs[0];
ram[15][2] <= ~regs[0][7];
ram[15][3] <= regs[0][3];
state <= s_3;
end
s_3: begin
ram[8] <= ram[7] ^ ram[15];
state <= s_1;
end
default:
state <= s_0;
endcase
end
end
assign led = regs[0];
endmodule

For the interested, I get multi-source errors on ram[15][3], ram[15][2], and ram[15][0]... but not ram[15][1]. Since the signals in question are all driven from different states within the same FSM, I am not sure why this is considered multiple drivers. I am sure this is something obvious to the well-informed. Any ideas?

Perhaps ram[15][1] is never driven to a value other than zero and has

been "replaced by logic." What tools are you using, and what version?
I have seen a lot of bogus multi-source messages from Xilinx XST
especially when using arrays and loops. Theoretically any number
of assignments in the same process should never create a multi-source
error.

-- Gabor

 

[glen herrmannsfeldt]

smileforthecamerahotshot@gmail.com wrote:

Any help is appreciated. I get errors of the following sort:

"Multi-source in Unit <tst_1> on signal <ram<15><3>>; this
signal is connected to multiple drivers."

It isn't so obvious to me how to read this.

It seems that it should depend on what is available
as RAM resources.

The source for the entire unit in question is as follows:

module tst_1(
input rst,
input clk,
output [7:0] led
);
parameter s_0 = 2'b00;
parameter s_1 = 2'b01;
parameter s_2 = 2'b10;
parameter s_3 = 2'b11;

reg [1:0] state;
reg [7:0] ram[0:15];
reg [7:0] regs[0:7];

initial begin
state <= s_0;
end

always @(posedge clk) begin
if (rst == 1'b1)
state <= s_0;
else begin
case (state)
s_0: begin
ram[15] <= 8'h00;

OK, being inside the always @(posedge clk) this is a synchronous RAM.

Personally, I do like writing state machines with the state
logic inside, but some tell me that the state selection and
state action should be separate blocks. Normally I don't believe
the difference matters, but it isn't so obvious to me in the
case of ram.

state <= s_1;
end
s_1: begin
regs[0] <= ~ram[8];
ram[15][0] <= 1'b1;
ram[15][1] <= 1'b0;

Since only two bits of ram are being changed, this requires
either separate RAMs or separate write enable bits.

state <= s_2;
end
s_2: begin
ram[7] <= regs[0];
ram[15][2] <= ~regs[0][7];
ram[15][3] <= regs[0][3];

Now you change both ram[7] and ram[15] in the same state,
so it requires dual port write access. That is fine, but
is much less common than dual port read.

state <= s_3;
end
s_3: begin
ram[8] <= ram[7] ^ ram[15];

In this case, dual port read and separate write port at the same time.

state <= s_1;
end
default:
state <= s_0;
endcase
end
end
assign led = regs[0];
endmodule

Maybe it doesn't have anything to do with the problem, but are
you sure that the target architecture supports RAM with two read
and two write ports?

-- glen

 

On Sunday, September 23, 2012 5:58:45 PM UTC-7, Gabor wrote:

Any help is appreciated. I get errors of the following sort:



"Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is connected to multiple drivers."



The source for the entire unit in question is as follows:



module tst_1(

input rst,

input clk,

output [7:0] led

);

parameter s_0 = 2'b00;

parameter s_1 = 2'b01;

parameter s_2 = 2'b10;

parameter s_3 = 2'b11;



reg [1:0] state;

reg [7:0] ram[0:15];

reg [7:0] regs[0:7];



initial begin

state <= s_0;

end



always @(posedge clk) begin

if (rst == 1'b1)

state <= s_0;

else begin

case (state)

s_0: begin

ram[15] <= 8'h00;

state <= s_1;

end

s_1: begin

regs[0] <= ~ram[8];

ram[15][0] <= 1'b1;

ram[15][1] <= 1'b0;

state <= s_2;

end

s_2: begin

ram[7] <= regs[0];

ram[15][2] <= ~regs[0][7];

ram[15][3] <= regs[0][3];

state <= s_3;

end

s_3: begin

ram[8] <= ram[7] ^ ram[15];

state <= s_1;

end

default:

state <= s_0;

endcase

end

end

assign led = regs[0];

endmodule



For the interested, I get multi-source errors on ram[15][3], ram[15][2], and ram[15][0]... but not ram[15][1]. Since the signals in question are all driven from different states within the same FSM, I am not sure why this is considered multiple drivers. I am sure this is something obvious to the well-informed. Any ideas?



Perhaps ram[15][1] is never driven to a value other than zero and has

been "replaced by logic." What tools are you using, and what version?

I have seen a lot of bogus multi-source messages from Xilinx XST

especially when using arrays and loops. Theoretically any number

of assignments in the same process should never create a multi-source

error.



-- Gabor
I am using Xilinx ISE WebPACK v12.4 (nt64). I also tried this using ISE WebPACK 9.2i 32-bit and get the same errors. I have tried targeting an XC3S500E and an XC3S1600E. One thing that I noticed is that if I change the s_0 state to do this "ram[15][7:0] <= 8'h00;" instead of this "ram[15] <= 8'h00;" then I get no errors. I don't understand this.

 

[Gabor]

smileforthecamerahotshot@gmail.com wrote:

On Sunday, September 23, 2012 5:58:45 PM UTC-7, Gabor wrote:
Any help is appreciated. I get errors of the following sort:
"Multi-source in Unit <tst_1> on signal <ram<15><3>>; this signal is connected to multiple drivers."
The source for the entire unit in question is as follows:
[code snipped]
For the interested, I get multi-source errors on ram[15][3], ram[15][2], and ram[15][0]... but not ram[15][1]. Since the signals in question are all driven from different states within the same FSM, I am not sure why this is considered multiple drivers. I am sure this is something obvious to the well-informed. Any ideas?
Perhaps ram[15][1] is never driven to a value other than zero and has
been "replaced by logic." What tools are you using, and what version?
I have seen a lot of bogus multi-source messages from Xilinx XST
especially when using arrays and loops. Theoretically any number
of assignments in the same process should never create a multi-source
error.

-- Gabor
I am using Xilinx ISE WebPACK v12.4 (nt64). I also tried this using ISE WebPACK 9.2i 32-bit and get the same errors. I have tried targeting an XC3S500E and an XC3S1600E. One thing that I noticed is that if I change the s_0 state to do this "ram[15][7:0] <= 8'h00;" instead of this "ram[15] <= 8'h00;" then I get no errors. I don't understand this.

It looks like a bug, so you might want to try to use the "new"
parser in ISE 12.4 (or later) by adding the following to the
"other command line options" in the XST synthesis properties:

-use_new_parser yes

-- Gabor