speaker-0: Welcome to another episode of Wearing Flufflops. I'm Ron and with me ⁓ Yaron, hi. Today we wanted to do something different and start with a quiz. Yaron, can you indulge us?

speaker-1: You're all hey guys.

speaker-2: Yeah.

speaker-1: Yeah, so we thought today starting a little bit differently, I'm gonna play a song for you on my acoustic guitar. And your job is to identify the song, to guess the song name. So ⁓ I can give you a quick hint that it is somehow related to today's topic. ⁓ so let's see if you can ⁓ detect the song name.

speaker-0: ⁓ well let's see the recording. Go for it. ⁓ Bad you're on. Now for those of you ⁓ who managed to guess that, that's ⁓ great, shelve it for a moment. ⁓ we'll be right ⁓ back in you know a couple of slides ⁓ with the answer. But before that, I wanted to talk about something else. ⁓ keyboards. So ⁓ the keyboard layer that we are all used to today ⁓ is called QWERTY because of the letters, ⁓ Q W E R T fly.

speaker-1: Thank you.

speaker-0: ⁓ but ⁓ back in 1936 there was a different layout ⁓ called ⁓ Dvorak and the difference between those two ⁓ was how the letters ⁓ were set on the keyboard. ⁓ in the Dvorak, which was designed for speed and and comfort, and ⁓ you know you can type much ⁓ faster and and you know don't get fatigue. ⁓ Most of the ⁓ letters that are ⁓ you know widely used were on the home run, which was the you know center line ⁓ where your fingers are. On the QWERTY, on the other hand, it was designed to prevent mechanical ⁓ typewriter jams. So it was less about the UN and more about the machine. So we have here, you know, two types of ⁓ keyboards. One is much ⁓ better for speed and comfort ⁓ and the other is much better for the machine and ⁓ one of them won. ⁓ let's see those jobs side by side.

speaker-1: Yeah, and the the one that won was not the one that was better, let's put it this way. As we all know, we are still using the query layout ⁓ most of the times here. And ⁓ when we look at the reasons why, ⁓ part of it is because of timing. So the Dvorak layout came ⁓ came along in the ⁓ Great ⁓ Depression era. ⁓ not a really good time for people to make ⁓ capital investments. And yeah, and a few years later there was World War Two. Again, not a good time. People prioritized ⁓ reliability over experimental technologies. And there's also the notion that ⁓ technology has to be tenx better ⁓ in order to really ⁓ proliferate. And nobody wanted to invest ⁓ something like t a hundred hours of training just to switch to a different type of keyboard. So Quarity is still around.

speaker-0: Thank you. So we we had the the good enough, we had you know a lot of ⁓ typewritering ⁓ machines that were already QWERTY and you know making a change was a big ⁓ investment. And ⁓ there was also the gap of you know, most of the people did not know well to type on Vorak and they were just used to the QWERTY keyboard. ⁓ so you know Keep that in mind also because it it it is tied to our topic today. And back to the song that you played so ⁓ nicely. so for those of you who guessed ⁓ the song name, go buy yourself something nice. ⁓ for the rest of us, the the song name is The Winner Loses. ⁓ it it was out in nineteen ninety-two. ⁓ and that's by ⁓ Body Count. So ⁓ it's it's a great ⁓ rock ⁓ ballade. ⁓ and we also wanted to t thank ⁓ Tiberio ⁓ for bringing this topic out. ⁓ Tiberio you asked us to talk about the downfall of Specman and E-language and I'm not sure ⁓ yet whether it's the Dvorak or the QART but ⁓ we we'll talk about that in a in a minute. So yeah, that that's about ⁓ that.

speaker-1: And now for our special guest for the show, today we have ⁓ Chico Zadik. ⁓ he's one of the ⁓ really the verification experts out there for a long time. ⁓ he probably doesn't know it, but I went to his Specman class twenty-three years ago as a junior verification engineer from National Semiconductor. I remember it

speaker-0: Great to have you here. Thank you so much for

speaker-1: Good morning, it's a pleasure. and really ⁓ Chico is one of the experts on methodology and languages, Beckman, Mr. Verilog. And ⁓ maybe Chico wa maybe you can introduce yourself quickly and then we can dive in.

speaker-2: Okay, my name is Heskell Sadik, but everybody called me Chico. This is a nickname that ⁓ my sister ⁓ gave me when I was very young. Anyway, I graduated university at 76, meaning I'm about 50 years in this business. I started as a boat design engineer at the beginning and then I decided that I like software better. I moved to software and from there ⁓ I went to a silicon company named National Semiconductors and I was ⁓ the head of the software group there at that time.

