Credo Technology Group Holding Ltd (CRDO) Earnings Call Transcript & Summary

All right. Welcome back to the Barclays Technology Conference. I'm Tom O'Malley, semiconductor and semi-cap equipment analyst here at Barclays. Lucky enough to have Bill Brennan and Dan Fleming of Credo here with me. How are you guys doing?

Doing well. Thanks for having us.

Thank you for being here. Let's start off with the 30,000-foot view. You guys just had a remarkable quarter, and the stock has reflected that over the past couple of days. But what product portfolios did you focus on when you guys first went public? And as you've moved through these couple of years, how has the world sort of played into the areas of the world in which you decided to focus on only a couple of years ago?

Sure. Yes, one of the things that I think is unique about a historical impact is that we've stayed amazingly consistent with the plan that we've been executing to. And so I think if we go back 3 years and we look at the roadshow for the IPO, it's remarkably similar to what we're doing now in a sense that we projected that the Ethernet market would be the first market that we'd really ramp into in a big way. And we did solutions for copper as well as optical retimers for copper. We talked about AEC being a system-level solution that we really pioneered and then optical DSPs being a big opportunity. That's played out. We talked about the system-level AEC solution having the largest TAM, and we talked about generally those 3 product families kind of matching the TAM size from an overall revenue breakout from a Credo standpoint. So that's played out exactly the way that we thought it would. We also projected, when we were going to IPO, that we would enter the PCIe market in the Gen6 time frame. It's taken some time for that market to develop, and it still feels like today that it's a calendar year '25 design-in for Gen6 and a calendar year '26 production ramp. So it's played out, at a high level, pretty much the same way that we projected. I will say that kind of within those markets, it's been a bit different. We didn't expect to do so much customization. We didn't expect to deliver such -- like really various features associated with the AECs. But the moment we kind of realized that the engineers are responsible for the rack design and the way that servers and appliances are put together, they want to have more telemetry. They want to have the ability to do firmware upgrades on the fly, things that have never been considered before as you look back, and we really replaced DACs. And I say most recently, at OCP, we talked a lot about kind of a new development in the AEC space, and it's really specific to AI clusters. We've done a lot of work with xAI. They're a unique team because they're really approaching their design from the ground up. And so a lot has been said about the densification of the data center, meaning how do you get more compute per square foot? How do you get more compute out of the building that you're building? If you can pack more into each rack and the technologies that enable that from a ground-up design is, do you design for liquid cooling versus air cooling? Do you design for the kind of massive power sourcing that you would need to go 10x the power sourcing to each rack. If you can do that, you can absolutely go maximum density. The example that we talked about at OCP was an 18-rack design that was air cooled and was sourced with power that was more traditional. They've been able to collapse that architecture into 6 racks. So the form factor has shrunk. One of the things we've learned about AI clusters is that reliability is like absolute front of mind. And that comes from this effect of link flapping. Link flapping or a link flap is where you get a momentary drop in the link. In a cluster, there's really -- there's no redundancy. If you look at front-end network and say, why haven't we talked about link flaps related to the front-end network? It's because there's redundancy built in. So there are flaps happening, but they're not getting any hit. There's no packets dropped, and that's by an architectural design. You get into a cluster, there is no redundancy. So you get a single link flap, it will take your cluster down. It will take the entire thing down for a significant amount of time to reset. And from a productivity loss perspective, you've got to go back to the start of the training run that you were in. And so secondary effect of densifying the data centers that you've got shorter connections within a rack. And so A is we developed a family of 7-meter cables, 800-gig, 7-meter cables that can span that entire rack now that the form factor has been reduced. And the real driver is reliability. Because the way we develop and deliver the AECs that we're shipping, we call the family ZeroFlap AECs. And so that's definite difference from when we were talking during the IPO. I'll say, at the highest level, we weren't really talking about AI at the IPO. And I think that the way that I view it is that this huge new network that comes with an AI cluster, this back-end network that is literally 10x or 100x the size of the front end market that we are all thinking about. And I also like to like maybe toot the horn for connectivity, not just Credo, but all of the connectivity players that have all been conditioned to think about GPUs as -- that is AI clusters are GPUs, but like a GPU is just a GPU unless you have high-speed connectivity linking all the GPUs together. So I think it's nice that the market is starting to recognize the opportunity for high-speed connectivity as well. And that's new related to AI compared to 3 years. That was a long answer to a pretty short question.

