Patent ID: 12200139

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

Embodiments are described herein according to the following outline:1.0. Overview2.0. System Overview3.0. Functional Overview4.0. Example Embodiments5.0. Extensions and Alternatives

1.0. OVERVIEW

Approaches, techniques, and mechanisms are disclosed for manufacturing and operation of the electronic systems discussed herein including digital currency mining systems optimized for power, performance and integrated circuit surface area. The electronic systems can improve performance and enable independent operation of different components of the system.

According to one embodiment, the system can include a circuit simulation system for simulating a first test circuit for determining an effective hash rate of the first test circuit and comparing the effective hash rate of a second test circuit.

According to one embodiment, the first test circuit can be configured as a SHA-256 hash engine having at least one expander and at least one compressor for calculating a hash digest of a message.

According to another embodiment, the system can include a circuit database coupled to the control module, the circuit simulation system, and the summary module.

In other aspects, the inventive subject matter encompasses electronic systems configured to carry out the foregoing techniques.

2.0. SYSTEM OVERVIEW

FIG.1illustrates an example embodiment of an electronic system100. The electronic system100, such as a digital currency mining system, can calculate values used for generating blocks120of data used to represent elements of a digital ledger, such as used in a blockchain configuration.

The electronic system100can have a variety of configurations. In an embodiment, electronic system100can include one or more cryptographic engines102, a controller104, storage devices106, memory devices108, input-output devices110, and network devices112.

The cryptographic engines102can be used to calculate cryptographic values to represent aspects of the digital ledger including blocks, block headers, hash values, and other similar values. The cryptographic engines102can have different hardware and software configurations. For example, the cryptographic engines102can be include dedicated hardware devices including portions of application specific integrated circuits (ASIC), field programmable gate arrays (FPGA), custom circuitry, cryptographic accelerators, processors, or other computing devices.

In some embodiments, the cryptographic engines102can be dedicated ASIC devices that have been optimized for power, performance, and surface area. In other embodiments, where the electronic system100is a digital currency mining system, the ASIC devices can be optimized to maximize other metrics, such as the effective hash rate. The cryptographic engines102can also be optimized for effective hash rate which can be related to the overall performance metric. The cryptographic engine102optimized for the maximum effective hash rate can be a proxy value for the other metrics for power, performance, and surface area.

In some embodiments, the controller104can be a computer processor for controlling the electronic system100. In yet other embodiments, the controller104can include dedicated electronic circuitry for controlling the other elements of the electronic system100. The controller104can be a CPU, microcontroller, state machine, multi-processor, or other similar device.

The controller104can be coupled to the storage devices106, the memory devices108, the IO devices110, and the network devices112. The storage devices106, such as disk drives, solid state drives, flash memory, or other bulk data storage devices, can be used to store information and data used and generated by the system.

The memory devices108are coupled to the controller104and provide active memory devices such as random-access memory that is used for regular operation of the system. The IO devices110can be used to communicate with other components and can include keyboards, mice, monitors, and other similar devices. The network devices112can provide communication links to other systems. The network devices112can include ethernet devices, optical communication devices, and other similar communication devices used to form network connections with other systems.

In some embodiments, the electronic system100can be used to calculate one or more of the blocks120for the digital ledger. The digital ledger, such as a blockchain118, can record and be used to validate a series of transactions of the digital currency.

In yet other embodiments, the electronic system100can be a node on a Bitcoin network which is a peer-to-peer network of nodes that implement the Bitcoin protocol. The Bitcoin protocol facilitates a blockchain based public distributed ledger.

The nodes on the Bitcoin network are configured to be able to communicate with one or more other nodes. Users on the nodes can broadcast messages to the network including transaction messages describing changes to the ledger, such as the transfer of cryptocurrency to other users.

Each of the nodes has a local copy of the entire ledger. If one or more transactions are invalid, then the transaction can be ignored. The transactions can be validated only when the entire set of nodes in the network agree that they are valid.

FIG.2illustrates an example embodiment of the blockchain118. The blockchain118is a distributed data structure that can represent a digital ledger that can be distributed over a group of computer network nodes. Each of the blocks120can include one or more records that describe transactions performed on the digital currency represented by the blockchain118. Multiple copies of the digital ledger are distributed and stored on the nodes of the network to provide redundancy. This provides a decentralized record of transactions that cannot be altered without being detected simply by comparing one of the blocks120on one of the nodes to the equivalent one of the blocks120on a different one of the nodes.

The blockchain118includes a group of the blocks120that are serially linked to one another. In some embodiments, each of the blocks120includes block header122that includes a pointer to a previous one of the blocks120to define the set and order of the blocks120making up the blockchain118.

The blocks120can have a variety of data structures. In one embodiment, each of the blocks120can include data fields including a block size210, the block header122, a transaction counter214, and a set of transactions216.

In some embodiments, the block size210can be four bytes long and can define the size of the block in bytes. The transaction counter214can range between one and nine bytes and indicates the number of transactions216in the block120. The transaction216are a variable sized field and includes the details of the transactions216recorded in the block120.

The blocks120in blockchain118can include entries about the transactions216in the block120. The transactions216can include a version number, a flag field, an input counter, an output counter, a set of inputs, a set of outputs, witnesses, and a lock time.

The block header122can include a variety of metadata or different data elements used to manage blockchain118. In some embodiments, the block header122can include information such as a timestamp220, a previous block hash230, a version222, a Merkle root224, a difficulty target226, and a nonce228.

In one embodiment, the block header122can be sized at 80 bytes. This can include four bytes for the version222, thirty-two bytes for the previous block hash230, thirty-two bytes for the Merkle root224, four bytes for the timestamp220, four bytes for the difficulty target226, and four bytes for the nonce228.

The timestamp220in the block header122is a time of block generation indicating the number of milliseconds since the block was mined. The time is specified as the number of milliseconds since the beginning of the Unix epoch. Valid new blocks must have a timestamp that is within 140 milliseconds of the actual time.

The Merkle root224in the block header122is a representation of a hashed data structure to show data verification and integrity for the transactions216in the block. The Merkle root224is a cryptographic value resulting on calculating a hash value on each node of a Merkle tree representing all of the transactions216of one of the blocks120.

The version222in the block header122describes the blockchain version of one of the blocks120. The version222can be one of several types including version 1.0 for cryptocurrency, version 2.0 for smart contracts, version 3 for decentralized structure, and version 4.0 for industrial applications.

