Fuseload Architecture for SoC Reconfiguration via Fuse Headers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The existing system-on-chip (SoC) architectures are limited by a pre-defined one-to-one mapping between fuse addresses and register addresses, which inhibits repurposing and reconfiguration, leading to inefficient use of resources and inflexibility in loading different configurations.
Innovation Solution
The introduction of a fuse header with subfields such as a starting register address, fuse header identity, and fuse count allows for a modular and configurable mapping between fuse addresses and register addresses, enabling flexible copying of trims to registers and avoiding unnecessary resource usage.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a pre-defined one-to-one mapping between fuse addresses and register addresses is used, then the fuseload process is simple and deterministic, but the SoC cannot be repurposed or reconfigured for different applications
Solution Approach 1:
The patent segments the fuse address space by introducing fuse headers that divide the continuous fuse array into discrete groups. Each fuse header contains metadata (such as register start address, fuse count, and skip options) that defines a specific mapping configuration. This segmentation allows different portions of fuse space to be independently configured for different register mappings, enabling multiple applications to share the same physical fuse infrastructure without requiring a complete redesign of the mapping mechanism.
2Productivity
If all trims are loaded to registers during fuseload, then the SoC is fully configured for operation, but unnecessary trims are wasted when only a subset is needed for specific applications
Solution Approach 1:
The patent implements partial action by allowing the fuseload process to load only the necessary subset of trims rather than requiring all trims to be loaded. The fuse header contains a fuse count field and register start address that define the exact range of fuses to be loaded. Additionally, skip options in the fuse header enable the system to selectively skip certain fuse groups that are not needed for the current application, thereby avoiding the waste of loading unnecessary trim data while still achieving complete configuration for the intended purpose.
3Ease of manufacture
If a fixed fuse-to-register mapping is implemented, then the hardware design is simplified, but engineering change orders are required for any reconfiguration
Solution Approach 1:
The patent introduces dynamics into the previously static fuse-to-register mapping by making the mapping configuration programmable through fuse headers. The fuse headers contain configurable fields (register start address, fuse count, skip options) that can be set during manufacturing or programming to define different mapping relationships. This dynamic configuration capability allows the same hardware to be reconfigured for different applications without requiring engineering change orders or physical hardware modifications, significantly reducing reconfiguration time and enabling rapid prototyping and product iteration.
Data Source
AI summary
Methods, systems, and devices that support fuseload architectures for system-on-chip (SoC) reconfiguration and repurposing are described. Trim data may be loaded from fuses to registers on a die based on a fuse header. For example, a set of registers coupled with a set of fuses on the die may be identified, where the set of fuses may store trim data to be copied to the registers as part of a fuseload procedure. In such cases, one or more fuse headers may be identified within the trim data, and each fuse header may correspond to a fuse group that includes a subset of fuses. Based on one or more subfields within a fuse header, a mapping between fuse addresses and register addresses may be determined, and the trim data from each fuse group may be copied into a set of registers based on the mapping.