Targeting a Cyclone V SoC device, I have a lot of inferred RAM in my design. Most of them are simple single clock dual-port RAM. In the Timing Analysis there are paths from a PORT_B_WRITE_ENABLE_REG to the outputs of the RAM. The RAM has no write on port B, and the "no_rw_check" attribute is set. Indeed, if you locate the path in the Technology Map viewer, it simply shows the RAM output path. Additionally there are no setup paths found by the analyser -to PORT_B_WRITE_ENABLE_REG, only -from.
What exactly are these paths? They are causing some timing issues in part of the design. With "no_rw_check" attribute set, I would expect there to be no bypass path, which is confirmed by looking at the Technology Map viewer, so the output should in no way be dependent on any write enable signal on either port, let alone one that doesn't exist!
链接已复制
Please find attached an example RAM summary, one of which there exists this path.
I think it is because of setting of new data for read-during-write in the same port. It could not be changed anyhow. Try to register at output port where it would help the timing. Also, CV M10K performance spec can be referred to this datasheet https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/cyclone-v/cv_51002.pdf, Table 33, pg44.
That would make sense because of the naming, however it is a simple dual-port RAM, so there is no "new data" on port B, and I would assume that the write enable on port B would be tied low?
So I guess I can cut those paths? It may help with timing throughout the design. I am concerned that when you try to locate the path in the Technology Map Viewer, it highlights the data output path, which obviously I don't want to cut!
You should instantiate RAM block through IP catalog. If using that , you would see what those options or parameters in GUI can be changed. Please see RTL below that I retrieved from generated dual-port RAM :
//Example of 8 bit width RAM
altsyncram altsyncram_component (
.address_a (address_a),
.address_b (address_b),
.clock0 (clock),
.data_a (data_a),
.data_b (data_b),
.wren_a (wren_a),
.wren_b (wren_b),
.q_a (sub_wire0),
.q_b (sub_wire1),
.aclr0 (1'b0),
.aclr1 (1'b0),
.addressstall_a (1'b0),
.addressstall_b (1'b0),
.byteena_a (1'b1),
.byteena_b (1'b1),
.clock1 (1'b1),
.clocken0 (1'b1),
.clocken1 (1'b1),
.clocken2 (1'b1),
.clocken3 (1'b1),
.eccstatus (),
.rden_a (1'b1),
.rden_b (1'b1));
defparam
altsyncram_component.address_reg_b = "CLOCK0",
altsyncram_component.clock_enable_input_a = "BYPASS",
altsyncram_component.clock_enable_input_b = "BYPASS",
altsyncram_component.clock_enable_output_a = "BYPASS",
altsyncram_component.clock_enable_output_b = "BYPASS",
altsyncram_component.indata_reg_b = "CLOCK0",
altsyncram_component.intended_device_family = "Cyclone V",
altsyncram_component.lpm_type = "altsyncram",
altsyncram_component.numwords_a = 32,
altsyncram_component.numwords_b = 32,
altsyncram_component.operation_mode = "BIDIR_DUAL_PORT",
altsyncram_component.outdata_aclr_a = "NONE",
altsyncram_component.outdata_aclr_b = "NONE",
altsyncram_component.outdata_reg_a = "CLOCK0",
altsyncram_component.outdata_reg_b = "CLOCK0",
altsyncram_component.power_up_uninitialized = "FALSE",
altsyncram_component.ram_block_type = "M10K",
altsyncram_component.read_during_write_mode_mixed_ports = "DONT_CARE",
altsyncram_component.read_during_write_mode_port_a = "NEW_DATA_NO_NBE_READ",
altsyncram_component.read_during_write_mode_port_b = "NEW_DATA_NO_NBE_READ",
altsyncram_component.widthad_a = 5,
altsyncram_component.widthad_b = 5,
altsyncram_component.width_a = 8,
altsyncram_component.width_b = 8,
altsyncram_component.width_byteena_a = 1,
altsyncram_component.width_byteena_b = 1,
altsyncram_component.wrcontrol_wraddress_reg_b = "CLOCK0";
*************************************
What clock frequency are you using for that RAM? Can put your inferred RAM here?
