Abstract: A simulation framework is capable modeling a hardware implementation of a reference software system using models specified in different computer-readable languages. The models correspond to different ones of a plurality of subsystems of the hardware implementation. Input data is provided to a first simulator configured to simulate a first model of a first subsystem of the modeled hardware implementation. The input data is captured from execution of the reference software system. The first simulator executing the first model generates a first data file specifying output of the first subsystem. The first data file specifies intermediate data of the modeled hardware implementation. The first data file is provided to a second simulator configured to simulate a second model of a second subsystem of the modeled hardware implementation. The second simulator executing the second model generates a second data file specifying output of the second subsystem.

Abstract: The embodiments herein describe a communication protocol (which can be implemented in hardware or software) that provides efficient recover packet loss and can transit large messages in a complex network environment. In one embodiment, each data packet contains an encoded universal sequence which is unique across the sends, which enables cross-sender loss recovery. A receiver can include a transmission control module that controls the receiving buffer and maintains the buffer status and the sender's status. The transmission control module stores incoming packets to the correct position in the receiving buffer and generates acknowledgement notifications. The transmission control module also handles packet loss and out-of-order receiving of the packets containing the transactions.

Abstract: Embodiments herein describe a hardware accelerator for a blockchain node. The hardware accelerator is used to perform a validation operation to validate one or more transactions before those transactions are committed to a ledger of a blockchain. The embodiments herein describe a scheduler for assigning validation engines to the transactions in response to the number of endorsements in the transactions.

Abstract: Embodiments herein describe a hardware accelerator for a blockchain node. The hardware accelerator is used to perform a validation operation to validate one or more transactions before those transactions are committed to a ledger of a blockchain. The embodiments herein describe an out-of-order validation scheme where a collector is used to collect validated transactions out of order. Thus, if a validation pipeline has finished validating a later transaction before another validation pipeline has finished validating an earlier transaction, the pipeline can nonetheless send its results to the collector and retrieve another transaction from a scheduler. In this manner, the downtime for the validation pipelines is reduced or eliminated.

Abstract: Embodiments herein describe a hardware accelerator for a blockchain node. The hardware accelerator is used to perform a validation operation to validate one or more transactions before those transactions are committed to a ledger of a blockchain. The blockchain may include multiple peer-nodes, each of which contains standard software running on a server or container. Instead of validating a block of transactions using software, the hardware accelerator can validate the transactions in a fraction of the time. The peer-node software then gathers the validation results from the hardware accelerator and combines the results with received block data to derive the block which is committed to the stored ledger.

Abstract: Embodiments herein describe a hardware accelerator (e.g., a network acceleration engine) for a blockchain machine or node. The hardware accelerator parses packets containing separate components of a block of transactions to generate data to perform a validation process. To avoid the latency that comes with using software, the embodiments herein describe a protocol processor in the hardware accelerator that parses the packets and prepares the data so it can be consumed by downstream components in the accelerator without software intervention. These downstream components can then perform a validation operation to validate one or more transactions before those transactions are committed (i.e., added) to a ledger of a permissioned blockchain.

Abstract: Mining proxy acceleration may include receiving, within a mining proxy, packetized data from a mining pool server and determining, using the mining proxy, whether the packetized data qualifies for broadcast processing. In response to determining that the packetized data qualifies for broadcast processing, the packetized data can be modified using the mining proxy to generate broadcast data. The broadcast data can be broadcast, using the mining proxy, to a plurality of miners subscribed to the mining proxy.

Abstract: Embodiments herein describe a hardware accelerator (e.g., a network acceleration engine) for a blockchain machine or node. The hardware accelerator parses packets containing separate components of a block of transactions to generate data to perform a validation process. To avoid the latency that comes with using software, the embodiments herein describe a protocol processor in the hardware accelerator that parses the packets and prepares the data so it can be consumed by downstream components in the accelerator without software intervention. These downstream components can then perform a validation operation to validate one or more transactions before those transactions are committed (i.e., added) to a ledger of a permissioned blockchain.

Abstract: Embodiments herein describe a hardware accelerator for a blockchain node. The hardware accelerator is used to perform a validation operation to validate one or more transactions before those transactions are committed to a ledger of a blockchain. The blockchain may include multiple peer-nodes, each of which contains standard software running on a server or container. Instead of validating a block of transactions using software, the hardware accelerator can validate the transactions in a fraction of the time. The peer-node software then gathers the validation results from the hardware accelerator and combines the results with received block data to derive the block which is committed to the stored ledger.

Abstract: A method determines a configuration for inter-processor communication for a heterogeneous multi-processor system. The method determines at least one subgraph of a graph representing communication between processors of the heterogeneous multi-processor system. For each subgraph the method (i) determines a plurality of subgraph design points. Each subgraph design point has a variation of channel mapping between any two of the processors in the subgraph by selecting from first-in-first-out (FIFO) memory and shared cache, and varying the shared cache and a local memory associated with at least one of the processors according to the channel mapping; and (ii) selects a memory solution for the subgraph, based on a cost associated with the selected memory solution. The method then determines a configuration for the graph of the heterogeneous multi-processor system, based on the selected memory solutions, to determine the configuration for inter-processor communication for the heterogeneous multi-processor system.

Abstract: A method of determining a metric of a System-on-Chip (SoC), the method comprising: receiving a model dependency graph representing the SoC, the model dependency graph having a plurality of nodes representing components of the SoC and their models, and a plurality of directed edges between the nodes representing variables passed between the nodes of the model dependency graph; modifying the model dependency graph by clustering a plurality of strongly connected nodes in the model dependency graph into a single clustered node to form a clustered model dependency graph; determining an execution schedule according to a direction of an edge in the clustered model dependency graph; and executing models in the clustered model dependency graph according to the execution schedule to determine metrics of the SoC.

Abstract: A method determines a configuration for inter-processor communication for a heterogeneous multi-processor system. The method determines at least one subgraph of a graph representing communication between processors of the heterogeneous multi-processor system. For each subgraph the method (i) determines a plurality of subgraph design points. Each subgraph design point has a variation of channel mapping between any two of the processors in the subgraph by selecting from first-in-first-out (FIFO) memory and shared cache, and varying the shared cache and a local memory associated with at least one of the processors according to the channel mapping; and (ii) selects a memory solution for the subgraph, based on a cost associated with the selected memory solution. The method then determines a configuration for the graph of the heterogeneous multi-processor system, based on the selected memory solutions, to determine the configuration for inter-processor communication for the heterogeneous multi-processor system.

Abstract: A method of determining a metric of an SoC, the method comprising: receiving a model dependency graph representing the SoC, the model dependency graph having a plurality of nodes representing components of the SoC and their models, and a plurality of directed edges between the nodes representing variables passed between the nodes of the model dependency graph; modifying the model dependency graph by clustering a plurality of strongly connected nodes in the model dependency graph into a single clustered node to form a clustered model dependency graph; determining an execution schedule according to a direction of an edge in the clustered model dependency graph; and executing models in the clustered model dependency graph according to the execution schedule to determine metrics of the SoC.