AFE to SoC HIGH SPEED INTERFACE FOR FULL DUPLEX DOCSIS CABLE

MODEMS

BACKGROUND

[0001] Cable modems (CMs) are generally used to connect or bridge a local network with a larger network, such as the Internet. The CM is a network bridge that can provide communication over a medium, such as hybrid fibre-coaxial (HFC) and radio frequency over glass (RFoG).

[0002] CMs can use an interface between various circuits or components. This interface can negatively impact CM operation, such as reduced data rate.

[0003] What is needed are techniques to facilitate CM operation with regards to the CM interface.

BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Fig. 1 is a diagram illustrating a cable modem architecture 100 in accordance with one or more embodiments.

[0005] Fig. 2 is a diagram illustrating a high speed interface (HSIF) architecture 200 in accordance with one or more embodiments.

[0006] Fig. 3 is a diagram illustrating HSIF framing 300 in accordance with one or more embodiments.

[0007] Fig. 4 is a table describing parts of an HSIF frame in accordance with one or more embodiments.

[0008] Fig. 5 is a diagram illustrating a HSIF frame structure 500 in accordance with one or more embodiments.

[0009] Fig. 6 is a table 600 describing HSIF ordering and Endianness for a frame structure in accordance with one or more embodiments.

[0010] Fig. 7 is a table describing an example of a suitable HSIF frame header structure and/or elements in accordance with one or more embodiments. [0011] Fig. 8 is a table showing AGC update word(s) in accordance with one or more embodiments.

[0012] Fig. 9 is a table showing control type indications in accordance with one or more embodiments.

[0013] Fig. 10 is a table showing a virtual general purpose input output (V- GPIO) in accordance with one or more embodiments.

[0014] Fig. 1 1 is a table showing event marker examples in accordance with one or more embodiments.

[0015] Fig. 12 is a diagram illustrating suitable examples of sample sets 1200 in accordance with one or more embodiments.

[0016] Fig. 13 is a table illustrating examples of suitable TX framing profiles in accordance with one or more embodiments.

[0017] Fig. 14 is a table illustrating examples of suitable RX framing profiles in accordance with one or more embodiments.

[0018] Fig. 15 is a diagram illustrating an example of a suitable preamble 1500 in accordance with one or more embodiments.

[0019] Fig. 16 is a diagram illustrating an example 64b/66b encoded HSIF frame 1600 during alignment mode in accordance with one or more embodiments.

[0020] Fig. 17 is a flow diagram illustrating an example 64b/66b preamble and SYNC alignment method 1700 using a dedicated sequence in accordance with one or more embodiments.

[0021] Fig. 18 is a flow diagram illustrating an example 64b/66b preamble alignment/lock procedure or method 1800 in accordance with one or more embodiments.

[0022] Fig. 19 is a flow diagram illustrating an example HSIF Frame Alignment method 1900 using a SYNC Preamble in accordance with one or more

embodiments.

[0023] Fig. 20 is a flow diagram illustrating an example Alignment Maintenance Flowchart or method 2000 in accordance with one or more embodiments. [0024] Fig. 21 is a flow diagram illustrating an example Link Alignment Maintenance Flowchart or method 2100 in accordance with one or more embodiments.

[0025] Fig. 22 is a flow diagram illustrating an example decoding process in accordance with one or more embodiments.

[0026] Fig. 23 is a table showing examples of Code Word Structures in accordance with one or more embodiments.

[0027] Fig. 24 is a diagram illustrating an example 64b/66b encoded HSIF frame during normal operation in accordance with one or more embodiments.

[0028] Fig. 25 is a diagram illustrating an example 64b/66b scrambler in accordance with one or more embodiments.

[0029] Fig. 26 is a diagram illustrating an example 64b/66b de-scrambler in accordance with one or more embodiments.

[0030] Fig. 27 is a diagram illustrating an example of buffers of an HSIF transmitter in accordance with one or more embodiments.

[0031] Fig. 28 is a diagram illustrating an example of framer lane cycling in accordance with one or more embodiments.

[0032] Fig. 29 is a diagram illustrating an example of a framer flow diagram in accordance with one or more embodiments.

[0033] Fig. 30 is a diagram illustrating an example of a de-framer flow diagram in accordance with one or more embodiments.

[0034] Fig. 31 is a diagram illustrating an example of a multi-lane frame alignment in accordance with one or more embodiments.

[0035] Fig. 32 is a table showing TX direction framing profiles and

configurations in accordance with one or more embodiments.

[0036] Fig. 33 is a table showing RX direction framing profiles and

configurations in accordance with one or more embodiments.

[0037] Fig. 34 is a table showing example lane assignments and framing v operation modes in accordance with one or more embodiments. [0038] Fig. 35 is a table showing examples of programmable framing parameters in accordance with one or more embodiments.

[0039] Fig. 36 is a diagram illustrating data path and interface segments in accordance with one or more embodiments.

[0040] Fig. 37 is a diagram illustrating an example link initialization process in accordance with one or more embodiments.

[0041] Fig. 38 is a diagram illustrating an example link initialization process in accordance with one or more embodiments.

[0042] Fig. 39 is a table showing examples of configurable delay buffers in accordance with one or more embodiments.

[0043] Fig. 40 is a table showing examples of cable modem (CM) operation modes in accordance with one or more embodiments.

[0044] Fig. 41 is a table showing examples of SoC HSIF lane states and operation modes in accordance with one or more embodiments.

[0045] Fig. 42 is a table showing examples of configurable parameters of the HSIF physical interface on the AFE side in accordance with one or more embodiments.

DESCRIPTION

[0046] A full duplex (FDX) Cable Modem (CM) architecture or system can include an analog front end (AFE) and a silicon on chip (SoC) where the AFE is implemented as a separate integrated circuit (1C) from the silicon on chip (SoC). This AFE typically requires or uses a high speed interface (HSIF) to transfer a real time spectrum data and control between the AFE and the silicon on chip (SoC).

[0047] Existing interfaces are generally unable to support required or selected data rates, data types configurations, configuration modes, control information and the like.

[0048] The high speed interface is implemented, in one example, on an Intel Cable Modem 1C. [0049] One or more embodiments for a high speed interface (HSIF) are disclosed that support required or selected data rates, data types configurations, configuration modes, control information and the like. The HSIF can include a protocol based on configurable data frames that carry sets of digitized samples of the RF channel in upstream and downstream direction. The protocol is capable of supporting FDX data streams for (a) main downstream, (b) auxiliary“feedback” downstream , (c) two upstream streams, (d)auxiliary echo canceling upstream for the main downstream. The protocol supports dynamic rate reduction for low bandwidth, low power application through framing structure change.

[0050] This high speed interface (HSIF) can be used for Intel based Cable Gateway platforms, other cable modem platforms, and the like. The interface provides a power efficient way to transfer high speed data and control, while meeting (all) specific requirements of full duplex (FDX) system.

[0051] The interface can include use of any or a selectable physical layer. The interface can be scalable, such as using a combination of number of lanes and lane rates, depending on the needed/selected bandwidth to transport the required data. The interface can support dynamic data mapping according to actual data bit rate vs. bit rate available for traffic. The interface can support several data streams in parallel in each direction (A data stream may include samples from a single source or from multiple sources). The interface can support deterministic latency (from sample-in to sample-out on the remote side). Additionally, the interface can support dynamic operation mode switching and other features.

[0052] The present disclosure will now be described with reference to the attached figures, wherein like reference numerals are used to refer to like elements throughout, and wherein the illustrated structures and devices are not necessarily drawn to scale. As utilized herein, terms“module”,“component,”“system,”

“circuit,”“element,”“slice,”“circuitry,” and the like are intended to refer to a set of one or more electronic components, a computer-related entity, hardware, software (e.g., in execution), and/or firmware. For example, circuitry or a similar term can be a processor, a process running on a processor, a controller, an object, an executable program, a storage device, and/or a computer with a processing device. By way of illustration, an application running on a server and the server can also be circuitry. One or more circuits can reside within the same circuitry, and circuitry can be localized on one computer and/or distributed between two or more computers. A set of elements or a set of other circuits can be described herein, in which the term“set” can be interpreted as“one or more.”

[0053] As another example, circuitry or similar term can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry, in which the electric or electronic circuitry can be operated by a software application or a firmware application executed by one or more processors. The one or more processors can be internal or external to the apparatus and can execute at least a part of the software or firmware application. As yet another example, circuitry can be an apparatus that provides specific functionality through electronic components without mechanical parts; the electronic components can include one or more processors therein to execute executable instructions stored in computer readable storage medium and/or firmware that confer(s), at least in part, the functionality of the electronic components.

