Hardware-based dynamic cyclic redundancy check (CRC) generator for automotive applications
By using multiple streaming CRC engines in parallel to generate CRC values in the replication engine hardware and updating the ring descriptor through software, the problem of low efficiency in CRC value generation and processing in the prior art is solved, and efficient data transmission performance is achieved.
Patent Information
- Application Number
- CN202380062650.6
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2022-09-06
- Filing Date
- 2023-06-26
- Publication Date
- 2025-04-08
- Estimated Expiration
- 2043-06-26
AI Technical Summary
When the prior art realizes data transmission between multiple communication protocols, it is difficult to efficiently generate and process cyclic redundancy check (CRC) values, resulting in high computational cost and long time.
By implementing multiple streaming CRC engines in the hardware of the replication engine, CRC values for multiple data sets are allowed to be generated in parallel, and the ring descriptors are stored and updated through software to reduce hardware processing time.
It realizes efficient parallel generation of CRC values in a secure network, improves the performance and efficiency of data transmission, and reduces processor intervention and frequent attention to data transmission.
Smart Images

Figure CN119790614A_ABST
Abstract
Description
[0001] CROSS-REFERENCE TO RELATED APPLICATIONS
[0002] This application claims the benefit of priority to U.S. non-provisional application No. 17 / 929,764, filed on September 6, 2022; the entire contents of which are incorporated herein by reference. Background Art
[0003] A communication network may implement network devices that are communicatively coupled to each other according to various communication standards. In order to transmit data between other devices within the communication network, the network devices must be configured or configurable to communicate according to the communication protocol used by the other devices. For example, a network device attempting to establish a communication link between Bluetooth-enabled devices and another communication link between Wi-Fi-enabled devices involves establishing a link and transmitting data according to both Bluetooth and WIFI standard protocols. Part of the communication link and data transmission process includes performing a cyclic redundancy check (CRC) to verify the data payload, ensure data security and prevent errors. Network devices attempting to transmit data between network devices implementing various communication protocols need to perform a CRC defined by the various communication protocols. Summary of the invention
[0004] Various aspects include a method for generating a cyclic redundancy check (CRC) in a secure network performed by a replication engine of a computing device. Various aspects may include replicating a first data set received from an interface bus in hardware of the replication engine to obtain a first data set copy, replicating a second data set received from the interface bus in hardware of the replication engine to obtain a second data set copy, generating a first CRC value for the first data set copy via a first streaming CRC engine in hardware of the replication engine, and generating a second CRC value for the second data set copy in parallel via a second streaming CRC engine in hardware of the replication engine, sending a first streaming CRC message including the first data set copy and the first CRC value to a processor of the computing device, and sending a second streaming CRC message including the second data set copy and the second CRC value to the processor.
[0005] Some aspects may also include generating a first source ring descriptor including a first source data pointer indicating a memory location of the first data set based on the first communication message, and generating a second source ring descriptor including a second source data pointer indicating a memory location of the second data set based on the second communication message.
[0006] In some embodiments, copying a first data set received from an interface bus in the hardware of the replication engine to obtain a copy of the first data set may also include copying the first data set based on a first source data pointer, and copying a second data set received from the interface bus in the hardware of the replication engine to obtain a copy of the second data set may also include copying the second data set based on a second source data pointer.
[0007] In some embodiments, the first source ring descriptor may include first length bits indicating the length of the first data set, first aggregation bits indicating that the first CRC value is generated as part of a first data set stream including multiple data sets, and a first CRC type indicating a first communication protocol, and the second source ring descriptor may include second length bits indicating the length of the second data set, second aggregation bits indicating that the second CRC value is generated as part of a second data set stream including multiple data sets, and a second CRC type indicating a second communication protocol.
[0008] In some embodiments, generating a first CRC value for a first data set copy via a first streaming CRC engine may also include generating a first CRC value for the first data set copy via the first streaming CRC engine based on a first CRC type indicating a first communication protocol, and generating a second CRC value for a second data set copy via a second streaming CRC engine may also include generating a second CRC value for the second data set copy via the second streaming CRC engine based on a second CRC type indicating a second communication protocol.
[0009] In some embodiments, the first CRC type and the second CRC type may be different CRC types.
[0010] Some aspects may also include generating a first state ring descriptor including a first CRC value and a first status bit, generating a second state ring descriptor including a second CRC value and a second status bit, setting the first status bit after generating the first CRC value, wherein sending a first streaming CRC message is performed in response to setting the first status bit, and setting the second status bit after generating the second CRC value, wherein sending the second streaming CRC message is performed in response to setting the second status bit.
[0011] Some aspects may also include generating a first destination ring descriptor including a first destination data pointer, and generating a second destination ring descriptor including a second destination data pointer, wherein sending a first streaming CRC message may also include sending the first streaming CRC message based on the first destination data pointer, and wherein sending a second streaming CRC message may also include sending a second streaming CRC message based on the second destination data pointer.
[0012] Some aspects may also include copying a third data set received from the interface bus in hardware of the replication engine to obtain a third data set copy, wherein a first CRC value for the first data set copy is generated in hardware of the replication engine via a first streaming CRC engine and a second CRC value for the second data set copy is generated in hardware of the replication engine via a second streaming CRC engine in parallel, and may also include generating a final CRC value via the first streaming CRC engine, wherein the final CRC value is generated using the third data set copy and the first CRC value, and wherein sending a first streaming CRC message to the processor may also include sending a first streaming CRC message to the processor including the first data set copy, the third data set copy, and the final CRC value.
[0013] Further aspects may include a computing device having a replication engine configured to perform the operations of any of the methods outlined above. Further aspects may include a computing device having means for performing the functionality of any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS
[0014] The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate example embodiments, and together with the general description given above and the detailed description given below, serve to explain features of the various embodiments.
[0015] Figure 1A is a component block diagram of a secure network 150 illustrating components and supporting systems suitable for implementing various embodiments.
[0016] Figure 1B is a diagram illustrating an example software architecture including a radio protocol stack suitable for implementing a user plane and a control plane in wireless communications of an embodiment.
[0017] Figure 1C is a system block diagram illustrating an example decomposed base station architecture according to various embodiments, which may be part of a 5G network suitable for implementing a hardware-based dynamic CRC generator.
[0018] Figure 2 is a component block diagram illustrating an example computing and wireless modem system suitable for implementing various embodiments.
[0019] Figure 3 is a component block diagram illustrating an example system 300 configured to establish secure device-to-device communications between a security subsystem and a network device according to some embodiments.
[0020] Figure 4 is a block diagram of a replication engine including a streaming CRC engine according to various embodiments.
[0021] Figure 5 is a block diagram of a replication engine including a software-based ring descriptor according to various embodiments.
[0022] Figure 6 is a block diagram of a streaming CRC engine implemented within a channel of a replication engine according to various embodiments.
[0023] Figure 7 is a block diagram of a conventional packet-based CRC message transmitted across a bus.
[0024] Figure 8 is a block diagram of streaming CRC messages transmitted across a bus according to various embodiments.
[0025] Fig. 9 is a block diagram of an example data set flow according to various embodiments.
[0026] Fig. 10A is a process flow diagram of a method for generating a CRC in a secure network according to various embodiments.
[0027] FIG. 10B to FIG. 10E is a process flow diagram of operations 1000b - 1000e that may be performed as part of a method for generating a CRC in a secure network according to some embodiments.
[0028] Fig.11 is a component block diagram of a network computing device 1100 suitable for use with various embodiments, such as a security subsystem. DETAILED DESCRIPTION
[0029] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.
[0030] Various embodiments include hardware elements and methods implemented in such hardware elements for generating one or more cyclic redundancy checks (CRCs) in parallel in a network, such as an automotive network supporting various safety-related subsystems.
[0031] Many different vehicle subsystems have safety-related functions, such as sensor systems, braking systems, information displays, etc., many of which need to exchange data and commands with many other vehicle subsystems. Due to safety considerations, safety-related systems need to exchange data across networks and data buses in a safe and reliable manner. A method for ensuring that data exchanged between devices is accurately communicated involves including CRC information in message packets, which enables the receiving device to confirm the accuracy of the packet data and correct some errors that may be introduced in the transmission. What complicates the safe exchange of data and commands between multiple vehicle subsystems is that many subsystems and devices connected to the vehicle network use different network protocols. In addition, some subsystems and devices can exchange data via wireless communication links, including Bluetooth, Bluetooth low energy (BLE) and Wi-Fi, which use different protocols from devices that communicate data via the wired network of the vehicle. Different communication protocols may involve different CRC methods. Therefore, various components and subsystems that communicate on the vehicle network, particularly safety-related subsystems (referred to as "safety subsystems") that exchange data on the vehicle network may need to adapt to a variety of different methods for generating and using CRC information.
[0032] Various embodiments include hardware solutions and methods for supporting the generation of streaming CRC of data sets communicated via various protocols. Various embodiments allow to generate and / or calculate the CRC value of multiple data sets in parallel (e.g., in the same time window) by implementing multiple streaming CRC engines in the hardware of the replication engine that can be implemented in the safety subsystem. Each streaming CRC engine can be assigned a channel, and can handle multiple data sets of different CRC types in the data set stream (i.e., stack). The packet overhead of each data set can be stored by software as source, state and destination ring descriptors and updated in software, thereby reducing the time for generating CRC in the streaming CRC engine based on hardware. Although particularly useful for vehicle systems, various embodiments can also be useful in any network of components and subsystems that use more than one communication protocol to communicate data and commands.
[0033] The term "computing device" is used herein to refer to any or all of the following: router devices (wired or wireless), appliances (wired or wireless), cellular phones, smartphones, portable computing devices, personal or mobile multimedia players, laptop computers, tablet computers, smartbooks, ultrabooks, handheld computers, wireless email receivers, Internet-enabled multimedia cellular phones, medical devices and equipment, biosensors / devices, wearable devices (including smart watches, smart clothing, smart glasses, smart wristbands, smart jewelry (e.g., smart rings, smart bracelets)), entertainment devices (e.g., wireless game controllers, music and video players, satellite radios, etc.), wireless network-enabled Internet of Things (IoT) devices (including smart meters / sensors, industrial manufacturing equipment, large and small machines and appliances for home or business use), wireless communication elements within autonomous and semi-autonomous vehicles, wireless devices attached to or incorporated into various mobile platforms, global positioning system devices, and similar electronic devices including memory and programmable processors. Computing devices (e.g., cellular phones, smartphones, etc.) that include wireless communication components and are configured to communicate with other computing devices via wireless communication links are referred to herein as "wireless computing devices".
[0034] The term "system on chip" (SoC) is used herein to refer to a single integrated circuit (IC) chip that includes multiple resources and / or processors integrated on a single substrate. A single SoC may include circuits for digital, analog, mixed signal, and radio frequency functions. A single SoC may also include any number of general and / or specialized processors (digital signal processors, modem processors, video processors, etc.), storage blocks (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). The SoC may also include software for controlling the integrated resources and processors and for controlling peripheral devices.
[0035] The term "system-in-package" (SiP) may be used herein to refer to a single module or package that includes multiple resources, computing units, cores and / or processors on two or more IC chips, substrates, or SoCs. For example, a SiP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SiP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SiP may also include multiple independent SoCs that are coupled together via high-speed communication circuitry and packaged together in close proximity (such as on a single motherboard or in a single computing device). The proximity of the SoC facilitates high-speed communication and sharing of memory and resources.
[0036] Network devices that implement various communication protocols may process cyclic redundancy checks (CRCs) and generate CRC values for error correction and data security purposes as defined by each communication protocol. Different communication protocols generate CRC values in different ways, and therefore two components or subsystems using different communication protocols may generate / use different CRC values. For example, devices, networks, and subsystems such as advanced driver assistance systems (ADAS) (i.e., safety subsystems) may wirelessly communicate with multiple network devices such as multimedia distribution devices, entertainment displays, wireless mobile devices, wireless charging stations, tire pressure monitoring systems, keyless entry devices, and any other device capable of communicating with ADAS within a secure network, some of which may use different CRC methods in data exchanges on the same network.
[0037] The Replication Engine is a module in the Security Subsystem Network that handles data transmission between various network devices for all types of communication protocols, including Ethernet, Controller Area Network (CAN), Serial Transport, Secure Digital (SD) Transport, Double Data Rate (DDR) Transport, and WiFi, etc. The recommended processing for data integrity checking to generate CRC values varies depending on the protocol.
[0038] In automotive safety networks and subsystems, the recommended CRC processing steps may vary based on the standards implemented by the devices and subsystems that are communicatively coupled to the safety subsystem (i.e., ADAS) within the safety network. Thus, the safety subsystem may process and generate CRC according to various standards specified by the Automotive Open System Architecture (AUTOSAR).
[0039] AUTOSAR is a development partnership of automotive stakeholders that aims to create and establish an open and standardized software architecture for automotive electronic control units (ECUs). AUTOSAR seeks to cover scalability across different vehicles and platform variants, software portability, consideration of usability and safety requirements, and maintainability over the product lifecycle. AUTOSAR recommends that ADAS follow various communication standards, including but not limited to automotive hardware functional safety (FuSa) features (e.g., ISO 26262), any International Telegraph and Telephone Consultative Committee (CCITT), algorithms for serial streams (e.g., Wide Area Network (WAN), radio communication protocols, secure digital, DigRF) modem standards, Ethernet standards, Bluetooth and Bluetooth Low Energy (BLE) standards, and AUTOSAR CRC standards and recommended protocols, such as the AUTOSAR safety polynomial CRC32P4 using the 0xF4ACFB13 polynomial, the SAE J1850CRC8 with a 0x1D polynomial for diagnostic and digital sharing applications in vehicles, and the 8-bit 0x2FCRC for open safety communication protocols.
[0040] While the AUTOSAR specification recommends CRC for functional safety of all protocols and specifies new methods for CRC protocols for safety-related protocols, various other standards may recommend different protocols. Therefore, dynamic compliance for all protocols recommended by AUTOSAR and various other standards is a challenge because each standard may have different requirements for generating and verifying CRC when communicating data payloads between communicatively connected devices and subsystems. Traditional packet-based CRC processing is performed sequentially according to each standard and may require a CRC overhead of up to 50% of the total bit length of each associated data stack. Therefore, for each variant of the communication protocol, verifying the CRC value according to the conventional packet approach may be computationally expensive and time-consuming.
[0041] Various embodiments minimize the processing for generating CRC values performed by hardware by unloading CRC overhead to data structures such as software-based ring descriptors. Various embodiments can generate and update source ring descriptors, state ring descriptors, and destination ring descriptors for each data set communicated between network devices. In addition to other CRC overhead fields or bits associated with payload or data sets, ring descriptors can also include metadata that can be used to identify source, destination, updated CRC value, CRC type. Various embodiments can further generate CRC in parallel by implementing multiple hardware-based streaming CRC engines in separate channels, wherein each streaming CRC engine can process data set streams of multiple data sets including identical or different CRC types. CRC type can be an indicator representing that a data set is transmitted to a secure subsystem and / or a communication protocol transmitted from a secure subsystem.
[0042] Various embodiments include a computing device for use in a secure network, the computing device comprising: an interface bus, through which communications including a data set are transmitted; and a replication engine coupled to the interface bus. The replication engine may include a replication engine buffer in hardware configured to store the data set as a data set copy, and a first streaming CRC engine and a second streaming CRC engine. The replication engine may be configured to copy a first data set received from the interface bus to the replication engine buffer as a first data set copy, and to copy a second data set received from the interface bus to the replication engine buffer as a second data set copy. The replication engine may also be configured to generate a first CRC value for the first data set copy using the first streaming CRC engine and generate a second CRC value for the second data set copy using the second streaming CRC engine. The replication engine may then send a first streaming CRC message including a first data set copy and a first CRC value and a second streaming CRC message including a second data set copy and a second CRC value to a processor of the computing device via the interface bus.
[0043] In some embodiments, the replication engine may be further configured to generate a second CRC value for the copy of the second data set using a second streaming CRC engine in parallel with generating the first CRC value using the first streaming CRC engine.
[0044] In some embodiments, the replication engine may further include a memory mapping subsystem configured to generate a first source ring descriptor based on the first communication message, the first source ring descriptor including a first source data pointer indicating a memory location of the first data set. The memory mapping subsystem may also be configured to generate a second source ring descriptor based on the second communication message, the second source ring descriptor including a second source data pointer indicating a memory location of the second data set. In some embodiments, the replication engine may also be configured to copy the first data set to the replication engine buffer based on the first source data pointer, and copy the second data set to the replication engine buffer based on the second source data pointer.
[0045] In some embodiments, the replication engine may be further configured such that the first source ring descriptor includes a first length bit indicating the length of the first data set, a first aggregation bit indicating that the first CRC value is generated as part of a first data set stream including multiple data sets, and a first CRC type indicating a first communication protocol. The replication engine may be further configured such that the second source ring descriptor includes a second length bit indicating the length of the second data set, a second aggregation bit indicating that the second CRC value is generated as part of a second data set stream including multiple data sets, and a second CRC type indicating a second communication protocol.
[0046] In some embodiments, the replication engine may also be configured to generate a first CRC value for a first data set copy based on a first CRC type indicating a first communication protocol using a first streaming CRC engine, and to generate a second CRC value for a second data set copy based on a second CRC type indicating a second communication protocol using a second streaming CRC engine, wherein the first CRC type and the second CRC type are different CRC types.
[0047] In some embodiments, the memory mapping subsystem may be configured to generate a first state ring descriptor including a first CRC value and a first state bit, generate a second state ring descriptor including a second CRC value and a second state bit, set the first state bit in response to the first streaming CRC engine generating the first CRC value, and set the second state bit in response to the second streaming CRC engine generating the second CRC value. The replication engine may be configured to send a first streaming CRC message via the interface bus in response to the memory mapping subsystem setting the first state bit, and send a second streaming CRC message via the interface bus in response to the memory mapping subsystem setting the second state bit.
[0048] In some embodiments, the memory mapping subsystem may be further configured to generate a first destination ring descriptor including a first destination data pointer, and to generate a second destination ring descriptor including a second destination data pointer. The copy engine may be configured to send a first streaming CRC message via the interface bus based on the first destination data pointer, and to send a second streaming CRC message via the interface bus based on the second destination data pointer.
[0049] In some embodiments, the replication engine may also be configured to copy a third data set received from the interface bus to the replication engine buffer as a third data set copy, use the first streaming CRC engine to generate a final CRC value using the third data set copy and the first CRC value (i.e., the first data set and the third data set are part of the same data stream), and send a first streaming CRC message including the first data set copy, the third data set copy, and the final CRC value to the processor via the interface bus.
[0050] In various embodiments, multiple channel traffic in a network (e.g., a safety network) may be handled with different CRC types based on the recommendations of different communication protocols (i.e., how to generate or otherwise calculate CRC within hardware circuits). Various embodiments address organizational, throughput, and processing issues associated with implementing all communication protocols recommended by AUTOSAR. As a result of (i) multi-channel parallel CRC generation, (ii) hardware-based streaming CRC generation for data streams including multiple data sets, and (iii) offloading CRC overhead from hardware to software in the form of a ring descriptor data structure, the performance and efficiency of the safety subsystem are improved. More specifically, subsystem and secure network performance is improved due to the following features: CRC is calculated or otherwise generated in hardware, CRC is calculated or otherwise generated in a stream manner rather than a packet manner and is updated in a state ring descriptor stored in a memory mapped subsystem (e.g., firmware, DDR), CRC overhead is not added to the data payload or data buffer (i.e., but is stored separately as a software-based ring descriptor), the calculated CRC is handled by software (i.e., the generated CRC value is updated within the software-based state ring descriptor), verification of the CRC checksum is done in software as the data is consumed by the application, multiple channels handle different types of communication protocols and each data stream may include a different CRC type, and processor interrupts are minimized (i.e., fewer interrupts) when instructions are replaced by ring descriptors stored in a batch stack. In other words, data transfers can be initiated for multiple channels supporting different types of protocols by programming the source and destination ring descriptors of each channel by software, data transfer completion can be marked again in batches for the ring descriptor stack populated by hardware for the state ring descriptor, and CRC verification for the batched data transfer stream programmed in the source descriptor is handled by software. This reduces processor intervention and frequent attention to every data transfer per channel.
[0051] Figure 1A is a component block diagram of a secure network 150 illustrating components and supporting systems suitable for implementing various embodiments. Figure 1A , vehicle 152a may include a safety subsystem 180, which may include various circuits and devices for controlling the operation of vehicle 152a and communicating with other similarly equipped vehicles, such as vehicle 152b. Figure 1A In the example illustrated in , the safety subsystem 180 includes a radio module 185, a processor 182, a memory 181, an input module 183, an output module 184, and a replication engine 190. The safety subsystem 180 can be coupled to and configured to control a drive control component 186, a navigation component 187, one or more sensor components 188, a telematics component 191, and an infotainment component 193 of the vehicle 152a.
[0052] Base stations 110 may communicate with core network 140 over wired or wireless communication links 126. Wireless communication links 126 may use various wired networks (e.g., Ethernet, TV cable, telephone, fiber optic, and other forms of physical network connections) that may use one or more wired communication protocols (such as Ethernet, Point-to-Point Protocol, High Level Data Link Control (HDLC), Advanced Data Communications Control Protocol (ADCCP), and Transmission Control Protocol / Internet Protocol (TCP / IP)).
[0053] The wireless computing device 120 and the vehicles 152a and 152b may communicate with the base station 110 over the wireless communication link 122. The wireless communication links 122 and 124 may include multiple carrier signals, frequencies, or frequency bands, each of which may include multiple logical channels. The wireless communication links 122 and 124 may utilize one or more radio access technologies (RATs). Examples of RATs that may be used in the wireless communication links include: 3GPP LTE, 3G, 4G, 5G (e.g., NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile phone communication technology cellular RATs. Other examples of RATs that may be used in one or more of the various wireless communication links within the communication system 100 include medium-range protocols (such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire) and relatively short-range RATs (such as ZigBee, Bluetooth, and Bluetooth Low Energy (BLE)). In some embodiments, wireless communication links 122 and 124 may comprise direct connect communication links that may be established over a PC5 interface in accordance with applicable 3GPP standards.
[0054] The safety subsystem 180 may include a processor 182 that may be configured with processor executable instructions to control maneuvers, navigation, and / or other operations of the vehicle 152a, including the operations of various embodiments. The processor 182 may be coupled to the memory 166, the replication engine 190, and the radio module 185, for example, via an interconnect or bus (e.g., an advanced extensible interface (AXI)). The device 182 may include one or more processing units. In some embodiments, the processor 182 may be a network on chip (NoC), a switch, or a trusted integrated circuit (TIC) that is communicatively coupled or connected to various network-enabled devices (i.e., via the radio module 185) within the safety network 150. In addition to firmware, the replication engine 190 may also include multiple hardware-based streaming CRC engines, such as a memory mapping subsystem for storing software-based ring descriptors to offload CRC packet overhead from hardware.
[0055] The radio module 185 may be configured for wireless communications, including implementing the operations of various embodiments. The radio module 185 may exchange wireless signals with the base station 110 via the wireless communication link 122, and exchange wireless signals with the control unit in the other vehicle 152b via the wireless communication link 124. In some embodiments, the radio module 185 may also enable the vehicle 152a to communicate with the wireless communication device 120d (e.g., a cellular phone) via a two-way wireless communication link 178 (such as a WiFi or Bluetooth wireless data link). Similarly, the radio module 185 may enable the processor 182 to send information to and receive information from various network devices 189 within the security network 150 via the wireless communication link 178. The network device 189 may be any device that can be communicatively coupled to the radio module 185 within the security network 150, such as a wireless charging station, a key card or device for keyless entry, an infotainment system, a cellular device, a tire pressure measurement system, and a satellite-based navigation system (e.g., a global positioning system (GPS)). The examples of network devices 189 provided to communicate with the radio module 185 are limited for simplicity only and are not intended to be exhaustive. In various embodiments, the controlled network devices may also include smart electrical plugs and smart switches, smart security systems, smart health devices and health monitors, smart appliances, smart meters, smart toys, smart environmental monitors and environmental control systems, various Internet of Things devices, and any other suitable device capable of communicating with the radio module 185.
[0056] In various embodiments, the wireless communication links 122, 124, 178 may implement any of a variety of known wireless communication protocols and standards, such as Radio Frequency for Consumer Electronics (RF4 CE), Controller Area Network (CAN), long-range protocols such as 3GPP LTE, 3G, 4G, 5G (e.g., NR), GSM, CDMA, WCDMA, WiMAX, TDMA, any other mobile phone communication technology cellular RAT, medium-range protocols such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire, relatively short-range RATs such as ZigBee, Bluetooth, BLE, DigRF, any other communication based on the Institute of Electrical and Electronics Engineers (IEEE) 802 standard (e.g., IEEE 802.3), infrared (IR) communication protocols such as RECS-80, RC-5, RC-6, NEC / Renesas protocols, or any other suitable IR communication protocol. In some embodiments, various network devices 189 may be directly connected to the security subsystem 180 via wired connections that implement one or more communication protocols, such as Ethernet, Recommended Standard (RS)-232, RS-485, Universal Asynchronous Receiver Transmitter (UART), Universal Synchronous / Asynchronous Receiver / Transmitter (USART), Universal Serial Bus (USB), High-Definition Multimedia Interface (HDMI), or any other suitable wired communication protocol.
[0057] The safety subsystem 180 may be an advanced driver assistance system (ADAS), and the wireless communication links 122, 124, 178 in conjunction with the safety subsystem 180 (e.g., processor 182, radio module 185, and replication engine 190, etc.) may further implement safety and / or standardized protocols as specified by AUTOSAR, including but not limited to automotive hardware functional safety (FuSa) features (e.g., ISO 26262), any International Telegraph and Telephone Consultative Committee (CCITT), algorithms for serial streams (e.g., wide area network (WAN), radio communication protocols, secure digital, digital radio frequency (DigRF)), etc.), AUTOSAR CRC standards and recommended protocols, such as the AUTOSAR safety polynomial CRC32P4 using the 0xF4ACFB13 polynomial, the SAE J1850 CRC8 with a 0x1D polynomial for diagnostic and data sharing applications in vehicles, and the 8-bit 0x2FCRC for open safety communication protocols.
[0058] Input module 183 may receive sensor data from one or more sensor components 188 as well as electronic signals from other components, including drive control component 186 and navigation component 187. Output module 184 may be used to communicate with or activate various components of vehicle 152a, including drive control component 186, navigation component 187, and sensor 188.
[0059] The safety subsystem 180 may receive and send analog and / or digital sensor data from and to the sensor assembly 188, and may be configured to communicate unidirectionally and / or bidirectionally with the sensor assembly 188. The safety subsystem 180 in conjunction with the sensor assembly 188 may communicate with a network device (e.g., wireless computing device 120, network device 189) configured to relay sensor information of the network device. The safety subsystem 180 in conjunction with the sensor assembly 188 may be configured to implement various features, such as electric vehicle (EV) wireless charging, keyless entry, phone-as-key, automatic parking, tire pressure monitoring, remote sensor control, and autonomous driving features (such as lane and brake checks and alerts).
[0060] The safety subsystem 180 may be coupled to a drive control assembly 186 to control physical elements of the vehicle 152a related to maneuvering and navigation of the vehicle, such as the engine, motor, throttle, steering elements, flight control elements, braking or retarding elements, etc.
[0061] The safety subsystem 180 may be coupled to the navigation component 187 and may receive data from the navigation component 187 and be configured to use such data to determine the current position and orientation of the vehicle 152a and an appropriate route toward the destination.
[0062] The safety subsystem 180 may be coupled to the telematics component 191. The safety subsystem 180 may receive data from and send data to the telematics component 191, and may be configured to send and receive information between a base station (e.g., 110) and other vehicles (e.g., 152b) in conjunction with the telematics component 191. The safety subsystem 180 in conjunction with the infotainment component 193 may be configured to provide various features, such as implementing Car2Car and Car2Infrastructure standards, LTE offloading, media services, over-the-air (OTA) updates, and universal Internet access.
[0063] The safety subsystem 180 may be coupled to the infotainment component 193. The safety subsystem 180 may receive data from and send data to the infotainment component 193, and may be configured to stream data such as video and / or audio media to a display or media output unit of a communicatively connected network device (e.g., wireless computing device 120, network device 189). The safety subsystem 180 in conjunction with the infotainment component 193 may be configured to provide various features such as hands-free voice calling, music streaming, multimedia distribution, rear seat entertainment systems, display sharing, Apple CarPlay, Android Auto, MirrorLink, and general Internet access.
[0064] The processor 182 and / or the navigation component 187 may be configured to communicate with the core network 140 (e.g., the Internet) using the wireless communication link 122 with the cellular data network base station 110. The processor 182 may also be configured to execute a variety of software applications by executing processor-executable instructions in the application layer as described herein.
[0065] Although security subsystem 180 is described as including separate components, in some embodiments, some or all of the components (e.g., processor 182, memory 181, input module 183, output module 184, and radio module 185) may be integrated into a single device or module, such as a system-on-chip (SoC) or system-in-package (SiP) processing device, such as reference 180. Figure 2 Such a SoC or device may be configured for use in a vehicle and configured (such as configured with processor-executable instructions executed in processor 182) to perform the operations of the various embodiments when installed in a vehicle.
[0066] In some specific implementations, the safety network 150 may include one or more devices configured to communicate as part of an intelligent transportation system (ITS). ITS technology can improve the interoperability and safety of driver-operated vehicles and autonomous vehicles. The cellular vehicle-to-everything (C-V2X) protocol defined by the Third Generation Partnership Project (3GPP) supports ITS technology and serves as the basis for vehicles to communicate directly with communication devices around them. C-V2X defines transmission modes that provide non-line-of-sight perception and a higher level of predictability for enhanced road safety and autonomous driving. Such C-V2X transmission modes may include V2V, V2I, and V2P, and may utilize frequencies in the 5.9 gigahertz (GHz) spectrum independent of cellular networks. C-V2X transmission modes may also include vehicle-to-network communications (V2N) in mobile broadband systems and technologies, such as 3G mobile communication technologies (e.g., GSM Evolution (EDGE) systems, CDMA 2000 systems, etc.), 4G communication technologies (e.g., LTE, Advanced LTE, WiMAX, etc.), and 5G systems.
[0067] Figure 1B An example of a software architecture 300 is illustrated, which includes radio protocol stacks for the user plane and control plane in wireless communications between a security subsystem 180 (e.g., a controller or SIP 200 of a vehicle 152a) and a second computing device 350 (e.g., in a vehicle 152b, a network device 189, a wireless computing device 120). In some embodiments, the security subsystem 180 and the second computing device 350 may communicate via D2D or another suitable device-to-device communication method. Figure 1A and Figure 1B , the security subsystem 180 may implement the software architecture 300 to communicate with the computing device 350. In various embodiments, the layers in the software architecture 300 in the security subsystem 180 may form a logical connection with the corresponding layers in software form of the second computing device 350. The software architecture 300 may be distributed among one or more processors (e.g., processors 212, 214, 216, 218, 252, 260).
[0068] Although illustrated with respect to one radio protocol stack, in a multi-SIM (Subscriber Identity Module) wireless computing device, the software architecture 300 may include multiple protocol stacks, each of which may be associated with a different SIM (e.g., in a dual-SIM wireless communication device, two protocol stacks are associated with the two SIMs, respectively). Although described below with reference to LTE communication layers, the software architecture 300 may support any of a variety of standards and protocols for wireless communication, and / or may include additional protocol stacks that support any of a variety of standards and protocols for wireless communication.
[0069] Software architecture 300 may include a non-access stratum (NAS) 302 and an access stratum (AS) 304. NAS 302 may include functions and protocols that support packet filtering, security management, mobility control, session management, and traffic and signaling between a SIM (e.g., SIM 204) of a wireless computing device and its core network 140. AS 304 may include functions and protocols that support communication between a SIM (e.g., SIM 204) and an entity (e.g., a base station) of a supported access network. Specifically, AS 304 may include at least three layers (layer 1, layer 2, and layer 3), each of which may include various sublayers.
[0070] In the user plane and control plane, layer 1 (L1) of AS 304 may be a physical layer (PHY) 306, which may oversee functions that implement transmission and / or reception on the air interface. Examples of such physical layer 306 functions may include cyclic redundancy check (CRC) attachment, decoding blocks, scrambling and descrambling, modulation and demodulation, signal measurement, MIMO, etc. The physical layer may include various logical channels, including a physical downlink control channel (PDCCH) and a physical downlink shared channel (PDSCH).
[0071] In the user plane and the control plane, layer 2 (L2) of AS 304 may be responsible for the link between the security subsystem 180 and the second computing device 350 on the physical layer 306. In various embodiments, layer 2 may include a medium access control (MAC) sublayer 308, a radio link control (RLC) sublayer 310, and a packet data convergence protocol (PDCP) 312 sublayer, each of which forms a logical connection terminated at the second computing device 350.
[0072] In the control plane, layer 3 (L3) of AS 304 may include a radio resource control (RRC) sublayer 3. Although not shown, the software architecture 300 may include additional layer 3 sublayers, as well as various upper layers above layer 3. In various embodiments, the RRC sublayer 313 may provide functionality including broadcasting system information, paging, and establishing and releasing RRC signaling connections between the security subsystem 180 and the second computing device 350. Direct communication messages from the application layer may be sent directly over L2 or L3, or sent over L2 or L3 via another signaling layer (e.g., PC5 signaling or PC5-S).
[0073] In various embodiments, the PDCP sublayer 312 may provide uplink functions including multiplexing between different radio bearers and logical channels, sequence number addition, handover data handling, integrity protection, ciphering, and header compression. In the downlink, the PDCP sublayer 312 may provide functions including in-sequence delivery of data packets, duplicate data packet detection, integrity verification, deciphering, and header decompression.
[0074] In the uplink, the RLC sublayer 310 may provide segmentation and concatenation of upper layer data packets, retransmission of lost data packets, and automatic repeat request (ARQ). In the downlink, the RLC sublayer 310 functions may include reordering of data packets to compensate for out-of-order reception, reassembly of upper layer data packets, and ARQ.
[0075] In the uplink, the MAC sublayer 308 may provide functions including multiplexing between logical and transport channels, random access procedures, logical channel priorities, and hybrid ARQ (HARQ) operations. In the downlink, MAC layer functions may include channel mapping within a cell, demultiplexing, discontinuous reception (DRX), and HARQ operations.
[0076] While the software architecture 300 may provide functionality for sending data over a physical medium, the software architecture 300 may also include at least one host layer 314 to provide data transfer services to various applications in the security subsystem 180. In some embodiments, the application-specific functionality provided by the at least one host layer 314 may provide an interface between the software architecture and the general processor 206.
[0077] In other embodiments, the software architecture 300 may include one or more higher logical layers (e.g., transport, session, presentation, application, etc.) that provide host layer functionality. For example, in some embodiments, the software architecture 300 may include a network layer (e.g., an IP layer) where a logical connection terminates at a packet data network (PDN) gateway (PGW). In some embodiments, the software architecture 300 may include an application layer where a logical connection terminates at another device (e.g., an end user device, a server, etc.). In some embodiments, the software architecture 300 may also include a hardware interface 316 between the physical layer 306 and communication hardware (e.g., one or more radio frequency transceivers) in the AS 304.
[0078] Figure 1C is a system block diagram illustrating an example disaggregated base station 160 architecture that may be part of a 5G network that may support external communications with a network implementing various embodiments and thereby interface with a hardware-based dynamic CRC generator. Figures 1A to 1C, the decomposed base station 160 architecture may include one or more central units (CU) 162, which may communicate directly with the core network 140 via a backhaul link, or indirectly with the core network 140 through one or more decomposed base station units (such as a near real-time (near RT) RAN intelligent controller (RIC) 164 via an E2 link, or a non-real-time (non-RT) RIC 168 associated with a service management and orchestration (SMO) framework 166, or both). The CU 162 may communicate with one or more distributed units (DU) 170 via corresponding midhaul links (such as an F1 interface). The DU 170 may communicate with one or more radio units (RU) 172 via corresponding fronthaul links. The RU 172 may communicate with corresponding UEs 120 via one or more radio frequency (RF) access links. In some implementations, a user equipment (UE) (such as a vehicle automated driving system (ADS) 104) may be served by multiple RUs 172 simultaneously.
[0079] Each of the units (i.e., CU 162, DU 170, RU 172), as well as near-RT RIC 164, non-RT RIC 168, and SMO framework 166 may include one or more interfaces, or be coupled to one or more interfaces configured to receive or send signals, data, or information (collectively referred to as signals) via a wired or wireless transmission medium. Each of these units or an associated processor or controller that provides instructions to the communication interface of these units may be configured to communicate with one or more of the other units via a transmission medium. For example, these units may include a wired interface that is configured to receive or send signals to one or more of the other units via a wired transmission medium. In addition, the unit may include a wireless interface that may include a receiver, a transmitter, or a transceiver (such as a radio frequency (RF) transceiver) that is configured to receive or send signals, or both, to one or more of the other units via a wireless transmission medium.
[0080] In some aspects, CU 162 may host one or more higher layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented with an interface configured to communicate signals with other control functions hosted by CU 162. CU 162 may be configured to handle user plane functionality (i.e., central unit-user plane (CU-UP)), control plane functionality (i.e., central unit-control plane (CU-CP)), or a combination thereof. In some specific implementations, CU 162 may be logically divided into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP unit may communicate bidirectionally with the CU-CP unit via an interface (such as an E1 interface). As needed, CU 162 may be implemented to communicate with DU 170 for network control and signaling.
[0081] DU 170 may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RUs 172. In some aspects, DU 170 may host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more high physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation and demodulation, etc.) depending at least in part on a functional split such as that defined by the Third Generation Partnership Project (3GPP). In some aspects, DU 170 may also host one or more low PHY layers. Each layer (or module) may be implemented using an interface that is configured to communicate signals with other layers (and modules) hosted by DU 170 or with control functions hosted by CU 162.
[0082] The lower layer functionality may be implemented by one or more RUs 172. In some deployments, the RUs 172 controlled by the DUs 170 may correspond to logical nodes that host RF processing functions or low PHY layer functions (such as performing fast Fourier transforms (FFTs), inverse FFTs (iFFTs), digital beamforming, physical random-access channel (PRACH) extraction and filtering, etc.), or both, based at least in part on functional partitioning (such as lower layer functional partitioning). In such an architecture, the RUs 172 may be implemented to handle over-the-air (OTA) communications with one or more UEs 120. In some specific implementations, real-time and non-real-time aspects of control and user plane communications with the RUs 172 may be controlled by the corresponding DUs 170. In some scenarios, this configuration may enable the DUs 170 and CUs 162 to be implemented in a cloud-based radio access network (RAN) architecture (such as a vRAN architecture).
[0083] The SMO framework 166 may be configured to support RAN deployment and provisioning of non-virtualized network elements and virtualized network elements. For non-virtualized network elements, the SMO framework 166 may be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which may be managed via an operation and maintenance interface (such as an O1 interface). For virtualized network elements, the SMO framework 166 may be configured to interact with a cloud computing platform (such as an open cloud (O-Cloud) 176) to perform network element lifecycle management (such as to instantiate virtualized network elements) via a cloud computing platform interface (such as an O2 interface). Such virtualized network elements may include, but are not limited to, CU 162, DU 170, RU 172, and near-RT RIC 164. In some specific implementations, the SMO framework 166 may communicate with hardware aspects of the 4G RAN (such as an open eNB (O-eNB) 174) via the O1 interface. Additionally, in some specific implementations, the SMO framework 166 may communicate directly with one or more RUs 172 via the O1 interface. The SMO framework 166 may also include a non-RT RIC 168 configured to support the functionality of the SMO framework 166 .
[0084] The non-RT RIC 168 may be configured to include logic functions that enable non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the near-RT RIC 164. The non-RT RIC 168 may be coupled to or in communication with the near-RT RIC 164 (such as via an A1 interface). The near-RT RIC 164 may be configured to include logic functions that enable near-real-time control and optimization of RAN elements and resources via data collection and actions through an interface (such as via an E2 interface) that connects one or more CUs 162, one or more DUs 170, or both, and the O-eNB with the near-RT RIC 164.
[0085] In some implementations, in order to generate an AI / ML model to be deployed in the near-RT RIC 164, the non-RT RIC 168 may receive parameters or external enrichment information from an external server. Such information may be utilized by the near-RT RIC 164 and may be received from a non-network data source or from a network function at the SMO framework 166 or the non-RT RIC 168. In some examples, the non-RT RIC 168 or the near-RT RIC 164 may be configured to tune RAN behavior or performance. For example, the non-RT RIC 168 may monitor long-term trends and patterns of performance and employ AI / ML models to perform corrective actions through the SMO framework 166 (such as via reconfiguration of O1) or via the creation of RAN management policies (such as A1 policies).
[0086] Various embodiments may be implemented on a number of single-processor and multi-processor computer systems, including system-on-a-chip (SoC) or system-in-package (SiP). Figure 2 is a component block diagram illustrating an example computing and wireless modem system 200 suitable for implementing any of the various embodiments. The various embodiments may be implemented on a number of single-processor and multi-processor computer systems, including SoCs or SiPs.
[0087] refer to Figure 1A to Figure 2 , the illustrated example wireless device 200 (which may be a system-in-package in some embodiments) includes two SoCs 202, 204 coupled to a clock 206, a voltage regulator 208, at least one subscriber identity module (SIM) 268 and / or a SIM interface and a wireless transceiver 266, which is configured to send and receive wireless communications to and from network wireless devices (such as base stations 110, wireless computing devices 120, vehicles 152b, and network devices 189) via an antenna (not shown). In some embodiments, the first SoC 202 operates as a central processing unit (CPU) of the wireless device, which executes instructions of software applications by performing arithmetic, logic, control, and input / output (I / O) operations specified by the instructions of the software application. In some embodiments, the second SoC 204 may operate as a dedicated processing unit. For example, the second SoC 204 may operate as a dedicated 5G processing unit responsible for managing high-capacity, high-speed (e.g., 5 Gbps, etc.) and / or ultra-high frequency short wavelength (e.g., 28 GHz millimeter wave spectrum, etc.) communications.
[0088] The first SoC 202 may include a digital signal processor (DSP) 210, a modem processor 212, a graphics processor 214, an application processor (AP) 216, one or more coprocessors 218 (e.g., vector coprocessors) connected to one or more of these processors, memory 220, custom circuits 222, system components and resources 224, interconnects / bus modules 226, one or more temperature sensors 230, a thermal management unit 232, and a thermal power envelope (TPE) component 234. The second SoC 204 may include a 5G modem processor 252, a power management unit 254, an interconnect / bus module 264, multiple mmWave transceivers 256, memory 258, and various additional processors 260 (such as an application processor, a packet processor, etc.).
[0089] Each processor 210, 212, 214, 216, 218, 252, 260 may include one or more cores, and each processor / core may perform operations independently of other processors / cores. For example, the first SoC 202 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., MICROSOFT WINDOWS10). In addition, any or all of the processors 210, 212, 214, 216, 218, 252, 260 may be included as part of a processor cluster architecture (e.g., a synchronous processor cluster architecture, an asynchronous or heterogeneous processor cluster architecture, etc.).
[0090] The first SoC 202 and the second SoC 204 may include various system components, resources, and custom circuits for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations, such as decoding data packets and processing encoded audio and video signals for rendering in a web browser. For example, the system components and resources 224 of the first SoC 202 may include power amplifiers, voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components used to support processors and software clients running on the wireless device. The system components and resources 224 and / or custom circuits 222 may also include circuits for interfacing with peripheral devices (such as cameras, electronic displays, wireless communication devices, external memory chips, etc.).
[0091] The first SoC 202 and the second SoC 204 may communicate via an interconnect / bus module 250. The various processors 210, 212, 214, 216, 218 may be interconnected to one or more memory elements 220, system components and resources 224, and custom circuits 222, and a thermal management unit 232 via an interconnect / bus module 226. Similarly, the processor 252 may be interconnected to a power management unit 254, a millimeter wave transceiver 256, a memory 258, and various additional processors 260 via an interconnect / bus module 264. The interconnect / bus modules 226, 250, 264 may include an array of reconfigurable logic gates and / or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communications may be provided by an advanced interconnect, such as a high-performance network on chip (NoC).
[0092] The first SoC 202 and / or the second SoC 204 may also include an input / output module (not illustrated) for communicating with resources external to the SoC, such as a clock 206, a voltage regulator 208, one or more wireless transceivers 266, and at least one SIM 268 and / or a SIM interface (i.e., an interface for receiving one or more SIM cards). Resources external to the SoC (e.g., clock 206, voltage regulator 208) may be shared by two or more of the internal SoC processors / cores. At least one SIM 268 (or one or more SIM cards coupled to one or more SIM interfaces) may store information supporting multiple subscriptions (including a first 5G NR subscription and a second 5G NR subscription, etc.).
[0093] In addition to the example system-level package 200 discussed above, various embodiments may also be implemented in a variety of computing systems that may include a single processor, multiple processors, a multi-core processor containing two or more independent processing cores (e.g., central processing unit (CPU) cores, Internet protocol (IP) cores, graphics processor unit (GPU) cores, etc.), or any combination thereof.
[0094] Figure 3 is a component block diagram illustrating an example system 300 configured to establish secure device-to-device communications between a security subsystem and a network device according to some embodiments. Figures 1A to 3, the system 300 may include the security subsystem 180, one or more network devices 404 (e.g., vehicle 152b, wireless computing device 120, network device 189, second computing device 350), and external resources 418 (e.g., databases, network servers), which may communicate via a wireless communication network 424. The external resources 418 may include information sources external to the system 300, external entities participating with the system 300, or other resources. In some implementations, some or all of the functionality attributed herein to the external resources 418 may be provided by resources included in the system 300. The system 300 may include multiple hardware, software, and / or firmware components that operate together to provide the functionality attributed herein to the processor 422.
[0095] The security subsystem 180 may include electronic memory 420, which may be configured to store information related to the functionality implemented by the data set replication module 430, the CRC generation module 432, the ring descriptor generator module 434, the ring descriptor update module 436, the memory mapping module 438, the CRC type identification module 440, the CRC type enabling module 442, the send / receive module 444, and any other instruction modules.
[0096] Electronic storage 420 may include non-transitory storage media that electronically stores information. Electronic storage 420 may include one or both of system storage provided integrally with system 200 (i.e., essentially non-removable) and / or removable storage that is removably connected to system 200 via, for example, a port (e.g., a universal serial bus (USB) port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). In various embodiments, electronic storage 420 may include one or more of charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drives, floppy disk drives, etc.), and / or other electronically readable storage media. Electronic storage 420 may include one or more virtual storage resources (e.g., cloud storage, virtual private networks, and / or other virtual storage resources). Electronic storage 420 may store software algorithms, information determined by processor 422, and / or other information that enables system 200 to operate as described herein.
[0097] The security subsystem 180 may be configured by machine-readable instructions 406. The machine-readable instructions 406 may include one or more instruction modules. The instruction modules may include computer program modules. The instruction modules may include one or more of a data set replication module 430, a CRC generation module 432, a ring descriptor generator module 434, a ring descriptor update module 436, a memory mapping module 438, a CRC type identification module 440, a CRC type enabling module 442, a send / receive module 444, and other instruction modules (not illustrated). The security subsystem 180 may include a processor 422 configured to implement the machine-readable instructions 406 and corresponding modules.
[0098] Processor 422 may include one of a plurality of local processors that may be configured to provide information processing capabilities in system 200. Thus, processor 422 may include one or more of the following: a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Although processor 422 may be configured to provide information processing capabilities in system 200, processor 422 may include one or more of the following: a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and / or other mechanisms for electronically processing information. Figure 3 4. In some embodiments, processor 422 may include multiple processing units. These processing units may be physically located within the same device, or processor 422 may represent processing functionality of multiple devices distributed in system 200.
[0099] In some embodiments, the processor 422 executing the data set copy module 430 may be configured to copy the first data set received from the interface bus in the hardware of the copy engine to obtain a first data set copy. In some embodiments, the processor 422 executing the data set copy module 430 may be configured to copy the second data set received from the interface bus in the hardware of the copy engine to obtain a second data set copy. In some embodiments, the processor 422 executing the data set copy module 430 may be configured to copy the first data set in the hardware of the copy engine based on the first source data pointer. In some embodiments, the processor 422 executing the data set copy module 430 may be configured to copy the second data set based on the second source data pointer. In some embodiments, the processor 422 executing the data set copy module 430 may be configured to copy the third data set received from the interface bus in the hardware of the copy engine to obtain a third data set copy.
[0100] In some embodiments, the processor 422 executing the CRC generation module 432 may be configured to generate a first CRC value of the first data set copy via the first streaming CRC engine in the hardware of the replication engine, and in parallel generate a second CRC value of the second data set copy via the second streaming CRC engine in the hardware of the replication engine. In some embodiments, the processor 422 executing the CRC generation module 432 may be configured to generate a first CRC value of the first data set copy via the first streaming CRC engine based on a first CRC type indicating a first communication protocol. In some embodiments, the processor 422 executing the CRC generation module 432 may be configured to generate a second CRC value of the second data set copy via the second streaming CRC engine based on a second CRC type indicating a second communication protocol. In some embodiments, the processor 422 executing the CRC generation module 432 may be configured to generate a final CRC value via the first streaming CRC engine, wherein the final CRC value is generated using the third data set copy and the first CRC value.
[0101] In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a first source ring descriptor based on the first communication message, the first source ring descriptor including a first source data pointer indicating a memory location of the first data set. In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a second source ring descriptor based on the second communication message, the second source ring descriptor including a second source data pointer indicating a memory location of the second data set. In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a first state ring descriptor including a first CRC value and a first state bit. In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a second state ring descriptor including a second CRC value and a second state bit. In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a first destination ring descriptor including a first destination data pointer. In some embodiments, the processor 422 of the execution ring descriptor generator module 434 may be configured to generate a second destination ring descriptor including a second destination data pointer.
[0102] In some embodiments, the processor 422 executing the ring descriptor update module 436 may be configured to update the source ring descriptor, the state ring descriptor, and the destination ring descriptor, including updating the length bit, the aggregation bit, the source data pointer, the CRC value, and the destination data pointer. In some embodiments, the processor 422 executing the ring descriptor update module 436 may be configured to set a first status bit after generating a first CRC value, wherein sending a first streaming CRC message is performed in response to setting the first status bit. In some embodiments, the processor 422 executing the ring descriptor update module 436 may be configured to set a second status bit after generating a second CRC value, wherein sending a second streaming CRC message is performed in response to setting the second status bit.
[0103] In some embodiments, the processor 422 executing the memory mapping module 438 may be configured to allocate a range of memory locations and addresses using external memory or a memory subsystem embedded within the replication engine (e.g., firmware, DDR) for storing data structures such as ring descriptors and associated data including metadata.
[0104] In some embodiments, the processor 422 executing the CRC type identification module 440 may be configured to identify a CRC type associated with a CRC algorithm defined by a communication standard or protocol, where the CRC type is identifiable in metadata received from a network device external to the replication engine as part of the communication.
[0105] In some embodiments, the processor 422 executing the CRC type enabling module 442 may be configured to enable and control hardware circuitry within a streaming CRC engine of the replication engine to generate a CRC value for a data set based on a CRC type associated with the data set.
[0106] In some embodiments, the processor 422 executing the send / receive module 444 may be configured to send a first streaming CRC message including a first data set copy and a first CRC value to the processor of the computing device. In some embodiments, the processor 422 executing the send / receive module 444 may be configured to send a second streaming CRC message including a second data set copy and a second CRC value to the processor. In some embodiments, the processor 422 executing the send / receive module 444 may be configured to send a first streaming CRC message based on a first destination data pointer. In some embodiments, the processor 422 executing the send / receive module 444 may be configured to send a second streaming CRC message based on a second destination data pointer. In some embodiments, the processor 422 executing the send / receive module 444 may be configured to send a first streaming CRC message including a first data set copy, a third data set copy, and a final CRC value to the processor.
[0107] Processor 422 may execute modules 430 - 444 and / or other modules via software, hardware, firmware, or some combination of software, hardware, and / or firmware and / or other mechanisms for configuring processing capabilities on processor 422 .
[0108] The description of the functionality provided by different modules 430-444 is for illustrative purposes and is not intended to be limiting, as any of the modules 430-444 may provide more or less functionality than that described. For example, one or more of the modules 430-444 may be eliminated, and some or all of their functionality may be provided by other modules in the modules 430-444. For another example, the processor 422 may execute one or more additional modules that may perform some or all of the functionality attributed below to one of the modules 430-444.
[0109] Figure 4 is a block diagram of a replication engine including a streaming CRC engine according to various embodiments. Figures 1A to 4 , the replication engine 190 may include any number "N" of hardware-based streaming CRC engines 192. For example, the replication engine 190 may include a first streaming CRC engine 192-1, a second streaming CRC engine 192-2, an "Nth" streaming CRC engine 192-N, and any number of streaming CRC engines (not illustrated) between the second streaming CRC engine 192-2 and the Nth streaming CRC engine 192-N. The replication engine 190 may be a module in a security subsystem (e.g., 180) that replicates data sets during data transmission (i.e., receiving and sending) for all types of communication protocols (including Ethernet, CAN, serial transmission, SD, DDR, BLE, etc.). An interface bus (e.g., Advanced eXtensible Interface (AXI), interconnect / bus module 226, 264) may connect the streaming CRC engines 192 of the replication engine 190 to a processor (e.g., 164) within the security subsystem.
[0110] The replication engine 190 may calculate or otherwise generate a CRC in a packet manner (i.e., conventional CRC calculation), in a stream manner in parallel channels, and / or in accordance with each CRC standard defined in a communication protocol implemented within a secure network (e.g., 150). Specifically, the streaming CRC engines 192 may each be associated with a separate channel, wherein a software-based ring descriptor indicates a source, status, and destination corresponding to a data set being processed by the streaming CRC engine 192 for error checking purposes. In other words, after the software generates and stores the source, status, and destination ring descriptors identifying the corresponding data set, the CRC calculation may be performed by the streaming CRC engine 192 (i.e., in hardware). For example, the replication engine 190 may divide, generate, or otherwise define a separate channel for each streaming CRC engine 192 in a memory mapped area (i.e., within a memory mapped subsystem (e.g., within the replication engine 190; within a DDR connected to or embedded in the replication engine 190; within the firmware of the replication engine 190)). As shown, there may be a number N of channels, which is equal to the number N of streaming CRC engines 192: Channel 1 may include a streaming CRC engine 192-1, a source ring descriptor 502-1, a state ring descriptor 504-1, and a destination ring descriptor 506-1; Channel 2 may include a streaming CRC engine 192-2, a source ring descriptor 502-2, a state ring descriptor 504-2, and a destination ring descriptor 506-2; Channel N may include a streaming CRC engine 192-N, a source ring descriptor 502-N, a state ring descriptor 504-N, and a destination ring descriptor 506-N; and any other channels may include equivalent ring descriptors. Therefore, each of the ring descriptors 502, 504, 506 may be a data structure stored in the firmware (i.e., the memory mapping subsystem) or in the memory mapping area of the replication engine 190.
[0111] Each channel N can handle multiple CRC types, or various CRC algorithms defined by wireless communication protocols and standards (e.g., AUTOSAR, WiFi, BLE, DigRF, etc.). Implementing separate channels N, each of which includes a hardware-based streaming CRC engine 192, can allow for parallel handling and calculation of multiple CRC types for various applications. For example, channel 1 can process a stream or stack of data sets for CRC check and verification, where each data set within the data set stack can be the same or different CRC type, while channel 2 is processing a different data set stack. In some embodiments, the order in which the CRC of each data set within the channel is calculated can be based on the order of arrival (i.e., when the streaming CRC engine 192 copies the data set). In some embodiments, the order in which the CRC of each data set within the channel is calculated can be based on priority (e.g., high priority DMA, low priority DMA, dynamic priority, fixed priority).
[0112] Figure 5 is a block diagram of a replication engine including a software-based ring descriptor according to various embodiments. Figures 1A to 5 , the replication engine 190 may generate a source ring descriptor 502 , a state ring descriptor 504 , and a destination ring descriptor 506 and store them in a memory mapped area in the firmware of the replication engine 190 .
[0113] Each ring descriptor may be stored in a stack of ring descriptors of the same type according to the order in which the data sets are received (i.e., from communicatively connected devices (e.g., network device 189, wireless computing device 120, vehicle 152b) via radio module 185). For example, each data set may be associated with source ring descriptor 502, state ring descriptor 504, and destination ring descriptor 506.
[0114] The replication engine 190 may generate a source ring descriptor 502, a state ring descriptor 504, and a destination ring descriptor 506 associated with each received data set based on metadata included in each data set. The replication engine 190 may store each ring descriptor of all data sets together in the firmware according to the ring descriptor type. For example, the source ring descriptors 502 (e.g., source ring descriptors [1], [2], [N]) of all data sets (e.g., data [1], [2], [N]) may be stored together in the firmware as a sequential stack, the state ring descriptors 504 (e.g., state ring descriptors [1], [2], [N]) of all data sets may be stored together in the firmware as a separate sequential stack, and the destination ring descriptors 506 (e.g., destination ring descriptors [1], [2], [N]) of all data sets (e.g., data [1], [2], [N]) may be stored together in the firmware as another sequential stack. Thus, as Figure 5 and Figure 6 , the source ring descriptors 502-1, 502-2, ..., 502-N in each individual channel (e.g., channels 1, 2, ..., N) can be aggregated and stored in the firmware of the replication engine 190 as a single stack, the state ring descriptors 504-1, 504-2, ..., 504-N in each individual channel can be aggregated and stored as a single stack, and the destination ring descriptors 506-1, 506-2, ..., 506-N in each individual channel can be aggregated and stored as a single stack. Each ring descriptor stack can be sequentially ordered according to the order in which the replication engine receives and / or replicates each data set within the replication engine buffer 194.
[0115] The replication engine 190 may receive or otherwise be notified and request one or more data sets regarding communications between the security subsystem 180 and any network device within the security network 150. The replication engine 190 may replicate any received data sets within a hardware-based replication engine buffer 194. For example, the replication engine 190 may receive and replicate any number of data sets (e.g., data [1], data [2], ..., data [N]) from one or more devices according to one or more communication protocols, each of which may require various CRC verification processes and algorithms. The data sets received from each network device may include metadata that the replication engine 190 can use to generate various ring descriptors.
[0116] In order to perform CRC calculations with respect to all data received by and sent from the security subsystem 160, the replication engine 190 may communicate a data set with a memory subsystem (e.g., DDR) within the security subsystem 160. When communicating a data set with the memory subsystem for the purpose of performing a CRC calculation on the data set, the firmware of the replication engine 190 may generate a source ring descriptor 502. Each generated source ring descriptor 502 may include a length bit (i.e., the length of the data set), an aggregation bit or aggregation bit (i.e., one or more bits indicating that the data set can be processed in a streaming parallel channel manner for CRC calculation, as opposed to a conventional packet-based CRC calculation), one or more bits indicating a CRC type (e.g., Type 1, Type 2, Type 3, etc., as defined by a communication protocol standard), and a source data pointer (i.e., a memory index).
[0117] The source data pointer may indicate a memory mapped address and / or a physical and / or virtual location at which a corresponding data set is stored in the memory subsystem. For example, a processor (e.g., 182) in communication with replication engine 190 may receive a communication including a data set from a device (e.g., network device 189) within secure network 150.
[0118] The processor may forward the communication to the replication engine 190, and the firmware of the replication engine 190 may generate a source ring descriptor 502 including a length bit, an aggregation bit, a CRC type, and a source data pointer during the process of transferring the data set to the memory subsystem. For example, the replication engine 190 may receive a first data set regarding a communication from a cellular phone via a BLE connection and replicate the first data set, and may receive a second data set regarding a communication from a wireless charging station via a WiFi connection.
[0119] The replication engine 190 may generate a first source ring descriptor having a CRC type indicating that the first data set should be and will be processed according to the BLE CRC processing standard, may subsequently generate a second source ring descriptor having a CRC type indicating that the second data set should be processed according to the WiFi CRC processing standard, and may subsequently load or otherwise store the first source ring descriptor and the second source ring descriptor as an ordered stack within the firmware.
[0120] The copy engine 190 may detect when a source ring descriptor 502 has been generated based on the data set. After the copy engine 190 detects the presence of the source ring descriptor 502 stored in the firmware within the pad length, aggregation, CRC type, and source data pointer bits, the copy engine 190 may locate the corresponding data set according to each source data pointer, and may copy the data set from the memory mapped area to the copy engine buffer 194. The copy engine 190 may simultaneously generate a destination ring descriptor and a state ring descriptor based on the data set copy while performing parallel CRC calculations on the data set copy via the streaming CRC engine 192. For example, the first data set and the second data set may be copied from the firmware address locations identified by the first source data pointer and the second data pointer of the first source ring descriptor (e.g., 502-1) and the second source ring descriptor (e.g., 502-2), respectively, thereby generating the first data set copy and the second data set copy stored by the copy engine buffer 194.
[0121] The replication engine 190 may generate a first state ring descriptor and a second state ring descriptor (e.g., 504-1, 504-2) and a first destination ring descriptor and a second destination ring descriptor (e.g., 506-1, 506-2) based on the first data set copy and the second data set copy, respectively. After replicating each data set to obtain a data set copy, the replication engine 190 may update the first destination ring descriptor with a length bit and a destination data pointer and update the second destination ring descriptor with a length bit and a destination data pointer (i.e., a memory index indicating where the CRC to be calculated / generated will be sent). The first state ring descriptor and the second state ring descriptor may be generated to include a length bit and an aggregation bit.
[0122] Once the data set is copied to the replication engine 190, the replication engine 190 can perform the following tasks in parallel (i.e., at the same or substantially the same time / within the same time window): (i) performing a first CRC calculation based on the CRC type of the first source ring descriptor via a first streaming CRC engine (e.g., 192-1); (ii) performing a second CRC calculation based on the CRC type of the second source ring descriptor via a second streaming CRC engine (e.g., 192-2).
[0123] After completing the CRC calculations for the first data set copy and / or the second data set copy, each of the corresponding state ring descriptors 504 may be updated based on each data set copy to include the final generated CRC. The first state ring descriptor and the second state ring descriptor may be updated according to the order in which the CRC calculations performed by the first streaming CRC engine and the second streaming CRC engine are completed. For example, the first streaming CRC engine may complete the CRC calculations for the first data set copy before the second streaming CRC engine completes the CRC calculations for the second data set copy. Therefore, the replication engine 190 may update the first state ring descriptor with the CRC of the generated first data set copy before updating the second state ring descriptor with the CRC of the generated second data set copy.
[0124] As another example, the second streaming CRC engine may complete the CRC calculation for the second data set copy before the first streaming CRC engine completes the CRC calculation for the first data set copy (e.g., the first streaming CRC engine may calculate the CRC according to a more stringent, more time-consuming standard). Therefore, the replication engine 190 may update the second state ring descriptor with the CRC generated for the second data set copy before updating the first state ring descriptor with the CRC generated for the first data set copy.
[0125] Figure 6 is a block diagram of a streaming CRC engine implemented within a channel of a replication engine according to various embodiments. Figures 1A to 6 , the streaming CRC engine 192 can be one of any number N of streaming CRC engines 192 of the replication engine 190.
[0126] Based on the metadata from the source ring descriptor, the streaming CRC engine 192 can calculate or otherwise generate a CRC for the data set copy. The metadata can include a CRC type that allows the streaming CRC engine 192 to enable the data set copy to be calculated according to the CRC type (i.e., the CRC protocol defined by the communication standard type).
[0127] A copy of the data set may be provided (i.e., via "Data stream_in") to a CRC circuit 604 (a hardware component, not illustrated) based on the metadata, thereby enabling or otherwise activating the hardware to process the copy of the data set. For example, the metadata may indicate CRC type 2 (e.g., BLE CRC protocol), and the CRC circuit 604 for CRC type 2 may be enabled via an "enable2" signal.
[0128] The data set copy may be streamed into the CRC circuit 604 for CRC type 2 calculation. After processing, the CRC data may be output to CRC_out and multiplexed (and / or reflected as necessary according to the AUTOSAR standard for CRC) to obtain the final CRC for the data set copy. The final CRC may then be updated in the corresponding state ring descriptor 504.
[0129] In some embodiments, the streaming CRC engine 192 may process more than one data set copy before obtaining a final CRC. For example, a first streaming CRC engine may process a sequence of more than one data set copy. This process of analyzing the CRCs of more than one data set copy in a row before obtaining a final CRC may also be performed in parallel with a second streaming CRC engine that processes a different sequence of more than one data set copy separately (i.e., as described in reference to FIG. 1 ). Figure 7 described above).
[0130] A group of two or more data set copies may be referred to as a data set stream, where each data set copy within the data set stream has a CRC calculated or generated sequentially and, depending on the CRC type, fed into the CRC circuit until the last data set copy of the data set stream is processed and a final CRC is calculated or otherwise generated. Thus, the streaming CRC engine 192 may calculate or otherwise generate a final CRC for several data set copies, which may be of the same CRC type or different CRC types.
[0131] A CRC is calculated for each data set, and a streaming CRC is calculated for multiple data sets linked to multiple source ring descriptors within a data set stream. The end of a data set stream (i.e., the last data set within a data set stream) may be indicated by an aggregation bit not being set in a source ring descriptor associated with the data set stream. One state descriptor and one CRC may be updated for multiple data sets forming a single data set stream. In contrast, if the communication protocol is a packet-based protocol, a CRC is generated for each data set, the aggregation bit is not set, and a one-to-one mapping is generated from a source ring descriptor to a state ring descriptor with each generated CRC.
[0132] For example, each data set copy within the data set stream may be fed into the CRC circuit 604 according to the CRC type and length defined by the metadata according to each source ring descriptor for each data set copy in the data set stream. For example, the data set stream may include a first data set copy and a second data set copy, each of which can be identified by a first source ring descriptor and a second ring descriptor, respectively. The first source ring descriptor may indicate that the first data set copy has a length of 56 bits, a CRC type 3 (e.g., WiFi), and an aggregation bit (i.e., indicating that the data set copy is part of the data set stream), and the second ring descriptor may indicate that the second data set copy has a length of 16 bits, a CRC type 2 (e.g., BLE), and an aggregation bit. Therefore, the metadata in the firmware of the replication engine 190 may enable a CRC type 3 of the CRC circuit 604 of the streaming CRC engine 192; and the first data set copy may be processed to determine the CRC. Since the first data set copy is part of the data set stream indicated by the aggregation bit, the first calculated or generated CRC value is multiplexed back into the CRC circuit 604 via the "feedback CRC" connection. The metadata in the firmware of the replication engine 190 may then enable CRC Type 2 of the CRC circuit 604 of the streaming CRC engine 192; and the second data set copy may be processed to determine the CRC and the feedback CRC value from the CRC calculation of the first data set copy. This process may be repeated until the last data set copy of the data set stream has a calculated or generated CRC, based on which a final CRC is determined.
[0133] Figure 7 is a block diagram illustrating a conventional packetized CRC message 700 for a 4K byte data payload transmitted across a bus. Assuming 32 bits of CRC overhead per packet, the packetized CRC message 700 may include a total number of bits according to the following formula: 4096 bits [data] + (64 packets x 32 bits of CRC per packet) = 4096 + 2048 = 150% of the payload. Therefore, if the CRC is handled in hardware, the conventional packetized CRC message 700 may include 100% of the payload data and 50% of the overhead due to the packetized CRC addition.
[0134] Figure 8 is a block diagram illustrating a streaming CRC message 800 for a 4K byte data payload transmitted across a bus according to various embodiments. Figures 1A to 8, assuming a 32-bit CRC, the streaming CRC message 800 may include a total number of bits according to the following formula: 4096 bits [data] + 32-bit CRC uploaded in software = 100% payload. Therefore, if the CRC is handled in hardware, the streaming CRC message 800 may include 100% payload data and a CRC checksum added in the data payload. The integrity of the CRC data can be ensured by offloading the CRC overhead to the source ring descriptor 502, state ring descriptor 504, and destination ring descriptor 506 in firmware while providing zero overhead in the payload due to the CRC addition. The streaming CRC message 800 with reduced overhead allows the data payload and corresponding CRC value to be sent more efficiently across the interface bus, thereby reducing the computing resources and time required for the receiving processor to unpack and utilize the streaming CRC message 800 compared to the packetized CRC message 700.
[0135] Fig. 9 is a block diagram illustrating an example of a data set flow 900 according to various embodiments. Figures 1A to 9 , data set flow 900 illustrates that multiple CRC data sets of different CRC types can be supported in a single channel. The data widths supported in data set flow 900 may include 64-bit, 56-bit, 48-bit, 40-bit, 32-bit, 24-bit, 16-bit, and 8-bit data widths. The protocols supported by data set flow 900 may include CRC-8-SAE data sharing protocol in vehicles, CRC-8-2F open security protocol, CRC-16 CCITT modem / Bluetooth / DigRF protocol, CRC-32P4 AUTOSAR security protocol, CRC-32 Ethernet IEEE802.3, and any other known CRC protocol.
[0136] Fig. 10A is a process flow diagram of an example method 1000a that may be executed by a processor of a receiving wireless device for generating a cyclic redundancy check (CRC) in a secure network (eg, secure network 150) according to various embodiments. FIG. 10B to FIG. 10E is a process flow diagram of example operations 1000b-1000e that may be performed as part of a method 1000a for generating a CRC in a secure network, according to some embodiments. Figures 1A to 10E, method 1000a and operations 1000b-1000e may be performed by a replication engine (e.g., processor 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a computing device (e.g., security subsystem 180, wireless computing device 120, vehicle 152b, network device 189). In some embodiments, the replication engine (e.g., processor 182, 210, 212, 214, 216, 218, 252, 260, 422, auxiliary engine 190) may be configured to perform operations via processor-executable instructions stored in a non-transitory processor-readable medium (e.g., 220, 258, 420). The components for performing the operations of method 1000a and each of operations 1000b-1000e may be processors of systems 100, 160, 200, 300, and 1100, such as processors 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190, and / or as described in reference Figures 1A to 6 and Figures 8 to 10E Similar to those described above.
[0137] In block 1002, a copy engine of a computing device may perform operations including copying in hardware of the copy engine a first data set received from an interface bus to obtain a first data set copy. For example, a copy engine (e.g., copy engine 190) may receive a communication including a data set across an interface bus (e.g., AXI, interconnect / bus module 226, 264), and may copy the data set to a copy engine buffer (e.g., copy engine buffer 194) in hardware of the copy engine. In some embodiments, copying in hardware of the copy engine the first data set received from the interface bus to obtain a first data set copy may also include copying the first data set based on a first source data pointer (i.e., of a first source ring descriptor). A component for performing the operations of block 1002 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, copy engine 190) of a security subsystem (e.g., 180) that executes a data set copy module 430.
[0138] In block 1004, a copy engine of the computing device may perform operations including copying in hardware of the copy engine a second data set received from the interface bus to obtain a copy of the second data set. For example, a copy engine (e.g., copy engine 190) may receive a communication including a data set across an interface bus (e.g., AXI, interconnect / bus module 226, 264), and may copy the data set to a copy engine buffer (e.g., copy engine buffer 194) in hardware of the copy engine. In some embodiments, copying in hardware of the copy engine the second data set received from the interface bus to obtain a copy of the second data set may also include copying the second data set based on a second source data pointer (i.e., a pointer to a second source ring descriptor). A component for performing the operations of block 1004 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, copy engine 190) of a security subsystem (e.g., 180) that executes a data set copy module 430.
[0139] In block 1006, a replication engine of a computing device may perform operations including generating a first CRC value for a first data set copy via a first streaming CRC engine (e.g., 192-1) in hardware of the replication engine, and generating a second CRC value for a second data set copy in parallel via a second streaming CRC engine (e.g., 192-2) in hardware of the replication engine (e.g., 190). The parallel temporal generation of the first CRC value and the second CRC value may be performed in separate channels (e.g., channel 1, channel 2), each channel including a set and / or stack of ring descriptors (e.g., 502, 504, 506) and a streaming CRC engine 192. Means for performing the operations of block 1006 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) executing a CRC generation module 432.
[0140] In some embodiments, generating a first CRC value for the first data set copy via the first streaming CRC engine in block 1006 may also include generating a first CRC value for the first data set copy via the first streaming CRC engine based on a first CRC type indicative of a first communications protocol.
[0141] In some embodiments, generating a second CRC value for the copy of the second data set via the second streaming CRC engine in block 1006 may also include generating a second CRC value for the copy of the second data set via the second streaming CRC engine based on a second CRC type indicating a second communication protocol. In some embodiments, the first CRC type and the second CRC type may be different CRC types or may be the same CRC type.
[0142] In some embodiments, generating a first CRC value for a first data set copy via a first streaming CRC engine in the hardware of the replication engine in box 1006 and generating a second CRC value for a second data set copy via a second streaming CRC engine in the hardware of the replication engine in parallel may also include generating a final CRC value via the first streaming CRC engine, wherein the final CRC value may be generated using the third data set copy and the first CRC value.
[0143] In block 1008, a replication engine (e.g., 190) of a computing device may perform operations including sending a first streaming CRC message including a first data set copy and a first CRC value to a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422) of a computing device (e.g., security subsystem 180). In some embodiments, sending the first streaming CRC message may further include sending the first streaming CRC message based on a first destination data pointer (e.g., of the first destination ring descriptor 506-1). In some embodiments, sending the first streaming CRC message to the processor may further include sending the first streaming CRC message including a first data set copy, a third data set copy, and a final CRC value to the processor. Means for performing the operations of block 1008 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) executing a send / receive module 444.
[0144] In block 1010, a replication engine (e.g., 190) of a computing device may perform operations including sending a second streaming CRC message including a copy of a second data set and a second CRC value to a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422). In some embodiments, sending the second streaming CRC message may also include sending the second streaming CRC message based on a second destination data pointer (e.g., of the second destination ring descriptor 506-2). Means for performing the operations of block 1010 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) executing a send / receive module 444.
[0145] Fig. 10B Operations 1000b that may be performed as part of method 1000a for generating a CRC in a secure network are illustrated according to some embodiments. Figures 1A to 10B, a replication engine (e.g., 190) of a computing device (e.g., security subsystem 180) may perform operations including generating a first source ring descriptor (e.g., 502-1) including a first source data pointer indicating a memory location of a first data set based on the first communication message in block 1012. In some embodiments, the first source ring descriptor may include a first length bit indicating a length of the first data set, a first aggregation bit indicating that the first CRC value is generated as part of a first data set stream including a plurality of data sets, and a first CRC type indicating a first communication protocol. The means for performing the operations of block 1012 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) executing a ring descriptor generation module 434.
[0146] In block 1014, a replication engine (e.g., 190) of a computing device (e.g., security subsystem 180) may perform operations including generating a second source ring descriptor (e.g., 502-2) including a second source data pointer indicating a memory location of a second data set based on the second communication message. In some embodiments, the second source ring descriptor may include a second length bit indicating a length of the second data set, a second aggregation bit indicating that the second CRC value is generated as part of a second data set stream including a plurality of data sets, and a second CRC type indicating a second communication protocol. A component for performing the operations of block 1014 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) executing a ring descriptor generation module 434.
[0147] After the operations in block 1014 , the replication engine may perform the operations in block 1002 as described.
[0148] Fig. 10C Operations 1000c that may be performed as part of method 1000a for generating a CRC in a secure network are illustrated in accordance with some embodiments. FIG. 1A to FIG. 10C After the operations in block 1006, a replication engine (e.g., 190) of a computing device (e.g., security subsystem 180) may perform operations including generating a first state ring descriptor (e.g., 504-1) including a first CRC value and a first state bit in block 1016. Means for performing the operations of block 1016 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) executing ring descriptor generation module 434.
[0149] In block 1018, a replication engine (e.g., 190) of a computing device (e.g., security subsystem 180) may perform operations including generating a second state ring descriptor (e.g., 504-2) including a second CRC value and a second state bit. Means for performing the operations of block 1018 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) executing ring descriptor generation module 434.
[0150] In block 1020, a replication engine (e.g., 190) of a computing device (e.g., security subsystem 180) may perform operations including setting a first status bit after generating a first CRC value, wherein sending a first streaming CRC message may be performed in response to setting the first status bit. Means for performing the operations of block 1020 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) executing a ring descriptor update module 436.
[0151] In block 1022, a replication engine (e.g., 190) of a computing device (e.g., security subsystem 180) may perform operations including setting a second status bit after generating the second CRC value, wherein sending the second streaming CRC message is performed in response to setting the second status bit. Means for performing the operations of block 1022 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) executing ring descriptor update module 436.
[0152] The order of operations described with reference to blocks 1002-1022 is exemplary only and not exhaustive. For example, the operations described with reference to blocks 1016 and 1018 may be performed before, during, or after the operations described with reference to block 1006.
[0153] Following the operations in block 1022 , the replication engine may perform the operations in block 1008 as described.
[0154] Fig. 10D Operations 1000d that may be performed as part of method 1000a for generating a CRC in a secure network are illustrated in accordance with some embodiments. FIG. 1A to FIG. 10D, after the operations in block 1004, a replication engine (e.g., 190) of a computing device (e.g., security subsystem 180) may perform operations including generating a first destination ring descriptor (e.g., 506-1) including a first destination data pointer in block 1024. Means for performing the operations of block 1024 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of the security subsystem (e.g., 180) executing the ring descriptor generation module 434.
[0155] In block 1026, a replication engine (e.g., 190) of a computing device (e.g., security subsystem 180) may perform operations including generating a second destination ring descriptor (e.g., 506-2) including a second destination data pointer. Means for performing the operations of block 1026 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, replication engine 190) of a security subsystem (e.g., 180) executing a ring descriptor generation module 434.
[0156] After the operations in block 1026 , the replication engine may perform the operations in block 1006 as described.
[0157] Fig. 10E Operations 1000e that may be performed as part of method 1000a for generating a CRC in a secure network are illustrated in accordance with some embodiments. Figures 1A to 10E After the operations in block 1004, a copy engine (e.g., 190) of a computing device (e.g., security subsystem 180) may perform operations including copying the third data set received from the interface bus in hardware of the copy engine (e.g., copy engine buffer 194) to obtain a third data set copy. Means for performing the operations of block 1028 may include a processor (e.g., 182, 210, 212, 214, 216, 218, 252, 260, 422, copy engine 190) of a security subsystem (e.g., 180) executing a data set copy module 430.
[0158] Following the operations in block 1028 , the replication engine may perform the operations in block 1006 as described.
[0159] Various embodiments can be implemented on various network devices, examples of which are Fig.11 1 is illustrated in the form of a network computing device 1100 used as a network element (such as a base station) of a communication network. Such a network computing device may include at least Fig.11 Refer to Figures 1 to Fig.11, the network computing device 1100 may generally include a processor 1101 coupled to a volatile memory 1102 and a large capacity non-volatile memory such as a disk drive 1103. The network computing device 1100 may also include a peripheral memory access device such as a floppy disk drive, a compact disk (CD) or a digital video disk (DVD) drive 1106 coupled to the processor 1101. The network computing device 1100 may also include a network access port 1104 (or interface) coupled to the processor 1101 for establishing a data connection with a network (such as the Internet and / or a local area network coupled to other system computers and servers). The network computing device 1100 may include one or more antennas 1107 for sending and receiving electromagnetic radiation, which may be connected to a wireless communication link. The network computing device 1100 may include additional access ports such as USB, FireWire, Thunderbolt, etc. for coupling to peripheral devices, external memory or other devices.
[0160] The processor of the wireless network computing device 1100 can be any programmable microprocessor, microcomputer, or one or more multi-processor chips that can be configured by software instructions (applications) to perform various functions, including the functions of the various embodiments described below. In some wireless devices, multiple processors may be provided, such as one processor dedicated to wireless communication functions within SoC 204 and one processor dedicated to running other applications within SoC 202. Typically, software applications can be stored in memory 1102, 1103, which are then accessed and loaded into the processor. The processor may include internal memory sufficient to store application software instructions.
[0161] Specific implementation examples are described in the following paragraphs. Although some of the specific implementation examples in the following specific implementation examples are described in terms of example methods, further example implementations may include: the example methods discussed in the following paragraphs implemented by a computing device, the computing device including a processor configured with processor-executable instructions for performing the operations of the methods of the following specific implementation examples; the example methods discussed in the following paragraphs implemented by a computing device including components for performing the functions of the methods of the following specific implementation examples; and the example methods discussed in the following paragraphs may be implemented on a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause the processor of the computing device to perform the operations of the methods of the following specific implementation examples.
[0162] Embodiment 1: A method for generating a cyclic redundancy check (CRC) in a secure network, performed by a replication engine of a computing device, the method comprising: replicating a first data set received from an interface bus in the hardware of the replication engine to obtain a first data set copy; replicating a second data set received from the interface bus in the hardware of the replication engine to obtain a second data set copy; generating a first CRC value for the first data set copy via a first streaming CRC engine in the hardware of the replication engine, and in parallel generating a second CRC value for the second data set copy via a second streaming CRC engine in the hardware of the replication engine; sending a first streaming CRC message including the first data set copy and the first CRC value to a processor of the computing device; and sending a second streaming CRC message including the second data set copy and the second CRC value to the processor.
[0163] Embodiment 2: According to the method described in Embodiment 1, the method further includes: generating a first source ring descriptor based on a first communication message, the first source ring descriptor including a first source data pointer indicating a memory location of the first data set; and generating a second source ring descriptor based on a second communication message, the second source ring descriptor including a second source data pointer indicating a memory location of the second data set.
[0164] Embodiment 3: A method according to embodiment 1 or 2, wherein copying the first data set received from the interface bus in the hardware of the replication engine to obtain the first data set copy also includes copying the first data set based on the first source data pointer, and copying the second data set received from the interface bus in the hardware of the replication engine to obtain the second data set copy also includes copying the second data set based on the second source data pointer.
[0165] Embodiment 4: A method according to any one of Embodiments 1 to 3, wherein the first source ring descriptor includes a first length bit indicating the length of the first data set, a first aggregation bit indicating that the first CRC value is generated as part of a first data set stream including multiple data sets, and a first CRC type indicating a first communication protocol, and wherein the second source ring descriptor includes a second length bit indicating the length of the second data set, a second aggregation bit indicating that the second CRC value is generated as part of a second data set stream including multiple data sets, and a second CRC type indicating a second communication protocol.
[0166] Embodiment 5: A method according to any one of embodiments 1 to 4, wherein generating the first CRC value of the first data set copy via the first streaming CRC engine also includes generating the first CRC value of the first data set copy via the first streaming CRC engine based on a first CRC type indicating a first communication protocol, and generating the second CRC value of the second data set copy via the second streaming CRC engine also includes generating the second CRC value of the second data set copy via the second streaming CRC engine based on a second CRC type indicating a second communication protocol.
[0167] Embodiment 6: The method according to embodiment 5, wherein the first CRC type and the second CRC type are different CRC types.
[0168] Embodiment 7: According to the method described in any one of Embodiments 1 to 6, the method further includes: generating a first state ring descriptor including the first CRC value and a first status bit; generating a second state ring descriptor including the second CRC value and a second status bit; setting the first status bit after generating the first CRC value, wherein sending the first streaming CRC message is performed in response to setting the first status bit; and setting the second status bit after generating the second CRC value, wherein sending the second streaming CRC message is performed in response to setting the second status bit.
[0169] Embodiment 8: According to the method described in any one of Embodiments 1 to 7, the method further includes: generating a first destination ring descriptor including a first destination data pointer; and generating a second destination ring descriptor including a second destination data pointer, wherein sending the first stream CRC message further includes sending the first stream CRC message based on the first destination data pointer, and wherein sending the second stream CRC message further includes sending the second stream CRC message based on the second destination data pointer.
[0170] Embodiment 9: According to the method described in any one of Embodiments 1 to 8, the method further includes: copying the third data set received from the interface bus in the hardware of the replication engine to obtain a third data set copy, wherein the first CRC value of the first data set copy is generated in the hardware of the replication engine via the first streaming CRC engine, and the second CRC value of the second data set copy is generated in the hardware of the replication engine via the second streaming CRC engine in parallel, and further includes generating a final CRC value via the first streaming CRC engine, wherein the final CRC value is generated using the third data set copy and the first CRC value, and wherein sending the first streaming CRC message to the processor further includes sending the first streaming CRC message including the first data set copy, the third data set copy and the final CRC value to the processor.
[0171] As used in this application, the terms "component", "module", "system", etc. are intended to include computer-related entities, such as but not limited to hardware, firmware, a combination of hardware and software, software, or software being executed, which are configured to perform specific operations or functions. For example, a component can be, but is not limited to, a process, a processor, an object, an executable file, an execution thread, a program, and / or a computer running on a processor. By way of example, both an application running on a computing device and a circuit (e.g., SoC) of a computing device can be referred to as a component. One or more components may reside in a process and / or an execution thread, and a component may be located on a processor or core and / or distributed between two or more processors or cores. In addition, these components may be executed from various non-transient computer-readable media having various instructions and / or data structures stored thereon. Components can communicate via local and / or remote processes, function or procedure calls, electronic signals, data packets, memory reads / writes, and other known network, computer, processor, and / or process-related communication methods.
[0172] A variety of different cellular and mobile communication services and medium-range and short-range and / or near-field communication standards are available or contemplated in the future, all of which may enable and benefit from the various implementations. Such services and standards include, for example, the 3rd Generation Partnership Project (3GPP), Long Term Evolution (LTE) system, 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G), Global System for Mobile Communications (GSM), Universal Mobile Telecommunications System (UMTS), 3GSM, General Packet Radio Service (GPRS), Code Division Multiple Access (CDMA) system (e.g., cdmaOne, CDMA1020TM), Enhanced Data Rates for GSM Evolution (EDGE), Advanced Mobile Phone System (AMPS), Digital AMPS (IS-136 / TDMA), Evolution-Data Optimized (EV-DO), Digital Enhanced Cordless Telecommunications (DECT), Worldwide Interoperability for Microwave Access (WiMAX), Wireless Local Area Network (WLAN), Wi-Fi Protected Access I and II (WPA, WPA2), and Integrated Digital Enhanced Network (iDEN), Bluetooth, BLE, WiFi, and DigRF. Each of these technologies involves, for example, the transmission and reception of voice, data, signaling, and / or content messages. It should be understood that any references to terminology and / or technical details related to individual telecommunication standards or technologies are for illustrative purposes only and are not intended to limit the scope of the claims to a particular communication system or technology unless specifically recited in the claim language.
[0173] The various embodiments illustrated and described are provided merely as examples illustrating various features of the claims. However, the features shown and described with respect to any given embodiment are not necessarily limited to the associated embodiment, and may be used or combined with other embodiments shown and described. Furthermore, the claims are not intended to be limited to any one example embodiment. For example, one or more operations of methods 1000a-1000e may replace or be combined with one or more operations of methods 1000a-1000e.
[0174] The foregoing method descriptions and process flow charts are provided only as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order given. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter," "then," "next," etc. are not intended to limit the order of operations; these words are used to guide the reader through the description of the method. In addition, any reference to a claim element in the singular form (e.g., a reference using the article "a," "an," or "the") should not be interpreted as limiting the element to the singular.
[0175] The various exemplary logic blocks, modules, components, circuits, and algorithmic operations described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various exemplary components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. The technician may implement the described functionality in different ways for each specific application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.
[0176] The hardware for implementing the various exemplary logic components, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed with a general purpose processor, digital signal processor (DSP), application specific integrated circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic components, discrete hardware components, or any combination thereof designed to perform the functions described herein. Although a general purpose processor may be a microprocessor, in an alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of receiver smart objects, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuits specific to a given function.
[0177] In one or more embodiments, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or codes on a non-transient computer-readable storage medium or a non-transient processor-readable storage medium. The operation of the method or algorithm disclosed herein may be implemented in a processor-executable software module or a processor-executable instruction, which may reside on a non-transient computer-readable or processor-readable storage medium. A non-transient computer-readable or processor-readable storage medium may be any storage medium accessible by a computer or processor. By way of example and without limitation, such non-transient computer-readable or processor-readable storage media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage device, magnetic disk storage device or other magnetic storage smart object, or any other medium that can be used to store the required program code in the form of an instruction or data structure and can be accessed by a computer. Disks and optical disks as used herein include compact discs (CDs), laser discs, optical disks, digital versatile discs (DVDs), floppy disks, and blue discs, wherein disks generally reproduce data magnetically, and optical discs reproduce data optically with lasers. The above combinations are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable storage medium and / or computer-readable storage medium, which may be incorporated into a computer program product.
[0178] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein, but should be accorded the broadest scope consistent with the following claims and the principles and novel features disclosed herein.
Claims
1. A computing device for use in a secure network, the computing device comprising: Interface bus; A replication engine coupled to the interface bus, the replication engine comprising: a replication engine buffer in hardware of the replication engine, the replication engine buffer configured to store the data set as a data set replica; a first stream cyclic redundancy check (CRC) engine; and Second stream CRC engine, The replication engine is configured as follows: copying a first data set received from the interface bus to the copy engine buffer as a first data set copy; copying a second data set received from the interface bus to the copy engine buffer as a second data set copy; generating, using the first streaming CRC engine, a first CRC value for the first data set copy; generating a second CRC value for the second data set copy using the second streaming CRC engine; and A first streaming CRC message including the copy of the first data set and the first CRC value and a second streaming CRC message including the copy of the second data set and the second CRC value are sent to a processor of the computing device via the interface bus.
2. The computing device of claim 1, wherein the replication engine is further configured to generate the second CRC value for the second data set copy using the second streaming CRC engine in parallel with generating the first CRC value using the first streaming CRC engine.
3. The computing device of claim 1 , wherein the replication engine further comprises: A memory mapping subsystem, the memory mapping subsystem being configured to: generating a first source ring descriptor based on the first communication message, the first source ring descriptor comprising a first source data pointer indicating a memory location of the first data set; as well as A second source ring descriptor is generated based on the second communication message, the second source ring descriptor including a second source data pointer indicating a memory location of the second data set.
4. The computing device of claim 3, wherein the replication engine is further configured to: copying the first data set to the copy engine buffer based on the first source data pointer, and The second data set is copied to the copy engine buffer based on the second source data pointer.
5. The computing device of claim 3, wherein the replication engine is further configured such that: the first source ring descriptor comprising first length bits indicating a length of the first data set, first aggregation bits indicating that the first CRC value was generated as part of a first data set stream including a plurality of data sets, and a first CRC type indicating a first communication protocol; and The second source ring descriptor includes second length bits indicating a length of the second data set, second aggregation bits indicating that the second CRC value is generated as part of a second data set stream including a plurality of data sets, and a second CRC type indicating a second communication protocol.
6. The computing device of claim 1 , wherein the replication engine is further configured to: generating, using the first streaming CRC engine, the first CRC value for the copy of the first data set based on a first CRC type indicative of a first communications protocol, and generating, using the second streaming CRC engine, the second CRC value for the copy of the second data set based on a second CRC type indicative of a second communication protocol, The first CRC type and the second CRC type are different CRC types.
7. The computing device of claim 1, wherein the replication engine further comprises: A memory mapping subsystem, the memory mapping subsystem being configured to: Generate a first state ring descriptor including the first CRC value and a first state bit; generating a second state ring descriptor including the second CRC value and a second state bit; setting the first status bit in response to the first streaming CRC engine generating the first CRC value; as well as setting the second status bit in response to the second streaming CRC engine generating the second CRC value, The replication engine is further configured to: sending the first streaming CRC message via the interface bus in response to the memory mapping subsystem setting the first status bit; and The second streaming CRC message is sent via the interface bus in response to the memory mapping subsystem setting the second status bit.
8. The computing device of claim 1, further comprising: A memory mapping subsystem, the memory mapping subsystem being configured to: generating a first destination ring descriptor including a first destination data pointer; as well as generating a second destination ring descriptor including a second destination data pointer, wherein the copy engine is further configured to: sending the first streaming CRC message via the interface bus based on the first destination data pointer; and The second streaming CRC message is sent via the interface bus based on the second destination data pointer.
9. The computing device of claim 1 , wherein the replication engine is further configured to: copying a third data set received from the interface bus to the copy engine buffer as a third data set copy; using the first streaming CRC engine to generate a final CRC value using the third data set copy and the first CRC value; as well as The first streaming CRC message including the first data set copy, the third data set copy, and the final CRC value is sent to the processor via the interface bus.
10. A method for generating a cyclic redundancy check (CRC) in a secure network, performed by a replication engine of a computing device, the method comprising: replicating, in hardware of the replication engine, a first data set received from the interface bus to obtain a first data set copy; replicating, in hardware of the replication engine, a second data set received from the interface bus to obtain a second data set copy; generating a first CRC value for the first data set copy via a first streaming CRC engine in the hardware of the replication engine, and in parallel generating a second CRC value for the second data set copy via a second streaming CRC engine in the hardware of the replication engine; sending a first streaming CRC message including the first data set copy and the first CRC value to a processor of the computing device; and A second streaming CRC message including a copy of the second data set and the second CRC value is sent to the processor.
11. The method according to claim 10, further comprising: generating a first source ring descriptor based on the first communication message, the first source ring descriptor comprising a first source data pointer indicating a memory location of the first data set; as well as A second source ring descriptor is generated based on the second communication message, the second source ring descriptor including a second source data pointer indicating a memory location of the second data set.
12. The method according to claim 11, wherein: Copying the first data set received from the interface bus in hardware of the copy engine to obtain the first data set copy further comprises copying the first data set based on the first source data pointer, and Copying the second data set received from the interface bus in hardware of the copy engine to obtain the second data set copy further includes copying the second data set based on the second source data pointer.
13. A method according to claim 11, wherein the first source ring descriptor includes first length bits indicating the length of the first data set, first aggregation bits indicating that the first CRC value is generated as part of a first data set stream including multiple data sets, and a first CRC type indicating a first communication protocol, and wherein the second source ring descriptor includes second length bits indicating the length of the second data set, second aggregation bits indicating that the second CRC value is generated as part of a second data set stream including multiple data sets, and a second CRC type indicating a second communication protocol.
14. The method of claim 10, wherein: Generating the first CRC value of the first data set copy via the first streaming CRC engine also includes generating the first CRC value of the first data set copy via the first streaming CRC engine based on a first CRC type indicating a first communication protocol, and generating the second CRC value of the second data set copy via the second streaming CRC engine also includes generating the second CRC value of the second data set copy via the second streaming CRC engine based on a second CRC type indicating a second communication protocol.
15. The method of claim 14, wherein the first CRC type and the second CRC type are different CRC types.
16. The method according to claim 10, further comprising: Generate a first state ring descriptor including the first CRC value and a first state bit; generating a second state ring descriptor including the second CRC value and a second state bit; setting the first status bit after generating the first CRC value, wherein sending the first streaming CRC message is performed in response to setting the first status bit; and The second status bit is set after generating the second CRC value, wherein sending the second streaming CRC message is performed in response to setting the second status bit.
17. The method according to claim 10, further comprising: generating a first destination ring descriptor including a first destination data pointer; as well as A second destination ring descriptor is generated including a second destination data pointer, wherein: Sending the first streaming CRC message further comprises sending the first streaming CRC message based on the first destination data pointer, and Sending the second streaming CRC message further includes sending the second streaming CRC message based on the second destination data pointer.
18. The method according to claim 10, further comprising: replicating in hardware of the replication engine a third data set received from the interface bus to obtain a third data set replica, wherein generating the first CRC value of the first data set copy via the first streaming CRC engine in the hardware of the replication engine and generating a second CRC value of the second data set copy via the second streaming CRC engine in the hardware of the replication engine in parallel further comprises: generating a final CRC value via the first streaming CRC engine, wherein the final CRC value is generated using the third data set copy and the first CRC value, and The sending of the first streaming CRC message to the processor further includes: sending the first streaming CRC message including the first data set copy, the third data set copy and the final CRC value to the processor.
19. A replication engine for a computing device, the replication engine comprising: means for duplicating a first data set received from the interface bus to obtain a copy of the first data set; means for duplicating a second data set received from said interface bus to obtain a copy of the second data set; means for generating, in parallel, a first CRC value for the first data set copy and a second CRC value for the second data set copy; means for sending a first streaming CRC message including a copy of the first data set and the first CRC value to a processor of the computing device; and Means for sending a second streaming CRC message including a copy of the second data set and the second CRC value to the processor.
20. The replication engine according to claim 19, further comprising: means for generating a first source ring descriptor based on the first communication message, the first source ring descriptor comprising a first source data pointer indicating a memory location of the first data set; and Means for generating a second source ring descriptor based on the second communication message, the second source ring descriptor comprising a second source data pointer indicating a memory location of the second data set.
21. The replication engine of claim 20, wherein: The means for copying the first data set received from the interface bus to obtain a copy of the first data set further comprises means for copying the first data set based on the first source data pointer, and The means for copying the second data set received from the interface bus to obtain a copy of the second data set further comprises means for copying the second data set based on the second source data pointer.
22. The replication engine of claim 20, wherein: the first source ring descriptor comprising first length bits indicating a length of the first data set, first aggregation bits indicating that the first CRC value was generated as part of a first data set stream including a plurality of data sets, and a first CRC type indicating a first communication protocol; and The second source ring descriptor includes second length bits indicating a length of the second data set, second aggregation bits indicating that the second CRC value is generated as part of a second data set stream including a plurality of data sets, and a second CRC type indicating a second communication protocol.
23. The replication engine of claim 19, wherein: The means for generating the first CRC value for the copy of the first data set further comprises means for generating the first CRC value for the copy of the first data set based on a first CRC type indicative of a first communication protocol; and The means for generating the second CRC value for the copy of the second data set further includes means for generating the second CRC value for the copy of the second data set based on a second CRC type indicative of a second communication protocol.
24. The replication engine of claim 23, wherein the first CRC type and the second CRC type are different CRC types.
25. The replication engine of claim 19, further comprising: means for generating a first state ring descriptor comprising said first CRC value and a first state bit; means for generating a second state ring descriptor comprising said second CRC value and a second state bit; means for setting the first status bit after generating the first CRC value, wherein sending the first streaming CRC message is performed in response to setting the first status bit; and means for setting the second status bit after generating the second CRC value, wherein sending the second streaming CRC message is performed in response to setting the second status bit.
26. The replication engine of claim 19, further comprising: means for generating a first destination ring descriptor including a first destination data pointer; and means for generating a second destination ring descriptor including a second destination data pointer, in: The means for sending the first streaming CRC message includes means for sending the first streaming CRC message based on the first destination data pointer, and the means for sending the second streaming CRC message includes means for sending the second streaming CRC message based on the second destination data pointer.
27. The replication engine of claim 19, further comprising means for replicating a third data set received from the interface bus to obtain a copy of the third data set, wherein: means for generating, in parallel, the first CRC value for the first data set copy and the second CRC value for the second data set copy including means for generating a final CRC value using the third data set copy and the first CRC value; and Means for sending the first streaming CRC message to the processor includes means for sending the first streaming CRC message to the processor including the first data set copy, the third data set copy, and the final CRC value.
28. A non-transitory processor-executable medium having processor-executable instructions stored thereon, the processor-executable instructions configured to cause a replication engine of a computing device to perform operations comprising: replicating, in hardware of the replication engine, a first data set received from the interface bus to obtain a first data set copy; replicating, in hardware of the replication engine, a second data set received from the interface bus to obtain a second data set copy; generating a first CRC value for the first data set copy via a first streaming CRC engine in the hardware of the replication engine, and in parallel generating a second CRC value for the second data set copy via a second streaming CRC engine in the hardware of the replication engine; sending a first streaming CRC message including the first data set copy and the first CRC value to a processor of the computing device; and A second streaming CRC message including a copy of the second data set and the second CRC value is sent to the processor.
29. The non-transitory processor-executable medium of claim 28, wherein the stored processor-executable instructions are further configured to cause the replication engine of the computing device to perform operations further comprising: generating a first source ring descriptor based on the first communication message, the first source ring descriptor comprising a first source data pointer indicating a memory location of the first data set; as well as A second source ring descriptor is generated based on the second communication message, the second source ring descriptor including a second source data pointer indicating a memory location of the second data set.
30. The non-transitory processor-executable medium of claim 29, wherein the stored processor-executable instructions are further configured to cause the replication engine of the computing device to perform operations such that: Copying the first data set received from the interface bus in hardware of the copy engine to obtain the first data set copy further comprises copying the first data set based on the first source data pointer, and Copying the second data set received from the interface bus in hardware of the copy engine to obtain the second data set copy further includes copying the second data set based on the second source data pointer.
Citation Information
Patent Citations
Multi-protocol support on common physical layer
CN112860610A
Error protection for payload using dual CRC enhancement
CN114826479A
Parallel CRC calculation for multiple packets without requiring a shifter
US10171108B1
Electronic device having a runtime integrity checker
US20160085618A1
Performing cyclic redundancy checks using parallel computing architectures
US20210067173A1