speaker-0: Hi everyone, welcome to the third chapter of wearing flip-flops. I'm Ronan, your host and with me, Yaron Dani. And we have again our special guest Claudio. We haven't had the chance to finish our contestation last week. So let's dive into some more questions that we had.

speaker-1: Hey guys

speaker-2: Let's dive guys!

speaker-0: about the sizes and the scale of the chips. We talked about the verification plan, the strategy, ⁓ but we also touched that there are different teams. ⁓ So prototyping, emulation, formal ⁓ verification, know, cluster block level, full chip. Can you say ⁓ how do you guys work as a team and are there... any things that you guys do together or each of you working in a silent?

speaker-2: No, so that's a good question because on top of what you said we have also physical design team that we work also with and we have also software guys that are apart, know, really a part of us, right? And yes, it's a challenge, you know, have to make small groups that will be focused on different, you know, subsystem or areas in the design and there is one owner that will drive this small team. Small team I mean, it's not so small, but we tried to like, been six, between six and ⁓ like eight people or something like that.

speaker-0: PwS likes to say pizza size, right?

speaker-2: Pizza size. Yes, but you know, it depends. So the thing is that when you have small groups, you know, then you can and you have an owner that you can trust that knows how to synchronize all those things. You have one owner, like I said from the beginning, it's all about mindset at the end of the day, you have to trust the people that have ownership, see the full picture, think big, dive deep on the other side and deliver results with highest quality. This is all you have to have.

speaker-0: You know, I'm the block level guy for a few blocks. ⁓ and I'm not a data bliss. I just run the blocks and what do I care about the full chip at this point? Why do I care about the emulation? Do I really have to have interaction or would you as the overall owner, you know, dive into what each of us are doing and make sure that we do the things that help us both or each.

speaker-2: So first of all, we don't want dependencies, right? So I don't want now that the unit level guy will think what the emulation will do, but he has at the end of the day, let's say if you are owner of a block, right, and you want to do sign-off, you have to, when you do sign-off, you don't do for the DV, you do together with what was done in emulation. What was done in full chip simulation? What was done in block level? What was done in any formal verification? Right? So there is no such thing.

speaker-0: you are the owner of the block from up but then you have you know each team should be the owner right what what about

speaker-2: Cross the board! That's fine Yes Yes, no, there is one No, no, no, it isn't because you have one owner that will do the sign-off and he needs to make sure that all of the way But it doesn't mean the emulation guy now. Okay, let's say if the emulation guy is the owner Let's say he's the owner. So he's not he needs to make sure that everything that was ⁓ plan to be done in formalization was done and it's covered and it's covered and you know that we got what we wanted to get there if it's foolproof or maybe you know not foolproof just coverage so if you are the owner it doesn't mean the others doesn't have their own ownership on what they are doing that means that you from my perspective right I cannot you know talk to ⁓ I do that but let's say I will not if the scale will go and continue to grow there is a limit with how many people I can you know synchronize Simultaneously so I need to have people I can trust that will do what I did two years ago and Four years ago and stuff like that. This has to you know to make a scale you have to do that

speaker-0: Let's talk about the life cycle of a project, like the day to day of what each of the teams are doing. Let's maybe split that in the first three months and then talk about, you know, after that, if there's any difference.

speaker-2: There is a difference, For example, not always, it depends, but in most of the cases, like unit level will finish its work earlier and for modification also. They work like mostly in parallel, right? And full chip will continue to tape out, right?

speaker-0: the full chip with the block level and with emulation? Yes.

speaker-2: All in parallel, multiple...

speaker-0: Do you have the things ready for emulation at day one?

speaker-2: First of all, to bring up the emulation, a lot of time you have issues with bringing up the model and the compilation stuff and stuff like that is even not related to functionality, connect all the devices that you need externally. And a lot of times, by the way, because let's say you have a unit level, a new VM, and you have VIPs to connect to your device, right? And sometimes you have issues with the environment. you know, verification environment stuff that you know your VIP doesn't work as you expected and you debug it with the vendor. In emulation, there is a lot less things to deal that are verification environment issues. There are less.

