speaker-0: Hi everyone, welcome back to another chapter of ⁓ wearing ⁓ flip-flops. last time we had ⁓ Frank and we talked about ⁓ emulation issues and we kind of ⁓ stopped in the middle. So ⁓ happy to have you here again, Frank.

speaker-1: Happy to be here. Thanks for having me.

speaker-0: ⁓ let's dive right into the question that we left off with. You know, what's the difference between a small startup using emulation and a big enterprise ⁓ using the same?

speaker-1: Yeah, first of all, I think they are if you look at this, it's really about the design size. ⁓ the for startups it's especially interesting to not have to make an emulation versus prototyping purchase decision early on. So our EP ready hardware ⁓ that allows you to reconfigure between emulation and prototyping use cases as you see in the top there, by changing the software stack. And by doing cabling either optimized for design flexibility or for design performance, throughout the project they can change the allocation of your design, which I think we have a slide on that, where essentially you can as a user ⁓ f grow your design from the IP and subsystem verification to the full chiplet and multi-dy. verification with software, there are bugs and there are different types of bugs at every phase. Hardware assisted verification is the bridge between what you do traditionally in simulation and then the advanced use cases like power and performance validation for which often people were relying on silicon. So a startup will perhaps only do a subsystem and not the full chip. But even a big company, our very big users also really enjoy the EP ready reconfigurability, ⁓ because everybody has to do IP subsystem verification first before you do the full chip verification, right? So we have actually customers telling us if I find a bug at the full chip that verification or even in the multi-di phase. That should have been found at the IP or subsystem phase, well I'll I'll look at my flow and fix it, right? So you mentioned

speaker-0: ⁓ multi dive. ⁓ what's that?

speaker-1: Multi-dye ⁓ chiplets. So ⁓ as we are approaching the radical limit in design size, so the physical limit of how much ⁓ silicon estate you can actually manufacture with the right yields, but also as we are approaching a phase where it's not always the most aggressive technology node that gives you the best results, so you want to bring in For physical interfaces, some 16 nanometer components or 7 nanometer components with your 3, 2, and angstrom ⁓ level components. Chiplets really are the raw dyes that are integrated on substrate. They have many different technologies: 2D, 2.5D, 3D stacking. So on the right-hand side, you see the memories as raw dye. combined with accelerators compute on a substrate and they use standard interfaces like UCIE, for example, ⁓ to connect those chiplets like you would do on a board ⁓ in the past, but now it's all within one package.

speaker-2: And how how do you in terms of hardware assisted verification, what is different when you ⁓ you want to verify a chiplet or a stack die versus ⁓ a chip? I remember from my synopsis days for simulation, we actually had a solution of different VCS processes running and communicating through sockets or some other technology. ⁓ does it change also for ⁓ hardware assisted?

speaker-1: Absolutely. So one of the ⁓ things we're doing there is we're using modular approaches, modular ⁓ hardware assisted verification. So if you look at these boxes here, the different setups in emulation and prototyping which you reconfigure over time by re cabling and ⁓ moving a different software stack on it. These boxes also can be representations of the chiplet that you combine. So for example, one of the boxes in prototyping can be a compute subsystem. It's ⁓ configured already. So it's kind of like don't touch in the old synthesis days where you had blocks that you don't ⁓ touch anymore. So you don't need to recompile. You know that system works. And then you connect it using the same cutline, the same interface you would do between the chiplets or even for complex chips, very large SOCs. You will connect it through an AXI over a PCI Express interface between the different boxes as a setup, or you will use UCIE, the standard chip interface over PCI Express to connect the boxes. So the verification setup mimics the modularity of the chip Multi dye design. Mm.

speaker-0: But again if I'm taking that to the sorry Frank, did do you want to say anything?

