Patent Description:
<NPL>, discloses a noninterference, fine-grained, stealthy physical side-channel attack on hardware enclaves based on snooping the address lines of the memory bus off-chip.

The invention provides a method of claim <NUM>, an apparatus of claim <NUM>, and a computer-readable medium of claim <NUM>.

The details of one or more aspects of embedding data in address streams are described in this document with reference to the following drawings. The same numbers are used throughout the drawings to reference like features and components.

Techniques and devices are described for embedding data within an address stream on an interconnect, such as a memory bus of a computer. Here, physical lines that communicate an address stream can be made to communicate data, which is interspersed amongst or referenced through bits of the address stream. Address lines of the interconnect can be dedicated or selectively employed to propagate the address stream (e.g., in a time-division manner that is shared between the address stream and a data stream). Bits of the address stream typically convey addresses (e.g., memory pages and offsets) used in execution of read or write operations; data to be read or written during their execution, however, is communicated separately through a data stream, which may be on different physical lines than the address stream. To avoid complexities in tracing a data stream contemporaneously with tracing an address stream and any command lines, the address stream is configured to occasionally carry data, which can then be automatically recorded as part of a trace of the address stream. Data detected from within this extra, logical data channel can be used to enhance the addresses and other information obtained in the memory trace, for example, to perform a function or to determine data and control dependencies, even without monitoring the data stream.

A program or system state, a thread identifier or process identifier, an instruction or program counter, and a function or task identifier are some examples of data that can be directly embedded in an address stream. To indirectly communicate the embedded data through the address stream, this data can include a pointer or reference to a mailbox or other portion of memory, which is allocated for the purpose of communicating data through the address stream.

Consider a test engineer or technician evaluating a memory for a computer through signal-trace-analysis and a memory-system simulation. Software instrumentation executing at a host or memory device may output a memory trace to a data file. Alternatively, physical probes attached to command lines or address lines may be used to send signals to a recipient that records the signals of the address stream as a trace, typically, however, without recording a corresponding data stream. The recipient of the memory trace may be a program, a logic analyzer, a routine, a system on chip (SoC), or another component or entity. The output received from the probes or software instrumentation can be recorded by the recipient in association with timestamps. The recorded signals or data file may be fed to the memory-system simulation for subsequent playback and signal-trace-analysis. The simulation's playback of the command lines and address stream offers insight into how the memory design performs when connected to a host of a computer.

Existing logic analyzers or other recipients of probed signals have a finite number of input channels. Generating a complete memory trace, including both the address stream as well as a corresponding data stream, if even possible, would require a complex logic analyzer, an excessive number of probes, and significant storage space. Useful control dependencies may be discoverable from inspection of the data stream; however, it may not be feasible to trace the data stream while also tracing the address stream and control lines because of limitations in probing or monitoring by a recipient. Ignoring the data stream is one way to curtail costs and complexities in performing signal-trace-analysis. Unfortunately, without the data stream, some data or control dependencies are undiscoverable during simulation playback. Moreover, a computer system often runs multiple programs (e.g., applications, processes) and threads with interleaved memory activity. It is therefore difficult to precisely correlate software events with memory activity without having context about the data as well as the addresses of memory activities appearing on the memory bus.

An example computing system described herein injects data directly into the address stream or indirectly by injecting an indication of the data in the address stream. The data may provide context for addresses appearing within the address stream at that point in time. The context can be recorded for use during subsequent playback and/or analysis, without requiring additional instrumentation, probes, lines, wires, pins, or other hardware, beyond that which is already used to monitor an address stream. The data can also be used to convey other information, such as a message from a program executing at the host device to a memory device or other recipient of the address stream, without modifying hardware. The data can be used to convey control dependencies, which can be used to produce more-accurate simulations, for example. When output on existing address wires of an address bus, the embedded data can be useful to validate a new memory or to control a memory in ways that addresses cannot. As such, although normally an address stream only includes addresses, the computing system is configured to occasionally embed data within its address stream, directly or indirectly, and in accordance with certain principles described herein.

The example system includes a host device connected to a memory device over an interconnect. The host device regularly sends signals over the interconnect, for example, by transmitting an address stream and control commands on address and control lines, and by transmitting a corresponding data stream on data lines. The host device sends an indication of data through the address stream, which to a logic analyzer or other recipient appears like any other address on the memory bus. The host device outputs the data onto a hidden channel, which is conceptually overlaid on the address lines and interspersed within the address stream.

Probing the address lines to trace the address stream likewise traces the data that the host device sends through the hidden channel. As such, when monitored, the data or indication of data within the hidden channel is traced in the same way addresses outside the hidden channel are preserved. To a recipient of the address stream, this embedded data can provide context or clues for debugging or for determining how the system performs. From the data, control or data dependencies, which are normally undiscoverable without a trace or understanding of a corresponding data stream, are identifiable from the trace of the address stream.

The embedded data can supplement or enhance a memory-system simulation. For example, a logic analyzer monitoring an address stream can control a function (e.g., an alarm or alert) based on the data obtained from the address stream. During playback, the simulation can omit, from a memory trace, memory traffic related to the data if the omission is desirable to conceal (e.g., from an analyzer) that data was communicated in the address stream. The memory traffic revealed during signal-trace-analysis and simulation playback can be excluded to prevent an incorrect simulation playback; memory traffic referencing embedded data may be subtracted from a memory trace before playback. While the data extracted from the address stream may be omitted from the simulated playback of the address stream, the data can be output alongside the addresses of the address stream, which can improve fidelity of a memory-system simulation. Sending data through an address stream using the techniques and devices described herein is not limited to improving memory-system simulations, however.

The techniques and devices additionally or alternatively allow data to be embedded in an address stream at any time, and for any reason, not merely to support test and evaluation. For example, some memory architectures specify dedicated input and output channels to pass tracking information over a memory bus between a host device and a memory device. Other memory devices may provide internal registers that obtain contextual data written by a host device, e.g., prefetch hints or non-cacheable address flags, which the memory devices use to complete memory operations. Although both techniques enable data communication, both also add complexity to hardware of the system, which can greatly add to costs. In contrast, a host device of an example computing system can convey data on the address lines of a memory bus, including whenever a physical sideband channel or access to a data stream is not available.

As mentioned, data can be directly or indirectly injected into the address stream. Data may be communicated directly within the address stream by causing the host device to invoke a software library function that automatically manipulates addresses being sent on the memory bus, so the addresses convey an indication of data. The software library can include an initialization function, which, when called by the host device, sends a recipient of the address stream (e.g., a memory device) information about when or how data, if embedded, will appear in the address stream. Initialization may not be necessary; performance, however, can be improved through initialization in some scenarios by effectively priming the recipient to recognize data when the data appears in the address stream. After initialization, the host device can call a send-message or send-packet function of the software library to embed in the address stream data that is input as a parameter to the function. Alternatively, the host device may use the described techniques and methods to communicate commands or other information to the memory device using data embedded in an address stream.

The indication of data embedded in an address stream may itself represent bits of information or metadata that appear to be addresses but that are not referenced to a mailbox location. If, however, a mailbox is used, a program can pre-allocate a memory area as the mailbox and share the mailbox location with the memory device, logic analyzer, or other recipient of the embedded data. This way, there does not need to be any upfront coordination between the recipient and the host device. Instead, whenever an address into the already-allocated mailbox is identified within the address stream, the recipient treats the offset bits embedded data due to the reference to the mailbox. Because the memory of the mailbox is privately allocated and owned by the program, and because the size of the mailbox may be small and contained to only one or a few pages in memory, there will likely not be any interfering or unintended memory requests within the mailbox. By establishing a mailbox and/or communicating using a checksum-which is described below, any program can establish a reliable and private mailbox for application-specific data, for example.

Embedding data directly within an address stream can be effective to transmit data from a host device to a recipient. A processor or a memory controller of a host device, or a component of a memory device, may act on data communicated through an address stream, such as by directing caches, prefetchers, or other hardware of the computer or by executing a processing-in-memory (PIM) operation. If probing the address stream, a separate physical test probe is not necessary to extract the embedded data. The recipient may include logic that recognizes a transmission of data appearing in an address stream. By monitoring the address portion of a memory bus, the logic may identify data in response to identifying a particular address pattern, which was not initiated by a test program.

Another way to embed data through an address stream is by indirectly embedding the data, such as by establishing a mailbox. Using a mailbox increases the throughput of the hidden channel, as more data can be conveyed via the mailbox in a shorter amount of time or in fewer memory-bus cycles than if the data is embedded directly. To embed data indirectly within an address stream, a program can cause a host device to allocate a contiguous portion of memory equal to an intended size (e.g., a four-kilobyte page) for the mailbox. The program may repeat a pattern of addresses (e.g., a page address with one or more offsets) in the address stream, within a particular window (e.g., a window based on time or number of address entry transmissions), to indicate where the mailbox is being designated for future data transmissions. When the pattern appears in the address stream within the allowed window, the memory or other recipient of the address stream automatically determines that all subsequent addresses that reference a page or pages of memory containing the mailbox are indications of data embedded by the program. For example, rather than an address, the address stream may carry bits that reference the mailbox and include offset bits having the embedded data. The embedded data can be obtained from the mailbox by detecting within the address stream the mailbox location (e.g., a page and/or offset of an address) and extracting the associated offset as the embedded data. A mailbox may not, however, be necessary in some example computing systems.

Optionally, an indication of data embedded in an address stream may include a checksum posing as one of the addresses within the pattern of addresses used to convey the data or the indication of data. The checksum enables the recipient to determine a correct order to parts of the data, for example, when transmission of an indication of data requires multiple memory cycles of the address stream. The ability to reorder parts is helpful in case the order is altered based on how the memory bus is managed by the memory controller of the host device and/or the memory device, each of which may be outside a sender program's control. The checksum fails if no combination of addresses in a group of addresses within the address stream can be ordered to satisfy a checksum equal to a remaining address in the group. A checksum may not be necessary in some example computing systems where reliability or the likelihood of reordering is less of a concern.

