SoC Feature Configuration via HSE for Secure Field Upgrades

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing SOCs are manufactured with permanently disabled features, limiting customer flexibility and leading to quicker obsolescence and waste due to the inability to upgrade features without replacing the entire chip.

Innovation Solution

Implementing a hardware security engine (HSE) within the SOC to manage secure enablement/disabling of features based on customer needs, allowing field upgrades through an encrypted configuration file processed by the HSE, which ensures configuration integrity and rollback to a valid state in case of errors.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of manufacture

If features are permanently disabled during manufacturing to create low-end versions, then production cost and device complexity are reduced, but customer flexibility and adaptability are limited

Engineering Contradiction:
Improveproduction costVSAvoidcustomer flexibility
Core Design Contradiction:
Ease of manufactureVSAdaptability or versatility

Solution Approach 1:

The patent implements a hardware security engine with a state machine that dynamically changes the operational state of SOC features through secure configuration updates. Features transition between disabled and enabled states based on authenticated configuration data, allowing the system to adapt its functionality after manufacturing without physical modification.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent changes the configuration parameters of SOC features through encrypted configuration files that contain enable/disable states. The hardware security engine authenticates and applies these parameter changes to feature configuration registers, allowing flexible feature activation without manufacturing changes.

Inventive Principle:
Principle #35Parameter changes

2Device complexity

If features are permanently disabled during manufacturing, then device complexity is reduced, but the ability to upgrade features without replacing the entire SOC is lost

Engineering Contradiction:
Improvedevice complexityVSAvoidupgrade capability
Core Design Contradiction:
Device complexityVSAdaptability or versatility

Solution Approach 1:

The patent prepares the SOC during manufacturing by embedding a hardware security engine with a state machine and configuration storage, but does not permanently disable features. Instead, the features are pre-configured in a disabled state that can be securely changed later, allowing upgrades without replacement while maintaining manageable complexity.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent separates the feature control functionality into a dedicated hardware security engine with state machine, distinct from the main SOC functionality. This segmentation allows independent management of feature enablement without affecting the core SOC operations, enabling upgrades while maintaining overall system simplicity.

Inventive Principle:
Principle #1Segmentation

3Adaptability or versatility

If the entire SOC is replaced to add features, then full feature functionality is achieved, but product obsolescence accelerates and waste increases

Engineering Contradiction:
Improvefeature functionalityVSAvoidwaste
Core Design Contradiction:
Adaptability or versatilityVSLoss of substance

Solution Approach 1:

The patent uses encrypted configuration files as a form of digital copy to transfer feature enablement information to the SOC. Instead of physically replacing the chip, the feature state is copied from the configuration file into the SOC's configuration registers through the hardware security engine, enabling features without material waste.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent allows old configuration data to be discarded and replaced with new configuration data that enables additional features. The hardware security engine manages this transition by authenticating new configuration files and applying them to update the feature states, recovering full functionality without discarding the physical SOC hardware.

Inventive Principle:
Principle #34Discarding and recovering

4Adaptability or versatility

If configuration updates are allowed in the field, then customer flexibility is improved, but security risks and configuration integrity challenges increase

Engineering Contradiction:
Improvefield upgrade capabilityVSAvoidconfiguration integrity
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The hardware security engine acts as an intermediary between the external configuration update source and the SOC feature controls. It authenticates incoming configuration files using cryptographic verification, validates their integrity, and only applies them if they pass security checks, thereby enabling field upgrades while protecting configuration integrity.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The state machine within the hardware security engine provides feedback mechanisms to track the current configuration state and verify successful updates. It monitors configuration changes and ensures that only valid state transitions occur, maintaining reliability while allowing flexible field updates.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP4478179B1Field upgradeable system on a chip (SOC)
Publication Date: 2026.04.15 NXP USA INC
  • EP4478179B1 patent drawingFigure 1
  • EP4478179B1 patent drawingFigure 2
  • EP4478179B1 patent drawingFigure 3

AI summary

A system on a chip (SOC) includes a user space having one or more cores, and a hardware security engine (HSE). The HSE includes storage circuitry configured to store an SOC configuration table. The SOC configuration table is configured to store, in a first entry, a current and valid configuration record corresponding to a current configuration of the SOC. The HSE is configured to, in response to an update service request from a core of the user space, decrypt an encrypted file to obtain new configuration data, update a blank record in a second entry of the SOC configuration table to be the current and valid configuration record storing the new configuration data, and update the current and valid configuration record in the first entry to be a previous and valid configuration record.