speaker-1: No, I just ⁓ you can ask a question. I just wanted to on this chart you very nicely see the different use cases we talked about, right? So you start with a specific setup, you have three projects, you have an initial assignment of your resources to those projects. When you're done with the IP subsystem compliance checks in the top, you you take the project two. hardware move some of it over to project one and go back and forth and ⁓ to your own point. ⁓ that then comes into play. You have brought up ⁓ a subsystem that's now working ⁓ without new changes necessary in the prototyping setup. So you don't touch this anymore and you connect it as a modular component in your verification setup.

speaker-0: I think it shows ⁓ nicely and and blend into the question that we asked ⁓ also ⁓ before, the difference between startups using emulation ⁓ and big enterprises ⁓ using emulation. ⁓ I'm just wondering, I mean, if a startup is is building, you know, a huge ⁓ chip, is there a difference or you know, what do you see?

speaker-1: Well, I think for startups it's very important that ⁓ over time you can reassign your resources for hardware assisted verification to the use cases that are most pressing at that point doing the project. I mean ⁓ the for big companies that's also true. They will do ⁓ verification of the subsystem, they will do verification of the IP and then integrate the full chip. But for a start Let's face it, the big a lot of the big companies are using multiple vendors and they're using ⁓ much larger setups. For a startup, I will have the situation that later in the project I, for example, need more prototyping because now I have users ⁓ running the software updates ⁓ as I'm getting in the last three months before tapeout. And so I'm reconfiguring my system from emulation to more prototyping to serve more users. Those are very, very important abilities to switch between the different use cases. And they're especially relevant in a startup where you count and turn every dollar you invest, right? So this ability to reconfigure gives you the best ROI.

speaker-0: And just ⁓ you know talking about this topic, so if a startup ⁓ purchases, you know, ⁓ a large enough ⁓ emulation machine, ⁓ can it be cut into chunks if you have different teams compiling different parts of the ⁓ machine and utilizes the same machine ⁓ with multiple little teams?

speaker-1: Absolutely. So we have ⁓ I mean we just came out of ⁓ SNUG ⁓ here, the Synopsis user group, ⁓ last month and ⁓ we had customers talking about ⁓ like a hot startup here in the ⁓ US is ⁓ etched AI. They were talking about how they use up to s forty software developers that are running the emulation system in parallel. So the way that works is that you really have ⁓ the box, ⁓ the configuration that may go, let's say, up to 23 billion gates, and ⁓ you have ⁓ now the ability to cut it into chunks. So you have different users accessing different ⁓ parts of the design. And then there's also very complex and advanced scheduling on top where you basically have your queue of tasks. that you run into it. So you you shoot off ⁓ tasks that are then mapped into ⁓ the engine as it's available. And you even reassign priorities. Hey, this software ⁓ routine needs to be checked. stop everything else, pause it, ⁓ safe restore later, and then run ⁓ the environment ⁓ for this high priority task ⁓ highly prioritized. So yeah, it's you're very flexible. in the assignment of your tasks to the hardware resources.

speaker-2: Where where does synopsis ⁓ emulation fit best here?

speaker-1: So it emulation and prototyping have ⁓ very different characteristics as we discussed last podcast and today, ⁓ with respect to the setups, synchronous versus asynchronous setups. we fit into all those domains, but this chart is worthwhile looking at, digesting it a little bit more just to understand the different design sizes we have reached at this point as we are in the mid twenties in the early in the age of AI, right? So you have the

speaker-0: Frank, in your answer, sorry, ⁓ just ⁓ in your answer, can you also touch, you know, the the difference because ⁓ each emulation platform and we don't talk ⁓ have to talk about, you know, ⁓ let's keep it general, but some emulators are CPU based, some emulations are ⁓ FPGA based. ⁓ and you know, the context of where synopsis emulation fits best, let's talk about, you know. ⁓ the designs and also touch you ⁓ the differences between ⁓ the FPGA based or the ⁓ cheap sil the custom silicon based emulation.