No, no. It's a great summary. I think if I think back about the inception of at least the public version of the company was the transition to 100-gig lanes in the front end, and then AI had really taken off. I guess what I thought was always interesting, and I guess the question that I have now, is you started with the HiWire alliance and you set a standard and you're a pioneer in kind of developing the market which you kind of own today. And now, like we're almost at the second phase of that transition where you said there's always going to be customers and competitors that come to this market that are going to compete with us. This is not a market where we're going to have a monopoly. So you're starting to see -- and I think this is a good thing that you [ generally refer ] to more people talking about this, right? Bigger companies talking about this. So when you think about your competitive dynamic versus those companies who haven't been talking about it as much but are now definitely highlighting it as a major driver for them, one, I guess how do you feel you're able to differentiate? Because those companies have talked about being first as an important thing in other markets. And two, what is your validation of the size of this market moving forward?

Sure. Yes. So when we decided to really go all in on this market, that was a pretty unpopular decision amongst a number of groups of people, including investors. We were private at the time. Our Board meeting that day when I informed our investors, that was an interesting one. But I guess the fact that we are here years later, 6 or 7 years later from the moment we decided to go really after the entire system solution, I think we're looking at a multibillion-dollar TAM. I don't think there's any question about that. You can look to many, many different research analysts that will build it up. They build it up from the bottom, they look at the tops down. You land on a multibillion-dollar market. But I think it's a natural when people assess what markets they can pursue with technology that's available to them, it's natural that they're going to pursue a multibillion-dollar market. So I really view the competition aspect of it as a confirmation of our original vision, which is excellent. There's different approaches between the competitors. Our approach has been to own the entire system just like we would own any of the product that we would build and deliver to the market. From a competitive standpoint, what we're trying to deliver to our customers is the best possible experience from the day that we talk about the spec that they're trying to achieve. I want to be first with delivering samples. I want to be first to go into a qualification, first stage qualification. I want to be first to complete the fleet scale, qualification and ultimately, the first to ramp production. That is the clearly stated objective internally. We've done a good job of doing that at multiple customers. I think we're uniquely organized to be able to do 20 SKUs at one time. We've got the horsepower in the organization. I don't have to call another CEO and ask for his help. If you look at the good news that we were able to share last week, one of the underlying messages from an operations standpoint, how do you respond so quickly? How do you respond so quickly with being able to build the product that goes into that upside? And so I think it's a testament to the way we're organized. I have an IC operations team. I have an AEC operations team that takes full ownership of all of the components that go into it. Of course, we have manufacturing partners that carry responsibility, but at the end of the day, we own it, and we think that works well for us. And so I think this will play itself out, but I think the market is large enough to have several healthy players.

So supply chain ecosystem, how you set up your business in a really big market, I think you see that starting to play out in the customer diversification, right? So up until this past quarter, you had a customer ramp up to a majority of your revenue then ramp down, and a second customer ramp up to over 50% of revenue and then slightly tick down. And with that customer ticking down, you still grew that business. And that's a testament to the fact that you now have 3 material customers in the AEC business. So can you talk about, with that expansion -- you mentioned some up-and-coming hyperscalers already, but with that expansion, are you seeing similar problems addressed across those customers? Or are you seeing a diverse set of applications? And maybe spend a little time walking people through like what problems you're solving with those customers.

