Configurable circuit telemetry system

Abstract

Various aspects of this disclosure provide a circuit (112), in some examples including a storage element (118), a coprocessor (122), and a telemetry sequencer (120) coupled to the storage element and the coprocessor. The telemetry sequencer is configured to implement a digital state machine to: receive configuration information indicating the type of telemetry data to be generated; retrieve operations and operands, wherein the operations and operands define a series of sequential actions to be performed to generate the telemetry data; drive the coprocessor with operations and operands by passing some of the operations and operands in the operations to the coprocessor for processing; receive and store intermediate outputs of the series of actions as telemetry data in a first format from the coprocessor, and receive and store final outputs of the series of actions as telemetry data in a second format from the coprocessor.

Description

Background Technology

[0001] Telemetry involves the measurement, reporting, and / or collection of data from monitoring systems. In electronic systems, telemetry data can include measurements of voltage, current, temperature, power, or any other metrics or values ​​that are of interest or useful for monitoring the electronic system. As the volume of telemetry data increases, difficulties arise in efficiently generating and / or processing it, such as when monitoring a greater number of metrics. Summary of the Invention

[0002] At least some aspects of this disclosure provide circuitry. In at least one example, the circuitry includes a storage element, a coprocessor, and a telemetry sequencer coupled to the storage element and the coprocessor. The telemetry sequencer is configured to implement a digital state machine to receive configuration information indicating the type of telemetry data to be generated, and to retrieve operations and operands associated with the type of telemetry data to be generated from the storage element. The operations and operands define a series of sequential actions to be performed to generate the telemetry data. The telemetry system is also configured to implement a digital state machine to drive the coprocessor with operations and operands associated with the type of telemetry data to be generated by passing at least some of the operations and operands in the operations to the coprocessor for processing by the coprocessor. The telemetry system is also configured as a digital state machine to receive and store intermediate outputs of a series of actions from the coprocessor as telemetry data in a first format. The telemetry system is also configured as a digital state machine that receives and stores the final output of a series of actions from the coprocessor as telemetry data in a second format.

[0003] Other aspects of this disclosure provide a system. In at least some examples, the system includes a multiphase power supply, a central processing unit, and a telemetry system coupled to the multiphase power supply and the central processing unit. The telemetry system is configured to implement a digital state machine to receive sensor data in a digital format indicating a measured value of the system condition. The telemetry system is also configured to load a plurality of operations and a plurality of operands that together define a series of actions for determining telemetry data using the sensor data as one of the operands. The telemetry system is further configured to implement a digital state machine to perform a series of actions to produce a final output as the result of the final operation of the series of actions and to store the final output as telemetry data in a first format. The system is configured to modify the value of a signal output by the multiphase power supply based at least in part on the produced final output.

[0004] Other aspects of this disclosure provide methods implemented by digital state machines. In at least some examples, the method includes receiving sensor data in a digital format indicating circuit conditions and loading a series of actions to utilize the sensor data as operands to determine telemetry data. The series of actions is defined by multiple operations and multiple operands. Loading the series of actions includes loading multiple operations into telemetry sequence slots for coprocessor computation and loading multiple operands into telemetry sequence slots for coprocessor computation. The method also includes performing the series of actions to produce a final output as the result of the last operation in the series of actions. Performing the series of actions includes passing at least some of the multiple operations and at least some of the multiple operands to the coprocessor for coprocessor processing. The method also includes storing the final series of actions output as telemetry data in a first format. Attached Figure Description

[0005] For a detailed description of the various examples, reference will now be made to the accompanying drawings, in which:

[0006] Figure 1 A block diagram of an illustrative server system based on various examples is shown;

[0007] Figure 2 A schematic diagram is shown for generating time-stamped sequences of telemetry data according to various examples;

[0008] Figure 3 Schematic diagrams are shown of example operational sequences for generating telemetry data, based on various examples; and

[0009] Figure 4 A flowchart illustrating the methods used to generate data based on various examples of telemetry data is shown. Detailed Implementation

[0010] Some methods for providing telemetry data include hardware solutions that are, to some extent, tailored to a specific customer application or a specific measurement. For example, hardware dedicated to a specific parameter (such as voltage, current, temperature, etc.) generates telemetry data for that specific parameter. Some examples of hardware are also dedicated to specific formats, such as conforming to a specific standard, having a specific size, or having a customer-defined self-limiting format. In systems that monitor multiple metrics to generate telemetry data, individual hardware solutions that include each desired format, measurement, or other standard can lead to increased space and / or power consumption in the telemetry circuitry. One such system is a multiphase DC-to-DC power converter.

[0011] In at least some implementations of a DC-DC power converter, multiple parameters are monitored to generate telemetry data. In some examples, this telemetry data is used internally within the DC-DC power converter, for example, for control. In other examples, the telemetry data is used outside the DC-DC power converter and / or the circuitry that generates the telemetry data. In other systems, more or fewer parameters may be monitored to generate telemetry data. The monitored data can be reported in various formats. For example, monitored data can be processed and reported in integer format, full-precision format, half-precision format, linear format, percentage format, Power Management Bus (PMBUS) format, Serial Voltage Identifier (VID) (SVID) format, SVID Interface (SVI) format, Parallel VID (PVID) format, Adaptive Voltage Scaling (AVS) format, I2C format, self-defined format, etc. In some examples, multiple formats of data processed from the original format may be required (e.g., measured and output by sensors, or converted from the analog domain to the digital domain of measured data). For example, a customer may wish to report data in a first format and a second format, where the second format differs from the first format. The same data can be used for calculations in a third format as required by the telemetry system. For example, a customer may want the output current reported in milliamperes (mA) and as a percentage of the maximum output current. The telemetry system may then require the output current in amperes (A) to determine the output power. In telemetry systems where each of these formats is generated by a specific hardware solution, three separate circuits may be required. For example, the telemetry system may include circuitry for determining the output current in mA, circuitry for determining the current in A, and circuitry for determining the percentage of the maximum output current.

[0012] In modern server systems, and especially high-performance server systems, many different standards can be monitored, and at least some of these standards can be reported and / or used by the server system in multiple formats. In at least some examples, such high-performance systems include at least a system that utilizes a power supply and can adjust the performance of a processing unit (e.g., a central processing unit (CPU)) based on telemetry data associated with that power supply. The format of the requested telemetry data can change at any time, such as late in the telemetry system development cycle or during the telemetry system's lifecycle. For example, if the telemetry system performs measurements with specific hardware circuitry, as described above, and does not include hardware circuitry dedicated to new format requirements, the telemetry system may become obsolete shortly after startup. Therefore, it is desirable for the telemetry system to be configured to provide telemetry data in a manner largely separate from the hardware that generates the telemetry data. For example, the telemetry system could use the same hardware circuitry to generate telemetry data to produce multiple telemetry data parameters (e.g., voltage, current, power, temperature, efficiency, etc.) and in multiple formats. Furthermore, in some examples, the telemetry system may have the capability to provide telemetry data that a particular customer is not interested in or is not interested in at a particular time, and therefore generating that telemetry data at a particular time fails to effectively utilize resources. However, the telemetry system may operate sequentially, causing it to still generate and output that telemetry data, resulting in reduced processing efficiency and increased latency. Therefore, it may also be necessary for the telemetry system to include configurability regarding which operations are performed and / or which telemetry data is generated, such as in a non-sequential mode, rather than being limited to sequential operation.

