corrupted data when accessing dual port bram in Cyclone II

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I am having several dual port block rams in a cyclone II device. The
access takes place as simple dual port option with only one clock for
the bram but sometimes a write, when a read is done simultaneously. I
expexted the old data to appear at the output as demanded, when I
defined the brams from within the altera megafunction wizzard.

I know about the possible bugs, when using two different clocks, as
described in an altera technical announcement, therefore I use only one
system clock for the rams.

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?


Re: corrupted data when accessing dual port bram in Cyclone II
Quoted text here. Click to load it

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



Re: corrupted data when accessing dual port bram in Cyclone II
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.


Re: corrupted data when accessing dual port bram in Cyclone II
Quoted text here. Click to load it

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

Quoted text here. Click to load it

Then open a service request to Altera.

Quoted text here. Click to load it

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


Re: corrupted data when accessing dual port bram in Cyclone II

"[..]

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.

Re: corrupted data when accessing dual port bram in Cyclone II
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.

Quoted text here. Click to load it



Re: corrupted data when accessing dual port bram in Cyclone II

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.


Re: corrupted data when accessing dual port bram in Cyclone II
Quoted text here. Click to load it

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



Re: corrupted data when accessing dual port bram in Cyclone II

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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



Re: corrupted data when accessing dual port bram in Cyclone II
Quoted text here. Click to load it

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:
http://www.altera.com/literature/hb/qts/qts_qii53004.pdf
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:
http://www.altera.com/literature/hb/qts/qts_qii53018.pdf

-David Karchmer
 Altera


Re: corrupted data when accessing dual port bram in Cyclone II
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.


Site Timeline