speaker-0: Everyone started from national semiconductor. At least everyone on today's podcast.

speaker-2: yeah, it was a a great company at that time in Israel but ⁓ it disappeared eventually. Anyway, ⁓ and then we start ⁓ I was moved from from my my job as a software engineer into the verification because we had a lot of bugs and problems in the the ch the chip that we taped out. And from there I kind of fall fall in love with this topic and ⁓ I stayed there for a while. I was about thirteen years a national semiconductor and then I joined a startup company called Vericity, which actually invented Specman ⁓ as a langu as a tool and ⁓ the language E as a as a verification language. I was a VPR and D from day one. And I quit ⁓ right before the IPO. ⁓ I was exhausted from ⁓ many hours of work and I went Yeah And then I went to ⁓ Intel where I continue working on verification methodology definition and ⁓ I worked both in ⁓ Specman for ⁓ for about half the time and then in UVM about half the time and I was stayed there until last year. And ⁓ in the last year I'm ⁓ trying to do some methodology improvement at Nvidia Israel.

speaker-0: Let's dive right into you know question that ⁓ we were asked to to ask ⁓ you and you know the first ⁓ question that comes to mind is productivity numbers. You you used both you know spec-man and UVN on kind of ⁓ similar ⁓ designs. so you're you know one of the few people I think in the world that has the perspective of ⁓ the good and the bad for both. ⁓ so can you share with your audience you know the difference between those and some productivity numbers.

speaker-2: Well Spekman was the first ⁓ verification language that came out and then later on ⁓ it's actually the same company, Vericity actually invented the OVM and from Delder the UVM. As such it is a language which is targeted for verification. That's why all the construct and all the the the infrastructure and the ⁓ development environment was really from the early beginning was aimed for verification. And I think in eventually it became ⁓ a b a best fit for what we need for verification. And even UVM with all the consortium behind it and so forth are getting closer every time to specman but I I don't think they can reach the the richness and capability that SEC Specman provide for a verification.

speaker-0: I if you have to, you know, sanitize the essence of what's different. ⁓ what's different?

speaker-2: ⁓ Specmin has two and main ⁓ capabilities that ⁓ rare and very few languages in the world really use that. One of them is the the aspect-oriented ⁓ capability and the second one was ⁓ the capability of running at the same time some of the code com as compiled to native machine as ⁓ you ⁓ you are running AO simulation on. And some can be run interpreted. Meaning that ⁓ when you run a test in verification, you can know the test environment that knows how to control the d the the device under test, inputting and output and so forth, and even checking it. But for the stimuli you want the test to actually change each time you run a different test, change the scenarios that are injected. So and

speaker-0: Can you say a few words about what is aspect oriented?

speaker-2: Aspect oriented enable ⁓ one person to actually extend a ⁓ struct type without inheritance. It means that I can ga go to any struct that is defined in the verification system and add add to it, whether this is data or whether this is a constraint for a random generation, or even modify method. You can extend method, you can replace method, you can end code in the beginning of the method or end of the method. The the reason this is very important for verification is because the the concept of separation between test environment and which can do anything under configuration, but has to get information from a test file which is outside. So the test file extends those tracts that need to ⁓ be configured and in the same file you can change many of such strand and method and change the behaviour of the test environment according to the needs.

speaker-0: And if we're talking about UVM, what do you need to do there in order to reach, you know, the same ⁓ capabilities?

speaker-2: There is a capability in UVM called factory, which is the kind of pattern that a lot of languages use. You call a factory and you ask him to you ask it to give you a ⁓ kind of a copy of the struct extended ⁓ type, and then use that instead of the original definition of the struct. Meaning that in the same ⁓ compilation ⁓ run type. You actually maintain two type of track in in the memory, which ⁓ requ first of all it's much more complex to do the physically, to do the work, ⁓ encoding. And secondly it t it takes a lot more memory ⁓ to actually do

speaker-0: So can you talk a bit about the productivity numbers? How many more lines of code? How much more debug effort? What's the difference in p productivity ⁓ with you know Spec when compared to UVM?