[0054] It is understood that when an element is referred to as being“connected” or “coupled” to another element, it can be physically connected or coupled to the other element such that current and/or electromagnetic radiation (e.g., a signal) can flow along a conductive path formed by the elements. Intervening conductive, inductive, or capacitive elements may be present between the element and the other element when the elements are described as being coupled or connected to one another. Further, when coupled or connected to one another, one element may be capable of inducing a voltage or current flow or propagation of an electro-magnetic wave in the other element without physical contact or intervening components. Further, when a voltage, current, or signal is referred to as being“applied” to an element, the voltage, current, or signal may be conducted to the element by way of a physical connection or by way of capacitive, electro-magnetic, or inductive coupling that does not involve a physical connection.

[0055] As used herein, a signal that is“indicative of” a value or other information may be a digital or analog signal that encodes or otherwise communicates the value or other information in a manner that can be decoded by and/or cause a responsive action in a component receiving the signal. The signal may be stored or buffered in computer readable storage medium prior to its receipt by the receiving component and the receiving component may retrieve the signal from the storage medium. Further, a “value” that is“indicative of” some quantity, state, or parameter may be physically embodied as a digital signal, an analog signal, or stored bits that encode or otherwise communicate the value.

[0056] Use of the word example is intended to present concepts in a concrete fashion. The terminology used herein is for the purpose of describing particular examples only and is not intended to be limiting of examples. As used herein, the singular forms“a,”“an” and“the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,”“comprising,”“includes” and/or“including,” when used herein, specify the presence of stated features, integers, steps, operations, elements and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.

[0057] In the following description, a plurality of details is set forth to provide a more thorough explanation of the embodiments of the present disclosure.

However, it will be apparent to one skilled in the art that embodiments of the

present disclosure may be practiced without these specific details. In other

instances, well-known structures and devices are shown in block diagram form rather than in detail in order to avoid obscuring embodiments of the present

disclosure. In addition, features of the different embodiments described hereinafter may be combined with each other, unless specifically noted otherwise.

[0058] Fig. 1 is a diagram illustrating a cable modem architecture 100 in

accordance with one or more embodiments. The architecture 100 is provided for illustrative purposes and it is appreciated that suitable variations are contemplated.

[0059] The architecture 100 is shown as a connectivity block diagram and includes an analog front end (AFE) 102 and a silicon on chip (SoC) 104.

[0060] The architecture 100 shows a high speed serial interface (comprising of several serial lanes) used to stream (transfer) data between the SoC 104 and the AFE 102. The SoC 104 can be a cable modem chipset, firmware, and the like. In one example, the SoC 104 is an Intel ^® Puma™ 8. In another example, the SoC 104 is a cable modem chipset. The high speed interface is also referred to as “HSIF". [0061] In RX direction the AFE 102 is the transmitting side and the SoC 104 (Intel® Puma™ 8) is the receiving side.

[0062] In TX direction the AFE 102 is the receiving side and the SoC 104 (Intel® Puma™ 8) is the transmitting side.

[0063] The HSIF can support:

[0064] Point-to-Point interface, carrying samples in both directions;

[0065] any physical layer;

[0066] Scalable, can use any combination of number of lanes and lane rates, as long as the overall bandwidth is sufficient to transport the required data;

[0067] Dynamic data mapping according to actual data bit rate vs. bit rate available for traffic;

[0068] Supports several data streams in parallel in each direction (A data stream may include samples from a single source or from multiple sources);

[0069] Deterministic latency (from sample-in to sample-out on the remote side);

[0070] Dynamic operation mode switching; and the like.

[0071] Fig. 2 is a diagram illustrating a high speed interface (HSIF) architecture 200 in accordance with one or more embodiments. The architecture 200 is provided for illustrative purposes and it is appreciated that suitable variations are contemplated.

[0072] A left side of the diagram shows an analog front end (AFE), such as the AFE 102 and a right side of the diagram shows a SoC, such as the SoC 104.

[0073] On a transmit side 202, samples from logical data streams and inline control data are mapped into a frame structure over single/multiple lanes. The framed data of each lane is then encoded/scrambled with 64b/66b line code.

Forward Error Correction data is added and the frames are sent over the lane to the receiving side. All frames on all lanes can start simultaneously.

[0074] On a receiving side 204, data from multiple lanes is aligned, data integrity is verified using the FEC, and the bit stream is then de- scrambled/decoded resulting in the framed data.

[0075] The framing structure is removed, the source data is re-constructed and output to the receiving blocks.

[0076] The HSIF assumes use of the same reference clock on both sides of the interface. A suitable clock transfer/synchronization scheme can be used. [0077] The interface (HSIF) is designed to support deterministic latency of sample taken to sample out on remote side. It is achieved using link initialization method described below.

[0078] HSIF Data Streams and Framing - AFE HSIF Framer/de-framer performs framing of the RX data to be sent to Intel® Puma™ 8 and de-framing of TX data received from Intel® Puma™ 8.

[0079] The AFE includes an HSIF framing circuit 206, a coding FEC 208, and a serializer/deserializer 210. The SoC includes a SoC serializer/deserializer 212, an SoC coding FEC 214 and an SoC framing circuit 216.

[0080] Fig. 3 is a diagram illustrating HSIF framing 300 in accordance with one or more embodiments. The framing 300 is provided as an example for illustrative purposes.

[0081] The HSIF framing 300 (also shown as 206 in Fig. 2) has receive (RX) data streams coming in and transmit (TX) data streams going out. The HSIF framing circuitry 300 is generally part of the AFE.

[0082] The HSIF framing 300 generally de-frames received data to be sent to the SoC and frames TX data from the SoC. Control messages can also be passed between the SoC and the AFE in one or both directions. Data stream can be considered as a continuous flow of samples from one logical source to another, such as between the SoC and the AFE.

[0083] A single data stream can be transferred using one or more physical high speed serial lanes present between the AFE and the SoC. Lanes that are used to transport a data stream are typically not used in parallel to transport another data stream.

[0084] A single data stream can include samples from single or multiple sources.

[0085] It is appreciated that the interface HSIF can be configured to use a suitable number of serial lanes.

[0086] Generally, multiple lanes that are used to transport a data stream run or operate at the same rate.

[0087] Fig. 4 is a table describing parts of an HSIF frame in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated. The frame can be generated by the HSIF framing circuit 206 or 300, described above.

[0088] The table shows frame parts on a left column and associated size in bits in a right column.

[0089] Fig. 5 is a diagram illustrating a HSIF frame structure 500 in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[0090] The frame structure 500 can be used/generated by the HSIF framing circuit 300 and is shown having a frame header 502 and one or more sample set(s). An example sample set is shown at 503. The frame header 502 can include control indication, a control channel and the like. The sample sets can include a set type, samples, Pseudo Randomness Binary Sequence(s) (PRBS) and the like. One or more padding bits can be present at the end of the frame structure 500.

[0091] The overall structure of the frame can be the same in all or

multiple/some modes. However it is appreciated that mode specific constants such as size of samples, size and structure of sample sets, number of sets in a frame and the like can vary.

[0092] Fig. 6 is a table 600 describing HSIF ordering and Endianness for a frame structure in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[0093] The table 600 depicts data type in a left column and associated ordering in a right column. The data types include frame header and contents, sample, samples in a sample set, frame order, PRBS sequence and 64b code word in this example. The ordering for the various data types is shown.

[0094] The information provided by the table 600 can be included in the frame header 502 of the frame structure 500.

[0095] Fig. 7 is a table describing an example of a suitable HSIF frame header structure and/or elements in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated. [0096] The table can be used with or as the frame header 502 in the frame structure 500. Generally, the frame header is used to transfer data that is not samples.

[0097] A left column shows automatic gain control (AGC), channels and the like. A second column shows an associated size in bits. A third column shows associated detail.

[0098] Fig. 8 is a table showing AGC update word(s) in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[0099] The AGC update word(s) can be provided as part of the framing header 502 of the framing structure 500. Further, the AGC update word(s) can be elements or part of the frame header.

[00100] A left column shows an AGC gain value and Gain Change. A second column shows an associated size in bits. A third column shows associated detail.

[00101] The protocol carries updates of the AGC state of the receiver.

[00102] Each framed data stream carries an AGC update word that includes two AGC update fields for up to two independent signals.