The difficulty target226is a value indicating the complexity and the computational power required to mine the network and find new blocks. It represents a threshold value that can be compared to an intermediate hash value to determine. The difficulty target226can also be known as the bits field.

The nonce228is a number used to validate the information within the block120by calculating a hash value of the block header122used to validate the block120. The hash value is validated if the value is less than another one of the hash value of the block120.

In some embodiments, additional information can be associated with the blocks120and the block header122. These values can include a height232, a genesis block234, and a block hash236or block header hash238.

The height232, or block height, value can indicate how many blocks are before the current block. Height can be derived from the number of layers of blocks if they were all stacked on top of one another.

The genesis block234is the first block in the blockchain118. The genesis block234is a known and fixed block and represent a starting value for the previous block hash230of the block120.

The block hash236, or the block header hash, is a cryptographic value calculated by performing a hashing operation on the block header122. The block hash236can act as a primary identifier of the block120. In some embodiments, the block hash236can be calculated by performing the SHA-256 hashing operation on the block header122twice. This can be designated a double SHA-256 hash operation. The output of the first SHA-256 hashing operation is the input for the second SHA-256 operation to calculate the final double SHA-256 hash result.

The block hash236is a unique value because it calculates the hash value on the block header122including the updated values of the nonce228, the Merkle root224, and the previous block hash230. In some embodiments, the block hash236can be a block header hash238which is the hash of just the block header122. The block hash236can also be known as a message hash, message header hash value, hash digest, digest, or a combination thereof. The blocks can also be configured with a padding value240.

FIG.3illustrates an example embodiment of a cryptographic hash process302. The cryptographic hash process302can be a SHA-256 hash process.

The Secure Hash Algorithm256(SHA-256) is a set of cryptographic hash functions for mapping a message304of arbitrary size to a hash value311which can be a fixed size value, such as a hash, hash value, hash code, or a hash digest312. The message304can be an arbitrary set of data such as a block of data, a block header, or other similar set of data.

The SHA-256 hash process can divide the message304into multiple chunks320of sixty-four bytes each and process the chunks320serially to generate a final version of the hash digest312. The chunks320are formatted and passed through an expander306to generate a message schedule310of sixty-four words of thirty-two bits each. The expander306, such as an expander circuit, an expander module, or an expander function, can receive one of the chunks320of 512 bits or sixteen thirty-two-bit words and generate an expander output of sixty-four thirty-two-bit words. The expander306can make it harder for cryptographic attackers to control the position of bits in the output.

The output of the expander306, the message schedule310, can be passed to a compressor308. The compressor308can compress the output of the expander into a 256-bit hash value for the hash digest312.

FIG.4illustrates an example embodiment of a digital currency mining process402. The digital currency mining process402can maintain the public ledger or the blockchain118by verifying transactions405stored in the blockchain118.

The digital currency mining process402, such as the bitcoin mining process, can calculate a block header hash value and update the nonce228of the block header122that is used to calculate the block hash236for the current one of the blocks120containing the current value of the nonce228.

The digital currency mining process402can perform a double SHA-256 operation on the block header122to determine a block header hash that is less than or equal to the difficulty target226.

The hash digest428is calculated by calculating the nonce228for one of the blocks120that results in the hash420having a value lower than the difficulty target226.

In some embodiments of the digital currency mining process402, the first hash module410, such as a SHA-256 hash module, can receive a first portion407of the block header122to calculate a first intermediate hash422of the first portion407of the block header122. For example, the first portion407can be a 512-bit segment of the block header122. The first portion407can be received by a first expander440and the result passed to the first compressor450. The first compressor450can also receive a constant value. This produces a first intermediate hash422of the first portion407of the block header122which can be passed to the second hash module412.

The second hash module412can receive a second portion409of the block header122, such as the second 512 bits of the block header122including an initial value of the nonce228, in a second expander442. The second expander442can expand the inputs and pass the result to a second compressor452. The output of the second compressor452is a second intermediate hash424which can represent a 1024-bit hash of the block header122. The second intermediate hash424can be passed to a third hash module414.

The third hash module414can receive the second intermediate hash424and a padding value429in a third expander444. A third compressor454can then receive the output of the third expander444and a constant value and can then calculate the block header426. For example, the block header426can be compressed to a 512-bit hash value.

A comparison module416can compare the block header426to the difficulty target226. If the block header426is less than or equal to that difficulty target226, then the block120is successfully created and the validation is complete. If the block header426is not below the difficulty target226, then an increment nonce module430can increment the nonce228and the validation process can be cycled again.

FIG.5illustrates an example embodiment of a hashing unit502. The hashing unit502is a computing device for calculating hash values506for a set of chunks of data.

The hashing unit502can calculate one or more hash values for a set of data. In some embodiments, the hashing unit502can calculate a SHA-256 hash, a SHA-512 hash, a MD5 hash, or other similar hash values.

In an embodiment, the hashing unit502can include two or more hash engines504. In one embodiment, the electronic system100can include up to 254 of the hash engines504. Each of the hash engines can create a hash digest for each record and block. The hash engine can receive portions, or chunks, of data that can be mathematically converted to a hash digest.

In some embodiments, the hashing unit502can be configured to include four unrolled double SHA-256 implementation of the hashing unit502. This can allow a common expander542to be shared in common with the other four of the hash engines504.

The hashing unit502can include a built-in self-test multiplexer518(BIST multiplexer518) that can receive a BIST signal517for controlling the multiplexer. The BIST multiplexer518can receive two sets of input including a linear-feedback shift register512(LFSR512) and a nonce input515. The LFSR512can be the input received from a shift register whose input is a linear function of the previous state. The nonce input515can be calculated by combining an engine number514and the output of a nonce counter516. The output of the BIST multiplexer518can be the updated value of the nonce228.

The hashing unit502can include a first hash core528and a second hash core538. The first hash core528can be configured with a common expander542that passes the expander output to four individual compressors.

The common expander542can pass the message schedule using a message formed from the nonce228, the Merkle root224, the difficulty target226, and the timestamp220. The common midstate543can be used by the other components, including a first compressor544, a second compressor546, a third compressor548, and a fourth compressor550.

The first hash core528can be configured to use the common expander542that is shared with four of the compressors.

In the second hash core538, each compressor can be configured with a separate expander, such as a fifth expander552coupled to a fifth compressor554, a sixth expander556.

The hash digest coupled to a sixth compressor558, a seventh expander560coupled to a seventh compressor562, and an eighth expander564coupled to an eighth compressor566.