speaker-2: I I I last time I measured it was about I don't know five or six years ago. It was a about factor of two in in a lot of areas. and ⁓ this has to do because of the AOP and the interpretation as I as I I said on these this come together by the way. If you don't do if to really support good AOP you need capability of interpretation to do that. And That's a number I measured in in in some of the projects. I didn't really ⁓ had a chance to ⁓ duplicate the work in both languages many times, but in those ⁓ situations where we convert from one to another, these are the numbers that I basically got.

speaker-1: I'm just curious if from your perspective is there any advantage or something ⁓ interesting in the sister Verilog on UVM ecosystem that is ⁓ better than the Specman and ERM ecosystem or

speaker-2: Well, ⁓ it's hard to say. I mean ⁓ let me let me say this. I I think anything that you c you c you can do in Specman you can also do in UVM eventually. The real question is how many lines of code and effort ⁓ you want you want to invest. So anything that I said, including the AOP is with a factor is kind of provide a solution to UVM. So you you can't say that you can't do it. The real issue is how many lines of code eventually you're gonna maintain.

speaker-1: How many bugs are you gonna introduce when you write the factory code and ⁓ you know, all the macros and ⁓ right.

speaker-2: There is any kind of ⁓ rule of thumb that I that I know about the the the the ⁓ the how many lines of code ⁓ if you count them in in in ten K lines and quantities, ⁓ it goes exponentially. So if you if and verification minimum today are over million lines of code on an average. Okay. So I think about it ⁓ if I even add thirty percent more. It's a lot of maintenance resources that require to just maintain it alive. Not not to say that the world the needs to change it from project to project, the nice meet, according to the the device under test, right?

speaker-0: Yeah actually it's a great point. I mean even 30% when you talk about millions is co quite a lot. ⁓ can we dive into you know some specific examples like you know let's talk about an environment or a test that you had in the past from from your experience. ⁓ let's dive into you know Something that is worth comparing. What did you do here with Spec-Man? What did you do there with UVM? And let's try to quantify and better understand you say you know ⁓ 2x or 30%, or let's try to understand the notion of what's required to do ⁓ in in you know spec-man or in UVM in order to achieve the same.

speaker-2: There are construct ⁓ Specman actually is is ⁓ is a programming language like all the object oriented the programming language and UVM is also such, right? Except that the

speaker-0: Just ⁓ a question before, sorry for for that. ⁓ I think in order to to compare apples to apples, so you know, I would have compared Spec-Man to system Verilog and UVM to ERM know, ⁓ kind of the libraries on on top, or do you think differently?

speaker-2: I think ERM and UVM are are the same and basically again s it's the implementation and the lines of code that they use. Methodology wise, I think it's the same, provide the same capability, the same ⁓ way of doing verification, which is right, I think. And ⁓ the only issue again is is lines of code and maintenance costs. Okay. But let me give you an example. You wanted an example about I think the be the best example is is ⁓ the maintenance of the test. If ⁓ to do a test in system very log, ⁓ it's much more complex without the AOP and interpretation. Okay. The the way that we work with Specman, we compile the whole environment without the test and use it many times for different tests. The test themselves are equaled that using AOP, extend different structs within the test environment and configure them, add to them functionality that is required, whether this functionality is for specific additional filter feature in the in the new project, or whether this is something that you rarely run. For instance, you don't have to collect coverage. during all the the period of developing the the the project, right? You might start a kind of a little bit later or some somewhere in the middle of the project. So this kind of thing are are fitted very, very nicely to AOP. What AOP provides is is ability to add an an interpreted file that add a feature. If you don't add this file, for instance the coverage file, you don't collect coverage and so forth. To get to get the same thing with UVM, you have to always compile the whole thing. And with switches, you configure it not to use the code. But you do pay for ⁓ memory and runtime. And the more important things, you pay you pay for complexity. Okay? So it's much harder to do changes, small changes in the environment without breaking the whole system this way. If you if you keep the the test bench to the minimal required for running a basic test and then everything else is additional interpreted code, it's much easier to actually maintain such an environment. Okay.

speaker-1: But but it does come with some challenges, right? ⁓ I mean you can sometimes ⁓ if you're not ⁓ very strict with the methodology of what you extend or and what you do in the test, sometimes ⁓ you can break things or create a very convoluted code. that