speaker-1: Sure. So first, if you look in this chart, you have different design size ranges. You have the very large designs, those are typically the data center designs. That's the bleeding edge where you have ⁓ at this point we're in twenty twenty-six as we're recording this. ⁓ you have the Ruben GPU announced. That's like three hundred. ⁓ 30 billion transistors translating to 84 billion gates. But not everybody is that big, right? So the ⁓ mobile designs, if you look at mobile and consumer, they kind of ⁓ they they have about a order of magnitude less capacity requirements and then you have much smaller designs like IoT designs. So to your question, where do we fit First of all, prototyping typically doesn't go to the full ⁓ tens of billions of gates set up because you have in prototyping setups to deal with this asynchronicity between the different blocks. There's much more ⁓ manual optimization going on. Emulation fits across all these ranges and then ⁓ as you know in the industries there are different ways of emulating We at Synopsis have FPGA based systems. ⁓ there's also processor-based systems out there where you really have a array, ⁓ a massive array of processors ⁓ executing the hardware assisted ⁓ verification environment. Then you have kind of a mix ⁓ with ⁓ custom FPGA implementations. ⁓ we all are applicable to the very big designs and the smaller designs alike. There are differences sometimes with respect to ⁓ debuggability, compile time and so forth. So our ⁓ synopsis domain, if you look at the users that ⁓ report on their usage and exchange best practices with other users at things like SNUG and DAC. ⁓ you have a good mix of people doing the ⁓ the very big designs. ⁓ you had this snug, you had people like Intel talking about the very large designs, but then you have accelerators like ⁓ etched ⁓ was there, you have people like Rebellions ⁓ talking about accelerator designs that aren't quite at the ⁓ eighty billion gate ⁓ Ruben. GPU level. So it's a good mix and emulation fits across all of them. And prototyping typically stays at ⁓ at at a more limited ⁓ design space. So we see these at this point going to the ⁓ a ⁓ multiple billion gate range you had NVIDIA talk about this at ⁓ SNUG as well, how they're using prototyping for ⁓ the subsystems really there. ⁓ and then also very important these days because the ecosystem's also complicated, ⁓ taking prototyping and emulation to interact with their customers, right? So have, as we discussed earlier, a subsystem represented and then ⁓ interacting with the customer and partner on that. So we fit well here. This is an eye chart. Normally it animates. You have in the top the different applications, ⁓ which are your designs, you have hardware and software. Those are ⁓ those hardware portions are mapped into the engines, like the ZBoot server engines for best ⁓ density and best scalability, and the EP ready engines on the right, which are for best ⁓ performance and best ⁓ reconfigurability. They're connected to the virtual and physical world on the right. They're connected to other tools on the left that are ⁓ for example the connection to virtual prototyping or the connection to simulation for ⁓ simulation acceleration use cases. And then you have this verification to system use cases in the middle there that are ⁓ shifting left the ⁓ tasks that you would typically do in silicon into the pre-silicon phase. And ⁓ if you go to the next slide, it's all integrated here with the other ⁓ engines, right? So that's kind of the takeaway slide I would say you have ⁓ unified debug and compile across the virtual formal simulation, emulation prototyping engines. They all are connected. ⁓ they use ⁓ models and protocols that can move between the different engines, right? So you have for protocols, for example, you have virtual models, you have ⁓ VIP in simulation, you have speed adapters ⁓ for emulation and prototyping, and then you connect all this data to look at coverage, debug. across those engines. So emulation and prototyping, the hardware assisted components are a very central and important part, but it's really the combination of all the engines that will get you the best verification results.

speaker-0: Sounds amazing. ⁓ I think we're almost done. Is there anything that we didn't ask that we should have?

