Talk:SDRAM latency

It is requested that a computing diagram or diagrams be included in this article to improve its quality. Specific illustrations, plots or diagrams can be requested at the Graphic Lab.
For more information, refer to discussion on this page and/or the listing at Wikipedia:Requested images.

Unless specific criteria are stated for which the article must be edited, a 'clean-up' notice should not be placed. Try giving feedback on a talk page before stating an entry is of insufficient quality.

Article title

This article should be renamed "SDRAM latency" since the timing issues and terminology it addresses are DRAM specific. -- uberpenguin 02:29, 21 March 2006 (UTC)[reply]

Order of SDRAM access terms

In this section, tRAS is listed last and is referenced before it is explained. Moving to the top of the list, under tCAS, would be easier to understand and more digestible. Does anyone disagree with this idea? -Etienne 03:38, 17 July 2006 (UTC)[reply]

Work on it but keep it in the order so the terms remain in the order you would read them like the 2.5-3-3-5 example. ---Supercoop 17:04, 17 July 2006 (UTC)[reply]

Well, they are already listed in the order that they listed in spec. So make no changes, I guess. -Etienne 22:04, 17 July 2006 (UTC)[reply]

Units for tRC etc.

I cannot parse "The precharge command takes a clock cycles before ...". Also Samsung, at least, specifies values whose names begin with "t" in nanoseconds, not clocks. This is significant when one part is used at different clock rates in different applications. —The preceding unsigned comment was added by NormHardy (talk • contribs) 06:54, 23 February 2007 (UTC).[reply]

I forgot one word there.... And I wrote the description in terms of clock cycles because the interface is synchronous. Of course the limitations are real-time and specified in nanoseconds, and the number of clock cycles to wait for the timings has to be calculated for each operating frequency. Alinja 10:58, 23 February 2007 (UTC)[reply]

OK, Thanks for the update. The Samsung note was for a synchronous device but your explanation is fine as is. It would merely confuse here to speak in terms of ns.

Diagram

I find it difficult to understand how all these timings relate to each other. Would it be possible for someone with more knowledge to insert a diagram depicting a complete memory access where each of the latencies is marked? Drhex 09:19, 6 July 2007 (UTC)[reply]

Marked as such. Page 16 of http://www.samsung.com/global/business/semiconductor/products/dram/downloads/ddr2_device_operation_timing_diagram_may_07.pdf is probably somewhat close to what we want, but it contains too much technical (product-specific?) detail. —AySz88 \^-^ 02:08, 8 December 2008 (UTC)[reply]

The first diagram at http://techwww.in.tu-clausthal.de/site/Dokumentation/IC_digital/Speicher/SDRAM/HY57V653220B/SDRAM_timing.pdf may be more clear (though it still has too much detail). I suppose tCL (aka tCAS) should be indicated as just the time from the CAS strobe to the corresponding data appearing on DQ? We don't talk about "additive latency" at all, and probably should assume that it is zero. —AySz88 \^-^ 02:48, 8 December 2008 (UTC)[reply]

Hmm, a more-abstract representation (something like http://arstechnica.com/paedia/r/ram_guide/figure6b.2.html), rather than a strict digital timing diagram, might be something to consider. —AySz88 \^-^ 02:53, 8 December 2008 (UTC)[reply]

explanation of tRAS

The changes made on 08:37, 17 August 2007 about the tRAS timing are really entertaining, but unfortunately they're probably not, uh, encyclopedic. Especially the part that says "Right in your face!" -128.244.208.71 (talk) 22:22, 21 January 2008 (UTC)[reply]

Removed (was a copyvio anyway) and replaced with a summary. —AySz88 \^-^ 01:26, 8 December 2008 (UTC)[reply]

Measurements

The article says "Most computer users don't need to worry about SDRAM latency" but most specifications for computer memory include the CL so it does matter. —Preceding unsigned comment added by 76.87.181.194 (talk) 07:46, 29 June 2008 (UTC)[reply]