[0013] Implementing such functionality using a specific hardware solution results in a large amount of circuitry. At least some of this circuitry may be largely redundant or unused by some customers, leading to increased circuit size and cost. Despite this large amount of circuitry, some customers may still lack the required functionality when it is highly customized for their specific needs. To provide customization, some telemetry systems may utilize microcontrollers or other forms of CPUs to generate telemetry data. However, telemetry data often changes rapidly and may have relatively short timeframes for generation, reporting, and action based on the telemetry data to prevent damage to the monitored components that generate the data. For example, some implementations may require the generation and reporting of telemetry data in less than about one microsecond. Microcontrollers or CPUs that offer configurability lacking in specific hardware solutions may be unable to meet the timing requirements for telemetry data generation and reporting, especially when using floating-point operations. Furthermore, the generation and reporting of telemetry data is a continuous process, occurring for the duration the monitored system is powered on in many implementations. Allowing the system's microcontroller or CPU to generate telemetry data would prevent that microcontroller or CPU from performing other processing, thus limiting system performance.

[0014] At least some aspects of this disclosure provide a telemetry system. In some examples, the telemetry system includes multiple configurable points. For example, the telemetry system includes parallel operations time-multiplexed into telemetry sequence slots, where the slots are executed sequentially. However, unlike the hardware-specific solutions discussed above, the configurability of the telemetry system allows operations to be omitted from the telemetry sequence slots. For example, an operation can be omitted when it corresponds to telemetry data that is not of interest to the client or is not needed at a particular time (e.g., during startup). The telemetry system can also be configured with operations performed on sensor data. For example, while the hardware solutions discussed above are dedicated to a specific series of actions that generate and format telemetry data, the telemetry system provided herein is dynamic. As used herein, dynamism can indicate that the telemetry sequence slots can be changed based on a desired operating mode. Dynamics can also indicate that the operand can be changed in a series of actions. For example, a changing operand such as temperature can be changed in a series of actions that utilize temperature as the operand without relying on pre-encoded data. Furthermore, the dynamic nature of telemetry sequence slots allows for the selection of different operands based on one or more results of a series of actions that generate telemetry data or measurement or sensing data. For example, a given operand may have a first value under certain conditions (e.g., when the measured temperature exceeds a threshold) and a second value under other conditions (e.g., when the measured temperature does not exceed the threshold). In at least some embodiments, the telemetry sequencer implements a digital state machine that performs multiple actions to generate telemetry data using the same hardware set, such as a coprocessor. In at least some examples, the coprocessor is an arithmetic logic unit (ALU) or other components capable of performing mathematical calculations and / or logical operations to assist the telemetry sequencer in generating telemetry data.

[0015] In some examples, a series of actions includes one or more mathematical operations, each accepting at least two operands. In some examples, the mathematical operations are cascaded, allowing the telemetry system to provide one or more insertion points or intermediate / additional outputs before the final mathematical operation in the series of actions. For example, in generating output current telemetry data in mA, the telemetry system can provide insertion points before a series of actions that convert the output current from A to mA. In this way, the telemetry system can store the output current in A for subsequent calculations (such as power in watts) while using the same hardware and providing the output current in mA substantially simultaneously. Furthermore, the configurability and programmability of the telemetry system allow the customer to freely add a series of actions to generate telemetry data of a desired type or format. For example, if it is unknown at the time of manufacturing the telemetry system that a particular type of telemetry data may be needed later, but a particular type of telemetry data is still required, the telemetry system can be programmed to provide that telemetry data. In contrast, the specific hardware solutions discussed above would lack the hardware configuration and components necessary to provide the new specific types of telemetry data that the telemetry system of this disclosure can provide.

[0016] At least some embodiments of the telemetry system disclosed herein improve upon specific hardware solutions for generating telemetry data by providing programmability and configurability to generate specific telemetry data at a specific time using the same hardware components that generate different telemetry data at another time. This programmability enables the telemetry system of this disclosure to have different sequences of telemetry data generation during startup, after startup, when a fault is detected, during calibration, etc. This improves upon specific hardware solutions that follow a particular order of telemetry data generation, regardless of whether the generated telemetry data is useful or needed at a given time, thus wasting resources and time. The telemetry system of this disclosure further improves upon specific hardware solutions for generating telemetry data by enabling the output of intermediate and final results of a series of actions for generating telemetry data, thereby reducing redundant processing and saving time compared to specific hardware solutions that generate only one type and one format of telemetry data per solution. The telemetry system of this disclosure also improves upon specific hardware solutions for generating telemetry data by providing post-manufacturing configurability to support the generation of new telemetry data or new formats of telemetry data, which specific hardware solutions would be unable to perform due to their hardware nature.

[0017] The telemetry system of this disclosure is improved by enabling the delivery of telemetry data to components consuming less area more quickly and with lower power consumption, rather than by a specific hardware solution or CPU that generates telemetry data. In particular, at least some embodiments of the telemetry system of this disclosure have a die size approximately 2 square millimeters smaller than a specific hardware solution used to generate a given type of telemetry data (e.g., current in one or more formats). For example, the telemetry system of this disclosure can consume approximately 1.15 square millimeters of die space compared to a hardware-specific solution consuming approximately 3.2 square millimeters of die space. This reduction in die surface area leads to a decrease in the manufacturing cost of the telemetry system of this disclosure and a reduction in the bill of materials (e.g., required components) in the telemetry system of this disclosure, further reducing the cost of the telemetry system of this disclosure.

[0018] Turn now Figure 1 An illustrative server system 100 is shown. Although described as a server system, system 100 may represent implementations of other systems. For example, system 100 may generally represent other systems that implement and monitor multiphase power supplies or any system that measures telemetry data. In at least one example, system 100 includes a power source 102, a power supply 104, and a CPU 106. Power source 102 is, for example, mains power or power received from an adapter that converts mains power from alternating current (AC) to DC. In other examples, power source 102 is a battery or other power storage device. The power supply is 104, which in some examples is a component that receives power from power source 102 and generates one or more power signals to power CPU 106. Although only one coupling between power supply 104 and CPU 106 is shown, any number of couplings may be present in various examples. Furthermore, system 100 may include one or more additional components (not shown) that also receive one or more power signals from power supply 104.

