Marvell disclosed on 19 August 2026 that it had expanded its custom-semiconductor relationship with Google across programmes attached to Google’s TPU ecosystem. The agreement also includes a warrant permitting Google to purchase up to 58.97 million Marvell shares at $206.58 per share—an aggregate exercise price of approximately $12.18bn if all the relevant shares vest and the warrant is fully exercised. This is not a $12.2bn upfront investment or confirmed chip order. Broadcom separately retains a Google TPU agreement extending to as late as 2031. For verification teams, the deeper issue is how multi-supplier AI infrastructure is specified, integrated and signed off. [1][5]
What Google and Marvell Have Announced
According to Marvell’s 19 August 2026 Form 8-K, Marvell and Google entered into a commercial agreement on 29 July 2026 concerning Marvell’s development of custom semiconductor products for Google. Marvell describes the expanded relationship as spanning custom-silicon programmes attached to the TPU ecosystem, including AI inference accelerators, storage controllers, network-interface controllers, memory-interface controllers and near-memory compute. [1]
That wording is significant because it describes a broader infrastructure relationship than a single accelerator block. It does not, however, publicly disclose which TPU generation or accelerator architecture is involved, how design responsibilities are divided, which foundry will manufacture any resulting devices, what process technology will be used, whether particular products will use HBM, chiplets or advanced packaging, or when production silicon will appear.
Those details should remain unknown unless Google, Marvell or another authoritative filing subsequently confirms them.
What the $12.2 Billion Warrant Actually Means
The warrant is the part of the story most vulnerable to misleading headlines.
Marvell issued Google a warrant on 18 August 2026 to purchase up to 58,970,907 Marvell shares at $206.58 per share. Multiplying the maximum share count by that exercise price gives approximately $12.18bn. That is the basis of the widely reported $12.2bn figure. [1][2][3]
It is therefore incorrect to describe the agreement as:
- Google paying Marvell $12.2bn upfront
- A confirmed $12.2bn Google chip order
- A direct $12.2bn cash investment already made
- Or a $12.2bn chip-development budget
Only 1,360,867 warrant shares have time-based vesting, in equal quarterly instalments during the first year. The remaining shares vest according to discretionary purchases of qualifying Marvell Custom Products from Marvell’s fiscal third quarter of 2027 through fiscal 2033. There are 240 performance tranches, with one tranche vesting for every $500m of Custom Products revenue. [1]
Mathematically, 240 × $500m equals $120bn. That explains the very large potential-revenue number appearing in financial coverage. It does not mean Google has committed to buy $120bn of chips. The filing itself describes the purchases as discretionary. Full performance vesting would require the associated qualifying revenue thresholds to be reached. [1][3]
Confirmed Facts, Undisclosed Details and Engineering Implications
| Confirmed | Not publicly disclosed | Reasonable engineering implication |
| Google and Marvell entered a commercial custom-semiconductor agreement on 29 July 2026. [1] | Exact product architecture and individual TPU generations. | Inference: Google is creating a relationship that can cover more than one silicon function rather than one isolated device. |
| The publicly listed programme areas include inference accelerators, storage, networking, memory interfaces and near-memory compute. [1] | Exact allocation of those programmes between Google, Marvell, Broadcom or other suppliers. | Inference: interface ownership and system acceptance become as important as individual block verification. |
| Google has a warrant for up to 58.97m Marvell shares at $206.58. [1][2] | How many shares will ultimately vest or be exercised. | Inference: the warrant creates long-term commercial alignment tied predominantly to purchasing activity. |
| Broadcom separately disclosed a Google agreement for future TPU generations and AI-rack components extending to as late as 2031. [5] | How future work will be divided between Broadcom, Marvell and Google internally. | Inference: diversification is better supported by public evidence than an assumption of immediate supplier replacement. |
| Marvell’s wider ASIC platform includes IP and capabilities spanning high-speed SerDes, storage, silicon photonics, advanced packaging, chiplets and HBM. [6] | Whether the Google programmes use any specific Marvell packaging, HBM, chiplet or photonics technology. | Inference: Marvell has a broad technical toolbox, but those generic capabilities must not be presented as confirmed Google design choices. |
Sources: Marvell filings, Broadcom filing and Marvell FY2026 Form 10-K.
Why Google May Want More Than One Custom-Silicon Partner
Google has not publicly explained the complete strategic rationale for expanding Marvell’s role, so motives beyond the filing need to be labelled as inference.
From an engineering and programme-management perspective, however, several reasons for using more than one capable silicon partner are plausible: parallel product schedules, access to different IP portfolios, reduction of concentration risk, additional implementation capacity, architecture-specific expertise and commercial leverage. That does not require Google to move every TPU programme from one supplier to another.
A hyperscaler can instead allocate different generations, supporting devices, interfaces or implementation responsibilities to different partners while retaining internal architectural ownership. The key technical consequence is that the verification boundary moves with the commercial boundary.
Marvell, Broadcom and the Difference Between Diversification and Replacement
The public evidence does not support a simple “Marvell replaces Broadcom” conclusion.
On 6 April 2026, Broadcom disclosed a long-term Google agreement under which Broadcom would develop and supply custom TPUs for future Google TPU generations, together with networking and other components for next-generation Google AI racks, extending to as late as 2031. [5]
Reuters also reported that analysts viewed the Marvell announcement as an expansion of Google’s supplier base rather than clear evidence of Broadcom displacement. [3]
The safest conclusion today is therefore supplier diversification with an unresolved division of future responsibilities. This distinction is worth preserving because Alpinum’s existing Apple–Broadcom custom-ASIC analysis already covers the wider move towards long-term custom-silicon partnerships. The Google–Marvell story adds a different question: what happens when a hyperscaler operates several such relationships simultaneously?
Why AI Infrastructure Is Moving Beyond a Single Accelerator
Google itself describes TPUs as purpose-built accelerators operating as part of a broader AI Hypercomputer architecture combining hardware, software and infrastructure. [7][9]
At large scale, useful AI performance depends on more than arithmetic throughput. Model weights, activations and intermediate state must move between memory and compute. Accelerators must communicate with other accelerators. Storage must feed workloads and checkpoints. Networks must sustain collective communication. Firmware and runtimes have to initialise, schedule, recover and observe the hardware.
Google’s May 2026 reliability discussion makes the scale explicit: it describes TPU superpods made from thousands of interconnected devices and argues that availability for frontier workloads must increasingly be treated at cluster rather than individual-instance level. These are Google’s own engineering claims, but they illustrate why rack and cluster behaviour matter. [8]
The Verification Challenge in Multi-Vendor Custom Silicon
The hardest verification problem may not be whether one supplier can verify one chip. It is whether all parties agree on what must be true at the boundaries.
A chip supplier can deliver an RTL implementation that satisfies its local specification while the integrated system still fails because another team interpreted latency, ordering, retry, reset, firmware or performance requirements differently. That makes requirements traceability, interface contracts and acceptance evidence programme-level artefacts rather than paperwork. Teams facing this class of problem can use established pre-silicon verification practices to connect architectural intent to executable checks, coverage and sign-off evidence rather than waiting for integration failures to define the real specification.
Multi-Vendor Custom-Silicon Verification Handoffs
| Handoff area | Required engineering artefact | Verification risk | Evidence needed before sign-off |
| Product requirement → architecture | Versioned requirements, workload envelope and acceptance criteria | Ambiguous performance or behaviour targets | Requirement traceability, architecture reviews and measurable acceptance tests |
| Architecture → RTL implementation | Executable specification and independent reference model | RTL matches implementation assumptions rather than original intent | Scoreboard/reference correlation, assertions, functional coverage and targeted formal results |
| Third-party IP → SoC integration | Interface/configuration contract and verification IP | Third-party or licensed IP configured or integrated incorrectly | Protocol compliance, configuration coverage, reset/clock/power tests and negative testing |
| Accelerator → memory subsystem | Bandwidth, ordering, error and flow-control contract | Starvation, corruption, backpressure or inability to sustain required throughput | Traffic stress, ordering checks, bandwidth measurements and fault injection |
| Compute → high-speed interconnect | Protocol, topology, QoS and forward-progress requirements | Congestion, deadlock, reordering or starvation | VIP, assertions, targeted formal analysis and long-duration congestion scenarios |
| Hardware → firmware | Register, boot, reset and error-state specification | Firmware sequences hardware into unverified states | Boot/recovery regressions, register-model checks and hardware–software co-verification |
| Firmware → compiler/runtime | Versioned command and execution contract | Legal software generates unsupported or pathological hardware sequences | Differential testing, ABI/API conformance and representative compiled workloads |
| Chip results → rack-scale validation | Telemetry, RAS, workload and service-level acceptance plan | Component passes while cluster performance or availability fails | Realistic workloads, fault/recovery tests, congestion data, telemetry and quantified acceptance evidence |
Who Owns Verification Intent Across Company Boundaries?
A multi-company programme needs more than a list of test owners. It needs an owner for each verification intent statement.
For example, “the interface supports retry” is not sufficiently precise. The engineering contract should state what failures trigger retry, whether operations may be reordered, how many requests can be outstanding, what happens during reset, what latency is acceptable, which counters expose failures and what constitutes successful recovery. Responsibility should then be separated into at least three questions:
Who specifies the behaviour? Who demonstrates local compliance? Who accepts the integrated result?
Those may be three different organisations. A further safeguard is reference-model independence. If implementation and checking logic both encode the same misunderstanding of an ambiguous specification, a perfectly matching scoreboard can still provide false confidence.
Alpinum’s existing analysis of verification planning and coverage closure explains why sign-off evidence must remain connected to requirements rather than simply to test activity.
Verifying Compute, Memory, Networking and Storage as One System
A system can be functionally correct and still fail its workload objective.
An accelerator may generate correct results while spending too much time waiting for memory. A network may be protocol-compliant while creating severe tail latency under collective traffic. Storage may pass individual I/O tests while checkpoint bursts interfere with other workloads. Firmware recovery may work for one device but cause large-scale service disruption when many devices fail or restart together. The verification plan therefore needs two distinct classes of acceptance:
Functional acceptance asks whether data, commands, ordering, exceptions and state transitions are correct.
System-performance acceptance asks whether the platform reaches defined throughput, latency, utilisation, availability and recovery objectives under realistic workloads and contention.
These should not be collapsed into one “pass” criterion. Open Compute Project’s 2026 Ethernet for Scale-Up Networking specification similarly treats congestion management, low latency and link reliability as first-class concerns for scale-up AI systems.
Where UVM, Formal Verification, Emulation and Hardware–Software Co-Verification Fit
No single verification methodology covers this entire evidence chain.
UVM and simulation are well suited to reusable interface environments, constrained traffic, scoreboards, protocol checking, configuration combinations and functional coverage. Accellera explicitly positions UVM around interoperability and reusable verification components. [10]
Assertion-based and formal verification are particularly useful for bounded protocol behaviour, arbitration, ordering rules, control logic, security conditions and selected forward-progress properties. They can explore combinations that are difficult to reach through simulation. Formal verification should not, however, be described as exhaustively proving a complete rack-scale AI platform. Capacity, abstraction and property scope still determine what can actually be proved.
Emulation allows much longer workloads, firmware, drivers and runtime software to execute before silicon while preserving more hardware fidelity than a pure software model. Accellera’s SCE-MI standard provides an industry interface for hardware-assisted verification environments. [10]
FPGA prototyping can accelerate software development and system interaction, but FPGA mapping is not a substitute for proving ASIC timing, power or every implementation-specific behaviour.
Hardware–software co-verification is essential wherever firmware, drivers, compilers or runtimes control scheduling, memory allocation, synchronisation, error handling or recovery.
Teams building these skills can review Alpinum’s SystemVerilog/UVM verification training and formal verification training programme. For project delivery rather than training, targeted formal verification services can be applied where proof adds genuine risk reduction.
Rack-Scale Validation: Performance, Congestion, Reliability and Recovery
At rack and cluster scale, verification becomes partly an exercise in distributed-system behaviour implemented through hardware and software.
Useful scenarios include sustained collective traffic, hotspot formation, backpressure propagation, link degradation, retries, partial device loss, firmware restart, checkpoint/recovery, resource reconfiguration and simultaneous failures. Performance testing also needs distributions rather than only averages. A system that delivers acceptable mean latency but severe long-tail stalls can fail a real inference objective.
Google’s own cluster-reliability framework explicitly connects infrastructure health, software frameworks and application-level recovery mechanisms. That is useful evidence for the broader engineering principle: AI-infrastructure sign-off cannot stop at “every ASIC passed its testbench”. [8]
What Engineering and Verification Leaders Should Do
A practical verification-lead checklist for any multi-supplier custom-silicon programme is:
- Assign explicit ownership for every system and interface specification
- Version interface contracts and record assumptions at each supplier boundary
- Maintain independent golden or reference models where practical
- Define reusable verification IP and configuration responsibilities
- Map critical requirements to assertions and targeted formal properties
- Define functional coverage around risk rather than raw percentage targets
- Add workload-driven performance, bandwidth and congestion scenarios
- Inject errors and verify containment, retry, degradation and recovery
- Validate firmware, drivers, compilers and runtime versions against hardware
- Define who owns regressions at IP, SoC, platform and system levels
- Establish cross-company defect triage with reproducible evidence
- Define final acceptance and sign-off artefacts before implementation reaches closure
For broader programme support, Alpinum’s ASIC and SoC design verification services cover verification planning, implementation and system-level confidence rather than treating methodology as an isolated tool choice.
What This Signals for the AI Infrastructure Race
The Google–Marvell agreement is significant partly because of its scale, but the more durable signal is architectural.
Hyperscaler custom silicon is increasingly connected to an ecosystem of accelerators, memory controllers, networking, storage, firmware, runtimes and rack infrastructure. Marvell’s FY2026 filing describes its wider custom-ASIC platform as spanning high-speed SerDes, compute, security, storage, silicon photonics and advanced-packaging technologies. Those are Marvell platform capabilities, not confirmation that Google has selected each technology for this agreement. [6]
The competitive question is therefore becoming less “who supplies the AI chip?” and more “who can help build and validate the complete data path from workload to infrastructure?”
That same movement towards deeper custom-silicon ownership can be compared with Alpinum’s recent Anthropic custom-silicon analysis, although the verification boundary here is distinctly multi-company and infrastructure-wide.
Alpinum Perspective
For verification organisations, supplier diversification should trigger a review of evidence architecture, not simply a larger regression plan. Each new implementation partner creates an additional point at which specifications, assumptions, models, coverage and acceptance results can diverge. The most useful response is to define verification ownership at the same time as design ownership and to preserve traceability from product requirement through RTL, firmware and rack-level acceptance.
AI techniques may help teams analyse regressions, generate candidate tests or classify failures, but sign-off responsibility remains an engineering decision. Alpinum’s work on AI in Design Verification is most relevant where such automation strengthens rather than obscures that evidence chain.
Key Takeaways
- The $12.2bn figure is associated with the warrant terms, not an upfront Google payment or confirmed chip order.
- Most warrant vesting is conditional on future qualifying purchases; $120bn is a threshold implied by 240 × $500m, not a committed Google spend.
- Public evidence does not establish that Marvell is replacing Broadcom; Broadcom has a separate Google agreement extending to as late as 2031.
- The Marvell agreement covers several custom-silicon categories attached to the TPU ecosystem, making system integration more important than isolated accelerator correctness.
- Multi-vendor programmes need explicit ownership of specifications, reference models, regressions, defect triage and acceptance evidence.
- AI-infrastructure verification must connect chip correctness with memory, networking, firmware, runtime behaviour, congestion, reliability and recovery.
References
[1] Marvell Technology, Inc., Form 8-K: Google commercial agreement and warrant, 19 August 2026. https://investor.marvell.com/sec-filings/all-sec-filings/content/0001193125-26-356217/d412696d8k.htm
[2] Marvell Technology, Inc., Exhibit 4.1: Warrant to Purchase Common Stock, 18 August 2026.https://investor.marvell.com/sec-filings/all-sec-filings/content/0001193125-26-356217/d412696dex41.htm
[3] Reuters, Marvell gives Google option to buy $12.2 billion stake in custom AI chip deal, 19 August 2026. https://www.reuters.com/technology/marvell-grants-google-122-billion-stock-warrant-custom-chip-deal-2026-08-19/
[4] Financial Times, Google strikes $12bn AI chip deal with Marvell, 20 August 2026.
https://www.ft.com/content/0fdb094c-fc03-4d3c-8da6-bd11af88ff63
[5] Broadcom Inc., Form 8-K: Long Term Agreement with Google, April 2026.
https://www.sec.gov/Archives/edgar/data/1730168/000119312526144028/d87999d8k.htm
[6] Marvell Technology, Inc., Form 10-K for fiscal year ended 31 January 2026.
https://investor.marvell.com/sec-filings/all-sec-filings/content/0001835632-26-000011/mrvl-20260131.htm
[7] Google Cloud, Tensor Processing Units.
https://cloud.google.com/tpu
[8] Google Cloud, Cluster-level reliability for trillion-parameter models on TPUs, 12 May 2026.
https://cloud.google.com/blog/products/compute/cluster-reliability-for-trillion-parameter-models-on-tpus
[9] Google Cloud, AI Hypercomputer and integrated AI infrastructure.
https://cloud.google.com/blog/products/ai-machine-learning/introducing-cloud-tpu-v5p-and-ai-hypercomputer
[10] Accellera Systems Initiative, UVM and SCE-MI standards resources.
https://www.accellera.org/downloads/standards
FAQs
Marvell disclosed a commercial agreement with Google covering Marvell’s development of custom semiconductor products attached to Google’s TPU ecosystem. Publicly listed programme categories include inference accelerators, storage controllers, network-interface controllers, memory-interface controllers and near-memory compute. [1]
No. Google received a warrant permitting it to purchase up to 58.97 million Marvell shares at $206.58 each, subject to vesting and other terms. The roughly $12.2bn figure comes from applying the disclosed exercise price to the maximum share count. It is not an upfront $12.2bn cash investment. [1][2]
That has not been established. Broadcom disclosed in April 2026 that it has a long-term agreement to develop and supply future Google TPUs and AI-rack components extending to as late as 2031. The allocation of future programmes between Google, Broadcom, Marvell and other suppliers is not publicly disclosed. [5]
Google describes TPUs as purpose-built accelerators designed around AI workloads and integrated with its wider AI software and infrastructure. Custom silicon allows architecture to be optimised around the intended workload rather than only using a general-purpose accelerator, although the economics and engineering trade-offs depend on deployment scale and workload stability. [7]
The Google filing specifically identifies custom programmes involving inference accelerators, storage, networking, memory interfaces and near-memory compute. Separately, Marvell’s general custom-ASIC platform includes high-speed interconnect, storage, security, packaging, HBM, chiplet and silicon-photonics capabilities. Those general platform capabilities should not be assumed to describe the undisclosed Google architecture. [1][6]
Because correctness depends on contracts between organisations as well as blocks of RTL. Specification ambiguity, different reference models, firmware/version assumptions, interface behaviour, performance requirements and recovery semantics can create failures even when each supplier’s local design passes its own verification environment.
A credible programme normally combines simulation and UVM environments, assertions, targeted formal verification, independent reference models, coverage, hardware–software co-verification, emulation and where useful FPGA prototyping. System-level acceptance then has to test realistic traffic, software, performance, congestion and recovery. Formal verification is powerful for selected properties but does not exhaustively prove an entire rack-scale AI platform.
Written by : Mike Bartley
Mike started in software testing in 1988 after completing a PhD in Math, moving to semiconductor Design Verification (DV) in 1994, verifying designs (on Silicon and FPGA) going into commercial and safety-related sectors such as mobile phones, automotive, comms, cloud/data servers, and Artificial Intelligence. Mike built and managed state-of-the-art DV teams inside several companies, specialising in CPU verification.
Mike founded and grew a DV services company to 450+ engineers globally, successfully delivering services and solutions to over 50+ clients.
Mike started Alpinum in April 2016 to deliver a range of start-of-the art industry solutions:
Alpinum AI provides tools and automations using Artificial Intelligence to help companies reduce development costs (by up to 90%!) Alpinum Services provides RTL to GDS VLSI services from nearshore and offshore centres in Vietnam, India, Egypt, Eastern Europe, Mexico and Costa Rica. Alpinum Consulting also provides strategic board level consultancy services, helping companies to grow. Alpinum training department provides self-paced, fully online training in System Verilog, UVM Introduction and Advanced, Formal Verification, DV methodologies for SV, UVM, VHDL and OSVVM and CPU/RISC-V. Alpinum Events organises a number of free-to-attend industry events
You can contact Mike (mike@alpinumconsulting.com or +44 7796 307958) or book a meeting with Mike using Calendly (https://calendly.com/mike-alpinum-consulting).
Stay Informed and Stay Ahead
Latest Articles, Guides and News
Explore related insights from Alpinum that dive deeper into design verification challenges, practical solutions, and expert perspectives from across the global engineering landscape.
