speaker-0: Hi everyone and welcome to another episode of wearing ⁓ flip-flops. ⁓ hi around. ⁓ two special guests. ⁓ the first one is ⁓ Nikutu. ⁓ yeah, Nikutu. ⁓ well, you know, his predecessor was ⁓ Niku, but he flew away, and this is number two, so Nikutu, that's that's how it worked. ⁓ thank you.

speaker-1: Today we have

speaker-0: Actually the the reason he's here ⁓ with me today, ⁓ we're recording that ⁓ episode ⁓ earlier and he was not asleep and we is his when he's not asleep, it's making a lot of noise unless he's here. So ⁓ we'll we'll have this episode with ⁓ Nikuto, right? Be good. Technical issues. So ⁓ we have ⁓ a special guest with us, Frank ⁓ Shamster, ⁓ Mr. Emulation. ⁓ Happy to have you here, Frank.

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

speaker-0: ⁓ so can you give a ⁓ a bit of a background about ⁓ about you?

speaker-1: Sure, I like the little bug there on my shoulder. Gotta gotta get rid of those. I'm ⁓ executive director for strategic programs in the systems group at Synopsys. ⁓ so I deal with everything from the very early touch to software with virtual prototyping architecture. ⁓ then I say very big chunk because it's a valuable piece, the hardware-assisted verification and the verification IP. And I'm ⁓ working in that team in the product management group, dealing a lot with the narratives, how things fit together across the flow from ⁓ the early software, hardware portions through simulation, emulation, prototyping so that you get verified RTL. ⁓ I've been in it in a for a while, started with my own chip developments back in Germany did ⁓ seven chips ⁓ that all worked, luckily went to the US ⁓ in the late nineties and have been in Cadence and Synopsis and a couple of startups including in Paris for VIP and Orter ⁓ for ⁓ models and Orteris for ⁓ networks on chips. ⁓ I'm OHN engineer. ⁓ I'm also working very closely across the industry. Besides my day job at Synopsis, I'm also dealing with the design automation conference that happens every year in the summer, where I'm this year the program chair for the engineering tracks, which is kind of the user conference within DAC.

speaker-0: ⁓ well. Sounds like a lot of experience, Rad. So ⁓ for us you're Mr. Emulation. ⁓ but before maybe we dive into you know ⁓ specific questions, ⁓ just for the audience who who is not ⁓ well acquainted with ⁓ emulation, in in the past ⁓ episode we we talked about verification and some emulation, but what's the difference and why one would need emulation?

speaker-1: So emulation and yeah the the term mis emulation here I've been for the better part of the last decade in it as well, doing very very public fights around what is the right emulator and what are the right characteristics for emulation. If you compare it in the verification flow with the other engines, the end goal is to get rid of those little black dotted red buggers, the defects in your design. And when you think about it from an hardware verification perspective with system very log definitions ⁓ of the design, you have various techniques to do this. You can simulation where the execution is on a computer, a standard host, and X eighty six or ARM based system. that's kind of the ⁓ go to how we all grew up back in the nineties. That's where how I verified the chips. You have formal verification where you don't simulate. You have ⁓ a this design space where you formally with properties ⁓ prove that certain states ⁓ can not be rate reached and then simulation because of the complexity of the designs we are dealing with has huge advantages when it comes to Test benches you can have very complex ⁓ as in your last episode with Specman UVM and so forth, you have very complex ways to directly look into the design. Debug is great because you have all this observability. You can go into all instances, all nodes very easily. The ⁓ only downside is is the speed of ⁓ simulation caps out. It's typically in the hertz to kilohertz range. And when it comes to driving designs with software, and that's first the lower level drivers, but then even a standard Linux boot has basically millions of cycles to be executed, it would be way too slow to get there. And that's where those hardware assisted verification engines fit in. ⁓ emulation and fpg based prototyping where you will get much faster speed so you run in the megahertz range and tens to hundreds of megahertz in fpg based prototyping. ⁓ the thing you trade for it is that you now run in a hardware engine so typically things like ⁓ debug insights aren't as ⁓ flexible as the ⁓ as you have it in simulation. So each engine has their own advantages, very specific use cases within the verification flow.

speaker-2: And as Frank, as as the chips are growing, ⁓ can you share from your point of view the statistic of ⁓ you know, trends of simulation versus ⁓ emulation?