[0019] In at least one example, the power supply 104 is a multiphase power source. For example, the power supply 104 includes multiple phases 108A, 108B, ... 108N, which are selectively controlled as active / active or inactive / inactive by a multiphase controller 110. The multiple phases 108A-108N are selectively controlled based on the load applied to the power supply 104 by the CPU 106 and / or any other component receiving power supply signals from the power supply 104. In at least some examples, the multiphase controller 110 is coupled to the CPU 106 and configured to receive instructions from the CPU 106 to control at least some of the multiple phases 108A-108N. Each of the multiple phases 108A-108N is, for example, a power regulator. The power supply 104 also includes a telemetry system 112. The telemetry system 112 includes, in at least some examples, an analog-to-digital converter (ADC) 114 and a core 116. In some examples, telemetry system 112 also includes multiple ADCs for the telemetry system, and each ADC (including ADC 114 of the telemetry system) may have one or more channels. ADC 114 is configured to receive an analog signal representing the state of at least one phase of phases 108A-108N and convert the analog signal into a digital signal. ADC 114 then provides the digital signal to core 116 for further processing. The analog signal representing the state of at least one phase of phases 108A-108N can be received from any suitable component or sensor (not shown), and its scope is not limited to this document.

[0020] Core 116 is configured to receive a digital signal output by ADC 114 and generate telemetry data at least in part based on that digital signal. In some examples, the generation of telemetry data is controlled at least in part by configuration information received from CPU 106. In other examples, core 116 is programmed to have a default telemetry data generation operation that can be modified by CPU 106. Alternatively, configuration information can be received from another device (not shown) capable of performing logical operations and / or processing. For example, configuration information can be received from a device other than CPU 106 (not shown) that implements a state machine to determine and output the configuration information. In at least one example, core 116 receives configuration information from CPU 106 indicating the desired type, desired format, etc., of the telemetry data. Based on the configuration information received from CPU 106, core 116 generates a time-multiplexed sequence of operations to generate the telemetry data requested by CPU 106, the format of which is also requested by CPU 106. In other examples, at least some of the configuration information is generated from default telemetry data stored within core 116, without first receiving it from CPU 106.

[0021] In at least some examples, core 116 includes storage element 118, telemetry sequencer 120, and coprocessor 122. Storage element 118 can be any suitable device(s) capable of storing data, such as random access memory (RAM), including static RAM (SRAM), one or more registers, etc. In at least some examples, telemetry sequencer 120 generates telemetry data based on data received from ADC 114, data stored in storage element 118, and / or data stored in local memory (not shown) of telemetry sequencer 120. In at least one example, telemetry sequencer 120 implements a digital state machine that generates the telemetry data. In at least some examples, the state machine implements the provisions of this disclosure. Figure 4 The operations are shown and discussed in more detail to provide at least some of the functionality of this disclosure. In at least some examples, the digital state machine offers advantages over other types of processing, such as general-purpose processors, CPUs, or other forms of processing. For example, when multiple data formats are involved, a CPU can be very slow in generating telemetry data. For example, an exemplary or general-purpose CPU may require approximately 50-60 clock cycles to perform a single multiplication between two operands in a single-precision format. For example, for a series of actions involving multiple (e.g., 10-15) data format conversions and multiple (e.g., 10-15) operations to generate telemetry data, a CPU may require a very long time to produce a result. In contrast, the telemetry system driven by the digital state machine of this disclosure can perform approximately 10 operations in a total of approximately 10-20 clock cycles. Therefore, in at least some examples, the telemetry sequencer 120 implements a digital state machine and performs operations without using a CPU. Figure 4 The actions of method 400, in some examples, include receiving configuration information from the CPU (e.g., the type and / or format of the telemetry data to be generated, a series of actions to be performed, operations, operands, and / or intermediate output points) and / or providing intermediate and / or final outputs to the CPU. For example, in at least some embodiments, according to the telemetry data generation process of this disclosure, the telemetry sequencer 120 does not use the CPU when generating telemetry data.

[0022] In at least one example, local memory may be a register that stores a register file containing data. For example, telemetry sequencer 120 may include registers (not shown) implemented as local memory. Telemetry sequencer 120 may also include a telemetry engine (not shown) that implements a state machine to generate telemetry data. In some examples, coprocessor 122 includes functions and / or circuitry for performing one or more mathematical calculations. For example, in at least some embodiments, coprocessor 122 is or includes an arithmetic logic unit (ALU). For example, in various embodiments, coprocessor 122 includes any one or more of an adder, multiplier, divider, data filter(s), data format converter(s), etc. In at least some examples, components of coprocessor 122 may be hardware circuitry optimized for performing a specific task. For example, an adder is optimized for performing addition or subtraction operations, a multiplier is optimized for performing multiplication operations, etc. At least some components of coprocessor 122 may be shared between or within the hardware circuitry of coprocessor 122.

[0023] To generate telemetry data, telemetry sequencer 120 loads operations and computational objects into local memory and invokes the operations for execution by coprocessor 122. For example, based on digital signals received from ADC 114 and configuration information received from CPU 106, telemetry sequencer 120 loads a series of actions into local memory. In at least some examples, loading a series of actions includes identifying operations included in the series of actions and invoking the operations in telemetry sequence slots for sequential execution by coprocessor 122.

[0024] After loading a series of actions, telemetry sequencer 120 loads the operands of the series of actions into local memory. The operands include any one or more of the following: digital signals received from ADC 114, data stored in storage element 118, data received from CPU 106, and / or data stored in local memory. For example, telemetry sequencer 120 may store a list of operations and / or at least some operands associated with the series of actions to generate telemetry data in the local memory of telemetry sequencer 120 based on configuration information received from CPU 106. In another example, telemetry sequencer 120 may store a list of operations and / or at least some operands associated with the series of actions that generate telemetry data in storage element 118. In the absence of specific configuration information received from CPU 106, the list of operations and / or at least some operands associated with the series of actions stored in storage element 118 can provide default operations for telemetry sequencer 120. When telemetry sequencer 120 receives configuration information requesting telemetry data from CPU 106 (the series of actions for which are stored in the local memory of telemetry sequencer 120), the telemetry sequencer accesses the local memory to load the operations of the series of actions into the telemetry sequence time slot. In other examples, a list of operations and / or at least some operands associated with the series of actions that generate the telemetry data are stored in storage element 118 and loaded into the telemetry sequence time slot by telemetry sequencer 120 from storage element 118.

[0025] In at least some examples, telemetry sequencer 120 loads data into telemetry sequence slots in a parallel manner. For example, in at least some examples, while an operation associated with a first series of actions that generate first telemetry data is being executed, telemetry sequencer 120 loads operations and / or operands associated with a second series of actions that generate second telemetry data into the telemetry sequence slot. In at least some examples, this parallel processing optimizes the performance of core 116 by reducing the amount of time consumed in generating telemetry data. For example, parallelism enables core 116 to generate telemetry data for each telemetry sequence slot, rather than alternating between telemetry data generated in one telemetry sequence slot and a new series of actions loaded in the next telemetry sequence slot.