[00103] It is appreciated that AGC updates may or may not be used, depending on a specific data stream. In cases when not needed, these bits can be assigned to other control functionality.

[00104] Fig. 9 is a table showing control type indications in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00105] The control type indications can be provided or used in the frame header 502 of the frame structure 500.

[00106] Generally, several control types are exchanged between the SoC 104 and the AFE 102. Control types are passed over the Control channel with a corresponding control type indication.

[00107] The control messages may or may not require an acknowledge from the remote side.

[00108] There can be cases or instances when two data streams are transported in parallel. Some controls are related to the lane or data stream, but others can be common (such as host messages). [00109] A Main Control Lane is a lane or indication for lanes that are control data over all or selected active lanes used by a framing profile. Thus, the control data for a Main Control Lane can be used by all/selected active lanes.

[00110] For example, one lane can be designated as the Main Control Lane. The default main control lane will be the lane in the current framing profile with the lowest index (e.g. if Lo and Li are used the control words will be taken from Lo).

The selection of the control lane can be configured and can be re-assigned by a host. The AFE 102 can check if both control words are identical to detect a suspected error, however there would be no way to correct since it is not known which lane had the error.

[00111] The frame header 502 can also include a Control Type Indication. For this indication, a control word is accompanied by Control Type Indication bits for each header of a frame structure. The control word can specifying the type of the control that’s being passed.

[00112] A left column shows a control type indication. A second column indicates which entity sent the indication and a third column shows associated detail.

[00113] A host messaging channel/type passes data between processors on both sides of a link in both TX and RX directions. The messages passed over this channel are split and transported in available slots in the frames. Data that is seen in a specific frame may be a part of a longer message and is not directly related to the data passed in that specific frame.

[00114] The bits allocated for the host message bits are b[15:0] out of the 20 available bits regardless of the size of the message. b[19:16] are not used. It is noted that that host messages are a multiple of 16 bits, in one example.

[00115] The timing/latency of the control messages transfer is not guaranteed, and this channel is not intended to transfer time-sensitive control/signaling.

Moreover, transfer of the host message gets lower priority than other signaling types and the host message may be transferred in non-consecutive frames, with higher priority signaling using the control word in between parts of the host message. [00116] The effective throughput of the Control Channel is dependent on the used frame structure. It is not guaranteed that the same throughput would be achievable in all frame structures (over different operation modes).

[00117] The structure of the messages and data sent over the control channel is outside of the scope of this document.

[00118] During transition there be instances when the transition happens before host message transfer ends.

[00119] Fig. 10 is a table showing a virtual general purpose input output (V- GPIO) in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00120] The virtual general purpose input output (V-GPIO) is a type of control type indications. In one example, the V-GPIO word includes 20 bits, bit 0 being LSB and bit 19 being MSB.

[00121] When a V-GPIO word is received, the current V-GPIO values are replaced with ones from the received V-GPIO word. If no V-GPIO words are received, the currently set values remain unchanged.

[00122] After a V-GPIO change by the SoC 104 the AFE 102 can be configured to generate an Event Marker signal.

[00123] It is noted that the assignment of V-GPIO can change and some V-GPIO can be assigned to specific data stream type(s).

[00124] Another type of Control Type Indications is a Data Path Activate signal. The Data Path Activate signal is used during link initialization for achieving fixed/measurable latency. The Data Path Activate signal is used in both TX and RX directions.

[00125] Fig. 1 1 is a table showing event marker examples in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00126] An event marker is sent by the AFE 102 based on configuration setting from the SoC 104. The SoC 104 can configure the AFE 102 to send an event marker when a specified trigger happens or occurs. The trigger could be a change or toggle of a V-GPIO, such as one of the DAC_EN, physical change or toggle of a GPIO as a result of V-GPIO toggle (such as TX EN in case TX EN is routed to the PGA via tuner) or when an“Event Marker Request” is received from the SoC 104.

[00127] An event marker points at or identifies a sample set (see below) that was written into the sample buffer when an event trigger was received.

[00128] Fig. 12 is a diagram illustrating suitable examples of sample sets 1200 in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00129] Sample sets are typically defined for each operation scenario or mode.

[00130] The sample set generally includes:

[00131] One bit (“Idle” bit) indicating valid Sample Set ( ) or Idle set (O’) followed by one or more samples.

[00132] Fig. 13 is a table illustrating examples of suitable TX framing profiles in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are

contemplated.

[00133] The table includes TX framing profiles that include an Index, mode, sample type, samples per set, sets per frame, frame length (bytes), pad bits, and a lane configuration (config).

[00134] Fig. 14 is a table illustrating examples of suitable RX framing profiles in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are

contemplated.

[00135] The table includes TX framing profiles that include an Index, mode, sample type, samples per set, sets per frame, frame length (bytes), pad bits, and a lane configuration (config).

[00136] An Idle Set can be transmitted instead of a regular sample set there isn’t a sample set available or ready for a transmitter to send.

[00137] The size of the Idle Set is typically identical to the size of the sample set that is being used in the relevant mode.

[00138] The Idle set (See, Fig. 5) is indicated by a de-asserted“Valid” bit (Idle is represented by O’). [00139] It is appreciated that due to various sample set sizes and the constraint of a frame length being a multiple of 64 bits (due to 64b/66b encoding) some profiles can require padding of the frame with unused bits to achieve the target frame size. Padding bits are utilizes and appended to the frame after the last sample/idle set, scrambled together with the rest of the data and transported in 66- bit code words.

[00140] The padding bits can include alternating Ό’ and T or PRBS and is covered by FEC.

[00141] The framed HSIF data is encoded and FEC is added by the coding FEC 208 or 214 before the bits are transmitted over the high speed serial link. As an example, the encoding used with Intel® Puma™ 8 HSIF is 64b/66b.

[00142] The 64b/66b line coding and scrambling is implemented as described in the following sections. The encoding and scrambling example is based on the IEEE 802.3ae-2002 amendment (802.3 10GBase-R Clause 49). Additional detail about the encoding can be found below.

[00143] Fig. 15 is a diagram illustrating an example of a suitable preamble 1500 in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated. The preamble 1500 can be used for alignment and the like.

[00144] The preamble, in this example, is for a 64b/66b data-only code word.

[00145] The 64b/66b encoding adds two preamble bits (Sync Preamble 01 ) to a 64-bit code word, which are shown on a left side of Fig. 15.

[00146] 64b/66b encoding defined in IEEE specifies two preambles, one for data-only code word (“01”) and one for mixed data and control (“10”). In this example, the“01” preamble is used to transfer data (“Data” preamble). The“10” preamble is in the code word that is aligned with the beginning of the HSIF frame (“SYNC” preamble). Reception of a“00” or“1 1” is considered an error. An error code will be indicated.

[00147] Fig. 16 is a diagram illustrating an example 64b/66b encoded HSIF frame 1600 during alignment mode in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated. The preamble is for a 64b/66b data-only code word. [00148] Generally, the receiver aligns frames on the beginning and the end of the 64b/66b scrambled code words to provide suitable data transfer functionality.

[00149] Two suitable methods to achieve alignment are shown, however it is appreciated that other suitable methods are contemplated. An alignment mode is a mode where one of the alignment methods are used to perform alignment.

[00150] A first method uses a 64b/66b Preamble and is referred to as a preamble alignment method.

[00151] A second method uses an Alignment bit sequence and is referred to as an alignment bit sequence method.

[00152] It is noted that the 64b/66b and HSIF alignments start after the CDR of participating lanes has been locked on the incoming bit stream.

[00153] The alignment bit sequence method is an alignment process using a dedicated alignment sequence. This alignment method can be used to achieve faster alignment on the 64b/66b code and HSIF frame start (by SYNC preamble) but is not typically used for alignment maintenance.

[00154] Transmitters that are initialized or re-set to a different rate start transmitting the alignment sequence until they receive a switch to data mode command. Then the transmitter switches to regular HSIF mode and the receiver will maintain the alignment.

[00155] The alignment sequence, in one example, is a set of 8 ^* Ό0001 1 1 1’

(OxOF) symbols following a SYNC preamble, comprising an“alignment code word”. The rest of the code words include a PRBS sequence (e.g., a scrambled stream of Ό0001 1 1 1’ symbols).

[00156] It is appreciated that the transmission is performed in alignment mode in Fig. 16.

