opportunities, especially for the new type of accelerators, as you have seen in the presentation. The ideas that we have is leveraging
potentially specific data sets and specific libraries, right? And obviously, MLIR will enable us to do this, this mapping.
So, uh, that's… that's definitely a lot of opportunities there. There's a lot of discussion that we can have, and…
Uh, they got it.
Okay, right.
Yeah.
And Valerie, we're gonna have a longer, deeper follow-up conversation with the team on this, okay?
Okay, that would be great. Thank you, but enjoyed the presentation.
Very good. Um, Maya?
So, I have a question that probably
has a lot of different answers, but I know time is short, but uh… it seems as if when you're doing a chiplet and chip design, that the majority of the time is spent in verification.
And I wondered, uh, what… how you were addressing that, or for the MVP concept, that isn't as important as getting the ideas out there.
Yeah, um, you know, part of… part of our, uh, approach, I think, is to… is to try and.
uh, what, maybe… sideline a lot of the verification.
Uh, tasks, uh, through rapidly and… inexpensively.
creating test hardware. So that our verification.
of, uh, triplet packaging and triplet integration. comes from the use of testing, but maybe this is something Andreas could… Talk about how the definition of our chiplet interfaces.
We'll also, uh, help address the verification challenge.
Yeah, uh, hi, Maya. Uh, I think that there's a couple of things, uh… that, uh, that we're doing. One is, uh.
The open source aspect of, uh… of some of the IP that we're developing, and so… You know, you certainly… there's less verification when you don't have the right code, so when you download.
you know, TensorFlow, PyTorch, right? You… somebody else has done the verification, so… Yes, you do have to worry about how you compose those library functions and create the upper-level logic, but at least somebody has.
unit testers and files and verify the lower-level stuff, right? So that's a net gain. And in hardware, we generally don't do that.
the, you know, we do reuse some. IP out there, but for the most part, we write a lot of code.
From scratch, and so we can say that verification, but I think the much more important thing is the fact that once you go into chiplets.
you just short-circuit the verification altogether, especially all the physical stuff, the… running DRC on the deck, running signal integrity, power resolution. Once you have a die, you have a physical device that you can do a data sheet for.
And then, uh, the verification goes down drastically, so… The idea of turning IP into a hardened physical device is sort of raising the level of abstraction.
By a lot. Now we just have a box with pins on it.
As opposed to, uh… a white box that you really have to verify every time you tape it out. And we see this a lot with, uh, especially with complex IP, like certies and memory controllers.
Where even though we license it from big vendors, and we pay them millions of dollars, we still have to spend 6 to 9 months before we tape out.
And imagine if instead of that, you had a memory controller chiplet that just worked.
And all you had to do was hook up the pins properly, and you're done. You can imagine how much, uh, how much you can save in that, so… That's my… that's my spiel.
Thank you.
Thank you. Thank you, Andreas.
So, let me just quickly say to Andreas, right now, at, uh, the OCP thing, ARM is presenting a chiplet
their chiplet interface.
Like, at this moment, it's on their screen, because Ron just sent it to me in a…
I saw that. The more standards, the merrier, they say.
Yes, I learned from Sadash Ankhor that we're in conflict with the.
the OCP workshop today. Okay, um, I think that's all. Uh, any… any last questions or comments from anyone?
Alright, if not, um… invitations open to all the Meerkat teams. Feel free to reach out to me, or any of our leadership team here at Decode.
Um, we're happy to have follow-up discussions.
Thank you, everyone.
Thanks so much, Jim. Thanks, everybody.
Thanks.