Each of the compressors can receive a separate midstate, such as a midstate 0, midstate 1, midstate 2, and midstate 3. Each of the hash cores can be configured to iterate only the nonce. The lower eight bits of the nonce will be a constant for each core and equal to a core identification number.

The system can use a midstate value to hold intermediate results. For example, the midstate value can include a zeroth midstate520, a first midstate522, a second midstate524, and a third midstate526.

The H3I value is a chaining value used when a hash value is calculated piecemeal, such as H3I chain value 0530, H3I chain value 1532, H3I chain value 2534, and H3I chain value 3536. The midstate value and the H3I values can be provided to the compressor units in the first stage536of the hashing unit502.

The hashing unit502can include a second BIST multiplexer570that can be controlled by the BIST signal517. The second BIST multiplexer570can have two inputs including the nonce228as received from the first BIST multiplexer518and the output of the LFSR512.

The hash digests from the compressors of the second hash cores can be passed to a comparison module574to compare the hash digest to the difficulty target226. If the hash digest is lower than the difficulty target226, then the result can be sent to a buffer shift register572before being passed to a controller.

FIG.6illustrates an example embodiment of an expander unit602. The expander unit602is a circuit for receiving a message606and generating intermediate values for the compressor for calculating a hash value.

The expander unit602implements a Message Expander (ME) functionality. In some embodiments, the expander unit602can receive the message606, such as a 512-bit input message, and expand the message606into 64 chunks604of 32-bit data, such as an array with 64 entries. The chunks604are pieces of data generated from message606.

The expander unit602can include a shift register array652, a sigma block654, and an adder block656. The shift register array652can be a multi-stage shift register for linearizing the chunks of the message606.

In some embodiments, the expander unit602can include a multiplexer unit642which can receive the message606and an output from the adder block656and send the portions of the message606to the multi-stage shift register array652.

The chunks604of the message606can be passed to the multi-stage shift register array having a register610, a register612, a register614, a register616, a register618, a register620, a register622, a register624, a register626, a register628, a register630, a register632, a register634, a register636, a register638, and a register640. The expander unit602can generate a message schedule660having the64of the chunks604of data in a specified order. The registers can be used to hold different chunks604of the message schedule660.

The sigma block654can include one or more sigma function units, such as a first sigma unit643and a second sigma unit644. The sigma block654can calculate intermediate values that can be passed to the adder block656. For example, the first sigma unit643can receive the output of the register612and pass the result to a first carry-save adder646of the adder block656. The second sigma unit644can receive the output of register636and pass the result to a second carry-save adder648(second CSA648) of the adder block656. Other configurations can be used to optimize performance and reduce power requirements.

The adder block656can be implemented in a variety of ways. In one embodiment, the adder block656can include the first carry-save adder646, the second CSA648, and a carry-propagate adder650. However, the adder block656can be configured with other combination of adder types. The type of adders used can be varied to optimize the functionality of the adder block656. For example, the adder block656can be configured to minimize a critical path for data passing through the adder block656to reduce the amount of time and energy needed to perform the operations.

The expander unit602can be configured in a variety of ways. In some embodiments, the expander unit602and the components can be configured to increase effective hash rate, reduce power consumption, increase performance, or reduce the surface area of the electric circuit on the integrated circuit. Different components can be configured using different techniques to improve the overall effective hash rate of the ASIC.

In some embodiments, the expander unit602can be driven at a clock signal666at a clock frequency664. The clock signal666can be provided by a phased lock loop unit653(PLL653) that can vary the frequency as needed. The clock signal666can be coupled to the electrical components of the expander unit602to control the operation of the expander unit602.

In some embodiments, the configuration of the expander unit602can include an expander critical path668. An expander critical path668can be the route through the expander unit602with the lowest total delay which can be the sum of the individual delays670of each of the components in the expander critical path668.

Different configurations of the expander unit602can change the expander critical path668. This can be done by optimizing individual components, such as reducing the delay associated with a type of adder. In an example, the expander critical path668can be configured as the delays of each of the first sigma unit643, the first CSA646, the second CSA648, the CPA650, and the multiplexer unit642. The design of the expander unit602can be improved by reducing the amount of the delay670for any of the components.

FIG.7illustrates an example embodiment of a compressor unit702. The compressor unit702is a circuit for receiving the message schedule704and calculating a hash value.

The compressor unit702implements a Message Compressor (MC) functionality. The compressor unit702can receive a message schedule704from the expander unit602. For example, the message schedule704can be 74 chunks of 32-bit data generated using a message706.

The compressor unit702can include a register block770, a function block772, and an adder block774. The register block770can buffer data for calculating a hash digest764. In an example, the hash digest764can be calculated as the addition of A1, A2, B, C, D, E, F, G, and H.

The register block770can include multiple registers for temporarily buffering data. The registers can include a register A1710, a register A2712, a register B720, a register C726, a register D730, a register E734, a register F742, a register G750, and a register H756.

In some embodiments, function block772can include a variety of functional units. The function block772can include a first sum unit716, a majority unit722, a first multiplexer unit728, a second sum unit736, a choose unit744, and a second multiplexer unit758.

The first sum unit716can receive the output of the first CPA unit714. The first sum unit716can pass the output to the first CSA unit718of the adder block774.

The majority unit722can have three binary inputs and output a result bit that represents the majority value of the three inputs. In some embodiments, the majority unit722can receive inputs from the first CPA unit714, the register B720and the register C726. The output of the majority unit722can be passed to the second CSA unit724.

The first multiplexer unit728can receive inputs from the register C726and the register D730. The output of the first multiplexer unit728can pass the output to the seventh CSA unit760.

The second sum unit736can receive the output of the register E734. The result of the second sum unit736can be passed to a third CSA unit738and the fourth CSA unit740.

The choose unit744can receive inputs from the register F742and the register G750. The output of the choose unit744can be passed to the fifth CSA unit746and a sixth CSA unit748.

The second multiplexer unit758can receive inputs from the register G750and the register H756. The output of the second multiplexer unit758can be passed to the eighth CSA unit762.

The adder block774can add the results of various stages and feedback to the register block770. The adder block774can include a first CSA unit718, a second CSA unit724, the third CSA unit738, a fourth CSA unit740, a fifth CSA unit746, the sixth CSA unit748, a seventh CSA unit760, a second CPA unit732, a first register L752, and a second register L754.