speaker-0: I ⁓ would say for emulation, since if you need to run software and stuff, so if the DOT is not mature enough, things would break ⁓ at time zero. You can't really do that. So ⁓ are you saying that you cope with environment issues and then wait or?

speaker-2: No, so there is a synchronization, right, at the project level that we are seeing, you know, if the chip doesn't get out of reset in full chip, and there are real issues in the RTL, of course, I will go to emulation, I will get the same. So there is no point to do that, you know, just in the sake of doing that. So we do a synchronization meetings that we look at all, know, from block level, we see what happens in the full chip in subsystem, if there is a subsystem in the middle, right. And we do checkpoints, it's on weekly basis. We are not just taking and you know in the sake of doing things in parallel we cover our eyes and go forward without checking. No, we do have synchronization.

speaker-0: And if we look about block level and cluster level and full chip level tests, can you estimate how much time a test runs, compiles and runs in each of the categories, let's say in the first three months?

speaker-2: It depends because we have a lot of configurations to the environment, even in the full chip we have an environment for development that runs relatively fast. ⁓ Let's say the fastest test in Full Chip will run like one hour and a half, one hour, right? Which is fast, it's not something...

speaker-1: Do you have any tricks to shorten the simulation time? ⁓

speaker-2: Of course we do, but we won't tell. ⁓ Yes, we do. We do. We use also.

speaker-1: I'll just, yeah. You're forced like configurations, skip resets, PLL

speaker-2: ⁓ We do not skip resets because it won't work but we do have shortcuts in the design but totally in the design we do you know smart like backdoors like you said in places where we can but it's also like we split the chip you know we have the full chip but you don't have to have the whole blown all the time right Exactly. So I don't want to get to the details of that.

speaker-0: 90 minutes for the shorter test in full chip.

speaker-2: And you get to the longest test you can go to a week or you know if you want to do a stress test in Gate level is a different story. And in gate level, by the way, we have a very special technique that, you know, it's currently in a patent process that we developed here. So, yeah, because if you think about a full chip and run this kind of full chip, and you can imagine, right, the size of it, it's not feasible to run Netlist, full Netlist on that. And definitely not SDF, right? Definitely not SDF, which is at least 10 times slower than any gate level. Actually, I might say, I don't know, because I cannot say all the industry, because I don't know all the industry, but as far as I know, I don't think this technique is used anywhere. I must be humble because there many smart people in this industry that probably doing also smart things.

speaker-0: Claudio, so you said 90 minutes to a week. Most of the tests in the first three months for cluster or full chip, would those take half a day, a day, a few hours?

speaker-2: Few hours I think, few hours.

speaker-0: happened after three months?

speaker-2: You say three months, you know, it depends, but let's say three months, okay? Then we start to ramp, you know, the more exhaustive tests, right? And the exhaustive tests, you know, if I develop tests, I do it in a small model. Anyway, the tests will run exactly the same when I, it should be run exactly the same when I run it in a larger model. And if it fails, I need to debug, but I will run it, you know, I will not run it during the day and wait for it to, get finished unless I need to debug and this is what I do. But in general, the long tests that are exhaustive and doing stuff like that, they're running in batch mode and if they fail, they rerun automatically and we get the waves dump and the logs and all the stuff. So we don't really spend time in waiting, but I cannot say that it cannot happen. It can happen.

speaker-0: pain points. for you, if you had to pick up two pain points that keep you, wouldn't say up at night, but bother you the most in the verification process as it is today, what would those be?

speaker-2: I think that I Think if you look at the verification in general, right and you want to solve the most time-consuming problem It will always be debug Always be debug right if you take how much code even if you write an environment from scratch and you do everything The debug will take you any way more time than coding so if you you know debugging and and I'm not talking about just RTL and definitely gate level and definitely as DC, which is not an easy bug. It's not, you know, the straightforward for application standard verification guy to debug as DC failures. It's a different story. It's a different approach. It's a different world. You have to understand a little bit back end. So, so if I, you know, my approach, for example, in using AI, I think it's, you know, doing it with like ⁓ documentation and creating strategy from mass.