speaker-2: Absolutely. You're absolutely right. And ⁓ it has to come with very strict methodology, that's first off. And the second secondly, I think that ⁓ the industry kind of thinks that verification is a work of ⁓ hardware engineers, but I think ⁓ with these two languages, ⁓ software engineer especially by E, I think software engineer so or software capability of ⁓ your engineers is very very important to succeed and ⁓ you can always get to a ⁓ bad usage of ⁓ AOP in such a way that you will not be able to maintain the the environment anymore anymore. It become too complex. I think the you hit it exactly the the the the caveat of of specman and the E language. I mean it's it's it is very strong. But it is complex and ⁓ in some areas it's kind of give you a rope to hang yourself, okay. ⁓

speaker-1: Well with strength comes the responsibility, right? You have to be responsible and not write ⁓ you know, garbage code or something that will you look at it six months later and nobody's gonna understand.

speaker-0: Exactly. So Rico if if I can ⁓ gently sense it it seems like you favor ⁓ specman in a way. why do you think Specman isn't as popular as UVM today?

speaker-2: ⁓ we already mentioned one thing. I mean it is complex and it is dangerous if ⁓ you're not using the right methodology and the right educated people that can use it correctly. While UVM is is ⁓ from the out outside of it, it looks like C. So it's a language that every engineer, whether hardware or software or computer engineers, really learns in university. It's much easier to learn. It's much easier for people to understand when they join a company, a newly joined company, they they can understand what they see much easier. Just ramping up on Specman and the e language takes a few months more than actually ramping up on UVM. So the complexity is ⁓ is something that managers need to to pay attention ⁓ for and it's depend on ⁓ what outside engineer you have in in your area. I mean if there is a lot of other company using specman you probably will be able to hire an experienced specman ⁓ programmers out there. And if you are ⁓ not in this situation, I I suggest you get off of Specman and and use UVM because ⁓ the chances that you find engineers that with the knowledge of UVM is is much h higher, I think.

speaker-0: Thank you. Actually in in that aspect, I think, you know, ⁓ Yaron and myself both, you know, our careers split. I ⁓ went to Cadence and Yaron went to to synopsis. So for many years we were kind of ⁓ competitors and ⁓ yeah rivals in ⁓ in a way and ⁓ you know it it was interesting to to see the the dynamics where specman you know at the time as you mentioned really had the upper hand because it it it allowed to do things faster with with less code ⁓ but for some period of time it was proprietary and then ⁓ synopsis came with you know a a great play of ⁓ you know pushing and driving the system verlog and and the uvm And and you know then it it became a dynamics of you know ⁓ companies that loved spec man and companies that due to many reasons worked with synopsis on on UVN. And even though at the end of the day specman became a standard, ⁓ not everybody ⁓ you know went and implemented it all. So it became if you want spec man you should probably work with Cadence or on top of you know ⁓ VCS unless you're working with Cadence and you know I think it was a brilliant marketing ⁓ act together with you know challenges that ⁓ we had at the time with you know what what's the right thing to do ⁓ at Cadence and more and more you know critical mass as you mentioned if design verification engineers went to the ⁓ UVM. So today if you want to hire Specman people, it's difficult. ⁓ you know it's it's it's not as easy as, you know, ⁓ you mentioned ⁓ UVM ⁓ being taught at the university. So there there was time where Yuhiko was was ⁓ were teaching ⁓ spec men and i it was taught in a lot of forums. Nowadays less and less ⁓ people are taught ⁓ spec men So I I think in addition to the technical challenges that that you discussed, that is also you know another angle that could be you know a business and an ecosystem reason to why this happens.

speaker-2: I agree. I mean I think this is a situation. Even I think even Cadence today. I mean in some area they neglect Specman. For instance AI, they develop a lot of the tools that ⁓ is based on AI a support just the V U VM from Cadence and not the the Spec Man. So it looks like ⁓ that even Cadence ⁓ kind of planning for the future to actually ⁓ I don't know if they drop Specman. Eventually but ⁓ they they put things

speaker-0: think so ⁓ yeah I don't think so I i it is a great language but ⁓ yeah you know it it it's kind of pushed aside but you know a question that ⁓ we wanted to ask you you know ⁓ if you were you know to start a new ⁓ verification project today having said you know everything that we just discussed now which language would you have chosen And why?

speaker-2: I I would choose ⁓ very f very S V T B the U VM very long. From now. Because of the practical reason that you mentioned the so far, it would be much easier for me to actually do a tape out. ⁓ if I'm a startup company or even you know, company with ⁓ a breadth years of ⁓ experience. Still if this is your project, I would move to UVM. Or maybe even jump directly to AI sometimes in the future. So if you really start a new project, you better consider using AI as a basis. And once you use AI, you know, these two languages ⁓ cannot beat with it. That is the capability that I see today.

