- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can this controller provide max throughput that the DDR2 device can allow?
Or maybe more appropriately stated: what is the max throughput of the HPCII controller for DDR2 devices. Talking logically and not w.r.t. meeting timing. Maybe a bit of a vague question(s) and I would be happy to elaborate. I will be writing my own Avalon-MM local_ side logic so I can do whatever it required there. Presumably I would use bursting to the full extent. Presumably I would see the local_ready signal toggle if I try to go too fast(right?) but if I was just hammering on this interface then how often would that be? I think I can only issue one command to the controller every 2nd phy-clk cycle but if we are bursting with length 4 then this should not limit and possibly this would mean I might never see local_ready toggle - right? Generally, accesses are expected to be bursts of transfers of data between the DDR and some on-chip memory. Controller is currently operated full rate and memory is 32 bits wide. Timing diagrams would be helpful as the ones in the HPCII user's guide are quite simple and never show the local_ready signal toggling - maybe because there is only a few transfers in the diagram. Thank-you.Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I'm getting around 97% efficiency out of it. To max out the throughput you have to sequentially access it. If you randomly access it I think I was seeing an efficiency between 33-40% (I forget off the top of my head).
These documents should have some pointers of what to do: http://www.altera.com/literature/hb/nios2/edh_ed51007.pdf http://www.altera.com/literature/hb/nios2/edh_ed51008.pdf- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I would be happy to solicit any questions to help move this thread along.
Regards.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Oops! One minute between my last post and that of BadOmen's - sorry.
Thanks very much for the reply. Will review your post.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank-you for the reply, BadOmen.
I guess the key comment in one of the attached is: >>>>Because DDR SDRAM memories incur a penalty when switching banks or rows, >>>>performance improves when they are accessed sequentially using bursts. Your comments were: >>>>I'm getting around 97% efficiency out of it. To max out the throughput you have to >>>>sequentially access it. If you randomly access it I think I was seeing an efficiency >>>>between 33-40% (I forget off the top of my head). So, would that mean that 97% is worst case read or write using sequential accesses using bursts? So, would that mean that you are at 97% and not 100% only because of throughput degradation when eventually switching banks or rows(once at the end of a row say) and it is only at this point that we see the local_ready signal toggle? Else where does this degrade from 100% and under what circumstances would we see the local_ready signal toggle? I will code something up shortly to test. Thanks again.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
97% means that is the best case efficiency of the memory for my system. There are penalties like refresh cycles, initial read latency, etc... So 97% means that for every 100 clock cycles that read/write were asserted only three of those cycles had waitrequest asserted (local_ready = 0). I was using a local burst count of 2 but the HP2 controller has the option to make the local port non-bursting. If you provide a bunch of back to back sequential accesses the controller will bundle them into a single burst to provide to the PHY. Once you disable the bursting you can use arbitration share to make sure the arbiter doesn't let in other masters if a master is already performing a bunch of non-bursting accesses. You'll never truly hit 100% efficiency with SDRAM over a substantial period of time since there are always overhead command cycles that prevent data from being moved.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks! :)

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page