[00157] The receiver looks for the 64-bit alignment code word containing 8x symbols of OxOF (Ό0001 1 1 1’). When the alignment code word has been located, the receiver waits and tries to detect the SYNC preamble at its expected location in the beginning of the next frame and another alignment sequence immediately following the SYNC preamble. If the preamble and alignment code word are detected at their expected locations, the receiver changes the state to“aligned”.

[00158] It is noted that in alignment mode the alignment sequence and the PRBS are not scrambled. In normal data mode the data is scrambled. [00159] Fig. 17 is a flow diagram illustrating an example 64b/66b preamble and SYNC alignment method 1700 using a dedicated sequence in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated. The method 1700 uses the alignment bit sequence method.

[00160] In one example, alignment using the 64b/66b preamble is based on the method described in IEEE 802.3 10G Ethernet specifications. Regardless of the scrambled data, the non-scrambled preamble provides a O’->’1’ or Ί’->’0’ transition once every 66 bits.

[00161] The method 1700 begins at block 1702, where the alignment method begins. Various variables can be initialized.

[00162] The de-scrambler looks for the preamble at 1704 and checks if a similar preamble arrives 66 bits later. If the preamble is not found at the target position at block 1706, the receiver looks for the next transition in the bit stream, and attempts to align again at block 1704. When after a transition another one is found 66 bits later at block 1706 the receiver checks if the transition is seen Ni consecutive times before indicating alignment at block 1708.

[00163] During operation the receiver keeps looking for the preamble occurring each 66 bits. If the preamble is not found N _å times over Ni code words the receiver must indicate that it lost alignment, and attempt to re-align by proceeding to block 1704.

[00164] Fig. 18 is a flow diagram illustrating an example 64b/66b preamble alignment/lock procedure or method 1800 in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00165] Fig. 18 shows the 64b/66b preamble alignment/lock procedure. It is noted that the figure 18 describes the alignment process using the 64b/66b code. The flowchart that includes dedicated alignment sequence and preambles.

[00166] The method 1800 utilizes the IEEE 802.3 specifications clause 49, but has been modified.

[00167] The method 1800 begins at block 1802.

[00168] A candidate location is selected or changed at block 1804 and various variables are initialized. [00169] The receiver looks for the preamble at block 1806. If the preamble is found, the method 1800 goes to block 1808 where the preamble count (pr count) is incremented.

[00170] Where:

[00171] Ni is the number of consecutive preamble detections before changing state to“aligned”, the default value for Ni is 64.

[00172] /V? is the number of missed detections (i.e. preamble not found at expected location) while in“aligned” state, before indicating loss of alignment. The default value for N _å is 16.

[00173] If the preamble count is less than N1 , the method returns to block 1806 for a next preamble. If the preamble count is equal to N1 and the preamble is invalid (pr_invalid>0), the method returns to block 1804 where a new candidate location is selected/changed.

[00174] If the preamble count is equal to N1 and the preamble is valid

(pr_invalid=0), alignment has been performed and preamble alignment

(pr_align<=TRUE) is set to true. The method 1800 can then continue to

synchronous alignment.

[00175] If the preamble is not found at 1806, the method 1800 continues at block 1812 where the preamble count is incremented and a preamble invalid/not found (pr invalid) is also incremented.

[00176] If the preamble count is equal to N1 , the preamble invalid is less than N2 and the preamble alignment is true, the method 1800continues back to block 1804.

[00177] If the preamble count is less than N1 , the preamble invalid is less than N2 and the preamble alignment is true, the method 1800 returns to block 1806 for another preamble.

[00178] If the preamble invalid is equal to N2, the preamble alignment is set to false, sync lock (syncjock) is set to false, and the method 1800 returns to block 1804.

[00179] It is noted that a loss of 64b/66b alignment also implies a loss of the SYNC preamble location and resulting in loss of the location of HSIF frame start.

[00180] HSIF Frame Alignment using SYNC Preamble - The method of achieving lock on the SYNC preamble is similar to the method of achieving lock on 64b/66b code. A flow diagram for this method is shown in Fig. 19. [00181] Fig. 19 is a flow diagram illustrating an example HSIF Frame Alignment method 1900 using a SYNC Preamble in accordance with one or more

embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00182] It is noted that it is possible that the 64b/66b alignments can be done in parallel. The link can switch to maintenance after the receiver is aligned on both 64b/66b preamble and SYNC (=HSIF frame start).

[00183] Fig. 20 is a flow diagram illustrating an example Alignment Maintenance Flowchart or method 2000 in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00184] The Alignment Maintenance Flowchart of Fig. 20 shows the alignment states/flowchart taking into account both preamble types. The starting point of the flowchart is when the receiver locked on the preamble and SYNC, either using preamble alignment or dedicated alignment sequence.

[00185] Fig. 21 is a flow diagram illustrating an example Link Alignment Maintenance Flowchart or method 2100 in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00186] 64b/66b Encoding/Decoding Process -

[00187] Fig. 21 Error! Reference source not found, describes the encoding stages.

[00188] It is noted that the blocks on the diagram are not drawn to scale.

[00189] The framed HSIF data is fed into the scrambler.

[00190] The HSIF frame is aligned to the beginning of a 64b/66b code word. i.e. HSIF header starts immediately after the bits of the preamble. The first code word of the HSIF frame uses the“10” (SYNC) preamble.

[00191] Code words that are not the first or the last contain only framed HSIF data and have a“01” (Data) preamble.

[00192] The last code word of the encoded HSIF frame will contain the RS FEC bits in the last 16 bits of the code word. The FEC bits are not scrambled. The last code word uses the“01” (Data) preamble. [00193] The bit stream that includes the pre-pended preamble bits is serialized and transmitted over the lane.

[00194] Fig. 22 is a flow diagram illustrating an example decoding process or method 2200 in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated. Fig. 22 describes a 64b/66b decoding process.

[00195] The preamble bits of each code word are the first bits at the output of the de-serializer. The SYNC preamble bits are the first bits of the HSIF frame at the de-serializer output.

[00196] The preambles are removed from the received 66-bit code words. The 64-bit payload is decoded (and corrected) by the FEC decoder and de-scrambled, before HSIF de-framing.

[00197] Fig. 23 is a table showing examples of Code Word Structures in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are

contemplated.

[00198] 64b/66b Code Word Structures - Fig. 23 summarizes the different code word structures.

[00199] Fig. 24 is a diagram illustrating an example 64b/66b encoded HSIF frame during normal operation in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00200] 64b/66b Scrambler - The scrambler used in 64b/66b encoding is a self synchronizing (multiplicative) scrambler. This means that the scrambler is never reset during operation and there is no need to load the LFSR with initial values.

[00201] The scrambling polynomial is given by:

[00202] G(x) = 1 + x ³⁹ + x ⁵⁸

[00203] Fig. 25 is a diagram illustrating an example 64b/66b scrambler in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00204] Fig. 26 is a diagram illustrating an example 64b/66b de-scrambler in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00205] The scrambler and de-scrambler can be implemented using LFSR, such as a linear feedback shift register.

[00206] 64b/66b Run Length (TBR) - 64b/66b encoding with a scrambler makes it highly unlikely that the transmitted serial data will be a series of consecutive identical bits (run length), e.g. long sequence of Ό’ or of T. Nevertheless theoretically such sequence could happen. In such case there could be a series of identical bits between two preambles, with the preambles guaranteeing a transition at least once in 66 bits.

[00207] The receiving side clock recovery circuit used with the protocol must be able to withstand run length of above 66 bits at a rate of 16 Gbps and maintain lock, under all conditions.

[00208] Forward Error Correction (FEC) - The FEC that will be used with Intel® Puma™ 8 HSIF protocol is Reed-Solomon. The code overhead is 2 bytes and it is able to correct one byte in an up to 256 bytes block. It is a similar implementation of the Intel® Puma™ 7 RS FEC, running at higher rate.

[00209] The HSIF framing and encoding structure is designed to fit within 256 bytes, and have the 2-byte RS block at the end of the frame. The RS bytes are not scrambled, and they cover framed data that is scrambled by the 64b/66b scrambler. Hence the entire HSIF frame is scrambled and covered by the FEC.

[00210] 128b/130b Line Code - Implementation of the protocol may include support for the 128b/130b line code.

[00211] Multi-Lane Operation

[00212] The framer will map a number of logical channels (=data streams) over several lanes.

[00213] The method of data mapping to lanes and sample sets is similar in all modes, while the framing parameters are configuration-dependent.

