ID:276027 Inferred dual-clock RAM node "<name>" from synchronous design logic. The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.

CAUSE: In a Verilog Design File (.v) or VHDL Design File (.vhd), you described a set of registers that behave as a RAM. Analysis & Synthesis replaced the registers with a RAM node. Later on, this RAM node will infer an instance of the altsyncram megafunction that will implement the functionality of the registers using the memory blocks in the target device. However, the RAM has different read and write clocks, or the read and write clocks have different enable conditions, making them effectively different. If you read and write to the same address simultaneously (a read-during-write), the read will return an undefined value, even though your design may require the read-during-write to return either the old data or the newly written data. When the read and write clocks are identical, Analysis & Synthesis configures the RAM to match the behavior of the design and, in some cases, adds bypass logic when the RAM does not natively support the read-during-write behavior. When the read and write clocks are different, Analysis & Synthesis cannot configure the RAM with a specific read-during-write behavior or add bypass logic, so the read-during-write behavior of the RAM may not match the read-during-write behavior of your original design. In most designs, there is no real mismatch. For example, a FIFO between two asynchronous (unrelated) clock domains has no definite read-during-write behavior. In fact, a read-during-write should never occur. There are, however, a few unique cases with a real mismatch. Analysis & Synthesis cannot distinguish these unusual cases from the more common cases, so you should evaluate your design for any potential mismatch. A real mismatch may occur if your design continuously reads from the array that models the RAM in the HDL, as illustrated by the following Verilog example

module dual_clock_ram
(
	input rclk, wclk, we,
	input [7:0] data, input [5:0] raddr, waddr,
 	output [7:0] q
);
   reg [5:0] raddr_reg;
   reg [7:0] ram[0:63];
   always@(posedge wclk)
	 begin
		if(we) ram[waddr] <= data;
	 end
   always@(posedge rclk)
	 begin
		raddr_reg <= raddr;
	 end
   assign q = ram[raddr_reg];
endmodule

               

In this example, a read-during-write or a read that closely follows a write should return the newly written data. When implemented in a memory block in the target device, the write cycle is not complete before the read begins. Consequently, the dual-clock inferred by Analysis & Synthesis requires two read cycles to access the correct data at the memory location. A mismatch may also occur if the read and write clocks derive from the same clock source. For example, you connected the pins that feed the read and write clocks to the same clock source on your board, or you created a design partition that make the clocks appear distinct to Analysis & Synthesis. That is, they are ports on the design partition boundary but they are fed by the same source in the parent partition. In simulation, the RAM has a specific read-during-write behavior that will not be matched by the implementation in the memory blocks of the target device.