Yes. So I think there's different opportunities in different parts of the network. The first opportunity within the market was in the front-end network, and it was with the disaggregation of chassis. Amazon was out there first building their own switch racks. So basically pulling the switches out of the chassis, stacking them vertically, the connections that were made over the backplane inside a chassis were the connections that were being replaced by short in-rack switch-to-switch connections. So that was the obvious first market. And then when we started collaborating with Microsoft, it was clear that we could offer some real differentiation from a feature standpoint in the server, general compute server, to top-of-rack switch. So this is really the connection from the NIC to the front-end network. So that became a big focus. And then probably about 18 months ago, it was very clear that maybe the largest opportunity was going to be on the back end, the back-end network for AI clusters. As that's developed over time, we really see 2 opportunities there. For Ethernet or the protocol that we've been focused on, the first network that everybody realized was the scale-out network, and that was linking all of the appliances to the leaf-spine switch for that back-end network. Big opportunity, probably a 10x opportunity compared to the front-end network opportunity in whole. Now we're seeing the scale-up network is the next big opportunity, and it's happening at 2 players. You can see NVL72, that large bundle of copper on the back of their rack. That is really taking that scale-up network that we've seen inside the appliance that directly linking all of the GPUs on an appliance card. Now that's coming out going rack scale. And so it's a tremendous opportunity from a volume standpoint. And those connections are being made with AECs. At re:Invent last week, I had a lot of pictures that were sent to me showing they've taken the scale-up network out of the appliance and gone rack scale. So that becomes a really nice opportunity long term. And you could make an argument that scale-up network that is actually larger than 10x. So it's maybe a multiple of the 10x. So it's absolutely massive when you think about the TAM growth that the market is going to see as the entire back end is an opportunity for AECs.

So when you think about that scale-up opportunity, there's a couple of differences between that scale-out opportunity. Obviously, you're closer in terms of distance. So passive copper has just hung around for longer. But then you have the, I would say, the clashing heads of protocols, right? You have Ethernet, which has come down very effectively thus far. And now the advent -- well, not really the advent, but the extension of PCIe offboard to certain connections as well. And you guys have started talking more about PCIe as well. So when you look at that battle, I ask this question to companies and they're always like, we're agnostic. We'll go either way. We check all the boxes. But like could you maybe walk through where you see positives and negatives to each? I know that PCIe was a protocol designed onboard. I know that Ethernet obviously was not preferable for AI, and there was always an InfiniBand solution even before NVIDIA bought Mellanox. But just walk me through where you maybe see the world going and where Credo wins and loses in both of those scenarios?

Maybe there's 2 worlds. I think one world is NVIDIA, and NVIDIA is going to take that world where they want to, and it probably sounds like InfiniBand and NVLink. The rest of the world, I think, is going to land on Ethernet for certain connections, and PCIe for others short term. Naturally, if you're talking about in an appliance where you've got an x86 as kind of an I/O controller and you've got GPUs, naturally that CPU to anything else protocol of PCIe is going to be used. It's natural that it landed on that GPU to GPU connection within the appliance, and it's natural that, as we go rack scale, that PCIe as the protocol. So I think there's a pretty well-understood path from PCIe 5, 32-gig NRZ to PCIe Gen6, which is 64-gig PAM-4. The real question mark comes after that is there -- and because that time line is kind of predicated on Intel getting things done, which is maybe schedules haven't been held well. And so how do you look at that GPU to GPU connection a little bit differently and say, how do I get off this time line that I don't want to be on? And also, how do I deal with NVLink being at 224-gig and PCIe Gen6 being at 64-gig? So when you're talking about bandwidth, there is a direct correlation between the bandwidth of your connectivity and the performance of the cluster, well understood. So how do you rationalize planning your next generation at 64 gig when your competitor is at 224? So there's been a lot of energy around UALink in the past, say, 3 to 6 months. A lot of people believe that, that's going to land in a very Ethernet-like protocol, and that there's going to be a move that -- it's probably not going to happen too quickly, but maybe the next step is UALink. In that sense, I think it makes sense to us. I'll say we're agnostic and smile. But that's maybe the way we see it going.