[00214] In all modes the framer will build the frames in parallel over all lanes, and the lane headers will appear simultaneously over the used lanes. The framer will cycle through the available lanes and map the sample sets or idle sets to the lane transmission queues, as shown in Fig. 28 and 29.

[00215] Buffers - Several buffer types are described. [00216] Lane buffer - includes bits that either were written by the framer and will be transmitted over the serial interface or were received from the serial interface and will be read by the de-framer.

[00217] Sample buffer - includes samples that either were written by the data stream and will be read by the framer (to be transmitted) or were received, written to the buffer by the de-framer and will be read as the reconstructed data stream.

[00218] Fig. 27 is a diagram illustrating an example of buffers of an HSIF transmitter in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00219] A sample buffer is used for each transported data stream, and a lane buffer is used for each active lane of a framing profile.

[00220] Lane Cycling or Framer Lane Cycling - When filling the lane

transmission buffers, the framer will round-robin between the lanes used in the current framing mode and write the appropriate sample set into a corresponding lane buffer. After writing into the last lane used by the framing profile, the framer will return to the first lane used by that profile. An example of lane cycling is shown in Fig. 28.

[00221] Fig. 28 is a diagram illustrating an example of framer lane cycling in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00222] Multi-Lane Framing - The framer prepares the lanes used in the current framing profile. It cycles between the used lane buffers and writes valid or idle sample sets from the sample buffer, as shown in Fig. 29.

[00223] Fig. 29 is a diagram illustrating an example of a framer flow diagram in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00224] Fig. 30 is a diagram illustrating an example of a de-framer flow diagram in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated. [00225] The de-framer checks the used lane for valid sample sets. The valid sample sets are taken from the lane buffers into the sample buffer and the idle sets are discarded.

[00226] Fig. 31 is a diagram illustrating an example of a multi-lane frame alignment in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00227] Multi-Lane Frame Alignment - The lanes are transmitted over the interface simultaneously.

[00228] In case that a lane operates at a different rate than other lanes, the frame start time of slower frames will coincide with frame start time of faster frames.

[00229] Fig. 31 shows an example of Lo and Li operating at 16 Gbps, L2 inactive and L3 operating at 8 Gbps.

[00230] Framing Modes and Profiles

[00231] In a TX direction (U/S and Echo Cancelling data streams) the AFE receives framed non-FDX and FDX spectrum data from SoC and de-frames it into the relevant data streams.

[00232] In a RX direction (D/S and Feedback data) the AFE frames the D/S ADC and Feedback ADC samples into data that will be sent to the SoC over HSIF interface.

[00233] Framing of a single data (sample) stream to single or multiple lanes is defined by a framing profile. The profile defines type and rate of transferred samples, number of used lanes and lane rate.

[00234] A lane/framing configuration may include more than one profile. For example, in FDX mode, the AFE will simultaneously transmit one stream with D/S framing profile (2.5 Gsps over two lanes 16 Gbps each, or“2.5G/12b/2L/16G”) and one stream with Feedback framing profile (1 .875G/12b/2L/16G).

[00235] The configurations/profiles for TX and RX are independent, meaning that in theory any TX profile could run parallel to any RX profile. The actual pairing is according to existing operation modes. Index is used to refer to a specific framing configuration described above. [00236] Fig. 32 is a table showing TX direction framing profiles and

configurations in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00237] 1 : May be a multiplexed stream or a single stream, depending on the operation mode

[00238] 2: Transition (intermediate) profile

[00239] 3: Energy Management Mode

[00240] Fig. 33 is a table showing RX direction framing profiles and

configurations in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00241] 1 : Support of this mode is optional

[00242] 2: Transition (intermediate) profile

[00243] 3: Energy management mode profile

[00244] Multi-Lane Link Maintenance - Link behavior when an error indication occurs will be controlled by software.

[00245] The AFE will report and maintain error counters and issue an interrupt in all specified cases.

[00246] When a data stream is transported over multiple lanes, all lanes must be locked with CDR, encoding and framing for the stream to be valid.

[00247] Fig. 34 is a table showing example lane assignments and framing v operation modes in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00248] 1 : The transition to“PLC channel only” mode is from“1 x1 with OFDM primary”. In“1x1 with OFDM primary” the OFDM channel is transferred over L3. The PLC may be routed via L2 e.g. when the used lane rate is lower, or over L3 either by an additional lane switch or by changing the framing structure on-the-fly in L3.

[00249] 2: Support of PLC-only receive traffic is optional

[00250] Framing Mode Transitions

[00251] The following mode transitions are described. [00252] TX

[00253] FDX <-> Single Channel (EMM)

[00254] RX

[00255] FDX <-> Single Channel (EMM, via non-FDX)

[00256] Non-FDX <-> Single Channel (EMM)

[00257] It is noted that the HSIF-related parts of the transition are described. Full transition definitions will be described in the AFE specification document.

[00258] TX FDX <-> Single Channel Transition

[00259] This transition happens when the CM operates in FDX mode and for energy management purposes exits the FDX mode to continue operation in a single U/S channel mode, and the opposite - single channel U/S to FDX.

[00260] Several example transitions are described below.

[00261] TX FDX to Single Channel Transition - [00262] It is noted that single channel in the“legacy” (non-FDX) U/S is transferred using the non-FDX U/S spectrum samples with the spectrum containing only the single channel.

[00263] Start state:

[00264] The SoC transfers to the AFE: samples of the U/S spectrum up to 85 MHz combined with the 108-684 MHz FDX spectrum into a single data stream, over 2x lanes operating at 16 Gbps rate (Lo and Li); and samples of D/S Echo Cancelling spectrum in 108-684 MHz band over 2x lanes operating at 16 Gbps (l_2 and l_3)

[00265] Transition process

[00266] The SoC terminates the D/S Echo Cancelling data stream and messages the AFE to stop receiving Echo Canceling

[00267] SoC disables the FDX data stream, leaving only the non-FDX data stream that is still being resampled to 1 .875 giga-bits per second (Gbps) and sent in the combined non-FDX + FDX stream

[00268] SoC powers down l_2 and initializes l_3 lane transmitter to 8 Gbps, sends a message to the AFE to power down l_2 and initialize l_3 to 8 Gbps accordingly [00269] AFE sends“lock” indication for l_3

[00270] Lo and Li still running at 16 Gsps transferring data (non-FDX samples added to FDX samples) at 1 .875 Gsps [00271] The SoC enables a data path that decimates the 625 Msps by 2, thus creating a 312.5 Msps data stream that is parallel to re-sampled 1 .875 Gsps data stream

[00272] SoC adds the 312.5 Msps data stream over a lane and synchronizes between the streams

[00273] Upon signaling reception the AFE starts reading samples from l_3 into the U/S spectrum buffer instead of from the multiplexed spectrum

[00274] AFE messages“transition successful” to the SoC

[00275] SoC terminates the multiplexed stream, powers down the relevant lane transmitters (Lo, Li and L2) and messages the AFE to power down the

corresponding lane receivers

[00276] End state

[00277] SoC transfers to the AFE a single data stream of non-FDX spectrum samples at 312.5 Msps over a single 8 Gbps lane

[00278] TX Single Channel to FDX Transition - [00279] Start state

[00280] SoC transfers the 85 MHz U/S spectrum at 312.5 Msps over a single lane (L3) at ½ rate (8 Gsps)

[00281 ] Transition process

[00282] SoC initializes ⁷ 2x unused lane transmitters (Lo and Li) to 16 Gbps rate and signals the AFE to initialize the corresponding lane receivers to 16 Gbps

[00283] AFE sends“lock” indication for the required lanes

[00284] Non-FDX 312.5 Msps data stream is still transferred over L3 @ 8 Gbps

[00285] SoC starts mapping the combined non-FDX and FDX band samples into the multiplexed stream and synchronizes the sample streams

[00286] Upon signaling reception the AFE starts reading the U/S samples from the multiplexed stream into the U/S spectrum buffer, and reading the OFDMA sub bands samples into the relevant sub-band buffers

[00287] SoC terminates the single 8 Gbps lane stream, initializes L2 and L3 transmitters to 16 Gbps and messages the AFE to terminate and initialize the lane receivers to 16 Gbps

[00288] SoC starts transferring the Echo Canceling data stream at 1 .875 Gsps over L2 and L3 16 Gbps lanes [00289] SoC powers down l_2 transmitter and signals the AFE to power down the unused l_2 lane receiver

[00290] End state

