speaker-0: If we ask the only language model one plus one, we'll give you two because you learned that in zillions of times it's during the training process. But not every answer by LLM is always correct because it's statistical. We need to do the grounding, we need to validate the answer from the language model by applying the tools, the form application tools to validate.

speaker-1: This this may be dangerous because it might not be the right sign-off.

speaker-0: And every agent maybe have sub-agents as well. So this is a hierarchy of Asian, a group of agents working together. And the orchestrators basically based on the context and the stage on the plan, basically be able to employ the right agent to do that.

speaker-1: How the agents decide what to put in formal, what to put in verification, what to do in emulation or prototyping.

speaker-0: Excellent question. This basically

speaker-1: Welcome to another episode of Wearing Flip Flops. I'm Ronani Urost and with me again Professor Ziyad. Hi. Great to have you again.

speaker-0: Thank you for inviting me once again for the second episode. This is great.

speaker-1: Today we focus on form up.

speaker-0: great. This is my lovely topic, they would like to speak about it.

speaker-1: Let's let's talk about a bit of the your background informal.

speaker-0: Well, wow, this is I think all my career, you know, the industrial career was touching or working with AI and and recently but before that with the formal from the down of this domain. I remember my thesis, master thesis in Tel Aviv University was informal. Think about it, about you know, thirty plus years.

speaker-1: Yeah. Back then was it in production or just the seeds?

speaker-0: This was the seed. Then we try to do combin combinatorical formal verification, meaning that take a Boolean logic and analyze it. Then was collaboration with Brandon Bryant on netlist and circuit, how to optimize transistors and build functional representation of transistors, talk about combinational equivalent checking, how to verify two, you know, formulas, two, you know. RTLs that are matching on the states. This was the first application of formal verification at the time. It's equivalent checking and I remember several kind of old companies.

speaker-1: So this Intel

speaker-0: Then Intel, you know, worked on the whole formal verification from I think the first application was the Pentium. This was 1995. I believe I was a bit, you know, close that Pentium bug that we kind of you know. I remember the recall at Intel that time just to validate that formally. And this was the trigger to expand and double down on formal verification. With Intel built several generations of formal tools to be consumed by the Intel you know design teams until the Pentium Pro, the P6, we call that the time. Then Jasper, several years in the US, came to Israel, continue building the startup. And then the whole applications of formal beyond you know model checking or property verification, we came up with all these apps with you know from the architectural validation down into kind of you know gate level analytics and and optimization, formal verification, etc. All the apps. Then you know after that, basically being acquired by Cadence in 2014 and we build you know special Business unit for Jasper and continue growing with the big kind of backbone of cadence. And now this is basically you know the the de facto standard informal verification in the world in chip design. So even you know, people in their resumes, and if you people want to hire somebody formal verification, they ask knowledge about in Jasper in particular, and this is basically. I'm teaching formal recognition at Technon these days. The the demand is huming everywhere. People call me, Ronet called me, hey Ziad, how are you doing? I said, Great, give me five people. I want five references for five people in form lubrification. So the demand is humangous. So we're teaching a course, kind of fundamental course in the technology, and you know, we start with the fifty people. Last round we have about two eighty people attending the the the the the course.

speaker-1: I guess you're qualified to talk about formal.

speaker-0: Well yeah. Okay.

speaker-1: so let's dive into the first question and it it it kind of you know relates also to the previous discussion that that we had. So formal gives a mathematical yes no answer and LLMs and AI is more statistics. how do those two next?

speaker-0: Great question. Yeah. So basically again e every problem we can, you know, in our domain we can redu we can convert it or simplify it into two kind of answers. One is yes no answer, another one implementable, implement for me this in certain kind of structure, etc. It's called the realization or synthesis in general, okay. So the decision, yes or no, okay, it can be done by language model, okay, based on training, because language model is a statistical model. If we ask the only language model one plus one, we'll give you two, okay, because you learned that in zillions of times it's during the training process, okay? But not every answer by LLM, okay, is always correct because it's statistical, right? We need to do the grounding, meaning to validate the answer from the language mode by applying the tools, the formal recognition tools to to validate this. So basically, content generation, let's say in the formal application, I want to create from spec set of properties, assertions. Okay. So the properties could be correct, syntactically correct, or syntactically incorrect. If they are syntactically correct, the question are semantically correct or not. So we need to have the tool underneath to get the properties that are being created by the language model and check them syntactically. And guess what? Sometimes the the the syntax is incorrect. Yeah, recent language model become more, you know, you know, dependable that can create a correct, I mean syntactically correct question. Are they semantically correct? Are kind of adhering to design behavior, need to do the formulation engines and JASP in this case to validate that. To have the language model to do validation of the language model of the properties, there are some, you know. Early results here and there, which is okay, but at the end need to send that proof to the the right engine or the right proof system to validate the results. So this is this is the this this is the creation. The other one is about managing the proof. Manage the proof basically it's kind of flow. It's basically how to create the assertions, how to divide the assertions, which one the assumptions to rely on, which one to prove. how to cluster them, how to define in what order, which LAM is helping other other other properties. That proof management, AI can do significant and very good job on this. It's kind like planning. This is the essence of the language model and the AI.

speaker-1: A question about that. Yeah. So Ashish Dabari, the CEO of Axiomize, which we'll have in a future episode, he said that the the assertions that are created by LLMs might give a false confidence that you have you know a lot of things done, they're green, and you're good. And this may be dangerous because it might not be the right sign-off. What is your opinion?

speaker-0: Short break. Quick question. Got a hardware story? Or a bug you'll never forget? Don't be shy. Drop us a note and come tell it on the show. In the meantime, be a friend and rate us. Bugs have feelings too. Okay, back to the show.

speaker-1: What is your opinion?

speaker-0: Definitely. This is about the how you measure the quality of results or the KPI of the formal agent. If the KPI are low level, meaning that, you know, counting properties that are being created by AI as a measure. This is it's kind of BS. Okay, it's not by the count of the properties. Another one is hey, I used AI and create for me covers. And based on these covers, I managed to cover my entire design. This is another BS, very low level, because you can put covers on the output and say, Okay, cover this, cover this, cover this. At the end you will make sure that you know that every everything's being kind of connected to the output. It doesn't make any sense. So it's

speaker-1: Still the responsibility of the designer of the verification guy to make sure that things are so

speaker-0: So this is why we have in every company we have the expert users to decide on what are the metrics, what are the the the properties to verify, how to turn spec into real properties that cover what we want to what's the intent needed. Now AI is being trained to answer this, how to you know create these assertions, but at the end, the the expert users need to be able to review them. Now, agents. They are all agent, Simple Asians can achieve results based on low-level KPI, and they claim we are doing great. And we see I see it in the market. I see in many, many kind of incidences that say, hey, we have done this and here's our our KPI. Well, I I cannot read the result. This basically makes me a bit nervous. With all my history at at in in this domain, this is like very, very

speaker-1: Do you have a specific example?

speaker-0: Yeah, well, of course, you know, the I some customers came up with, hey. Here's my my KPI key matrix for for success for the quality of results. I give it to this tool, I give it to the other tool, and I don't see differentiation because they're so both getting 100% coverage. And I said, well, let me see what what what KPI and what design you're doing. Every design is like a Mickey Mouse design, small design, like a little FIFO, little counter, you know, of course what they have in mind into to to to to start touching the water there. And the low-level quality results, all of them doing great, can run it with the clothed code without any agent, just clothed code without any tooling, and does the results and give up with the with the with the good results. Of course, the question is how to measure the real impact of the agent in this domain. Need to make sure that you capture the right intent, you write capture the right assumptions about that intent, be able to do proofs. It's not only I'm doing cover here and there, I have some properties, need to see how what's the verification essence out of the agent and how to measure the verification.

speaker-1: It reminds me what Claudio mentioned in in an episode that we we did about how to verify big chips and graviton. And you know, part of the verification plan is not just what to check, but exactly how you check it. Because if you say I'm checking coherency and you're not doing the right things, you're just saying that you're checking it. You know, can do a check mark, a green stuff, but you didn't check anything, and anything. So it it really matters the how.

