Reassessing architectural control
A fabless semiconductor company was assessing how to incorporate RISC-V across its architecture, software stack, proprietary IP and partner portfolio. An open-standard instruction-set architecture offered the prospect of greater flexibility and reduced dependence on a single proprietary architecture provider. It also raised a more difficult question: how could the company broaden ecosystem participation without weakening the capabilities on which customer value depended?
The client was not considering a simple technical migration. It was deciding how far RISC-V should extend across its product portfolio, which elements of its architecture and software should remain proprietary, which could be shared or jointly developed, and where partnership could accelerate adoption without excessive dependency.
An overly cautious approach could leave the company outside a growing ecosystem. An overly ambitious shift could fragment its technical stack, increase integration costs or tie its commercial position to tools, standards and partners that had not yet matured around its target workloads.
Openness created new choices—and dependencies
RISC-V created a spectrum of choices. The client could use it selectively in defined products, adopt it as a shared foundation with proprietary extensions, invest in common software and tooling, form alliances around specific applications, or take a more limited role while monitoring ecosystem development.
Each pathway changed the balance between control and adoption. Greater conformity to common profiles could improve portability and customer confidence. More proprietary customisation could protect technical differentiation, performance or product value, but increase the cost of software maintenance and reduce compatibility with the ecosystem the client needed to grow.
Partnership carried a similar tension. Ecosystem alliances could accelerate access to commercial cores, verification, development tools, software support, customer channels and standards influence. Yet a narrow partner portfolio could shift rather than reduce dependence. The strategic question was therefore not whether to participate, but which relationships would strengthen the company’s position and which would concentrate technical or commercial risk.
Adoption depended on the wider ecosystem
A conventional architecture assessment might compare licensing cost, performance, power efficiency and development effort. Those inputs were necessary, but insufficient. Adoption depended on the interaction of software maturity, toolchain compatibility, standards profiles, developer capability, customer requirements, proprietary IP, partner incentives, regional market access and the wider semiconductor supply chain.
Software maturity could not be treated as a single ecosystem-wide condition. The relevance of compilers, debuggers, operating systems, libraries, verification and performance tools varied by workload, product type and customer environment. The client needed to understand where RISC-V could offer a credible near-term proposition, where additional ecosystem investment was required, and where the economics of adoption would remain unattractive.
Geopolitical considerations added another layer. RISC-V could reduce ISA-level dependency, but did not make the client independent of design tools, manufacturing, supply chains, customers or trade rules. Architectural openness changed where control and exposure sat within the system; it did not remove those constraints.
Testing architecture and alliance pathways
Bruqe framed the engagement around the client’s strategic objectives, differentiation priorities, target workloads, investment capacity, acceptable dependencies and IP-risk thresholds. The work mapped how architecture design, proprietary extensions, software maturity, standards participation, customer adoption, partner incentives and geopolitical exposure affected one another.
It then tested alternative architecture and alliance pathways: selective deployment, a shared base with differentiated layers, deeper participation in standards and software development, targeted vertical-market adoption and staged commitment. These pathways were examined across plausible futures for tool maturity, customer adoption, standards evolution, partner concentration, IP exposure and regional access.
The objective was not to determine whether RISC-V was inherently superior. It was to identify where openness could expand strategic options, where proprietary control remained essential and which commitments should remain reversible as the ecosystem developed.
Designing a portfolio of control
The analysis reframed the question from an architecture-selection decision into a portfolio of choices across IP, software, talent, standards and partnerships. It clarified which early investments could build useful options—developer capability, verification, targeted software support, standards participation and selected alliances—without committing the client to a full portfolio transition.
Preserving choice as the ecosystem evolves
The resulting decision architecture allowed the client to pursue RISC-V where it could strengthen flexibility and customer value, while preserving the ability to adapt as technical and market conditions evolved. The central implication was clear: openness creates strategic value only when it is paired with the differentiated capabilities, ecosystem relationships and software coherence required to turn it into durable adoption.
