Results 1 to 2 of 2

Thread: bandwidth=function(sum(timings)) simplification

  1. #1
    Registered User
    Join Date
    Sep 2005
    Posts
    10

    bandwidth=function(sum(timings)) simplification

    I am tying to get a handle at hardware level of bandwidth versus timings, say 2-2-2-5 1T.

    Many of us have seen the diagrams that show what is necessary to go thru a complete memory access.
    i.e. [CAS]+[RAS-to-CAS Delay]+[Act-to-Precharge Delay]+etc. http://www.pcstats.com/articleview.cfm?articleID=873

    My thinking is that the optimal PCXXXX speed number for a given memory stick, is just a matter of adding the appropriate timings a given memory stick is capable of, in terms of nanoseconds to complete the memory cycle, and then providing a memory clock rate, like 400 or 500 million ticks per second, which provides the proper total time for memory to complete its memory cycle. Since some sticks are shipped untested, we have to do the test ourselves. But, once the actual memory subtimings are known, the PCXXXX number should be a function of these?

    Anyone have a formula, which if given the timings memory is capable (nanoseconds for each stage in the memory cycle), would "tell" the BIOS what the optimal number of ticks per cycle the memory should "see"?

    If there were such a formula, that would focus on how the memory is built (gate delay times), rather than running "test programs", whether synthetic or real, then setting up memory paramaters would be easier.

    I know that I am missing something here.
    So much discussion on tight timings at PC3200 versus looser timings at higher PCXXXX. Basically if you know the absolute time that a memory requires for CAS, RAS-to-CAS Delay, etc, and add these up, you know how long memory is going to need to complete each random access. Then you could just run memory at a clock rate that provides this time??

    Anyone understand, at the gate level, what this memory timings and PCXXXX is about? Something must be going on, that does not allow an easy optimal setting for the rate memory should be clocked at, by some "appropriate arithmetic" on the CAS, RAS-to-CAS, etc timings?

    I have read a lot about looser timings at faster memory clock rates. If you are going to provide memory with more "ticks", but then set "looser timings by setting say CAS=2.5 or CAS=3 or higher, does that not bring you back to the same place you began? You are just counting more of the albeit faster memory clock ticks. The actual wall time of when the next memory sub-event occurs is the same!

    Basically, is not adjusting timings and adjusting the rate memory is being clocked at, two ways of doing exactly the same thing?

    Occams Razor, says why not one? Either a facility for changing the memory timing numbers (i.e the number of ticks a memory stick counts for the CAS stage, etc.) OR a facilitly for changing the number of ticks per second the memory controller provides to the memory stick? NOT BOTH!!

    Note: In the above, when I say the CAS,RAS-to CAS, etc timings I know these are usually given in terms of clock ticks, but I am using the term timings in some of the above to mean the absolute time, I guess in nanoseconds, that each memory sub-function requires, to be stable.

  2. #2
    Registered User
    Join Date
    Oct 2005
    Posts
    41

Bookmarks

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •