Patent ID: 12216934

The drawings have not necessarily been drawn to scale. Similarly, some components and/or operations may be separated into different blocks or combined into a single block for the purposes of discussion of some of the embodiments of the present technology. Moreover, while the technology is amenable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the technology to the particular embodiments described. On the contrary, the technology is intended to cover all modifications, equivalents, and alternatives falling within the scope of the technology as defined by the appended claims.

DETAILED DESCRIPTION

Technology is disclosed herein that improves the functioning of communication in sensing networks. In particular, a hub system is described that allows connection of multiple sensing devices and multiple processing devices in an efficient, flexible and transparent manner. As a result, multiple sensing devices, including both real-time and non-real-time devices, can be efficiently routed to processing systems in a way that allows for high processing power and/or fail-safe processes.

In various implementations, this disclosure describes a hub that allows the data from each of the sensors to be communicated efficiently to multiple processing systems in order to effectively drive the car in real-time.

The implementations may be capable of interacting with existing sensors and processing systems transparently. For example, a camera sensor that is providing real-time sensor output, can provide the sensor output, unaware that the multi-chip hub is receiving the data, reformatting and copying the data prior to providing the data to multiple processors for redundant processing. It may appear the same to the camera and each of the processors as if the sensor output is provided directly to a single processor. The multi-chip hub is able to process data according to rules, and may handle different types of data or data from different types of sensors differently. The multi-chip hub can improve the efficiency of the multi-chip sensor system, allowing for improved processing.

Referring now to the drawings,FIG.1shows a multi-chip hub120in an operational scenario. Sensors110-112are various sensors connected to multi-chip hub120. WhileFIG.1depicts 3 sensors,110-112, any number of sensors may be used. This is generally true with regard to each of the drawings in this application. The application is not limited to the specific number of elements included in the drawings or in the description. Redundant elements can be removed and additional redundant elements can be added without changing the meaning of the disclosure. Further, sensors110-112may be the same type of sensor, or varied sensors. For example, sensor110may depict a camera recording video. In various implementations, this video may be recorded at a low resolution or high resolution, and at a low or high frame rate. For example, sensor110may be a camera recording video at 2 megapixels and 120 frames per second. Sensor111may be a different sensor, such as a radar sensor. Sensor112may be yet another sensor, such as a lidar sensor. Sensors111and112, acting as a radar sensor and a lidar sensor may record data at a high fidelity or a low fidelity, at a long distance or a short distance. In various alternative implementations, the sensors110-112may include pressure sensors, light sensors, audio sensors, ultrasound sensors, flow sensors, contact sensors, temperature sensors, capacitive sensors, voltage sensors, photoelectric sensors, rotation sensors, radioactivity sensors, acceleration sensors, current sensors, humidity sensors, moisture sensors, smoke sensors, visibility sensors, GPS sensors, or magnetic sensors, among others. Each of these sensors110-112may provide raw data or may include some degree of processing or preprocessing to the data output.

Each of sensors110-112provides data to the multi-chip hub120. The data may be provided in any known format. In an implementation, sensor110, acting as a camera recording video, may provide data according to a Camera Serial Interface (CSI). Other sensors may provide data as ethernet encapsulated data or Controller Area Network (CAN) data, by way of example. Any format that is commonly known could be used for delivery of data from the sensors110-112to the multi-chip hub120.

In an implementation, multi-chip hub120is embodied on a System On a Chip (SOC). The SOC may be a generic SOC, comprising a processor, memory, and input/output ports. Alternatively, the SOC may be a specialized system incorporating additional specialized hardware elements that facilitate the activities of the multi-chip hub120, as will be discussed in more detail below.

Multi-chip hub120provides the data from the sensors110-112to processors130-132. In an implementation, processors130-132may be SOCs. Alternatively, processors130-132may be dedicated signal processing devices, or general purpose processors. WhileFIG.1shows 3 processors130-132, in implementations, the multi-chip hub120may provide sensor data to any number of processors130-132. Processors130-132may be configured to act redundantly, for instance to duplicate processing in the case of a failure. Processors130-132may be configured to operate collaboratively. By way of example, Processor130may be configured to handle processing of signals originating from camera sensors such as sensor110, processor131may be configured to handle processing of signals originating from lidar sensors such as sensor111, and processor132may be configured to handle processing of signals originating from radar sensors, such as sensor112. In an implementation, processors130-132may be configured to operate cooperatively with data distributed among processors130-132such that none of processors130-132becomes overloaded. Alternatively, the processors130-132may operate cooperatively with real-time data processed by processor130and non-real-time data processed by processor131. The operation of multi-chip hub120can be adjusted so that data is delivered to processors130-132such that processors130-132can operate redundantly or cooperatively as needed. For, multiple processors130-132may receive the same data, with each of processors130-132operating independently on the data, including performing differing functions or the same function redundantly, such as for fault handling purposes. This is not meant to be an exhaustive list of how processors130-132can operate together, but is merely a few examples.

The data from the sensors110-112may be provided to processors130-132in raw form, or in some type of processed form. In an implementation, the data from sensor110may be aggregated within multi-chip hub120until a given amount of data has been gathered, at which point the data may be transferred to one or more of processors130-132. Alternatively, the data can be segmented if the data block received is larger than desired. This can serve to match the data delivery with any number of various processing or delivery needs, such as latency needs of processors130-132, PCIe packet size or burst size to increase processing efficiency or facilitate on-the-fly data compression. Multi-chip hub120can provide the data to processors130-132in any format. In an implementation, the data is provided over a memory-mapped communication link such as PCIe or Hyperlink, for example.

FIG.2depicts an internal block diagram of an implementation of multi-chip hub220. Camera210, lidar sensor211, and acceleration sensor212depict sensors utilized in a multi-chip sensor system. As discussed with regard toFIG.1, each of sensors210-212may depict a variety of sensors. For the sake of discussion, an implementation will be described forFIG.2, in which camera210is a camera, lidar sensor211is a lidar sensor and acceleration sensor212is an acceleration sensor. Each of camera210, lidar sensor211, and acceleration sensor212provides sensor data to the multi-chip hub220.

CSI interface230, Ethernet interface231and CAN interface232are in multi-chip hub220. Multi-chip hub220may additionally or alternatively include any number of other different sensor interfaces. Again, for the sake of discussion, in an implementation, CSI interface230is a Camera Serial Interface (CSI). Thus, camera210, provides continuous real-time video data to multi-chip hub220through CSI interface230. Continuous, real-time is not meant to signify that there can never be a break or lag in the data provided by camera210. Rather, continuous and real-time are both meant to signify importance and time criticality to the multi-chip processing system. Thus, since in an implementation, the data from camera210is very important to the multi-chip sensor system, and it is important that the data be processed very quickly, this data is said to be continuous, real-time data. Similarly, lidar sensor211provides data to ethernet interface231. Depending on the function of lidar sensor211, the data it provides may be considered real-time or non-real-time data. Further, acceleration sensor212provides data to CAN interface232. In an implementation, the data provided by the acceleration sensor is considered to be non-real-time data. In an implementation, each of CSI interface230, ethernet interface231and CAN interface232may be configured to operate as a Direct Memory Access (DMA) slave port. In this way, multi-chip hub220can operate seamlessly with sensors designed for a DMA system. Each of CSI interface230, ethernet interface231and CAN interface232connect to interconnect234in multi-chip hub220.

Interconnect234is further connected to on-chip memory233, external memory238and processor235. In an implementation, each of on-chip memory233, external memory238and hub processor235can be generic to an SOC. On-chip memory233and/or external memory238may be configured to provide temporary storage for data from camera210, lidar sensor211, and/or acceleration sensor212in the functionality of multi-chip hub220. Hub processor235provides processing for configuring hub module240to carry out some or all of the functionality of multi-chip hub220through control path configuration. In an implementation, Hub processor235provides processing to carry out some or all of the functionality of multi-chip hub220.

Additionally, multi-chip hub module240is connected to interconnect234. Multi-chip hub module240can be a control module for the multi-chip hub functionality. In an implementation, multi-chip hub module240can additionally include hardware, firmware or software that is specialized to perform, as well as control, multi-chip hub functionality.

Further, interconnect234is connected to PCIe interface236and Hyperlink interface237. PCIe interface236is connected to processors250-251, and Hyperlink interface237is connected to processor252. As discussed above, multi-chip hub may contain additional or alternative output interfaces which have not been shown. Each of PCIe interface236and Hyperlink interface237can be configured to operate as a DMA master port. Multi-chip hub can then be transparent to processors250-252, which can operate as if connected directly to DMA slave sensors.

FIG.3depicts a functional diagram according to an implementation of multi-chip hub module340. Configuration input315is shown within multi-chip hub module340. In implementations, configuration input315may have a user interface that allows a user to fill in information in context definition data316. This could be done directly, by a user making individual selections, or indirectly, by a user creating rules to fill in the information in context definition data316, which will be discussed in more detail with regard toFIG.6. In implementations, configuration input315may not actually be an input, as it may be controlled by firmware or software within multi-chip hub module340, such that multi-chip hub module automatically fills in context definition data316. Context definition data316could be filled in based on the elements connected to multi-chip hub, for example.

Context definition data316is used to control the functionality of multi-chip hub module340as data is handled by multi-chip hub module340. In particular, context definition data316is used by smart data movement engine320to determine which processing blocks are applied to individual data that is received from sensors.

Real-time input301and non-real-time input302are shown within multi-chip hub module340. In an implementation, real-time input301corresponds to one or more of CSI interface230, ethernet interface231and CAN interface232inFIG.2. For instance, if camera210and lidar sensor211fromFIG.2are interpreted to provide real-time data, real-time input301may correspond to both CSI interface230and ethernet interface231. Non-real-time input302may then correlate to CAN interface232. Essentially,FIG.3is depicting that the interfaces are divided into real-time and non-real-time inputs. In an implementation, one ethernet interface my provide real-time data, while another ethernet interface may provide non-real-time data, for example. Alternatively, the input interfaces could be divided into more categories—for example, high priority, medium priority, and low priority.

The real-time input301and non-real-time input302each feed data into the transaction buffer310. Real-time transaction buffer311and non-real-time transaction buffer312are located within transaction buffer310. Data from the real-time input301proceeds into the real-time transaction buffer311, and data from the non-real-time input302proceeds into the non-real-time transaction buffer312. Each of the real-time transaction buffer311and non-real-time transaction buffer312may be implemented as First In First Out (FIFO) buffers.

Data from the transaction buffer310is transferred to the smart data movement engine320. Since the real-time data is separated from the non-real-time data in separate buffers, the real-time data can be given priority in processing by the smart data movement engine320. When data from the transaction buffer310is moved into the smart data movement engine320, it is initially processed by the context mapper330. Context mapper330receives the data from the transaction buffer and determines the context of the data. In an implementation, the context of the data describes which sensor originated the data. The context definition data316describes how data of each context should be handled. Included in the context definition data316is an indication of where data of each context should be stored in memory350. Context memory blocks351-353can correlate to different contexts. For example, data corresponding to context1may be assigned (by the context definition data316) to context memory block351. Context2and context3may respectively correspond to context memory blocks352and353. In an implementation, memory350is embedded memory in the multi-chip hub module340, which is implemented on an integrated circuit. Context memory block351-353are allocated when setting up a context through configuration input315. Context memory blocks351-353provide working area for managing in-flight operations for the assigned context.

Context definition data316also includes description of which processing blocks of smart data movement engine should be applied to a given context of data. For example, context1data may be assigned to be processed through each of re-formatter module331, compression module332, multicast block333and error handler334. Context2data may only be assigned to pass through re-formatter module331and error handler334.

