Patent Description:
Standardization of memory subsystem processes may allow for interoperability among different device manufacturers. Standardization allows for building devices with different architectural designs and different processing technologies that function according to specified guidelines. Memory devices receive commands from memory controllers over command buses, which are traditionally trained to ensure that the signaling between the devices meets the expected standards. Training can refer to iterative testing of different I/O (input/output) interface parameters to determine settings that result in best accuracy of signaling on the signal lines. A common term for signal accuracy is finding a middle or center of a signal eye. Memory technologies need to train a command bus timing and voltage sampling point to be in a middle or center of a signal eye for optimal performance.

<NPL> discloses the DDR5 SDRAM specification, including features, functionalities, AC and DC characteristics, packages, and ball/signal assignments. The purpose of the Standard is to define the minimum set of requirements for JEDEC compliant 8Gb through 32Gb for x4, x8, and x16 DDR5 SDRAM devices.

<CIT> discloses a memory system that includes a memory controller with a plurality N of memory-controller blocks, each of which conveys independent transaction requests over external request ports. The request ports are coupled, via point-to-point connections, to from one to N memory devices, each of which includes N independently addressable memory blocks. All of the external request ports are connected to respective external request ports on the memory device or devices used in a given configuration. The number of request ports per memory device and the data width of each memory device changes with the number of memory devices such that the ratio of the request-access granularity to the data granularity remains constant irrespective of the number of memory devices.

Variations in how signals are sent and received between a memory controller and one or more memory devices may be caused by differences in memory device designs as well as decreasing memory device geometries, shrinking package sizes, increasing channel bandwidth, and increasing signaling frequencies. Thus, a significant variation in memory channel layouts makes it unlikely for memory device suppliers to guarantee that a memory device will operate in a default state without command bus training. Command bus training is particularly complex since it's a chicken and egg problem where the command bus may be the only way to communication with a memory device that may have no sideband communication channel. Yet that same command bus requires proper centering. It is also difficult to attempt to complete command bus training outside of standardized training modes (e.g., to address complicated cross-talk or interference situations) since errors on the command bus may cause a memory device to hang or lock up. A hung or locked up memory device may lead to a long and expensive reset flow or process.