speaker-1: Sure. ⁓ so we have the slide here. This is courtesy of the ESDA, the electronic system design automation consortium where everybody contributes their data. ⁓ all the EDA vendors. ⁓ the the blue part here is simulation and ⁓ you can see here this has been over the last thirty years. It has been growing very significantly. It's ⁓ almost a billion dollar market and twenty twenty four for simulation. one of the interesting bits ⁓ for ⁓ the remainder of this ⁓ category which is in the ESDA reports called two point three logic verification. ⁓ you have these other components in it like dynamic verification, hardware assisted verification and others and ⁓ the reason why we basically can't call out hardware assisted verification by itself, ⁓ is that when you have ⁓ less than or only up to three renders, you basically don't call out that category ⁓ specifically. ⁓ you basically do only the aggregate. But this difference there between simulation and the full logic verification ⁓ is the is very much dominated by hardware assisted verification. So it's it's a very big chunk and contribution there. So what you see in this graph are a couple of like ⁓ bumps and so forth. You see in 2000, 2001 originally hardware assisted verification was really built ⁓ for and used a lot by the CPU vendor. So you have the guys doing ⁓ X80X, X eighty six CPUs and so forth very early doing that, there's a lot of graphics going on in that domain. If you look into the twenty tens, the bump there where hardware assisted verification grows quite a bit, that's probably the mobile bump, I would say. ⁓ so that's where you have people realizing you really need to boot your operating system on your mobile device before you tape out your chip. So at that time people are starting to really make software the a part of the tape out considerations that you hold your tape out if the hardware software isn't working together and you can't boot your OS early and for that you need those many cycles that you get in emulation and FPGA based prototyping. And then of course

speaker-0: The the trend that we see here Frank is that ⁓ emulation starts to ⁓ grow beyond the standard verification as a solution to to verify ⁓ chips ⁓

speaker-1: Two verified chips, but the software's a driver. Yeah, but the software's a driver, absolutely. So the twenty nineteen bit, that's really where AI comes in, right? So those huge ⁓ growth factors, that's all the data centers. And now you really come to the point where you need to run AI workloads, software workloads before you tape out to verify that the hardware works for one, but also to optimize performance, power and things like that. We'll go into the use cases here in a second, but ⁓ that's where hardware assisted verification really shines. And it's a combination of emulation. I know you you refer to it as emulation, but also a very significant chunk of it is FPJ based prototyping. So we kind of summarize it as hardware assisted verification.

speaker-0: Okay, so can we talk about emulation use cases? Well when we talk about emulation, ⁓ you talked a bit about software development, about ⁓ software bring up, ⁓ regression, power, fault ⁓ simulation. Can you talk about you know those aspects and use cases a bit?

speaker-1: Sure, sure. So in the old days, when we started, haha, ⁓ we it was really just about the functionality mostly, right? Does the design work? I remember my first chip back in the nineteens was actually a chipset for motion estimation for video encoding. ⁓ well I I was happy when my FFT chip and the what was it, the inverse discrete cosine transformation chips and those different elements When they just produce data, right? So I was ⁓ happy with just the functionality. As you've seen over time how all this has grown, people really want to shift left ⁓ as much as they can. What we mean by that is the type of use cases that you would ⁓ deal with when the Siticon comes back and where you would be experiencing a pivotal moment as a project manager if your chip doesn't really work are things like power. Does the software actually work or do I have to do workaround workarounds and software? There's a great segment of Jensen Wang of Nvidia Fame about ⁓ their ⁓ pivotal moment in the 90s. ⁓ you can put the link to the podcast in the show notes. the ⁓ the story goes and he describes this quite colorfully that they had a certain amount of runway to ⁓ for the company to get to silicon and to get ready. So they spent a significant portion on emulation at the time because they needed to make sure that the software works when the chip comes back. And even then the software had to do like some workarounds, but they got it working and worked with all the the software community to avoid certain special combinations of the software. So it's a quite colorful and interesting, insightful story, software being such a big component of the verification. So you have driver development, you have workload specific architecture. So today from the story with Jensen in the nineties, ⁓ you really have this full flow where you go from the IP that has local drivers on the PCI Express to Linux booting on things like the Neoverse cores from ARM integrated with our PCI Express, DDR, LPDDR, the and then connected over UCIE between chiplets. That goes into architectures that that are packaged in chiplets and multi-dy designs today. That scales up into ⁓ servers and scales out into data center connections, right? So you have just a lot of software going on there. And the use cases here are really when you look at our portfolio here of different hardware assisted engines from emulation for scalability and density, which is a Zebu server system on the left, to the systems that have ⁓ the best ROI because you can switch between emulation and prototyping use cases quite easily. You see kind of the six core ⁓ use cases left and right. You have early RTL verification. That's basically an extension of what you do in simulation and you use debug environments to eradicate those little buggers ⁓ for Hardware software verification, you have regressions with speed matters, you do software bring up with virtualization around it, and then on the right you have the other. I just want to stop you for

