05-24-2017 09:14 AM
Hi,I had used altsyncram for writing into first port and reading from the second port in a DUAL_PORT mode. Everything seems to be working in the simulation and in the hardware. Now the design changes demand writing data into PortA, and ability to read simultaneously from PortA and from PortB. I modified the altsyncram configuration to make it BIDIR_DUAL_PORT with the following instance usage altsyncram# ( .address_aclr_b ("CLEAR0" ), .intended_device_family ("Stratix V" ), .lpm_type ("altsyncram" ), .numwords_a (DATA_DEPTH ), .numwords_b (DATA_DEPTH ), .operation_mode ("BIDIR_DUAL_PORT" ), // Single Port Access .outdata_aclr_b ("CLEAR0" ), .power_up_uninitialized ("TRUE" ), .ram_block_type ("M20K" ), .read_during_write_mode_mixed_ports ("OLD_DATA"), .widthad_a (ADDR_WIDTH ), .widthad_b (ADDR_WIDTH ), .width_a (1 ), .width_b (1 ), .width_byteena_a (1 ) ) altsyncm20k_mask (.aclr0 (1'b0 ), .address_a (maskindex_ff), .clock0 (clk ), .data_a (maskin_ff), .wren_a (wr_ff), .address_b (cam_index_ff), .aclr1 (1'b0 ), .addressstall_a (1'b0 ), .addressstall_b (1'b0 ), .byteena_a (1'b1 ), .byteena_b (1'b1 ), .clock1 (clk ), .clocken0 (1'b1 ), .clocken1 (1'b1 ), .clocken2 (1'b1 ), .clocken3 (1'b1 ), .data_b (1'b0 ), .eccstatus ( ), .q_a (maskstatusoutHost ), .q_b (maskstatusouttbt), .rden_a (lookupdirect_ff&~wr_ff), .rden_b (cam_match_ff&lookuptbt_ff), .wren_b (1'b0 ) ); Surprisingly the simulation gives valid reads from both the ports, but in hardware the readdata from PortB isnt valid, but readvalue from PortA is correct. 1) What could be the reason why read on PortB fails in hardware. I went through the https://www.altera.com/ja_jp/pdfs/literature/ug/ug_ram_rom.pdf, but couldnt make out any mistakes. 2) Whats the difference between altsyncram and altdpram(UseCase) ?. References: FPGA Used: StratixV ADDR_WIDTH:11 DATA_DEPTH:2048 Thanks in advance Jeebu Jacob Thomas
05-30-2017 02:58 PM
Since your simulation is working, it's hard to tell.Did you re-configure the memory block in source code or with the GUI? (I'd recommend the latter) Have you checked warning messages from the compilation flow? Have you checked the timing closure? Have you tried in-circuit debug? What do you mean by invalid data? Is the data a few cycles late or completely incorrect? Is it invalid all the time or only with simultaneous access? Is it toggling? Do you have built-in memory test?
05-31-2017 04:24 AM
Hi Maximov,Thanks a lot for ur reply Answers inline to your questions below 1) Did you re-configure the memory block in source code or with the GUI? (I'd recommend the latter)? I just used the instance in source code, and did not use GUI. What difference does it make? 2) Have you checked warning messages from the compilation flow? Yes, couldnt find anything suspicious. Since you have pointed this out. I ll scrutinize again and confirm :) 3) Is Timing Closure done? Yes. Timing closure is done, and there are no negative slacks. 4)Have you tried in-circuit debug? No, In-Circuit debugging seems to be the last debugging option for me, as it takes time to set up. So I m investing time right now to find obvious bugs/mistakes. 5) What do you mean by invalid data? Invalid Data means data which is not expected. In my case, all data is coming to be zero. My read case is continuous 16 addresses, and all the read data has value 0. 6) Do you have built-in memory test? No, i ve not explored one yet. Is it available for altsyncram?. Thanks again Jeebu
05-31-2017 09:00 AM
Hi.If you're reading all zero - I'd assume the memory port is not connected properly. But you should have seen something in the compilation log. At the moment I can only suggest the following: 1. configure a memory unit with megawizard/IP catalog and instantiate it. There is a bunch of parameters hidden in comments that might affect the result. Try AUTO instead of M20K just as an experiment. 2. check the post-fitting technology map viewer to see if your read data net is connected properly, as well as all the other signals for B-port (clock, enables etc). 3. In-circuit debug is not hard at all and definitely faster than expecting another reply from my time-zone :) I don't think memory BIST is available in the core, I asked if you have it in your RTL (just in case).