The first CSA718can receive inputs from the first sum unit716, and two inputs from the second CSA724. The output of the first CSA718can be passed to the register A1710and the register A2712.

The second CSA unit724can receive inputs from the majority unit722and two inputs from the fourth CSA unit740. The two outputs of the second CSA unit724can be passed to the first CSA unit718.

The second CPA unit732can receive inputs from the third CSA unit738. The second CPA unit732can pass the results to the register E734.

The third CSA unit738can receive inputs from the second sum unit736and two inputs from the fifth CSA unit746. The two outputs of the third CSA unit738can be passed to the second CPA unit732.

The fourth CSA unit740can receive input from the second sum unit736and two inputs from the sixth CSA unit748. The two outputs of the fourth CSA unit740can be passed to the second CSA unit724.

The fifth CSA unit746can receive inputs from the choose unit744and two inputs from the first register L752. The output of the fifth CSA unit746can be passed to the third CSA unit738.

The sixth CSA unit748ca receive input from the choose unit744and two inputs from the eighth CSA unit762. The output of the sixth CSA unit748can be passed to the fourth CSA unit740.

The first register L752can receive two inputs from the seventh CSA unit760. The outputs from the first register L752can be passed to the fifth CSA746.

The second register L754can receive two inputs from the eighth CSA unit762. The output of the second register L754can be passed to the sixth CSA unit748.

The seventh CSA unit760can receive inputs from the first multiplexer unit728and two inputs from the eighth CSA unit762. The output of the seventh CSA unit760can be passed to the first register L752.

The eighth CSA unit762can receive inputs including a hashing constant765(Kj), a register variable766(Wej) and the message schedule704from the expander unit602. The output of the eighth CSA unit762can be passed to the seventh CSA unit760.

The compressor unit702can be formed in a variety of ways. The example register block770, function block772, and the adder block774can be configured in different ways. The configuration can include combinations of carry-save adders, full-adders, carry 0 propogate adders, ripple-carry adders, carry-lookahead adders, or other types of adder circuitry. Each type of adder can be configured to have different optimization factors including power, performance, surface area, and effective hash rate. Further the adders within the adder block774can have different connections to accommodate the data flow as needed.

In some embodiments, the compressor unit702can be driven at the clock signal666at the clock frequency664. The clock signal666can be provided by the phased lock loop unit653that can vary the frequency as needed. The clock signal666can be coupled to the electrical components of the compressor unit702to control the operation of the compressor702.

Each of the components of the compressor702can have a delay782associated with normal operation. The delay782can be expressed as the number of clock cycles required to generate an output based on the inputs.

In some embodiments, the configuration of the compressor unit702can include a compressor critical path780. The compressor critical path780can be the route through the compressor unit702with the lowest total delay which can be the sum of the individual delays782of each of the components in the compressor critical path780.

Different configurations of the compressor702can change the compressor critical path780. This can be done by optimizing individual components, such as reducing the delay associated with a type of adder. In an example, the compressor critical path780can be configured as the delays of each of the CSA762, the second register L574, the sixth CSA748, the fourth CSA740, the second CSA724, and the first CSA718. The design of the compressor unit702can be improved by reducing the amount of the delay782for any of the components. In addition to the expander critical path668and the compressor critical path780, there is a hash engine critical path784which can represent the critical path through both the expander unit602and the compressor unit702.

In other embodiments, the compressor unit702can be configured to operate at different voltage levels. The components of the compressor unit702can be coupled to a common power source or can be powered on a group basis to provide different power levels to different components or sets of components. Configuring the compressor unit702to use different power levels can reduce the power consumption of the circuit. Similarly, the compressor unit702can be configured to use different power levels at different clock frequencies.

FIG.8illustrates an example embodiment of an application specific integrated circuit chip802(ASIC802). The ASIC802can be used to implement one or more of the hash engines. The ASIC802can have conductive pins to provide input and output signals as well as other pins for power and ground busses.

The ASIC802is an application specific integrated circuit designed to function as a set of high-performance hash engines. It can include internal circuitry customized to perform a variety of function such as cryptographic functions, logic function, arithmetic function, and other related functions.

The ASIC802can have a variety of configurations related to power and power distribution. In an embodiment, the ASIC802can have a source voltage trace804, such as VDD_DLV, and a ground trace806, such as VSS.

In some configurations, the ASIC802can have a set of identification pins to uniquely identify and address the hash engines of the ASIC802. This can include ID [0]810, ID [1]812, ID [2]814, and ID [3]816. The ASIC802can have other identification pins including ID [7]842, ID [6]844, ID [5]846, and ID [4]848.

The ASIC802can have additional power and ground pins including a VSS1 pin818, a VSS_IO pin824, a VSS2 pin850, a VDD_SCV pin820.

The ASIC802can have a test pin820, such as test_mode_i. The ASIC802can have a thermal trip reset output pin854, such as thermal_trip_o_reset_n_i and a thermal trip reset input pin854, such as thermal_trip_i_reset_n_o. The ASIC802can have a VDD_IO pin824.

The ASIC802can have response pins including a response input command output pin826, such as response_i_command_o and a response output command input pin858, such as response_o_command_i. The response pins can transfer response information from the ASIC802.

The ASIC802can have clock pins including a clock input output pin828, such as clock_i_o and a clock output input pin860, such as clock_o_i. The clock pins can be used to propagate clock signals.

The ASIC802can have command pins including a command input response output pin832, such as command_i_response_o and a command output response input pin864, such as command_o_response_i. The command pins can be used to propagate command signals.

The ASIC802can have other power pins such as a VDD_IO pin830, a VDD_IO pin836. The ASIC802can have a VDD_SCV pin838. The ASIC802can have a VDD_IO pin840.

The ASIC802can have other test pins. For example, the ASIC802can have a test clockout output pin852.

The ASIC802can have thermal trip related pins including a thermal trip output reset pin854, such as thermal_trip_o_reset_n_i. The ASIC802can have a reset thermal trip output pin834, such as reset_n_i_thermal_trip_o, and a reset thermal trip input pin866, such as reset_n_o_thermal_trip_i.

The ASIC802can have a response output command input pin858, such as response_o_command_i. The ASIC802can have a command output response input pin864, such as command_o_response_i.

The ASIC802can have power pins including a VDD_IO pin856and a VDD_IO pin862. The ASIC802can have a VDD_IO pin868. The ASIC802can have a VDD_SCV pin870. The ASIC802can have a VDD_IO pin872.

The pinout of the ASIC802shows how the internal circuitry can receive and distribute power and communication signals. The ASIC802can be combined with another of the ASIC802to form a multi-unit configuration with each of the ASIC802communicating with other similar chips.

The ASIC802can be configured to operate together with another of the ASIC802chips in a variety of ways. The ASIC802can operate in an array configuration, in a daisy-chain configuration, or a combination thereof.

FIG.9illustrates an example embodiment of a circuit simulation system902. The circuit simulation system902can receive one or more test circuits924defined in input files920and simulate the operation of the circuits to determine the operational parameters of the circuit including power, performance, and required surface area of a circuit layout910.

The circuit simulation system902can be used to evaluate the test circuit924to determine if that design and performance of the test circuit924is better than other designs. The circuit simulation system902can simulate the operation of the test circuit924to monitor the behavior of the test circuit924. This can include determining an effective hash rate962which can show the number of validated blocks and transactions processed in terms of the number of hashes calculated per second.

The circuit simulation system902can have a variety of configurations. In some embodiments, the circuit simulation system902can include automation components that can retrieve different circuits, generate different circuits, simulate the circuits, and evaluate the circuits. In other embodiments, the circuit simulation system902can have other configurations including standalone systems, manual systems, or other similar systems.

In various embodiments, the circuit simulation system902can include different components. The circuit simulation system902can include a control module904, a simulation engine906, and a summary module908.

The control module904can control the overall operation of the circuit simulation system902. This can include retrieving one or more of the input files920from a circuit database925, controlling test and data flow, and providing output. The circuit database925can store one or more of the input files920that define the configuration of the test circuit924. The input file920can include a file identifier926to uniquely identify the file in the circuit database925.

The input file920can be simulated using a vector input with a large number of test value inputs or points. The test data can be in a constrained range of values to focus on specific test conditions. The test values can be constrained in different ways. In one embodiment, the input data range can have a uniform random distribution. This allows coverage of a specific range when evaluating the performance of test circuit924. This can allow for testing of the longest data path through the test circuit924.

In another embodiment, test vector inputs940can be configured to test for a specific workload type and focus on known inputs. These test vector inputs can be varied and generated on an individual basis or generated programmatically as in a Monte Carlo analysis dataset. The test vector input940can be configured to be a random distribution of test data, specific data tailored to exercise specific portions of the test circuit924, or other similar test configurations.

In some embodiments, the control module904can include hardware, software, or a combination thereof. The control module904can include a user interface, data storage units, memory units, display unit, communication units, and other similar units.

The control module904can retrieve one or more of the input files920from the circuit database925. The circuit database925can be implemented in a variety of ways. The circuit database925can be a relational database, a non-relational database, a text file, a binary file, or a combination thereof.

The input file920, such as a component netlist file, is a textual representation of a circuit and can describe the components and connections between components that make up the test circuit924. In some embodiments, the input file920can include or be linked to operational directives used to drive the simulation of the circuit and generate an output file922having information about the electrical performance and status of the test circuit924during the simulation. The input file920and the simulation engines906can support the automatic swapping of modules, such as the circuit modules from the libraries.

The input file920can be linked to or can include data capture instrumentation directives for evaluating the test circuit924. The directives can include test scripts and parameter variations for evaluating the test circuit924. The test circuit924can include pipelines and multi-stage circuit. The output directives for the test circuit924can include capturing data for intermediate stages on the circuit.

In some embodiments, the simulation engine906can support analysis of heat threshold and hot spots on the test circuit924. This can include evaluation of the power infrastructure of the test circuit924, such as power and ground bus layouts, proximity analysis, and other similar items. This can be especially useful around critical modules such as the hash engines and related components.

In yet other embodiments, the input file920can support static and dynamic variations of different clock frequencies, different power ranges for different components, ranges of voltages for different components and modules, and the physical and electrical effects of vias and corners. Input file920and the simulation engine906can process enhanced cooling techniques including closed loop cooling subsystems and components.

The output file922is a textual report of the simulation of the test circuit924. The output file922can include data reporting the electrical conditions at points within the test circuit924. In some embodiments, the output file922can include complex information such as wave forms, physical area of models and sub-models, frequency, or other parameters.

The simulation engine906can mathematically model and simulate the execution of the test circuit924in the input file920. The simulation engine906can receive the input file920and simulate the circuit described in the file to generate the output file922using a variety of techniques.

In some embodiments, the simulation engine906can use a modified nodal analysis technique to solve electrical circuits for both static and dynamic conditions including performing AC analysis, DC analysis, DC transfer curve analysis, noise analysis, transfer function analysis, transient analysis, and other similar techniques.

The simulation engine906can have a variety of configurations. In some embodiments, the simulation engine906can include a computer running a simulation software package, such as SPCE2G6, SPCE3F4, WinSpice, or other similar programs. In other embodiments, the simulation engine906can be implemented using custom hardware including co-processors or other performance accelerators to increase performance.

In other embodiments, the simulation engine906can solve for the electrical properties of the circuits in the input file404using Kirchoff's current law, Kirchoff's voltage law, or both together. The circuit simulation system902can also solve for non-linear, time-domain configurations.

The simulation engine906can be configured to use a variety of circuit libraries. For example, the input file404can include components and other elements retrieved from the SPICE libraries. The input file404can include directives to include specific libraries including private and customized libraries. The data in the input file404can include standard or default component libraries as well third-party libraries. The libraries can include individual components, circuits, subcircuits, simple and complex circuit models, specialized device models, and other similar elements. In some embodiments, the libraries can include additional metrics such as performance, surface area, a circuit area934, thermal factors, power usage, or other similar metrics.

Using customized libraries instead of standard cell libraries can provide additional functionality. When standard cell libraries are used, the effective hash rate962cannot be measured because the cell delays and timing analysis in the simulation engine906is often done for the worst case or worst case with some scaling factors applied. Using customized libraries can allow the simulation engine906to better account for the dependence of the effective hash rate962on inputs and the current state of the circuit at any point in time as influenced by previous inputs.

