[Oberon] SDRAM performance

D EMARD vordah at gmail.com
Fri Nov 15 06:58:32 CET 2019


Yes all they are all discussing problem in good direction.

In practical design there's often a trade off between
price of chips, how many GB and GHz will we get out
and how difficult is to design everything to fit together.

So for example one can write the core to utilize all of the burst and
bank switch capabilities of RAM to get speedup up to the
last ns of what chip can provide, but the driver core would be complex
and it may not like to run at high clock. Or, a very simple
core can run at high clock but is missing burst support and
can't do video. Good design is somewhere inbteween

and if I understood oberon's principles it should be to
make a smallest readable code that works GoodEnough.
Some complexity can be added later if in practice appears
neccessary.


On 11/15/19, Skulski, Wojciech <skulski at pas.rochester.edu> wrote:
> All:
>
> It will be good to know how fast is SDRAM in practice. I googled for "sdram
> access time". I found lots of generic discussions where I could learn all
> the theory and few conclusions. I also found a few practical estimates. Here
> are the most relevant finds for the record.
>
> 1. Good online discussion.
>
> http://forum.gadgetfactory.net/topic/1934-sdram-controller-with-consistent-access-time/
> There is a long discussion full of many interesting details, simulations,
> and corner cases. A good read. At the end of the discussion Matthew Hagerty
> concluded: "My design lets me read or write a word (16-bits in this case)
> every 70ns."
>
> So 70 ns is the number I want to remember for a random fetch or store. Block
> reads are a different matter which is more related to video. There are many
> interesting thoughts by Hamster in that discussion concerning how to
> organize the video with SDRAM.
>
> 2. A PhD thesis in Electrical Engineering, 175 pages.
>
> Shao, Jun, "Reducing main memory access latency through SDRAM address
> mapping techniques and access reordering mechanisms",
> Dissertation, Michigan Technological University, 2006.
> https://digitalcommons.mtu.edu/etds/72
>
> Like every dissertation, this one also starts with a background information
> which is worth reading IMHO.
>
> Hope it helps,
> Wojtek
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>


More information about the Oberon mailing list