Also described herein is a messaging protocol that can be implemented independent of, or in combination with, a mailbox and checksum to convey an indication of data embedded within an address stream. The messaging protocol includes a preamble or postamble message, either of which is identifiable from a repeating pattern of addresses in the address stream, similar to identifying a mailbox. The preamble or postamble messages bound the program's indication of data, which appears as a payload message distributed across one or more memory cycles of the address stream. The preamble message represents a header or start of the payload message, and the postamble message conveys an end or tail of the payload message. Non-cacheable byte read or write instructions executed by the program can cause the repeating patterns associated with the preamble or postamble messages to be identifiable within the address stream, as a predefined distribution of addresses or a predefined distribution of deltas (e.g., inter-address differences) between addresses.

The payload message includes a sequence of addresses that encode the indication of data. The sequence of addresses belonging to the payload message appear in the address stream, after the preamble message and before the postamble message if one or both are used. These address sequences are uncommon; each has almost no chance of occurring on the memory bus as part of a series of regular memory requests. The unique sequences are thus readily detectable by a recipient of the address stream, such as a memory device or a trace-reader program. As mentioned, addresses that make up the sequence in the payload message may be reordered on the memory bus, for instance, by a memory controller. The correct sequence of addresses is attainable if the payload message includes a checksum, from which the correct order of addresses can be derived.

The messaging protocol may use a mailbox to support indirect communication of data through the address stream. Referencing the mailbox enables a sender to avoid wasting memory cycles by constantly repeating a preamble or postamble message. A program can directly embed a payload of data within the address offset bits within an address stream, for example, including one or more least-significant-bits (LSBs). Instead of actual data, the payload can represent a pointer (e.g., an address to a physical page of memory) for the mailbox that is referenced to communicate the desired data. The program may output the payload message with the mailbox-pointer between sending the preamble and postamble messages if both are used. The trace-reader program, the memory device, or other recipient of the address stream can therefore determine from the payload the page of memory allocated to the program for the mailbox. A subsequent payload message, even without a preamble or postamble message, can reference the mailbox page automatically to trigger the recipient to identify data, indirectly, by extracting the bits from an offset within a mailbox page of memory.

In some cases, a program writes data to a mailbox at runtime to communicate with a recipient. The recipient of the address stream obtains data from the mailbox when the mailbox page appears in the address stream. The mailbox can be monitored without the overhead of communicating and interpreting preamble or postamble messages once the mailbox is established. Devices monitoring the address stream can trigger internal functions that act on embedded data in response to identifying an address within the mailbox (e.g., the address of a memory page) from the address stream.

Using a predetermined mailbox, rather than establishing the mailbox through the messaging protocol, enables the sender and recipient to begin encoding and decoding embedded data more-quickly. Predetermining the mailbox avoids having to exchange a preamble message or postamble message, either of which can be anywhere in the address stream, as well as interleaved with many other unrelated memory requests. Predetermining a mailbox that is already allocated to the program may be simple and effective for some systems; however, other example systems may further promote stability, reliability, and security by bounding each payload of data with a preamble or postamble using the messaging protocol.

Whether established ahead of time or through the messaging protocol, once the location of a mailbox is determined, data can be retrieved from an address stream by accessing (e.g., reading from or writing to) the mailbox's page or other memory location. For example, the LSBs of an address to a four-kilobyte-sized page can contain up to twelve bits of data in each address of an address stream recorded for a memory trace. The minimum size of a memory (e.g., a DRAM DIMM) data transfer (sometimes referred to as a "burst") may be sixty-four (<NUM><NUM>) bytes. These six LSBs for the burst may not be communicated on the memory bus during a read or write operations. For write operations, the mailbox can be identified by monitoring write-byte-mask bits to get the LSBs back. Or if using reads, because each page may be <NUM><NUM> bits, each offset may communicate six (i.e., twelve minus six) bits of data per read.

Because it may be desirable to work with eight-bit checksums, for ease in encoding or decoding them in a computer system, some implementations may use a mailbox size larger than a 4KB page (e.g., four times larger) to reduce the number of bits used to identify the mailbox and to increase the quantity of bits used for the payload by two bits, i.e., log <NUM> (<NUM>). To achieve an eight-bit checksum, four pages of four kilobytes of memory per page may be used as a mailbox with a 16KB size. The payload messages that result from a 16KB mailbox are eight-bit "byte-sized" offsets within the mailbox, whether a given offset contains desired data or a checksum, either of which can be eight bits in such implementations. Therefore, allocating a larger mailbox that is greater in size than a single 4KB page can increase the number of offset bits available to convey embedded data, and doing so may ensure each data item or checksum in a payload message can occupy a desired number of bits, such as a byte.

<FIG> illustrates an example computer <NUM> in which various techniques and devices described in this document can operate. The computer <NUM> includes a host device <NUM>, which has one or more processors <NUM> and at least one memory controller <NUM>, and a memory device <NUM> (referred to simply as "a memory <NUM>"). In some examples, memory controller <NUM> may be an aspect of, and may reside on or within, the one or more processors <NUM>. The computer <NUM> further includes an interconnect <NUM>, which may be implemented as, for instance, a memory bus <NUM>. The computer <NUM> can be any type of computing device, computing equipment, computing system, or electronic device which can utilize a channel for embedding data in an address stream.

As shown, the host device <NUM> and the memory device <NUM> are each coupled to the memory bus <NUM>. Thus, the host device <NUM> and the memory device <NUM> are coupled one to the other via the memory bus <NUM>. The processors <NUM> execute instructions that cause the memory controller <NUM> of the host device <NUM> to send signals on the memory bus <NUM>. The host device <NUM> is configured to send an indication of data, such as a preamble message, a postamble message, a payload message, or the like as later described, within an address stream communicated on the memory bus <NUM>. This communication can include addresses as well as an indication of data, sent over the memory bus <NUM> as part of an address stream <NUM>. Put another way, the data refers to information other than a memory address for a (read or write) memory request. An indication of the data therefore, includes any machine or human recognizable feature, which appears in the address stream <NUM> to convey data, specifically, data other than an address to support a read or write memory request.

Thus, the memory bus <NUM> can include or provide a conduit for an address stream <NUM> or a data stream <NUM>, or both. The address stream <NUM> includes or can be realized using a group of address wires, and the data stream <NUM> can encompass a different group of wires of the memory bus <NUM>, referred to as data wires herein. The memory bus <NUM> can include additional wires or wireless connections; for example, a wired or wireless control bus may carry status or command signals exchanged between the host device <NUM> and the memory <NUM>. Alternatively, the interconnect or memory bus <NUM> can propagate both the address stream <NUM> and the data stream <NUM> at least partially over the same physical wire or wires. As some examples, the interconnect <NUM> can include a frontside bus, a memory bus, an internal bus, peripheral control interface (PCI) bus, etc. If the interconnect or memory bus <NUM> includes a command bus or propagates a command stream, the host device <NUM> can also or instead propagate data over the command bus or command stream.

The processors <NUM> execute a program <NUM> and, through the memory controller <NUM>, read from and write to the memory <NUM>. Executing the program <NUM> configures the processors <NUM> and the memory controller <NUM> of the host device <NUM> to communicate data <NUM> in the address stream <NUM> and on the memory bus <NUM> that is shared with the memory <NUM>. The processors <NUM> may include or may be the computer's: host processor, central processing unit (CPU), graphics processing unit (GPU), artificial intelligence (AI) processor (e.g., a neural-network accelerator), or other hardware processor or processing unit.

The memory <NUM> is illustrated as a memory for the computer <NUM>; however, the memory <NUM> can be integrated within the host device <NUM> or separate from the computer <NUM> and/or can be of various types. For example, the memory <NUM> can include an integrated circuit memory, dynamic memory, random-access memory (e.g., DRAM, SRAM), or flash memory to name just a few. Any addressable memory having identifiable locations of physical storage can be used as the memory <NUM>. Further, although the host device <NUM> and the memory device <NUM> are depicted as being discrete components, the host device <NUM>, the memory device <NUM>, and the interconnect <NUM> may alternatively be integrated on a single die (e.g., as an SoC).

A module referred to as the program <NUM>, as well as any other module described herein, may be stored in a computer-readable media or other hardware components of the computer <NUM>. Each module, including the program <NUM>, represents a set of processor-executable instructions, including software instructions, firmware instructions, or a combination thereof.

Responsive to the processors <NUM> executing the instructions defining the program <NUM>, the host device <NUM> is configured to communicate the data <NUM> in the address stream <NUM> of the memory bus <NUM>, which is shared between at least the memory <NUM> and the host device <NUM>. For example, as part of a conventional memory-write or read command issued during a first frame of memory traffic on the memory bus <NUM>, the program <NUM> causes the processors <NUM> and the memory controller <NUM> to output addresses <NUM> in the address stream <NUM> and to output data <NUM> within the data stream <NUM>. The data <NUM> may indicate what the memory <NUM> is to store at the addresses <NUM> included in the address stream <NUM>, and alternatively, for a read, the data <NUM> may indicate what the memory <NUM> reads in the address specified in the address stream. The memory <NUM> executes the write or read command by storing the data <NUM> received on the data stream <NUM> in a storage location of the memory <NUM> that is defined by the addresses <NUM>.

In some implementations, in a subsequent frame of traffic on the memory bus <NUM>, which is described next, the program <NUM> directs the processors <NUM> and the memory controller <NUM> to output data <NUM> in the address stream <NUM>. The memory <NUM> or (as later described) a logic analyzer, which is internal or external to the computer <NUM>, is configured to determine the data <NUM> communicated through the address stream <NUM> between the memory <NUM> and the host device <NUM>. The data <NUM> is not interpreted to be a memory address for a read or write command, which is the case for the addresses <NUM> and the data <NUM>. Instead, the data <NUM> represents a payload of information, metadata in some cases, or a mailbox location through which information, such as metadata, is to be communicated.

In response to detecting the data <NUM>, the memory <NUM> may use the data <NUM> to perform a function, such as a PIM operation. A hidden channel embedded within the address stream <NUM> therefore provides an additional communication path between the memory controller <NUM> of the host device <NUM> and the memory <NUM>. When fed into a memory simulator or other platform used for processing the address stream <NUM>, the data <NUM> may cause the memory simulator or other platform to output or display an indication of the data <NUM>, for example, during playback and trace-analysis. An engineer or tester can consider the data <NUM> to aid in interpreting a trace of signaling on the memory bus <NUM> or to memory issues associated with portions of the program <NUM>. A simulator or other processing platform, including the program <NUM>, can use the data <NUM> to determine data or control dependencies between memory requests, which can enable more accurate simulation output.

The data <NUM> may include a program context indication, such as a thread identifier (TID) or a pointer to a longer thread identifier. The program <NUM> can inject the thread identifier into the hidden channel within the address stream <NUM> as the data <NUM>. For example, the thread identifier categorizes prior memory requests involving the addresses <NUM> and the data <NUM>, which appeared earlier in the trace. Alternatively, the thread identifier can precede the relevant memory requests in the address stream <NUM>. As a function of the program <NUM>, the program <NUM> can periodically direct the processors <NUM> to send the data <NUM>. When implemented at an operating system level, an operating system of the computer <NUM> can direct the host device <NUM> to send the data <NUM> on each change in process-context or each thread-context switch. The data <NUM> may be associated with a first thread or a first CPU core of the processors <NUM> in an initial frame on the memory bus <NUM>, and in a subsequent frame, the data <NUM> may originate from a different thread or a different CPU core of the processors <NUM>. When the host device <NUM> includes a cache, the thread or CPU core of the processors <NUM> that triggers a write-back might not be the same thread or CPU core of the processors <NUM> that last accessed the data. In contrast, memory-reads are triggered by a most-recent read operation, prior to the transmission of the data <NUM>. The ability to convey a thread or process identifier enables a simulator or other program to indicate through their respective outputs, requests from different threads being executed in parallel, without the simulator or other program needing to keep track of dependencies.

Including byte-loads and byte-stores (e.g., non-cacheable, input-output) issued by the program <NUM> can direct the processors <NUM> of the host device <NUM> to send the data <NUM> via the memory controller <NUM> to the memory <NUM> at a precise time or within a particular frame. Memory fencing techniques may be used to accurately position the data <NUM> within a memory trace, relative to other memory accesses recorded in the memory trace. Operations issued within a memory fence are certain to be executed by the processors <NUM> and the memory controller <NUM> prior to operations issued outside the memory fence. The program <NUM> may include or be any instrumentation, software library, or other type of module configured to inject metadata in the address stream <NUM> as the data <NUM>. Alternatively, hardware circuitry of the host device <NUM> may inject the data <NUM> into the address stream <NUM>.

In operation, the program <NUM> may inject a thread identifier into the address stream <NUM> on the memory bus <NUM>, which appears in the address trace being probed, whenever the program <NUM> switches to a new thread. The memory <NUM>, other program, or trace analyzer that receives the thread identifier determines which thread executing on the processors <NUM> of the host device <NUM> is producing the addresses for memory operations that follow. The thread identifier, along with other types of data <NUM>, are examples of context, which provides a richer trace because individual sections of the trace can be associated with different threads. This thread identifier or other data <NUM> may appear on the memory bus <NUM> before, after, or as part of a payload message, which is described with reference to <FIG> and <FIG>.

<FIG> and <FIG> illustrate aspects of communication within an address stream, in which a mailbox is referenced by data in the address stream. <FIG> illustrates mailbox communication, which involves the communicating program allocating memory for the mailbox upfront using repeated transmissions. <FIG> illustrates a messaging protocol, which utilizes preamble, payload, and/or postamble messages to convey data from one end of the address stream to the other. In the examples of <FIG> and <FIG>, time elapses in the downward direction from time <NUM> to time t.

By default, the memory <NUM> (of <FIG>) treats bits of information in the address stream <NUM>-<NUM> as addresses <NUM> for a memory request. The processors <NUM> and the memory controller <NUM> of the host device <NUM> are configured to communicate addresses <NUM> in the address stream <NUM>-<NUM> shared with the memory <NUM>. The memory <NUM> uses the addresses to read, write, or otherwise execute a memory operation with the memory <NUM>.

In some implementations, the address stream <NUM>-<NUM> can adhere to a split-transaction protocol. The split-transaction protocol allows the memory controller <NUM> and the memory <NUM> to execute groups of load and store instructions in a non-atomic way, without the program <NUM> or the processors <NUM> having to manage their execution. Operating a memory with a split-transaction protocol can facilitate efficient memory accesses.

Turning first to <FIG>, which illustrates an example mailbox <NUM> that is established in a portion of the memory <NUM> allocated in advance, before the program <NUM> embeds data <NUM>-<NUM>, <NUM>-<NUM>, or <NUM>-<NUM> in an address stream <NUM>-<NUM>. The address streams <NUM>-<NUM> and <NUM>-<NUM> are examples of the address stream <NUM>. The program <NUM> causes the computer <NUM> to allocate the mailbox <NUM> as a contiguous amount of storage at the memory <NUM>. The mailbox <NUM> may be equal to a size of a page in memory, or multiple pages of memory to increase a size of the offset and thereby increase bandwidth or improve checksum performance. To establish the mailbox <NUM>, the program <NUM> causes the host device <NUM> to send a repeating pattern (n cycles) of addresses in the address stream <NUM>-<NUM> within a window <NUM>. The window <NUM> may be established as having a particular length of time (e.g., a time window) or having a particular quantity of address entries of the address stream <NUM>-<NUM>. One address in each repeating pattern can represent a checksum for determining an order to the remaining (two in this example) addresses in the repeating pattern. The remaining addresses, when concatenated together in a particular order that satisfies the checksum, define the page or range of pages for the mailbox <NUM>. Although the addresses for the two depicted cycles are illustrated as being temporally adjacent, the addresses may alternatively be separated by other addresses, including those with addresses for memory requests or those with data that are masquerading as addresses for memory requests.

In response to detecting n repetitions of two or more address entries with a corresponding checksum, within an allowed window <NUM> of addresses, and with little or no interspersed or spurious other addresses, the memory <NUM>, a logic analyzer, or other recipient that detects the repeating pattern in the address stream <NUM>-<NUM> determines that mailbox <NUM> is dedicated to the program <NUM> for the duration of the program <NUM>. This allows the program <NUM> to establish a private mailbox for application-specific data. This can be simpler than using a preamble, payload, and/or postamble message, which is described in <FIG>, because a preamble or postamble recognition scheme can be avoided while still handling the address re-ordering by the host device <NUM> that can make a mailbox hard to decode.

As shown in <FIG>, the recipient of the address stream <NUM>-<NUM> can interpret data <NUM>-<NUM>, <NUM>-<NUM>, and <NUM>-<NUM> based on subsequent memory requests that reference the mailbox <NUM>. Because the mailbox <NUM> is contained within a privately allocated portion of the memory <NUM>, which is owned by the program <NUM>, there is not likely to be interfering, or unintended addressing to the mailbox <NUM> within the range of addresses allocated to the mailbox <NUM>.

As an alternative to establishing the mailbox <NUM> with repeated transmissions, <FIG> shows how a messaging protocol can be used to indicate the location of the mailbox <NUM>. In processing the address stream <NUM>-<NUM>, which along with address stream <NUM>-<NUM> are examples of the address stream <NUM>, a recipient can determine the mailbox <NUM> from having identified a preamble message <NUM>, a postamble message <NUM>, and/or a payload message <NUM> in-between. The address stream <NUM>-<NUM> propagates or carries data <NUM>-<NUM>, which is an example of the data <NUM>. The address stream <NUM>-<NUM> provides the mailbox <NUM>, and the address stream <NUM>-<NUM>, which occurs subsequently, references the mailbox <NUM> to communicate additional data <NUM>-<NUM> and <NUM>-<NUM>, as further examples of the data <NUM>.

In operation, the memory <NUM> determines that a current portion of the address stream <NUM>-<NUM> includes an indication of the data <NUM>-<NUM> as opposed to addresses. Responsive to determining that the current portion of the address stream <NUM>-<NUM> includes addresses <NUM> and does not include data embedded therewith, the memory <NUM> executes reads or writes to fulfill memory requests with the addresses <NUM> contained in the current portion of the address stream <NUM>-<NUM>.

In contrast, when the indication of the data <NUM>-<NUM> appears in the address stream <NUM>-<NUM>, the memory <NUM> interprets the address stream <NUM>-<NUM> differently than if it were the addresses <NUM>. Based on the data <NUM>-<NUM> appearing in the address stream <NUM>-<NUM>, the memory <NUM>-<NUM> can determine a context of a memory request or a command to perform rather than determining an address page or offset associated with a memory request. Responsive to determining that the current portion of the address stream <NUM>-<NUM> includes the data <NUM>-<NUM>, the memory <NUM> can ignore the data <NUM>-<NUM>. Alternatively, the memory <NUM> can extract the data <NUM>-<NUM> from the current portion of the address stream <NUM>-<NUM> to perform a command or save the data <NUM>-<NUM> for outputting as part of a testing scenario, which is described with reference to <FIG>. Although some of the description herein refers to the memory <NUM> or <NUM>-<NUM>, as the device processing an address stream <NUM> or taking actions based on detected data <NUM> during operation or testing, these descriptions may also or instead apply to acts performed by a logic analyzer or test equipment that is processing the address stream (e.g., offline after a test has been concluded).

To convey the data <NUM>-<NUM> within the address stream <NUM>-<NUM>, the processors <NUM>, acting through the memory controller <NUM>, communicate a payload message <NUM>, and optionally, a preamble message <NUM> and/or a postamble message <NUM>, in any order. If the preamble message <NUM> or the postamble messages <NUM> is output, the host device <NUM> outputs the preamble message <NUM> before communicating the payload message <NUM>, which typically precedes the postamble message <NUM>. The memory controller <NUM> can, however, reorder the messages <NUM>, <NUM>, <NUM> within the address stream <NUM>-<NUM> as part of a scheme to issue memory requests in an order that efficiently accesses different memories cards, banks, or modules. Thus, the memory bus <NUM> may convey to the memory <NUM> the payload message <NUM> before or after transmitting either of the optional preamble or postamble messages <NUM> and <NUM>. The memory <NUM> can nonetheless identify the preamble message <NUM>, the payload message <NUM>, and the postamble message <NUM>, no matter the order of appearance in the address stream <NUM>-<NUM>. Responsive to identifying the preamble message <NUM>, the memory <NUM> interprets the payload message <NUM> as containing or being at least part of the data <NUM>-<NUM>. The memory <NUM> determines an end to the data <NUM>-<NUM> in response to identifying the postamble message <NUM>.