[0026] In at least some examples, the generated telemetry data can be stored by telemetry sequencer 120 in storage element 118 or in the local memory of telemetry sequencer 120, and reused as a computational object for determining additional telemetry data. For example, telemetry data indicating the output current in PMBUS format can be stored and reused as a computational object to determine the output current in another different format, such as SVID format. In this way, redundant processing common to both telemetry formats is reduced, and the same hardware that determines the output current in PMUS format can also determine the output current in SVID format. This reuse of hardware reduces the physical size of core 116 compared to telemetry systems that use hardware solutions specifically tailored for each type of telemetry data and / or the format to be output.

[0027] In at least some examples, telemetry sequencer 120 passes a pair of operands and operations to coprocessor 122 for processing. In at least some examples, providing operands and operations to coprocessor 122 is referred to as driving coprocessor 122. For example, telemetry sequencer 120 drives coprocessor 122 to produce output by providing a pair of operands and operations to be performed on coprocessor 122. Coprocessor 122 then provides the output back to telemetry sequencer 120, which either stores the output or returns it as another operand for processing to coprocessor 122. For example, after a series of actions are invoked into a telemetry sequence slot, telemetry sequencer 120 performs operations with the assistance of coprocessor 122. For example, for each operation in a series of actions, telemetry sequencer 120 passes an operand and an identifier of the type of operation to be performed to coprocessor 122. Coprocessor 122 then uses the received operand to perform the identified operation and returns the result to telemetry sequencer 120. Then, the telemetry sequencer 120 stores the result in local memory or storage element 118, reports the result (e.g., to CPU 106), or provides the result, along with an identifier of another operand and another operation, back to the coprocessor 122 for execution by the coprocessor 122. In at least some examples, the coprocessor 122 is any device capable of performing arithmetic operations, including at least addition, subtraction, division, and multiplication. In some examples, the coprocessor 122 is a collection of hardware solutions for performing operations. For example, the coprocessor 122 may include hardware adders, hardware multipliers, etc. In other examples, the coprocessor 122 may include programmable elements that perform at least some of the operations discussed herein. For example, the coprocessor 122 may be an arithmetic logic unit (ALU), a field-programmable gate array (FPGA), and / or any other structure capable of performing arithmetic operations or other operations attributable to the coprocessor 122 discussed herein. In at least some examples, the coprocessor 122 includes additional functions implemented in hardware or software, such as format conversion and / or data filtering.

[0028] In at least some examples, the telemetry sequencer 120 performs a series of actions to generate telemetry data by executing a series of operations, each operation accepting two operands as input. In some examples, executing the sequence of operations includes passing the operands to the coprocessor 122 for execution by the coprocessor 122 and receiving the results from the coprocessor 122. In some examples, telemetry data may be required in multiple formats (e.g., as indicated in the acknowledgment information). Alternatively or additionally, in some examples, it may be expected to use the results of operations that are not the result of the entire series of actions performed by the telemetry sequencer 120 when determining other telemetry data. In such examples, a series of actions may be specified between operations. For example, for a series of actions to generate telemetry data that includes nine operations for generating telemetry data, in at least some examples, a series of actions may be specified to produce one or more intermediate outputs before the ninth operation of the series of actions. For example, a series of actions of nine operations and ten operands may produce telemetry data indicating the output current in a first format (such as SVID format). However, by specifying a series of actions after the sixth operation (or some operations other than the final operation), telemetry data indicating the output current in a different format (such as the PMBUS format) is generated. In this way, as described above, two different formats of telemetry data are generated using essentially the same hardware resources and within the same telemetry sequence time slot. This specification of the series of actions before all other operations in the series enables more efficient processing by reducing redundant operations and determining multiple telemetry formats in a parallel manner (e.g., substantially simultaneously).

[0029] Turn now Figure 2 The diagram illustrates an example time-stamped sequence 200 used to generate telemetry data. In at least some examples, the time-stamped sequence 200 is generated by a telemetry sequencer 120 and controls the order of operations performed by a coprocessor 122, each operation as described above. Figure 1The discussion focuses on, for example, when telemetry sequencer 120 receives a request to generate telemetry data, it inserts or invokes a series of actions for generating that telemetry data into the telemetry sequence slot. In other examples, telemetry sequencer 120 is configured to operate at any time the telemetry sequencer 120 is powered on, such as according to a default or pre-programmed telemetry data generation process or schedule. In such examples, when telemetry sequencer 120 receives a request to generate telemetry data, it outputs the requested telemetry data after generating the telemetry data according to a default or pre-programmed telemetry data generation process or schedule. In at least some examples, with the assistance of coprocessor 122, the series of actions invoked in the telemetry sequence slot are executed sequentially by telemetry sequencer 120. In some examples, certain series of actions may be repeated at a higher frequency in the telemetry sequence slot compared to other series of actions. For example, telemetry data that needs to be kept more timely, more important, or needed in a faster manner may be invoked more frequently in the telemetry sequence slot. In contrast, telemetry data that is not needed as quickly or is less important can be invoked less frequently in telemetry time slots. Furthermore, certain telemetry data that can typically be generated at specific times (such as during system startup) but which the customer does not want can be excluded from the telemetry sequence time slots to prevent unnecessary processing. This is an improvement over at least some examples of telemetry systems that utilize hardware-specific solutions to generate telemetry data. For example, at least some of these hardware-specific solutions generate telemetry data sequentially, moving from one telemetry parameter to another until all telemetry data is generated and then starting again. This wastes processing power and energy generated for telemetry data that the customer is not interested in, and does not include the flexibility to change the frequency of generating specific telemetry parameters to suit a particular implementation.

[0030] like Figure 2 As shown, telemetry sequence slots are invoked in parallel. For example, before telemetry sequencer 120 executes a series of actions A, it loads the operation sequence and operands used to implement actions A into the telemetry sequence slots. While executing actions A, telemetry sequencer 120 loads the operation sequence and operands used to implement actions B. This process is repeated, where while actions are being executed in the current telemetry sequence slot, the operation sequence and operands used to implement the actions are loaded in the next telemetry sequence slot. Figure 2Additionally, the invocation is dynamic or configurable. For example, during the first and second operation cycles (202 and 204, respectively), telemetry data corresponding to a series of actions C is not of interest, and therefore this series of actions is not invoked in the telemetry sequence slots for execution by the coprocessor 122. However, starting from the third cycle of operation 206, the telemetry data corresponding to a series of actions C becomes of interest, and the series of actions is invoked in the telemetry sequence slots for execution by the coprocessor 122. Furthermore, although the telemetry data corresponding to a series of actions D is of interest for the first to third cycles of operations 202-206, the telemetry data corresponding to a series of actions D becomes no longer of interest for any desired time period starting from the fourth cycle of operation 208. Therefore, starting from the fourth cycle of operation 208, the series of actions D is no longer invoked in the telemetry sequence slots and continues until the telemetry data corresponding to a series of actions D becomes of interest again. Although regarding Figure 2 A series of actions A, B, C, and D are shown, but in various examples, any number of actions can be invoked and executed within an operation cycle. Furthermore, a series of actions can be invoked and executed more than once within a single operation cycle.

