Path: EDN Asia >> Design Centre >> IC/Board/Systems Design >> Benefits of DDR interface gate-level simulation
IC/Board/Systems Design Share print

Benefits of DDR interface gate-level simulation

11 Aug 2015  | Abhinav Gaur, Kushagra Khorwal

Share this page with your friends

Duty Cycle Checks
JEDEC spec requires a 47-53% duty cycle clock and DQS. As shown in Fig 3, DDR controller block is generally partitioned in chip-top. PLL or the main clock source should ideally be sitting quite close to the controller to avoid the long clock path. Both Data and Strobes are generated from the same clock edge. So, any rise / fall variation on the clock path would eventually disturb the DQS duty cycle, and the eye diagram of Data. If the PLL is sitting quite far from the DDR controller, following recommendations would work for better duty cycle:

 • Have similar type of cells in the path.
 • Use symmetric cells if available.
 • Use Inverters if feasible to avoid degradation due to skewed lots.
 • Use inverters in front and last stages of a long buffer chain. This would reduce the degradation. (figure 4)
 • Use same type of transition and loads across the clock path
 • For all the clock sources, be it PLL or an external clock source, duty cycle checks should be met till the pad

Figure 4: Inverters at the beginning and end of a buffer chain to improve the duty cycle.

Testbench issues to be addressed
The DDR GLS simulations are sensitive to various testbench setup parameters. If there is any problem in testbench, it can lead to failures in GLS. Various points to be taken care of are:

One should ensure that all annotations are happening correctly, because if any annotation gets missed, it can lead to violations of various timing parameters like duty cycle of clock, etc. Hence on must ensure that all units of the design, clock gating cells, pads, etc. are properly annotated and there are no warnings pertaining to DDR.

The hookup of the DDR model to the SoC must be as per the standards. For example, in case a pull down is required on DQS, it should be done before-hand to avoid unnecessary failures in GLS.

Sometimes the DDR models used in verification environment are way stricter than the actual DDR memory behaviour. For example, the model expects zero skew between the differential DQS signals, which is impossible to achieve in actual implementation. So the verification engineer must be aware of what all model parameters can be relaxed and what all should be considered as it is.

The DDR pads must be configured according to the values for which timing has been met by STA. For example, the drive strength of pad needs to be programmed as per recommendation from STA.

The "pulse_e" & "pulse_r" settings must be such that they allow DDR clock pulse to pass through. The DDR clock is usually of a high, and if the pulse reject setting is not lowered, it will not allow DDR clock to pass through a delay path.

Synchroniser flops (if any) present in the DDR controller hard (custom) blocks must be identified before hand to avoid unnecessary GLS debug.

It is important to realise the importance of running GLS for DDR memory interfaces. It can uncover a lot of hidden design problems which are otherwise invisible to the designer. With a lot of tight checks for various DDR timing parameters, GLS ensures that the physical implementation is done correctly. One must ensure the following points while running GLS for DDR interface:

 • The design is running at the maximum desired frequency.
 • The design is running with models for the actual memories to be used on board.
 • The DDR pads are configured as per suggestions from STA and physical implementation team.
 • The simulations should be run with the correct set of pad libraries for various DDR memories like DDR3L, DDR3, LPDDR2, etc.

Running gate level simulations for DDR interfaces requires a lot of interaction between the verification and timing (STA) team. With correct feedback going to the timing team at each step, one can ensure proper implementation of a DDR memory interface.

About the author
Abhinav Gaur completed his B.E. from Delhi College of Engineering in the field of Electonics & Communication in the year 2011. He joined Freescale in June, 2011 and since then have been a part of the SoC Verification Team. He has been involved in the verification of automotive application SoCs.

Kushagra Khorwal received his Masters in VLSI Design from GGSIP University in Delhi, India. Currently, he is working with Freescale Semiconductors, Noida, India as a Lead Design Engineer in the field of SoC Physical Design. His interests include SoC Clock Tree Synthesis, Padring Design, and SoC Power Optimisation Schemes.

 First Page Previous Page 1 • 2 • 3 • 4

Want to more of this to be delivered to you for FREE?

Subscribe to EDN Asia alerts and receive the latest design ideas and product news in your inbox.

Got to make sure you're not a robot. Please enter the code displayed on the right.

Time to activate your subscription - it's easy!

We have sent an activate request to your registerd e-email. Simply click on the link to activate your subscription.

We're doing this to protect your privacy and ensure you successfully receive your e-mail alerts.

Add New Comment
Visitor (To avoid code verification, simply login or register with us. It is fast and free!)
*Verify code:
Tech Impact

Regional Roundup
Control this smart glass with the blink of an eye
K-Glass 2 detects users' eye movements to point the cursor to recognise computer icons or objects in the Internet, and uses winks for commands. The researchers call this interface the "i-Mouse."

GlobalFoundries extends grants to Singapore students
ARM, Tencent Games team up to improve mobile gaming

News | Products | Design Features | Regional Roundup | Tech Impact