The host device <NUM> indicates a beginning or head of the payload message <NUM> by outputting the preamble message <NUM>. The preamble message <NUM> appears in the address stream <NUM>-<NUM> at time <NUM> and alerts the memory <NUM> to the start of the payload message <NUM>.

To determine that the address stream <NUM>-<NUM> includes the payload message <NUM>, the memory <NUM> may look for the preamble message <NUM>. The preamble message <NUM> is a repeating sequence of addresses across multiple address strides. The host device <NUM> communicates (e.g., places or drives) the addresses of the preamble message <NUM> onto the memory bus <NUM> repeatedly (e.g., hundreds of times). The memory <NUM>, or a logic analyzer of the computer <NUM> or automated test equipment (ATE) for memory simulation scenarios that are performed offline, identifies the preamble message <NUM> in response to recognizing the repeating sequence of addresses within some sliding window of addresses (not shown in <FIG>). In some cases, the pattern of addresses in the preamble message <NUM> is derived from deltas between addresses, rather than absolute values of the addresses themselves. Also referred to as inter-address-deltas, each address-delta is a difference between two addresses. In summary, the data <NUM>-<NUM> is transferred within the address stream <NUM>-<NUM> as a predetermined pattern of addresses or inter-address-deltas that the memory <NUM>, or the logic analyzer, is programmed to recognize. In some examples, the predetermined pattern is a statistical distribution of addresses, which are interpreted together as the preamble message <NUM>.

In example operations, the memory <NUM> is configured to determine that the address stream <NUM>-<NUM> includes the preamble message <NUM> by identifying a pattern of offsets of addresses in the address stream. In <FIG>, the pattern of offsets in the preamble message <NUM> includes the offsets [<NUM>, <NUM>, <NUM>, <NUM>]. The memory <NUM> recognizes the preamble message <NUM> in response to identifying such a pattern of offsets in the address stream <NUM>-<NUM>. Responsive to determining that the address stream <NUM>-<NUM> includes the preamble message <NUM>, the memory <NUM> detects or determines the presence of the payload message <NUM>.

To improve reliability in communicating the data <NUM>-<NUM> within the address stream <NUM>-<NUM>, the pattern of offsets in the preamble message <NUM> may encode a pattern of deltas that indicate the preamble message <NUM>. Each delta in the pattern of deltas is an inter-address difference or delta between pairs of the offsets in the address stream <NUM>-<NUM>. In <FIG>, the pattern of deltas in the preamble message <NUM> includes [+<NUM>, -<NUM>, +<NUM>]. The memory <NUM> may recognize the preamble message <NUM> in response to identifying the pattern of deltas.

During a subsequent communication of data <NUM>-<NUM> in the address stream <NUM>-<NUM>, the memory <NUM> may identify the same pattern of deltas [+<NUM>, -<NUM>, +<NUM>] based on the same or a different pattern of offsets previously included in the preamble message <NUM>. For example, the memory <NUM> can recognize the preamble message <NUM> in a subsequent portion of the address stream <NUM>-<NUM> that the pairs of offsets in the subsequent portion of the address stream <NUM>-<NUM> are the same or different than the pairs of offsets [<NUM>, <NUM>, <NUM>, <NUM>] in a previous preamble message <NUM>. If different from previous pairs of offsets, the pairs of offsets included in the preamble message <NUM> can again encode a pattern of deltas corresponding to [+<NUM>, -<NUM>, +<NUM>] to indicate the beginning of the payload message <NUM>.

To compensate for an unknown reordering on the memory bus <NUM>, which may be performed by the memory controller <NUM>, the memory <NUM> may identify a particular ratio of offsets or deltas between pairs of offsets in the preamble message <NUM>. For example, a pattern of deltas corresponding to [+<NUM>, +<NUM>, -<NUM>] may be deemed the same as the pattern of deltas including [+<NUM>, -<NUM>, +<NUM>] within a window of addresses of a given size. Likewise, rather than deltas, a particular ratio of offsets can be used to convey the preamble message <NUM>. For example, the memory <NUM> may identify an equal quantity or distribution of offsets that correspond to <NUM>, <NUM>, <NUM>, and <NUM>.

The memory <NUM> may seek to identify hundreds of occurrences of the offsets to identify a single preamble message <NUM>. For example, the computer <NUM> or operating system thereof has a four-kilobyte address range in each page of memory. The preamble message <NUM> includes absolute offsets (e.g., [<NUM>, <NUM>, <NUM>, <NUM>]) within the page "A". The memory <NUM> may recognize the preamble message <NUM> in response to identifying the absolute offsets within the page "A" or an equal quantity of each of the absolute offsets within a time window of the address stream <NUM>-<NUM>. The memory <NUM> seeks a high density of addresses on the memory bus <NUM> that pertain to same memory page. For instance, a relevant high density of addresses reference a single page "A," and each address has one of the absolute offsets found in the preamble message <NUM>. In response to identifying a sufficient quantity of each of the absolute offsets to satisfy a pattern of the preamble message <NUM>, the memory <NUM> determines that the data <NUM>-<NUM> is being communicated on the memory bus <NUM> in the address stream <NUM>-<NUM>.

The memory <NUM> may not identify the preamble message <NUM> with one hundred percent certainty, but the memory <NUM> likely detects the preamble message <NUM> with near (e.g., ninety-nine percent) certainty. The memory <NUM> may maintain a list of every page addressed within the sliding time window mentioned above. The memory <NUM> identifies the preamble message <NUM> in response to identifying a page with a high-reference-rate and a majority of absolute offsets that match the pattern of the preamble message <NUM>.

Before time t, and after communicating the payload message <NUM> within the address stream <NUM>-<NUM>, the processors <NUM> cause the memory controller <NUM> to communicate the postamble message <NUM> on the memory bus <NUM> as part of the address stream <NUM>-<NUM>. The processors <NUM> output the postamble message <NUM> to indicate an ending of the payload message <NUM> and an end to the communication of the data <NUM>-<NUM> for this incidence.

The host device <NUM> communicates the postamble message <NUM> in the address stream <NUM>-<NUM> similarly to how the host device <NUM> causes the memory controller <NUM> to communicate the preamble message <NUM>. For example, the processors <NUM> cause the memory controller <NUM> to output the postamble message <NUM> as a series of consecutive addresses to a common page in the memory <NUM>, which series includes a particular pattern of absolute offsets or deltas in the address stream <NUM>-<NUM>. Responsive to determining that the address stream <NUM>-<NUM> includes the postamble message <NUM>, the memory <NUM> determines an end to the communication of the data <NUM>-<NUM>.

In response to determining the postamble message <NUM>, the memory <NUM> determines the data <NUM>-<NUM> based on a content of offsets that define the payload message <NUM>, which appear before the postamble message <NUM> in the address stream <NUM>-<NUM>. Between time zero and time t, the address stream <NUM>-<NUM> includes a time-ordered sequence of addresses within a single page "A" within the memory <NUM>. The addresses of the data <NUM>-<NUM> may be transmitted by the host device <NUM> in the order received by the memory controller <NUM> from the processors <NUM>. Alternatively, the memory controller <NUM> may reorder addresses of the address stream <NUM>-<NUM> or scramble addresses transmitted on the memory bus <NUM> at this time after, for example, what may be relatively long periods where the addresses appear in order. The memory <NUM> can account for the reordering of addresses that make up data when interpreting the addresses based on a sequence indication, a checksum, and so forth.

The memory <NUM> determines that the address stream <NUM>-<NUM> includes the postamble message <NUM> by identifying a corresponding pattern of offsets. In <FIG>, the pattern of offsets in the postamble message <NUM> includes [<NUM>, <NUM>, <NUM>, <NUM>]. The memory <NUM> is configured to recognize the postamble message <NUM> in response to identifying this pattern of offsets. As discussed above in relation to the pattern of offsets in the preamble message <NUM>, the pattern of offsets in the postamble message <NUM> may also encode a pattern of deltas. Each delta in the pattern of deltas is a difference between pairs of the offsets within the postamble message <NUM>. To improve reliability in communicating the data <NUM>-<NUM> within the address stream <NUM>-<NUM>, the memory <NUM> may recognize the postamble message <NUM> in response to identifying multiple addresses as including another pattern of deltas in the address stream <NUM>-<NUM>. For example, in <FIG>, the other pattern of deltas in the postamble message <NUM> includes [-<NUM>, +<NUM>, -<NUM>].

In some cases, the payload message <NUM> of the data <NUM>-<NUM> includes a portion of the address stream <NUM>-<NUM> received after the preamble message <NUM> and before the postamble message <NUM>. The payload message <NUM> encodes the data <NUM>-<NUM> within address bits that make up page offsets of addresses to a page "A" in the memory <NUM>, which is the same page "A" in the addresses of the preamble and postamble messages <NUM> and <NUM>. The data <NUM>-<NUM> may therefore correspond to at least the actual bit-content of the offset portion(s) of the payload message <NUM>. In some examples, the data <NUM>-<NUM> includes a mailbox <NUM> that indicates a location that can be referenced when future data <NUM> is communicated, which is described with reference to the address stream <NUM>-<NUM>.

Within the payload message <NUM>, the host device <NUM> may communicate a mailbox location, which can include a page in the memory <NUM> that is referenced to efficiently communicate future data <NUM>. For example, the mailbox <NUM> can correspond to a page address of the memory <NUM> that is referenced to communicate data <NUM>-<NUM> and <NUM>-<NUM>. Thus, the mailbox <NUM> can also serve to indicate additional data, such as the data <NUM>-<NUM> or <NUM>-<NUM>, to the memory <NUM> or a trace analyzer. The host device <NUM> communicates the mailbox location as address bits transmitted within the payload message <NUM>. In this way, the payload message <NUM> can include actual, data <NUM>-<NUM> and/or a reference to a location of future data <NUM>-<NUM> or <NUM>-<NUM> to be communicated to the memory <NUM>.

Based on the parts of the address stream <NUM>-<NUM> received after the preamble message <NUM>, the memory <NUM> identifies a mailbox location of the mailbox <NUM>. Based on the payload message <NUM>, the memory <NUM> interprets the offsets as a mailbox location indicating a page of memory <NUM> that identifies when data <NUM>-<NUM> and <NUM>-<NUM> is being communicated. The offset bits numbered [<NUM>,. , <NUM>] and [<NUM>,. , <NUM>] that appear in the payload message <NUM> are interpreted as a reference to establish the mailbox <NUM>, rather than as an addressable offset for a memory request. In the example of <FIG>, the memory <NUM> determines the data <NUM>-<NUM> and <NUM>-<NUM> to include "<NUM>" and "<NUM>," respectively, in the address stream <NUM>-<NUM>.

