Browse Prior Art Database

Retaining DDR Memory Contents Across LBIST and Functional Reset

IP.com Disclosure Number: IPCOM000241235D
Publication Date: 2015-Apr-07
Document File: 5 page(s) / 90K

Publishing Venue

The IP.com Prior Art Database

Abstract

Preserving Dual Data Rate (DDR) memory contents is a must for speeding up subsequent boot times but Logic Built in Self-Test (LBIST) and functional reset tend to corrupt the DDR memory contents. This paper describes a software + hardware scheme for preserving DDR memory contents when the DDR controller is going through LBIST or being reset.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 46% of the total text.

Retaining DDR Memory Contents Across LBIST and Functional Reset

Abstract:

Preserving Dual Data Rate (DDR) memory contents is a must for speeding up subsequent boot times but Logic Built in Self-Test (LBIST) and functional reset tend to corrupt the DDR memory contents. This paper describes a software + hardware scheme for preserving DDR memory contents when the DDR controller is going through LBIST or being reset.

Body:

Introduction:

Dual Data Rate (DDR) memory contents retention is important to speed up subsequent boot times. LBIST and functional resets tend to corrupt the DDR contents. This paper will explain how to tackle this issue. This paper describes a way of preserving DDR memory contents when the DDR controller is going through a Logic Built in Self-Test (LBIST) or being reset. The basic scheme is a hardware+software hybrid solution to maintain DDR contents across LBIST and functional reset.

The basic idea and motivation:

This scheme uses a combination of hardware and software techniques to provide the user with the capability to retain multiple logical sections of DDR memory across an LBIST cycle (and functional reset cycle). The implementation requires proper selection of levels of various hardware resets and retention logic. Also a software level paradigm is defined to ensure and identify sections of retained logic in DDR. A handshake mechanism is developed between the DDR controller and the reset controller during the occurrence of any functional reset. In case of any functional reset event, the reset controller first issues a request to the DDR controller for putting DDR in self-refresh mode. The reset is propagated to the entire SoC only after getting acknowledgment from the DDR controller. At the same time, DDR CKE and RESET pads are safe stated before the DDR controller is itself reset. After reset de-assertion, a particular software sequence (explained in the paper) is followed to remove safe stating from DDR pads and bring DDR memory out of self-refresh mode.  For LBIST, the memory is put in self-refresh mode through software and the DDR pads are safe stated before the LBIST is run and the acknowledgement going to the reset controller is also safe stated (since LBIST will be running on the DDR controller also).

Hardware components required:

1.     A series of retention flops/latches sitting out of LBISTed logic and resettable on destructive reset to maintain the state of CKE and RESET pads.

2.     A series of retention flops/latches to maintain the state of ZQ (the calibration pads). This is required because ZQ pad internally affects the state of the CKE and RESET pads.

3.     A ‘State’ maintenance flop that maintains the state of PAD retention and at the same time can be read as status. Sits out of LBIST.

4.     A clearing bit for the above STATE flop.

5.     Reset state machine gating logic based on a self refresh request-ack protocol with DDR controller.

6.     A series of Software read writeable flops to maintain states of section of prese...