speaker-0: touch AI actually right after this question, let's focus on, you you mentioned that one, the biggest pain point is debug faster, right? Is there another big pain point around that? ⁓ For example, is runtime something that bothers you?

speaker-2: If I could run, you know, I'm a software guy in my background, I'm a Bachelor of Computer Science, I used to write, you know, a software that, you know, you compile, press the button and you see the result. So I wish I would have a simulator that, you know, I press the button and I see the result. So this is something that we would really, you know, I always thought about, you know, what would be the solution, you know, how do I make a CPU that All he knows he gets any simulation image right that's relation image and runs it in seconds But that's that's I think it's you know, if I could save the runtime, right? It would be huge because you know if you think about the long test, know If you talk about the one two hours test also if you save one hour test and you do it in one minute You save a lot, right? 60 times So if you take something that runs a week and you minimize it to like 10 minutes, then you saved your life.

speaker-0: Would you say that nowadays because of the growing complexity, more ⁓ workloads are shifted towards FPGA and emulation?

speaker-2: So first of all, yes, we use mostly emulation, right? But we don't use FPGA as far as I'm concerned with. But anyway, if you think about, there is a, so emulation, it's great, right? It's fantastic, but it's much more expensive, right? So you don't have endless, resources for that and also simulation don't have endless resources. It's never endless, right? But you have much more. And also, you know, if you look at, so today emulation, today emulators, have debug capabilities like you have in simulation, but you do have things that are not existing in emulation. For example, if you want to check CDC, there is no way to do it in emulation, for example. And if you want to check out, you see you don't you can check it in emulation. So even if you have like a lot of resources, you still look cross. ⁓

speaker-0: Lock domain checker

speaker-1: and cross domain, clock domain crossing and reset domain.

speaker-2: Exactly. Yes. So these kind of things you don't have also, you There are other things that I don't want to get into it too much details, but You know simulation. It's still not something that you can replace entirely with Maybe FPGA would but you if you J you have then the debug capabilities that are really challenging right because You have to upfront think about what you want to see in waveform So it's not the same as an emulation, definitely not as simulation.

speaker-0: about FPGA and emulation. We'll take that offline. Claudio, so let's move to AI. We can't do a chapter here without talking about AI. What do you guys do with AI today? And I guess, what do you do? What works? What doesn't work? Because we do see a lot of hype. Everybody's talking about AI. Would love to understand what's working, what... state in the works and what's your opinion on all this?

speaker-2: So I think AI is good in many aspects, right? If you think about, know, definitely we talked about reading documents and you know, you can just ask questions instead of reading the full document, know, it saves a lot of time. The other things that, you know, I used, I liked it because, you know, when it started, I wanted to give, you know, like, okay, I will give you some RTL module. please write me the functional coverage for this model. And he did it very well. He did it very well. Because I had this model before and I had the coverage already that, you know, we reviewed it many projects with the designers. This coverage, you know, covers really well. And he did it 80 % of the job, which is excellent, right? Imagine I could get 80 % of any coverage and then complete the other 20%. I'm fine with that, right? If you save me 80 % of my work, that's fantastic. The other thing is I think that we are moving forward now in progress to use it more like agents, ⁓ agentic AI, right? Making agents that can take a process and do it thoroughly. For example, if you have a regression tool, right? And you can analyze the regression automatically, send you the report, tell you, okay, this is the problem here. The other, the next thing is to connect, for example, to your signal database. Read the database, understand from there which signals to extract from there and look and tell you, okay, this is the problem in this module in the design. So to save debug time, if you know, imagine you sleep at night, right? Your regression is running, the agent is running the regression, the other agent is taking the results, analyze them and takes the failure, analyze the failure and give you the first hint, even the first hint. This is the area of the design that caused the problem. If you have that, then it's fantastic. We are not there yet. It does a part of it, but it's not does it something that you know you can, it's accountable. But I think it's going there very fast, very, very fast. It's so if you take, for example, automation scripts, it does it perfectly. Every script that I written, so you know, I'm against the excuse me, I don't I hope I will not ⁓ Get angry at anyone, but I do not like the egg groups and stuff like that We like to do all the verification team is doing all the automation stuff and stuff like that. So there are Yes So because so so we do on ourselves So there was scripts that I did long time ago, know And we run them to us for some kind of things Anyway, I took this and I generate those exactly with AI I'd even didn't look at the code is just works And even if it doesn't work, I give the script back, please fix this scenario and it fixes that. So it's fantastic in generating scripts, C code, C plus plus code. It's really doing a great job in very long. It's not there yet, but it's not so far from that.

