Errors reading M9K dual port in Cyclone III

[Altera_Forum]

Hi, 

We are using four Megawizard generated dual ports in a 3C40F484C8. There are 128 locations, 24 bits wide, asynchronous write and read clocks. A common write_data and write_address bus goes to all four dual ports. Logic provides 2 pages to ensure a location does not get read and written to at the same time. One side is written to in a burst at 120MHz, and data read out continually at 12MHz. We experience occasional errors in the read data, worse when the device is cold, but above 0 degrees C, always bit20 or bit21 read high when it should be low. The read errors only occur when the write data bus is active, as if there is some crosstalk between write and read data busses. Some builds exhibit the problem, some don't, although changes to the source code (VHDL) between builds are seemingly unconnected with the dual ports.  Some other info,  The errors only occur at a particular phase relationship between the write and read clocks. Quartus simulation does not show the error. Timing analysis passes. I have replicated the problem on the Altera Cyclone evaluation board (3C25), although only below 0 degrees C.  If we use LE's instead of M9K as memory the problem does not occur, but that uses a lot of LE's! Core voltage is fine, also ran it from bench PSU and it still fails.  Assuming there is no problem with the silicon, I wonder if I've hit a combination of device/design that highlights a weakness in the Quartus synthesis/fitting process.  I would be interested to hear if anybody else seen anything similar, or could shed any light on this,  Thanks

[Altera_Forum]

Can you SignalTap it and capture addresses and data in and out? How do you know it's the memory and not something elsewhere. 

If it occurs when cold, it might be a hold violation. Where do your read and write clocks come from? Are you sure the data in and control is clocked on the write domain while the read data is clocked back into the read domain? (If you're not analyzing between the domains because they're asynchronous, then clocking something in the wrong domain wouldn't show up static timing analysis)

[Altera_Forum]

Hi, thanks for your reply. I do have SignalTap on write and read signals, although adding SignalTap to the read side quite often stops the error from occurring. When it does fail with SignalTap attached I can see the dual port read data corrupted. The read and write clocks are from 2 independent oscillators. I'm confident that the two sides of the memory use the two clocks correctly. It's the fact that the error occurs when the write data is active that concerns me, although I guess there could be some marginal timing on the read side that gets pushed into failing by some write side noise. 

 Thanks again for your reply, any other thoughts gratefully received,  Regards,

[Altera_Forum]

--- Quote Start ---  adding SignalTap to the read side quite often stops the error from occurring  --- Quote End ---   is indicating timing problems, usually.

[Altera_Forum]

With SignalTap, are you opening Assignments -> Partition Window and setting the top-level partition to Post-Fit Placement and Routing? Then in SignalTap only tap Post-Fit nodes. This way the place-and-route doesn't change and hopefully the problem stays the same as you tap different nodes. (You may already be doing this, but if it goes away when tapping then you may not). Plus you get faster SignalTap compiles.  

Are the oscillators going through PLLs? If you re-read the same location(if possible), does it give different values?

[Altera_Forum]

No. I'm not doing that with Signal Tap, I re-run Quartus. This is half the problem really, adding a signal into SignalTap and the performance changes, so this is a good tip, thanks.  

Perhaps the problem here is hold timing? The problem gets worse at lower temperatures, which suggests hold timing, and although the clock in the read domain is only 12MHz, hold timing is essentially independent of clock frequency. However the system is really very simple and passes timing analysis, both Classic and Timequest. It also does not fail if the memory is made of logic. Thanks for any input,  Regards

[Altera_Forum]

Can you post the exact MW options you used to instantiate the M9K block in your design? If possible please attach the HDL code of the instantiation.

[Altera_Forum]

Hi,  

The memory is instantiated like this  -----RAM 1---------------------------------------------------------------------  tx_mezz_ram_1 : tx_mezz_ram port map(  wrclock => mezz_rx_clk_pll_out,  wraddress => write_addr,  data => write_data,  wren => wren,  rdclock => transmit_clock,  rdaddress => read_addr,  q => read_data0 );  The Megawizard vhd file is attached,  Regards

[Altera_Forum]

I noticed your RAM is using an enable signal. Altera has discovered a problem with the Quartus 9.0 timing analysis of the M9K in CIII involving enable signals. Here's the solution id /rd04302009_15. There's a script you can run to diagnose if your design is at risk for the missing enable path in the Quartus timing analysis.

[Altera_Forum]

Hi, I have not worked much with running scripts. Can someone give a quick explanation of how to run the script described in the solution id /rd04302009_15 that was mentioned above? 

 Thanks