The effective hash rate962of the test circuit924can be determined in a variety of ways. In some embodiments, the effective hash rate962can be determined using the simulation engine906for a given design and energy consumed for that hash rate by doing a binary search on a clock frequency958for which a design operates with an acceptable value of an error rate or tolerable number of errors, such as when an error rate950is less than an error threshold944. The error threshold944can be predefined or calculated dynamically. In some cases, the error threshold944within a statistical confidence interval is used. Different designs are presented in different sets of the input files920to the simulation engine906and the resulting power-performance-area (PPA) values or the effective hash rate962as measured by that flow are compared to choose the best design embodied in the input files920. For example, the circuit simulation system902can select one of the test circuits924from the circuit database925and a circuit power930and then perform a series of simulations of the test circuit924at different values of the clock frequency958. The different values of the clock frequency958used for simulation can be determined using a search, such as a binary search, over a range of the clock frequencies958, such as from a low clock threshold952to a high clock threshold954at intervals of a clock interval956. In other embodiments, the search can include other types of search including linear search, jump search, uniform binary search, exponential search, interpolation search, or other search techniques.

In other embodiments, the effective hash rate962can be calculated by using the simulation data of one or more of the hash engines as they process the test vector input940. One example of calculating the effective hash rate962is determining the individual hash rate for one hash value for one of the hash engines and multiply by the total number of hash engines in the ASIC.