speaker-0: Exactly. And this is how I'll talk about the mental model later on. But but you know, we have this you know scenario where we you know working with let's say with ARM and they have a new AMBA protocol, C H I J, whatever, and they talk about in the spec about coherency, okay, and you read what the spec is written there, I read it, I can understand the spec differently than then than you can understand it. You know, maybe have something in mind, some assumptions. That's not explicitly written there and have so

speaker-1: Sure, a lot of times there's ambiguity.

speaker-0: as ambiguity. And we had the kind of task force at cadence from different from the and you know from from protocol to go into emulation, to go to simulation, to go to formal kind of study group to understand. And some and many times we went back to the you know the spec owner to hey, the spec is ambiguous here. We need to do a better job in describing that. So verification is very high touch, okay. You can do little verification and claim good results, which is okay just for marketing stuff. But you know, to the responsibility is high. A chip can go in in performance less than the spec, little, it's fine, works. But functional verification, you know more more than me. Something something wrong, okay, they kind of did or alive in in in in in in day one, basically. This is basically the responsibility is high. And formal because it gives yes no, correct, incorrect is so critical. And I saw these days some incidents that people using other systems to with AI and hey, I did the proof. And then you think carefully, you see that sometimes they assume something without verifying the assumption, and based on assumption get the proof. But you go to verify the assumption, assumption is wrong. Yeah. So so there's this is it's kind of decades of innovation and robustness and all the time to tell you the truth that all the time we find some issues to correct to can to correct the the engines, correct the flow, to you know close holes in the correctness. It's it's you know like uphill climbing here in in the

speaker-1: about about that you know correctness and independent check in in in this era so an agent writes a property then a another agent runs and and do the the checks but then is it an independent correct check because you you give agents to do everything where where is the human in the loop and you know what problems or solutions can can

speaker-0: It's always about it to see the entire flow. Okay. it's okay and it's good to have a mix of agents with different contexts and system prompts that drive them and maybe using different language models to cross-check, which is good. And this is a part of the orchestrations and the harnessing of the agents. And at the end, you know, in this domain, the human in the loop is still very important to check. There is no anomalies and something being assumed which is incorrect. So I believe as going to autonomous, I give an example of autonomous here. Basically, I in the previous episode talked about an example that sometimes to prove something, to prove property, we need to put a set of helper or tactics or axioms to be helping that property or helper assertions. And every round. By human, create one, two, three in every hour, two hours, and spend days and get to some thousand of these things. Now, the autonomous formal verification is basically the agent can create the helper assertions, prove them, and Jasper give a systematic way. It's called proof structure to manage these kind of decisions. So we kind of give safety net to the agent to do the right job. And basically it's not like ad hoc. So the tooling is supposed to give some structure to help the Asians to do the autonomous things and back and bookkeeping what's being done and have the tool to do the checks if the that proof is is going through the right way and there is no self-dependencies like using self-assumptions to prove assertions which are not proven. So this kind of mechanics underneath is in essence it is missing. It's missing you cannot rely on just I got the agent doing that.

speaker-1: For now, because we are four level four and not level five yet. okay, so formal provides kind of three solutions or three outcome outputs. whether the property assumption was true, was it false, or if it's a bounded, it's true for this amount of cycles. that's kind of the the span. adding AI to the blend, does it affect how many bounded results are there?

speaker-0: Well, our our you know it's very important you know topic. So as you mentioned that it's you know we have inclusive and ex and non non-inclusive results. Inclusive results meaning that we have z you know true false, counterexample and evidence of the false, or we have depth proof, okay, get to depth let's say two hundred. Okay. The question, you know, with AI, can I go further? Okay. Now of course. The question is how to measure the results from formal and from sorry from the AI, the intermediate progress by AI. So we need to have a systematic way to measure the impact of the AI during the process. So for example, if the AI discover a new fact, let's say new helper assertion, okay, the question, this new fact is it doesn't going to help me advance the bound or not. So, what is the impact of new fact, new helper, or new knowledge that being added to

speaker-1: Yeah.

