Talking Zen 6 with Mike Clark at AMD In-Depth

Talking Zen 6 with Mike Clark at AMD In-Depth George Cozma Nov 11, 2026 20 4 Share Hello you fine Internet folks, I sat down with AMD’s Mike Clark to talk about Zen 6, the evolution from Zen 5 and what some of the differences are between Zen 6 and Zen 6c and what drove some of those changes. Hope y’all enjoy! The transcript below has been edited for readability and conciseness. George Cozma: Hello, you fine Internet folks. We’re here at AMD In-Depth, where we’re talking about Venice. With me, I have a returning guest, Mike Clark. Would you like to tell the audience who you are? Mike Clark: Hi, I’m Mike Clark, the original architect of Zen. Some people refer to me as “Zen Daddy.” I’ve been working on cores here at AMD for 33 years, and we’ve got another great one coming, so I’m very proud of the design team I get to represent here today. George Cozma: I’ve had some hands-on time with Zen 6c. Let’s talk about the change that’s happened with Zen 6 and Zen 6c, what I refer to in my piece as the Zen 6 family. Why is it different from previous generations? Mike Clark: Right. Starting with Zen 4, we’ve been going through this evolution of having two core families. Before, we were really just using the denser technology as an area play. In this generation, having learned a lot, as we were filling out that denser version of the core, we wanted to leverage it to add some extra IPC within the core. So if you look more in-depth at what we have, what used to be our classic design, we now think of as our high-frequency design. And our dense technology is now our top-of-the-line, no-questions-asked performance core, because we’ve also enabled the full L3 in that implementation, at 4MB per core. So we have 32 of those cores, 128MB of L3, and the highest IPC you can get in that core. George Cozma: Awesome. So far, one thing I’ve noticed is that the vector scheduler is a bit bigger on Zen 6c. What was the reasoning for increasing that on Zen 6c? Mike Clark: Well, that wasn’t the only thing we increased. One principle we follow is that we don’t want to create a delta between the two architectures that software has to be optimized for. We want them to have the same fit and feel, so the same optimizations apply to both. But because of its reduced frequency target, Zen 6c can have a little more capacity in the queues, since it doesn’t have to reach the maximum frequency the high-frequency core has to hit. The floating-point scheduler is just one example. There are other queues throughout the core that are larger in Zen 6c, to pull out a little more IPC and get a little more leverage in that SMT environment as well. George Cozma: Interesting. Both Zen 6 and Zen 6c build on the design you had in Zen 5, and one of the interesting things with Zen 5 was the dual decode setup. Has the front end changed much to let a single thread make better use of both decode clusters? Mike Clark: Yes. As you said, Zen 5 was a new foundation, with the ability to fetch two basic blocks and get them down the line. But it gets quite complicated with one thread running larger-footprint workloads, where some of it might be hitting the I-cache and some of it might be hitting the op cache, and you’re trying to get everything synced up. So we spent a lot of time optimizing that and making it more efficient from both a delivery and a power perspective: less power wasted, and more efficient delivery from that new front end. George Cozma: Awesome. Going down into the execution engine, I also noticed that the number of integer multiply units has gone down from three to two. Could you talk a bit about what drove that choice? Mike Clark: It really came out of the Zen 5 design, where we had a more unified scheduler. To make a scheduler simpler, you want the units it schedules into to be very uniform, and the way we had set up those schedulers, adding a third multiplier to the group it was scheduling into was easy and didn’t add complication. In Zen 6, we realized that to really scale out the architecture, we needed to go back to more distributed schedulers, which now schedule into the ALUs. We hadn’t seen much uptick from that extra multiplier on Zen 5, so to optimize the area and the schedulers, we went back to two multipliers. George Cozma: Speaking of integer multiply, on the vector side you’ve added two more VNNI units. What was the impetus for adding them, and at what point in the design did you add them? Mike Clark: As I said in the talk, these are long design programs. We weren’t designing Zen 6 to be an agentic core. When we started, no one was really even using that term. But Zen 5 was a whole new foundation for AI workloads, and we’ve always believed the core has a place in AI: orchestration, data type manipulation, smaller models. So we were always focused on making the core good at AI. It’s not going to beat a GPU, and that’s not the point. We realized we probably should have some more VNNI, given where we were seeing inference go, and the team rallied around that. It was kind of late, since these are long-lead projects and the floor plan was set, but the team rallied, we were able to squeeze a couple more VNNI pipes in there, and it was a big success. George Cozma: Again on the vector side, one of the oddities of Zen 5 was that although the wires were all there, the load unit could only do two vector loads at a time. What changed within the Zen 6 core to allow four vector loads, assuming they’re either 128 or 256 bits? Mike Clark: We can do the 256-bit loads. Since we were able to do two 512-bit loads, we already had 1,024 wires headed over there. Obviously, using them piecemeal versus as one contiguous set complicates the design. I think it’s something we always wanted to do on Zen 5, but with all the change and getting it working, we left that for the Zen 6 team, and they were awesome. We’re all really one team at AMD anyway, and sometimes things intersect at different points in the roadmap. This was the time to do it. George Cozma: Speaking of bandwidth into the caches, the L2 in Zen 5 had some oddities where it couldn’t always hit 64 bytes per cycle on reads. What changed in Zen 6 to allow that? Because I’ve been able to measure it, and it does hit that. Mike Clark: Honestly, sometimes you just don’t see some of these things. A lot of it was that we would be over-prefetching, and prefetches that hit in the L2 would be robbing L2 bandwidth. So we made sure we could sustain those prefetches alongside demand requests, reduce the conflicts, and deliver the full 64 bytes per cycle that we want. George Cozma: Awesome. Circling all the way back to the front: the all-important branch predictor. There seems to have been a reduction in branch misprediction latency, so when you miss a branch, the number of cycles it takes to recover has gone down. What I also noticed, which is really neat, is that there wasn’t any reduction in accuracy. So how did you pull off not only a faster branch predictor, but one that’s even slightly more accurate than Zen 5’s already very accurate predictor? Mike Clark: The branch prediction team, as you know, is very algorithmic. There’s lots of design space and lots of exploration, and AI has even been getting involved in helping us figure out how to optimize it. It’s a great optimization problem: the number of TAGE tables, how much information they hold, accuracy. So we set out to make a more efficient one. That was an area where we didn’t really want to grow; we thought we could be more efficient in the way we lay out the tables for prediction. And we’re always focused on our pipeline length. No matter how good a branch predictor you build, there are always hard-to-predict branches, and you’re always going to mispredict. So each generation, we’re monomaniacally focused on getting going again as fast as we can when we’re wrong. There are lots of unique tricks we pull to get that redirect back into the front end and get it flowi