Fair enough. Fair enough. How about we pivot a little bit to the optical DSP portion of the business? So you've seen increasing success there. You've always described yourself as kind of an N-1. Up until this point, like the world was still growing and relatively dominated by a single provider. But as you're making this transition to 1.6T, I think that you're seeing a diversification. I think the companies that our incumbents are also admitting that as well. So can you talk about when you think about your optical DSP in the future, and I think I will point to myself and raise my hand as making a fault. When we first talked about this at CES this year, you talked about the two-pronged strategy at 3-nanometer, right? You had the full 3-nanometer, and then you had the cutdown 3-nanometer DSP for LRO, and I was like, I don't understand this. And the world has really moved to that. So when you look at the opportunity in optical DSP, do you see more dollars going in the 3-nanometer full DSP? Or kind of a cutdown LRO product?

Yes. So it's interesting. Why did we come up with this LRO approach? You've got to go back to a few years ago at OFC when there was this -- almost this urgent call to action for 1.6T that we were on a path on power that was just not sustainable. And so like the easy default answer is take the highest power component out, like remove the DSP. The world has been full DSP up until this point, and so that was a pretty big leap. You get off standards. You could completely -- if you've got control over both ends of the connection, meaning you're off of it, living in an ecosystem of interoperability, okay, maybe that's possible. But the large, large majority of the volume out there, there are standards and interoperability for a reason. And so we were thinking, okay, how do we maintain standards? How do we maintain interoperability? But how do we significantly reduce the power? And so if you look at a typical link, say, from switch to switch, there's actually 3 DSPs happening. From the switch where it's transmitted to the first module, there's a clock and data recovery that's done, or a DSP transmits over the wire, or over the fiber, there's another DSP done. And then it's finally transmitted to the next switch and at the switch, there's a SerDes with a receiver and there's a DSP done there as well. So there's 3 DSPs in the typical link. LRO was basically picking the midpoint. LPO is saying go to one DSP at the end at the other switch, and hopefully, this 50-Gb monster SerDes is able to equalize. Farfetched on a large scale. So we looked and said, instead of dropping it to one, let's drop it to two. And we did it successfully, and we've shown great data. And now we've put the decision in the hands of the engineers that we're working with. And it's not really the decision of the module players because they're very interested in delivering disruptive products to the hyperscalers. It's really the engineers at the hyperscalers that have got to say, I've lived in a full DSP world my entire career. Am I willing to bet on removing a DSP? Is power that important? And that's why we moved quickly to 3-nanometer, because of power. I wanted to deliver a full DSP that was something that anybody could pick up and do a module design that fit under the ceiling on power for these OSFP and DD connectors. And if they were really wanting to go after another 5 watts of power, I'll do an LRO version, too. The good news is there's a lot of activity around LRO in the module space. That leads, by the way, to great full DSP designs. Because if you do the half, you do the whole. And so I like how our footprint is growing within that community of engineers.

Super helpful. One more on the AEC side. I was thinking about second half, obviously, going to be driven by a customer that you've previously had, big ramp up in the second half. A common debate that's had out there right now is when you look at the architectural decisions that are being made by hyperscalers, whether that's to use general purpose silicon or to use more customized ASICs, which direction do those customers go in longer term? I think generally, people agree that down the road, people will use more customized product, but today, we're like very early days in this market and so there's some split. When you think about your ability to attach to an accelerator or to be part of a solution that's using an accelerator, whether that's a general purpose accelerator or a customized piece of silicon, is there any difference in that attach rate? I think people sometimes maybe make the mistake that if you're deploying a GPU from NVIDIA, that you won't find yourself in that solution. Can you maybe walk me through how much of that ramp may be associated with each?

Yes. I think first-level answer is that we don't see what's behind the NIC. So we'll interface with a NIC say 4 lanes of 50 gig or 4 lanes of 100 gig. Literally, it could be an NVIDIA GPU or it could be an internally developed GPU. It could be -- we don't see -- so in a sense, by design, we're agnostic, in a sense. And then beyond that, I guess, I would say that there is no differentiation between GPUs. It's literally at a NIC level. I can give you my opinion about internal silicon versus silicon that's developed by the players today that are in the market. And I think it boils down to what's the amount of gear that you get for the spend? And if you can get triple the deployment if you'd use internally develop silicon, if you can make it work, it's an obvious thing that you'll use more -- you'll get 3x the bang of your buck. And that's really the question is how many teams out there that are internal teams are as good as these leaders in the market. And to a certain extent, I would say it may be a David versus Goliath scenario. No matter how much money you spend, if you're not really actually chip company within a data center, if you don't have 2,000 engineers and if you haven't done this for your whole career, I don't know. I don't know how good a bet that is. But again, I don't care. I just hope for more deployments.