speaker-0: that? So exactly. So we we have several ways how to imp to measure the impact of the bound. Okay, now if I'm doing, for example, induction proof, okay. Induction proof usually it fails in the induction step because the induction is taking a more generic way, how from all of those lists. Deduction is basically one way to prove property by you know verifying that property holds up to certain you know depth, okay, and and you know this is what called the the base of the induction, like in the mathematical induction in normal you know studies, in math studies. And the step means that I'm able to verify that the property holds on all possible states, not only on the state that's being reached up to bound. on the base bound k. So basically it's a a a way to do generic proof by assuming more states to start with in the proof. And usually it gets you know false, false negative basically gets kind of counterexample and need to strengthen the induction by adding more helper assertions to remove some of the initial states that are used in the the the k-induction and basically helper assertion will will will will will be useful okay if it tries to remove some of this wrong failures of the induction. So we have always different ways to measure the goodness of a new helper assertions and this is part of the artifact of the engines how to measure that. So so the point is AI in the loop in the harnessing it can create you know new knowledge. The question does the new knowledge is is adding more value to the proof or not? And this is the experts, the the tooling and the tools and the engines can, give some rewarding. Some negative rewarding, sometimes adding more helper assertions just make the proof is worse. Sometimes it's better. So all this are reinforcement learning between the AI and the proof engines, this is the the the the essence, how to make the big leverage or great leverage of the AI.

speaker-1: Let's talk about apps. what are apps?

speaker-0: Apps basically is a more unified way to solve a verification problem, okay, using self-contained methodology or self-contained set of tools or capabilities. Example, if I want to do security verification in chip design, okay, I want to have a dedicated capability that checks that there is no way to to to hack the keys, to override the keys in the chip.

speaker-1: So is that pre coded assertions and properties

speaker-0: Exactly. Package includes some some libraries, workflow, certain algorithms that are dedicated to this. For example, I want to compare two designs, do equivalent checking between designs. So to build the mitre and how to do the checks and do the cut points to reduce complexity. So basically think about an an app as a recipe, dedicated, replicated, commonly problem used. by many, many users worldwide and we put an app and the apps are look and f they have the same look and feel, meaning that you can go from one app to other app with the with feel that it's still at home.

speaker-1: So can AI agents replace apps so

speaker-0: Think think about apps are like you know the you know as as another tool, okay, for the for certain thing. Okay, it has a methodology from the user and has a technology and the app is enabled for that. AI can be added to augment and improve the the the the the the flow of the app and make it even more versatile, more dynamic.

speaker-1: Can you place that entirely?

speaker-0: I I think Probably we can come up with more leverage of the technologies in the apps, okay, for doing with with AI. But think about these apps are very closed for sign-off, okay? So the AI will be great for working and creating the workflows, etc., and give you, make progress in the design, the verification. But then everyone has regression. We need to run to run for for tape-out. You need to run the entire thing because people don't take much of a risk. Just hey, I want to tape out based on you know what the agent did today. Maybe in in in a few years, basically we have the confidence and the the the the the marriage between the tools and the AI becomes tighter. This will be, I think will way to go, but for time being these technologies will will will continue thriving.

speaker-1: So let's talk about support. so do you have statistics about you know using, for example, Jasper? how many users are using field application engineers and support before the AI era? And nowadays, I mean, does AI affect the level of support that you need to provide customers?

speaker-0: Well, basically I think that the kind of support is evolving. Okay. Meaning that up till day before the AI, so the application engineers, as very well, basically, they come to help the the customer train on the tools, train on the methodologies, you know, chase some hard problems, mm, misbehavior of tools to report some some issues or some improvement required in the tool by the RD. That requires and every a application engineer is dedicated to certain area because it's complex and they dive, have experts in timing, experts in place and drought, experts in informal, experts in simulation, experts in coverage, experts in debug. They have kind of more than 50 different talents there, kind of talents. So with AI, things become more entangled in the context of quantum, meaning that you know the AI combines Different skills together. I talked about the front-end design and verification. See, the design and verification become convoluted. So basically, the A the application engineer needs to know multiple domains, and not only in doing multiple domains, so because the AI is handy and we deliver the AI platform, in this case Jedi, so our application engineers can build their own agents to ease their work and even deliver more results and help. the the the the the users in much more advanced, more sophisticated things. So I see evolution in the expectations on the application engineers and what they can do today much more than can can be done before. So their productivity is much higher and they can invent new technologies on the spot by applying AI. And actually we are training our AEs at Cadence, you know, you know, Cadence has thousands of AEs. I'm personally involved in the summits and you know It's gonna like crazy. Everyone, jumping on it to be able to leverage this this knowledge and and get out of it and support and innovate, come up with new solutions. So remember we talked about AE where basically AE's application engineer can build their own scripts and their little utilities. Think about that in ten times more because the AI enables much more.

speaker-1: what about you we talked about you know simulation and you know formal we have emulation in the previous episode we talked about the master agent and super agents and how does it all run together? How the agents decide what to put in formal, what to put in verification, what to do in emulation or prototyping.

speaker-0: Excellent question. This basically, the the the head agent, okay, empowered by Frontier LLM in general, and you know, based on the query and based on the task, it can do the the planning, meaning that to divide the problem into sub-problems, okay, as part of the planning. And every sub-problem can be classified by either the skills that being ac accessible by the head agent or by trained LLMs or what called the SLMs small language models to be dedicated to this task. So the head agent be able to launch or to do harnessing to launch the the right agent. For example, in in formal verification, you will say, okay, I have, let's say, today have a flow, raise the design, okay, raise the spec, create help, create the assertions, you know, Build the setup, understand the clock, the reset, compile the design, you know, build the tasks, the every task, basically the set of properties to verify with their corresponding assumptions, send these tasks in parallel to the engines, get some results, debug results. This flow

speaker-1: So whose responsibility?

speaker-0: is kind of basically built in the tool, but all the steps are kind of need to be invoked manually by the expert or by scripts. So what happened? The agent is orchestrating all the steps.

speaker-1: Is it the agent responsibility or the owner of the verification plan or the specific one? Or again in in in in the episode about how to check graviton. So one person was in in charge of the holistic everything, whether it's verification, formal, emulation, is it still the person or is it

speaker-0: Exactly. This is a hierarchy of responsibilities. Maybe same person has multiple responsibilities and maybe different persons divided the responsibilities among each other. If you have a think about it logically, you have a verification, big verification task. Okay. Now we need to have verification planning. Okay, what I need to verify when consuming the spec, I analyze the spec, I build a mental model with the spec to understand what are the essence, what is being needed to be What's the content of that? What protocols you need to verify? What final state machine reachability you want verify?

speaker-1: So it's one layer, a layer of the formal, right?

speaker-0: Then go for every task need to be dedicated to multiple to the right agent. And every agent maybe have sub-agents as well. So this is a hierarchy of agent, the crew of agents working together. And the orchestrators basically, based on the context and the stage on the plan, basically be able to employ the right, you know, agent to do that. And sometimes agents they they delegate to each other, meaning that one agent get the job, I say, I need to have assisted by other agents. An example, I'm doing formal verification, I want to do coverage analysis, okay, of all these properties. But I know that simulation has done the coverage analysis. So I call the the simulation, hey, run these tests, show me the coverage that you found, I will get added to the formal coverage database and the missing ones I will focus on. So kind of like more collaborative agents going to work together. It's nothing in it's the same logical things that the engineers, real engineers talk about. We're trying to automate that by having the language model is the way to orchestrate among different agents and do the end to end verification.

speaker-1: Makes perfect sense. I'm trying to find a question that is not AI related. So here's one. talking about the cloud, how how is the readiness of formal for cloud usage?

speaker-0: Well it's it's in at can I speak about Jasper. It's in production for many years. I remember we are working together in the past on some exposures with the pre previous you know work and we support all the clouds, Google, Amazon and you know, all the clouds around. And so with Azure, you know, basically the the tools are built from the architecture perspective to be able to launch jobs seamlessly on parallel on-prem and on the cloud or mixed mode, the hybrid mode.

speaker-1: So there are orchestrators as LSF. do you base on them or