speaker-0: Let's talk about that for let's expand on on you know.

speaker-1: That's probably gonna be very interesting to our leaders.

speaker-2: Listeners. I think that ⁓ it will be possible in the near future to actually extract all the data ⁓ during simulation that is required for verification and put it in some certain database. And from there ⁓ you can ⁓ ask the AI to look at the result of the test, with ⁓ compare the behavior. to the spec. Okay. It will take a lot of ⁓ iteration until ⁓ you ⁓ you get the eye to answer correct question. But the nice things about the eye that eventually when you start reaching the end of the project, most of the thing that the eye can do will be fairly accurate. I wouldn't say that n you will see no test benches anymore in a simulation. But ⁓ it the amount of ⁓ codes in the test bench can be reduced significantly and a lot of the tasks that we're doing today can be done better in AI.

speaker-0: So, you know, maybe you can educate us ⁓ because n not every ⁓ every one of our listeners is an expert in in verification. When you build a verification environment, ⁓ what are the components that you need to have as of today? And you know the the right question after that would be okay, so Won't you need that? Would you skip that all? But let's start with just the the base of what is there in a verification environment?

speaker-2: The verification environment is three parts, I think. It's ⁓ there is a stimuli generation which is very important. This is what what ⁓ stimulus and duty and ⁓ trying to expl ⁓ explore the bugs. The second one is ⁓ the checking mechanism. Let's say let's talk just about end-to-end checking, for instance, according to it should be according to the spec. And the third one is coverage. These are the the the three things that are important.

speaker-0: So are we giving up now ⁓ with the AI on any of them?

speaker-2: It gradually will move to that. I think the the easiest things to do is actually to start with coverage with AI. Because if you think about it, ⁓ coverage is just ⁓ it's just counting information existing a in a huge database. If you imagine that all the tests dump a lot of information about state machine and interfaces and and clocks and events within the simulation. Dump the them out into a database. You just want to ask the AI to actually see that all combination of a state machine and input to a unit were ⁓ properly ⁓ checked. Okay. So it's a mechanism that doesn't require the complex language ⁓ definition, it just needs to N just need to c ⁓ kind of ⁓ configure the AI and what what combination ⁓ of ⁓ of ⁓ states are a collision with a n ⁓ with collision with other combination of state machine are really important. First of all that they can happen and that they should happen and they they are important ⁓ to measure.

speaker-0: So just to understand the the idea, you're talking about ⁓ you know, the AI looking at the spec and then generating kind of direct spec ⁓ direct tests ⁓ to cover specific scenarios and use cases ⁓ according to the spec.

speaker-2: ⁓ actually initially I was talking ⁓ what I was talking is just coverage. Assuming you have the whole test bench running, except the collection of coverage. And you dump all the information outside and you collect the coverage by AI. Okay. And the AI can k come back to you and say you didn't test this one, ⁓ this combination of inputs, and ⁓ this is how I would suggest that you change your test. So it will take a test which is closer to the situation that you want to get, and ⁓ suggest modification and you just duplicate the the test file, do the changes and s and do it again. At this as in this stage, we didn't save anything. We just collect ⁓ did a better collection of the coverage. We save a little bit about the code of the ⁓ on the code of the coverage, but it's not the majority. Eventually, Since the AI ⁓ has the capability also to read the very local code. I want to tell the AI to generate the stimuli per situation. So he instead instead of generation generating one test that randomly ran a lot of combination, ⁓ instead of that, it will generate a specific test that he specific scenario. And together with the coverage, you will be able to actually generate those tests overnight and doing collecting the coverage again and see what holes you have again and again. So you don't need a random generation. You need just a machine that ⁓ eject the stimuli into the DOT and the stimuli are generated by the AR. That's one possible direction.

speaker-0: And how do you check that the stimuli and the duty ⁓ actually ⁓ behaved correctly?

speaker-2: This is the hard part. Okay, the hard part is actually making the I and understand the connection between the specs themselves, ⁓ which is written in in simple user language, ⁓ human language like English. Understand the spec in to a certain extent that given a situation or a flow of inputs, it can tell you ⁓ at the end what should be the output on the other. side. ⁓ This is a hard part. I think this is this will take time. I think that in the first stage what what will we we'll need to do, we'll need to ask him to use existing ⁓ reference model that we have in the test bench ⁓ and he will use those reference models to tell him what what is correct and incorrect as an output, but he will do the best.

