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?
corrupted data when accessing dual port bram in Cyclone II
Started by ●July 19, 2006
Reply by ●July 19, 20062006-07-19
> 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? >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
Reply by ●July 19, 20062006-07-19
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.
Reply by ●July 19, 20062006-07-19
On Wed, 19 Jul 2006, homoalteraiensis wrote: "[..] 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.
Reply by ●July 19, 20062006-07-19
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. "homoalteraiensis" <fpgaengineerfrankfurt@arcor.de> wrote in message news:1153303906.254358.157210@m79g2000cwm.googlegroups.com...>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? >
Reply by ●July 19, 20062006-07-19
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.
Reply by ●July 19, 20062006-07-19
homoalteraiensis wrote:> That is the point. Modelsim shows a well behavior. Nothing wrong.And the Quartus timing analysis shows no problems either I'm assuming.> The error only shows up in real and signal tap analysis.Then open a service request to Altera.> I already changed > the timing (slower). The only way to shun this problem is, to disallow > simultanous access, which in fact lowers performance.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
Reply by ●July 19, 20062006-07-19
homoalteraiensis wrote:> 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.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
Reply by ●July 20, 20062006-07-20
"homoalteraiensis" <fpgaengineerfrankfurt@arcor.de> wrote in message news:1153325559.258147.44130@p79g2000cwp.googlegroups.com...> > 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. >You're instinct is right, learning more about semaphores will be of no help in this particular situation.> 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. >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
Reply by ●July 20, 20062006-07-20
> > 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. >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