Browse Prior Art Database

Memory Interface Clocking for Cycle Time Independence

IP.com Disclosure Number: IPCOM000104386D
Original Publication Date: 1993-Apr-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 2 page(s) / 67K

Publishing Venue

IBM

Related People

Hilaire, JA: AUTHOR

Abstract

This is a solution to having cycle time independence on an interface where the path delay is greater than the cycle time. Fig.1 shows the fetch and store path across the interface. To be cycle time independent, the goal is to transfer from latch to latch in the next clock cycle. That is why there is double latching on both sides of the fetch interface. Fig. 2 shows the data transfer across both the store and fetch interface. For this discussion assume a 3.5ns cycle time and the early and late path delays across the interface to be 5 and 7ns. The system launches store data with a TO clock in cycle 1. It takes between 5 and 7ns to get to the receiving latch. It is latched with a TO clock delayed 4.5ns. This puts the latching edge of the clock in the valid data window. The 4.

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

Memory Interface Clocking for Cycle Time

Independence

      This is a solution to having cycle time independence on an
interface where the path delay is greater than the cycle time.  Fig.1
shows the fetch and store path across the interface.  To be cycle
time independent, the goal is to transfer from latch to latch in the
next clock cycle.  That is why there is double latching on both sides
of the fetch interface.  Fig. 2 shows the data transfer across both
the store and fetch interface.  For this discussion assume a 3.5ns
cycle time and the early and late path delays across the interface to
be 5 and 7ns.  The system launches store data with a TO clock in
cycle 1.  It takes between 5 and 7ns to get to the receiving latch.
It is latched with a TO clock delayed 4.5ns.  This puts the latching
edge of the clock in the valid data window.  The 4.5ns delay is done
by using the earliest time the card could get the clock plus fixed
card wiring.  The rest of the card will use this same clock.

      When fetched data is sent back to the system, it starts out on
a TO + 4.5ns boundary and has to end up in the system on a TO
boundary.  If each latch transfer was done in one clock cycle, there
would be no problem.  This solution adds two levels of latch and the
last transfer is still not on the next clock cycle.  Another level of
latch would have been required.  Instead, the clocks are modified for
the last transfer.  To do the fetch, start a TO + 4.5ns clock and
t...