[00291] SoC transfers a combined non-FDX + FDX data stream at 1 .875 Gsps over two lanes @ 16 Gbps

[00292] RX FDX <-> Single Channel Transition

[00293] RX FDX to Single Channel Transition - [00294] Start state

[00295] AFE transfers samples of D/S over 2x 16 Gbps lanes and Feedback over 2x 16 Gbps lanes

[00296] Transition process

[00297] SoC stops receiving the Feedback stream and messages AFE to terminate the Feedback stream transmission over l_2 and l_3

[00298] SoC sends messages the AFE to re-initialize the now unused l_3 transmitter to 8 Gbps rate (in case of single OFDM channel) or 2 Gbps rate (in case of single SC-QAM channel), lock the channelizer in the AFE to the target channel (this is outside of the HSIF protocol scope) and initializes l_3 receiver to the same rate

[00299] SoC receives the samples and sends the channelized data to one of the demodulators

[00300] When the SoC is demodulating the target channel both from D/S and from channelized samples and can align/synchronize between them it performs hand-over to channelized only

[00301] SoC messages AFE to power down the lane transmitters that were used for D/S (Lo, Li, L2) and powers down the corresponding lane receivers on SoC side

[00302] End state

[00303] AFE transfers a single channelized OFDM over a single 8 Gbps lane or a single channelized SC-QAM over a single 2 Gbps lane

[00304] RX Single Channel to FDX Transition - [00305] Start state

[00306] AFE transfers a single channel over a single 2 Gbps or 8 Gbps lane (L3) to SoC

[00307] Transition process [00308] SoC signals the AFE to initialize 2x lane transmitters (U, Li) to 16 Gbps and initializes corresponding SoC receivers to 16 Gbps

[00309] AFE starts D/S spectrum sample transfer over Lo and Li in parallel to the baseband single channel

[00310] SoC locks a channelizer + demodulator on the primary channel from the D/S spectrum in parallel to separate demodulator locked on the baseband channel

[00311] Once the SoC aligns between the two parallel primary channels it signals the AFE to power down the channelizer and the lane transmitter used to transmit the single channel and powers down the corresponding lane receiver

[00312] SoC signals the AFE to initialize l_2 and l_3 transmitters to 16 Gbps and initializes own l_2 and l_3 receivers to 16 Gbps

[00313] SoC signals the AFE to start transferring Feedback stream and starts receiving the Feedback stream over 2x 16 Gbps streams

[00314] End state

[00315] D/S data stream is transported over 2x 16 Gbps lanes and a Feedback data stream is transported over 2x 16 Gbps lanes from the AFE to SoC

[00316] RX Non-FDX <-> Single Channel Transition

[00317] RX Non-FDX D/S to Single Channel Transition -

[00318] The transition from D/S-only operation (FDX-L) to Single Channel is identical to the transition described in section [00293] starting from step 2. a.

[00319] RX Single Channel to Non-FDX Transition

[00320] The transition from Single Channel to D/S non-FDX operation is identical or similar to the transition described in RX FDX to Single Channel Transition.

[00321] Total Framing/Encoding Overhead

[00322] In addition to the payload data, the frame header, control channel and FEC are transmitted.

[00323] Additional overhead is caused by the line coding and padding bits.

[00324] The overhead depends on the frame structure and size and thus is different with different operation modes.

[00325] The total HSIF overhead including the 64b/66b code and padding bits ranges between -6.5% to -14%.

[00326] Frame Buffering [00327] The frame may be buffered before it is transmitted but this is an implementation consideration.

[00328] Since AGC updates and event markers can point at sample sets in the end of the frame, the beginning of the frame carries the AGC update words and signaling that could point to the last sample set. This may be achieved by buffering the frame but the implementation method is not mandated as long as the abovementioned requirement is fulfilled.

[00329] In multi-lane operation all frames must leave the transmitter

simultaneously, which may also place constraints on buffering (e.g. one lane could be ready to send but the second is not - but they must start simultaneously).

[00330] Framing/Encoding Programmability

[00331] Fig. 35 is a table showing examples of programmable framing parameters in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00332] The HSIF framing parameters can be programmed using SPI.

[00333] System Power-Up

[00334] At power-up, the AFE will start transmitting the default frame structure with alignment sequence (automatically or after a message from Puma).

[00335] The framing will be transmitted over all lanes, without any valid data payload.

[00336] The SoC will lock on the framing/encoding from the AFE and will start transmitting the framing/encoding on which the AFE will lock.

[00337] Initialization Process and Deterministic Latency

[00338] The various segments/parts of the data path are shown in Fig. 36.

[00339] Fig. 36 is a diagram illustrating data path and interface segments in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00340] Fig. 37 is a diagram illustrating an example link initialization process in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated. [00341] The link initialization process results in constant or close to constant latency.

[00342] It is noted that this process will start only after all lanes are locked on preambles and on HSIF frame start.

[00343] As shown, different parts of the interface are flushed (cleared) and data pipeline is disabled until activation at a known moment with a known system state, yielding similar latencies whenever performed.

[00344] This link initialization process is also described in a different way in Fig. 38.

[00345] Fig. 38 is a diagram illustrating an example link initialization process in accordance with one or more embodiments. The diagram is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00346] The Fig. 38 shows the latencies for initialization of both direction of a link. The description below refers to a general case ignoring the directions.

[00347] It is noted that in the diagram T2 lands in the second frame after data path activate signal - this is just an example. Depending on the buffers in the system the first data set will be transmitted/received in a frame corresponding to the buffering.

[00348] Before To all HSIF transmitters and receivers are cleared and disabled. This includes FIFOs, framing/de-framing, processing blocks that work on groups of samples and their buffers and any other block that may introduce variance in the latency between power cycles.

[00349] Both sides are locked on the frame structure (HSIF and 64b/66b preambles) from the remote side.

[00350] At time To side A enables its transmitter synchronized to the beginning of an HSIF frame. From that point, since the system is in known state with the transmitter being completely empty from data the latency Z-^ from taking/generating a sample at To to until that sample is received on side B at T _å will be deterministic.

[00351] In addition to activating the buffer, side A also sends a“Data Path Activate” signal. The signal is received at side B with latency that does not change between power-on and upon reception of the signal side B activates its data path, thus continuing the chain of events that starts each time from a known state. The sample that arrived at T _å will be received at a system state that is repeatable, and will take the same latency to arrive to the DAC output or de-mod input at T3.

[00352] It is/can be assumed that the signal processing (data path) of the AFE receive direction before the HSIF has a deterministic (constant) latency from ADC to the interface input (sample buffer) between power cycles. If this is not the case, the data path aside from the interface must also be re-set and activated from a deterministic state.

[00353] The same on SoC side will be ensured by data path design.

[00354] All buffers are designed so that no under-run or over-run happens during operation because even if the system could recover from such event - it would change the latency.

[00355] FIFO First Read/Write Thresholds

[00356] During normal operation, the samples are read by the framer (in both directions) when there is at least one ready sample set to read. During link initialization, the first read of a sample set from the data buffer into the framer must occur when there is Nssi ready sample sets in the buffer, where Nssi > 1. The default value of Nssi must be configurable.

[00357] In the receive direction the de-framer will write the samples into the sample buffer. The samples must be from the buffer after there are Nss2 sample sets ready to read, with Nss2 < Nssi. The default value of Nss2 must be

configurable.

[00358] Latency vs. Framing Profile

[00359] The link initialization process is performed with all lanes being locked but over a specific data stream. For example, the D/S may initialize a two-lane framing structure carrying samples at 2.5 Gsps, and then a Feedback stream can be added carrying samples at 1 .875 Gsps over two lanes.

[00360] The latency can be referenced to the first sample entering the data path in sync to the HSIF frame start. As such, the latency of a sample over HSIF could be made similar to that of a different sample rate by controlling the output buffer read threshold, but the latency may still be different due to different latency of the signal processing.

[00361] Therefore, the delay per framing mode/profile may be characterized. [00362] When two data streams are initialized in the link, the latency for RX direction will be determined by D/S sample stream and the latency for TX will be determined by either the combined D3.1 non-FDX + D3.1 FDX sample stream or by D3.1 standalone non-FDX data stream.

[00363] It is assumed that the Echo Canceling related path latencies do not need to be constant over power cycles as the latencies of these paths are taken into account by EC training.

[00364] It is assumed that there is no need to maintain the support of constant latency when in energy management modes.

[00365] Sample Stream Addition and Synchronization