Between time zero and time t, the address stream <NUM>-<NUM> includes a time-ordered sequence of addresses within a single page "A" that are sent to the memory <NUM>. For ease of description, the addresses of the data <NUM>-<NUM> are transmitted by the memory controller <NUM> in the address stream <NUM>-<NUM> in the order received from the processors <NUM>. As described in relation to the other drawings, the address stream <NUM>-<NUM> may include reordered or scrambled addresses during transmission on the memory bus <NUM> after what may be long periods where the addresses appear in order. As described below, the memory <NUM> can account for the reordering of addresses that make up data when interpreting the addresses using, for instance, an order-dependent checksum.

While the data <NUM>-<NUM> may appear as regular addresses including page and offset values, the page and offset values of the data <NUM>-<NUM> convey a message for the memory <NUM>. A preamble message <NUM> appears initially on the memory bus <NUM> at time zero. The preamble message <NUM> precedes a payload message <NUM>. The preamble message <NUM> and the payload message <NUM> are followed by a postamble message <NUM>, which completes its transmission on the memory bus at time t. The moment that the preamble message <NUM> ceases, the memory <NUM> or logic analyzer may interpret addresses on the memory bus <NUM> as payload information. In the example of <FIG>, the payload message <NUM> takes two memory cycles.

Rather than merely sending the data <NUM>-<NUM> as the payload message <NUM>, the host device <NUM> can send the payload message <NUM> to initialize the mailbox <NUM> to establish how future data <NUM>-<NUM> and <NUM>-<NUM> will be indicated. The addresses in the payload message <NUM> encode data or a pointer to data for the mailbox <NUM>. In the example of <FIG>, the payload message <NUM> includes two address portions numbered [<NUM>,. ,<NUM>] and [<NUM>,. When combined (e.g., concatenated), the two portions establish a memory page for the mailbox <NUM>. If the memory page corresponds to page "P" of the memory <NUM>, the data <NUM>-<NUM> and <NUM>-<NUM> are communicated within address offset bits of the page "P" of the mailbox <NUM>. The data bits directed to the mailbox <NUM> may be ignored in terms of standard memory requests. On the host side, the processors <NUM> allocate the page "P" of the memory <NUM> to the program <NUM> for exclusive use by the program <NUM> to communicate the data <NUM>-<NUM> and <NUM>-<NUM>, and potentially additional data. After initializing the mailbox <NUM>, a subsequent address along the address stream <NUM> to the page "P" is a reference to a location of the memory <NUM> that is indicative that data is being communicated and may be interpreted or stored accordingly.

<FIG> illustrates an example computer <NUM>-<NUM> configured to send data embedded in an address stream. The computer <NUM>-<NUM> is only one example of the computer <NUM>, and it is shown in greater detail. The computer <NUM>-<NUM> includes a computer-readable storage medium <NUM>, which may be a non-transitory computer-readable storage medium. The host device <NUM> exchanges information with the computer-readable storage medium <NUM> over an interconnect <NUM>. The computer-readable storage medium <NUM> may be realized at least partially using a memory device <NUM>-<NUM> and/or part of the host device <NUM>, or the computer-readable storage medium <NUM> may be physically separate from the host device <NUM>.

The computer-readable storage medium <NUM> includes multiple groups of data: one group is labeled user space <NUM>, and the other group is labeled system services <NUM>. The system services <NUM> provide applications that are accessible from the user space <NUM> including access to a variety of services and functions, such as a system library module <NUM> (also referred to simply as "a system library <NUM>"). For example, the program <NUM>, which is shown in <FIG> as being maintained in the user space <NUM>, can call on a system function or a system task from the system library <NUM> to perform an operation on behalf of the program <NUM>. The user space <NUM> may include a user library <NUM>. The user library <NUM> may be customizable by a user of the computer <NUM>-<NUM> and provides applications executing from within the user space <NUM> with access to additional services and functions than those provided by the system library <NUM>. The user library <NUM> or the system library <NUM> may include functions that, when called, enable the program <NUM> to send embedded data within the address stream <NUM>.

The computer <NUM>-<NUM> also includes the host device <NUM>, including the one or more processors <NUM> and the at least one memory controller <NUM>. A memory bus <NUM>-<NUM>, which is an example of the memory bus <NUM>, propagates the address stream <NUM>-<NUM> and the data stream <NUM> between the memory controller <NUM> of the host device <NUM> and the memory <NUM>-<NUM>. The address stream <NUM>-<NUM> carries, for example, the preamble message <NUM>, the payload message <NUM>, and the postamble message <NUM> that are sent from the host device <NUM>. The memory bus <NUM>-<NUM> also includes one or more control lines <NUM>, which carry control signals back and forth between the host device <NUM> and the memory device <NUM>-<NUM>.

The memory <NUM>-<NUM> is an example of the memory <NUM>. Included in the memory <NUM>-<NUM> is an optional embedded-data receiver module <NUM>. In practice, the memory device <NUM> may be used, which does not necessarily include any hardware or software modifications, such as the inclusion of the embedded-data receiver module <NUM>.

The embedded-data receiver module <NUM> determines that the address stream <NUM>-<NUM> includes addresses or data. In response to identifying data by, for example, detecting the preamble message <NUM>, the embedded-data receiver module <NUM> configures the memory <NUM>-<NUM> to act on the data rather than process the address stream <NUM>-<NUM> as if it contained the kind of address typically observed on the memory bus <NUM>-<NUM> during a read, write, or other memory request.

The embedded-data receiver module <NUM> configures the memory <NUM>-<NUM> to identify, based on the payload message <NUM>, the mailbox <NUM> where a dedicated page in the memory <NUM>-<NUM> is reserved to designate data. For some types of data, multiple mailbox locations may be used to transmit different types of data from the host device <NUM> to the memory <NUM>-<NUM>. In such cases, the embedded-data receiver module <NUM> can determine, based on the payload message <NUM>, multiple portions of the data that are associated with different mailbox locations. Additionally or alternatively, the embedded-data receiver module <NUM> can determine how many bits are associated with a page address portion and how many bits are associated with an offset address portion. Based on this information, the embedded-data receiver module <NUM> can interpret different sizes of data appropriately or concatenate multiple portions of data together. Thus, the host device <NUM> and the memory <NUM>-<NUM> can exchange data of varying sizes or amounts.

The program <NUM> can call on a function maintained by the system library <NUM> or the user library <NUM> to enable the program <NUM> to send data embedded in the address stream <NUM>-<NUM>. In response to the function call, the processors <NUM> execute the function to request that the memory controller <NUM> allocate a page of the memory <NUM>-<NUM> to the program <NUM> for maintaining the mailbox <NUM>. The program <NUM> interfaces with the libraries <NUM> or <NUM> to communicate the data using one or more mailbox locations.

As part of an initialization, the libraries <NUM> and <NUM> cause the processors <NUM> to communicate the one or more mailbox locations within the payload message <NUM>. For example, the offsets within the payload message <NUM> can point to a location of the mailbox <NUM>, such as by providing an address of a memory page for the mailbox <NUM>. The program <NUM> outputs additional data by reading or writing at different times to the page address of the mailbox location of the memory <NUM>-<NUM> that is allocated to the program <NUM>. For example, the libraries <NUM> or <NUM> can cause the processors <NUM> to output other data as offsets to the mailbox page within a subsequent payload message appearing on the address stream <NUM>-<NUM>.

As one example, the program <NUM> can communicate a thread identifier associated with the program <NUM> with reference to a location of the mailbox <NUM>. The thread identifier can be relatively long and therefore span multiple address offsets or address deliveries via the mailbox to communicate the entire thread identifier. The program <NUM> can output an indication of the mailbox page via which the data is communicated in a function call to the system library <NUM>. For example, the mailbox location may correspond to a <NUM>-bit address of the page of the memory <NUM>-<NUM> allocated for the mailbox <NUM>. The program <NUM> can also provide the data to the system library <NUM>.

In response to the function call by the program <NUM>, the system library <NUM> generates the preamble message <NUM>. By directing the processors <NUM> to output the preamble message <NUM>, the system library <NUM> alerts the embedded-data receiver module <NUM> of the memory <NUM>-<NUM> to monitor the address stream <NUM>-<NUM> for the payload message <NUM>. The embedded-data receiver module <NUM> determines that the preamble message <NUM> includes a sequence or pattern of offsets inserted to indicate a transmission of data. For example, the preamble message <NUM> may include a particular distribution of offsets in a long sequence of addresses, which the embedded-data receiver module <NUM> is programmed to identify.

Based on the information received from the program <NUM> about the mailbox location via which the data is to be communicated, the system library <NUM> generates the payload message <NUM>. The payload message <NUM> may include, with reference to the location of the mailbox <NUM>, the thread identifier or other data to be communicated. The data can be inserted as the offsets in a series of addresses appearing in the address stream <NUM>-<NUM>. The common page identifier in the series of addresses that are included in the payload message <NUM> indicate to the embedded-data receiver module <NUM> at the memory <NUM>-<NUM> that data is being communicated via the mailbox <NUM>.

The embedded-data receiver module <NUM> obtains the data identified by the mailbox <NUM> and included in multiple addresses of the address stream <NUM>-<NUM> as the payload message <NUM>. By concatenating multiple portions of the data together, the embedded-data receiver module <NUM> determines the thread identifier of the program <NUM>. Other types of information, including other kinds of program-execution context data, may alternatively be communicated over the address stream <NUM>-<NUM> via the established mailbox <NUM>. Although some of the description herein refers to the embedded-data receiver module <NUM> processing an address stream <NUM>-<NUM> or taking actions based on detected data during operation or testing, these descriptions may also or instead apply to acts performed by a logic analyzer or test equipment that is processing the address stream (e.g., offline after a test has been concluded).

Using the established mailbox <NUM> allows larger amounts of data to be efficiently shared over the address stream <NUM>-<NUM> because the preamble message <NUM> is not needed for each piece of information being communicated. Using a mailbox <NUM>, however, is not required for communicating data over the address stream <NUM>-<NUM>. Furthermore, using the messaging protocol is not required to transmit data or an indication of data, within the address stream <NUM>-<NUM>. Rather, the mailbox <NUM> can be allocated to a page in memory by the host device <NUM>, such that whenever a recipient of the address stream <NUM>-<NUM> (e.g., the memory <NUM>-<NUM>) identifies the page where the mailbox <NUM> is allocated, the recipient decodes the address referencing the page to be an offset to data in the mailbox <NUM>.

As described above, in some examples the payload message <NUM> contains data that is informative of current processing characteristics or dependencies or that instructs the memory <NUM>-<NUM> to perform some function. This informative data is provided as an offset address instead of providing a mailbox location as shown in the address streams of <FIG> and <FIG>. In other words, the offsets within the payload message <NUM> may represent individual portions of data. When concatenated together by the embedded-data receiver module <NUM>, the individual portions enable the thread identifier or other context data of the program <NUM> to be determinable directly from a memory trace of the memory bus <NUM>-<NUM>.

<FIG> illustrates an example detection scheme <NUM> with an address stream <NUM>-<NUM> that supports detection of transmissions of data. When the program <NUM> or an operating system of the computer <NUM> wants to communicate embedded data via an address portion of the memory bus <NUM>, a routine in the library <NUM> or <NUM> can direct the host device <NUM> to inject a preamble message <NUM> into the address stream <NUM>-<NUM>. The preamble message <NUM>, responsive to being identified by the embedded-data receiver module <NUM> of the memory <NUM>-<NUM>, can presage transmissions of additional data using the messaging protocol described herein. This messaging protocol, which uses a checksum with each transmission of data, can obviate the use of a preamble message <NUM> for each such transmission.

The preamble message <NUM> in the address stream <NUM>-<NUM> includes a sequence of four addresses to page "B" with offsets [<NUM>, <NUM>, <NUM>, <NUM>]. The indication of the presence of data by the preamble message <NUM> can be based on absolute offsets [<NUM>, <NUM>, <NUM>, <NUM>] or on a series of inter-address deltas [-<NUM>, -<NUM>, +<NUM>]. The preamble message <NUM> can be repeated in the address stream for n cycles, with n being any positive integer. Repeating the sequence of offsets tens, hundreds, or thousands of times improves the likelihood that the embedded-data receiver module <NUM> will identify the preamble message <NUM>. Accurate identification can prevent erroneous positive or negative detection of data (e.g., erroneous positive detection of data can occur when the processors <NUM> are in-fact communicating physical addresses for a memory request).

In controlling the memory bus <NUM>, the memory controller <NUM> can rearrange the order in which the addresses appear in the address stream <NUM>-<NUM>. Thus, the order of the offsets or inter-address deltas may be flexible in accordance with some described implementations.

Instead of identifying a particular sequence of offsets, the embedded-data receiver module <NUM> can identify the preamble message <NUM> by identifying a particular distribution of offsets to a single page in a sliding window of time or a given quantity of addresses. For instance, the embedded-data receiver module <NUM> identifies the preamble message <NUM> in response to noticing hundreds of addresses to the page "B" with the offsets "<NUM>," "<NUM>,". , and so forth. For each of the different absolute offsets or inter-address deltas observed in the address stream <NUM>-<NUM> during the sliding window of time, the embedded-data receiver module <NUM> keeps a count.

In response to determining that the counts of each of the different absolute offsets or inter-address deltas are equal during the sliding time window, the embedded-data receiver module <NUM> records the page "B" referenced in the preamble message <NUM> as the mailbox <NUM> (of <FIG>). The module also begins to monitor for a payload message <NUM>, which references the same page address "B" indicated in the preamble message <NUM>. On the other hand, responsive to determining that the distribution of offsets does not match an expected distribution of offsets of a preamble message <NUM>, the embedded-data receiver module <NUM> ignores the addresses in the address stream <NUM>-<NUM> because the addresses do not include embedded data.

Sending the preamble message <NUM> to start communicating data in this way can improve reliability and reduce noise in the address stream <NUM>-<NUM>. This can be helpful because the other contents of the address stream <NUM>-<NUM> might interrupt a sequence of related addresses used for communicating embedded data. For the embedded-data receiver module <NUM>, any noise within the address stream <NUM>-<NUM> corresponds to addresses for legitimate memory requests, as opposed to a transmission of data. The addresses that convey data are identified, and possibly recorded or otherwise used, by the embedded-data-receiver module <NUM>, while the addresses for memory requests are not. In some cases, in response to determining the mailbox is, or corresponds to, page "B," the embedded-data receiver module <NUM> recognizes that this means the entire page "B" is exclusive to the program <NUM> for communicating data. There will likely be little-to-no noise in the mailbox page, so any addresses that are directed to the page "B" are determined by the embedded-data receiver module <NUM> to be transmissions of data.

Having identified the page "B" of the memory <NUM>-<NUM> as the mailbox <NUM> that the computer <NUM>-<NUM> allocated to the program <NUM>, the embedded-data receiver module <NUM> determines that any additional addresses in the address stream <NUM>-<NUM> reference the page "B. " Once the mailbox page "B" is established, the library <NUM> or <NUM> directs the host device <NUM> to output a payload message <NUM>-<NUM>, including offsets [a, b, c]. The program <NUM>, acting through the library <NUM> or <NUM>, can therefore encode packets of data as offsets within the mailbox page "B.

The address stream <NUM>-<NUM> can transmit a payload message of any size, and the embedded-data receiver module <NUM>, likewise, can receive and interpret a payload message no matter the size. Initially, the library <NUM> or <NUM> receives a request from the program <NUM> to transmit data. Within the request, the program <NUM> can share the size of the data with the library <NUM> or <NUM>. In other examples, the library <NUM> or <NUM> can determine a quantity of addresses required to output the data by determining how many bits the data occupies. Based on this quantity of bits or size of the request and the quantity of bits per offset, the library <NUM> or <NUM> determines a number of addresses that will be used in the address stream <NUM>-<NUM> to send all the data in a single payload message <NUM>. For example, the library <NUM> or <NUM> determines a total quantity of bits required for the payload message <NUM>-<NUM> to include the data [a, b, c]. By dividing this total quantity of bits by the data capacity of each address (e.g., the offset size in bits), the library <NUM> or <NUM> identifies a quantity of addresses for sending the data [a, b, c] as the single payload message <NUM>-<NUM>.

To enable the decoding or detecting of data when received by the embedded-data receiver module <NUM> as part of the address stream <NUM>-<NUM>, the library <NUM> or <NUM> can provide a checksum with transmissions of the data. A checksum provides a value that is derived from core data and can therefore link the core data to the checksum, and vice versa. An example of a checksum is a cyclic redundancy check (CRC) code. The library <NUM> or <NUM> can implement a CRC code scheme by sending a CRC checksum (also sometimes referred to as a "CRC value" or more simply as a "CRC") for the data, which can be part of the payload message <NUM>-<NUM>. For example, only two offsets [a, b] of the three offsets in the payload message <NUM>-<NUM> include the data, while the third offset [c] is the CRC checksum for a particular combination of the two other offsets in the data.

The library <NUM> or <NUM> calculates a quantity of addresses to send the data, and then calculates the CRC checksum over the offsets within those addresses. Including the CRC checksum as an offset within an additional address enables the embedded-data receiver module <NUM> to detect which addresses make up the payload message <NUM>-<NUM>. In addition, the CRC checksum enables the embedded-data receiver module <NUM> to identify the CRC and piece the payload message <NUM>-<NUM> together in a correct order, even if the memory controller <NUM> rearranges the pieces of the payload message <NUM>-<NUM> and issues them over the memory bus <NUM> in a different order or as an unordered group.

In the illustrated example, over a sliding window of time, the address stream <NUM>-<NUM> includes the payload message <NUM>-<NUM>. The payload message <NUM>-<NUM> is directed to the mailbox page "B" and includes three addresses with the offsets [a, b, c]. Although three offsets appear in the address stream <NUM>-<NUM>, only two of the offsets are payload data, and the third is the CRC checksum. The embedded-data receiver module <NUM> may be unaware of which of the three offsets is the CRC checksum and a correct order of the payload data.

To determine which offset is the CRC checksum, the embedded-data receiver module <NUM> considers all the offsets in the payload message <NUM>-<NUM>, which is identified by the address page "B," combined (e.g., concatenated) in different permutations until a combination of all but one offset equals the CRC checksum of the remaining offset. For the offsets [a, b, c], the different combinations of offsets include abc, acb, bac, bca, cab, and cba. With a high probability, only one of the different combinations will pass a CRC check. For instance, "a+b" may produce a checksum "c. " The embedded-data receiver module <NUM> determines the combination that correctly specifies a CRC checksum computed for the other offsets received during the sliding window. The CRC check will fail if bits are in a different position from which the bits were encoded and output to the address stream <NUM>-<NUM>. By considering each of the different combinations until the correct sequence of two address offsets results in a checksum indicated by the third offset, the embedded-data receiver module <NUM> can decode the data from the address stream <NUM>-<NUM> using the CRC checksum. Although a CRC checksum is used by way of example, other checksums that verify data payload, with or without order confirmation, can be used instead.

When the embedded-data receiver module <NUM> determines a combination of offsets that reference the mailbox page "B" and that pass the CRC checksum, the embedded-data receiver module <NUM> can isolate the offsets for the data and discard the offset containing the CRC checksum. The isolated offsets can then be saved or used to perform some function. If the embedded-data receiver module <NUM> fails to identify the CRC checksum in an identified payload message <NUM>, the embedded-data receiver module <NUM> may output an alert or notification that the CRC checksum failed. For example, the embedded-data receiver module <NUM> can inject a failure code in a trace of the memory bus <NUM> in response to determining that no combination of offsets within a payload message <NUM>-<NUM> produce a CRC checksum that is included in the message identified by a different page address "A.

Although not shown in <FIG> with a preamble message, the embedded-data receiver module <NUM> may have determined that the page address "A" of the memory <NUM>-<NUM> corresponds to the mailbox <NUM>. In trying to determine the CRC checksum for the payload message <NUM>-<NUM>, the embedded-data receiver module <NUM> may fail to identify a combination of offsets [p, q, r] from the payload message <NUM>-<NUM> that satisfy the CRC checksum included in one of the other offsets. During subsequent analysis of the trace, the failure code that appears on the address stream <NUM>-<NUM> indicates where the CRC checksum failed, to aid in debugging the failure.

An advantage of this checksum technique is that it does not matter in which order the individual addresses to a mailbox appear because (except in very rare circumstances) the CRC check will only pass with a single correct combination. When computing or applying a CRC checksum, the order matters. If the offsets are analyzed in a different order from the one used to produce the CRC checksum, the CRC checksum will not be validated. The CRC checksum entails a specific order to the bits corresponding to the CRC, so if the ones and zeroes are in a different order, the CRC check fails.

The CRC can be computed or established by the library <NUM> or <NUM>; however, attributes of the CRC checksum or a scheme implementing CRC do not need to be established up-front. The CRC can be any size, and the library <NUM> or <NUM> may communicate the size of the CRC checksum within the offsets of the preamble message <NUM> or a previous payload message <NUM> (e.g., of <FIG>). These types of initializations can set up or communicates the size or type of the checksum that is to be used. Although it can be changed at runtime (e.g., through another preamble message), if the embedded-data receiver module <NUM> knows the number of bits for a CRC checksum before calculating the different combinations of offsets, the search for the correct combination of offsets can consume fewer processing resources or be completed more quickly.

The library <NUM> or <NUM> can additionally or alternatively communicate how many addresses form a group that includes both a checksum and the associated payload data to facilitate analysis at a memory device. In some of the example implementations described above, the checksum approach to detecting data is performed in conjunction with a mailbox page. For instance, the payload message <NUM>-<NUM> is depicted as using the page "B" as a mailbox. These implementations facilitate identifying those addresses that should be analyzed for potentially matching a checksum. However, these implementations also entail sending a preamble message <NUM>, which can be relatively lengthy. Thus, in other example implementations, the payload message <NUM>-<NUM> can be sent without first establishing a mailbox. These implementations that omit a mailbox avoid the overhead of the preamble message <NUM> with an added cost for decoding the address stream <NUM>-<NUM> and detecting a set of related addresses using a checksum. Further, although some of the description herein refers to the embedded-data receiver module <NUM> processing an address stream <NUM>-<NUM> or taking actions based on detected data during operation or testing, these descriptions may also or instead apply to acts performed by a logic analyzer or test equipment that is processing the address stream (e.g., offline after a test has been concluded).

<FIG> illustrates additional an example environment <NUM>-<NUM> in which various techniques and devices described in this document can operate to perform a memory test. The environment <NUM>-<NUM> includes a computer <NUM>-<NUM>, which is an example of the computer <NUM>-<NUM>. The computer <NUM>-<NUM> includes the host device <NUM> communicatively coupled with a memory device <NUM>-<NUM>, which is an example of the memory device <NUM>-<NUM>. The computer <NUM>-<NUM> is also communicatively coupled to a logic analyzer module <NUM>, for example, via one or more probes <NUM> directly-coupled to the memory bus <NUM>, via an interconnect <NUM> connected to the host device <NUM>, or using an interconnect <NUM> coupled to the memory device <NUM>-<NUM>. The logic analyzer module <NUM> may be an internal component of the computer <NUM>-<NUM> or even the memory <NUM>-<NUM> within the computer <NUM>-<NUM>. In other examples, the logic analyzer module <NUM> is implemented external to the computer <NUM>-<NUM>, such as part of ATE, and configured to record a trace of the memory bus <NUM>.

The logic analyzer module <NUM> determines the data <NUM> embedded within the address stream <NUM>, directly from the address stream <NUM> or indirectly. The data <NUM> is directly determined from signals obtained via the one or more probes <NUM>. To indirectly determine the data <NUM>, other signals or information is used, specifically information or signals obtained from the host device <NUM> or the memory <NUM>-<NUM> over the interconnects <NUM> or <NUM>. For example, an optional embedded-data-receiver module <NUM>-<NUM>, which is an example of the embedded-data-receiver module <NUM>, may determine the data <NUM> embedded within the address stream <NUM> and output the data <NUM>. Either by directly or indirectly determining the data <NUM> embedded in the address stream <NUM>, the logic analyzer module <NUM> uses the data <NUM> to tag or otherwise enhance a memory trace generated from other information appearing on the memory bus <NUM>.

No matter the source of input signals, the logic analyzer module <NUM> can compile the signals received from the one or more probes <NUM>, the interconnect <NUM>, and the interconnect <NUM> into an enhanced memory trace that can be analyzed concurrently with traffic that appears on the memory bus <NUM>, or offline. The logic analyzer module <NUM> may output the enhanced memory trace to a data file, the program <NUM>, or another system for consideration by a test and evaluation group, for example, using the interconnect <NUM>. This output from the logic analyzer module <NUM> may drive a user interface of the program <NUM> or a different application from which a user of the computer <NUM>-<NUM> can analyze operations associated with the host-device-to-memory-device interface, including the memory bus <NUM> of the computer <NUM>-<NUM>.

The embedded-data receiver module <NUM>-<NUM> may output different information to the logic analyzer module <NUM> than the information the embedded-data receiver module <NUM>-<NUM> collects from the address stream <NUM>. For example, the data <NUM>, including a CRC checksum, may appear on the memory bus <NUM> as part of the address stream <NUM>. In response to determining the CRC checksum and verifying the accuracy of the data <NUM>, the embedded-data receiver module <NUM>-<NUM> may output a version of the data <NUM> via the interconnect <NUM>, except for excluding the CRC checksum from the data <NUM>, originally. In some cases, the embedded-data receiver module <NUM>-<NUM> uses the data <NUM> without passing it on to the logic analyzer module <NUM>. In this way, the communication of the data <NUM> can be transparent to the logic analyzer module <NUM>.

Turning to <FIG>, illustrated is an example environment <NUM>-<NUM> in which various techniques and devices described in this document can operate to simulate a memory using results generated from a memory test. The environment <NUM>-<NUM> represents part of a simulator computing system and includes a memory controller simulator module <NUM>, which when executed on a processor (not shown) configures the processor to output simulation results <NUM> based on an enhanced address trace <NUM>, which includes data embedded in an address stream.

The memory controller simulator module <NUM> is communicatively coupled with a computer-readable storage medium <NUM>-<NUM>, which is an example of the computer-readable storage medium <NUM>. The logic analyzer module <NUM>, for example, stores the enhanced address trace <NUM> based on information collected from at least one of the probes <NUM>, the interconnect <NUM>, or the interconnect <NUM>. The computer-readable storage medium <NUM>-<NUM> may further store simulation results, control dependencies, or other address trace data or metadata.

The memory controller simulator module <NUM> includes a trace preprocessor module <NUM> configured to receive the enhanced address trace <NUM> as input and separates the enhanced address trace <NUM> into two portions. A first portion includes an address trace <NUM>, without any embedded data, and the second portion includes trace metadata <NUM>, which represents the embedded data, including control dependencies or other context, separated from the enhanced address trace <NUM>.

A simulation engine module <NUM> of the memory controller simulator module <NUM> produces the simulation results <NUM> output from the memory controller simulator module <NUM>. The simulation results <NUM> associate data, including control dependencies or other context, with the addresses shown in the address trace <NUM>. Because the simulation engine module <NUM> incorporates the trace metadata <NUM> into an analysis of the address trace <NUM>, the simulation results <NUM> are more accurate, or at least more detailed than simulation results produced without embedding data in an address stream during a test. The memory controller simulator module <NUM> is configured to use the enhanced address trace <NUM>, which includes embedded data, to produce a more-accurate simulation of a memory design than if the address trace <NUM> is used without access to the trace metadata <NUM> to generate simulation results.

<FIG> illustrates an example process <NUM> with operations <NUM> through <NUM> performed by a computing system configured to embed data in an address stream, the address stream being separate from a data stream. As described throughout, the address stream and data stream are propagated over a single interconnect, such as a memory bus. For example, the computer <NUM> performs the operations <NUM> through <NUM> by executing instructions at a host device <NUM>, such as instructions associated with the program <NUM> and/or a library, such as the library <NUM> or <NUM> from <FIG>. Performance of the operations (or acts) <NUM> through <NUM> is not necessarily limited to the order or combinations in which the operations are shown in <FIG> or described herein. Further, any of one or more of the operations may be repeated, combined, or reorganized to provide other operations for embedding data in a data stream. In executing the operations <NUM> through <NUM>, the computer <NUM> is therefore configured to communicate data <NUM> in an address stream <NUM> over a memory bus <NUM> extending between the host device <NUM> and a memory <NUM>.

At <NUM>, the computer <NUM> identifies data for transmission within an address stream. For example, the host device <NUM> receives data from the program <NUM>, which while executing at the processors <NUM>, calls on the library <NUM> or <NUM> to invoke one or more functions. When invoked by the program <NUM>, the library <NUM> or <NUM> directs the host device <NUM> to send data <NUM> within the address stream <NUM>.

At <NUM>, the computer <NUM> generates a pattern of address bits indicative of the data for transmission within the address stream. For example, while executing at the host device <NUM>, the library <NUM> packages the data <NUM> received as input from the program <NUM>, into a format suitable for communication through the address stream <NUM>. The pattern of address bits indicative of data may be formulated in accordance with the repetition-based pattern of <FIG>, the message-based pattern of <FIG>, and so forth. The pattern of address bits may include a checksum, a sequence indicator per address, and the like.

At <NUM>, the computer <NUM> transmits an indication of the data by sending the pattern of address bits as a bitstream within the address stream. Here, the bitstream includes multiple bits and occupies a portion of the address stream <NUM> and includes data or an indication of data instead of address information. For instance, the packaged data <NUM> from step <NUM> is output by the memory controller <NUM> onto the address stream <NUM>. An indication of the packaged data <NUM> appears on the address lines of the memory bus as an encoded series of one or more addresses. The encoded series of one or more addresses, rather than conveying an address for a read or write request, informs the memory <NUM> or other recipient of the address stream <NUM> (e.g., the logic analyzer module <NUM>) that data is being transferred from the host device <NUM> over the address stream <NUM>.

At <NUM>, the computer <NUM> can transmit the indication of the data in various ways, as described throughout this document. Each of the operations <NUM>, <NUM>, and <NUM> are optional and not required but each of the operations <NUM>, <NUM>, <NUM>, and <NUM> can promote reliability or security in sending data through an address stream.

At <NUM>, the computer <NUM> determines whether to use a messaging protocol. If so, when a recipient of the address stream <NUM> is configured to detect a preamble message, a payload message, and/or postamble message, the computer <NUM> includes at <NUM> the data <NUM>, or an indication of how the data <NUM> is referenced in relation the memory <NUM>, as part of the payload message. For example, the address bits communicated through the address stream may represent the data <NUM>, or they may indicate an offset to a page of the memory <NUM> which is reserved by the program <NUM> to communicate the data <NUM> over an address stream <NUM>. In other implementations, the pattern of address bits may be repeatedly transmitted (e.g., in n cycles) within a window <NUM> of time to indicate that data is present in the address stream <NUM>.

Alternatively, when the recipient of the address stream <NUM> is not configured for communicating using the messaging protocol described herein, the computer <NUM> may bypass operation <NUM> and proceed to operation <NUM>. In such cases, the computer may include the data <NUM> as an encoded series of address bits, which are subsequently identifiable from a memory trace or by the recipient. Or, still bypassing step <NUM>, the computer <NUM> can communicate an indication of the data <NUM> without relying on the described messaging protocol by transmitting address bits that indicate a page that is reserved for communicating the data <NUM> to the memory <NUM>.

At <NUM>, the computer <NUM> determines whether the communication of the data <NUM> is to include a checksum, such as a CRC checksum, in the event the memory bus <NUM> rearranges some of the address stream <NUM> so that parts of the data <NUM> appear out-of-order when communicated through the address stream <NUM>. The checksum can be used by a recipient to determine a correct ordering of the address bits to determine the data <NUM> or mailbox location of the data <NUM>. If the checksum is not being used, the computer <NUM> returns to operation <NUM> to repeat the process <NUM>, if additional data is identified.

At <NUM>, the computer communicates a checksum determined from a correct ordering of the address bits in the pattern. For example, a library routine of the host device <NUM>, e.g., the library <NUM> or <NUM>, determines a pattern of address bits or inter-address deltas for conveying the data <NUM>, and determines a checksum based on the pattern so that if parts of the data <NUM> are interspersed with addresses, or otherwise rearranged in a different order than the host device <NUM> intended, the recipient can order the address bits to determine the data <NUM>. Said differently, the host <NUM> may output the indication of data <NUM> as an unordered group of addresses that appear in the address stream <NUM>. The processors <NUM> are configured to include, within the unordered group of addresses, one or more offsets that represent a checksum corresponding to remaining offsets from the unordered group of addresses arranged in a correct order.

A recipient of the address stream <NUM>, may verify the data <NUM>, such as a condition to outputting the data <NUM> on the interconnect <NUM> as part of a memory trace of the memory bus <NUM>. Here, the embedded-data receiver module <NUM>-<NUM> or other recipient determines a plurality of offsets contained in the address stream <NUM>. Based on the offsets, a particular offset in an ordered-combination of the plurality of offsets includes a checksum that is computed based on the remaining offsets in the ordered-combination.

For example, the payload message <NUM>-<NUM> includes the offsets [A, B, C] in any order. Two of the offsets, when concatenated together, satisfy the CRC checksum indicated by the third offset. To analyze these three offsets, the embedded-data receiver module <NUM>-<NUM> or other recipient can try each combination of the offsets [A, B, C] until a combination of two offsets produce a CRC checksum indicated by the third offset. In this example, the offsets "C" and "A," when concatenated together as "C+A," produce the CRC checksum value "B. " The embedded-data receiver module <NUM>-<NUM> can isolate the offsets that represent the data <NUM> from the offset(s) that represent the CRC checksum. That is, responsive to determining a particular offset comprises a CRC checksum for the remaining offsets, the embedded-data receiver module <NUM>-<NUM> may identify the remaining offsets in the ordered-combination as being the data <NUM> communicated by the program <NUM> in the address stream <NUM>. In other implementations, such as those that omit a checksum or that use a checksum that does not reflect data order, a sequence indicator may be included in the address stream as part of each offset having payload data in a group of related offsets.

The data <NUM> may indicate a mailbox <NUM> location corresponding to a page of memory allocated to a program that initiated the communication of the data. For example, the offsets A and B concatenate together forming mailbox location AB, which passes a CRC checksum equal to C. The program <NUM> can write additional data to the mailbox location AB in another payload message <NUM>, without invoking the library <NUM> or <NUM> and/or without sending another preamble message <NUM>. The embedded-data receiver module <NUM>-<NUM> or other recipient is programmed to recognize addresses in the address stream <NUM>, including the page (e.g., page "B") where the mailbox is established.

Acts <NUM> through <NUM> may be repeated to, for example, enable the program <NUM> to output another payload message <NUM>, or additional data, such as a new execution context indicator (e.g., a thread ID, a process ID, or a program counter (PC)).

Although some of the description herein refers to the embedded-data receiver module <NUM> processing an address stream <NUM> or taking actions based on detected data, these descriptions may also or instead apply to acts performed by a logic analyzer or other recipient device that monitors the address stream <NUM> (e.g., separately during or after a test has been concluded).

<FIG> illustrates an example process <NUM> with operations <NUM> through <NUM> performed by a computing system configured to extract or interpret data embedded within an address stream that is propagated over a memory bus or other interconnect beings probed or monitored, e.g., during a memory test. For example, the memory controller simulator module <NUM> performs the operations <NUM> through <NUM> when instructions associated with the memory controller simulator module <NUM> are loaded by a processor. Performance of the operations (or acts) <NUM> through <NUM> is not necessarily limited to the order or combinations in which the operations are shown in <FIG> or described herein. Further, any of one or more of the operations may be repeated, combined, or reorganized to provide other operations for interpreting data embedded in an address stream.

At <NUM>, the memory controller simulator module <NUM> receives an address trace. For example, the memory controller simulator module <NUM> obtains as input, the enhanced address trace <NUM>, which is stored by the logic analyzer module <NUM>, for example, within the computer-readable storage medium <NUM>-<NUM>.

At <NUM>, the memory controller simulator module <NUM> extracts data from the address trace. For example, the trace preprocessor module <NUM> receives the enhanced address trace <NUM> as input and divides the enhanced address trace <NUM> into the address trace <NUM>, without any embedded data, and the trace metadata <NUM>. The data can include a preamble message, a postamble message, a checksum, a payload message, and the like, as described throughout the disclosure.

At <NUM>, the memory controller simulator module <NUM> derives context metadata for addresses in the address stream based on the extracted data. For example, the simulation engine module <NUM> derives control dependencies, thread identifiers, program counters, or other contextual information from the trace metadata <NUM> to use as inputs or variables for enhancing a simulation.

At <NUM>, the memory controller simulator module <NUM> simulates a memory controller in accordance with the context metadata derived at <NUM>. For example, the simulation engine module <NUM> uses the control dependencies, thread identifiers, program counters, or other contextual information derived from the trace metadata <NUM> to annotate or highlight portions of the address trace <NUM>. This way the simulation results <NUM> that are output by the simulation engine module <NUM> are enhanced to include meaningful information about the context of addresses observed during the test.

While the techniques for embedding and extracting data from within an address stream are primarily described as promoting memory tests and memory simulations, there are many other use cases for embedding data within address streams. For example, the data can be used by the memory <NUM> or the host device <NUM> to align system or software events with their memory activity, for example, when analyzing memory behavior to debug software issues with execution of the program <NUM>. The data may convey parameters or data, which when embedded in an address stream, direct internal functions or parameters of the memory <NUM>, for example, by specifying values or states of memory-side hardware-registers that configure accelerators or other components of the memory <NUM>.

The entities of <FIG> may be further divided, combined, or used with their respective illustrated components as described herein. The example operating environments <NUM> of <FIG>, <FIG> of <FIG>, and <FIG> of <FIG>, as well as the detailed illustrations of <FIG>, <FIG>, <FIG>, and <FIG> illustrate but some of many possible environments, systems, and devices capable of employing the described techniques. Furthermore, some of the processes and methods described in this document are depicted in <FIG> or <FIG> as groups of blocks that specify operations performed, but the operations specified by the groups of blocks are not necessarily performed in the order or combination shown. Any of one or more of the operations may be repeated, combined, reorganized, or linked to provide a wide array of additional and/or alternate methods, including with other processes described herein. Also, the techniques are not limited to performance by one entity or multiple entities operating on one device, such as a single computer or a single processor. Instead the techniques may be performed by physically separate hardware that may be co-located at one facility or geographically dispersed.

Computer-readable media includes both non-transitory computer storage media and communication media including any medium that facilitates transfer of a computer program from one entity to another. Non-transitory storage media can be any available medium accessible by a computer, such as RAM, ROM, EEPROM such as flash memory, optical or compact disc ROM, and magnetic disk.

Unless context dictates otherwise, use herein of the word "or" may be considered use of an "inclusive or," or a term that permits inclusion or application of one or more items that are linked by the word "or" (e.g., a phrase "A or B" may be interpreted as permitting just "A," as permitting just "B," or as permitting both "A" and "B"). Also, as used herein, a phrase referring to "at least one of" a list of items refers to any combination of those items, including single members. For instance, "at least one of a, b, or c" can cover a, b, c, a-b, a-c, b-c, and a-b-c, as well as any combination with multiples of the same element (e.g., a-a, a-a-a, a-a-b, a-a-c, a-b-b, a-c-c, b-b, b-b-b, b-b-c, c-c, and c-c-c, or any other ordering of a, b, and c). Further, items represented in the accompanying figures and terms discussed herein may be indicative of one or more items or terms, and thus reference may be made interchangeably to single or plural forms of the items and terms in this written description.

Claim 1:
A method comprising:
identifying data for transmission within an address stream (<NUM>) of an interconnect (<NUM>) that couples a host device (<NUM>) to a memory device (<NUM>);
generating a pattern of address bits indicative of the data for transmission within the address stream (<NUM>);
transmitting, via the address stream (<NUM>) and to the memory device (<NUM>), an indication of data, the indication of data including a bitstream with the pattern of address bits; and
communicating, in the address stream (<NUM>), a checksum computed based on an order of the pattern of address bits.