Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Announcements
The Intel sign-in experience has changed to support enhanced security controls. If you sign in, click here for more information.
19982 Discussions

Timing paths from PORT_B_WRITE_ENABLE_REG to an inferred simple dual-port RAM output - why does this path exist?

JWils26
Beginner
1,170 Views

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!

0 Kudos
8 Replies
GuaBin_N_Intel
Employee
834 Views

Before commenting any, can share the RAM implementation details in Fitter report > Resource Section > RAM Summary?

JWils26
Beginner
834 Views

Please find attached an example RAM summary, one of which there exists this path.

GuaBin_N_Intel
Employee
834 Views

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.

JWils26
Beginner
834 Views

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?

GuaBin_N_Intel
Employee
834 Views

@JWils26​ You may be correct that it is tied to low since it is unused

JWils26
Beginner
834 Views

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!

JWils26
Beginner
834 Views

Also, how do you define the read during write behaviour on the same port? The sythesis ramstyle attribute only seems to affect the mixed port relationship.

GuaBin_N_Intel
Employee
834 Views

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?

Reply