speaker-0: You're on the verification side, but is it helping designers write faster blocks?

speaker-2: I don't think it's there, but I think it does help them with other stuff. I'm not sure I want to get into that because, but I don't think it's there in terms of like, okay, let's replace the designer because the AI will write the code better. I don't think we are there.

speaker-0: What about regressions and coverage? mean, getting to the coverage faster on each version that you have out. Is that working well?

speaker-2: So we do have something that we work with our vendor that supposed to do exactly what you are saying. I think it's not bad, but it's not there yet. But it's going to that direction and definitely I think that it's something that in the early 2000, 2007, something like that, there was a company that provided something really that it takes the coverage, creates a graph and split the dependencies. Wherever there is no dependencies, it splits and runs the test with a constraint that will cover the fastest way all the constraints that you have. So this is something that I think that the AI can do, right? Or the tools that are using AI in order to direct you to the coverage or the interesting scenarios. It can do all these kinds of things. I don't think it's there yet. But I think we are not far from there, by the way. We are not far. It's a matter not of 10 years, not two years, maybe less than that, but we'll see.

speaker-1: So currently it sounds like you're using mostly for AI to ⁓ optimize your productivity. I'm to replace the core design features or the risky technologies at this point. But coverage, if you can save time writing coverage code, it's not too risky because it's still coverage. It's not something that goes into the chip. So I guess my question is, so you mentioned that you had a model to compare with.

speaker-2: Exactly

speaker-1: So you know that the AI result is good. So what do you do if you don't have that? How do you, I mean, it's something that I'm struggling with my AI experiments. You know, I can type a prompt on my cursor pro here or a cloud code. It will generate, I just tried it, you know, a full ethernet, whatever, block. I can also ask it to build a verification environment for me. But how do I make sure that this whole thing works?

speaker-2: So I don't think in the current status that we are, you can really trust it. That's the thing. You have to be able to analyze what he generated and make sure that first of all, it's complete. Most of the time I think that it's not that it doesn't do or doesn't do anything. Most of the times what I saw is do it partially. And sometimes the holes that it's leaving, they're not so easy. So, you know, Let's say if you want to build an environment, new UVM environment for to start with, it's excellent. It will do for you all the, you know, the stuff that you already don't want to really write the code, but you cannot say, okay, the AI took it and did all the constraints and all the everything, you know.

speaker-0: the ownership i mean you're the owner you would not go and say yeah

speaker-1: That is the worker.

speaker-2: Currently not currently not but you know to be honest, right? I think it's going there I don't know how much time would take in the design area. It's a little bit behind I see in Python and you know other C or C++. It's much more advanced It's definitely there but but even you know even even in C or C++ I saw you still have to check and you still have to make sure that you know, there were no Hallucinations because it happens. Yes

speaker-1: Yeah, in our world, I think the problem is worse because or better. I mean, depends how you look at it. Because, you know, for C, C++, Python, whatever, you have so much data, you know, around can just scrape the Internet and get code for Verilog. I mean, if you're the company like Amazon, maybe can do the training on its own. ⁓ Intel, Broadcom, all the big, names, the hyperscalers. But, you know, somebody like someone else would have to make an effort to find the proper data set. you also guys, also have legacy projects that you can learn from. So yeah, it's interesting where this industry is going in terms of AI driven design.

speaker-2: I guess I guess you know for sure it's going that direction the question is how much time it will take to get you know to get an agent that will do the job and you don't have to check it thoroughly

speaker-1: And of course, there's the sensitive questions about what's going to happen to hiring and the workforce in industry. I don't know if you want to go there, Ronen, but...