[0031] Turn now Figure 3 A schematic diagram of an example operational sequence 300 for generating telemetry data is shown. In at least some examples, sequence 300 is generated by telemetry sequencer 120, as described above. Figure 1 The discussion focuses on, for example, the telemetry sequencer 120 determining operations and operands corresponding to telemetry parameters based on configuration information received by the telemetry sequencer 120, or a default operation sequence. The telemetry sequencer 120 loads these operations and operands into telemetry sequence slots. In at least some examples, these operations and operands are sequentially loaded into telemetry sequence slots by the telemetry sequencer 120. Then, by passing a pair of operands (and in some examples, at least one operand's data type) and operations to the coprocessor 122 for processing, the telemetry sequencer 120 executes the operations shown in sequence 300. For illustrative purposes, the example of determining the output current will be used to describe this. Figure 3 .However, Figure 3 This disclosure is not limited to this, and Figure 3 The teachings and this disclosure apply to multiple series of actions and multiple telemetry parameters. Additionally, Figure 3 At least some examples correspond to Figure 2 The time-stamped sequence 200 is a telemetry sequence time slot. For example, the operation shown in sequence 300 will be passed by telemetry sequencer 120 to coprocessor 122 in a telemetry sequence time slot by passing the operand and operation identifier (e.g., as such). Figure 2The sequence 300 is executed by one of a series of actions A, B, C, or D. Furthermore, the operations and operands of sequence 300 are loaded into the telemetry sequence time slot by telemetry sequencer 120 during the telemetry sequence time slot, which is a telemetry sequence time slot preceding the telemetry sequence time slot, during which sequence 300 is executed by telemetry sequencer 120.

[0032] In at least one example, the output current of a specific device in the first format can be determined based on a series of actions: IOUT_1 = (RawData1 – RawData2) * NumberOfPhasesOfPowerConverter * Coefficient1 * Coefficient2 + Coefficient3. Then, the output current of a device in the second format can be determined based on a series of operations: IOUT_2 = IOUT_1 * Coefficient4 / Coefficient5 * Coefficient6.

[0033] Regarding the selection of operations and operands, operand identifiers can be assigned to the above series of actions, such that IOUT_1 = I1, I1 = ((AB)*C*D*E) + F, IOUT_2 = I2, and I2 = I1*G / H*I. In the above, A = RawData1, B = RawData2, C = NumberOfPhasesOfPowerConverter, D = Coefficient1, E = Coefficient2, and F = Coefficient3. Furthermore, G = Coefficient4, H = Coefficient5, and I = Coefficient6. In at least some examples, each of the coefficients can be a fixed or variable coefficient. For example... Figure 3 As shown, the telemetry sequencer 120 loads operations and operands sequentially to implement the aforementioned series of actions. For example, the series of actions for determining IOUT_2 includes eight operations, the first five of which are sequentially shared with the series of actions for determining IOUT_1. Therefore, the output of the fifth operation for determining IOUT_2 is IOUT_1. By generating IOUT_1 simultaneously with IOUT_2, redundant processing (e.g., the first five operations) can be prevented. Furthermore, essentially the same hardware is used to generate IOUT_2 and IOUT_1, reducing space compared to a hardware-specific solution using dedicated hardware for generating IOUT_2 and separate hardware for generating IOUT_1.

[0034] Although Figure 3Eight operations are shown, but in various examples, any suitable number of series of actions can be loaded based on system constraints and design trade-offs. For example, when most series of actions will be X or fewer operations, where X is any non-zero integer, the system can be designed to support a maximum of X operations for a single series of actions. In at least some examples, this can optimize the size of the system (e.g., by preventing the consumption of extra space to support additional operations that are not frequently used). In at least one example, when more than X operations are needed to determine a particular telemetry parameter, the output of a series of actions containing X operations can be used as the input (e.g., an operand) of another series of actions containing X or fewer operations. In at least one example of the system disclosed herein, X is 9.

[0035] As another example, the output current IMON_PMBUS of a PMBUS-formatted device can be determined based on a series of actions. IOUT -V AMP_OFFSET Gain-V REF )*(1 / 2^ADC _resolution ) / R SENSE )+I CHANNEL_OFFSET In the series of actions described above, V IOUT It is a voltage signal representing the output current of the device, V AMP_OFFSET It represents the generation of V IOUT The amplifier offset value of the amplifier, Gain is the constant gain value, V REF This is the reference voltage, ADC_resolution is the resolution of the ADC 114, R SENSE It is the resistance value of the sensing resistor, and I CHANNEL_OFFSET This is the channel offset value of the ADC 114 used to perform the measurement related to IMON_PMBUS. The device's output current can then be determined in SVID format according to a series of actions: IMON_SVID = (IMON_PMBUS) * ((1 / ICCMAX) * 0x7FFF)). In this series of actions, ICCMAX is the maximum current that can be supplied to the device, and 0x7FFF is a constant.

[0036] Regarding the selection of operations and operands, operand identifiers can be assigned to the above series of actions, such that IMON_PMBUS = I1, I1 = AB * CD * E / F + G, IMON_SVID = I2, and I2 = I1 * H * I. In the above, A = V IOUT B = V AMP_OFFSET C = Gain, D = V REF , E=1.92 / 2^ADC_resolution*200, F=R SENSE G = ICHANNEL_OFFSET Furthermore, H = 1 / ICCMAX and I = 0x7FFF. For example... Figure 3 As shown, the telemetry sequencer 120 loads operations and operands sequentially onto the processor 122 to perform the aforementioned series of actions. For example, the series of actions for determining IMON_SVID includes eight operations, the first six of which are sequentially shared with the series of actions for determining IMON_PMBUS.

[0037] Therefore, the output of the sixth operation used to determine IMON_SVID is IMON_PMBUS. By generating IMON_PMBUS simultaneously with IMON_SVID, redundant processing (e.g., the first six operations) is prevented. Furthermore, essentially the same hardware is used to generate IMON_SVID and IMON_PMBUS, reducing space requirements compared to hardware-specific solutions that use dedicated hardware for generating IMON_SVID and separate hardware for generating IMON_PMBUS.