Following processing through the smart data movement engine320, the contextual data is sent to the processors through real-time output360or non-real-time output361. The smart data movement engine320sends the data to the appropriate output based on the context and the context definition data316. As was described above with regard to the real-time input301and non-real-time input302, the real-time output360and non-real-time output361may each correspond to multiple outputs, and/or multiple formats. Similarly, the real-time output360and non-real-time output361may both provide output to a single processor, (or may both provide output to the same three processors, for example), or the real-time output360and non-real-time output361may be divided and provided to separate processors.

Multi-chip hub module340, as a whole, presents a target memory address space for direct memory addressing (DMA) from sensors attached to real-time input301and non-real-time input302. In an implementation, this target memory address space is virtual, with no physical memory allocation. This target memory address space provides a proxy address as a target for transactions from the sensor. This target memory address space can be defined in configuration definition data316, along with further partitioning of the space into per-context virtual memory regions. When a transaction enters the multi-chip hub340, it will be addressed to a destination address. Context mapper330uses the destination address to find a matching target memory address in the configuration definition data316. This target memory address corresponds to one of the per-context virtual memory regions, and consequently, to one of the defined contexts. In an implementation, memory350is a physical memory which is used as a work area to hold data for in-flight transactions as they are processed through the functional blocks in smart data movement engine320. Memory350can be partitioned into multiple context specific memory blocks, such as context memory blocks351-353, and managed by context mapper330. The output can also be defined in context definition data316. For example, the output address may be defined as a linear address translation from the input address space and available output address space. The output address space may be a memory mapped region in PCIe or hyperlink address space.

As will be described with reference back toFIG.3. In step401, Software sets up the context descriptor. Configuration input315can take input from an outside source, such as a user interface, or from automated software to set up context definition data316. This data can include entries for each context that will be processed through smart data movement engine320. For example, context definition data316can include a memory location351-353for the context. Context definition data316can further include indications as to whether data of a certain context will be processed through re-formatter module331, compression module332, multi-cast block333, and/or error handler334. Context definition data316can further inform what type of reformatting or compression might be performed, or how many streams should be multi-cast, where to save the multi-cast data, data thresholds for the context memory blocks351-353, etc.

In step402, a DMA master initiates a transaction addressed to a multi-chip hub memory region. In an implementation, the DMA master may correlate with one of the processors connected to the real-time output360or the non-real-time output361. As the multi-chip hub module340is transparent to the processors, the processors can directly act as a DMA master as request data from one of the sensors. Alternatively, the multi-chip hub module may act as the DMA master, requesting data from the sensors. Multiple DMA masters can concurrently read/write through the real-time input301and non-real-time input302. In either scenario, data is transferred from one or more of the sensors attached to the real-time input301or non-real-time input302.

When the data is received in response to the DMA master initiated transaction, it is received into the transaction buffer310. If the data comes from a real-time source, it will be received into the real-time transaction buffer311. If the data comes from a non-real-time source, it will be received into the non-real-time transaction buffer312. In an implementation, the transaction buffer310is stored in Random Access Memory (RAM) in small amounts, which allows for fast, on the fly processing. This can be realized as fast local access FIFO memory, for example.

In step404, after the data is received into the transaction buffer310, a trigger is sent from the transaction buffer310to the context mapper330. Context mapper330then reads the data from the transaction buffer in step405. If context mapper receives multiple triggers indicating that both real-time data and non-real-time needs to be read, context mapper can prioritize the real-time data by reading initially from the real-time transaction buffer311. In this way, non-real-time data will not prevent real-time data from moving through the multi-chip hub340. Each of the real-time transaction buffer and the non-real-time transaction buffer are FIFO buffers, such that context mapper330can read all of the available data from the real-time transaction buffer before reading the available data from the non-real-time transaction buffer.

