corrupted data when accessing dual port bram in Cyclone II

Did you run a simulation (If not, then you should)? Do the actual results match the simulation results? (If they do then debug the problem in the simulation environment first)

KJ

That is the point. Modelsim shows a well behavior. Nothing wrong. The error only shows up in real and signal tap analysis. I already changed the timing (slower). The only way to shun this problem is, to disallow simultanous access, which in fact lowers performance.

"[..]

I observe corrupted data though! :-( It obviously is caused when the reading and writing processes access the same time. I am sure that I contraint "old data" and varified this in the vhdl-definitions created be the wizzard.

Ideas?"

Learn about semaphores, or even better in Ada: protected objects.

I recommend that you first upgrade to 6.0 SP1. If that does not fix your problem, contact the help desk at mysupport.altera.com. We will need your design and vectors to debug this case. The other things that I would look at is to make sure this design has the right set of timing constraints so that the fitter can implment the desired timing relationships.

Hope this helps, Subroto Datta Altera Corp.

1) "Learn about semaphores"

I know about semaphores, but according to my understanding it is a feature of a dp ram to be accessed the same time from both sides. If I'd implement a semaphore based access, there would be no need to use a dual ported ram, would it? The data that appears is totally wrong, having nothing to do with old data, as expected.

Anyway, I''ll camoe back to this issue later.

2) "Upgrade to 6.0 SP1"

Thanks, yes, I am with 6 SP1 now but the same experience. I also think, that it is a matter of physical timing. I will do a back annotation sim on order to find out.

And the Quartus timing analysis shows no problems either I'm assuming.

Then open a service request to Altera.

Or go to Altera to find out what the issue is, and if there are any work arounds.

I haven't used Cyclone but I've used Stratix and Stratix II dual port memories extensively with a single clock without any issues.

KJ

In cases like this, it can help to look at the corruption.

It is unlikely to "having nothing to do with old data, as expected". eg try gray code style old/new changes, and see if the corruption ever goes outside the changed bit(s).

The failure rate (how many ppm?) can also help give clues to the failure mechanism.

-jg

You're instinct is right, learning more about semaphores will be of no help in this particular situation.

Timing sim runs don't always catch things either. If it's a timing problem then static timing analysis is what you need to solve the problem. Quartus is already providing that info, but since you said you tried running it slower (not sure how slow or if it was slow enough per the static timing analysis) so it might not be a timing problem either which would then leave it as some form of Quartus bug which is why submitting a bug report to Altera would help.

KJ

As KJ writes, running static timing analysis is the best way to check for timing issues. Running the clock slower won't help you if you have a "Hold" violation, so you really want to make sure your design is fully constraint (Consider using the "Timing Constraint Checker" from the "Process | Start | Start Timing Constraint Check"), and then review the Timing Analysis Report, specially the Hold panels. If you see paths with Hold Slacks under 200ps, check if such paths are between different clocks (even if clocks are in phase). Unless you added some amount of Clock Uncertainty, you may be ignoring Jitter effects. If the clocks are different, you may also be seing some small error due to on-die variation, which is not modeled (which is why you should always add clock uncertainty on paths between different clocks). For more information, check:

or if you have the V6.0 full edition and you have some experience with SDC, you can also give the new TimeQuest Timing Analyzer a try:

-David Karchmer Altera

Thanks to all so far. As mentined , I am busy with other parts of the design to go deeper into that at the moment. TimeQuestAnalyzer will be the next step.