speaker-0: Big question. Claudio, are you guys hiring?

speaker-2: Yes. actually, you know, I think we are still at the point when, you know, talented people we are always looking for and with or without AI, we are in the same, you know, so we look, you know, for example, not only talented, but also with the right mindset, like I already mentioned that I think for me, it's the, you know, it's not, you can be talented, but if you are not in the right mindset, it's a problem for me, right? But if you're in the right mindset, then it can help.

speaker-0: Right mindset, you mean ownership, responsibility, making sure that you're responsible for whatever outcome would be and it's...

speaker-1: You are the CEO of your block, Could be the tagline here.

speaker-2: ⁓ Exactly Right, but it's not enough right you you know, you can have a very good intentions in life It doesn't always it's not enough. You have to have the good intentions and all who have the ability to achieve Exactly. So it's a combination. Yes, we are looking it's not we are not in any way like, you know I hear some in the news that you know some companies we stopped hiring and we are Because we have AI doing the job, we are not there and we do look for talented people and...

speaker-0: So maybe I'll ask you, if I'm a verification engineer, a few tips, but are you looking for ⁓ experienced engineers or also juniors? And let's just understand that ⁓ and then understand what is your expectations or tips from ⁓ people that could come and

speaker-1: for you.

speaker-2: This is a much tougher question for me. I should have prepared for that. But in our website, I guess that would be the easiest way. It's always there when we have openings. Regarding your question regarding juniors or experience, so look, it depends, right? So we hired in the last two months, like... five or four or five junior engineers and two students. And on the other hand, I can tell you that if there will be an experienced engineer, right, that will come and I think we will find something, you know, we will find a place for him. So we are looking for talented people. Yes, I very much like juniors, you know, and even non-experienced. Because they are very open and you know, they already in the the era of AI and all this stuff that you know, can you can use that?

speaker-0: have for you know someone who's coming to get into

speaker-2: I that, you know, first of all, think that patience is something that it's really important because, you know, if someone is coming and is expecting that, you know, in one month will be a vocation engineer that can do everything, it might be a disappointment, right? So you cannot really, ⁓ you cannot GZIP ⁓ experience. You have to have to take the time, learn. You have to be curious and you have to dive deep and understand. It's not just to get the job done, which is super important to get the job done, but you have also to take the time to understand and ask questions and be collaborative and know how to see and how to connect with people. It's super important to develop your career. I think it's also something that people, especially juniors... But it's also true for anyone that comes to a new company, needs to get appropriate and collaborate with a lot of people. And this is why, by the way, that when we are back in the office, return to office policy, because we believe that cooperating and collaborating, it's not something by the way. It's super, super important. Nobody can know everything. Nobody can cover everything. And nobody should know everything. It doesn't make sense. So that's why you have a team and that's why you have different people to collaborate and think together and brainstorming. I think it's essential. that's what I think that if someone that comes in, it doesn't matter if it's in our company or in any other company, ⁓ always look to collaborate with others. Always look for smart people to learn from them. The best thing to learn from is for other people.

speaker-0: Thank you. I think our time is up and I would like to thank you very much Claudio for your time and advice. I learned a lot in this session. So Elani, any last words for this chapter?

speaker-1: Yeah, thank you, Claudio. We know from a way back. So it's always a pleasure to meet people like you from the industry. Yeah, I really love the tagline, you be the CEO of your block. I mean, it's really, of course, backed by skills, but it really kind of pins the mindset of owning a block in verification because, you know, Like, you know, only the paranoid survive, right? I mean, it's your block. can never go when I was back in the day when I was doing hands-on verification, you know, it's your block and you're always scared that some bug will slip ⁓ between the cracks. So yeah, that's a good, it's a good mindset. Thank you so much for. ⁓

speaker-2: First of all, thank you guys. It was a pleasure for me. It was always fun to talk to you guys, knowing you from the past and hopefully that we will still be connecting in the future. So thank you for having me here. It was a pleasure.

speaker-0: you. See you on the next chapter.

speaker-1: All right.

speaker-2: Bye. Bye bye.