As described herein, reference to memory devices can apply to different memory types. Memory devices may refer to volatile memory technologies. Volatile memory is memory whose state (and therefore the data stored on it) is indeterminate if power is interrupted to the device. Nonvolatile memory refers to memory whose state is determinate even if power is interrupted to the device. Dynamic volatile memory requires refreshing the data stored in the device to maintain state. One example of dynamic volatile memory includes dynamic random access memory (DRAM), or some variant such as synchronous DRAM (SDRAM). A memory subsystem as described herein may be compatible with a number of memory technologies or standards, such as DDR3 (double data rate version <NUM>, JESD79-<NUM>, originally published by JEDEC (<NPL>), DDR4 (DDR version <NUM>, JESD79-<NUM>, originally published in September <NUM> by JEDEC), LPDDR3 (low power DDR version <NUM>, JESD209-3B, originally published in August <NUM> by JEDEC), LPDDR4 (low power DDR version <NUM>, JESD209-<NUM>, originally published by JEDEC in August <NUM>), WIO2 (Wide I/O <NUM> (WideIO2), JESD229-<NUM>, originally published by JEDEC in August <NUM>), HBM (high bandwidth memory DRAM, JESD235, originally published by JEDEC in October <NUM>), LPDDR5 (originally published by JEDEC in February <NUM>), HBM2 ((HBM version <NUM>), originally published by JEDEC in December <NUM>), DDR5 (DDR version <NUM>, currently in discussion by JEDEC), or others or combinations of memory technologies, and technologies based on derivatives or extensions of such specifications.

DRAM memory devices designed to operate in accordance with LPDDR4 or LPDDR5 standards or specifications may have command bus training (CBT) modes that sample command/address (CA) values received via a command bus when a chip select (CS) signal is toggled and returns the sampled CA values on a data bus to a memory controller. The receiving memory controller uses this feedback to adjust a voltage reference for the command bus (VrefCA) (e.g., LPDDR5 mode register (MR) MR12. OP[<NUM>:<NUM>]). The receiving memory controller also uses this feedback to adjust relative timing between the command bus and a clock (CLK), usually with phase interpolator circuity, or may adjust advanced signaling techniques associated with higher command bus frequencies such as transmit or receiver equalization techniques. The CBT mode allows for training of LPDDR4 or LPDDR5 command buses, but it is a slow process that typically needs to run through firmware/software. For example, these LPDDR4/LPDDR5 CBT modes may require firmware/software to program a CA pattern, send the CA pattern to the DRAM via the command bus, read the sampled values returned on the data bus and have the firmware/software check for correctness or errors. Each of these steps are coordinated by the firmware such that, in some examples, command bus training may only take <NUM> sample every few microseconds. A rate of <NUM> sample every few microseconds may greatly limit how many CA patterns can be tested in an acceptable period of time. Also, the limited rate of sampling may negatively impact command bus training quality given that normal operation of LPDDR4 or LPDDR5 DRAM memory devices can present opportunities to gather/observe multiple samples per nanosecond. Thus, thousands of potential sampling points may be missed for observing correctness or errors of CA patterns when LPDDR4/LPDDR5 CBT modes are run through firmware/software at a memory controller.

DRAM memory devices designed to operate according to the proposed DDR5 specification support a command bus training mode called command address training mode (CATM). CATM samples CA values when CS toggles and returns results on a data bus for these types of DDR5 memory devices. However, instead of returning actual sampled CA values, DDR5 memory devices include internal circuitry to return just a parity of the sampled CA value. CATM significantly simplifies error checking of CA patterns since logic at the memory controller just needs to check if the data bus has been driven high (parity value indicating errors) or low (parity value indicating no errors) by the memory device. As a result, the logic at the memory controller arranged for command bus training of DDR5 memory devices no longer needs to compare CA patterns transmitted over the command bus with memory device sampled CA patterns returned via the data bus.

Simplified parity checks by logic at a DDR5 memory device for CA patterns during CATM eliminates most of the coordination work firmware is required to do compared to LPDDR4 and LPDDR5 memory devices during their respective command bus training modes. However, LPDDR4 and LPDDR5 memory devices lack the internal circuitry and logic to implement a command bus training mode similar to CATM. Therefore, a need exists for techniques to minimize coordination work of firmware at memory controllers implementing command bus training modes on LPDDR4 or LPDDR5 memory devices to shorten an amount of time to train a command bus and increase quality of command bus training.

<FIG> illustrates an example system <NUM>. In some examples, as shown in <FIG>, system <NUM> includes a processor and elements of a memory subsystem in a computing device. Processor <NUM> represents a processing unit of a computing platform that may execute an operating system (OS) and applications, which can collectively be referred to as the host or the user of the memory subsystem. The OS and applications execute operations that result in memory accesses. Processor <NUM> can include one or more separate processors. Each separate processor may include a single processing unit, a multicore processing unit, or a combination. The processing unit may be a primary processor such as a central processing unit (CPU), a peripheral processor such as a graphics processing unit (GPU), or a combination. Memory accesses may also be initiated by devices such as a network controller or hard disk controller. Such devices may be integrated with the processor in some systems or attached to the processer via a bus (e.g., a PCI express bus), or a combination. System <NUM> may be implemented as a system on a chip (SOC) or may be implemented with standalone components.

Reference to memory devices may apply to different memory types. Memory devices often refers to volatile memory technologies such as DRAM. In addition to, or alternatively to, volatile memory, in some examples, reference to memory devices can refer to a nonvolatile memory device whose state is determinate even if power is interrupted to the device. In one example, the nonvolatile memory device is a block addressable memory device, such as NAND or NOR technologies. A memory device may also include byte or block addressable types of non-volatile memory having a <NUM>-dimensional (<NUM>-D) cross-point memory structure that includes, but is not limited to, chalcogenide phase change material (e.g., chalcogenide glass) hereinafter referred to as "<NUM>-D cross-point memory". Non-volatile types of memory may also include other types of byte or block addressable non-volatile memory such as, but not limited to, multi-threshold level NAND flash memory, NOR flash memory, single or multi-level phase change memory (PCM), resistive memory, nanowire memory, ferroelectric transistor random access memory (FeTRAM), anti-ferroelectric memory, resistive memory including a metal oxide base, an oxygen vacancy base and a conductive bridge random access memory (CB-RAM), a spintronic magnetic junction memory, a magnetic tunneling junction (MTJ) memory, a domain wall (DW) and spin orbit transfer (SOT) memory, a thyristor based memory, a magnetoresistive random access memory (MRAM) that incorporates memristor technology, spin transfer torque MRAM (STT-MRAM), or a combination of any of the above.

Descriptions herein referring to a "RAM" or "RAM device" can apply to any memory device that allows random access, whether volatile or nonvolatile. Descriptions referring to a "DRAM", "SDRAM, "DRAM device" or "SDRAM device" may refer to a volatile random access memory device. The memory device, SDRAM or DRAM may refer to the die itself, to a packaged memory product that includes one or more dies, or both. In some examples, a system with volatile memory that needs to be refreshed may also include at least some nonvolatile memory.

Memory controller <NUM>, as shown in <FIG>, may represent one or more memory controller circuits or devices for system <NUM>. Also, memory controller <NUM> may include logic and/or features that generate memory access commands in response to the execution of operations by processor <NUM>. Memory controller <NUM> accesses one or more memory device(s) <NUM>. For these examples, memory device(s) <NUM> may be SDRAM devices in accordance with any referred to above. Memory device(s) <NUM> may be organized and managed through different channels, where these channels may couple in parallel to multiple memory devices via buses and signal lines. Each channel may be independently operable. Thus, separate channels may be independently accessed and controlled, and the timing, data transfer, command and address exchanges, and other operations may be separate for each channel. Coupling may refer to an electrical coupling, communicative coupling, physical coupling, or a combination of these. Physical coupling may include direct contact. Electrical coupling, for example, includes an interface or interconnection that allows electrical flow between components, or allows signaling between components, or both. Communicative coupling, for example, includes connections, including wired or wireless, that enable components to exchange data.

According to some examples, settings for each channel are controlled by separate mode registers or other register settings. For these examples, memory controller <NUM> may manages a separate memory channel, although system <NUM> may be configured to have multiple channels managed by a single memory controller, or to have multiple memory controllers on a single channel. In one example, memory controller <NUM> is part of processor <NUM>, such as logic and/or features of memory controller <NUM> are implemented on the same die or implemented in the same package space as processor <NUM>.

Memory controller <NUM> includes I/O interface circuitry <NUM> to couple to a memory bus, such as a memory channel as referred to above. I/O interface circuitry <NUM> (as well as I/O interface circuitry <NUM> of memory device(s) <NUM>) may include pins, pads, connectors, signal lines, traces, or wires, or other hardware to connect the devices, or a combination of these. I/O interface circuitry <NUM> may include a hardware interface. As shown in <FIG>, I/O interface circuitry <NUM> includes at least drivers/transceivers for signal lines. Commonly, wires within an integrated circuit interface couple with a pad, pin, or connector to interface signal lines or traces or other wires between devices. I/O interface circuitry <NUM> can include drivers, receivers, transceivers, or termination, or other circuitry or combinations of circuitry to exchange signals on the signal lines between memory controller <NUM> and memory device(s) <NUM>. The exchange of signals includes at least one of transmit or receive. While shown as coupling I/O interface circuitry <NUM> from memory controller <NUM> to I/O interface circuitry <NUM> of memory device(s) <NUM>, it will be understood that in an implementation of system <NUM> where groups of memory device(s) <NUM> are accessed in parallel, multiple memory devices can include I/O interface circuitry to the same interface of memory controller <NUM>. In an implementation of system <NUM> including one or more memory module(s) <NUM>, I/O interface circuitry <NUM> may include interface hardware of memory module(s) <NUM> in addition to interface hardware for memory device(s) <NUM>. Other memory controllers <NUM> may include multiple, separate interfaces to one or more memory devices of memory device(s) <NUM>.

In some examples, memory controller <NUM> may be coupled with memory device(s) <NUM> via multiple signal lines. The multiple signal lines may include at least a clock (CLK) <NUM>, a command/address (CMD) <NUM>, and write data (DQ) and read data (DQ) <NUM>, and zero or more other signal lines <NUM>. According to some examples, a composition of signal lines coupling memory controller <NUM> to memory device(s) <NUM> may be referred to collectively as a memory bus. The signal lines for CMD <NUM> may be referred to as a "command bus", a "C/A bus" or an ADD/CMD bus, or some other designation indicating the transfer of commands. The signal lines for DQ <NUM> may be referred to as a "data bus".

According to some examples, independent channels may have different clock signals, command buses, data buses, and other signal lines. For these examples, system <NUM> may be considered to have multiple "buses," in the sense that an independent interface path may be considered a separate bus. It will be understood that in addition to the signal lines shown in <FIG>, a bus may also include at least one of strobe signaling lines, alert lines, auxiliary lines, or other signal lines, or a combination of these additional signal lines. It will also be understood that serial bus technologies can be used for transmitting signals between memory controller <NUM> and memory device(s) <NUM>. An example of a serial bus technology is 8B 10B encoding and transmission of high-speed data with embedded clock over a single differential pair of signals in each direction. In some examples, CMD <NUM> represents signal lines shared in parallel with multiple memory device(s) <NUM>. In other examples, multiple memory devices share encoding command signal lines of CMD <NUM>, and each has a separate chip select (CS_n) signal line to select individual memory device(s) <NUM>.

In some examples, the bus between memory controller <NUM> and memory device(s) <NUM> includes a subsidiary command bus routed via signal lines included in CMD <NUM> and a subsidiary data bus to carry the write and read data routed via signal lines included in DQ <NUM>. In some examples, CMD <NUM> and DQ <NUM> may separately include bidirectional lines. In other examples, DQ <NUM> may include unidirectional write signal lines to write data from the host to memory and unidirectional lines to read data from the memory to the host.

According to some examples, in accordance with a chosen memory technology and system design, signals lines included in other <NUM> may augment a memory bus or subsidiary bus. For example, strobe line signal lines for a DQS. Based on a design of system <NUM>, or memory technology implementation, a memory bus may have more or less bandwidth per memory device included in memory device(s) <NUM>. The memory bus may support memory devices included in memory device(s) <NUM> that have either a x32 interface, a x16 interface, a x8 interface, or other interface. The convention "xW," where W is an integer that refers to an interface size or width of the interface of memory device(s) <NUM>, which represents a number of signal lines to exchange data with memory controller <NUM>. The interface size of these memory devices may be a controlling factor on how many memory devices may be used concurrently per channel in system <NUM> or coupled in parallel to the same signal lines. In some examples, high bandwidth memory devices, wide interface memory devices, or stacked memory devices, or combinations, may enable wider interfaces, such as a x128 interface, a x256 interface, a x512 interface, a x1024 interface, or other data bus interface width.

In some examples, memory device(s) <NUM> and memory controller <NUM> exchange data over a data bus via signal lines included in DQ <NUM> in a burst, or a sequence of consecutive data transfers. The burst corresponds to a number of transfer cycles, which is related to a bus frequency. A given transfer cycle may be a whole clock cycle for transfers occurring on a same clock or strobe signal edge (e.g., on the rising edge). In some examples, every clock cycle, referring to a cycle of the system clock, may be separated into multiple unit intervals (UIs), where each UI is a transfer cycle. For example, double data rate transfers trigger on both edges of the clock signal (e.g., rising and falling). A burst can last for a configured number of UIs, which can be a configuration stored in a register, or triggered on the fly. For example, a sequence of eight consecutive transfer periods can be considered a burst length <NUM> (BL8), and each memory device(s) <NUM> can transfer data on each UI. Thus, a x8 memory device operating on BL8 can transfer <NUM> bits of data (<NUM> data signal lines times <NUM> data bits transferred per line over the burst). It will be understood that this simple example is merely an illustration and is not limiting.

According to some examples, memory device(s) <NUM> represent memory resources for system <NUM>. For these examples, each memory device included in memory device(s) <NUM> is a separate memory die. Separate memory devices may interface with multiple (e.g., <NUM>) channels per device or die. A given memory device of memory device(s) <NUM> may include I/O interface circuitry <NUM> and may have a bandwidth determined by an interface width associated with an implementation or configuration of the given memory device (e.g., x <NUM> or x8 or some other interface bandwidth). I/O interface circuitry <NUM> may enable the memory devices to interface with memory controller <NUM>. I/O interface circuitry <NUM> may include a hardware interface and operate in coordination with I/O interface circuitry <NUM> of memory controller <NUM>.

In some examples, multiple memory device(s) <NUM> may be connected in parallel to the same command and data buses (e.g., via CMD <NUM> and DQ136). In other examples, multiple memory device(s) <NUM> may be connected in parallel to the same command bus but connected to different data buses. For example, system <NUM> may be configured with multiple memory device(s) <NUM> coupled in parallel, with each memory device responding to a command, and accessing memory resources <NUM> internal to each memory device. For a write operation, an individual memory device of memory device(s) <NUM> may write a portion of the overall data word, and for a read operation, the individual memory device may fetch a portion of the overall data word. As non-limiting examples, a specific memory device may provide or receive, respectively, <NUM> bits of a <NUM>-bit data word for a read or write operation, or <NUM> bits or <NUM> bits (depending for a x8 or a x16 device) of a <NUM>-bit data word. The remaining bits of the word may be provided or received by other memory devices in parallel.

According to some examples, memory device(s) <NUM> may be disposed directly on a motherboard or host system platform (e.g., a PCB (printed circuit board) on which processor <NUM> is disposed) of a computing device. Memory device(s) <NUM> may be organized into memory module(s) <NUM>. In some examples, memory module(s) <NUM> may represent dual inline memory modules (DIMMs). In some examples, memory module(s) <NUM> may represent other organizations or configurations of multiple memory devices that share at least a portion of access or control circuitry, which can be a separate circuit, a separate device, or a separate board from the host system platform. In some examples, memory module(s) <NUM> may include multiple memory device(s) <NUM>, and memory module(s) <NUM> may include support for multiple separate channels to the included memory device(s) <NUM> disposed on them.

In some examples, memory device(s) <NUM> may be incorporated into a same package as memory controller <NUM>. For example, incorporated in a multi-chip-module (MCM), a package-on-package with through-silicon via (TSV), or other techniques or combinations. Similarly, in some examples, memory device(s) <NUM> may be incorporated into memory module(s) <NUM>, which themselves may be incorporated into the same package as memory controller <NUM>. It will be appreciated that for these and other examples, memory controller <NUM> may be part of or integrated with processor <NUM>.

As shown in <FIG>, in some examples, memory device(s) <NUM> include memory resources <NUM>. Memory resources <NUM> may represent individual arrays of memory locations or storage locations for data. Memory resources <NUM> may be managed as rows of data, accessed via wordline (rows) and bitline (individual bits within a row) control. Memory resources <NUM> may be organized as separate channels, ranks, and banks of memory. Channels may refer to independent control paths to storage locations within memory device(s) <NUM>. Ranks may refer to common locations across multiple memory devices (e.g., same row addresses within different memory devices). Banks may refer to arrays of memory locations within a given memory device of memory device(s) <NUM>. Banks may be divided into sub-banks with at least a portion of shared circuitry (e.g., drivers, signal lines, control logic) for the sub-banks, allowing separate addressing and access. It will be understood that channels, ranks, banks, sub-banks, bank groups, or other organizations of the memory locations, and combinations of the organizations, can overlap in their application to access memory resources <NUM>. For example, the same physical memory locations can be accessed over a specific channel as a specific bank, which can also belong to a rank. Thus, the organization of memory resources <NUM> may be understood in an inclusive, rather than exclusive, manner.

According to some examples, as shown in <FIG>, memory device(s) <NUM> include one or more register(s) <NUM>. Register(s) <NUM> may represent one or more storage devices or storage locations that provide configuration or settings for operation memory device(s) <NUM>. In one example, register(s) <NUM> may provide a storage location for memory device(s) <NUM> to store data for access by memory controller <NUM> as part of a control or management operation. For example, register(s) <NUM> may include one or more mode registers (MRs) and/or may include one or more multipurpose registers.

In some examples, writing to or programming one or more registers of register(s) <NUM> may configure memory device(s) <NUM> to operate in different "modes". For these examples, command information written to or programmed to the one or more register may trigger different modes within memory device(s) <NUM>. Additionally, or in the alternative, different modes can also trigger different operations from address information or other signal lines depending on the triggered mode. Programmed settings of register(s) <NUM> may indicate or trigger configuration of I/O settings. For example, configuration of timing, termination, on-die termination (ODT), driver configuration, or other I/O settings.

According to some examples, memory device(s) <NUM> includes ODT <NUM> as part of the interface hardware associated with I/O interface circuitry <NUM>. ODT <NUM> may provide settings for impedance to be applied to the interface to specified signal lines. For example, ODT <NUM> may be configured to apply impedance to signal lines include in DQ <NUM> or CMD <NUM>. The ODT settings for ODT <NUM> may be changed based on whether a memory device of memory device(s) <NUM> is a selected target of an access operation or a non-target memory device. ODT settings for ODT <NUM> may affect timing and reflections of signaling on terminated signal lines included in, for example, CMD <NUM> or DQ <NUM>. Control over ODT setting for ODT <NUM> can enable higher-speed operation with improved matching of applied impedance and loading. Impedance and loading may be applied to specific signal lines of I/O interface circuitry <NUM>, <NUM> (e.g., CMD <NUM> and DQ <NUM>) and is not necessarily applied to all signal lines.

In some examples, as shown in <FIG>, memory device(s) <NUM> includes controller <NUM>. Controller <NUM> may represent control logic within memory device(s) <NUM> to control internal operations within memory device(s) <NUM>. For example, controller <NUM> decodes commands sent by memory controller <NUM> and generates internal operations to execute or satisfy the commands. Controller <NUM> may be referred to as an internal controller and is separate from memory controller <NUM> of the host. Controller <NUM> may include logic and/or features to determine what mode is selected based on programmed or default settings indicated in register(s) <NUM> and configure the internal execution of operations for access to memory resources <NUM> or other operations based on the selected mode. Controller <NUM> generates control signals to control the routing of bits within memory device(s) <NUM> to provide a proper interface for the selected mode and direct a command to the proper memory locations or addresses of memory resources <NUM>. Controller <NUM> includes command (CMD) logic <NUM>, which can decode command encoding received on command and address signal lines. Thus, CMD logic <NUM> can be or include a command decoder. With command logic <NUM>, memory device can identify commands and generate internal operations to execute requested commands.

Referring again to memory controller <NUM>, memory controller <NUM> includes CMD logic <NUM>, which represents logic and/or features to generate commands to send to memory device(s) <NUM>. The generation of the commands can refer to the command prior to scheduling, or the preparation of queued commands ready to be sent. Generally, the signaling in memory subsystems includes address information within or accompanying the command to indicate or select one or more memory locations where memory device(s) <NUM> should execute the command. In response to scheduling of transactions for memory device(s) <NUM>, memory controller <NUM> issues commands via I/O interface circuitry <NUM> to cause memory device(s) <NUM> to execute the commands. In some examples, controller <NUM> of memory device(s) <NUM> receives and decodes command and address information received via I/O interface circuitry <NUM> from memory controller <NUM>. Based on the received command and address information, controller <NUM> may control the timing of operations of the logic, features and/or circuitry within memory device(s) <NUM> to execute the commands. Controller <NUM> may be arranged to operate in compliance with standards or specifications such as timing and signaling requirements for memory device(s) <NUM>. Memory controller <NUM> may implement compliance with standards or specifications by access scheduling and control.

According to some examples, memory controller <NUM> includes scheduler <NUM>, which represents logic and/or features to generate and order transactions to send to memory device(s) <NUM>. From one perspective, the primary function of memory controller <NUM> could be said to schedule memory access and other transactions to memory device(s) <NUM>. Such scheduling can include generating the transactions themselves to implement the requests for data by processor <NUM> and to maintain integrity of the data (e.g., such as with commands related to refresh). Transactions can include one or more commands, and result in the transfer of commands or data or both over one or multiple timing cycles such as clock cycles or unit intervals. Transactions can be for access such as read or write or related commands or a combination, and other transactions can include memory management commands for configuration, settings, data integrity, or other commands or a combination.

In some examples, memory controller <NUM> includes refresh (REF) logic <NUM>. REF logic <NUM> may be used for memory resources that are volatile and need to be refreshed to retain a deterministic state. REF logic <NUM>, for example, may indicate a location for refresh, and a type of refresh to perform. REF logic <NUM> may trigger self-refresh within memory device(s) <NUM> or execute external refreshes which can be referred to as auto refresh commands by sending refresh commands, or a combination. According to some examples, system <NUM> supports all bank refreshes as well as per bank refreshes. All bank refreshes cause the refreshing of banks within all memory device(s) <NUM> coupled in parallel. Per bank refreshes cause the refreshing of a specified bank within a specified memory device of memory device(s) <NUM>. In some examples, controller <NUM> within memory device(s) <NUM> includes a REF logic <NUM> to apply refresh within memory device(s) <NUM>. REF logic <NUM>, for example, may generate internal operations to perform refresh in accordance with an external refresh received from memory controller <NUM>. REF logic <NUM> may determine if a refresh is directed to memory device(s) <NUM> and determine what memory resources <NUM> to refresh in response to the command.

According to some examples, memory controller <NUM> includes I/O training circuitry <NUM>. I/O training circuitry <NUM> refers to circuitry in memory controller <NUM> to execute training of I/O interconnections between memory controller <NUM> and memory device(s) <NUM>. Training can refer to the application of different settings to determine a setting that provides improved signaling quality. Training may include an iterative operation to test different settings, which includes voltage settings, timing settings, or other settings, or a combination. I/O training circuitry <NUM> may set the parameters associated with transceivers of I/O interface circuitry <NUM> and I/O interface circuitry <NUM>. In some examples, I/O training circuitry <NUM> enables command bus signal training for signal lines included in CMD <NUM>.

Training refers to testing and setting of electrical parameters or timing parameters or both that control a data signal eye. The data signal eye refers to timing and shape of rising and falling edges, on average, for a signal received on one or more signal lines. The height and width of the eye provides compliance with timing and voltage level requirements needed to trigger a logic value on the one or more signal lines or a change in logic value, or both. Command bus training may be in accordance with any example of command bus or C/A bus training described herein. In some examples, I/O training circuitry <NUM> may provide for a command bus training mode in accordance with any example described herein.

In some examples, memory device(s) <NUM> include I/O sampling and feedback logic <NUM>. I/O sampling and feedback logic <NUM>. I/O training circuitry <NUM> may work in coordination with CMD logic <NUM> to enable the testing of various signaling parameters to train signals routed via various signal lines coupled between memory controller <NUM> and memory device(s) <NUM>. I/O sampling and feedback logic <NUM> may sample these various signal lines during training and provide feedback to memory controller <NUM> to identify what settings provide signaling characteristics that will enable memory controller <NUM> and memory device(s) <NUM> to exchange information, such as commands from memory controller <NUM> and data written to or received from memory device(s) <NUM>.

According to some examples, based on a command from CMD logic <NUM>, memory device(s) <NUM> enter a command bus training mode. If memory device(s) <NUM> are arranged or configured to operate according to the proposed DDR5 specification, the command bus training mode may be CATM as described in more detail below. If memory device(s) <NUM> are arranged or configured to operate according to the LPDDR4 or LPDDR5 specifications, the command bus training mode may be an LPDDR4/LPDDR5 CBT mode. As described more below, either type of command bus training mode may enable a system such as system <NUM> to train a CA signal routed over command bus signal lines to one or more memory devices such as CA signals routed over signal lines included in CMD <NUM> to memory device(s) <NUM>. For example, with memory device(s) <NUM> in a command bus training mode, logic and/or features of memory controller <NUM> such as CMD logic <NUM> may cause commands and/or signals to be sent to memory device(s) <NUM> to train voltage margining, timing margining or phase margining or a combination (which can collectively be referred to as signal margining) for a CA signal routed via CMD <NUM> to align the CA signal with the memory subsystem clock signal of a clock signal included in CLK <NUM>.

Also, as described more below, command logic of a memory controller similar to CMD logic <NUM> of memory controller <NUM> may include or have access to error detecting circuitry such as I/O training circuity <NUM> that is capable of facilitating error detection of sampled signals by memory devices based on a common set of CA algorithms to generate CA patterns for both DDR5 memory devices or LPDDR4/LPDDR5 memory devices placed in respective CATM or CBT modes. For example, I/O training circuitry included within memory controller <NUM> may include at least some error checking hardware that enables CMD logic <NUM> to quickly and efficiently determine whether sampled CA patterns are correct or have one or more errors. According to some examples, this type of I/O training circuitry including or having access to error checking hardware may enable a memory controller to operate with a wider range of memory devices to include operating with DDR5 or LPDDR4/LPDDR5 memory devices utilizing a common set of CA patterns and/or CA training algorithms to train command buses for the different types of memory devices or technologies. Use of error checking hardware may also simplify coordination work for firmware or software needed when implementing command bus training for LPDDR4/LPDDR5 memory devices.

<FIG> illustrates an example system <NUM>. In some examples, as shown in <FIG>, system <NUM> includes a memory controller <NUM> and a memory device <NUM>. For these examples, also as shown in <FIG>, memory controller <NUM> includes, but is not limited to, an CMD logic <NUM>, I/O training circuitry <NUM> and I/O interface circuitry <NUM>. CLK <NUM>, CMD <NUM>, DQ <NUM> and other <NUM>, as shown in <FIG>, couple I/O interface circuitry <NUM> with I/O interface circuitry <NUM>. CLK <NUM>, CMD <NUM>, DQ <NUM> and other <NUM> may include similar signal lines and memory bus functionality as described above for CLK <NUM>, CMD <NUM>, DQ <NUM> and other <NUM> depicted in <FIG>.

In some examples, as shown in <FIG>, memory device <NUM> includes I/O sampling & feedback logic <NUM> and I/O interface circuitry <NUM>. Logic and/or features of I/O training circuitry <NUM> such as a pattern circuitry <NUM> or error detecting circuitry <NUM> may be capable of facilitating command bus training of either DDR5 or LPDDR4/<NUM> memory devices. For the example system <NUM>, memory device <NUM> may be arranged or designed to operate in compliance with the LPDDR4 specification or the LPDDR5 specification. For LPDDR4/<NUM> memory devices, CMD logic <NUM> may indicate, in some examples, that at least some compression of sampled CA patterns returned to memory controller <NUM> is needed by error detecting circuity <NUM> to provide a compressed representation of the sample CA patterns. As described more below, error detecting circuitry <NUM> may be arranged to implement various compression schemes on returned CA patterns.

According to some examples, pattern circuitry <NUM> may include programmable logic or features to enable pattern circuitry <NUM> to generate CA patterns based on one or more CA training algorithms provided by firmware or software executed by CMD logic <NUM>. For example, firmware or software executed by CMD logic <NUM> may provide the one or more CA training algorithms to pattern circuitry <NUM> to cause the generation of CA patterns. Although not shown, in <FIG>, pattern circuitry <NUM> may utilize one or more types of circuitry to cause a generation of pseudo random CA patterns such as one or more linear-feedback shift registers (LFSRs). Seed values, for example, may be indicated in one or more CA training algorithms and then used by pattern circuitry <NUM> to cause the generation of the pseudo random CA patterns. In some examples, in order to simulate impacts of complex cross talk or power delivery stress over signals routed via signal lines included in CMD <NUM> coupled between memory controller <NUM> and memory device <NUM>, pattern circuitry <NUM> may utilize multiple LFSRs. Pattern circuitry <NUM> may also create different frequency content by masking an LFSR pattern using a variable frequency square wave. Memory controller <NUM> may also enter various internal states to expose a command bus training regimen to side effects of these internal states. The internal states may include, but are not limited to, low power states or updating internal transmit settings based on temperature changes. As described in more detail below, generated patterns may be routed via command bus signal lines included in CMD <NUM> based on initiation of the CBT mode that is implemented according to the LPDDR4 or LPDDR5 specifications.

In some examples, error detecting circuitry <NUM> of I/O training circuitry <NUM> may include circuitry capable of facilitating error detection of sampled CA patterns observed by I/O sampling & feedback logic <NUM> responsive to initiation of the CBT mode. For these examples, a sampled CA pattern may be observed by I/O sampling & feedback logic <NUM> based on the CA patterns being routed via signal lines included in CMD <NUM>. The sampled CA pattern is sent back via a data bus that has signal lines included in DQ <NUM>. In one example, error detecting circuitry <NUM> may include circuitry to compress the returned sampled CA pattern to enable firmware or software executed by CMD logic <NUM> to determine whether the sampled CA pattern is correct or has one or more errors.

According to some examples, compression of the returned sampled CA pattern may include use of one or more exclusive OR (XOR) gates to compress the returned sampled CA pattern down to a single parity bit value. For these examples, pattern circuitry <NUM> may implement a CA training algorithm that causes pseudo random patterns to be generated on an even number of signal lines included in CMD <NUM> to create even parity. Thus, if the compressed sampled CA pattern generated a parity value of "<NUM>", software or firmware implemented by CMD logic <NUM> may determine that the CA pattern was sampled with no errors. If the compressed sampled CA pattern generated a parity value of "<NUM>", software or firmware implemented by CMD logic <NUM> may determine that the CA pattern was sampled with errors and corrective actions are needed (e.g., adjustments to electrical or timing parameters related to signals sent via signal lines included in CMD <NUM>).

In some examples, compression of the sampled CA pattern may include use of circuitry to calculate a cyclic redundancy check (CRC) value to represent a compressed sampled CA pattern. For these examples, pattern circuitry <NUM> may implement a CA training algorithm that has an expected M + <NUM> bit CRC value (where "M" represents any positive whole integer) for a CA pattern generated on signal lines included in CMD <NUM>. The expected M +<NUM> CRC value may be maintained by software or firmware executed by CMD logic <NUM>. When the sampled CA pattern is returned via DQ <NUM>, error detecting circuitry <NUM> calculates a CRC value for the sampled CA pattern. The CRC value may then be forwarded to the software or firmware executed by CMD logic <NUM>. The software or firmware executed by CMD logic <NUM> may then determine if the CRC value representing the compressed sampled CA pattern matches the expected M +<NUM> CRC value for the generated/sent CA pattern. If the provided CRC value matches the expected M + <NUM> CRC value, the software or firmware determines that there are no errors in the sampled CA pattern. If the provided CRC value does not match the expected M + <NUM> CRC value, the software or firmware determines that the sampled CA pattern includes errors and corrective actions are needed.

According to some examples, compression of the sampled CA pattern may include use of circuitry to generate a signature value to represent a compressed sampled CA pattern. The circuitry used to generate the signature value may include a multi-input shift register (MISR). For these examples, pattern circuitry <NUM> may implement a CA training algorithm that has an expected M + <NUM> bit signature value for a CA pattern generated on signal lanes included in CMD <NUM>. The expected M + <NUM> signature value may be maintained by software or firmware executed by CMD logic <NUM>. When the sampled CA pattern is returned via DQ <NUM>, error detecting circuitry <NUM> calculates a signature value for the sampled CA pattern by inputting sampled CA pattern into an MISR. A signature value outputted from the MISR may then be forwarded to the software or firmware executed by CMD logic <NUM>. The software or firmware executed by CMD logic <NUM> may then determine if the signature value representing the compressed sampled CA pattern matches the expected M + <NUM> signature value for the generated/sent CA pattern. If the provided signature value matches the expected M + <NUM> signature value , the software or firmware determines that there are no errors in the sampled CA pattern. If the provided signature value does not match the expected M + <NUM> signature value, the software or firmware determines that the sampled CA pattern includes errors and corrective actions are needed.

<FIG> illustrates an example system <NUM>. In some examples, as shown in <FIG>, system <NUM> includes memory controller <NUM> as described above for <FIG> and a memory device <NUM>. For these examples, CLK <NUM>, CMD <NUM>, DQ <NUM> and other <NUM> shown in <FIG> as coupling I/O interface circuitry <NUM> with I/O interface circuitry <NUM> may include similar signal lines and memory bus functionality as described above for CLK <NUM>, CMD <NUM>, DQ <NUM> and other <NUM> depicted in <FIG>.

In some examples, as mentioned previously, logic and/or features of I/O training circuitry <NUM> such as a pattern circuitry <NUM> or error detecting circuitry <NUM> may be capable of facilitating command bus training of either DDR5 or LPDDR4/<NUM> memory devices. For the example system <NUM>, memory device <NUM> may be arranged or designed to operate in compliance with the proposed DDR5 specification. For DDR5 memory devices, CMD logic <NUM> may indicate that no compression of sampled CA patterns returned to memory controller <NUM> is needed by error detecting circuity <NUM>. No compression is needed due to DDR5 memory devices including XOR circuitry at the memory devices that serve to compress sampled CA patterns. As described more below, I/O sampling & feedback logic <NUM> includes XOR circuitry <NUM> to compress sampled CA patterns at memory device <NUM>.

According to some examples, as mentioned above, pattern circuitry <NUM> may include programmable logic or features to enable pattern circuitry <NUM> to generate CA patterns based on one or more CA training algorithms provided by firmware or software executed by CMD logic <NUM>. As described in more detail below, generated patterns may be routed via command bus signal lines included in CMD <NUM> based on initiation of CATM that is implemented according to the proposed DDR5 specification.

In some examples, error detecting circuitry <NUM> of I/O training circuitry <NUM> may include circuitry capable of facilitating error detection of sampled CA patterns observed by I/O sampling & feedback logic <NUM> responsive to initiation of CATM. For these examples, the sampled CA pattern may be observed by I/O sampling & feedback logic <NUM> based the CA patterns being routed via signal lines included in CMD <NUM>. The sampled CA pattern may be compressed to a parity value by XOR circuitry <NUM> and the parity value is sent back via signal lines included in DQ <NUM>.

In one example, error detecting circuitry <NUM> may forward the parity value to software or firmware implemented by CMD logic <NUM>. Also, for these examples, pattern circuitry <NUM> may implement a CA training algorithm that causes pseudo random patterns to be generated on an even number of signal lanes included in CMD <NUM> to create even parity. Thus, if the returned parity value is "<NUM>", software or firmware implemented by CMD logic <NUM> may determine that the CA pattern was sampled with no errors. If the returned parity value is "<NUM>", software or firmware implemented by CMD logic <NUM> may determine that the CA pattern was sampled with errors and corrective actions are needed (e.g., adjustments to electrical or timing parameters related to signals sent via signal lines included in CMD <NUM>).

<FIG> and <FIG> illustrate an example diagram <NUM>. In some examples, diagram <NUM> may be timing diagram associated with implementing model command bus training (CBT) for a memory device arranged to operate incompliance with the LPDDR5 specification such as memory device <NUM> shown in <FIG> and described above. Examples are not limited to model CBT.

According to some examples, signal <NUM> represents a clock signal routed via signal lines included in CLK <NUM>, which can include a primary clock signal CK_t, and a complementary clock signal CK_c. For model CBT, the clock signal runs continuously. The timing of CLK signal <NUM> has different timing indicators, such as Ta0, Ta1,. , Td0, Td1,. , and so forth. The various sections of timing indicate timing that is not necessarily contiguous, although it may be. There are multiple breaks (BR) illustrated. The breaks are representative only. In some examples, command bus training while memory device <NUM> is implementing model CBT may establish alignment between the CK signal <NUM> and command bus (CA) signal <NUM>.

In some examples, CA signal <NUM> illustrates an example of CA signals routed via a command bus, which can include <NUM> signal lines [<NUM>:<NUM>] as shown in <FIG>. For example, the <NUM> signal lines of CA signal <NUM> may be routed through CMD <NUM> coupled between memory controller <NUM> and memory device <NUM>. The number of signal lines indicated in <FIG> is for example only.

According to some examples, logic and/or features of memory controller <NUM> may enable model CBT by issuing a first mode register write (MRW-<NUM>) command followed by a second MRW-<NUM> command as indicated in <FIG> that shows CMD signal <NUM> indicating entry into CBT. <FIG> also shows that CA signal <NUM> indicates valid MRW commands (around approximately ta0). Valid MRW commands are issued while asserting chip select (CS_n) signal <NUM> as shown in <FIG>. CMD signal <NUM> shows what command will be decoded based on the signals of CA signal <NUM>. In some examples, the MRW commands may be issued by memory controller <NUM> writing to or programming a multipurpose register of a mode register at memory device <NUM>. The model CBT MRW commands may be triggered by writing or programming a specific bit pattern to the multipurpose register.

According to some examples, WCK_t, WCK_c signal <NUM> may represent signals sent via signal lines included in CLK <NUM> that capture toggling of a state of DQ[<NUM>] signal <NUM>. In some examples, DQ[<NUM>] signal <NUM> may represent a signal line coupled to an <NUM>th pin of an <NUM> pin data bus. While DQ[<NUM>:<NUM>] signal <NUM> may represent signal lines coupled to the other <NUM> pins of the <NUM> pin data bus. For these examples, DQ[<NUM>] signal <NUM> and DQ[<NUM>:<NUM>] signal <NUM> may be included in DQ <NUM> coupled between memory controller <NUM> and memory device <NUM>.

In some examples, as shown in <FIG>, following tCAENT, CS_n signal <NUM> may be driven high while DQ[<NUM>] signal <NUM> is also driven high, and CA pattern A is sent from memory controller <NUM> via CA [<NUM>:<NUM>] signal <NUM> for command bus training as indicated by CMD signal <NUM> at around Td1 (e.g., based on patterns generated by pattern circuitry <NUM>). For these examples, a sample <NUM> may be the observed as CA pattern A. Sample <NUM>, for example, may be observed by I/O sampling & feedback logic <NUM> of memory device <NUM>. As shown in <FIG>, sample <NUM> may then be sent via DQ[<NUM>:<NUM>] signal <NUM> to indicate a resulting sampled CA pattern A at around Td4.

As shown in <FIG>, CA pattern A and its corresponding sample <NUM> is shown followed by a second CA pattern B and corresponding sample <NUM>. Also, <FIG> shows both these samples being sent via DQ[<NUM>:<NUM>] signal <NUM> at around TB0 and Td0. Examples are not limited to two CA patterns, any number of CA patterns may be received and sent while memory device <NUM> is in model CBT.

In some examples, as shown in <FIG>, first and second MRW commands are sent on CMD signal <NUM> at around tg0. For these examples, CS_n signal <NUM> is driven high and DQ[<NUM>] signal <NUM> is driven low to issue MRW-<NUM> and MRW-<NUM> commands to exit model CBT. After tMRD, memory device <NUM> may then be ready for normal operation.

<FIG> illustrates an example table <NUM>. In some examples, table <NUM> include AC parameters for command bus training for a memory device implementing model CBT as described above for diagram <NUM> in <FIG> and <FIG> and as described in the LPDDR5 specification. The AC parameters included in table <NUM> refer to the timing parameters for signaling on the signal lines while the memory device implements model CBT. For these examples, the signaling occurs with either rising or falling edges or both. The timing parameters included in table <NUM> refer to requirements to meet timing from one signal change to another, where a signal change triggers an operation by one or more logic, features or circuitry of the memory device.

Row <NUM> identifies tCBTWCKPRE_static, which represents a timing parameter that defines a static WCK period associated with toggling a DQ[<NUM>] signal. Row <NUM> identifies tWCK2DQYH, which represents a timing parameter for a set-up margin between the DQ[<NUM>] signal and a WCK_t, WCK_c signal. Row <NUM> identifies tDQ7HWCK, which represents a timing parameter for a hold margin between the DQ[<NUM>] signal and a WCK_t, WCK_c signal. Row <NUM> identifies tDQ7HCK, which represents a timing parameter for clock and command valid after the DQ[<NUM>] signal is asserted (high). Row <NUM> identifies tCHPRECS, which represents a valid clock requirement before a CS_n signal is asserted. Row <NUM> identifies tCKPSTCS, which represents a timing parameter for a valid clock requirement after the CS_n signal is asserted. Row <NUM> identifies tCAENT, which represents a timing parameter for a delay time from when the DQ[<NUM>] signal is asserted to CA bus training for a given CA pattern. Row <NUM> identifies tADR, which represents a timing parameter for an asynchronous data read. Row <NUM> identifies tCACD, which represents a timing parameter for CA bus training command to CA bus training command delay. Row <NUM> identifies tCKDQ7L, which represents a timing parameter for a CK_t, CK_c signal and a command valid via a CA [<NUM>:<NUM>] signal before the DQ[<NUM>] signal is deasserted (low). Row <NUM> identifies tDQ7LWCK, which represents a timing parameter for the DQ[<NUM>] signal being deasserted to static WCK.

The illustrated example table <NUM> indicates a minimum/maximum times in either nanoseconds (ns) or clock cycles for each parameter/symbol. In some examples, a CK cycle may be based on a CK_t, CK_c signal and a WCK cycle may be based on a WCK_t, WCK_c signal.

<FIG> illustrates an example diagram <NUM>. In some examples, diagram <NUM> may be timing diagram associated with implementing CATM for a memory device arranged to operate incompliance with the proposed DDR5 specification such as memory device <NUM> shown in <FIG> and described above.

According to some examples, signal <NUM> represents a clock signal routed via signal lines included in CLK <NUM>, which can include a primary clock signal CK_t, and a complementary clock signal CK_c. For CATM, the clock signal runs continuously. The timing of CLK signal <NUM> has different timing indicators, such as t0, t1,. , t(a+<NUM>), t(a+<NUM>),. , and so forth. The various sections of timing indicate timing that is not necessarily contiguous, although it may be. There are multiple breaks (BR) illustrated. The breaks are representative only. In some examples, command bus training while memory device <NUM> is implementing CATM may establish alignment between the CK signal <NUM> and command bus (CA) signal <NUM>.

In some examples, CA signal <NUM> illustrates an example of a CA signal routed via a command bus, which can include <NUM> signal lines [<NUM>:<NUM>] as shown in <FIG>. For example, the <NUM> signal lines of CA signal <NUM> may be routed through CMD <NUM> coupled between memory controller <NUM> and memory device <NUM>. The number of signal lines indicated in <FIG> is for example only.

According to some examples, logic and/or features of memory controller <NUM> may enable CATM by issuing a multipurpose command (MPC) as indicated by CMD signal <NUM>. CA signal <NUM> illustrates a CATM enter command (around approximately t0). CATM is exited or disabled based on asserting chip select (CS_n) signal <NUM> for <NUM> or more cycles of CK signal <NUM> (around approximately tc+<NUM> to tc+<NUM>), while sending a no operation (NOP) command via CA signal <NUM> as shown in <FIG>. CMD signal <NUM> illustrates what command will be decoded based on the signals of CA signal <NUM>. In some examples, the MPC may be issued by memory controller <NUM> writing to or programming a multipurpose register of a mode register at memory device <NUM>. The CATM enter command may be triggered by writing or programming a specific bit pattern to the multipurpose register.

In some examples, the MPC extends beyond multiple tCK cycles, during which CS_n signal <NUM> is asserted for only a single tCK cycle while in CATM. Once in CATM no other commands will be interpreted by memory device <NUM>. Memory device will only sample CA patterns sent from pattern circuitry <NUM>, generate a parity value by XOR circuitry <NUM> and send back parity values for the sampled CA patterns via DQ signal <NUM>. In some examples, as shown in <FIG>, while in CATM, memory controller <NUM> holds or maintains CA signal <NUM> at a deselect (DES) command encoding and holds CA signal at CA command when a CA pattern is not being sampled from CA signal <NUM>. As seen in CMD signal <NUM>, the difference between a DES command and a CA command is the assertion or deassertion of CS_n signal <NUM>.

According to some examples, DQS_t and DQS_c signal <NUM> represent a data strobe signal (DQS), which may include complementary DQS_t and DQS_c signals. The specific signaling of the data strobe conveyed via DQS_t and DQS_c signal <NUM> is not limiting on diagram <NUM>. CS_n signal <NUM> may represent a chip select signal for memory device <NUM>, where I/O sampling & feedback logic <NUM> may obtain multiple samples such as samples <NUM> and <NUM>. In some examples, once memory device <NUM> has CATM enabled, I/O sampling & feedback logic <NUM> samples a CA pattern sent on CA signal <NUM> on a rising CK edge, starting with a rising edge of clock signal <NUM> after a delay of tCATM_Entry, which represents a delay period that can begin after a tCATM_Entry. More or fewer samples can be used in alternate implementations.

In some examples, the delay from when samples <NUM> or <NUM> is observed to when the output of the a respective parity value (e.g., determined by XOR circuitry <NUM>) cause an output signal via DQ signal <NUM> is specified as tCATM_Valid. The time period tCATM_DQ_Window represents a period of time during which I/O sampling & feedback logic <NUM> or memory device <NUM> drives the output result of respective parity values on DQ signal <NUM> and can be shorter or longer than what is shown in <FIG>, depending on the system configuration. I/O sampling & feedback logic <NUM> may drive the outputs as indicating a value of <NUM> or <NUM> depending on the parity value. For example, as shown in <FIG>, the output on DQ signal <NUM> is "<NUM>" for sample <NUM> and "<NUM>" for sample <NUM>.

<FIG> illustrates an example table <NUM>. In some examples, table <NUM> include AC parameters for command bus training for a memory device implementing CATM as described above for diagram <NUM> in <FIG> and in the proposed DDR5 specification. The AC parameters included in table <NUM> refer to the timing parameters for signaling on the signal lines while the memory device implements CATM. For these examples, the signaling occurs with either rising or falling edges or both. The timing parameters included in table <NUM> refer to requirements to meet timing from one signal change to another, where a signal change triggers an operation by one or more logic, features or circuitry of the memory device.

Row <NUM> identifies tCATM_Entry, which represents a timing parameter that defines a delay or window or time between registration of the CATM entry command and the start of obtaining samples for command bus training. Row <NUM> identifies tCATM_Exit, which represents a timing parameter that defines a time between registration of the CATM exit command and the end of CATM. Row <NUM> identifies tCATM_Exit_Delay, which represents a timing parameter that defines a delay time after a CATM exit indication. Row <NUM> identifies tCATM_Valid, which represents a timing parameter from sample evaluation to output of the sample evaluation results on a data bus (DQ). For rows <NUM> and <NUM> a minimum time of <NUM> nanoseconds (ns) is indicated. For rows <NUM> and <NUM>, respective maximum times of <NUM> ns and <NUM> ns are indicated.

Row <NUM> identifies tCATM_DQ_Window, which represents a time that the output is available on the data bus (DQ). The time the output is available defines a window during which a memory controller can read the result. The illustrated example table indicates a minimum time available of <NUM> nCK or two clock cycles.

Row <NUM> identifies tCATM_CS_Exit, which represents a time that the CS_n signal is held low to register an exit command. Reference to holding the CS_n signal low can refer to an operation by a memory controller to drive a logic low on the CS_n signal line. In the example of table <NUM>, both parameters are illustrated as having a minimum time of <NUM> nCK and a maximum time of <NUM> nCK.

Included herein is a logic flows representative of example methodologies for performing novel aspects of the disclosed architecture. While, for purposes of simplicity of explanation, the one or more methodologies shown herein are shown and described as a series of acts, those skilled in the art will understand and appreciate that the methodologies are not limited by the order of acts. Some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram.

A logic flow and or portions of a logic flow may be implemented in software, firmware, and/or hardware. In software and firmware embodiments, a logic flow may be implemented by computer executable instructions stored on at least one non-transitory computer readable medium or machine readable medium, such as an optical, magnetic or semiconductor storage.

<FIG> illustrates an example logic flow <NUM>. As shown in <FIG>, logic flow <NUM> may include actions by a memory controller (e.g., memory controller <NUM>) and either a DDR memory device (e.g. memory device <NUM>) or an LPDDR5 memory device (e.g. memory device <NUM> during command bus (CA) training). In some examples, the memory controller trains an I/O interface between the memory controller and a memory device in response to a reset or initialization condition, <NUM>. For these examples, the chip select (CS) signal line is trained separately from other signal lines of the command bus of the I/O interface, <NUM>. According to some examples, the memory controller, based on memory type, sends a command or sequence of commands to the memory device to trigger entry into a command bus training mode, <NUM>. In response to the trigger, a DDR5 memory device enters CA training mode (CATM), 808A or an LPDDR5 memory device enters a command bus training (CBT) mode, 808B.

while the memory device is in a CA training mode, the memory controller drives a CA pattern on the command bus, <NUM>. The memory device samples the CA pattern, 812A/B. If the memory device is the DDR5 memory device, XOR circuitry at the DDR5 memory may XOR the sampled CA pattern, 812A and then output a parity value on a data bus to represent a compressed sampled CA pattern, 816A. If the memory device is the LPDDR5 memory device, the full sampled CA pattern is output on the data bus, 816B.

The memory controller reads the data bus, <NUM>. If what is read from the data bus is a CA sampled pattern, <NUM> pat. branch, the memory controller utilizes error detecting circuitry to compress the CA sampled pattern, <NUM> (e.g., to an XOR parity value, a CRC value or a signature value). The memory device evaluates the compressed value for an indication that the CA pattern was sampled correctly, <NUM>. If the memory controller determines the CA pattern was not sampled correctly, <NUM> No branch, the memory controller causes the memory device to change at least one I/O interface parameter and repeats driving the CA pattern on the CA bus, <NUM>.

According to some examples, if the command bus (CB) is trained, <NUM> Yes branch, the memory controller triggers an exit from command bus training, <NUM>. In response to triggering the exit of command bus training, the DDR5 memory device exits CATM and sets its parameters for the trained command bus, 830A or the LPDDR5 memory device exits CBT mode and sets its parameters for the trained command bus, 830B. In some examples, after training the command bus, the memory controller may separately train the data bus for data patterns written to the memory device, <NUM>.

<FIG> illustrates an example system <NUM>. In some examples, system <NUM> may be a computing system in which a memory system may implement a CA training mode. System <NUM> represents a computing device in accordance with any example described herein, and can be a laptop computer, a desktop computer, a tablet computer, a server, a gaming or entertainment control system, a scanner, copier, printer, routing or switching device, embedded computing device, a smartphone, a wearable device, an internet-of-things device or other electronic device.

System <NUM> includes processor <NUM>, which provides processing, operation management, and execution of instructions for system <NUM>. Processor <NUM> can include any type of microprocessor, central processing unit (CPU), graphics processing unit (GPU), processing core, or other processing hardware to provide processing for system <NUM>, or a combination of processors. Processor <NUM> controls the overall operation of system <NUM>, and can be or include, one or more programmable general-purpose or special-purpose microprocessors, digital signal processors (DSPs), programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or the like, or a combination of such devices.

In one example, system <NUM> includes interface <NUM> coupled to processor <NUM>, which can represent a higher speed interface or a high throughput interface for system components that needs higher bandwidth connections, such as memory subsystem <NUM> or graphics interface components <NUM>. Interface <NUM> represents an interface circuit, which can be a standalone component or integrated onto a processor die. Where present, graphics interface <NUM> interfaces to graphics components for providing a visual display to a user of system <NUM>. In one example, graphics interface <NUM> can drive a high definition (HD) display that provides an output to a user. High definition can refer to a display having a pixel density of approximately <NUM> PPI (pixels per inch) or greater and can include formats such as full HD (e.g., 1080p), retina displays, <NUM> (ultra-high definition or UHD), or others. In one example, the display can include a touchscreen display. In one example, graphics interface <NUM> generates a display based on data stored in memory <NUM> or based on operations executed by processor <NUM> or both. In one example, graphics interface <NUM> generates a display based on data stored in memory <NUM> or based on operations executed by processor <NUM> or both.

Memory subsystem <NUM> represents the main memory of system <NUM> and provides storage for code to be executed by processor <NUM>, or data values to be used in executing a routine. Memory <NUM> of memory subsystem <NUM> may include one or more memory devices such as read-only memory (ROM), flash memory, one or more varieties of random access memory (RAM) such as DRAM, or other memory devices, or a combination of such devices. Memory <NUM> stores and hosts, among other things, operating system (OS) <NUM> to provide a software platform for execution of instructions in system <NUM>. Additionally, applications <NUM> can execute on the software platform of OS <NUM> from memory <NUM>. Applications <NUM> represent programs that have their own operational logic to perform execution of one or more functions. Processes <NUM> represent agents or routines that provide auxiliary functions to OS <NUM> or one or more applications <NUM> or a combination. OS <NUM>, applications <NUM>, and processes <NUM> provide software logic to provide functions for system <NUM>. In one example, memory subsystem <NUM> includes memory controller <NUM>, which is a memory controller to generate and issue commands to memory <NUM>. It will be understood that memory controller <NUM> could be a physical part of processor <NUM> or a physical part of interface <NUM>. For example, memory controller <NUM> can be an integrated memory controller, integrated onto a circuit with processor <NUM>.

While not specifically illustrated, it will be understood that system <NUM> can include one or more buses or bus systems between devices, such as a memory bus, a graphics bus, interface buses, or others. Buses or other signal lines can communicatively or electrically couple components together, or both communicatively and electrically couple the components. Buses can include physical communication lines, point-to-point connections, bridges, adapters, controllers, or other circuitry or a combination. Buses can include, for example, one or more of a system bus, a Peripheral Component Interconnect (PCI) bus, a HyperTransport or industry standard architecture (ISA) bus, a small computer system interface (SCSI) bus, a universal serial bus (USB), or an Institute of Electrical and Electronics Engineers (IEEE) standard <NUM> bus.

In one example, system <NUM> includes interface <NUM>, which can be coupled to interface <NUM>. Interface <NUM> can be a lower speed interface than interface <NUM>. In one example, interface <NUM> represents an interface circuit, which can include standalone components and integrated circuitry. In one example, multiple user interface components or peripheral components, or both, couple to interface <NUM>. Network interface <NUM> provides system <NUM> the ability to communicate with remote devices (e.g., servers or other computing devices) over one or more networks. Network interface <NUM> can include an Ethernet adapter, wireless interconnection components, cellular network interconnection components, USB (universal serial bus), or other wired or wireless standards-based or proprietary interfaces. Network interface <NUM> can exchange data with a remote device, which can include sending data stored in memory or receiving data to be stored in memory.

In one example, system <NUM> includes one or more input/output (I/O) interface(s) <NUM>. I/O interface(s) <NUM> can include one or more interface components through which a user interacts with system <NUM> (e.g., audio, alphanumeric, tactile/touch, or other interfacing). Peripheral interface <NUM> can include any hardware interface not specifically mentioned above. Peripherals refer generally to devices that connect dependently to system <NUM>. A dependent connection is one where system <NUM> provides the software platform or hardware platform or both on which operation executes, and with which a user interacts.

In one example, system <NUM> includes storage subsystem <NUM> to store data in a nonvolatile manner. In one example, in certain system implementations, at least certain components of storage subsystem <NUM> can overlap with components of memory subsystem <NUM>. Storage subsystem <NUM> includes storage device(s) <NUM>, which can be or include any conventional medium for storing large amounts of data in a nonvolatile manner, such as one or more magnetic, solid state, or optical based disks, or a combination. Storage device(s) <NUM> holds code or instructions and data <NUM> in a persistent state (i.e., the value is retained despite interruption of power to system <NUM>). Storage device(s) <NUM> can be generically considered to be a "memory," although memory <NUM> is typically the executing or operating memory to provide instructions to processor <NUM>. Whereas storage device(s) <NUM> is nonvolatile, memory <NUM> can include volatile memory (i.e., the value or state of the data is indeterminate if power is interrupted to system <NUM>). In one example, storage subsystem <NUM> includes controller <NUM> to interface with storage device(s) <NUM>. In one example controller <NUM> is a physical part of interface <NUM> or processor <NUM> or can include circuits or logic in both processor <NUM> and interface <NUM>.

Power source <NUM> provides power to the components of system <NUM>. More specifically, power source <NUM> typically interfaces to one or multiple power supplies <NUM> in system <NUM> to provide power to the components of system <NUM>. In one example, power supply <NUM> includes an AC to DC (alternating current to direct current) adapter to plug into a wall outlet. Such AC power can be renewable energy (e.g., solar power) power source <NUM>. In one example, power source <NUM> includes a DC power source, such as an external AC to DC converter. In one example, power source <NUM> or power supply <NUM> includes wireless charging hardware to charge via proximity to a charging field. In one example, power source <NUM> can include an internal battery or fuel cell source.

In one example, memory subsystem <NUM> includes CA training logic <NUM>. CA training logic <NUM> may include logic at memory controller <NUM> to trigger a CA or command bus training mode and send signals to train a CA signal line. Memory <NUM> may include logic to provide feedback in response to CA patterns driven on the CA signal line. In CA training mode, memory <NUM> may indicate a compressed sampled value or the full CA pattern sampled in response to a given CA pattern driven on the CA signal line. The CA training may be in accordance with any example described herein.

<FIG> illustrates an example device <NUM>. In some examples, device <NUM> may be a mobile device in which a memory system may implement a CA training mode. Device <NUM> represents a mobile computing device, such as a computing tablet, a mobile phone or smartphone, a wireless-enabled e-reader, wearable computing device, an internet-of-things device or other mobile device, or an embedded computing device. It will be understood that certain of the components are shown generally, and not all components of such a device are shown in device <NUM>.

Device <NUM> includes processor <NUM>, which performs the primary processing operations of device <NUM>. Processor <NUM> can include one or more physical devices, such as microprocessors, application processors, microcontrollers, programmable logic devices, or other processing means. The processing operations performed by processor <NUM> include the execution of an operating platform or operating system on which applications and device functions are executed. The processing operations include operations related to I/O (input/output) with a human user or with other devices, operations related to power management, operations related to connecting device <NUM> to another device, or a combination. The processing operations can also include operations related to audio I/O, display I/O, or other interfacing, or a combination. Processor <NUM> can execute data stored in memory. Processor <NUM> can write or edit data stored in memory.

In one example, device <NUM> includes one or more sensors <NUM>. Sensors <NUM> represent embedded sensors or interfaces to external sensors, or a combination. Sensors <NUM> enable device <NUM> to monitor or detect one or more conditions of an environment or a device in which device <NUM> is implemented. Sensors <NUM> can include environmental sensors (such as temperature sensors, motion detectors, light detectors, cameras, chemical sensors (e.g., carbon monoxide, carbon dioxide, or other chemical sensors)), pressure sensors, accelerometers, gyroscopes, medical or physiology sensors (e.g., biosensors, heart rate monitors, or other sensors to detect physiological attributes), or other sensors, or a combination. Sensors <NUM> can also include sensors for biometric systems such as fingerprint recognition systems, face detection or recognition systems, or other systems that detect or recognize user features. Sensors <NUM> should be understood broadly, and not limiting on the many different types of sensors that could be implemented with device <NUM>. In one example, one or more sensors <NUM> couples to processor <NUM> via a frontend circuit integrated with processor <NUM>. In one example, one or more sensors <NUM> couples to processor <NUM> via another component of device <NUM>.

In one example, device <NUM> includes audio subsystem <NUM>, which represents hardware (e.g., audio hardware and audio circuits) and software (e.g., drivers, codecs) components associated with providing audio functions to the computing device. Audio functions can include speaker or headphone output, as well as microphone input. Devices for such functions can be integrated into device <NUM> or connected to device <NUM>. In one example, a user interacts with device <NUM> by providing audio commands that are received and processed by processor <NUM>.

Display subsystem <NUM> represents hardware (e.g., display devices) and software components (e.g., drivers) that provide a visual display for presentation to a user. In one example, the display includes tactile components or touchscreen elements for a user to interact with the computing device. Display subsystem <NUM> includes display interface <NUM>, which includes the particular screen or hardware device used to provide a display to a user. In one example, display interface <NUM> includes logic separate from processor <NUM> (such as a graphics processor) to perform at least some processing related to the display. In one example, display subsystem <NUM> includes a touchscreen device that provides both output and input to a user. In one example, display subsystem <NUM> includes a high definition (HD) display that provides an output to a user. High definition can refer to a display having a pixel density of approximately <NUM> PPI (pixels per inch) or greater and can include formats such as full HD (e.g., 1080p), retina displays, <NUM> (ultra-high definition or UHD), or others. In one example, display subsystem includes a touchscreen display. In one example, display subsystem <NUM> generates display information based on data stored in memory or based on operations executed by processor <NUM> or both.

I/O controller <NUM> represents hardware devices and software components related to interaction with a user. I/O controller <NUM> can operate to manage hardware that is part of audio subsystem <NUM>, or display subsystem <NUM>, or both. Additionally, I/O controller <NUM> illustrates a connection point for additional devices that connect to device <NUM> through which a user might interact with the system. For example, devices that can be attached to device <NUM> might include microphone devices, speaker or stereo systems, video systems or other display device, keyboard or keypad devices, or other I/O devices for use with specific applications such as card readers or other devices.

As mentioned above, I/O controller <NUM> can interact with audio subsystem <NUM> or display subsystem <NUM> or both. For example, input through a microphone or other audio device can provide input or commands for one or more applications or functions of device <NUM>. Additionally, audio output can be provided instead of or in addition to display output. In another example, if display subsystem includes a touchscreen, the display device also acts as an input device, which can be at least partially managed by I/O controller <NUM>. There can also be additional buttons or switches on device <NUM> to provide I/O functions managed by I/O controller <NUM>.

In one example, I/O controller <NUM> manages devices such as accelerometers, cameras, light sensors or other environmental sensors, gyroscopes, global positioning system (GPS), or other hardware that can be included in device <NUM>, or sensors <NUM>. The input can be part of direct user interaction, as well as providing environmental input to the system to influence its operations (such as filtering for noise, adjusting displays for brightness detection, applying a flash for a camera, or other features).

In one example, device <NUM> includes power management <NUM> that manages battery power usage, charging of the battery, and features related to power saving operation. Power management <NUM> manages power from power source <NUM>, which provides power to the components of device <NUM>. In one example, power source <NUM> includes an AC to DC (alternating current to direct current) adapter to plug into a wall outlet. Such AC power can be renewable energy (e.g., solar power, motion based power). In one example, power source <NUM> includes only DC power, which can be provided by a DC power source, such as an external AC to DC converter. In one example, power source <NUM> includes wireless charging hardware to charge via proximity to a charging field. In one example, power source <NUM> can include an internal battery or fuel cell source.

Memory subsystem <NUM> includes memory device(s) <NUM> for storing information in device <NUM>. Memory subsystem <NUM> can include nonvolatile (state does not change if power to the memory device is interrupted) or volatile (state is indeterminate if power to the memory device is interrupted) memory devices, or a combination. Memory subsystem <NUM> can store application data, user data, music, photos, documents, or other data, as well as system data (whether long-term or temporary) related to the execution of the applications and functions of device <NUM>. In one example, memory subsystem <NUM> includes memory controller <NUM> (which could also be considered part of the control of device <NUM> and could potentially be considered part of processor <NUM>). Memory controller <NUM> includes a scheduler to generate and issue commands to control access to memory device(s) <NUM>.

Connectivity <NUM> includes hardware devices (e.g., wireless or wired connectors and communication hardware, or a combination of wired and wireless hardware) and software components (e.g., drivers, protocol stacks) to enable device <NUM> to communicate with external devices. The external device could be separate devices, such as other computing devices, wireless access points or base stations, as well as peripherals such as headsets, printers, or other devices. In one example, device <NUM> exchanges data with an external device for storage in memory or for display on a display device. The exchanged data can include data to be stored in memory, or data already stored in memory, to read, write, or edit data.

Connectivity <NUM> can include multiple different types of connectivity. To generalize, device <NUM> is illustrated with cellular connectivity <NUM> and wireless connectivity <NUM>. Cellular connectivity <NUM> refers generally to cellular network connectivity provided by wireless carriers, such as provided via GSM (global system for mobile communications) or variations or derivatives, CDMA (code division multiple access) or variations or derivatives, TDM (time division multiplexing) or variations or derivatives, LTE (long term evolution - also referred to as "<NUM>"), or other cellular service standards. Wireless connectivity <NUM> refers to wireless connectivity that is not cellular and can include personal area networks (such as Bluetooth), local area networks (such as WiFi), or wide area networks (such as WiMax), or other wireless communication, or a combination. Wireless communication refers to transfer of data through the use of modulated electromagnetic radiation through a non-solid medium. Wired communication occurs through a solid communication medium.

Peripheral connections <NUM> include hardware interfaces and connectors, as well as software components (e.g., drivers, protocol stacks) to make peripheral connections. It will be understood that device <NUM> could both be a peripheral device ("to" <NUM>) to other computing devices, as well as have peripheral devices ("from" <NUM>) connected to it. Device <NUM> commonly has a "docking" connector to connect to other computing devices for purposes such as managing (e.g., downloading, uploading, changing, synchronizing) content on device <NUM>. Additionally, a docking connector can allow device <NUM> to connect to certain peripherals that allow device <NUM> to control content output, for example, to audiovisual or other systems.

In addition to a proprietary docking connector or other proprietary connection hardware, device <NUM> can make peripheral connections <NUM> via common or standards-based connectors. Common types can include a Universal Serial Bus (USB) connector (which can include any of a number of different hardware interfaces), DisplayPort including MiniDisplayPort (MDP), High Definition Multimedia Interface (HDMI), Firewire, or other type.

In one example, memory subsystem <NUM> includes CA training logic <NUM>. CA training logic <NUM> may include logic at memory controller <NUM> to trigger a CA or command bus training mode and send signals to train a CA signal line. Memory <NUM> may include logic provide feedback in response to CA patterns driven on the CA signal line. In the CA training mode, memory <NUM> may indicate a compressed sampled value or the full CA pattern sampled in response to a given CA pattern driven on the CA signal line. The CA training mode may be in accordance with any example described herein.

One or more aspects of at least one example may be implemented by representative instructions stored on at least one machine-readable medium which represents various logic within the processor, which when read by a machine, computing device or system causes the machine, computing device or system to fabricate logic to perform the techniques described herein. Such representations, known as "IP cores" and may be similar to IP blocks. IP cores may be stored on a tangible, machine readable medium and supplied to various customers or manufacturing facilities to load into the fabrication machines that actually make the logic or processor.

Various examples may be implemented using hardware elements, software elements, or a combination of both. In some examples, hardware elements may include devices, components, processors, microprocessors, circuits, circuit elements (e.g., transistors, resistors, capacitors, inductors, and so forth), integrated circuits, ASICs, PLDs, DSPs, FPGAs, memory units, logic gates, registers, semiconductor device, chips, microchips, chip sets, and so forth. In some examples, software elements may include software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, APIs, instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof. Determining whether an example is implemented using hardware elements and/or software elements may vary in accordance with any number of factors, such as desired computational rate, power levels, heat tolerances, processing cycle budget, input data rates, output data rates, memory resources, data bus speeds and other design or performance constraints, as desired for a given implementation.

Some examples may include an article of manufacture or at least one computer-readable medium. A computer-readable medium may include a non-transitory storage medium to store logic. In some examples, the non-transitory storage medium may include one or more types of computer-readable storage media capable of storing electronic data, including volatile memory or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writeable or re-writeable memory, and so forth. In some examples, the logic may include various software elements, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, procedures, software interfaces, API, instruction sets, computing code, computer code, code segments, computer code segments, words, values, symbols, or any combination thereof.

According to some examples, a computer-readable medium may include a non-transitory storage medium to store or maintain instructions that when executed by a machine, computing device or system, cause the machine, computing device or system to perform methods and/or operations in accordance with the described examples. The instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. The instructions may be implemented according to a predefined computer language, manner or syntax, for instructing a machine, computing device or system to perform a certain function. The instructions may be implemented using any suitable high-level, low-level, object-oriented, visual, compiled and/or interpreted programming language.

Some examples may be described using the expression "in one example" or "an example" along with their derivatives. These terms mean that a particular feature, structure, or characteristic described in connection with the example is included in at least one example. The appearances of the phrase "in one example" in various places in the specification are not necessarily all referring to the same example.

Some examples may be described using the expression "coupled" and "connected" along with their derivatives. For example, descriptions using the terms "connected" and/or "coupled" may indicate that two or more elements are in direct physical or electrical contact with each other. The term "coupled" or "coupled with", however, may also mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.

Claim 1:
A system (<NUM>) comprising:
a memory device (<NUM>) configured to include a command and address, CA, interface and a DQ interface (<NUM>);
a command bus (<NUM>) configured to couple with the CA interface;
a data bus configured to couple with the DQ interface;
a memory controller (<NUM>) configured to couple with the command bus and the data bus, the memory controller to include:
a controller logic (<NUM>) configured to generate a first command to trigger the memory device to enter one of a first command bus training mode or a second command bus training mode to train the CA interface; and
input/output, I/O, circuitry (<NUM>) configured to:
cause a CA pattern to be output via the command bus;
receive a sampled CA pattern from the memory device via the data bus, compress the sampled CA pattern to generate a first compressed value, if the memory device is in the first command bus training mode, and forward the first compressed value to the controller logic; and
forward a second compressed value received from the memory device via the data bus, the second compressed value to represent the sampled CA pattern compressed at the memory device, if the memory device is in the second command bus training mode.