speaker-0: Keigo, ⁓ may I ask you know, what do you or how do you spend your time today with AI? What do you play with? What's working? What's not?

speaker-2: Currently AI ⁓ I would say is is just doing some simple task. ⁓ but ⁓ it does help a lot in verification. Most of the tasks I would say are something that somebody or a verification engineer could could have been could have done with ⁓ a some complex script. So that's a level of ⁓ what are we using ⁓ AI today. For instance, ⁓ let's say you want to ⁓ to understand what's happened in that in specific test. ⁓ the AI can read the log files and you can tell him ⁓ what went wrong compared to other tests. Or please compare it to all the Android tests that we have on on on the disk. Compare this particular test while this test failed and the other didn't fail. And it gives you just the differences of way he looked at it. For a human to do that, it's a lot of ⁓ work. And by the time you get to I don't know, to the hundred test, you forget what you saw, right? While a machine, AI machine doesn't care. It can look at that and give you exactly ⁓ what is ⁓ the essence of ⁓ that could be ⁓ potentially the reason that ⁓ this test failed.

speaker-0: So to mirror my understanding, if if I understood correctly what you're saying, it's not yet debugging it all, you just not ⁓ ask it ⁓ wh what's wrong and it tells you, but it does flags differences and things to go and discover yourself.

speaker-2: I think this is this is where the market where where I what I see that people are capable of doing today with AI. Of course it's eventually gonna grow and the capability gonna go, but it's still in a level I would say that people that may may write script that can do that. But ⁓ maybe not as accurate and as good as AI, but it could have been done. And still it's a lot of help in a lot of things. Yes ⁓ so ⁓ it's more like investigations, I would say. Even if ⁓ not related to tests. If somebody is new to ⁓ to ⁓ a test bench and want to ask a question, who is ⁓ accessing this field, who is ⁓ driving the value, who is looking at this field? It you can do it with graphs, right? But it's much more accurate if you ask the AI and then ask him to actually go to the root. cause of the change. Okay, which is not easy to do. So you can do a lot of learning a lot of the investigation with AI. If you want to do a global modification, I want to ⁓ generate a subset of my test environment for certain things. You wanna tell him just build ⁓ build a ⁓ let's say a small test environment just just di does this stimuli. Okay, this kind of stimuli. ⁓ it can take out the all the file which are not necessary and modify those who left and build you a small test environment. But this is where we are today.

speaker-1: So does that mean that ⁓ unlike let's say the past twenty years, this opens up the opportunity for people who are not really verification engineers to start doing ⁓ very sophisticated stuff if the if somebody builds the AI ecosystem for them. And maybe even they will not need to be to code, not system Verilog and not Specman at some point.

speaker-2: I think this is where we are going, yeah. I think ⁓ the the validation engineer will be the one with the more ⁓ I would say ⁓ the controller, the brain behind the machine to say this is important, this is not, this is correct and this is not. And while the the stage of information is ⁓ still going on, ⁓ it will A lot of resources will be invented with that, but eventually toward the end of the project, ⁓ you you will give you will see good result, I think.

speaker-0: Thank you. Thank you, Rico. ⁓ I think our time is almost ⁓ up. anything you guys ⁓ wanna share and conclude?

speaker-2: Yeah. I would I would summarize the the the whole discussion was about spec mining UVM. I would say that if you are still if you are already using Specman, don't drop it until the AI come and replace it. And if you start a new one, you either take the chance and jump on the AI wagon right now, or start with UVM for a while and consider jumping to AI once the the AI really ⁓ maturity is is is proven. ⁓ I the one one thing about the AI people need to remember that sometimes you get false alarms, okay, with the eye. And ⁓ you can you cannot draw a absolute hundred percent safe conclusion from what the AI tells you. So I initially at least in this stage, test benches will stay just as a backup For the I until it's really

speaker-0: Gets better. Yeah.

speaker-1: Till we have at least ⁓ I don't know a few thousands of tape outs that are safe, nobody is gonna take the risk of taping out something that is not hundred percent.

speaker-0: My take on you know we called ⁓ this chapter the winner losers and you know we talked about ⁓ the benefits of specman and how it should have been a winner but it kind of ⁓ lost to UVM. And again, if we're looking at AI, it seems like UVM may lose to AI and you know time will tell, we'll we'll see that, but Anyway, Tiko, ⁓ it was a pleasure having you here. ⁓ thank you for joining us. And see you all on the next episode. Bye bye.