Browse Prior Art Database

System and Method for Synchronizing Packets Across Multiple Clock Domains

IP.com Disclosure Number: IPCOM000195730D
Publication Date: 2010-May-13
Document File: 6 page(s) / 382K

Publishing Venue

The IP.com Prior Art Database

Abstract

Described is a solution to the problem of synchronizing the clock domains of many devices to a marker in an incoming packet on a bus.

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

Page 1 of 6

Ȉ ˇȈ ˄Ȉ ˙

Ȉ ˇȈ ˄Ȉ ˙ Ȉ ˇȈ ˄Ȉ ˙

Described is a method for synchronizing a plurality of processing engines to an event that is detected uniquely by one of the said engines. Furthermore it is possible that these engines may be working "geared"; that is, the clock ratio between any of these engines may be N:M. This can be done with a combination of multiplier/forward divider settings
off a common PLL or with external clock dividers.

       A representative overall system is illustrated in Figure 1, which describes a memory interface design [801/802] that is being synchronized to an engine controlling a synchronous packet bus [800]. The objective is to align the rising edge of all the clocks (arriving at 800,801,802) to an event detected within the synchronous domain of the protocol logic [800]. The protocol logic is responsible for determining the initial synchronization event and then assembles a plurality of packets into a CRC protected frame synchronous to that event. Through internal modulo counters, it maintains synchronization with that event and decodes commands for the aforementioned memory interface.

Note that this overall scheme could apply to a hard

drive disk interface or a LAN interface by replacing [801,802] with the obligatory interfacing logic.

       The difficulty arises in that the depth of the clock tree [110,111,112] is not known, and it is not desirable to make it a factor in the design of the system. Due to process variability--and that clock design in an ASIC is typically designed separate from the functional design--it is highly desirable to make the design independent of the length of the tree. The only requirement on the tree is the typical low-skew requirement that already exists for most synchronous designs; that is, the arrival time at all latches at end of the tree must be within a pre-established, very small range.

       With this unknown, the question remains now, how does one start the clocks to the respective domains such that the requirement that all the domains receive a coincident rising edge at a specific moment as determined, in real-time, by the protocol logic? Specifically, by perhaps the decode of a special "framelock" command.

       The method described within requires the use of two synchronous engines. The first, a frame capture engine [400] which runs synchronously off the same clock as the protocol logic [800]. The second, a frame synchronizer [200], which runs off the same clock as the clock controller, i.e., the control logic that can start and stop the clocks. This clock-gating logic [CLKGATE, 500,501,502] is a synchronous state machine that has the properties that it can start an output clock after a predefined cycle delay from receiving a "GO" command and also be able to perform an N:1 division of the clock. These are found typically in the standard library of many ASIC design tool kits and often encompass test and lbist features in them.

       The procedure to start the clock per the above directi...