speaker-1: I think we had it over the two episodes we had a great we touched on a great set of data. ⁓ perhaps to look forward a little bit, ⁓ we we haven't talked enough about AI and ⁓ this is the er era of AI, right? So perhaps to add on top of it here you the all of this has AI components ⁓ on it. You ha see this with the brain and the cloud in the upper right, kind of as a ⁓ as a little badge on this, it's kind of normal that everything does that, right? So there's a lot of ⁓ agentic AI, we call this agent engineers at ⁓ synopsis going on where you have ⁓ this is a great domain ⁓ to ⁓ to watch and look forward to more changes where essentially now When it comes to the knowledge assist, that's the first thing ⁓ where you interact with your engines. Hey, why is this path not closing? Why am I getting only ⁓ 3.1 megahertz? I want more. Where's my critical pass? So there's a lot of ⁓ knowledge and runtime assistance to now ⁓ going forward, ⁓ much more AI coming here. ⁓ with analyzing the data. We call this the workflow assistance where you have agents looking into figuring out root causes in debug, ⁓ helping users to get to eradicating those little buggers much faster by applying AI to it. So that's the the big ⁓ new set of techniques that are are built on top of all this.

speaker-0: Sound amazing. I do have a question regarding that. ⁓ so you know, in the simulation side, ⁓ we we see everything that you just talked about with AI ⁓ starting to ⁓ you know take more and more ⁓ place, but ⁓ everything is kind of ⁓ approachable. ⁓ I'm struggling to understand, may maybe you can, you know, ⁓ explain that. ⁓ when you run on ⁓ an emulation with an emulation speed or with fp, the speeds are you know much faster. ⁓ and I think you know it could be a challenge gathering all the information of everything that happened in order to analyze live. So do you have any solution to do that or we're talking about running scripts, ⁓ seeing how to ⁓ extract the best of the machine and then when you stop and have a window that you debug with, look at that window. ⁓ I guess ⁓

speaker-1: Yeah, so to give you some examples there, ⁓ it so you're absolutely right. ⁓ the ⁓ usage of these tools was already kind of automated. There are systems in place with which you decide this task is best achieved in simulation, this other task is best achieved in emulation and prototyping because I need the speed for software bring-up, for example. Think of this as a big system with an MCP, the ⁓ the control ⁓ that that controls all the various agents. ⁓ and then agents in all domains being able to to become what we call at synopsis agent engineers. So instead of ⁓ calling somebody up, hey, ⁓ run this task in that configuration. ⁓ we we have these agent engineers learning how to set the settings for compile and ⁓ implementation and verification, how to collect the correct datasets for ⁓ debug out of ⁓ the emulation environment in Zebu and then ⁓ connect those ⁓ back up. ⁓ into Verdi for ⁓ combined debug, right? So there's so much data ⁓ that is collected where you then use these agents to to skim through the data and figure out what's relevant for the debug task, the root cause analysis at hand. So lots of ⁓ moving pieces here how these different ⁓ agents integrate but it's a very very ⁓ interesting space with huge productivity improvements just by way of knowledge assist, by runtime assisting of how to best execute this engines and then the whole workflow assistance on how the things combine. So yeah, taking agents, for example, collecting the right data from the different engines and then present them to Verdi to the user to confirm the root cause for a defect. So it is a very, very fast moving ⁓ fascinating new world.

speaker-0: Sound exciting. ⁓ Is any anything else we ⁓ wanted to check with ⁓ Frank?

speaker-2: I think we've covered ⁓ a lot of ground here in those two chapters. ⁓ it's always fascinating to talk about ⁓ emulation, simulation, all those Asian words.

speaker-0: Rantos. Thank you so much for ⁓ being ⁓ here with us ⁓ with us today. And ⁓ if we don't see each other in person ⁓ before Dak, so ⁓ I guess ⁓ see with Dak.

speaker-1: See you at Dak. Yeah, that's coming up in July and see you in Long Beach. There will be a lot of interesting ⁓ techniques. There's a whole track dedicated to verification in the engineering track. So ⁓ I have the privilege to have seen the program already and it's it's it will be exciting in Long Beach. So see you there.

speaker-0: you there and thanks again. Right. See you on the next episode.

speaker-1: Thank you. Bye everyone.