Context mapper330then writes the data to the appropriate context memory block351-353in step406. Context memory blocks351-353are defined in context definition data. In an implementation, context memory blocks are RAM, allowing for fast, on the fly processing. For example, these may be embedded local memories within multi-chip hub module340on an integrated circuit, this can avoid the need to store the data in long-term memory at all, creating significant time savings for on-the-fly data movement and processing. Context mapper330implements logic for the context memory blocks351-353, such as occupancy and wrap-around rules. Further, context mapper330can manage the context memory blocks351-353, and identify when the threshold defined in the context definition data316has been met.

In step407, context mapper330sends a trigger to the re-formatter module331when the threshold is met. Re-formatter module331reads the data (step408) from the context memory blocks351-353. In an implementation, re-formatter reformats the data by accumulating the data into efficient blocks of data. By way of example, the threshold size may be selected based on efficient sized frames for compression (256 bytes, 512 bytes, 1024 bytes). This can make compression more efficient. The threshold can also serve to reduce latency, as the multi-chip hub can forward small blocks of data rather than needing to wait, for example, for a full video frame to be complete (approximately 2 megabytes of data). For example, the threshold can be selected so that downstream PCIe or Hyperlink transfers are more efficient based on the packet size and/or data burst size.

In step409, the re-formatter module331forwards the data to the compression module332. The data may move to a context-specific FIFO buffer for the compression module332, or it may proceed directly to the compression module332. In the context definition data316, some contexts are not indicated to need compression. In that case, the data may proceed through the compression module332without performing any compression, or the data may bypass the compression module332.

Following the compression module332, in step411, the data is multicast if needed. The data can enter a context-specific FIFO buffer or proceed directly to the multicast block333. The context definition data316can define whether multicast is necessary for the particular context, how many copies are needed, and where the copies should be stored. If no multicast is necessary, the multicast block333can be bypassed. Each of the data streams from the multicast block333can enter a context specific FIFO buffer for the Error handler.

In step12, error handler334verifies the data, and confirms that the data has been timely provided. Error handler334, for example, handles transport completion and acknowledgements from processors connected to real-time output360or the non-real-time output361as transactions are output over PCIe and/or Hyperlink interfaces. The data then enters a real-time or non-real time FIFO buffer for the master port. The master port can correlate with one of the PCIe interface236or Hyperlink interface237fromFIG.2described above.

FIG.5shows context mapper530in more detail. Data from one or more of the sensors enters the transaction buffer510. Transaction buffer510sends a trigger to context mapper530to indicate that data has arrived in transaction buffer510. The data in the transaction buffer510may include sensor data as well as information related to the sensor data, such as command data, address data, attribute data, etc. Context mapper530reads the data from transaction buffer510. Context mapper530also has access to context definition data516, which may be in the form of a lookup table. InFIG.5, context mapper530shows the information from context definition data516as a lookup table which context mapper530uses with the data from transaction buffer510. By comparing the transaction address against the information encoded in the lookup table, context mapper530assigns a context to the data. As seen in context mapper530, context definition data516can include information such as context ID, input address range, context memory block location, threshold, compression flag, multi-cast flag and output address range. For example, Context ID may be derived by comparing the incoming request destination address to the per-context input address ranges encoded in the context definition data516. The address range is used to identify a corresponding context ID. The input address can be a region inside the multi-chip hub address space. On the output side, the output can be a PCIe or Hyperlink address space matching the output interface (such as real-time output360or the non-real-time output361). Context definition data516can hold the association between input addresses and output address for the transaction. Context definition data516can also contain further information relevant to the context.

Context mapper530coordinates movement between the various sub-blocks of smart data movement engine320, such as re-formatter331, compression module332, multi-cast block333and error handler334. The context definition data516can include context-specific information about each of the sub-blocks. After context mapper530reads the data from the transaction buffer510, context mapper530fills data to the context memory block550and sends a trigger to re-formatter module531.

