Forum Discussion
Altera_Forum
Honored Contributor
10 years agoError (10028): Can't resolve multiple constant drivers for net <name> at <??>
All, Here is one of my Verilog trial-learning code:
==============================================================// Verilog learning example
module SRAM_Read_Write_Sync ( nrst, Writeclk, Readclk, EQ, write_addr, read_addr);
input nrst, Writeclk, Readclk;
output EQ, write_addr, read_addr;
// Declare the address counters as 9-bit counters
reg write_addr;
reg read_addr;
reg EQ;
// reset address to 0 if NRST goes LO
always @ (negedge nrst)
begin
write_addr = 0;
read_addr = 0;
end
// increment Write address
always @ (posedge Writeclk)
begin
write_addr = write_addr + 1;
end
// increment Read address
always @ (posedge Readclk)
begin
read_addr = read_addr + 1;
if (read_addr == write_addr)
EQ = 1'b1;
else
EQ = 1'b0;
end
endmodule
================================================================== All, (the text in RED) when I try to use the negative edge of my nrst as a reset for my address counters I get the Error (10028): Can't resolve multiple constant drivers for net "read_addr[3]" at SRAM_Read_Write_Sync.v(26) If I remove the RED code it compiles fine. How should I implement a nrst signal that take precedence over any other signals that reset the address counters? Thanks, Keith13 Replies
- Altera_Forum
Honored Contributor
if you have a clock, the the only thing that should be in the sensitivity list (inside the brackets of the always) are the Readclk and nrst. You only care what happens on the clock edge, hence you dont want anything else. If you are trying to do logic with the clock, you are going to fail as this wont be possible in an FPGA. at the top level you should have:
always @(posedge Readclk or negedge nrst) begin if(~nrst) begin // asynchronous reset goes here else begin // this is for synchronous logic end // NOTHING ELSE HERE end - Altera_Forum
Honored Contributor
OK Thanks Tricky, I'll concentrate on this approach!! If I can't get the hang of it I will go back to schematic entry just so that i can get the design done and out the door.
Thanks again, Keith - Altera_Forum
Honored Contributor
--- Quote Start --- Comparing both addresses asynchronously is potentially worse than in a clock domain as it will be very glitchy, especially as you're using a count and not a grey code. --- Quote End --- Of course you're right, Tricky. I was just trying to solve one problem at a time. I was not going to get into safe clock domain crossing.