Another example of calculating the effective hash rate962is to simulate a given number of the hash engines and calculate the effective hash rate962as an average of the total number of the individual hash rates being simulated and multiplying an average hash rate948by the total number of hash engines being simulated. The effective hash rate962can be calculated where the hit rate is the clock frequency divided by (2{circumflex over ( )}#difficulty bits) times the number of hash engines. If no errors are occurring, the circuit should produce hits at a rate of the effective hash rate962. When errors start happening, the hit rate observed would be less. The test circuit924is simulated for large numbers of cycles to calculate the effective hash rate962and while the voltage and frequency of operation are varied to observe the true hit rate and then calculate the error rate for each of the voltage frequency pairs. The error rate is the hit rate minus the observed hit rate.

In another embodiment, the test circuit924can be used to calculate the effective hash rate962under varying operating parameters. The operational power level and the operation clock frequency can be varied for one of the test circuits924being simulated to achieve the effective hash rate962where the error rate950is above the error threshold944. Even when the correct operation is less than 100%, the error rate950is low enough to calculate the hash values and still achieve the desired effective hash rate962by performing useful work even when accounting for outputs that are incorrect. A system capable of optimizing the test circuit design selection and configuration based on the effective hash rate962can determine the parameter values for the three components of PPA. For example, the control module904of the circuit simulation system902can retrieve one or more of the test circuits924from the circuit database925and simulation operation at different operational power levels and different clock frequencies958to determine which parameter combinations to achieve the desired effective hash rate962. The circuit simulations can be performed on one or more of the simulation engines906. The results the circuit simulations can be stored in a summary module908and the acceptable parameter configurations can be extracted by a parser909to generate a report of the parameter values that provide the desired value of the effective hash rate962.

The operating voltage and operating frequency can be varied in a variety of ways. The voltage and frequency can be varied based on a voltage schedule and a frequency schedule, based on permutations of a voltage range and an operating frequency range, based on predefined values and predefined variations of the values, or other similar methods. In some embodiments, there may be three known operating voltages and a range of operating frequencies that can be evaluated. In other embodiments, the test circuits can be configured to read the operational voltages and operational frequencies from a table stored in a database or text file. The predefined value pairs can be retrieve and used to test and evaluate the test circuits.

In some embodiments, the simulation of a hash engine can use an input file920defining the circuitry of the hash engine and a test vector input file940having different block headers929. The test vector input file940can have a data set including multiple values for the block headers929. The simulation run can process each of the test values in the test vector input file920while varying the clock frequency958and the operating voltage. At different test settings, the simulation run can detect errors in circuit operations. These errors can include checksum errors, data errors, timing errors, or other types of errors. During the simulation, the system can calculate the error rate950for a particular input file920operating at the clock frequency958and an operating voltage966.

The error rate950can be compared to the error threshold944, such as a predefined error threshold including a statistical confidence interval, absolute threshold, or other similar threshold techniques. If the error rate950of the simulated circuit is not within the error threshold944for a particular combination of the clock frequency958and the operating voltage966, then the test circuit924defined by the input file920can be flagged as not passing at the test criteria.

The error rate950can be calculated in a variety of ways. In some embodiments, the circuit represented by the input file920can include error registers964. For example, the input file920can include register circuit modules from standard or customized libraries. The error registers964can be used to monitor the number of errors in the system.

The circuit simulation system902can operate in parallel and run one or more instances of the simulation engine906at one time. Each of the simulation engines906instances can be run on parallel hardware, multiple instances of the software on a computer, or a combination thereof.

In some embodiments, the simulation engine906can simulate operation of portions of the test circuit924at different clock frequencies. The input file920can include system timing parameters and test parameters including the clock frequency958, the low clock threshold952, the high clock threshold954, the clock interval956, and a clock configuration file960. For example, the input file920can include directives to simulate a portion of the test circuit924between the low clock threshold952and at the high clock threshold954at intervals of the clock interval956.

In another embodiment, the input file920can includes directives to simulate the test circuit924at different clock frequencies ranging between the low clock threshold952and the high clock threshold954at frequencies separated by the clock interval956. The simulation engine906can simulate the test circuit924and measure and track at least some of the operational parameters at the different clock frequencies. This can include at least a circuit power930, the circuit performance level932, the effective hash rate962, and the error rate950. The performance of the system can be compared to a performance threshold942to determine if adequate performance has been achieved. A target effective hash rate963can be compared to the performance threshold942.

In yet other embodiments, the system can simulate one or more hash engines and calculate the effective hash rate962at a given set of clock frequencies958and the operating voltage966. The operating voltage966can be varied between a low operating voltage and a high operating voltage or against a power threshold941. The power threshold941can be represented by a power level range, an upper power range, a lower power range, or other power ranges. The variations of the power range can include variations in the operating voltage and the operating current.

The operational parameters can be written to the output file922to monitor results. The output file922can be a text file created and updated by the simulation engine906. The individual parameters records can be formed using data logging directives in the input file920.

In some embodiments, the test circuit924can include a clock subsystem that can be a configurable frequency clock, such as a clock implemented using a phase locked loop (PLL) circuit. The PLL circuit can be configured to operate at a pre-defined frequency, dynamically updated frequencies, or a combination thereof. The configuration information for the PLL can be stored in a PLL configuration data928. The PLL configuration data928can be implemented as a file, data structure, registers, or other data storage structure. The PLL can be implemented in hardware or as a simulated unit in a circuit simulation system. The PLL can be modulated by changing the registry value used for configuration.

The summary module908can process the output file922of the simulation engine906to extract specific data and process results. The summary module908can be configured in a variety of ways. For example, the summary module908can include the parser module909can be configured for extracting data from the simulation engine906. The parser module909can extract data from the SPICE output file. This can be done with regular expressions, text extraction, pattern matching, or other similar techniques. The SPICE runs can be instrumented to periodically read the voltage values of different nodes in the circuit, such as the latch output nodes, convert the values to binary digital (0/1) value (v>v_ih for 1, v<v_i1 for 0) and transfer those values into a text or binary file. The parser module can then read the values and compares them to the output from a C/C++ model.

The circuit simulation system902can be configurated in a variety of ways. In some embodiments, the circuit simulation system902can be a standalone system, an automated system, or a combination thereof.

In an automated configuration, the circuit simulation system902can retrieve a set of the input files920from the circuit database925, simulate the test circuit924described in the input files920, extract the performance metrics, including the effective hash rate962, and identify the file identifier926of the input file920with the highest performance metrics, such as the effective hash rate962.

The circuit simulation system902can use a variety of customized and calculated embodiments of the test circuit924and test the test circuits924against different combinations of the circuit power930, clock frequency958, and circuit area934.

In some embodiments, the input file920can include a circuit design that can be known as a better-than-worst-case design that allows the test circuit924to reduce power requirements by optimizing for specific operating conditions rather than optimizing for the worst-case condition. One set of embodiments can include meta-information linked to the input file920than defined one or more operational voltage levels and one or more operational clock frequencies for operating the test circuit924.

In other embodiments, the simulation of the test circuit924at the different combinations of power, clock frequency, and circuit area can show improvements in a shorter time by performing multiple simultaneous simulations in the same time interval. The simulations can be performed by varying the test parameters to reflect live conditions to determine the proper parameters for operation in a variety of actual physical environments. The provides the ability to dynamically adjust operation of the circuits to maximize performance and minimize power.

3.0. FUNCTIONAL OVERVIEW

FIG.10illustrates an example of a manufacturing process flow1002for the electronic system100in an embodiment. The manufacturing process flow1002can describe the steps and process for manufacturing the electronic system100.

The manufacturing process flow1002can include a variety of operations. In an illustrative embodiment, the manufacturing process flow1002can include a retrieve first circuit step1004, a simulate first circuit step1006, a retrieve second circuit step1008, a simulate second circuit step1010, an identify preferred circuit step1012, and a formation step1014.

In the retrieve first circuit step1004, the circuit simulation system100can identify and retrieve a first input file920for a first test circuit1020from the circuit database925. The input file920for the first test circuit1020can include the netlist data for the components and connections of the first test circuit1020.

In some embodiments, a first input file1022of the first test circuit1020can include simulation and test directives for evaluating the first test circuit1020. The simulation and test directives can be configured as part of the first input file1022or linked to the first input file1022.

In the simulate first circuit step1006, the first input file1022can be processed by the simulation engines906. In some embodiments, the simulation engine906, such as a SPICE engine, can read and validate the first input file1022, simulate the first test circuit1020, and write the results into a first output file1034. A first effective hash rate1030can be determined for the first test circuit1020.

In another embodiment, the first effective hash rate1030can be calculated in a variety of ways. In one embodiment, the first effective hash rate1030can be calculated by retrieving hit information from registers in the first test circuit1020. The first test circuit1020can include several registers including a general hit count register with the number of preliminary hits from all unmasked engine, a general true hit count register with the number of actual hits from all unmasked engines, a specific hit count register with the number of preliminary hits from a specific hash engine, a specific true hit count with the number of actual hits from a specific hash engine, a difficult hit count register with the number of hits that pass the difficulty threshold, and a dropped hit count register with the number of hits which were discarded due to lack of buffering. The statistical hit and true hit data can be stored in the registers and retrieved to calculate the first effective hash rate1030.

In the retrieve second circuit step1008, a second input file1026of a second test circuit1024can include simulation and test directives for evaluating the second test circuit1024. The simulation and test directives can be configured as part of the second input file1026or linked to the second input file1026.

In the simulate second circuit step1010, the second input file1026of the second test circuit1024can be processed by the simulation engines906. In some embodiments, the simulation engine906, such as a SPICE engine, can read and validate the second input file1026, simulate the second test circuit1024, and write the results into a second output file1036. A second effective hash rate1032can be determined for the second test circuit1024.

In another embodiment, the second effective hash rate1032can be calculated in a variety of ways. In one embodiment, the first effective hash rate1030can be calculated by retrieving hit information from registers in the second test circuit1024. The second test circuit1024can include several registers including a general hit count register with the number of preliminary hits from all unmasked engine, a general true hit count register with the number of actual hits from all unmasked engines, a specific hit count register with the number of preliminary hits from a specific hash engine, a specific true hit count with the number of actual hits from a specific hash engine, a difficult hit count register with the number of hits that pass the difficulty threshold, and a dropped hit count register with the number of hits which were discarded due to lack of buffering. The statistical hit and true hit data can be stored in the registers and retrieved to calculate the second effective hash rate1032.

In the identify preferred circuit step1012, the first effective hash rate1030can be compared to the second effective hash rate1032. If the first effective hash rate1030is greater than the second effective hash rate1032, then the first test circuit1020is assigned to a preferred circuit1028. If the first effective hash rate1030is less than or equal to the second effective hash rate1032, then the second test circuit1024is assigned as the preferred circuit1028.

In the formation step1014, an optional process can use the preferred circuit1028to build a hardware implementation of the preferred circuit1028for hash engines1038. For example, the preferred circuit1028can be implemented as an ASIC chip.

In some embodiments, the formation step1014can be used to configure the operational parameters of live versions of the preferred circuit1028that have been previously fabricated to maximize system performance based on actual conditions. The simulations may be used to guide live operations by updating the operational parameters such as power and clock frequency for the preferred circuit1028.

Other examples of these and other embodiments are found throughout this disclosure.

4.0. EXAMPLE EMBODIMENTS

Examples of some embodiments are represented, without limitation, in the following clauses and use cases:

According to an embodiment, a method of manufacture of an electronic system comprises retrieving a first test circuit file from a circuit database, simulating the first test circuit file on a circuit simulation system configured to calculate a first effective hash rate of the first test circuit, retrieving a second test circuit from the circuit database, simulating the second test circuit file on the circuit simulation system to calculate a second effective hash rate of the second test circuit, the second test circuit operating at a different operating voltage than the first test circuit, the second test circuit operating at a different operating clock frequency than the first test circuit, comparing the first effective hash rate and the second effective hash to identify a preferred circuit having a target effective hash rate above a performance threshold, and forming an electronic system for a digital currency mining system using the preferred circuit.

In an embodiment, the method further comprises simulating the second test circuit over a set of operating clock frequencies, calculating a test hash rate and a hashing error rate of the second test circuit at each of the set of operating clock frequencies, identifying the effective hash rate of the second test circuit by determining a maximum test hash rate of the second test circuit with the hashing error rate below an error rate threshold over the set of operating clock frequencies, the maximum test hash rate at a peak clock rate, configuring the preferred circuit to operate at the peak clock rate.

In an embodiment, the method further comprises simulating the second test circuit over a set of operating voltages, calculating a test hash rate and a hashing error rate of the second test circuit at each of the set of operating voltages at a fixed operating clock frequency, and identifying the effective hash rate of the second test circuit as a maximum test hash rate with the hashing error rate below an error rate threshold over the set of operating voltages, the maximum test hash rate at a peak operating voltage, and configuring the preferred circuit to operate at the peak operating voltage.

In an embodiment, the method further comprises calculating the first test hash rate using the first test circuit configured to implement at least one SHA-256 hash engine, and calculating the second test hash rate using the second test circuit configured to implement at least one SHA-256 hash engine.

In an embodiment, the method further comprises calculating the hashing error rate as the sum of a functional error rate and an operational error rate.

In an embodiment, the method further comprises the first test circuit is configured as a SHA-256 hash engine having two or more compressor units sharing a message schedule generated by one expander unit.

In an embodiment, the method further comprises configuring the first test circuit to have a first power consumption lower than a second power consumption of the second test circuit.

In an embodiment, the method further comprises configuring the first test circuit to have a first circuit surface area lower than a second circuit surface area of the second test circuit.

In an embodiment, the method further comprises simulating an expander coupled to a compressor configured to calculate a hash digest.

In an embodiment, the method further comprises simulating an expander configured to form a message schedule of data from a first chunk of an initial message.

According to an embodiment, an electronic system comprises a circuit database having a first test circuit file entry and a second test circuit file entry, a circuit simulation system configured to calculate a first effective hash rate of the first test circuit and a second effective hash rate of the second test circuit, the second test circuit operating at a different operating voltage than the first test circuit, the second test circuit operating at a different operating clock frequency than the first test circuit, and a control unit configured to compare the first effective hash rate to the second effective hash to identify a preferred circuit having a higher effective hash rate and the control unit configured to form an electronic system for a digital currency mining system with the preferred circuit.

In an embodiment, the system further comprises a clock subsystem configured to generate a set of operating clock frequencies, and wherein the control unit is configured to calculate a test hash rate and a hashing error rate of the second test circuit at each of the set of operating clock frequencies with a fixed operating voltage and configured to identify the effective hash rate of the second test circuit by determining a maximum test hash rate of the second test circuit with the hashing error rate below an error rate threshold over the set of operating clock frequencies, the maximum test hash rate at a peak clock rate, and the circuit simulation system is configured to simulate the preferred circuit at the peak clock rate.

In an embodiment, the system further comprises the circuit simulation system configured to simulate the second test circuit over a set of operating voltages, the control unit is configured to calculate a test hash rate and a hashing error rate of the second test circuit at each of the set of operating voltages with a fixed operating clock frequency and configured to identify the effective hash rate of the second test circuit as a maximum test hash rate with the hashing error rate below an error rate threshold over the set of operating voltages, the maximum test hash rate at a peak operating voltage, and the circuit simulation system is configured to simulate the preferred circuit at the peak operating voltage.

In an embodiment, the system further comprises the first test circuit configured to implement at least one SHA-256 hash engine, and the second test circuit is configured to implement at least one SHA-256 hash engine.

In an embodiment, the system further comprises the control unit configured to calculate the hashing error rate as the sum of a functional error rate and an operational error rate.

In an embodiment, the system further comprises the first test circuit configured as a SHA-256 hash engine having two or more compressor units sharing a message schedule generated by one expander unit.

In an embodiment, the system further comprises the first test circuit configured to have a first power consumption lower than a second power consumption of the second test circuit.

In an embodiment, the system further comprises the first test circuit configured to have a first circuit surface area lower than a second circuit surface area of the second test circuit.

In an embodiment, the system further comprises an expander coupled to a compressor configured to calculate a hash digest.

In an embodiment, the system further comprises an expander configured to form a message schedule of data from a first chunk of an initial message.

5.0. EXTENSIONS AND ALTERNATIVES

As used herein, the terms “first,” “second,” “certain,” and “particular” are used as naming conventions to distinguish queries, plans, representations, steps, objects, devices, or other items from each other, so that these items may be referenced after they have been introduced. Unless otherwise specified herein, the use of these terms does not imply an ordering, timing, or any other characteristic of the referenced items.

In the drawings, the various components are depicted as being coupled to various other components by arrows. These arrows illustrate only certain examples of current flows between or through the components. Neither the direction of the arrows nor the lack of arrow lines between certain components should be interpreted as indicating the existence or absence of a flow between the certain components themselves.

In the specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. Thus, the sole and exclusive indicator of what is the invention and is intended by the applicants to be the invention, is the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction. In this regard, although specific claim dependencies are set out in the claims of this application, it is to be noted that the features of the dependent claims of this application may be combined as appropriate with the features of other dependent claims and with the features of the independent claims of this system, and not merely according to the specific dependencies recited in the set of claims. Moreover, although separate embodiments are discussed herein, any combination of embodiments and/or partial embodiments discussed herein may be combined to form further embodiments.

Any definitions expressly set forth herein for terms contained in such claims shall govern the meaning of such terms as used in the claims. Hence, no limitation, element, property, feature, advantage or attribute that is not expressly recited in a claim should limit the scope of such claim in any way. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

It is understood that the system functionality can be described using terms like module, unit, system, subsystem, pod, and component that represent devices that can be implemented using different combinations of mechanical and electronic elements. The systems and devices can include electric subsystems, mechanical subsystems, and other physical elements to operate and control the system. These elements can include computing elements that can execute the firmware and software of the system to control mechanical features of the system. In addition, the mechanical elements of the system can operate with or without control mechanisms in regular operation.