[0038] As another example, V_PMBUS = ((V OUT -V AMP_OFFSET Gain-V COMMON_MODE )-V CHANNEL_OFFSET The device's output voltage is determined using PMBUS format. In the series of actions described above, V... OUT V is the output voltage of the device. AMP_OFFSET To represent the generation of V OUT The amplifier bias value of the amplifier, Gain is the constant gain value, V COMMON_MODE It is the common-mode voltage, and V CHANNEL_OFFSET The offset value of the ADC 114 channel is used to perform the measurement related to V_PMBUS. Then, according to a series of actions, V_SVID = (V_PMBUS)*((1 / V MAX The output voltage of the device is determined in SVID format using the formula 0x7FFF. In the above series of actions, V... MAX It is the maximum voltage that can be supplied to the device and 0x7FFF is a constant.

[0039] Regarding the selection of operations and operands, operand identifiers can be assigned to the above series of actions, such that V_PMBUS = V1, V1 = AB * CDE, Vv_SVID = V2, and V2 = V1 / F * G. In the above, A = V... OUT B = V AMP_OFFSET C = Gain, D = V COMMON_MODE And E = V CHANNEL_OFFSET Furthermore, F = 1 / V MAX G = 0x7FFF. For example... Figure 3 As shown, the telemetry sequencer 120 loads operations and operands sequentially onto the processor 122 to perform the aforementioned series of actions. For example, the series of actions for determining V_SVID includes six operations, the first four of which are sequentially shared with the series of actions for determining V_PMBUS. Therefore, the output of the fourth operation for determining V_SVID is V_PMBUS. By generating V_SVID along with V_PMBUS, redundant processing (e.g., redundant processing of the first four operations) can be prevented. Furthermore, substantially the same hardware is used to generate V_SVID and V_PMBUS, reducing space requirements compared to hardware-specific solutions that use dedicated hardware for generating V_SVID and separate hardware for generating V_PMBUS.

[0040] Typically, in at least some examples, a series of actions for generating telemetry parameters and / or telemetry data in a specific format can be broken down into a series of cascaded operations that are programmable by a client or user via configuration information or pre-programmed during system manufacturing. For example, each telemetry parameter (sometimes referred to as a telemetry channel or simply a channel) may have a corresponding storage location that stores configuration settings for that telemetry parameter, including at least a series of actions, and in some examples, at least some operands. In some examples, the storage location is storage element 118, while in other examples, the storage location is another device capable of storing data. In at least some examples, the configuration settings are transferred (e.g., copied) from the storage location to the storage element of the telemetry sequencer 120 before the sequencer 120 generates telemetry data according to the configuration settings. To generate a specific telemetry parameter, the sequencer 120 accesses the corresponding storage location to obtain operations and / or at least some operands associated with the series of actions used to determine the telemetry parameter. Subsequently, the telemetry sequencer 120 loads operations and / or at least some operands, along with data output from the ADC 114 (which may have been previously stored), into the telemetry sequence slots to perform a series of actions.

[0041] In addition, although Figure 3 The example shows an insertion point or intermediate output, and this insertion point is between operation six and operation seven. However, in other examples, there can be any number of insertion points, either before or after any desired operation in a series of actions. For example, a series of actions may have no insertion point, or may have one insertion point, two insertion points, three insertion points, etc., depending on the requested telemetry parameters and / or telemetry format.

[0042] Turn now Figure 4 An illustrative flowchart of a telemetry data generation method 400 is shown. In at least some examples, method 400 is at least partially composed of... Figure 1 Core 116 implementation and referenced when describing method 400 Figure 1The components. In at least some examples, method 400 is a method for generating telemetry data by means of a configurable or programmable telemetry system that does not use hardware dedicated to each telemetry parameter or supported telemetry format. Instead, the telemetry system can be programmed according to a series of actions used to generate the requested telemetry parameters and / or telemetry format. In at least some examples, this independence from a hardware-specific solution for generating telemetry data, and further, the avoidance of using a CPU core to generate telemetry data, makes operation according to method 400 faster and more flexible. For example, method 400 is capable of generating telemetry data in about 300-400 nanoseconds in a 100 MHz system (e.g., generating telemetry data in about 30-40 clock cycles). This makes the generation of telemetry data much faster compared to at least some examples of CPU-generated telemetry data. Furthermore, after manufacturing a system implementing method 400, method 400 helps to define additional telemetry parameters or formats, or modify existing telemetry parameters or formats, thereby improving the hardware-specific solutions discussed elsewhere herein.

[0043] In operation 402, raw data is stored. In at least some examples, the raw data is sensor data (e.g., data generated by sensor measurements). In some examples, the sensor data is a measurement output in digital format by the ADC 114. In at least some examples, the measurement relates to the condition of circuitry such as a power converter. In some examples, the power converter is a component of a multiphase power supply. In other examples, the circuitry is any circuitry that is monitored and requests telemetry data. In some examples, the data is stored in short-term (e.g., volatile) memory, such as SRAM, registers, non-volatile memory, or other suitable storage elements or locations that can be accessed later for determining and / or reporting telemetry data.

[0044] In operation 404, it is determined whether preprocessing of the sensor data is required. If preprocessing is required, method 400 proceeds to operation 406. In operation 406, preprocessing is performed. Preprocessing may include determining the finite impulse response (FIR) of the sensor data, determining the average value of the sensor data, determining the offset of the sensor data, etc. In operation 408, the preprocessed data is stored. The preprocessed data can be stored in any suitable manner and at any suitable location, such as in operation 402 discussed regarding the sensor data.

[0045] Returning to operation 404, when preprocessing is not required, method 400 proceeds to operation 410. In operation 410, a series of actions is loaded. In at least some examples, the series of actions is loaded into a telemetry sequence slot by telemetry sequencer 120 as a series of operations whose operands are loaded according to subsequent operations. In some examples, the series of actions is accessed from memory and one or more operations and operands are defined for generating specific telemetry parameters and / or telemetry data in a specific format. In at least some examples, the telemetry sequence slot is stored in local storage elements of telemetry sequencer 120. In some examples, core 116 previously receives a series of actions from the user via a processor or other means configuring core 116, and then stores them in memory by core 116. Telemetry sequencer 120 loads a series of actions into the telemetry sequence slot, in some examples, as a cascaded series of operations, where the output of a previous operation is the input of a subsequent operation, until the final result is determined. As used herein, the final result or output of a series of actions is a value obtained by performing and / or calculating the last operation of the series of actions. For example, in a series of actions (A+B)*C=D, D is the final result of the series of actions. As used herein, an intermediate result or output of a series of actions is a value generated based on the execution and / or computation of operations within the series of actions that are not the final operation of the series. For example, for a series of actions (A+B)*C=D, the intermediate result could be the value obtained by adding A and B, and then multiplying that value by C to determine the final result of the series of actions. In at least some examples, the telemetry sequencer 120 invokes or inserts multiple series of actions to execute them in a parallel manner, as discussed elsewhere herein.

[0046] In operation 412, fixed coefficients are loaded. In at least some examples, the fixed coefficients are loaded by telemetry sequencer 120 into the telemetry sequence slots as operands of a series of actions. In some examples, the fixed coefficients are memory accesses and are one or more operands used to generate specific telemetry parameters in a specific format defined by a series of actions. In some examples, the fixed coefficients are previously received from the user by core 116 via the processor or other means configuring core 116 and then stored in memory by core 116.

[0047] In operation 414, dynamic coefficients are loaded. In at least some examples, the dynamic coefficients are loaded into the telemetry sequence time slot by the telemetry sequencer 120 as the computational object of a series of actions. In some examples, the dynamic coefficients are sensor data previously stored in operation 402 and / or preprocessed data previously stored in operation 408.

[0048] In operation 416, an operation that performs a series of actions is performed. For example, telemetry sequencer 120 performs an operation that performs a series of actions with the assistance of coprocessor 122. For example, telemetry sequencer 120 may send a pair of operands and an identifier of the operation to be performed to coprocessor 122 for processing. In at least some examples, the pair of operands and the identifier of the operation to be performed are selected based on the telemetry sequence slots using a first-in, first-out (FIFO) method. In various examples, the operation may be an arithmetic operation, such as multiplication, division, addition, or subtraction. In other examples, the operation may be any suitable operation used to change, process (e.g., average, filter, etc.) or otherwise manipulate fixed and / or dynamic coefficients to produce telemetry data defined by a series of actions.

[0049] In operation 418, it is determined whether all operations in a series of actions have been executed. If none of the operations in the series of actions have been executed, the method proceeds to operation 420. In operation 420, it is determined whether the insertion point follows the last executed operation. If the insertion point follows the last executed operation, the method proceeds to operation 422. In operation 422, the output value or result (e.g., intermediate output value) of the last executed operation is stored. For example, the telemetry sequencer 120 stores the output value of the last executed operation in a storage location for later output to a user, output to another electronic component, or as an operand in another series of actions to generate telemetry data. Now returning to operation 420, if the insertion point does not follow the previously executed operation, the method returns to operation 418. Now returning to operation 418, if all operations in the series of actions have been executed, the method proceeds to operation 424. In operation 424, the output value (e.g., final output value) of the series of actions is stored. The output value of the series of actions is, for example, the output value or result of the previously executed operation. In at least one example, the telemetry sequencer 120 stores the output values ​​of a series of actions in a storage location for later output to a user, output to another electronic component, or as an operand in another series of actions to generate telemetry data.

[0050] In at least some examples, method 400 is executed for each telemetry parameter generated by the system implementing method 400 (such as telemetry system 112). For example, a new instance of method 400 is implemented in telemetry system 112 for each telemetry sequence slot of telemetry system 112 (e.g., as mentioned above regarding...). Figure 2 (As shown).

[0051] While the operations of method 400 have been discussed and labeled with numerical references, in various examples, method 400 includes additional operations not listed herein. In some examples, any one or more of the operations described herein include one or more sub-operations (e.g., intermediate comparisons, logical operations, output selection via multiplexer, format conversion, etc.). In some examples, any one or more of the operations described herein are omitted. In some examples, any one or more of the operations described herein are performed in a different order than presented herein (e.g., in reverse order, substantially simultaneously, overlapping, etc.). Each of these alternatives is intended to fall within the scope of this disclosure.

[0052] In the foregoing discussion, the terms “comprising” and “including” are used in an open-ended manner and should therefore be interpreted as meaning “including, but not limited to…”. The term “coupled” is used throughout the specification. This term can encompass connection, communication, or signal paths that achieve a functional relationship consistent with the description of this disclosure. For example, if device A generates a signal to control device B to perform an action, in a first example, device A is coupled to device B, or in a second example, device A is coupled to device B via an intervening component C, where the intervening component C substantially does not alter the functional relationship between device A and device B, such that device B is controlled by device A via a control signal generated by device A. Devices “configured” to perform a task or function may be configured (e.g., programmed and / or hardwired) at the time of manufacture to perform that function and / or may be configured (or reconfigurable) by the user after manufacture to perform that function and / or other additional or alternative functions. Configuration can be achieved through firmware and / or software programming of the device, through the construction and / or layout of hardware components and the interconnection of the devices, or combinations thereof. Furthermore, it is said that circuitry or devices including certain components may alternatively be configured to be coupled to those components to form the described circuitry or device. For example, a structure described as including one or more semiconductor elements (such as transistors), one or more passive elements (such as resistors, capacitors and / or inductors) and / or one or more sources (such as voltage and / or current sources) may alternatively include only semiconductor elements within a single physical device (e.g., a semiconductor die and / or integrated circuit (IC) package) and may be configured to be coupled to at least some of the passive elements and / or sources to be formed by an end user and / or a third party during or after manufacturing.

[0053] Although certain components are described herein as having a specific process technology, these components can be replaced with components of other process technologies that achieve equivalent functionality as described herein. The circuits described herein can be at least partially reconfigured to include the replaced components to provide the desired functionality, at least partially similar to the functionality available prior to the component replacement. Unless otherwise stated, components illustrated as resistors generally represent any one or more elements coupled in series and / or parallel to provide the impedance represented by the illustrated resistor. Furthermore, the use of the phrase "ground voltage potential" in the foregoing discussion is intended to include chassis ground, ground, floating ground, virtual ground, digital ground, common ground, and / or any other form of grounding suitable for or applicable to the teachings of this disclosure. Unless otherwise stated, "about," "approximately," or "substantially" preceding a value means + / - 10% of the value.

[0054] The foregoing discussion is intended to illustrate the principles and various examples of this disclosure. Once the foregoing disclosure is fully understood, many variations and modifications will become apparent to those skilled in the art. This disclosure is intended to be construed as encompassing all such variations and modifications.

Claims

1. A circuit comprising: Storage element; Coprocessor; and A telemetry sequencer, coupled to the storage element and the coprocessor, and configured to implement a digital state machine to: Receive configuration information indicating the type of telemetry data generated; Retrieve from the storage element operations and operands associated with the type of telemetry data used to generate the telemetry data, wherein the operations and operands define a series of sequential actions to be performed to generate the telemetry data; By passing at least some of the operations and at least some of the operands to the coprocessor for processing by the coprocessor, the coprocessor is driven by the operations and operands associated with the type of the telemetry data to be generated; The intermediate output of the series of actions that receive and store the telemetry data in a first format from the coprocessor; and The final output of the series of actions that receive and store the telemetry data as a second format from the coprocessor.

2. The circuit of claim 1, wherein the telemetry sequencer drives the coprocessor to perform a plurality of telemetry sequence slots, each telemetry sequence slot representing a processing slot, during which the telemetry sequencer generates a type of telemetry data in at least one format based at least in part on data received from the coprocessor.

3. The circuit of claim 2, wherein the telemetry sequencer drives the coprocessor with the operation and the operand according to parallel processing, wherein the operation and the operand are passed to the coprocessor one telemetry sequence time slot before the coprocessor executes the telemetry sequence time slot of the series of actions defined by the operation and the operand.

4. The circuit according to claim 1, wherein the telemetry sequencer is further configured to: The operation receives the series of actions, the operation, at least some of the operands, and the operation that subsequently obtains the intermediate output of the series of actions from the central processing unit; and The storage element stores the series of actions, the operation, at least some of the operands, and the operation of obtaining the intermediate output of the series of actions thereafter.

5. The circuit according to claim 1, wherein at least one of the operational objects is a digital signal output of an analog-to-digital converter, wherein the digital signal output indicates the state of the circuit.

6. The circuit according to claim 5, wherein the circuit is a multiphase power supply.

7. The circuit according to claim 1, wherein the telemetry sequencer is further configured to: Receive second configuration information indicating the type of the second telemetry data to be generated; Retrieve from the storage element a second operation and a second operand associated with the type of second telemetry data to be generated, wherein the second operation and the second operand define a second series of actions performed by the coprocessor to generate the type of second telemetry data; While the telemetry sequencer is performing the series of actions, the program controls the second operation and the second operand associated with the type of the second telemetry data to be generated to enter the telemetry sequence time slot for execution after the telemetry sequencer has performed the series of actions. By passing at least some of the operations in the second operation and at least some of the operands in the second operand to the coprocessor for processing by the coprocessor, the coprocessor is driven by the second operations and the second operands associated with the type of the second telemetry data to be generated; and The final output of the second series of actions, which is received from and stored as the second telemetry data from the coprocessor.

8. A system comprising: Multiphase power supply; Central processing unit; and The telemetry system, coupled to the multiphase power supply and the central processing unit, is configured to implement a digital state machine to: Receive sensor data in digital format that indicates the status of the system; By loading multiple operations and multiple computational objects, and when the sensor data is used as one of the computational objects, the multiple operations and the multiple computational objects together define a series of actions for determining telemetry data; Perform the series of actions to produce a final output as the result of the final operation of the series of actions; and The final output is stored as the telemetry data in a first format. The system is configured to modify the value of the signal output by the multiphase power supply based at least in part on the final output produced.

9. The system of claim 8, wherein the telemetry system is further configured to store the intermediate output as telemetry data in a second format, and wherein the intermediate output is the result of an operation of the series of actions, the operation being not the final operation of the series of actions.

10. The system of claim 9, wherein the telemetry system is further configured to: Loading a second series of actions for determining second telemetry data, wherein the second series of actions is defined according to a plurality of second operations and a plurality of second operands, and wherein loading the second series of actions includes: Load the plurality of second operations; and Load the plurality of second operation objects, wherein at least one of the second operation objects is the telemetry data in the first format or the telemetry data in the second format; Perform the second series of actions to produce a final second output as the result of the last operation of the second series of actions; and The final second output is stored as the second telemetry data.

11. The system of claim 8, wherein the telemetry system is further configured to: Receive sensor data in analog format, representing measured values ​​indicating the condition of the system; The sensor data in analog format is converted into sensor data in digital format via an analog-to-digital converter; and The sensor data in the digital format is stored in a memory.

12. The system of claim 8, wherein the telemetry system is further configured to receive configuration information from the central processing unit, and wherein the configuration information indicates: The series of actions; The aforementioned multiple operations; At least some of the plurality of operands; and The intermediate output is used when an intermediate output is required after the operation of the plurality of operations.

13. The system of claim 8, wherein the telemetry system is further configured to load operations and computation objects associated with the second series of actions when performing the series of actions.

14. A method implemented by a digital state machine, comprising: Receives sensor data in digital format indicating the status of the circuit; Loading a series of actions for determining telemetry data when the sensor data is used as a computational object, wherein the series of actions is defined according to multiple operations and multiple computational objects, and wherein loading the series of actions includes: The multiple operations are loaded into telemetry sequence slots for coprocessor computation; and The plurality of computational objects are loaded into the telemetry sequence time slots for computation by the coprocessor; Executing the series of actions to produce a final output as the result of the final operation of the series of actions, wherein executing the series of actions includes passing at least some of the plurality of operations and at least some of the plurality of operands to the coprocessor for processing by the coprocessor; and The final output is stored as the telemetry data in a first format.

15. The method of claim 14, further comprising storing the telemetry data in a second format as an intermediate output, wherein the intermediate output is the result of an operation of the series of actions, the operation being not the final operation of the series of actions.

16. The method of claim 15, further comprising: Loading a second series of actions for determining second telemetry data, wherein the second series of actions is defined according to a plurality of second operations and a plurality of second operands, and wherein loading the second series of actions includes: The plurality of second operations are loaded into another telemetry sequence slot for computation by the coprocessor; and The plurality of second computation objects are loaded into the other telemetry sequence time slot for computation by the coprocessor, wherein at least one of the second computation objects is the telemetry data in the first format or the telemetry data in the second format; Perform the second series of actions to produce a final second output as the result of the last operation in the second series of actions; and The final second output is stored as the second telemetry data.

17. The method of claim 14, further comprising: Receive sensor data in analog format, which indicates the condition of the circuit. The sensor data in analog format is converted into the sensor data in digital format via an analog-to-digital converter; and The sensor data in the digital format is stored in a memory.

18. The method of claim 17, further comprising controlling the coprocessor to preprocess the sensor data before storing the sensor data.

19. The method of claim 14, further comprising receiving configuration information from a central processing unit, wherein the configuration information indicates: The series of actions; The aforementioned multiple operations; At least some of the plurality of operands; and The intermediate output is used when an intermediate output is required after the operation of the plurality of operations.

20. The method of claim 14, further comprising loading operations and computation objects associated with the second series of actions when performing the series of actions.

21. The method of claim 14, wherein the circuit is a multiphase power supply for a server system, and wherein the method further comprises modifying the value of an output signal of the multiphase power supply at least in part based on a determined final output.

22. The method of claim 14, wherein the telemetry sequencer loads a plurality of series of actions into a plurality of telemetry sequence slots, each telemetry sequence slot containing a series of actions, and wherein the telemetry sequence slots are dynamically reconfigurable to change their sequence of actions.

23. The method of claim 14, wherein the number of the plurality of operations, at least some of the plurality of operands, or the data type of at least some of the plurality of operations are variable between performing the series of actions and performing another series of actions.

24. The method of claim 14, wherein the first format is independent of the hardware component that generates the final output.

Images