FIG.6illustrates a method of operating a multi-chip hub in an implementation. The steps in hub initialization sequence650may be carried out with user input, such as through a user interface, or without user input. In step1, a context descriptor is allocated. This context descriptor may be allocated for a given sensor, such as a camera that is attached to the multi-chip hub. The allocation may occur automatically as the sensor is attached to the multi-chip hub, or automatically as the system powers up, for example. Alternatively, a user may indicate that a sensor is attached to the multi-chip hub, and manually allocate the context descriptor, or trigger a context descriptor to be allocated.

In step602, the multi-chip hub allocates per-context input address space. A portion of the input address space is reserved for use by a particular context. The input address space can be entirely virtual, with no physical memory. The per-context input address space can then be used to identify which context is associated with each incoming transaction. The per-context input address space can be saved in the context configuration data316along with a correlation with the appropriate context descriptor.

The context memory block is allocated in step603. The context memory block can be used as a work area buffer for in-flight transactions on a per-context basis. This context memory block may be a section of RAM that is allocated for data associated with a specific context. In an implementation, this context memory block may be a portion of RAM memory built into an SOC integrated circuit that is allocated to a particular context, such as the data provided by a particular camera sensor. In step604, the context descriptor is bound to the transaction buffer space and the context memory block. In an implementation, the context descriptor may be written to memory in the context memory block, for example. The context descriptor may further be written to a lookup table or similar.

Specific transfer attributes are configured next for the context in step605. These attributes may include re-formatting options, such as buffer thresholds, compression settings, multi-cast settings, etc. As described above, these attributes may be configured automatically or with user intervention. Context specific error handling settings, such as timeout settings, are also configured for the context.

When all of the attributes of the context are defined, the context memory block and the context descriptor are set as active in step607. At this point, the initialization sequence650is complete, and the multi-chip hub is ready to operate for that context. The initialization sequence650may need to be performed again for other contexts as well.

In step608, the DMA master is set up to move data from the sensor, such as the camera discussed above, to the transaction buffer. From here, the data will move through the multi-chip hub as discussed above. This is shown in step609. This step repeats until the teardown sequence begin sin step610. This teardown sequence may be triggered by a user through a user interface, or may be automatically triggered, such as when certain thresholds have been met, or when a power-down sequence is begun.

In step611, the DMA master is instructed to stop transfer of data. The context termination sequence660then proceeds. The context memory block is marked as inactive and the context descriptor is marked as inactive. The context teardown is initiated, and confirmed through hardware confirmation. In step615and616, the transaction buffer, context memory block and context descriptor are all reclaimed. In an implementation, the transaction buffer may continue if other contexts continue to utilize the transaction buffer.

FIG.7illustrates computing system701that is representative of any system or collection of systems in which the various processes, programs, services, and scenarios disclosed herein may be implemented. Examples of computing system701include, but are not limited to, integrated circuits, SOCs, server computers, routers, web servers, cloud computing platforms, and data center equipment, as well as any other type of physical or virtual server machine, physical or virtual router, container, and any variation or combination thereof.

Computing system701may be implemented as a single apparatus, system, or device or may be implemented in a distributed manner as multiple apparatuses, systems, or devices. Computing system701includes, but is not limited to, processing system702, storage system703, software705, communication interface system707, and user interface system709(optional). Processing system702is operatively coupled with storage system703, communication interface system707, and user interface system709.

Processing system702loads and executes software705from storage system703. Software705includes and implements multi-chip hub process706, which is representative of the multi-chip hub processes discussed with respect to the preceding Figures. When executed by processing system702, software705directs processing system702to operate as described herein for at least the various processes, operational scenarios, and sequences discussed in the foregoing implementations. Computing system701may optionally include additional devices, features, or functionality not discussed for purposes of brevity.

Referring still toFIG.7, processing system702may comprise a micro-processor and other circuitry that retrieves and executes software705from storage system703. Processing system702may be implemented within a single processing device but may also be distributed across multiple processing devices or sub-systems that cooperate in executing program instructions. Examples of processing system702include general purpose central processing units, graphical processing units, application specific processors, and logic devices, as well as any other type of processing device, combinations, or variations thereof.