speaker-0: second ⁓ to ask you about you know hybrid and and virtualization can you say a few words about how the machine works with kind of ⁓ verification environment and how it integrates what works where in the virtualization world

speaker-1: Sure, sure. So ⁓ as I pointed out, you have ⁓ earlier with simulation you run your your design, your execution on a software host, an x eighty six or an ARM based system, where in emulation you take the design and you map it into a hardware execution, a purpose build environment that runs much, much faster. So in a hybrid setup, which is a software bring up bit on the left, you will do things like taking models of the compute subsystem that run natively on the host. So you be boot a Linux there. And then you take, for example, a GPU accelerator where you need more fidelity and map that into the hardware engines and then you use what we call interface protocol solutions here at Synopsis connections that transact from the higher level description ⁓ at the transaction level into the signal level RTL. So you will have a read and write instruction coming from the software that executes on the host. And then that read and write from a memory address, for instance, is translated into the wiggling signals that you need at the signal level RTL and Verilog that's executed. in the emulator and that of course can happen with PCI Express, with Ethernet, with with MIPI, with all these connections where you connect between the two systems. And that gives you a balance of fidelity ⁓ with higher speed in emulation and the ability to abstract away parts of the software in a virtual environment.

speaker-0: Thank you.

speaker-1: So then on the previous slide, just to finish up on the right hand side, the item with the performance analysis, and that's really huge, right? Where on the left it's a lot of virtual connections and it's all about the RTL. On the right, it's about these advanced use cases, power, performance. We can basically run very long sequences to get power analysis. We then connect real physical hardware, like we connect a real PCI Express ⁓ environment to the system with what we call speed adapters, and then you even run compliance and certification and you have special use cases ⁓ emerging here like fault emulation software ⁓ with physical ⁓ representation in real number models. So there's more and more use cases. Coming ⁓ in the hardware-assisted verification environments. That's why we are calling it at this point software-defined, hardware-assisted verification, because you add more and more items in software. So on the next slide, if you ⁓ look into how this is set up, ⁓ I mentioned two systems earlier. the Zebu server systems in our environment are meant for the very large designs they have the best ⁓ scalability, the best density. So it's ⁓ cob probably the best ⁓ total cost of ownership for those. And those go up to like ⁓ well beyond sixty billion gates, right? So that's where the ⁓ the very large data center designs live.

speaker-0: Actually what what we wanted to ask on on you know this ⁓ this slide, ⁓ yeah, both of us. is the advantages and and disadvantages of each of the platforms.

speaker-1: Yeah, so it it's really I would not call call it disadvantages, it's really sweet spots. so on the left hand side you have the emulation use case. Here it's all about somebody is interested in emulation. The cabling there is for design flexibility. So what that means is in emulation you will have tasks and you will relocate the tasks that you run in your emulator across different regions of the emulator. So given that such a design at this point goes up to like twenty-three billion gates in emulation when you scale it up, the capacity of these environments, think of it as a purpose built server for ⁓ hardware ⁓ assisted verification. You have lots of smaller design subsystems that are Only a billion gate and then you run several of those in parallel. So emulation that's it's all about the design flexibility and the cabling is done this way that it's easy to relocate. On the right hand side, in contrast, when you really want to squeeze out performance, right? The left side runs let's say typically between five and ten megahertz via FPGA based, ⁓ that gives you the fastest speed. On the right hand side ⁓ for prototyping, now you find the critical path in your design and ⁓ or the multiple critical paths, and you do the cabling very specific to optimize for design performance. So you lose some of the flexibility of moving back and forth and and relocating ⁓ verification job within the system. But you get the absolute highest performance. So when you look at these systems with that are set up this way, you basically can get into the interface speed, right? So we have systems running well beyond fifty megahertz when it comes to ⁓ the interface verification of things like PCI Express, Ethernet, MIPI and so forth. And

speaker-0: When we say EP ready, that's the cabling that allows both sides to run based on what's best for the use case scenario?

speaker-1: Correct. EP ready hardware means that the same box, so if you look into the six boxes on the right hand side, that building block there is essentially the EP ready hardware, which by way of cabling and equally important by way of the software stack you execute on it, ⁓ can ⁓ run in either emulation or prototype remote, right? So you have ⁓ Emulus emulation use cases, that's the RTL verification, the ⁓ regressions, even the performance and power analysis, you have this on the left, that's one software stack. If later in your design now you want faster speed for software with a physical interface connected, then you switch it. ⁓ if you need the extreme performance, you do some recabling, but we have customers also switching To the HAPS protocompiler software stack with the prototyping use cases on it without recabling, that ⁓ then gives you the performance to deal with things like ⁓ software execution and ⁓ compliance and certification. So you see these use cases there, the user design mapped into those engines that eventually then are connected and executing and you have different use cases for emulation and prototyping and we have a detail on this on the next slide. If you combine

