AMD on progressive verification
- AMD Embedded posted guidance on progressive, system-level verification for Versal adaptive SoCs from algorithm to deployment. - The social thread referenced a related paper, EquivFusion, on hardware equivalence checking via MLIR accepted to FSE 2026. - The posts underline growing use of MLIR-based equivalence tools and system verification practices in adaptive SoC workflows (x.com, x.com)
AMD is pushing Versal chip teams to verify designs in stages, starting in software simulation and ending on hardware, instead of waiting for full emulation at the end. (amd.com) In an April 17, 2026 blog post, AMD Embedded said Versal adaptive system-on-chip designs now span programmable logic, artificial intelligence engines, and software on embedded processors, often built by different teams with different tools. The company said that makes integrated system verification one of the hardest parts of a Versal project. (amd.com) AMD said older Versal verification flows leaned on hardware emulation that stitched together QEMU for the processing system, XSIM for programmable logic, and a SystemC-based simulator for the AI Engine array. It said those simulators run far slower than silicon and require extra work to keep them synchronized. (amd.com) The newer flow starts earlier with functional simulation, then moves to XSIM-based subsystem simulation, and then to hardware-in-the-loop testing on boards. AMD said that sequence lets teams check algorithm behavior, subsystem integration, and deployed behavior without using full emulation for every step. (amd.com) A Versal device is not a single CPU. AMD describes it as a heterogeneous chip that combines Arm application and real-time processor cores, programmable logic, artificial intelligence engines, and a network on chip inside one package. (amd.com) That mix is why verification has become a system problem rather than a block-by-block check. AMD’s Versal methodology guide for release 2025.2 lists simulation flows for logic, SystemC models, high-level synthesis, AI Engine simulation, embedded software simulation, hardware emulation, network-on-chip simulation, and processor-system verification. (docs.amd.com) The social thread also pointed to a separate line of work on equivalence checking, which asks whether two versions of a design do the same thing even after they have been rewritten or lowered into different forms. An April 17, 2026 arXiv posting for EquivFusion said the tool checks consistency from high-level algorithm models down to gate-level netlists. (arxiv.org) The EquivFusion authors said their tool uses Multi-Level Intermediate Representation, or MLIR, as a common format so designs from PyTorch, C and C++, Chisel, Verilog, and netlists can be compared in one pipeline. The arXiv record says the paper was accepted to the FSE 2026 Tool Demonstration Track. (arxiv.org) AMD did not say it uses EquivFusion in its product flow, and the blog post focused on simulation and hardware-in-the-loop rather than formal proof tools. But the two posts land in the same moment: chip teams are trying to catch mismatches earlier, before a Versal design reaches the slowest and most expensive stages of validation. (amd.com, arxiv.org) For engineers building adaptive SoCs, the message from AMD’s April guidance is procedural, not rhetorical: verify the algorithm, then the subsystem, then the board, and leave full-system emulation as one tool in a larger stack. (amd.com)