Ronen laviv: Hi everyone and ⁓ welcome to another episode of Wearing Flip Flops. ⁓ we are here again with ⁓ Sirish post doc. ⁓ great to have you again, Sirish. How was Dak for you? Yeah, Dak was amazing and I really enjoyed the event and ⁓ was able to interact with ⁓ all of our customers and ⁓ happy to see like a lot of research and development going on in ⁓ AI and ⁓ our design space. Amazing. So let's see. La last time we we touched several aspects. We we talked about this ⁓ build vers my we we talked about you know ⁓ challenges ⁓ and qualification ⁓ required. on this episode I'd like to focus more on and discuss you know the ecosystem and ⁓ where we are all heading. ⁓ and and to start with the ecosystem, ⁓ I wanted to ask if the EDA vendors, the the synopsis cadence Siemens, ⁓ since they control the simulation Do they have an edge on you know solutions and companies as your company? Yeah, absolutely. They have a very, very good significant advantage. and I don't think anyone should underestimate them because companies like Synopsis Cadence, ⁓ Siemens have spent decades building world class ⁓ simulation tools, ⁓ verification synthesis and debug tools as well. So ⁓ the tools do generate like enormous ⁓ engineering data ⁓ which they already have and ⁓ naturally ⁓ they are positioned to embed AI into their environments. But I also think ⁓ just ⁓ that won't ⁓ help like ⁓ as engineers if you take ⁓ for example any of the design right like the it starts with specification to architecture to ⁓ RTL and ⁓ then it goes into the ⁓ verification plans, regression and so on. So ⁓ the those kind of workflows often t ⁓ cross like multiple vendors. So if just one EDA company is trying to ⁓ embed AI and trying to sell that ⁓ I don't think that's going to ⁓ be a big issue but definitely if they are if they are ⁓ going to do this workflows that will definitely help the ecosystem as well. And maybe a question around that. So so ⁓ you know last chapter our last episode we talked about MCP and and now you're saying that ⁓ the vendors actually have an edge. ⁓ what did they have that you know is not ⁓ available to to the customers or to you know third parties like yourself. I is there anything missing in the MCP that you would have wanted Cadence synopsis ⁓ Siemen C D A to externalize ⁓ so everything would just work better ⁓ from a third party ⁓ tooling system? So definitely if they ⁓ expose like a lot of this data right like ⁓ through not just MCP I think even through ⁓ API that will definitely help because in order to patch those ⁓ like it can be simulation data and let's say we ⁓ simulation data and also ⁓ if at all we want to directly fix some coverage holes if there is a easy way to do that like just ⁓ ⁓ send some information and they ⁓ create like ⁓ a nice cover group or those kind of stuff. So so what would you need for coverage, for example? So coverage yeah there are multiple things, right? Like yeah we might need to ⁓ do ⁓ sequences as well. Right. So you might need to modify the test bench and then ⁓ and then like rerun the entire thing. So ⁓ for example just ⁓ creating a ⁓ new ⁓ cover group or like new sequence ⁓ is not the end because then you need to run run the tool and then check the output. ⁓ the agents need to have a feedback like whether that coverage has improved because of that sequence. So ⁓ too. Sorry, ⁓ if if you still want to cover a j Sorry for disrupting No, so so I was about to finish. So ⁓ on the coverage side, like unless you have these sort of feedback, right? Yeah, the agents won't be able to do a good job. So if if at all they expose these through either MCP or ⁓ API, that would be great. So what about debug them? ⁓ because nowadays ⁓ if if ⁓ if I'm not mistaken, you know, they all have kind of MCP API into the ⁓ debug waveform ⁓ tool. You have the log files, you have the design. What else do you need? ⁓ yeah, this is a very interesting thing because we ⁓ spent a lot a lot of time on this, ⁓ especially the waveform data, right? ⁓ that is of ⁓ a l of lot lot of value because just through the logs ⁓ you can figure out like most of the stuff But if you want to backtrack and see where the actual issue is happening, ⁓ that will be better through waveforms and also the advantage is ⁓ you can provide that as an output ⁓ to the user as well. Because ⁓ you users can then judge the ⁓ output that is given by the AI very clearly. So what are you saying you you need to be to have ⁓ from the MCP that you don't have today? So basically the waveform waveform interface. Like a waveform interface. ⁓ So I guess, you know, it it would be a question, you know, whether it makes sense for ⁓ the ⁓ EDA vendors to externalize that business wise. But let's talk about, you know, Moore's lab ⁓ AI. What are you guys doing in order to gain an edge? ⁓ and you know to be better one, two, three years along the down the road. We we want to take this in several stages. First we want to stay very laser focused on one domain. So ⁓ today we are like very focused on verification and we are diverging a little bit into design and also like ⁓ firmware stuff. But ⁓ we are Building AI specifically for semiconductor engineering and that means every day we are thinking about specifications, RTL, ⁓ coverage, regression, waveforms, debug, ⁓ and those kind of stuff. And that depth of domain knowledge is difficult to replicate quickly unless yeah you form a very good team with ⁓ multidisciplinary ⁓ fields. And second second thing is as a startup we always keep our team very lean and we want to iterate very fast and at the same time we are trying to give a very good experience to our customers both on the support side and on the ⁓ to tooling side as well. And third thing, ⁓ the most important thing is ⁓ as we keep talking to these customers, we are gaining like lot of ⁓ experience in building this workflows. ⁓ dedicated to our semiconductor industry. Most AI products today ⁓ automate individual tasks. We focus on orchestration. Like we we we want to completely automate it. We are still not there yet, but yeah we ⁓ we have a plan to get there. And ⁓ fourth one is yeah we we want to be open by design. So we want to be flexible. In order to automate ⁓ automate it, so I guess you know, CAD has their own scripts and and and ecosystem. Are you saying you wanna build your parallel ecosystem so ⁓ a test gets ⁓ run, ⁓ tracked with coverage, ⁓ if it fails it get gets bucketed, gets debugged, ⁓ automatically fixed in the design order verification, reruns the regression, see that you know it it fails when ⁓ without the fix, passes with the fix. Is that where you're heading? Yeah, so we we are we are trying to build like a platform which can have all this different agents and people can pick and choose ⁓ whatever states they want. Like whether they just want to debug, yeah, they can do the debug. They ⁓ just want to stay at test bench level, keep writing tests, yeah, they can do that as well. But so basically also kind of ecosystem platform to run everything, or would you use the the customer platform? we we are completely on customer domain itself. Like yeah, we never host our tools on our cloud environment. It always runs on prem. Got it. Actually it it brings me to the next question because you know, recently ⁓ cheap agents ⁓ announced that they partner with Amazon. And I I'm wondering, do you have any plans to partner with third parties? Yeah, we we are always Does it make sense even to, you know, collaborate for a better ecosystem? ⁓ yeah, yeah, definitely. ⁓ partnerships are very important and we are always evalu evaluating strategic partnerships where we can. to create like a very good value for our customers both ⁓ on the semiconductor companies and also on the AI ecosystem as well. So because for example when you're doing when you're developing a chip right yeah you actually take like several tools. E even ⁓ if you take EDI tools, right, you take like design tools, verif tools and ⁓ there are like bunch of IP vendors. So ⁓ it is important to partner with all these companies to deliver a very good ⁓ output to our ⁓ customer. And recently if you ha I don't know if you have seen the D V Con announcement, we ⁓ partnered with Brecker and we are trying to build a PSS solution. So there are bunch of ⁓ partnerships that are going to be announced ⁓ ⁓ over the few months. Amazing. yeah. ⁓ Looking forward to seeing that. so, you know, we we started talking about that in on the previous talk that we we had. looking into the future, six, twelve pounds, two years. a company as a Moose Lab, what do you need to do ⁓ and where do you want to expend in order to you know keep up? Is it only the kind of the automatic flow or are there more things that you guys want to do in order to shine two years from now? Yeah, definitely. So first thing is yeah, after we ⁓ finish focusing on like several stages of the chip development ⁓ I don't know, it's it's a very ambitious goal, but we eventually want to be like a ⁓ a fabulous semiconductor product company. ⁓ in parallel as well, like providing ⁓ these ⁓ AI native solutions because ⁓ then I feel ⁓ more and more companies can ⁓ build their own chips very easily. because they can just like come with a product product idea to us and we ⁓ build the entire chip ⁓ to them and ⁓ in kind of a service company to build ⁓ chips and IPs for Whoever wants to ⁓ to have cheap design. Got it. ⁓ would that include ⁓ analog as well or only digital? ⁓ mostly digital, but yeah, we do have analog in our ⁓ roadmap because yeah, we were dealing with one of the customer. ⁓ but right now we are very focused on ⁓ digital design. ⁓ Okay, good luck with that. So let's dive into a few, you know, questions of What do you think the world would look like, you know, sooner than later or in a few months or or not even years. ⁓ let's talk about UVM. Would UVM sta stay around? What do you think? ⁓ this is a ⁓ very good question because I keep debating this with Tom, ⁓ who is our advisor and ⁓ he he was one of the authors of UVM so ⁓ I would say As LLMs keep becoming powerful, right, ⁓ it doesn't actually matter which language you choose. ⁓ I feel yeah, w ⁓ whether you use like any of this ⁓ chisel scala, UEM, Verilog, it doesn't matter ⁓ at that point. ⁓ I'm coming to that point. So ⁓ UEM will ⁓ try to exist in parallel along with ⁓ any ⁓ new kind of ⁓ hardware languages that are going to evolve. The reason being ⁓ for two things because ⁓ most of the VIPs and stuff ⁓ were built using UVM and also yeah I do agree ⁓ for ⁓ FPGS because yeah I s I started my career with FPGS and I know what you're talking about there. And ⁓ so I would say U VM will exist in parallel. Yeah, it won't go away for sure. Okay, but would there would there be you know other ways to to verify? For example, do you see more software test benches? do you see Python based test benches? how do you ⁓ envision the future with test benches, if at all? So it depends on the ⁓ y use case and the kind of chip you're trying to build because ⁓ when I was working for this startup before prior to Microsoft, right? So we were building like an AI accelerator. So there ⁓ we had a very small team and we had to check the entire ⁓ this image detection pipeline and the AI models were written in Python. So we created a bridge between Python and like ⁓ system where log and yeah the tests were written on both sides. So I would say it definitely depends on the kind of chip you are trying to build. ⁓ And these days, as you are seeing, most of the open source languages are also gaining popularity, especially Scala and Chisel because L LMs ⁓ understand software much better. So I could see see that happening definitely. What what about the design side? How would that be written? ⁓ design I haven't explored much, but yeah, even there, right, like ⁓ Yeah, there might be new languages but Verlog and System Verlog will still exist because ⁓ because of the design tools and design is a little bit more complicated, right? Because it needs to eventually get translated into Netlist and there are like several ⁓ optimizations that keep happening down the line. I feel design will be the hardest ⁓ to transform, but yeah there is still ⁓ There are ⁓ lot of languages that are coming up. We'll see. Even I'm I'm not sure about that. How about ⁓ debug? So so we talked a bit about ⁓ you know looping and automatic debugging, automatic fixing. ⁓ anything else you envision for debug? Yeah, I would say on the debug side it would be great if ⁓ if some someone forms a consortium and comes up with a open standard because right now the biggest challenge that ⁓ we or like anyone is facing who is building this tools is trying to ⁓ get the data in a very structured manner and feed it through the L L ⁓ and ⁓ do correlation with different aspects, right? Debug is not just one thing where you look at the log or like just ⁓ C a RTL file. You also need to match that with the spec intent, right? ⁓ and for that ⁓ I wish there there will be like some effort on building some sort of open interface that can ⁓ help build this AI solutions much quickly. Okay. ⁓ what about ⁓ waveform? Would that be required? And and I'm asking because you know the more automatic debug happens Probably the less people would have to review the waveform themselves. would we need a waveform after all? I feel yeah, we will just for us to review. ⁓ if you talk about the AI side, I think the simulation data and ⁓ the waveform data it might get ⁓ transformed into some sort of representation that will be easier for the ⁓ L L LMs to understand. But coming to the waveform itself ⁓ yeah, I definitely agree with you. There'll be ⁓ lesser waveforms to look at, but it it is always nice to look at like at least the ⁓ high level waveforms and see the system is working. It will be mostly useful for the human engineers ⁓ and less for the AI I feel. Okay. What about simulation? Would simulation as we know it today be required? Two years from now, ⁓ can there be? That ⁓ the LLM says, well the bug ⁓ you have a bug in line ⁓ twenty, I read the spec and that's ⁓ wrong. No simulation is as needed, no formal ⁓ verification is needed. Here are here are some bugs. Do we still need simulation? Yeah, I would say if you are trying to build a ⁓ complex X SOC kind of project, you definitely need simulation. it it might be ⁓ less optional if you are trying to deal with a smaller block. The reason I tell you why simulation is required is ⁓ eventually you're you're trying to deal with code and the way in the way you can verify a code is ⁓ by running it. So I don't see ⁓ a easy way to get out of that loop unless you your ⁓ L L ⁓ or AI solution is able to internally analyze all the paths ⁓ inside your design and like tell you like exactly okay yeah here is the problem and for that reason I feel simulation is definitely required but ⁓ as you know I could see a future where ⁓ simulation can become much faster because there are a lot of companies working in that domain and once that happens ⁓ it doesn't matter like yeah ⁓ you simply run simulation in a few minutes and yeah, you will get the results rather than like ⁓ your AI or like some tool going and analysing each and every path in your design. So w what you're saying is that as as AI becomes better at ⁓ debugging and fixing stuff, more simulation runs would be required, therefore ⁓ simulation would become the next bottleneck, right? Yeah. Because you see at that point, right, like ⁓ the more simulation runs it can do and like it can get a feedback, the better it will be at debugging issues. And it will you will have a very high quality code at the end, right? So what about productivity gains? what should customers expect ⁓ as for productivity gains? ⁓ I would say even today, right, ⁓ what we are trying to do is we are Trying to remove lot of manual work like trying to search for data and correlation ⁓ with specs or anything, right? ⁓ those kind of manual tedious tasks, e even like yeah, going through the waveforms. I think these kind of tedious tasks will get taken care by AI and it will eventually give you better results so you can ⁓ finish your debug within ⁓ like ⁓ a couple of minutes or like in maybe ⁓ hours instead of like days or weeks. So if we take talking about, you know, one hundred time of the project, let's say a year for the sake of ⁓ you know the discussion, what could the customer expect in design productivity and in verification productivity? What would the customer be able to pull in the schedule ⁓ or do more for a cleaner chip? ⁓ what what do you think? Where are we heading? So if if you are going to take like IoT kind of projects, right? Yeah, definitely you can ⁓ shrink the schedule. And there I think ⁓ most of the interfaces are pretty standard and if AI can learn learn those standard protocols, ⁓ we should be able to ⁓ fin finish off the chip maybe let's say in six months, right? And But if you are trying to build something on like a Nvidia GPU, right, like which is like super complicated, there ⁓ I would say ⁓ you would put more effort in ⁓ making making it better. And ⁓ there you can like do more and more testing and like have a very high quality chip at the end. Got it. ⁓ thank you. ⁓ maybe ⁓ another question is about Protecting the customer IPs. so you mentioned that in the future you might want to actually ⁓ be an IP factory. nowadays y you're providing all the tools on the ⁓ on prem at the customer ⁓ house or compute. but do you see here any security issue that ⁓ you get from customers ⁓ or concerns, security concerns, whether it's on their compute with your software or whether it's from, you know, other companies as yourself that are taking the customer design to their cloud. So I'll tell you about how we are doing and ⁓ because yeah I don't know what ⁓ other companies are offering. Yeah, I do see they offer cloud solutions and also on prem solutions, but Coming to our company, right? Since day one, ⁓ we have ⁓ we all always tell the customers that we never train on your data. Like it is once we ⁓ give you the software it is on your premise and we have no communication onto our cloud or ⁓ to any of our s our services. So the w ⁓ all our products today are like on prem. ⁓ The only thing the customer need ⁓ needs to get is the a L L ⁓ API key ⁓ which is like hosted on their ⁓ cloud infra i ⁓ it's not on our cloud servers. So ⁓ it's on their ⁓ cloud compliance and ⁓ whatever data that is going to be generated and interactions that are going to happen is like ⁓ within their premise. ⁓ nothing ever like ⁓ communicates with our servers at all. And ⁓ the only issue for ⁓ the customers would be yeah, it's their their choice like if they ⁓ want to use like ⁓ either the ⁓ LLM providers like ⁓ OpenAI, Anthropic or ⁓ any other cloud hosted services, or they can ⁓ build their own ⁓ GPU cluster and have their AI models within their premise as well. Siri, so w what would the future bottlenecks ⁓ be for verification? So ⁓ if I think it will be definitely ⁓ simulation, like if we have a simulator that can do simulations faster that will help the LLMs analyze the results better because then they can ⁓ run many simulations and gather all the information and reanalyze ⁓ the data and maybe ⁓ fix the design as well. ⁓ thank you Sirich. anything else I should have asked you and I haven't? No, I think yeah th the questions were ⁓ really challenging and I enjoyed your interview. And ⁓ maybe ⁓ we'll do some product demos in the future as well and I'll walk you through our flow. Thank you so much for ⁓ being with us and ⁓ see you all on the next episode. Bye bye.