speaker-0: Yeah, we will we'll we don't want to do this resource management inside, basically. We rely on the resource management available by the customer. Okay, some of them

speaker-1: Let me ask the the the question. So, for example, at just an example AWS has spot instances. spot instances are compute that is is very cheap. You can just demand it on the fly, but it can also be taken from you with two minutes notice. So if you run a property and and have to prove it, and it's a very long one, let's say it's it it It takes four hours and you know, two hours into the run, you get a sign, hey, we're taking the the spot instance. how do you cope with that?

speaker-0: Yeah, this is basically it's a well-known problem and being addressed. Basically, when you run a property, okay, and let's assume this is a very decent one, end-to-end and very complex, requires hours to finish. So it's there is no it's not a single job that runs on the cloud to verify it. It's usually multiple jobs. Running in parallel with multiple algorithms, we call them orchestration and the proofmaster to be able to launch multiple jobs and each one try chase the proof. If one of them be taken, you know, was put on the spot instance and make some progress. First of all, whatever being done as part of the spot instance period being communicated to the other jobs running on the same property. Now. If that spot is being taken, that means that job is being killed. There's other N minus one jobs still running. So basically the system is resilient to cope with this kind of unexpected failures, call it failure or kind of resource dynamic.

speaker-1: What what is not responsive and then asks kind of an LSF or any other runner to run another job?

speaker-0: the the the the the the proofmaster of of a Jasper it it's gonna observe that these jobs and communicate with them all the time. If one of them or some of them being disappeared because whatever reason maybe it's killed, the machine is re rebooted or the spot instance is being taken, whatever reason, the system is resilient to cope with that and even launch new jobs in other places.

speaker-1: What about the other side, the economics? so if for example a a proof is is taking hours and and going nowhere, and and you know customer is using thousands of instances of compute, it costs a lot of money. Who who knows to say, hey, we should kill those? It's th those are just costly.

speaker-0: This is the stagnation, we call the proof stagnation, meaning that a proof is running, and we observed, the orchestrator at at Jasper understands that this job is not making progress, basically making taking too much memory and stuck on certain depths, etc. So it has the ability to re you know refocus itself. into different modes to go to bug hunting things. So the tool is so smart in the way that can manage this limited resources and we get to the resource limit and resiliency. Another thing is basically since the tool is running regression all the time, it learns from the data and the proof behaviors we talk about optimization AI. So it has this optimization AI capability in Jasper. predicts the memory, what needs to be memory, what's memory and consumption needed for that property based on the behavior runs.

speaker-1: Then how does it use it?

speaker-0: It can basically we have them memory aware. It's called map, memory memory aware proof. Basically, based on the property, it estimates what memory it needs upfront before running it. And does the allocation to the right instance for that to be more careful and more economic in the proof.

speaker-1: Very useful.

speaker-0: So this is very important and this was J edited two years ago and this is very very very important feature. So this I think resources become very important now in the compute, now in AI as well, because you pay on tokens, right? So the whole thing about in the proof itself, not all the properties, not all the tasks in the in the whole Jasper flow require same level of reasoning. Some of them would need deep reasoning, some less deep reasoning. The question is which LM will be used and which LM is trained for specific tasks in the flow. And we have set of new pre-trained sorry, post-trained language model called SLM or small language models that are very dedicated to specific tasks. For example, a task that does induction proof, I talked about that. You have a small language model to attack this and make this decision of creating helper assertions and use them to converge much more efficient than using the generic way of language models.

speaker-1: Amazing. So I wanted to you know brainstorm with you the future. Of course. kind of the the holy grail in the future is here's the spec, here's the quantum machine. just let me know if the chip works and if not, show me what to fix or fix it and we're done. No simulation, no human in the loop. you know five phone steroids. How far are we from this?

