True DPRAM IP

[Altera_Forum]

Hi 

I need a true dual port RAM with 2 read and write accesses for a Stratix 4 device; With the MegaWizard this is in fact very easy but while trying to simulate with ModelSim I see a few issues: 1) Write cycles: While writing several cycles in a row, on the 'A' side, the cycle which follows (which WREN = '0') still causes the simulation environment to write erroneous data. It actually writes the data which is on the D_IN bus. This is confirmed by reading it from the other side (the 'B' side) the data is there. Does anybody have an idea?  2)Number of clock cycles: It seems that at least 2 cycles are required for a read operation (or 1 if there's a pipeline behind in case of continuous operation) and 1 cycle for write operation is enough. Is there a consistent documentation for this case with timing diagrams, I have the Internal ROM RAM User Guide but there is nothing clear there.  Thanks in advance for your help  Kind regards Thomas

[Altera_Forum]

Hi Thomas, 

   --- Quote Start ---   I need a true dual port RAM with 2 read and write accesses for a Stratix 4 device; With the MegaWizard this is in fact very easy but while trying to simulate with ModelSim I see a few issues: 1) Write cycles: While writing several cycles in a row, on the 'A' side, the cycle which follows (which WREN = '0') still causes the simulation environment to write erroneous data. It actually writes the data which is on the D_IN bus. This is confirmed by reading it from the other side (the 'B' side) the data is there. Does anybody have an idea?  2)Number of clock cycles: It seems that at least 2 cycles are required for a read operation (or 1 if there's a pipeline behind in case of continuous operation) and 1 cycle for write operation is enough. Is there a consistent documentation for this case with timing diagrams, I have the Internal ROM RAM User Guide but there is nothing clear there.   --- Quote End ---    I've used dual-port RAM on Stratix IV devices. I've never seen problems.  I suspect your write-enable timing is probably the source of your problem.   If you could post a simple testbench, with just an altsyncram component and your test sequence, then I'll take a look at the code.  Cheers, Dave

[Altera_Forum]

Hi Dave! 

Thanks for your fast reply. I really appreciate. I've been using DPRAMs a lot, it always worked very well. Actually, it might be a simulation problem, but not sure. Please find here attached a ZIP with: -- MegaWizard DPRAM -- Test bench -- Stimulus pattern (from text file) As seen in the stimulus, the sequence is as follows: 1) Write something to address 0, do this twice, I know that the first write cycle is not valid 2) write some addresses in a row 3) switch to read and set input data to a different pattern 4) perform some read operations and read back the address of the first read operation which has been written by erroneous data  There's also a ModelSim screenshot  Thanks in advance for your expertise!  Kind regards Thomas

[Altera_Forum]

Hi Dave, again me 

I forgot to mention that the functional simulation is ok, only the Gate Level simulation is affected.  Nice day to you. K.r. Thomas

[Altera_Forum]

Hi Thomas, 

 Here's a testbench that you can use as a reference to test the gate level simulation.   Altera altsyncram dual-port RAM testbench ----------------------------------------- 5/2/2012 D. W. Hawkins (dwh@ovro.caltech.edu) 1. Start Modelsim 2. Change directory to the source folder 3. Type 'source sim.tcl' in the Modelsim console 4. The wave window will show the waveforms, and the console will output the following messages: # ==============================================================================# Altera dual-port RAM testbench# ==============================================================================# # ------------------------------------------------------------------------------# Test# 1: Fill the RAM# ------------------------------------------------------------------------------# 1000 ns: Fill 128 locations of the RAM with a count pattern using port A# # ------------------------------------------------------------------------------# Test# 2: Check the RAM using port A# ------------------------------------------------------------------------------# 3028 ns: Check 128 locations of the RAM match the expected count pattern# 4076 ns: All checks passed ok!# # ------------------------------------------------------------------------------# Test# 3: Check the RAM using port B# ------------------------------------------------------------------------------# 5076 ns: Check 128 locations of the RAM match the expected count pattern# 7690 ns: All checks passed ok!# # ------------------------------------------------------------------------------# Simulation Completed!# ------------------------------------------------------------------------------   Perhaps this will help in determining the source of your problem.  Cheers, Dave

[Altera_Forum]

It looks like the gatelevel model erroneously registers WREN_A. I guess, it's a defective model and the real hardware will behave as expected.

[Altera_Forum]

Dear all 

Thanks for your kind help and advices. I decided to give a quick try with a specific embedded test design and a SignalTap. I believe that this will give a clear idea and that there's clearly a possible gatelevel registering of the WREN. I will let you know with consistent data asap.  Nice day to all of you! K.r. Thomas

[Altera_Forum]

Dear all 

As all of us could have guessed, implementing this true DPRAM design implemented in FPGA and monitored with a SignalTap works perfectly. You can check the screen shot here attached, all ok. A state machine performs  1. Read cycle to an address 2. Write cycle to the same address with new data 3. Read back of the new data For an easier reading only lower sections of address and data buses are shown. With an appropriate SignalTap clock rate one can almost get information on access time.  Thanks for having accompanied me till here. I will now log a service request in MySupport to check out Altera's position on that. Cause all this is used in a more complex system of coarse and I will need to gate level simulate all this.  Bye and looking forwards to talking to you soon. Thomas

[Altera_Forum]

--- Quote Start ---   implementing this true DPRAM design implemented in FPGA and monitored with a SignalTap works perfectly.   --- Quote End ---    Great!    --- Quote Start ---   I will now log a service request in MySupport to check out Altera's position on that.   --- Quote End ---    Before you do, make sure to test the gate level simulation using the latest edition of the Quartus tools. You will not get any support for old tools. Your megawizard instance was generated using 10.1. Try again using 11.1sp1 or 11.1sp2.    --- Quote Start ---   Cause all this is used in a more complex system of coarse and I will need to gate level simulate all this.   --- Quote End ---    Why? If your functionality is correct with an RTL simulation, and synthesis meetings timing (no errors from TimeQuest), then you do not need a gate level simulation. You really only need that to track down issues with the hardware being inconsistent with the RTL simulation, i.e., a SignalTap II trace that is inconsistent with the RTL trace. I very rarely need to use a gate level simulation (its too slow, and why bother when the hardware is right next to me).  Cheers, Dave

[Altera_Forum]

Hi Dave 

 Actually I felt confident that a true implementation would be ok. It's not the first time I use DPRAM but rather more the first time I wanted to include it it a simulation environment.  Initially we started the design on 11.1 SP2, then, for the documentation purposes of the issue I switched to an other computer with 10.1, the issue is strictly the same/  Regarding simulation it isn't always that straightforward as you state. We always prepare for simulation regardless if the timing analysis is good or not. My flow is with RTL Precision from Mentor and the project is a SOC emulation. With the constraints given there, the SDC generation is much more User friendly and the result always ok. So there is debug and sometimes simulation if something goes wrong for an easier monitoring of the signals. As you know SignalTap is nice but somehow intrusive and you need to re-compile whenever you forgot a signal to monitor, this is not in line with productivity constraints.  To conclude, I suspect an erroneous model. Doing the RTL simulation with the VHO is ok, switching to gate level it goes out of tracks. Should be easy to correct for ALTERA. K.r. Thomas

[Altera_Forum]

Hi Thomas, 

  --- Quote Start ---   Regarding simulation it isn't always that straightforward as you state. We always prepare for simulation regardless if the timing analysis is good or not. My flow is with RTL Precision from Mentor and the project is a SOC emulation. With the constraints given there, the SDC generation is much more User friendly and the result always ok. So there is debug and sometimes simulation if something goes wrong for an easier monitoring of the signals. As you know SignalTap is nice but somehow intrusive and you need to re-compile whenever you forgot a signal to monitor, this is not in line with productivity constraints.   --- Quote End ---  Thanks for your comments on how you use the tools. Its always interesting to hear how others use these tools.    --- Quote Start ---   To conclude, I suspect an erroneous model. Doing the RTL simulation with the VHO is ok, switching to gate level it goes out of tracks. Should be easy to correct for ALTERA.   --- Quote End ---  Did you file an Altera Service Request?  I'd recommend filing an SR, along with a simple design that can be synthesized, and then simulated with a common testbench/testcase generator. If you can take the work out of reproducing the problem, then the SR guys are pretty good about queuing up a software fix.  Cheers, Dave

[Altera_Forum]

Hi Dave 

 Thank you discussing this with me, I really appreciate. Yes I filed a SR and I gave as many info and files as I could, so reproducing the issue will be quite easy for them.  I'll keep you informed on the outcome.  Kind regards Thomas