[00366] In some operation or transition modes there is a need to synchronize a stream that is added to the link to the stream that is already transferred over the link.

[00367] The markers described in the following sections may point to a single sample or to a sample set.

[00368] Sync of a TX non-FDX Stream with Combined non-FDX and FDX Stream

[00369] When a transition from an FDX mode (1 .875G/15b/2L/16G - 1.875 Gsps, 15 bit/sample /16 Gbps lane rate/2 Lanes) to non-FDX single channel mode (312.5M/15b/1 L/8G - 312.5 Msps, 15 bit/sample /8 Gbps lane rate/1 Lane) happens, a seamless switch-over of the non-FDX signal between the data streams is required.

[00370] Assumptions:

[00371] The difference in latency between the non-FDX sample arriving to the non-FDX stream data buffer over the non-FDX decimated data path to the arrival to the combined stream data buffer in units of 312.5M sample duration is assumed to be characterized and known by the SoC transmitter

[00372] The difference in latency in the AFE TX HSIF receiver between a sample from a non-FDX frame arriving to the non-FDX DAC and a sample from the combined stream after filtering and resampling arriving to the non-FDX DAC is assumed to be known and characterized by the AFE receiver

[00373] The initialization process of the added lane: [00374] The additional 8 Gbps frame start will be synchronized to the 16 Gbps lanes frame start but will coincide only once in two frames

[00375] Synchronized to a simultaneous beginning of 8 Gbps and 16 Gbps frames the SoC transmitter will activate the 312.5M/8G SoC TX HSIF transmitter (framer and buffers) and send“Data Path Active” signal to the remote side

[00376] The remote side activates the 312.5M/8G AFE TX HSIF receiver (de framer and buffers) upon detection of the“Data Path Active” signal

[00377] After the data stream is initialized, the switch can be done as follows:

[00378] At the switch moment the SoC marks a non-FDX (312.5M/8G/1 L) stream sample and the combined FDX (1 .875G/16G/2L) stream sample, with the

1.875G/15b/2L/16G stream mark time-corrected for the latency difference between the two, effectively having marked the samples in both streams that contain the same non-FDX sample

[00379] When the samples are read from the sample buffers in the SoC TX HSIF transmitter and are framed into the corresponding data stream the marks will be translated into“event marker” signals pointing to the corresponding samples in the frame and transferred to the AFE side over the control channel field. The markers will propagate with the samples until the switch-over location (non-FDX DAC input)

[00380] The AFE will get both samples pointed to by the event markers, time- correct 1 .875G/15b/2l/16G stream sample marker to account for the different latency and when the marked sample from combined stream after filtering arrives to non-FDX DAC the AFE will switch to taking the samples from the non-FDX path instead

[00381] The AFE receiver data buffer sizes and their read thresholds must be designed so that the receive buffers of both streams will contain both marked samples at some point in time

[00382] Sync of a TX Combined non-FDX + FDX Stream with non-FDX Stream

[00383] When the transition from a 312.5M/8G/1 L non-FDX data stream back to a 1.875G/15b/2L/16G combined data stream happens, there is also a need for a seamless signal switch-over between the data streams.

[00384] Assumptions:

[00385] The difference in latency between the non-FDX sample arriving to the non-FDX stream data buffer over the non-FDX decimated data path to the arrival to the combined stream data buffer in units of 312.5M sample duration is assumed to be characterized and known by the SoC transmitter

[00386] The difference in latency in the AFE TX HSIF receiver between a sample from a non-FDX frame arriving to the non-FDX DAC and a sample from the combined stream after filtering and resampling arriving to the non-FDX DAC is assumed to be known and characterized by the AFE receiver

[00387] The initialization process of the added lanes:

[00388] The additional 2x 16 Gbps frames start will be synchronized to the 8 Gbps lane frame start but will happen two times more often

[00389] Synchronized to a simultaneous beginning of both 8 Gbps and 16 Gbps frames the SoC transmitter will activate the 1 .875G/15b/2L/16G SoC TX HSIF transmitter (framer and buffers) and send“Data Path Active” signal to the remote side

[00390] The remote side activates the 1 .875G/15b/2L/16G AFE TX HSIF receiver (de-framer and buffers) upon detection of the“Data Path Active” signal

[00391] After the data stream is initialized, the switch can be done as follows:

[00392] At the switch moment the SoC marks a non-FDX (312.5M/15b/1 L/8G) stream sample and a combined (1 .875G/15b/2L/16G) stream sample, with the later mark time-corrected for the latency difference between the two, effectively having marked the samples in both streams that contain the same non-FDX sample

[00393] When the samples are read from the sample buffers in the SoC TX HSIF transmitter and are framed into the corresponding data stream the marks will be translated into“event marker” signals pointing to the corresponding samples in the frame and transferred to the AFE side over the control channel field. The markers propagate with the samples until the switch-over location (non-FDX DAC input)

[00394] The AFE will get both samples pointed to by the event markers, time- correct the 1.875G/15b/2L/16G stream sample marker to account for the different latency and when the marked sample from the non-FDX stream arrives to the non- FDX DAC the AFE will switch to taking the samples from the combined filtered stream starting with the marked sample

[00395] The AFE receiver data buffer sizes and their read thresholds are be designed so that the receive buffers of both streams will contain both marked samples at some point in time [00396] AFE RX Path Latency Counter

[00397] During initialization, when the AFE activates the HSIF receiver (meaning that first samples from the ADC are written into the sample buffer) the AFE will also activate a counter. The counter will start from 0 and count each unit of time until the first valid sample set is read from the samples buffer into the framer. The counter value is then stored by the AFE and used in generating event markers.

[00398] There may be an option to characterize this delay, depending on AFE design.

[00399] Configurable Delay Buffers

[00400] Fig. 39 is a table showing examples of configurable delay buffers in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are

contemplated.

[00401] The AFE will have configurable delay implemented in the following points in the data path as shown in the table of Fig. 39.

[00402] Event Markers

[00403] An Event Marker points a sample set carrying samples that were taken when an event was triggered.

[00404] The following steps describe the marker generation in the AFE.

[00405] SoC toggles a V-GPIO or physical GPIO input to AFE that gets marked [00406] AFE receives the control word with V-GPIO toggle

[00407] Starts Sample Delay Counter

[00408] If a physical GPIO must be toggled as a result of V-GPIO toggle - it is toggled

[00409] Sample Delay Counter is running continuously in parallel to HSIF framing, until reaches AFE RX Latency value

[00410] AFE registers the index and the lane of the next valid sample set that is written to the frame buffer

[00411] AFE adds an“Event Marker” signal to the frame that is currently being constructed, pointing to the sample set in step 4

[00412] The Sample Delay counter is increased in the same time steps as the AFE RX path latency counter.

[00413] HSIF Operation Modes [00414] The interface HSIF supports several operation modes.

[00415] Fig. 40 is a table showing examples of cable modem (CM) operation modes in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00416] HSIF modes will be aligned to the AFE modes that will be programmed by the SoC depending on the system configuration and the energy management modes.

[00417] Three states are defined for the HSIF interface:

[00418] Lane Enabled

[00419] Lane Standby - can quickly return to Enabled state

[00420] Lane Disabled - will take time to enable the lane

[00421] Fig. 41 is a table showing examples of SoC HSIF lane states and operation modes in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00422] The table of Fig. 41 shows the configuration of the SoC. The AFE configuration will be the opposite - when SoC is transmitting the AFE will be receiving and vice versa.

[00423] Configurable parameters

[00424] Fig. 42 is a table showing examples of configurable parameters of the HSIF physical interface on the AFE side in accordance with one or more embodiments. The table is provided as an example for illustrative purposes and it is appreciated that suitable variations are contemplated.

[00425] While the invention has been illustrated and described with respect to one or more implementations, alterations and/or modifications may be made to the illustrated examples without departing from the spirit and scope of the appended claims. In particular regard to the various functions performed by the above described components or structures (assemblies, devices, circuits, systems, etc.), the terms (including a reference to a "means") used to describe such components are intended to correspond, unless otherwise indicated, to any component or structure which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary implementations of the invention.

[00426] Examples can include subject matter such as a method, means for performing acts or blocks of the method, at least one machine-readable medium including instructions that, when performed by a machine cause the machine to perform acts of the method or of an apparatus or system for dynamically generating a clock signal for a data processing system according to embodiments and examples described herein.