speaker-0: Of course, the Nirvana, lots of effort being invested on quantum. I myself you know was digging into it kind of several you know long periods of time. This is a promising the question is the maturity of the technology to scale. So qubits took about a few hundreds of qubits, maybe a few thousand of qubits, and I followed the progress by you know by the Google and IBM and other companies, decent progress, but still far from being ready for scale. If you fast forward, let's say five to ten years from now, yeah, I believe the situation that we have a quantum computing sitting in the in the cloud and they are ready for dedicated jobs, then they're not going to replace the classic compute. I don't think so. But they're going to be working together with the co with the classic with the normal compute with the Of the servers for certain tasks. I think in the verification space, in the form worker space, will be sweet spot for quantum. Because talk about state space and the fact that qubits, if you have n qubits by, you know, a qubit is like you know, like like a bit in the but it has the qubits can you know can visit all the state space in one cycle, meaning that if you have n qubits. So have two to N possible states. So the quantum sits understand all of them in one cycle. Well in the in the research things, we collaborate with our customers. Some of the customers they build you know quantum circuits. Yep. They're using our you know photonics and and tools from Cadence and we collaborate with them, some investments happening. But I believe this is the will be the next big b big wave to to collaborate with AI. So AI today is the the big wave. I believe the quantum It's not be like the the the the the similar wave AI will

speaker-1: Perfect.

speaker-0: be augmenting and will leverage actually the language models, if quantum compute become, you know, capable to host a language model, this is will be killer application. To have language model runs in blink.

speaker-1: On not only for semiconductor.

speaker-0: language model in general, basically on a compute, will be dramatic for the entire, world in all industries. But to get there, lots of and in in quantum the fidelity, that basically think about the circuit, quantum algorithms like a circuit, going from the inputs to output. As as the circuit becomes deeper, the the reliability of the measurement will be

speaker-1: No está.

speaker-0: the noise will be high. So how to make it the reliable in compute. This is take some time, lots of redundancy in the quantum in the qubits to kind of try to compensate on the on the fidelity issues, but

speaker-1: Well, time with looking looking forward to to seeing that. Definitely. I think I ran out of most of the questions. Anything I didn't ask you that I should have

speaker-0: I think we recently see that models, you know, frontier models from the big three, four companies talk about security of the language models, and they get to something weird, they lost control, etc. And this reminds me with the domain of security verification informal in the chip design. So I believe investment and trying to understand how formal verification or formal methods in general will be capable to cope with this problem. This is a very interesting topic of research and investment and collaboration with the with the frontier language model providers. So

speaker-1: You're saying looking into we we left a bit the semiconductor world into verifying LLMs with formal, is that what you mean?

speaker-0: I found a bug. Your five-star rating of our podcast is missing. Rate us on your favorite podcast platform. Thanks. See you on the next episode. Yes, it's for the general industries, not only for the chip design, basically. Think about you know in in chip design we verify security to for certain specific what you call the weaknesses. Okay, meaning that basically To protect some keys in the way that there is no way to override them or to leak them out or they are behaving according to the security protocol. Basically, we do the formulation for that. If you can zoom out and take the same idea into language model, language model fits in an environment, okay? I want that environment to be safe, meaning that I don't want a language model to be able to go beyond its allowance okay meaning that it doesn't go to illegal ports who can override something or kind of you know create malicious or create software that lives somewhere illegally etc we need to think about all these common weaknesses that the language model it's a responsibility of the of the LLM providers to see what are the those possible weaknesses and have kind of a kind of global collaboration on that to build the list of weaknesses and have this set of weaknesses available for the formal method to standardize that, to formalize that, and check on the fly that such weaknesses are still protected. And basically this is it's a big concern for the whole industry. I believe formal verification will play significant role in addressing even part of this problem with some methodology, with some regulations, etc. This will will give a big impact for the industry and increase our confidence about AI. Now, people start to see, okay, AI we're going to be out of control. shall I stop it? Some ideas, hey, just reduce investment on AI. I don't think it's the right thing. We need to continue investment in AI, but invest in making protected and make sure that we are doing the right thing right and and formal, I believe. It has the capabilities to do this. Okay, I I see some some progress started. I'm involved myself on some of these ideas.

speaker-1: Amazing. It seems like something, a topic for a full episode. for now I wanted to thank you very much. I really enjoyed our discussion. thank you very much for being a guest.

speaker-0: My pleasure. Thank you.

speaker-1: And thank you all for another episode of wearing flip-flops. See you on the next episode.

speaker-0: You