At HUAWEI CONNECT 2026 in Shanghai on 17 September, the Huawei Ascend 960 AI chip roadmap moved forward: Ascend 960DT is now due in Q1 2027 and Ascend 960PR in Q3 2027 [1]. The larger story for engineers is the system around them. Huawei says its Atlas 960E SuperPoD can combine up to 4,096 NPUs over UnifiedBus and near-packaged optics, and that SuperClusters can scale to 512,000 NPUs, or one million with a multi-rail topology [8].
For verification teams the consequence is direct: when thousands of accelerators, memory resources, interconnects, firmware components and software layers are expected to behave as one computing system, verification moves from proving chip behaviour towards establishing system behaviour under concurrency, failure and realistic workloads.
Why does Huawei SuperPoD scale change AI-chip verification?
At SuperPoD scale, verification shifts from proving that each NPU is correct to proving that thousands of interconnected NPUs behave correctly together. An accelerator can pass its own tests while the system still fails through congestion, ordering errors, deadlock, software scheduling, recovery logic, power behaviour or security gaps. Sign-off therefore has to cover the interconnect, memory, firmware, runtime software and fault handling as well as the chip.
How to read the sourcing. “Huawei says” marks Huawei’s own 17 September 2026 materials; “reported” marks third-party reporting; “Alpinum analysis” marks engineering inference about systems of this class, not a statement about Huawei’s design or process. This article analyses public information and implies no commercial relationship with any company named.
What Has Huawei Announced for the Ascend 960 AI Chip Roadmap?
Huawei says Ascend 960 development is ahead of the company’s own expectations, with the planned doubling of performance on track. On 17 September 2026, David Wang said Ascend 960DT would be ready in Q1 2027, three quarters earlier than the previous roadmap, while Ascend 960PR is targeted for Q3 2027, one quarter earlier. Huawei also plans Ascend 970 in 2028 and Ascend 980 in 2029. [1]
Huawei’s launch materials do not include per-chip specifications. Tom’s Hardware’s roadmap table (18 September 2026) lists Ascend 960DT with 288 GB of memory at 9.6 TB/s and Ascend 960PR with 192 GB, both at 2 PFLOPS FP8 [9]; treat these as reported roadmap figures. Micro-architecture and coherency mechanisms are undisclosed, and the suffixes should not be over-read: Huawei’s 2025 material defined 950PR as prefill and recommendation and 950DT as decode and training [11], but Huawei has not defined the 960 roles in its launch materials.
The more important architectural announcement for this discussion is the Atlas 960E SuperPoD. Huawei describes a SuperPoD as multiple computing nodes tightly coupled by high-speed interconnect and unified memory addressing so that they operate as a single logical computer. Its current Atlas 960E specification scales to 4,096 NPUs, with Huawei claiming up to 8 EFLOPS of FP8 compute and up to 1 PB of HBM. Those are Huawei specifications rather than independently validated workload benchmarks. [1] [8] Huawei’s launch materials do not state an Atlas 960E delivery date; some outlets report Q3 2027, which is unconfirmed.
Huawei describes UnifiedBus, the centre of its Peerium computing architecture, as a single open protocol connecting CPUs, NPUs, memory, SSDs, network cards and switches [2]. It says an Atlas 950 SuperCluster of 256,000 cards is already being deployed and that an Atlas 960 system based on near-packaged optics is under testing. For the Atlas 960E generation, Huawei says SuperPoDs can be linked over UnifiedBus or RoCE into SuperClusters of up to 512,000 NPUs using a two-tier, four-plane Clos architecture, or up to one million with a multi-rail topology [8]. Those larger figures describe what the architecture can support; Reuters separately reported the one-million target [3].
It is worth separating these latest disclosures from Huawei’s 2025 roadmap, which described an Atlas 960 SuperPoD capable of containing as many as 15,488 Ascend 960 processors. The newer 2026 system is specifically called Atlas 960E and carries a different maximum configuration. Huawei has not publicly reconciled every configuration and naming detail between those disclosures, so the numbers should not be combined into a single specification. [10]
Why SuperPoD Scale Is Different From Verifying a Single AI Accelerator
An individual accelerator presents difficult verification problems: arithmetic correctness, data movement, DMA, memory behaviour, interrupts, power control and software-visible operation.
A small multi-accelerator subsystem introduces communication, synchronisation and resource-sharing behaviour. At rack or pod scale, network topology, routing, collective operations, congestion, distributed scheduling and recovery become important. A tightly coupled SuperPoD adds even stronger dependencies between interconnect, memory and software.
This resembles the industry’s distinction between scale-up and scale-out. Scale-up fabrics tightly connect accelerators so they can act more like one compute domain; scale-out networks connect those domains into increasingly large clusters. Nvidia draws the same line, describing NVLink as its scale-up fabric and scale-out networks as those that connect servers across the data centre. [4] Huawei’s own material draws a similar line: SuperPoD nodes share unified memory addressing, while SuperPoDs are then joined into SuperClusters over UnifiedBus or RoCE [8].
Verification complexity consequently does not rise simply because there are more copies of the same NPU. It rises because the number of interactions, concurrent states, resource dependencies and failure combinations grows.
Alpinum analysis: a simple count shows the effect. Eight NPUs have 28 possible pairs; a 4,096-NPU SuperPoD has 8,386,560. That is 512 times the NPUs but roughly 300,000 times the potential pairwise flows. It is illustrative, counting possible interactions rather than effort, but it shows why complexity does not scale linearly with chip count.
Seven Verification Challenges That Grow at SuperPoD Scale
1. Interconnect Correctness and Congestion
At thousands of endpoints, the interconnect becomes part of functional correctness rather than only a performance feature.
Verification needs to cover routing and arbitration rules, packet or transaction ordering, credit management, backpressure, buffering, retries, traffic classes and congestion behaviour. Hotspots can appear when many accelerators communicate with the same destinations or participate in collective operations simultaneously.
A fabric may operate correctly under uniform traffic yet expose a flaw when several flows compete for shared buffers, links or arbitration resources.
Verification environments therefore need traffic patterns that represent real distributed AI behaviour rather than only independent interface tests. They also need to distinguish performance degradation from functional failure: congestion is expected; lost transactions, broken ordering or failure to make progress are not.
Where a fabric spans protocols, the boundary is itself a verification target. Huawei says SuperPoDs can be joined over UnifiedBus or RoCE [8]. Alpinum analysis: address mapping, ordering, flow control and error semantics must survive every crossing.
2. Deadlock, Livelock and Forward Progress
Large fabrics contain queues, credits, dependencies, shared resources and retry mechanisms. Those mechanisms can interact in cycles.
A deadlock may leave transactions permanently waiting for resources held by one another. Livelock allows activity to continue without useful progress. Starvation can leave one requester indefinitely disadvantaged despite the rest of the system moving forward.
Simulation can test many stressful traffic patterns, but discovering the precise sequence that creates a circular resource dependency may be difficult.
Formal analysis is a practical complement. A DVCon paper on SoC-level deadlock verification reports formal sign-off finding critical deadlock bugs on a mobile SoC, using architectural models because RTL models ran into runtime explosion [7].
Alpinum analysis: a worked example. Suppose credit-return messages share a queue with data. If that queue fills with data waiting for credits that can only return through it, nothing moves, and uniform-traffic tests rarely provoke it. Separate message classes or virtual channels break the dependency; formal analysis can check that the dependency graph is acyclic and that credits cannot be lost.
For teams developing complex control fabrics, Alpinum’s formal verification services provide a relevant methodology route for properties that are difficult to exhaust through stimulus alone.
3. Memory Consistency, Ordering and Coherency
Tightly connected accelerators can expose memory behaviour across physical boundaries.
Depending on the architecture, verification may need to reason about shared or distributed memory, cache state, DMA transactions, synchronisation, atomic operations and software-visible ordering. Not every accelerator architecture is cache coherent, and Huawei has not publicly disclosed every low-level coherency mechanism used by Ascend 960 systems. Huawei does say that a SuperPoD provides unified memory addressing across physical nodes [1], so cross-node visibility and ordering are part of the system definition, not a hypothetical.
The engineering issue is broader: the rules governing visibility of data must remain correct when many independent agents generate transactions concurrently.
A DMA engine writing stale data, an incorrectly ordered synchronisation event or an incomplete invalidation sequence can appear only under specific timing conditions. That makes memory-system verification a combination of protocol checking, end-to-end data integrity, assertions, constrained-random workloads and, where practical, formal properties.
4. Hardware/Software Co-Verification
An AI accelerator does not execute useful workloads in isolation.
Firmware initialises the hardware. Drivers expose it to the operating environment. Compilers map models to available compute resources. Runtime software manages execution. Communication libraries move tensors or collective data. Schedulers decide where work runs.
A hardware block can therefore meet its RTL specification while the complete platform still behaves incorrectly because software assumes a different sequence, timeout, memory model or error response.
Huawei says CANN, the software foundation of the Ascend ecosystem, has moved to community-driven open-source development, and that Ascend is a supported PyTorch backend that also works with Triton and vLLM [1]. Each interface is a place where a software assumption can diverge from hardware behaviour.
The verification boundary has to include NPU → firmware → driver → compiler/runtime → communication stack → scheduler → workload.
That is why pre-silicon verification has to connect with embedded software testing rather than treating software validation as a post-silicon activity.
5. Fault Propagation and Resiliency
The probability that an individual component experiences a fault does not need to increase for faults to become more visible at system scale; there are simply many more components and communication paths participating in the workload.
Useful scenarios include failed or degraded links, transient data errors, malformed transactions, stalled endpoints, timeouts, incomplete operations and unexpected resets.
Verification should establish whether the architecture can detect the error, contain it, report it, isolate affected resources, recover state where required and allow software to make an appropriate recovery decision.
Fault injection is therefore valuable not merely for proving that an error flag toggles, but for examining end-to-end recovery behaviour. A system that reaches peak throughput in nominal testing but cannot recover predictably from component failure has not been completely validated.
Public data shows how quickly this matters. Meta’s Llama 3 report describes a 54-day pre-training snapshot on a 16,384-GPU cluster with 419 unexpected interruptions, roughly one every three hours, about 78% attributed to confirmed or suspected hardware issues [12]. At that size, failure is normal operation.
Huawei claims the Atlas 960E’s optical design doubles fault-free operating time and reaches 99.8% system availability [8]. Alpinum analysis: 99.8% is about 17.5 hours of downtime a year, and Huawei’s materials do not say how it is measured. A fault-recovery verification plan has to answer exactly that: which faults, over what window, and which recovery actions count as downtime.
Alpinum analysis: not every fault announces itself. Silent data corruption, a wrong value with no error indication, can pass through a long training run and surface only as degraded model quality, so end-to-end integrity checks belong in the plan alongside fail-stop fault injection.
6. Power and Thermal Verification
Large AI workloads can activate substantial parts of an accelerator system concurrently.
Verification must therefore consider how workload execution interacts with clocking, voltage or frequency changes where implemented, power sequencing, resets, thermal management and throttling.
Huawei says the Atlas 960E is fully liquid-cooled and uses 5,500 Hi-ONE near-packaged optical engines where 48,000 800G modules would traditionally be needed, cutting power by more than 550 kW [8]. These are vendor claims and should not be generalised. Alpinum analysis: fewer, denser optical engines shift the verification surface rather than remove it; link bring-up, optical power states, thermal drift and degraded-link recovery need power-aware and fault-injection coverage.
The broader engineering requirement is clear: power management itself has functional behaviour. Throttling must not violate timing assumptions. Work migration must preserve state. Reset sequencing must remain safe. A power transition during heavy traffic must not corrupt transactions.
7. Security and Isolation
A tightly integrated compute fabric also expands the security verification boundary.
Areas can include firmware trust, secure boot, privilege enforcement, DMA access control, memory protection, debugging interfaces, software-visible management registers and isolation between workloads or tenants.
Security properties need to survive exceptional conditions, not just normal operation. A timeout, partial reset or recovery path should not accidentally bypass an access-control check.
For multi-user infrastructure, the question becomes broader than “is the NPU secure?” It becomes: Can one workload influence, observe or access resources belonging to another through shared hardware, memory, firmware or management paths?
An IEEE VLSI Test Symposium 2026 paper sets out a security-verification workflow, from asset identification and threat modelling to simulation, formal verification and countermeasure reasoning, with the open-source NVDLA accelerator as its case study [6]. Alpinum’s article on formal security verification for SoC design covers the property styles in more detail.
Why Simulation Alone Becomes Difficult at This Scale
Simulation remains fundamental. It offers detailed visibility, mature debugging and strong integration with UVM and coverage-driven flows.
The limitation is combinatorial.
Thousands of concurrent agents create enormous combinations of timing, traffic, software states, queue occupancy, errors and recovery sequences. Rare interactions can require long workloads before they become observable. Adding fault combinations expands the state space further.
The practical answer is not to replace simulation with a single alternative. It is to divide verification objectives between complementary methods.
The table below shows how the methods divide the work at this scale (Alpinum analysis, not a description of any vendor’s flow).
| Method | Best evidence for | Practical limit at this scale | Main blind spot |
| Simulation | Block and subsystem function, protocol checks, coverage | A few NPUs plus a fabric slice | Long software runs; rare traffic and timing combinations |
| Formal verification | Deadlock, ordering, credits, reset, access control | Blocks and abstract topology models, not whole-fabric RTL | Datapath and numerics; assumptions and vacuous proofs |
| Emulation | Long workloads, firmware and driver bring-up, activity for power analysis | One pod slice; capacity-bound | Full-scale traffic behaviour |
| FPGA prototype | Early runtime and software execution at speed | Small-N configurations | Debug visibility; fabric fidelity |
| System and performance models | Topology, routing, collectives and congestion at full N | Full scale, but abstract | RTL-level bugs |
| Post-silicon validation | True scale, faults, thermals, soak behaviour | Full scale | Late; hard to control; costly to fix |
Tool vendors position hardware-assisted verification around this gap. Synopsys describes running full operating systems, drivers, middleware and application workloads on emulation and FPGA-prototyping platforms before silicon is available [5].
Alpinum analysis: scale-dependent defects. Many fabric bugs reproduce in small configurations with shrunk buffers and credit counts, so reduced-scale verification pays off. Others appear only at full scale: counter widths, routing-table sizes, hop-count-tuned timeouts, tail latency under collective load. Those need system-level models and staged post-silicon bring-up with telemetry.
Alpinum analysis: workload shape. Training is dominated by collectives such as all-reduce; inference adds prefill, decode and KV-cache movement. Huawei’s split of the Ascend 950 into PR and DT variants [11], and its launch of a petabyte-scale KV-cache storage cluster [1], show that traffic differs by phase. A verification workload set should cover representative collectives and inference phases, plus numerical checks: low-precision formats and reduction order can change results, so define acceptable tolerance and where bitwise reproducibility is required.
Alpinum’s FPGA services are particularly relevant where teams need earlier execution of software or system scenarios before final silicon is available.
Where Formal Verification Can Add Value
Formal verification is most useful when the required behaviour can be expressed as precise properties and the relevant state space can be modelled effectively.
At accelerator-system level, useful property classes include:
- Every accepted request eventually receives a permitted completion or error response
- Arbitration cannot permanently starve a valid requester
- Credit accounting cannot underflow or overflow
- Defined transaction ordering is preserved
- A reset cannot expose partially initialised state
- Privileged registers cannot be modified from an unauthorised state
- Errors propagate to the correct handler
- Protocol state machines cannot enter illegal states
- Selected coherency or consistency invariants are preserved
- Resource dependencies cannot form an architectural deadlock
Formal does not replace simulation. Nor does proving a local property establish correctness of the whole cluster.
Its value is that it can provide stronger evidence for selected control-heavy behaviours whose critical corner cases may be extremely difficult to hit statistically.
Three cautions apply. Liveness properties such as “eventually completes” hold only under stated fairness assumptions. A proof can pass vacuously when constraints over-restrict the design, the subject of Alpinum’s article on vacuous proofs in formal verification. And at this scale formal is applied to routers, arbiters, credit logic and abstract routing models, not the RTL of the whole fabric.
Alpinum has discussed this same principle in its verification planning and coverage-closure guidance: verification methods should be selected according to the requirement and evidence needed, rather than forcing every requirement through the same test mechanism.
The Verification Shift: From Chip Correctness to System Correctness
The central lesson from architectures such as SuperPoD is that verification has acquired additional layers.
Figure 1. Verification does not scale simply with the number of NPUs. As accelerators are coupled into larger compute domains, verification must address additional behaviours created by interconnect, shared resources, software orchestration, failures and system-level recovery. The diagram represents a general engineering framework and does not imply undisclosed details of Huawei’s implementation.
| Verification level | Core sign-off question | Typical evidence |
| NPU / chip | Does the accelerator execute its specified operations correctly? | Simulation, assertions, formal properties and numerical checking |
| Subsystem | Do compute, memory, DMA and local interconnect maintain data and protocol correctness? | Constrained-random testing, protocol checking, formal and performance analysis |
| Multi-accelerator | Do accelerators coordinate correctly under concurrent communication and synchronisation? | Stress traffic, ordering checks, collective workloads and coherency or consistency tests |
| Pod / tightly coupled domain | Does the fabric preserve progress, ordering, recovery and software-visible behaviour under sustained load? | Emulation, workload testing, fault injection, performance and power validation |
| Super-scale cluster | Does the infrastructure preserve correctness, isolation and useful progress when components fail or workloads compete? | System workload validation, resiliency testing, software orchestration tests and post-silicon evidence |
This changes sign-off. A passing NPU regression is evidence about the NPU. It does not automatically establish that the complete AI system handles congestion, software scheduling, recovery or simultaneous failures correctly.
Verification leaders therefore need to define system-level invariants before building system-level tests.
Alpinum’s guidance on risk-based verification strategy and system-level verification in complex integrated architectures applies directly to this transition: integration risk needs its own verification intent rather than being assumed away because component-level coverage is strong.
What Huawei’s Roadmap Signals for the Wider AI-Chip Industry
Huawei’s approach is one example of a broader industry direction: performance is shaped as much by systems as by individual accelerator specifications.
Huawei is using Ascend processors, UnifiedBus, optical interconnect, memory architecture and software as a combined AI infrastructure strategy. Nvidia likewise differentiates between scale-up accelerator fabrics and scale-out cluster networking. The implementations differ, but both illustrate the growing importance of interconnect and full-stack co-design.
Reuters reports that Huawei is offsetting the limits of individual Chinese chips by linking large numbers of processors into one system, that it cannot make enough equipment to meet demand in China, and that Nvidia retains a major software advantage through CUDA [3]. Software belongs to the same picture: Huawei says CANN is now developed as community-driven open source and that Ascend is a supported PyTorch backend [1]. Semiconductor Engineering’s June 2026 feature likewise describes the focus shifting from the fastest single chip to a system balanced across processors, memory and interconnect [13].
This article does not repeat the market analysis in Alpinum’s 2026 semiconductor industry outlook or the wider custom-silicon coverage, such as DeepSeek’s custom inference silicon; it stays with verification at system scale.
For semiconductor engineering organisations, that changes where risk accumulates.
The verification frontier lies at boundaries: between processors and memory, between accelerators, between hardware and runtime software, between nominal operation and recovery, and between component correctness and infrastructure behaviour.
What Should Verification Leaders Ask Before Scaling AI Hardware?
Before sign-off criteria are fixed, a verification leader should be able to answer:
- What are the system-level invariants, and are they written independently of the implementation?
- Can any resource dependency lead to deadlock, livelock or starvation?
- Are memory visibility, ordering and atomicity rules explicit enough to verify?
- Which failure modes are injected, rather than merely assumed to be handled?
- Can firmware and runtime software recover from degraded hardware without corrupting state?
- Are reset, restart and partial-recovery paths verified under active traffic?
- Do pre-silicon environments run representative AI workloads and communication patterns?
- Are privilege, DMA and isolation boundaries tested during normal and exceptional operation?
- Are performance expectations kept separate from functional correctness criteria?
- What evidence is required before system-level sign-off, and which residual risks remain explicitly accepted?
- Can every availability, reliability or performance claim about the system be traced to a defined measurement basis and test evidence?
Those questions are more useful than simply asking whether regression coverage has reached a particular percentage.
Alpinum Perspective
SuperPoD-scale AI infrastructure illustrates why semiconductor verification needs to be planned beyond the boundaries of a single device.
The appropriate methodology will vary by architecture, but larger accelerator systems generally increase the importance of risk-based verification planning, formal methods for selected control properties, realistic hardware/software workloads, fault injection, power-aware validation, emulation or prototyping, and independent review of sign-off evidence.
AI tools can help with regression triage, coverage analysis and knowledge retrieval, but they should not obscure the chain from requirement to evidence. Alpinum’s work on AI in design verification focuses on introducing such capabilities while preserving engineering control.
The wider lesson from the Huawei Ascend 960 AI chip roadmap is therefore not that verification becomes a different discipline when accelerator counts rise. It is that the object being verified changes.
The target is no longer only a processor. It is a computing system in which silicon, interconnect, memory, firmware, software, workloads and recovery mechanisms must continue to behave correctly together.
For teams preparing system-level sign-off for tightly coupled accelerator platforms, Alpinum’s pre-silicon verification team can review the verification plan and the evidence it is meant to produce. For teams building capability in these areas, Alpinum’s semiconductor verification training programmes provide further routes into formal, design-verification and system-level methodology.
References
[1] Huawei, “Advancing the Agentic World, Building a Solid Silicon Foundation,” Sep. 17, 2026. [Online]. Available: https://www.huawei.com/en/news/2026/9/hc-wang-keynote
[2] Huawei, “Peerium Computing Architecture,” Sep. 2026. [Online]. Available: https://www.huawei.com/en/news/2026/9/new-computing-architecture-peerium
[3] Reuters, “China’s Huawei says AI chip demand outstrips supply as it steps up Nvidia challenge,” Sep. 17, 2026. [Online]. Available: https://www.usnews.com/news/top-news/articles/2026-09-16/chinas-huawei-sets-2027-launch-for-new-ai-chips-as-it-targets-nvidia
[4] NVIDIA, “NVLink: The Scale-Up Network for AI Factories.” [Online]. Available: https://developer.nvidia.com/blog/nvidia-nvlink-the-scale-up-network-for-ai-factories/
[5] Synopsys, “Software-Defined Hardware-Assisted Verification: A New Benchmark for AI-Era Chip Design.” [Online]. Available: https://synopsys.com/blogs/chip-design/software-defined-hardware-assisted-verification.html
[6] “AI-Assisted Hardware Security Verification: A Survey and AI Accelerator Case Study,” IEEE VTS 2026, arXiv:2604.01572, 2026. [Online]. Available: https://arxiv.org/abs/2604.01572
[7] “Covering the Last Mile in SoC Level Deadlock Verification,” DVCon Proceedings. [Online]. Available: https://dvcon-proceedings.org/wp-content/uploads/Covering-the-Last-Mile-in-SoC-Level-Deadlock-Verification.pdf
[8] Huawei, “Huawei Launches the World’s First NPO-based SuperPoD – the Atlas 960E SuperPoD,” Sep. 17, 2026. [Online]. Available: https://www.huawei.com/en/news/2026/9/hc-ascend960-supernode
[9] Tom’s Hardware, “Huawei details AI accelerator roadmap, pulls in next-generation Ascend NPUs by several quarters,” Sep. 18, 2026. [Online]. Available: https://www.tomshardware.com/tech-industry/artificial-intelligence/huawei-details-ai-accelerator-roadmap-pulls-in-next-generation-ascend-npus-by-quarters-fp4-performance-of-the-ascend-960pr-doubles-expectations
[10] Huawei, “Huawei Unveils World’s Most Powerful SuperPoDs and SuperClusters,” Sep. 18, 2025. [Online]. Available: https://www.huawei.com/en/news/2025/9/hc-lingqu-ai-superpod
[11] Huawei, “Groundbreaking SuperPoD Interconnect: Leading a New Paradigm for AI Infrastructure,” keynote, Sep. 18, 2025. [Online]. Available: https://www.huawei.com/en/news/2025/9/hc-xu-keynote-speech
[12] Meta, “The Llama 3 Herd of Models,” 2024. [Online]. Available: https://ai.meta.com/research/publications/the-llama-3-herd-of-models/
[13] Semiconductor Engineering, “I/O Design Challenges Grow In AI Data Centers And HPC Clusters,” Jun. 25, 2026. [Online]. Available: https://semiengineering.com/i-o-design-challenges-grow-in-ai-data-centers-and-hpc-clusters/
FAQs
Huawei defines a SuperPoD as a tightly coupled computing system in which multiple nodes are connected by high-speed interconnect and unified memory addressing so they can function as one logical computer. The Atlas 960E SuperPoD announced in September 2026 is specified for up to 4,096 NPUs. Huawei’s launch materials do not state an Atlas 960E delivery date.
Huawei announced on 17 September 2026 that Ascend 960DT is expected in Q1 2027 and Ascend 960PR in Q3 2027. Both dates are earlier than Huawei’s previous roadmap.
Huawei has not defined the roles of the two 960 variants in its launch materials. In the Ascend 950 generation, Huawei defined PR as prefill and recommendation and DT as decode and training. Tom’s Hardware’s roadmap table lists 960DT with 288 GB of memory at 9.6 TB/s and 960PR with 192 GB at 2.4 TB/s; treat these as reported roadmap figures rather than confirmed specifications.
An individual accelerator contains compute, memory and control functions within one device. A SuperPoD combines many accelerators and supporting resources through a high-bandwidth fabric, introducing system-level concerns such as routing, synchronisation, distributed memory behaviour, congestion, software scheduling, recovery and fault containment.
The number of possible interactions grows rapidly as accelerators, queues, links, software processes and failure conditions operate concurrently. Bugs can depend on rare combinations of traffic, ordering, timing or recovery events that are unlikely to appear in simple device-level tests.
Yes, for appropriate property classes. Formal methods are particularly useful for control-heavy questions such as protocol compliance, ordering, arbitration, deadlock freedom, forward progress, access control and reset sequencing. Formal complements rather than replaces simulation.
Teams may need to verify the individual accelerators, local and global interconnects, memory ordering, synchronisation, DMA, firmware, drivers, compiler/runtime behaviour, workload scheduling, power management, security boundaries, fault detection and recovery.
AI accelerators depend on firmware, drivers, compilers, communication libraries, runtimes and workload schedulers. Hardware can satisfy its block specification while the system still fails because software makes an incorrect assumption about sequencing, memory, timeout behaviour or recovery.
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.