[0001] Example 1 is an apparatus for a cable modem (CM) architecture. The apparatus includes a silicon on chip (SoC), an analog front end (AFE), a high speed interface and a high speed interface framing circuit (HSIF). The SoC is configured to provide received baseband signals and obtain transmit baseband signals based on a plurality of interface lanes. The AFE is configured to provide received radio frequency (RF) signals and provide transmit radio frequency signals based on the plurality of interface lanes. The high speed interface is coupled to the SoC and the AFE and configured to convey the plurality of interface lanes. The HSIF circuit is located within the AFE and/or the SoC and configured to frame one or more data streams for the plurality of interface lanes.

[0002] Example 2 includes the subject matter of Example 1 , including or omitting optional elements, wherein the plurality of interface lanes are serial interface lanes.

[0003] Example 3 includes the subject matter of any of Examples 1 -2, including or omitting optional elements, wherein the plurality of interface lanes are configured for full duplex (FDX) communication between the SoC and the AFE.

[00427] Example 4 includes the subject matter of any of Examples 1 -3, including or omitting optional elements, wherein the AFE comprises a serializer/deserializer configured to serialize and/or deserialize data streams for the plurality of interface lanes.

[00428] Example 5 includes the subject matter of any of Examples 1 -4, including or omitting optional elements, wherein the plurality of interface lanes include lanes having different speeds.

[00429] Example 6 includes the subject matter of any of Examples 1 -5, including or omitting optional elements, wherein the HSIF framing circuit is configured to frame a single data stream of the one or more data streams across two or more of the plurality of interface lanes.

[00430] Example 7 includes the subject matter of any of Examples 1 -6, including or omitting optional elements, wherein the HSIF framing circuit is further configured to frame a single data stream across a two or more of the plurality of interface lanes, wherein the two or more interface lanes have varied speeds.

[00431] Example 8 includes the subject matter of any of Examples 1 -7, including or omitting optional elements, wherein the HSIF framing circuit is further configured to dynamically allocate data from the one or more data streams based on framing parameters.

[00432] Example 9 includes the subject matter of any of Examples 1 -8, including or omitting optional elements, wherein the framing parameters include a selected throughput.

[00433] Example 10 includes the subject matter of any of Examples 1 -9, including or omitting optional elements, wherein plurality of interface lanes are configured by the AFE to support selected or required data rates, data types, configuration modes, control information and the like.

[00434] Example 1 1 includes the subject matter of any of Examples 1 -10, including or omitting optional elements, wherein the HSIF framing circuit is configured to generate sample sets for the one or more data streams and use the sample sets for control information transfer.

[00435] Example 12 includes the subject matter of any of Examples 1 -1 1 , including or omitting optional elements, wherein at least a portion of the plurality of interface lanes are full duplex.

[00436] Example 13 is an analog front end (AFE) for a cable modem (CM)

architecture. The AFE includes a high speed interface (HSIF) framing circuit, coding circuitry configured to decode the received data stream, and a serializer circuit. The high speed interface (HSIF) framing circuit configured to receive a data stream and to frame the received data stream for a plurality of interface lanes. The coding circuitry configured to decode the received data stream. The serializer circuit is configured to generate one or more serial lanes of data for the plurality of interface lanes based on the decoded received data stream.

[00437] Example 14 includes the subject matter of Example 13, including or omitting optional elements, wherein the HSIF framing circuit is further configured to received control information for the received data stream using a sample set.

[00438] Example 15 includes the subject matter of any of Examples 13-14, including or omitting optional elements, wherein the plurality of interface lanes have varying transfer speeds.

[00439] Example 16 includes the subject matter of any of Examples 13-15, including or omitting optional elements, wherein the serializer circuit and the HSIF framing circuit are configured allocate the decoded received data stream across the plurality of interface lanes to obtain a selected throughput and wherein the plurality of interface lanes have varied throughput speeds.

[00440] Example 17 is a method of operating a cable modem architecture. The method includes obtaining one or more data streams of baseband data by a silicon on chip (SoC) circuit; framing the one or more data streams across a plurality of interface lanes of a high speed interface, wherein the plurality of interface lanes have varying throughput speeds; and de-framing the one or more data streams by an analog front end (AFE) from the plurality of interface lanes.

[00441] Example 18 includes the subject matter of Example 17, including or omitting optional elements, further comprising generating control information and encoding the control information into a transmit sample set by the AFE.

[00442] Example 19 includes the subject matter of any of Examples 17-18, including or omitting optional elements, further comprising transmitting the one or more streams by the AFE.

[00443] Example 20 includes the subject matter of any of Examples 17-19, including or omitting optional elements, further comprising receiving the one or more data streams at an external device.

[00444] Example 21 includes the subject matter of any of Examples 17-20, including or omitting optional elements, further comprising de-framing the one or more data streams using transmitted control information. [00445] Example 22 is an apparatus for a cable modem (CM) architecture. The apparatus includes a silicon on chip (SoC); an analog front end (AFE) configured to provide a plurality of transmit lanes and a plurality of receive lanes; and a high speed interface (HSIF) framing circuit within the AFE and/or the SoC and configured to frame one or more first data streams and de-frame one or more second data streams.

[00446] Example 23 includes the subject matter of Example 22, including or omitting optional elements, wherein the AFE incorporates a protocol based on configurable data frames that carry sets of digitized samples of a radio frequency (RF) channel in upstream and/or downstream directions.

[00447] Example 24 includes the subject matter of any of Examples 22-23, including or omitting optional elements, wherein the protocol supports FDX data streams for one or more of a main downstream, an auxiliary or feedback downstream, two upstream streams, auxiliary echo canceling upstream for the main downstream and the like.

[00448] Example 25 includes the subject matter of any of Examples 22-24, including or omitting optional elements, wherein the protocol supports dynamic rate reduction for low bandwidth and/or lower power applications through framing structure.

[00449] Example 26 includes the subject matter of any of Examples 22-25, including or omitting optional elements, wherein the AFE is configured to us a selected physical layer of one or more physical layers.

[00450] Example 27 includes the subject matter of any of Examples 22-26, including or omitting optional elements, wherein the AFE is scalable to support a combination of lanes and lane rates.

[00451] Example 28 includes the subject matter of any of Examples 22-27, including or omitting optional elements, wherein the HSIF framing circuit uses a frame structure that includes a frame header and control indications, samples in a sample set, a frame order, and a PRBS sequence.

[00452] Example 29 includes the subject matter of any of Examples 22-28, including or omitting optional elements, wherein the frame structure includes one or more sample sets associated with the frame header. [00453] Example 30 includes the subject matter of any of Examples 22-29, including or omitting optional elements, wherein the HSIF framing circuit is configured to perform frame alignment using an alignment bit sequence.

[00454] Example 31 includes the subject matter of any of Examples 22-30, including or omitting optional elements, wherein the HSIF framing circuit is configured to perform frame alignment using a preamble.

[00455] Various illustrative logics, logical blocks, modules, and circuits described in connection with aspects disclosed herein can be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other

programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform functions described herein. A general-purpose processor can be a microprocessor, but, in the alternative, processor can be any conventional processor, controller, microcontroller, or state machine. The various illustrative logics, logical blocks, modules, and circuits described in connection with aspects disclosed herein can be implemented or performed with a general purpose processor executing instructions stored in computer readable medium.

[00456] The above description of illustrated embodiments of the subject disclosure, including what is described in the Abstract, is not intended to be exhaustive or to limit the disclosed embodiments to the precise forms disclosed. While specific embodiments and examples are described herein for illustrative purposes, various modifications are possible that are considered within the scope of such embodiments and examples, as those skilled in the relevant art can recognize.

[00457] In this regard, while the disclosed subject matter has been described in connection with various embodiments and corresponding Figures, where applicable, it is to be understood that other similar embodiments can be used or modifications and additions can be made to the described embodiments for performing the same, similar, alternative, or substitute function of the disclosed subject matter without deviating therefrom. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but rather should be construed in breadth and scope in accordance with the appended claims below. [00458] In particular regard to the various functions performed by the above described components (assemblies, devices, circuits, systems, etc.), the terms (including a reference to a "means") used to describe such components are intended to correspond, unless otherwise indicated, to any component or structure which performs the specified function of the described component (e.g., that is functionally equivalent), even though not structurally equivalent to the disclosed structure which performs the function in the herein illustrated exemplary

implementations of the disclosure. In addition, while a particular feature may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. The use of the phrase“one or more of A, B, or C” is intended to include all combinations of A, B, and C, for example A, A and B, A and B and C, B, and so on.