Dealing with clock jitter in embedded DDR2/DDR3 DRAM designs: Part 1
By Scott Schaefer, Micron Technology
Embedded.com (11/24/08, 05:33:00 PM EST)
Defining clock jitter
Prior to DDR2 technology, the expectation was that clock jitter specifications could be absorbed by the DRAM timing specifications. DDR2's faster clock rates and on-chip delay locked loop (DLL) changed all that, and industry-standard clock jitter specifications became a requirement for users and suppliers, and some, such as Micron, actually started specifying clock jitter specifications with the release of DDR memory.
Despite the fact that there seemed to be enough timing margin with DDR, the inclusion of the DLL begged for clock jitter guidance. Now, even though both DDR2 and DDR3 have clock jitter specifications, few DRAM users understand how to apply them or how to determine if their system clock violates the specification limits and what action to take if it does.
This series of three articles explores DDR2/DDR3 clock jitter specifications and provides guidance to embedded systems developers on how to apply them and how to deal with violations since many systems will unintentionally encounter them. (Note that statements made are equally applicable to DDR2 and DDR3 SDRAM, unless stated otherwise.)
Embedded.com (11/24/08, 05:33:00 PM EST)
Defining clock jitter
Prior to DDR2 technology, the expectation was that clock jitter specifications could be absorbed by the DRAM timing specifications. DDR2's faster clock rates and on-chip delay locked loop (DLL) changed all that, and industry-standard clock jitter specifications became a requirement for users and suppliers, and some, such as Micron, actually started specifying clock jitter specifications with the release of DDR memory.
Despite the fact that there seemed to be enough timing margin with DDR, the inclusion of the DLL begged for clock jitter guidance. Now, even though both DDR2 and DDR3 have clock jitter specifications, few DRAM users understand how to apply them or how to determine if their system clock violates the specification limits and what action to take if it does.
This series of three articles explores DDR2/DDR3 clock jitter specifications and provides guidance to embedded systems developers on how to apply them and how to deal with violations since many systems will unintentionally encounter them. (Note that statements made are equally applicable to DDR2 and DDR3 SDRAM, unless stated otherwise.)
To read the full article, click here
Related Semiconductor IP
- MIL-STD-1553 Controller IP
- UFS 5.x Device IP
- UCIe 3.x Controller IP
- Ethernet 800G PCS IP
- CHI to UCIe Bridge IP
Related Articles
- Dealing with clock jitter in embedded DDR2/DDR3 DRAM designs: Part 3
- A novel approach to ensure complete coverage for validation of communication protocols by inducing jitter and glitches in clock and data
- Pinning down the acceptable level of jitter for your embedded design
- Emerging Trends and Challenges in Embedded System Design
Latest Articles
- CHIA: An open-source framework for principled, agentic AI-driven hardware/software co-design research
- Croc: Training the Next Generation Chip Designers on Domain-Specific End-to-End Open Source Silicon
- Design and Development of a Neuromorphic Silicon Suite: PVT Sensing, Stochastic LIF Inference, On-Chip STDP Learning, and Crossbar Programming
- LLM4RTL: Tool-Assisted LLM for RTL Generation
- Towards Delta Aware Training: Efficient DNN Weight Storage for Resource-Constrained FPGAs