speaker-0: Before we before we move to the next slide, just one question here. ⁓ Comparing you know the three words, the prototyping, which is ⁓ FPGAs, ⁓ the emulation, which is also FPGAs in this case, right? And verification. So you know, debug debuggability-wise, is there a difference between each?

speaker-1: Absolutely. So it's debug has a couple of components. ⁓ you need to collect the data, you need to transmit the data ⁓ to the host, and then you need to visualize and and analyze with scripts the data on the host by looking with machine learning and and AI into the traces or just looking at the waveforms. For emulation ⁓ the debug is much Better typically than in prototyping because the difference between the two setups is in the setups synchronicity. What do I mean by that? On the left hand side we have what we call synchronous setups. Every every part of the user's design is tied to a ⁓ to a master clock, if you will. So if you proceed one clock cycle. In emulation, then everybody proceeds one clock cycle. All the interfaces, all the processors, all the accelerators. That's great for debug. So you can basically then read out a ⁓ a signal ⁓ a set of signals, you can force signals and so forth. That's all in emulation. On the right hand side, for prototyping, the setup of the design is asynchronous. It's mapping and replicating essentially what happens in the user design, every block is executing freely and coordinating like they would in the actual design through transactions through AXI or through signals between the different blocks. So that gets you to this much higher speed, but because you now have higher performance it is ⁓ and because you are asynchronous debug is getting a little bit more ⁓ challenging in terms of how do you read out ⁓ those items into trace buffers and how do you then ⁓ coordinate those items.

speaker-2: I had a question. ⁓ so you know, part of our audience are simulation guys and others probably are hardware guys. How does the ⁓ flow from running simulation change when you ⁓ want to move to hardware assisted verification? You know, in terms of capabilities, can verification engineers that did simulation in the past easily move to ⁓ hardware assisted? And also about the methodology, like what do you do with ⁓ if you have like test bench code, VIPs? UVM testament, whatever, can you leverage that and reuse that in a hardware assisted context?

speaker-1: Absolutely. So that's a very critical flow element. How do I transition from one engine to the next? What we do in Synopsisland, ⁓ we have this front end that is ⁓ shared between the different engines. So if you use VCS and if you use Zebu, ⁓ there's you have the same front end basically reading in the code, elaborating, linting, all those good things. So it's the same RTL you put in there, but then when you run it in emulation, you do this second level there, the interface protocol. So you connect ⁓ memory models that need to be replaced. You have you will take some elements potentially away, ⁓ you you have transactor models to connect to a virtual setup. ⁓ But it is the same design that goes into emulation and emulation is kind of white glove, if you will. It's a flow that is automated, the RTL is ⁓ compiled, it's ⁓ with our front end ⁓ partitioned into the different chunks that then get loaded into the Vivado software for the AMD FPGAs and mapped into the FPGAs. We're working very closely with AMD to optimize this flow so we have our own version of Vivado and so forth to make this all faster. And ⁓ test benches can be reused, absolutely. So you will ⁓ connect things. There's transaction based acceleration where you ⁓ connect your test bench. It's all becomes a question of ⁓ how much time the design doing execution spends in the test bench and how much time does it ⁓ So ⁓ but yes, you you have a flow and methodology there to transition between the engines and not only that to then collect the data. So the debug data is ⁓ put into databases that run across so that you can look at things like coverage and debug across the engines.

speaker-0: Time is ⁓ almost ⁓ up for this chapter. I think we'll have to call you ⁓ again ⁓ to to finalize all the things that we wanted to ⁓ to discuss. So ⁓ anything to to conclude this chapter guys?

speaker-1: Well to wrap it up, ⁓ emulation is a ⁓ key part, hardware assisted verification is a key part of the verification flow, which is really something you cannot live without these days. So prototyping and emulation are key to get your use cases into the pre silicon phase, things like power software and so forth. And I think over time this will only grow closer together with the simulation and even the formal flows as all those data components have to be combined holistically to then look at coverage, debug and so forth. So exciting times ahead.

speaker-0: Thank you so much, ⁓ Frank. It was a pleasure having you. We already have you know questions lined up. I wanted to ask you ⁓ you know about differences, ⁓ how startup would utilize ⁓ machines and you know how big enterprise and what's the difference, but let's keep that for ⁓ our ⁓ next episode. ⁓ so it was really pleasure having you here. Next episode.

speaker-1: Thank you. Amazing. Thank you.