One more for you and then a couple of CFO questions. You've talked more about PCIe as a product portfolio over cables. The retimer market has been talked more and more about by the people in your ecosystem. Is there a realistic time that you could intersect that market? You've talked about Gen6 in the past. It felt always more like cabling was the first area that you would attack. But onboard retiming, is that something that makes sense for you guys to go into?

100%. Sure. Yes, I don't see a difference in the opportunity. It's a different part of the architecture, but you would literally use the same retimer, either it's on the board or in an AEC. And in fact, 2 years ago, at OCP, we showed the conceptual design of having that front-end network come out of the appliance. We showed conceptual AECs with PCIe Gen6. And then at this OCP, we showed live demos, mission-critical traffic, mission mode traffic on an appliance design as well as in a cable. So we showed both. I look at both opportunities equally, and I think they're both large.

Helpful. All right. Just a couple of quick CFO ones. So you have a warrant agreement with Amazon. If you're tracking that customer's exposure, it looks like near the end of this fiscal year, you may come up to the entire term of the agreement. What does that mean from a financial perspective, potentially in Q4? And then second part of the question, not to do all multiparters here, but you were making the comment at earnings that even with a licensing business that you moderated, essentially derisked, you could still see gross margins in your originally guided range. What's changed there that's allowed you to get that gross margin leverage?

So first, let me just refresh everyone's memory on what the warrant was. So we've had it for about 3 years now with Amazon, and it was based upon shipping $200 million approximately worth of product to them. And the way the math works for a warrant is you recognize contra revenue for every dollar that you ship. And in our particular case, it comes out to a little over 9% of revenue, so it's kind of a 9% discount to revenue. So if we ship $1, we recognized $0.91. So some other numbers with regard to Amazon. Q1, they were north of a 50% customer of ours. This last quarter, they were 33%. We've been very consistent over last, say, 3 quarters describing the second half inflection point with the key driver of it being that customer. So that's still the case. We guided to a midpoint of $120 million. So if you look at all of the cumulative amount of warrant that has been kind of consumed, you're exactly right that kind of end of Q3, early Q4, you might expect that, that warrant will be fulfilled. So what does that mean for gross margins? Gross margin obviously depends on -- or how accretive it is to not have it is dependent upon what the gross margin of those products are, and it's a mixed basket of what we shipped to Amazon. But just speaking in general terms, you might see 4 Amazon products shipped, maybe a 400 basis point improvement in gross margin, plus or minus 50 basis points, depending on the product. So that kind of dovetails right into your second question. We guided slightly down for gross margin in Q3. But again, a lot of that, you might think, would be Amazon in the quarter with the warrant on it, which goes away in Q4 at some point, right? So the subtle message that we did give when we talked about IP revenue no longer being expected at 10% of revenue this year or in the future, we reiterated our long-term gross margin model of 63% to 65%, which means that we're comfortable in believing that our product gross margins have kind of surpassed where we thought they would be in the original gross margin model that we profile for everyone. So we're seeing that play out, and by the end of this year, it will be very evident that we're kind of landing right in the middle of where we thought we would be 3 years ago.

Super helpful. Just one more here. You've probably been more mobile than any other company in my space in terms of changing direction as a private company and then a public company. When you think about what's on the horizon, clearly, there's been a ton of new announcements from you guys recently on the PCIe side, but is there a place that investors should be looking for kind of the next transition? It sounds like you're talking about scale-up architecture and the solutions there is kind of the hot spot. Anything that you would point to as a potential next chapter in terms of development?

Let's talk about that next time.

All right. We'll see you next year, then. Thank you very much for being here, both of you. Appreciate it, and congrats on all the good work.

Thank you.