Storage system703may comprise any computer readable storage media readable by processing system702and capable of storing software705. Storage system703may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. Examples of storage media include random access memory, read only memory, magnetic disks, optical disks, optical media, flash memory, virtual memory and non-virtual memory, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other suitable storage media. In no case is the computer readable storage media a propagated signal.

In addition to computer readable storage media, in some implementations storage system703may also include computer readable communication media over which at least some of software705may be communicated internally or externally. Storage system703may be implemented as a single storage device but may also be implemented across multiple storage devices or sub-systems co-located or distributed relative to each other. Storage system703may comprise additional elements, such as a controller, capable of communicating with processing system702or possibly other systems.

Software705(including multi-chip hub process706) may be implemented in program instructions and among other functions may, when executed by processing system702, direct processing system702to operate as described with respect to the various operational scenarios, sequences, and processes illustrated herein. For example, software705may include program instructions for implementing a connection process as described herein.

In particular, the program instructions may include various components or modules that cooperate or otherwise interact to carry out the various processes and operational scenarios described herein. The various components or modules may be embodied in compiled or interpreted instructions, or in some other variation or combination of instructions. The various components or modules may be executed in a synchronous or asynchronous manner, serially or in parallel, in a single threaded environment or multi-threaded, or in accordance with any other suitable execution paradigm, variation, or combination thereof. Software705may include additional processes, programs, or components, such as operating system software, virtualization software, or other application software. Software705may also comprise firmware or some other form of machine-readable processing instructions executable by processing system702.

In general, software705may, when loaded into processing system702and executed, transform a suitable apparatus, system, or device (of which computing system701is representative) overall from a general-purpose computing system into a special-purpose computing system customized to establish connections and handle content as described herein. Indeed, encoding software705on storage system703may transform the physical structure of storage system703. The specific transformation of the physical structure may depend on various factors in different implementations of this description. Examples of such factors may include, but are not limited to, the technology used to implement the storage media of storage system703and whether the computer-storage media are characterized as primary or secondary storage, as well as other factors.

For example, if the computer readable storage media are implemented as semiconductor-based memory, software705may transform the physical state of the semiconductor memory when the program instructions are encoded therein, such as by transforming the state of transistors, capacitors, or other discrete circuit elements constituting the semiconductor memory. A similar transformation may occur with respect to magnetic or optical media. Other transformations of physical media are possible without departing from the scope of the present description, with the foregoing examples provided only to facilitate the present discussion.

Communication interface system707may include communication connections and devices that allow for communication with other computing systems (not shown) over communication networks (not shown). Examples of connections and devices that together allow for inter-system communication may include network interface cards, antennas, power amplifiers, RF circuitry, transceivers, and other communication circuitry. The connections and devices may communicate over communication media to exchange communications with other computing systems or networks of systems, such as metal, glass, air, or any other suitable communication media. The aforementioned media, connections, and devices are well known and need not be discussed at length here.

Communication between computing system701and other computing systems (not shown), may occur over a communication network or networks and in accordance with various communication protocols, combinations of protocols, or variations thereof. Examples include intranets, internets, the Internet, local area networks, wide area networks, wireless networks, wired networks, virtual networks, software defined networks, data center buses and backplanes, or any other type of network, combination of network, or variation thereof. The aforementioned communication networks and protocols are well known and need not be discussed at length here.

As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method or computer program product. Accordingly, aspects of the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects of the present invention may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

The included descriptions and figures depict specific embodiments to teach those skilled in the art how to make and use the best mode. For the purpose of teaching inventive principles, some conventional aspects have been simplified or omitted. Those skilled in the art will appreciate variations from these embodiments that fall within the scope of the disclosure. Those skilled in the art will also appreciate that the features described above may be combined in various ways to form multiple embodiments. As a result, the invention is not limited to the specific embodiments described above, but only by the claims and their equivalents.