Microarch Club - 111: Kay Li

Episode Date: May 8, 2024

Kay Li joins to talk about custom hardware used in high-frequency trading, development workflows for FPGA and ASIC design, and why verification has become a bottleneck in the design process. We also discuss SiLogy, the startup Kay founded with Paul Kim to improve the design workflow, including their experience applying to and going through YCombinator, their initial target market, and how the platform could evolve over time.Kay on LinkedIn: https://www.linkedin.com/in/kay-li-84924128b/Kay on Twitter: https://twitter.com/silikayliDetailed Show Notes: https://microarch.club/episodes/111

Hey folks, Dan here. Today on the MicroArchClub podcast, I am joined by Kay Lee. Kay is the CEO of Syllogy, which is a Y Combinator-backed startup building a collaborative CICD platform for integrated circuit design verification. Kay has had an interesting journey to working on hardware and eventually founding a company. We begin in North Florida, where Kay grew up and fell in love with mathematics. This takes him to the University of Chicago, where in addition to math and computer science, Kay studied finance and was exposed to the local high-frequency trading industry. Kay offers a unique view into the use of specialized hardware in high-frequency trading and describes why FPGAs have become popular in the field.

However, despite their effectiveness in latency-sensitive operations, the development workflow for FPGAs has remained cumbersome and inefficient. Kay's own first-hand experience with this process led him to start Syllogy with his co-founder, Paul Kim. The latter part of our conversation focuses on Kay's vision for Syllogy and how the FPGA and ASIC development process can be improved by borrowing from the workflows we have come to expect in software development. We also walk through the process of applying to Y Combinator, discuss what it takes to start and run a company, and talk about how the rapid rise of AI workloads could lead to a rise in the number of chip companies. One of my favorite parts of hosting the MicroArch Club is having the opportunity to talk with both folks who have had a huge impact on the field of processor design and those who are in the earlier stages

of their journey to doing so. When talking to Kay about Sylogy, I can't help but wonder if 50 years from now someone will be hosting a podcast and talk about the company with the same reverence with which I refer to historical EDA companies like Daisy Systems and Mentor Graphics. Either way, Kay and team will be part of the story, and I'm excited that there are still folks like them interested in pushing the industry forward. With that, let's get into the conversation. All right. Hey, Kay. Thanks for joining today. Yeah, yeah. It's good to be here. Awesome. Well, I'm super glad to have you on the show.

I've had a number of different folks from different backgrounds on the show, both folks that have kind of worked in the industry many years ago and are now maybe retired or at the latter stages of their career. I've had a few folks who are working in startups today and kind of on the more modern side of the industry. And I think you certainly fall into that category. And one of the things I really like is kind of comparing and contrasting those different experiences. So I think we'll have a lot of fun maybe learning how you've been inspired from folks in the past and developments in the past, but also learning about maybe what the work you're doing today is going to bring to the

industry as well. Yeah, yeah. Sounds good. Awesome. Well, if you've listened to the show at all, you know that I like to start with getting kind of folks' background. And I'd love to learn kind of what your introduction to computing was and maybe kind of like how that shaped the path you went on, you know, starting in your childhood. Yeah, I mean, like I didn't have like an extremely intense like background with computing growing up. You know, like my parents always had like a computer growing up. And my dad actually did research on like numerical analysis. So I remember at one point when I was in like middle school or something, I asked like if you could help me like learn how to program. And then he showed me Fortran. And I think that kind of ended my exploration at that point for a

little bit. And so, yeah, I mean, like, I've always just like been like goofing around on the computers. You know, a lot of it was just like doing like HTML stuff, or just like, like web based things, like nothing too elaborate. And yeah, those were my early memories working with computers. Mostly, I was just focusing on doing math, and that's, like, what I went to college for. And, yeah, I kind of... Yeah, I kind of did, like, some of the computer programming stuff a little bit later on in college, yeah.

Gotcha. Do you remember what your first computer was or the first machine y'all had in your house? I don't... Oh, man. I think it had, like, an... You know, all I remember is, like, I think it had an Intel Pentium 3 processor. That's the one that I actually remember using with any regularity.

And I remember when processors started getting like above like one gigahertz and then like quickly above it. It was like my mind was blown at that point. Sure. Yeah. Yeah. I don't know. It was great. I mean, like things change like so quickly during those times. And I think that's, you know, I mean, that obviously propelled a lot of innovation

forward because, you know, you can just like wait a year or two and then like, you know, clock speeds would be like so much higher. I don't know. Like your processors would be like so much better. Right. And then, you know, I went from like floppy disk to like CDs to DVDs and like all that kind of stuff and like flash drives. I don't know. It was a really cool time. Yeah. Awesome. Was the kind of like education environment you were in, this is one of the things that's kind of come up on the show a few times.

Was there a emphasis on computer science or was that not something that was really expected to be studied in kind of your high school and middle school environments? Yeah, not at all. Yeah, I mean, my,, yeah, I mean my, yeah, so I, I grew up in Northwest Florida. Uh, I was kind of taught by like, you know, like riverboat gamblers and like itinerant preachers, like that kind of thing. So yeah, it wasn't like the, I mean, I had, I had a pretty good education, um, in some ways, but it definitely wasn't like a high tech. Uh, tech. Yeah, like a lot of that stuff,

I just had to like figure out on my own. Yeah. Gotcha. And you kind of gravitated to math there, you said. Well, how did that manifest in high school? Were you kind of like getting involved in math competitions and things like that? Or was it more of just like within school, that was your interest? Yeah, I did a ton ton of math competitions and i took a lot of like math classes at uh the university of west florida like after school hours so like uh it started in the summers like um you know uh starting in like fourth or fifth grade i would just like audit like some random math classes where my dad would let me and then uh eventually i started taking like more advanced math classes and my dad would let me and then uh eventually I started taking like more advanced math classes and uh that's just what I really liked and uh you know it's

very beautiful because like you can just do it with like a piece of paper and a pen and you know and like a book and so you can just like learn a lot and uh you know it's fun like just like flipping to the end of like a book to see like what I will have learned after a certain amount of time so right yeah I still like to do a certain amount of time. So, you know, I still like to do like math stuff every now and then, um, you know, not with any seriousness, but like, it's all something that like, you know, I hold dear within my heart. Absolutely. And you decided to, uh, go to university of Chicago, I believe, which is a great school. And, um, I think you studied math there. Was that kind of like a natural transition?

Obviously this is the thing you're interested in. YouChicago's, you know, good in that department. Was it just kind of a seamless transition into college? Well, yeah, I mean, I wouldn't call it seamless. I mean, I basically wanted to do math the entire way through. Yeah, I mean, math is like, I mean, it's very beautiful, but it's also like very difficult. And I learned fairly early on that I was never going to make it. I was like a mathematician. You know, I was just being outclassed by like, you know, a lot of my friends at the time. I took like a notoriously difficult math class and actually stuck through all three quarters of it.

We're on the quarter system. And, you know, yeah, but I basically realized that i wasn't going to cut it as like a math person so i had to like try to figure out like what else to do um and you know like uh that was a bit of like a ego disappointment or something but um you know the start the scars of which i carry to this day but you know uh yeah but it was good to figure that out sooner rather than later because i know a lot of people who um continue to do math and then we're just kind of like tortured by it for the rest of their lives. I've only been tortured by it for most of my life. Right. Fair enough. So when you kind of decided or realized perhaps that math was not kind of the professional path, at least purely math, right? Where did you kind of start to look

in terms of what kind of profession or what you might want to get into after you graduated? Yeah, so my dad's a professor. So he naturally wanted me to be a professor as well. And my sister like went to graduate school for accounting. She got a PhD in accounting from MIT. And so academia was like the obvious route. So then I kept taking math classes because like, you know, that usually impresses people. And I was going to try to do maybe economics, maybe like finance, like one of those things. Towards the end of my time, though, I kind of realized I really did not want to go into academia. And so that's how I got into finance, basically, is, you know, like what requires like a lot of math

and what could I, you know, like, I don't know. Yeah, it pays better than grad school. So I could try to figure that out for a little bit of time. I did take some computer science classes in college. You know, mostly, I mean, discrete math, which has math in the name. So that kind of barely counts. Algorithms, which was taught in the name. So that kind of barely counts.

Algorithms, which was taught by like Laszlo Babay, who's like this like great, like theoretical computer scientist who like invented, instead of turning it into like something where you like write depth first search and like Python or something, you turn it into something where you ended up doing like these like proofs related to like whether or not something's NP complete, like, you know, stuff like that.

So that was fun too. but then I did functional programming so you know um in Elm which was which was honestly a lot of fun yeah and uh yeah yeah but then I eventually worked my way over into finance gotcha and you know being in Chicago uh one of the previous guests I had on the show is Matt Godbolt, and he works in trading in Chicago. And I had a kind of a bit of a personal experience going to university in St. Louis and then going up to Chicago. I was kind of the computer science finance kind of track as well. Was it kind of like that was the natural thing to do to get into trading if you were going the finance route? Or was that something that came along after kind of deciding to study finance? Yeah, so I kind of continued studying like math and a little bit of computer science and like some economics, just like not really knowing what was like.

I didn't I was a very career like minded at this point um but yeah i remember like talking with like a corn trader who like you know would trade in the pits at like the cme uh even in like 2012 or 13 whenever i met this guy like it seemed kind of old-fashioned at the time uh and then yeah and then you know i just like knew yeah then it just like applied to a bunch of different places. Oh, a funny thing is that I took a class at the Booth School. It was called Market Design, I think, or Mechanism Design, and something about this. It was taught by this professor, Eric Budish, who wrote a very famous academic finance paper on finance like you know an academic finance like a paper

on high frequency trading the high frequency trading arms race okay uh you know trying to quantify like how much money is like kind of you know uh being accumulated to these like latency games and stuff uh and he and then this was also when flash boys came out roughly uh so i read i remember reading flash boys i remember taking this class but i think i took the wrong lessons from the class i you know i got a good grade but like i i took the wrong lessons and i decided that like hyper busy trainings actually it seemed really cool you know right um yeah was the was the class kind of trying to uh make a case against it not providing a lot of value to society or was it was it actually encouraging the uh like thinking it was interesting i think uh so the class was like

more broader focus there was like a lot of things in like this like um specific field of like uh mechanism design that were really interesting at the time uh but yeah i mean eric brutish's work i think tries to argue that um it's this like continuous time uh matching of like people uh it was like uh market participants was like inefficient and that like it could be solved if you just like had like batch auctions if you just like had auctions like basically every like 100 milliseconds or so because then like the lancy uh yeah edge that you get is like becomes lower so you don't have to like worry about competing on like nanoseconds right right that makes sense so you you get interested in uh high frequency trading um what was kind of the next steps from there how did you

how did that actually kind of like manifest in in what did next? Yeah, so I applied to like a lot of different companies. And then I eventually started working out like a really small trading shop in Chicago. It was like around like 12, 13 people at the time. So really more of like a startup type of environment than, you know, your citadels, your HRTs of the world right um you know i thought i didn't really know anything so it would be good to like get exposure to like you know or get a lot more um i don't know like attention or something so uh i started off as a quant and i realized pretty quickly that was a terrible quant because uh whenever i did you know one problem is that like uh one really bad feature for a quant or a trader to have is uh not losing is is really not enjoying losing money right so i really hated whenever i saw my strategy like lose like i don't know like a few thousand dollars or something like that i would like agonize over like the fact

um you know like whereas like the entire game is like a statistical one so you have to like take the ups and the downs like right so that wasn't so i didn't cut it very well as a quant but the good thing about working out like a small firm is that they can you know there's usually like a bunch of fires going off at like any given time so uh i did like programming and then you know i had learned like c++ and Python at this point. So then eventually I started doing more C++ stuff and then eventually I got into FPGAs because, you know, that was like the new hotness in hyper-music trading at the time. So that's like, yeah, that's how I got started with chips essentially.

Gotcha. And what year was this or what time period was this in? It's roughly like 2016. Okay. Okay. Yeah. People are still using FPGAs. People have been using FPGAs at that point in time, but like there's still like, you know, a small trading firm in Chicago could find like little latency games that they could win at. Yeah. Gotcha. And so even for like a small, you know, company, like you were working at that point, there's hardware specialization that's going on.

Is this pretty much like across the board if you're going to play in this game? Is having custom hardware or at least, you know, reconfigurable hardware in the case of FPGAs and running all your own servers, is that just kind of like table stakes to even participate? Yeah, I mean, if you want to be a participant on some of these latency games, definitely. I mean, it depends on like what type of like strategies you're trying to run.

But yeah, like custom hardware at this point is like table stakes. And you can go through like the major training companies and look at their job postings. Like they all have like needs for like FPGA or ASIC engineers. Right. And so had you had any exposure to FPGAs at this point or were you just kind of, you know, in this job or internship and, you know, kind of introduced to this magical new concept of reconfigurable hardware? experience with FPGAs before. University of Chicago is very famously a very theoretical place. So there's no like FPGA theory going around. So they don't really have

any of that happening at the time, as far as I know. I remember during Professor Budish's class, he would talk about hybrid Z-trading for a lecture or two. And one of the murmurings was about how, like some trade show, they were like like oh yeah there's like custom hardware that you can use to trade so you don't even have to go through like software at all uh and he was like wow that's crazy you know so um yeah that's all i knew but you know the good thing about working at a small company is that even if you're not like a subject matter expert on this thing you can uh people will give you time to just like, try to figure it out in order to, uh, yeah. Like, yeah. In order to just like, see what you can get done. I mean, there, there are negatives, which is that like, uh, you're not, you're just kind of on your own, like trying to figure things out. Right. Uh, you don't get like the best,

like instruction, but it is good. Cause like you get exposure at least. Yeah. Gotcha. And what were some of the first things that you uh you know configured in fpga to do like what was your kind of hello world uh for fpgas uh i mean one of them was just like a just like a faster feed so like um yeah like uh cmu famously has like this like really like huge like insane uh message format uh with a lot of information on them. But like, you really only need like a certain like parts of it. So in order to just like improve like throughput throughout your like trading system, you can just like, but read it quickly and then just like transfer like the important data to

the different parts, like much more efficiently. So that was one. And then there was just like a lot of like trigger-based trading, which is what, yeah, like just like a lot of like trigger based trading, which is what. Yeah, like we did a lot of that. So that's what actually started making the money. It was like, you know, there was like some event on one symbol and then like we could take we could trigger like a trade in another symbol or sometimes the same symbol. Yeah. Gotcha. And was that all happening in the fpga in the trigger base case or was that uh yeah it was yeah yeah yeah gotcha yeah there's no software interaction uh at all yeah gotcha and how often is the um kind of like reprogramming of these strategies taking place uh at the kind of like edge there with the fpgas yeah i mean uh reprogramming it yeah so

i guess like um you know you don't reprogram the image that often i would say usually what happens is that you have like a certain firmware image and you have like a software process that like is like kind of the buddy of it so that you know the software actually tells like the hardware you know if like this symbol ticks up by by three, then trade on this other symbol at this price or something. So it programs the triggers into the FPGA, and the FPGA will use a very simple logic to run through them in order to see what to trade. Gotcha. Gotcha. That makes sense. And were you writing most of your RTL in Verilog at that point? Or did you all have any alternative languages that you were using? Most of that was just straight Verilog. And I got into the verification side of it just

because I was writing a C++ test bench for PostSynth. So yeah, like, yeah, you know, basically after, like, we have a firmware image, like, we have to, like, test it with, like, some real data, but also some, like, fake data in order to make sure that, like, you know, when things don't go through, like, software at all, you have to be very careful with, like, the risk profile of that, right? So that's why verification is super important in trading. Because you can, you know, you can send orders very quickly, but that could also mean you could lose a lot of money really quickly. Great. Can you kind of talk through what verification looks like in FPGAs? Obviously, this is going to be relevant kind of later on in your path as well. But just kind of like from a first principles perspective, what is verification in FPGA or logic design in general? Yeah, I mean, verification is basically, does the chip do the thing that I expect it to do?

Like given like some higher order model of what the chip is supposed to be doing. So that could be a design document. It could be like a model that somebody writes in a different language, like Python or Scala or something. You know, but basically, you know, in a different language like Python or Scala or something. But basically, chips are highly complex, like parallel systems, right?

Like software engineers love complaining about like, oh, they had to debug this like multi-threaded, like yada, yada. But like every clock cycle, like a million things are happening on a chip. So you can imagine that it becomes like, the complexity of like trying to debug that is like very difficult. And also like whenever you, uh, program in FPGA, there's no, there aren't a lot of great ways to

just like see what's going on inside. You can't just like slap on GDB and like, uh, you know, uh, let it rip. Um, so you have to do a lot of stuff before like pre-synthesis. So, you know, and you know, you could have, so let's say you have like a chip for trading or something, right? There's a part that does like the parsing of the messages, right? That you get from like a certain exchange. It's in some format. You have to extract like the price and the size data from it, let's say, right? Then you have like another part that's like a trigger based part, which like takes the price and size of like a trade, let's say, and then compares it,

like it runs through like some stuff in memory to see like if it should fire, right? That's another part of the logic. And then it could maybe fire like multiple things at like a given time, it might have to queue up some messages, you know uh all that kind of stuff uh all these things are happening that logic is running every clock cycle so you have to be sure that you tackle like every edge case you have to make sure that there aren't any like crazy race conditions um because like you could you know

let's say you have like two ethernet ports right that are both receiving trade information you don't want like the you know and the message will messages can be replicated on like both ports right you want to fire on like the first one but you want to make sure that like if the second one comes in maybe even happens on the same clock cycle you're not like double firing or you know there are all sorts of like weird like edge cases that can come about. So that's kind of a simplified view of what FPGA verification is about. And you can get as, yeah, your test benches, which are these ways of just testing

different sub-components of the system. They could be really small. It could just be, there's a messaging protocol between two blocks on your chip, or it can be very complex. It's like an integration of multiple blocks working together to make sure that there's nothing that goes awry there. Yeah. And it takes an enormous amount of time and effort. And that's why there are FPGA verification engineers and ASIC verification engineers who spend their entire time grinding out tests, going through test cases, doing constrained randomization.

You're running through random seeds constantly because maybe if you get a size that's problematic or all sorts of things can happen or like all ones or all zeros or like some like weird pattern that happens, like maybe like the chip will behave in like a way that you don't expect. So you have to look through, you have to run a bunch of random seeds. You have to go through, see the test failures, see why they failed. And yeah, I mean, it's a, it's very, it's very onerous. Right. Yeah. Right. And there's kind of like a few different vectors of optimization, right, when you're working with FPGAs and that like there's, you know, correctness, of course, which is kind of what you're speaking to there. But then there's also, you know, your utilization of logic elements on the board, which is, you know, fundamentally physically constrained.

There's also cycle times, which, you know, you're going to, if you're doing more in that clock cycle, right, you're eventually going to start bumping that clock cycle out. Now, what's kind of the process for balancing those various constraints that you have? And did you run into that much in trading or were you all mostly using like pretty beefy FPGAs that could handle whatever logic you were throwing at it uh i mean we use pretty beefy fpgas but like uh yeah i mean mostly we're just trying to i mean most important is correctness right uh you know you want to make sure that like whatever you get out is correct you know there's huge risk involved and you want to make sure that things are like down pat um but you know latency is obviously super important so you have to tighten up like certain paths or you know like

make sure that if you're going to add pipelining it's like on a non-critical path um you know stuff like that and yeah um i don't know it does get pretty complicated but uh ultimately what's important is that like it actually works and um you know it fits like a certain latency profile and you can do all sorts of like little tricks in order to like try to fit things in um yeah like a in a certain clock cycle but uh yeah yeah but that that's kind of why at a certain point you need asics right like if if your latency if latency is important enough you start like getting into like actually taping out a chip um because you know FPGAs no matter like

how many tricks you can do right they'll never be as like fast as an ASIC right because you have to go through all this programmable you know all these lots and stuff so right right and so uh did you ever were you ever exposed to ASICs in the in the trading space or was that mostly just like y'all didn't get to that point? You weren't actually ever taping out chips. So when I was at Hudson River, well, you know, I'll say that I like Hudson River Trading and a number of other companies. They have like ASIC verification engineers and ASIC, um, like, uh, engineered like job postings. So taping out a chip in hyper-easy trading is like pretty common, I would say at this

point. Gotcha. Gotcha. Makes a lot of sense. So you were kind of at this, uh, this smaller trading shop, right? And then you eventually, uh, ended up after university going to, uh, Hudson river. Is that right? And then you eventually ended up after university going to Hudson River. Is that right? Yeah. What was that kind of decision like? Did you just want to have a larger experience or how'd you end up there? Yeah. I mean, things kind of were

working out that well. I like the company that I was with in Chicago. That was part of it. And the second part was just that I, you know, I've gone to school in Chicago. I lived there for a few years afterwards. I kind of wanted to try something different. So I was looking at a number of different jobs at the time. And, you know, HRT, like Hudson River Trading, has like a really good reputation. They had, I interviewed there, I really liked the people that I interviewed with and talking to, and they had a really nice office at the time. Well, they still have a really nice office. They had a really nice office.

And, yeah, I don't know. It kind of just, like, worked. It was an interesting work. They did a lot of stuff with, like, open source, you know, like tools for, like, chips, and I thought that was really cool. So it felt like a pretty natural pairing. Gotcha. I feel like the FPGA space is one that is, you know,

pretty much reliant on proprietary tooling. As you mentioned, there are some open source tools. And I think, you know, more and more, there is more open source tool chains. But fundamentally, a lot of times when you get down to the bitstream you have to rely on on proprietary tools what type of tools were you using in this environment and did you find them kind of like adequate or or better than adequate at the task you are trying to do yeah so at HRT they you know we used

a lot of Verilator and CocoaTB. So Verilator is like an open source simulator. Some people would disagree that it's actually a true simulator or whatnot, but that's neither here nor there. And then CocoaTB is like a Python library that's like simulator agnostic, where you can write test benches in Python. And yeah, they use a lot of both of those. And then there's actually a really good blog post written by my old boss, Todd Strader, on how we use those tools or how we verified hardware at HRT. And yeah, they were pretty good. I mean, for FPGA workloads especially, I thought they worked pretty well. But the only problem is that when you get to, like, larger designs, sometimes, like, the performance would drop off pretty drastically.

One part of it is just, like, the way that we wrote our test benches. Another way is just, like, when you're introducing Python into something, it's automatically going to slow down. And Verilator had some issues with scaling. Yeah, like it didn't really work, play very nicely with the larger designs. And it's very fast for like smaller designs. And you don't have to worry about licenses. And you can run a bunch of tests in parallel, which is like what made it very attractive. And you'd also like spec the code because it's open source, right? So you can inspect the code,

you can see, like, you can fix bugs, you can upstream them, that kind of thing. But towards the end of my time there, I worked pretty much entirely on like Verilator and CocoaDB issues, trying to make sure that we could run as many tests as fast as possible. Gotcha. And what's kind of the thing that would you mentioned that some folks would not consider Verilator a real simulator or a full simulator? What would be the distinguishing factor between it and maybe some of the proprietary options that are alternatives? So most simulators are event-based simulators. And so it does these... Some would argue that's kind of a hack in order to just get... Yeah, so certain things with delays don't work in Verilator. I think they're starting to change that. Certain language constructs aren't supported as well.

There's an issue also with encrypted IPs. So if you buy verification IPs from people, or if you buy IPs from a third-party vendor, they're not just going to give you the raw source code and stuff, so you have to have a way of simulating the design with the IP. And for that, Verilator just has no answer for it. So that's one big pain point that a lot of people have.

It's also not a four-state simulator. It's just a two-state simulator, just zeros and ones. You can catch a lot of bugs with Xs and Zs and whatnot. So yeah, I think there's some other stuff there that people don't like

about Verilator as well. It doesn't have mixed language support as far as I know. I think there's some other stuff there that people don't like about Verilator as well. It doesn't have mixed language support, as far as I know. I think it just only supports system Verilog and Verilog. No VHDL. Yeah, so I thought if you have a Verilog-only codebase, it's pretty great. And you have small enough designs, and you can work around some of those other issues. But yeah, for the most part, if you work at like a large chip company, people aren't doing everything in Verilator.

And even at HRT, we use proprietary simulators when we ran into some of those issues. Yeah. And so would you usually use Verilator as kind of like the, it's just pre-synthesis verification, right? And so would you, you do the variator verification and that would be kind of the uh improved development workflow and and that sort

of thing uh and be able to get quick iterations on that and then you go through synthesis and do post synthesis verification as well and was that with proprietary tools uh you know we have like our kind of own like lab testing environment that would do uh post-synthesis stuff um for the very later yeah like the the attractive feature of it was that you could run like a bunch of tests in parallel because you don't have to worry about uh like licenses right so we could spin out like you know each developer could spin out like tens or hundreds of thousands of tests like with the press of a button that was pretty nice um you know just like distribute it out to like hrt's like uh like a compute cluster and then get results back really quickly uh that was a really nice feature that you couldn't really

get if you just only did proprietary um simulator stuff but yeah like before we would ship an image we would have to run some stuff through a proprietary simulator, depending on what project people were working on. Sometimes you could just get by with the Verilator CocoaDB stuff because there's enough confidence in some of the other components or just enough confidence in the components of the testing that was already done. One of the things that you mentioned was the, uh, encrypted IP blocks. Uh, and, and, you know, for folks that are not familiar with, uh, FPGAs or ASICs or things like that, uh, it can be kind of surprising the way that I think IP works in these various scenarios. Like if you come from a software background, uh, you might be familiar with integrating, you know, open source libraries, source libraries or, in some cases, less commonly now, proprietary libraries.

But proprietary IP is extremely common in logic design. What kind of percentage of designs that you've worked on have been made up of proprietary or pre-built IP-built ip designs that y'all weren't actually developing yourself yeah i think yeah so i mean in the industry like uh selling ips is like a huge like profit driver for like a lot of different companies a lot of companies their entire business knowledge is like selling ips right um so uh yeah like that's just the standard in hardware. For HRT specifically, yeah, I mean, I can't really comment on the exact proportion of off-the-shelf IPs versus in-house, but wherever we saw an advantage to just build stuff in-house, we would try to do it, especially on latency things.

Things that are especially latency sensitive. And I think that's true for across the industry. You know, honestly, a lot of like the IPs that you can buy off the shelf, like the, you know, we, you know, we thought that we could do better on. So then we just like invested the manpower to do so. Yeah. Was there any consideration for like the debug ability of your designs? If y'all wrote things in-house versus took IP off the shelf, especially if it was an encrypted IP block? Or did y'all ever have cases where you suspected that there was, you know, an error in the IP block or you just couldn't figure out what was going on with it yeah i mean uh in like the times where reviews like yeah like uh off the

shelf ips like there were often times where like there would be like some strange error that would pop up and you just like had very little visibility to what was going on so that was like endlessly frustrating because you have to like contact the vendor, you have to like, like write some tickets, like stuff like that. So that's like another reason not to do it. Right. Yeah. Whereas like if it's all in house, you can just like look at it. Sure. It, did you kind of, were you in a role where you were actually deciding, you know, what vendor provided IP would be used? And if so, you know, it's a,

it's a pretty different process than just going on GitHub and finding a library that implements what you need. What's kind of the process for deciding, Oh, you know, we need this functionality. Uh, let's go look at a vendor for this IP and then actually acquiring it. Yeah. Honestly, that was like kind of above my pay grade. Um, I didn't really, yeah. Like, yeah,. I know that people were constantly in touch with various IP vendors and providers, but yeah, I didn't really have to do a lot of that myself, fortunately. Gotcha. Gotcha. So you were at Hudson River for about four years, is that right? Yeah, like four and a half years, I think. Gotcha. And after you'd been there for a while you decide that uh it's it's time to go do something else uh what was

kind of the process uh of deciding that and uh you know what did it look like kind of leaving hudson river and uh before we actually get into uh what you decided to go do when you were leaving uh did you already have an idea for for where you were headed i had a few ideas for where i was headed so uh i mean the process of leaving you know you know i put in my put in my notice um you know i was very sad to leave because like you know i have a lot i still have a lot of friends uh at hrt and you know it was a great place to work um i thought you know i wanted to explore new opportunities i I wanted to try some different types of work. I had a non-compete so I knew I had to wait that out a year. I was initially going to try joining another trading firm.

But I kind of took my sweet time to just study, like read a bunch, just like try to figure out like stuff that you know just like different industry trends like I thought that was like really interesting. I also took like a month or two to just like kind of like you know lay on my back for a bit you know because I was working pretty hard but you know yeah I was trying a lot of different things. And then eventually I decided to like, you know, the number of times we can actually do a startup are like pretty limited, I think. So I think it was something that I always had in the back of my mind that I wanted to try at some point. So that's I decided to just like go for it. Gotcha. Gotcha. So, uh, you know, maybe a lot of folks are not as familiar with the, uh, the non-compete status, but that's fairly common, uh, in finance. I think, I think that, uh, it may

be less common now. Cause I believe that non-competes were just recently, uh, uh, banned essentially, but some people are like trying to sue over that. Um, I don't, I, I don't know what it's like at HRT or Citadel or anything now, but yeah, they were super common. And yeah, I think they'll try to enforce them as much as they can. Right, right. And I guess kind of the logic there is you've had all these experiences, and also in trading, the specific strategies you're using

are obviously when it's essentially a race, really valuable, especially in like the short term. So, you know, you kind of understand why they would have that. Did that end up being, you know, you mentioned you did a number of different things during that period. Did having that non-compete actually kind of perhaps enable you to go and try out a couple different things since you had to wait that period out anyway? Yeah, I mean, you know, I think it did, honestly. I know that a lot of people think that non-competes, I mean, this is, I think, just one case in which, like, a non-compete was actually, like, good for me to try to, like, figure something out. Otherwise, like, I would have probably just, like, really tried to just, like figure something out. Otherwise, like I would have probably just like

really tried to just like jump into another job as like quickly as possible. Right. Yeah, yeah. I mean, the AI stuff was like a huge thing and like I actually worked on like an AI inference chip, you know, for like training applications. And yeah, it was really cool stuff

and like that was like pretty hot um yeah i mean i i always want to learn rust so i like did some like rust stuff but yeah i think it was good for me to just like spend a few months just like really thinking about like what i really wanted to do next um because like the natural thing like once you get into finance and like you know you're getting free dinners at nobu and stuff is just like keep like you know going to nobu but like uh yeah i don't know like give me some time to reflect right which is very useful yeah gotcha and uh so you eventually decide that you want to go and start a company did the decision to kind of go and start a company precede the idea or did you um obviously you'd spent a lot of time in this space

of working with the developer tooling around logic design uh was that something where you know you were you were just kind of um from the beginning passionate about improving that experience for other folks yeah i think i think they kind of went hand in hand i think the desire to start my own company was always like latent uh you know i would would always joke about like, you know, dumb startup ideas. Things that are too dumb to put out into public. But, you know, like, yeah. But, you know, one thing that like YC tells you is that you should like try to figure out like where your areas of expertise are and like start there. And I just remember that like the process of developing your own chip or just like

iterating on designs just like so painful and so annoying and you have like this entire we had our own like weird infrastructure that was like built up in order to try to like get around some of it and yeah then I just like started talking to other people I knew who were working in chips and they all basically said the same thing um yeah like every company has their own like weird cicd testing framework uh and you know no one really loves it uh but you know it's just good enough it gets the job done um so yeah that's kind of how i like came into the you know like those two things came together like you know natural entrepreneurial esprit let's say and uh uh yeah like this like um i don't know like domain knowledge and something i really wanted fixed like i'm working on like an

fpga project right now um you know to kind of dog food our product a little bit but also just like partly for fun um yeah and you know i'm like tearing my hair out uh like just like getting stuff running. It's pretty awful. And I want more people to just be able to pick up an FPGA and then just get started, just trying stuff out. It would be really cool. Absolutely. I can certainly identify with that. And I'm very grateful for FPGAs because I don't have any sort of formal education in hardware.

But my introduction to FPGAs is what kind of like opened the door to getting experience in it because there isn't really a parallel to being able to do hardware development and test out different designs, you know, from, in my case, my home office, right? And so, but I do see a lot of folks that maybe it's the huge, you know, Vivado or Quartus install that holds them back, or maybe it's going through and learning different terminology, or just like the sheer time that you have to wait for synthesis, especially in larger designs. Those things can all be, you know, massive barriers. So I like kind of the idea of both improving for industry, right? The folks that are already doing this, they already have pain points, but also as part of that kind of opening up the door to other folks.

And it sounds like, you know, you've done a number of kind of like solo projects or side projects where you've been doing your own designs. I'm curious if you think that like an individual is capable of doing like a meaningful chip design, or if you think the complexity has risen to a level where that's like not really a feasible mode of operation. I mean, I think as it stands right now now to be able to do like a really complex design is like pretty infeasible for an individual um even playing around with things it's like kind of annoying to do like uh people learn all sorts

of insane programming languages for like no observable like use right you can look at like project or their leaderboards or something right right? Right. But even the most arcane languages that you see on Project Euler have an easier setup time than an FPGA, which is used by hundreds of thousands of people, right? And which is sort of crazy to me. And my goal is that everybody should be able to like start making their custom hardware like on an fpga maybe to get started and eventually maybe like you know if they find something interesting enough to be able to tape it out uh and yeah i would love to write like some blog posts like have like educational material on how to get started because you know uh up until

recently there hasn't been like a lot of like good like literature on how to get started with like designing custom hardware even if it's like an fpga like maybe you want to prototype like a gpu on a fpga you know uh just for fun like it'll never be as performing as an a100 or like whatever but like it could just be a fun thing to get a better appreciation for what's going on right uh that's just like so annoying and painful to get started right now that people are just going to fall, you know, like people are going to see that it takes like, you know, like nine hours to install like Vavado

and like, you know, like, or like whatever, like, and they're just going to give up. For sure. So I want to circle back around to maybe how you've taken some steps to address some of the different parts of the development workflow and maybe some that you'll want in the future. But let's kind of rewind. You mentioned YC. You did go the Y Combinator route with starting your company. I'm curious. I've talked to a number

of different folks who have gone through Y Combinator. And there's some folks who come in and they basically have an idea and have done no work. There's some folks who come in and they basically have an idea and have done no work. There's some folks who have literally been building a business for a number of years and they're trying to scale it, essentially. What kind of category or did you fall somewhere in between those two extremes? I guess I would say I'm a little bit between the two extremes. We had a general idea of trying to make hardware development easier. We're trying to, like, that's a pretty wide front on which to tackle. So we're trying a number of different things, we're noodling on them for a bit. And then when we came to

Y Combinator, we kind of had settled on the idea of a web-based platform for chip developers to do design verification. Because design verification ultimately is where most people spend their time. It's just running the tests, checking results, debugging. That actually takes up most developer time. That's how you iterate. That's how you get those iteration cycles down, Pat. You do place and route a few times or something, mostly to check that things haven't gone horribly awry or something. But your day-to-day developer experience, which is, I'm very humanistic in this regard. I want those developers to have a really great experience. And there's no great... Yeah, I mean, there hasn't been a great off-the-shelf platform for that,

which is what we're trying to develop now. Absolutely. And as part of the process of starting this company, obviously you already mentioned you found a co-founder. What was the process like identifying a co-founder? And who is your co-founder? Okay, so my co-founder and who is your co-founder? Okay. So my co-founder is Paul. So he was most recently a backend engineer at Cloudflare and he actually did a lot of cool testing for Cloudflare. He architected this test framework

that helped them migrate a really important auth service. He was on the auth team and the service was securing millions of users. you know also super important and you know he's somebody that I knew like we were roommates in college like so I've known him for a very long time and you know all yeah like we just like talk to each other all the time like you know we've been to like like France and Japan China and Lebanon with each other we go on like vacations with each other so like naturally when we were talking about when I was like thinking of like doing startup stuff like um you know I was like talking with him about it and eventually you know it became kind of obvious to me like originally I was going to try to do do it like do it solo against

everybody's advice but then I was like no that's just crazy and uh you know i have you know like paul's great and he started getting interested in hardware as well because like it's like a really cool technology but uh you know it's funny because i take for granted how bad some things are but you know if you show like somebody who only has done like software uh what it's like to try to program an fGA. It's nice seeing it through fresh eyes. So you can be like, oh yeah, that is pretty horrible. Why is this license a gigabyte long? I don't know, stuff like that. Right, right.

And you're a fairly technical person and certainly have an engineering background. You're kind of stepping into a CEO role in the company. What was the decision like, you know, CEO versus CTO, which I believe Paul is the CTO. And do you really feel like at this point that there's a big distinction or is that more, is being CEO and being perhaps more like organizationally focused as y'all scale the company? Is that something that's kind of like a goal of yours? i mean right now like uh

paul just like handles like all almost all the coding and then i try to handle almost everything else like so everything related to like you know just like um things as mundane as like like figuring out workers comp and like getting us like health insurance uh to doing uh to more important things like sales like talking to customers like that kind of stuff you know I'm doing some work to like dog food the product a little bit right now so you know doing a little bit of coding here and there but yeah I think that like division it's like a pretty pretty good yeah and like right now it's like kind of like a dev tool IIy kind of like framework is like

how we're thinking of it. So it makes sense for Paul to take the reins of that a little bit more so than me. Like, you know, obviously like I have like a say, cause you know, like I have like a domain knowledge in this. Um, so like, uh, we, we talk a lot. Um, but yeah, yeah, no, absolutely. I think that makes a lot of sense. Obviously, both roles are super important. I'm curious, once you all decided to start this company, what was the process like for

applying to Y Combinator? And then once you got in, what was the following process like after that as well? Yeah, I mean, the Y Combinator application is very simple. Like you have to record like a one minute long video explaining like what your company does and your background. That's probably like the most difficult thing. I went through a lot of takes, but even that is like pretty straightforward. And then there's an interview. So I actually applied initially just solo, which there's no chance I was going to get in solo, I think.

And then when me and Paul were getting more serious about doing the startup, I was like, hey, you should add yourself to the Y Combinator application because it's good for you to think about some of these questions, see how I answered them. And so like, you know, yada yada. Like, you know, I thought it was like a good idea, like a little exercise. We didn't really expect to get an interview.

And then you get an interview. It's scheduled like very quickly. And then you get an answer like the next day. And the interview is like pretty, it's pretty basic. You just have to be able to explain what your company does, why you're doing it, like who you're making the product for, just like very simple things. And I think they really value clarity of thought.

And if you can kind of get those right, you know, like I'm not, you know, like you have a pretty good shot of like getting in. And then after we got our acceptance, like the next day I got a phone call from like Brad Flora, who's our YC group partner. We just hired pretty quickly to just take it. And I moved to San Francisco from January, like mid January to mid April. And, uh, yeah. And, uh, it was a really great experience.

Uh, I liked it a lot. Absolutely. And, and y'all are kind of, uh, recently out of the program. Uh, and at the end, you know, you, uh, you had your launch and everything like that. Um, uh, I saw y'all's post on hacker news, uh, and you know and there's a lot of great comments there and feedback. What was the process like of launching, and what was sort of the milestones that y'all wanted to get in place

before you went public with it? Yeah, I mean, yeah. One thing that YC really tells you to do is to launch as soon as possible. And part of the advice is that you should launch a product, even like if you aren't embarrassed by the product you launch then you waited too long like that's like classic advice so we just like set like a pretty high goal for ourselves to launch like in march uh you know worked on it for like basically like two months just like really crap like uh it was like a really big lift and um yeah i mean it was cool to like just

have that like date set you know you have to schedule it a little bit in advance um and uh we had to delay it once because uh you know i i had to like i don't know our website didn't look very good and i was feeling pretty embarrassed about that so like i had to get into framer and like start like moving widgets around. But yeah, like it was really cool to see. And then like that entire day, like when we launched, me, Paul and our founding engineer, James,

we just like sat in a room and then we just like, just cranked out like comments, like answering people's questions. And yeah, it was really cool. And we celebrated with like Brazilian barbecue. It was like a really fun time. Like, you know know i have very fond memories of that day absolutely well let's let's actually talk about what y'all are doing and uh what the name of your company is uh is syllogy the

uh correct pronunciation yeah it's syllogy it has the capital l in there which is very like 1990s core but like um i think i'm gonna have to downgrade that to, you know, uh, an L in minuscule, but, uh, yeah, I mean, I kept trying to figure out like a name, uh, for a very long time and, uh, yeah, you know, naming a startup is never easy, but like, uh, two like Two things like I just want to combine together We're just like the idea of that like we're doing things with like silicon and that there's a lot of logic that we're trying to Verify right so that's basically it. It's not very it's not very creative or sexy or anything But it is and I was it was important to be able to get like a dot IO at the very least right because You know most of those are taken up

You know, I thought about like, you know most of those are taken up um you know i thought about like you know i opened up like an ancient greek dictionary uh to try to figure out like good words that i could use there like i tried all sorts of like wacky things um but yeah that's just kind of the name we settled on and you know i think it flows off the tongue uh syllogy so um yeah i don't know yeah as as an engineer i'm'm a big fan of naming things what they are. So, you know, it passes my test for sure. But, you know, we've talked a little bit about some of the different parts of logic design. And y'all are really, at least initially, and, you know, maybe I can extrapolate a little bit to y'all wanting to own perhaps more of the development workflow.

But you're really focusing in on verification. And one of the things I noticed when doing some research on, you know, the problem space that y'all are trying to solve, in addition to, you know, my own experience with it, was on your Y Combinator page, there's the video from John from Asianometry, which I'm sure most listeners already watch this channel because it is absolutely wonderful. But John goes through and describes kind of like this verification gap. And I thought it was really interesting, the framing. And I'm curious kind of like how you all play into this. It was I think in 1997, there was this concern about that chip manufacturing, right, was progressing at such a rate and the development tools were not keeping up with it. And so like the productivity was lagging. So essentially, we'd be able to manufacture devices or silicon, right, that was more capable than we could actually produce with the tooling

that we had. And he goes into a number of different reasons for why that wasn't the case. But then, you know, verification comes in and becomes sort of the bottleneck in this process. And I'm curious if, you know, why, I guess, verification is the bottleneck there. And if that is the reason that y'all are kind of tackling that as perhaps the first part of improving the development workflow here. Yeah, I mean, I think so. I think verification has just been overlooked for like a number of reasons. I mean, a big part of it is that it wasn't... A lot of design verification work got outsourced to India and other lower-cost countries.

There's not... And it's also just not very sexy of a field. You can think of it as QA, right? Which is not to say that the work there very sexy of a field. It's sort of like, you can think of it as like QA, right? Like, you know, like, which is not to say that like the work there isn't like super important or like super interesting. It's just that for whatever reason, it was like not seen as like an important like field.

And if you were, you know, graduating with like an electrical engineering degree, then if you worked as like an architect, right, you would get paid like 50% more than if you got paid as a verification engineer so people in the United States like you know no one graduated like top of their class uh in electrical engineering and went to work as like verification engineers um and I think that for like cultural reasons it was kind of like not seen as like that important um yeah you know and I do think that like it is a huge bottleneck um because

people have just like not kept their eye on the ball um you know whenever it comes to i think custom silicon uh like the amount of custom silicon entering the market right now and uh it's like just like exploding and like people are really trying to like do creative new things with custom silicon and um yeah i mean part you know and what's like really grinding people down now is like just like this like verification gap like the productivity just like hasn't kept up and um i don't know the entire industry in general hasn't innovated that much recently because like i just think that you know also like there's like there's like a big gap of people there's kind of like a lost generation of people

who um stopped doing electrical engineering and you know i don't know like 2008 to like you know a few years ago maybe um because that's like software engineering uh you know like software engineering salaries like exploded right but hard you know like software engineering salaries like exploded right but hard you know like hardware engineering hasn't kept hasn't kept up um i think people at nvidia now are like uh pretty happy though but uh but yeah so you know there's all sorts of like weird like uh i don't know like economic macroeconomic reasons that like, it just hasn't kept up. And I think more and more people are starting to see that it's like a huge problem, right? I believe like Intel keeps like delaying certain like new chip architectures or whatever, because

basically because of verification, they keep like finding like little bugs that like get introduced and they can't, they have to like, you know, they have to just like, I don't know, bring a slightly newer version of like an old architecture. But yeah, and you know, I hear that like NVIDIA's like DV workflow is like very good. So that's like one reason why they've like done so well. So I think more and more people are going to start seeing as like a competitive advantage to have like a really great verification workflow um yeah i mean like startups like have like tons of verification engineers and you know it's like a huge overhead for them um and you know people want to be making new chips like it'd be you know it'd be really cool if like you know uh you know if you just have an idea for a chip, you could like spin it out like a few quarters or something.

Right, right. So in terms of, you know, like what is literally the bottleneck, I know y'all are focusing on, it seems like to me at least, kind of like collaboration features and then perhaps just like compute as well, right? Because y'all are hosting the compute in which the verification runs. Are those kind of the major aspects of what, what is causing the bottleneck right now? Are there other aspects of verification that y'all are tackling or want to tackle in the near future? Yeah. I mean, like in the immediate term, like we're focusing on like collaboration and like uh compute because like uh like a lot of times like in chip design like tests will like take like days to run like sometimes like you know

they're a week plus long tests and you know uh just getting those numbers down would be like pretty helpful i think but also collaboration is like still pretty primitive uh there's a lot of you know a lot of times like the state of the art involves like, like copying over a waveform to your coworker or taking screenshots or like sending a Microsoft Word document in an email. You know, it'd be better if like, you can just like tag people directly where like the issues are and be able to like debug like within, like be able to send links instead. So that's kind of like one of the big things that we're working to enable um and yeah in the future like i mean this is something that we're also actively working on this is just like helping people write test benches quicker uh you know

you should be able to go from like a spec of the chip to uh like just even like a list of like edge cases like really quickly um or like things to test for, things to make sure that you cover, whenever two things are integrated, it'd be cool to like just be able to like inspect like those two blocks and like see like potential interactions that could go awry. And you know, that'd be especially useful

because like a lot of times like these integration tests, like, you know, there's like two teams that work on like two different like blocks, right? And you need to integrate them. And each has their own domain knowledge of the block, but it's hard to transfer that information around. So that's also a collaboration thing as well. So yeah, I think there's a lot of low-hanging fruit, but also there's a lot of potential innovation that you could just have in terms of like improving people's like productivity. Yeah. How flexible are y'all in terms of tooling? I know you mentioned Verilator on your website. Is it mostly like a, you know, folks upload their RTL source and, you know, you run the Verilator on it and execute the test benches? Or is there, you know,

the ability for folks to bring their own tooling as well? Yeah, we support a lot of different tooling in addition to Verilator. Yeah, like we started off just with Verilator because that was what I was most familiar with. But, you know, like customers have just been like, oh, yeah, we need to like use like some proprietary simulators as well. So we do have like some support for a number of those. Yeah. And the way that it works is basically you connect, it's like a GitHub app that you just connect your project to it. And then we have a web UI so that you can, that'll just, and our service will just run the test periodically. It'll be able to inspect a YAML file that where you'll be able to like

tell it how to like build the test binary and then run it. And then we just like collect all the information and like put it in like a really nice like format for you. Yeah. Absolutely. So do you see it kind of being like fitting into additional, perhaps like GitHub actions flows that folks would run and what, what are kind of some things that y'all could do that that someone could not do um in like maybe github actions or other ci tooling

you know that's just like essentially raw compute i mean what we're building is really like a chip developer focused workflow so like basically we're trying to like make sure that chip developers can run as many tests as fast as possible and like just like you know like it'll run them continuously over a lot of like different seeds and stuff not just like on like a git push but also just like periodically and uh like reporting features and um like a chip developer focus like workflow like things like waveforms uh rerunning failing tests um yeah um you know a lot of these things that like people normally to, either doesn't exist at their firms or their companies, or they would have to roll out themselves with a DevOps team that has to connect a bunch of tooling together.

Yeah, we're trying to make it a very simple chip developer focus workflow. And ideally it'll be something, they just, the first thing they do when they get to work, maybe after emails, open up our tool and see what issues flowed in, see test results, see what failed and see people's comments and help with debugging. Right. You mentioned that some larger companies may have kind of like already rolled their own systems for this. Do you feel like, I guess, a two-part question, do you feel like that, you know,

y'all are starting out targeting more like midsize or smaller companies, maybe other startups? And do you feel like some of the more accessibility of fabbing chips, you know, it's becoming more and more accessible to folks? Do you feel like you're kind of, you know, picks and shovels, as they say, for that kind of movement as well? Yeah, definitely. I think that a lot of, I mean, we've gotten a lot of traction from startups, especially because, you know, this is tooling that they would have to build out themselves at some point anyways, right?

So then they could just get onboarded with us and, like, we can help them out, like, you know, day zero. So, yeah, like, and I think that there's a lot more opportunity for people to be building their own chips. And there's, in fact, a lot of open source stuff coming out. There's Tiny Tape Out stuff. There's also open source PDKs, which would be cool to integrate with our product at some point. So I think I just went to a... Me and our founding engineer, we went to the Fossey Latch Up, the open source silicon conference. Free open source silicon. Which is really

cool to see like the kind of projects like people are starting to work on so i think more and more people are getting interested in like open source uh silicon but also like custom silicon and uh yeah like i would like to be part of that story that like more people are getting into like making their own chips like i think that'd be super cool absolutely well if you know folks are are able to reduce some of the overhead of verification in their design process by you know using a tool like like y'all's um there's also you know subsequent parts of that synthesis placing route right we've mentioned a couple of these um are y'all interested like it seems like right now the verification flow would be, you know, improved

quite a bit, especially if you're collaborating with other folks by, you know, using Zillogy or something like it. Um, but ultimately then you still have to have the proprietary tooling or, or perhaps maybe some of the open source tooling if applicable. Um, and you know, that there's still a fair amount of overhead in there. Are you all interested in kind of like chipping away at that part of the stack? And are there unique challenges with tackling that as opposed to verification? Yeah, I mean, it would be really cool to be able to like, you know, be kind of like this thing that like glues together all of these like different tools and different parts of

like the, you know the process of developing chips. I think my pie in the sky vision is that once you, in our app, you should be able to have a flow that once everything's done, you can click Add to Cart and send your design to TSMC. I think that'd be great. In terms of developing our own tools like uh you know you know there there would be like challenges for that um you know there's a lot of really great tooling out there that exists and a lot of great open source stuff um so yeah uh yeah i don't want to like uh

you know um like make any really strong predictions like this early but you know i'm like a yeah i'm very happy about like uh like the you know potential avenues for future growth sure right uh you know another thing that i've kind of observed with folks who get into the fpga design flow or asic design flow is this desire to maybe like create alternative tools as well. So like there's one, there's one you know, mode of operation where you could go about automating the operation or, you know, let's say like hosting tools and that sort of thing. Then you could also go down a path of, you know, potentially pursuing developing your own kind of like synthesis and that sort of thing. We already touched on why that can be challenging when you're targeting you know proprietary bit streams and that sort of

thing uh but are you all interested in you know potentially working in the uh you know like more modern hdl space or some of the the synthesis process uh for chips yeah definitely i mean like uh i think we're you know we'll we'll try to like skate to wherever the puck's going but like uh there's a lot of like different avenues that people are like interested in like uh uh yeah like a lot of cool like um like higher level synthesis stuff like it's like super cool to me and uh it would be great to like be able to like have a way of supporting those like very native like very easily and um yeah and uh yeah i mean i'm very excited about like the the um where like things are going uh in the space so yeah i don't know uh is another thing that kind of uh feels like an obvious path or something that you know i personally would like to see in in my own

kind of development uh we talked about some of the IP blocks and that sort of thing. You know, and obviously there are some barriers, just like some of the barriers you all ran into at Hudson River or at any of your stops where you had, you know, encrypted IP blocks and trying to use those with open source tooling. There's similar sorts of barriers that you could run into with trying to use a product like Sylogy. But one of the things that comes to mind is like, if folks are developing in Sylogy and, you know, verifying IP blocks and that sort of thing, there's also sort of like a unique marketplace, perhaps perspective there where IP blocks could become more accessible. You could get,

you know, more verifiable properties about them and that sort of thing. Is that something that you could see going after or something you're interested in? Yeah, definitely. I mean, I think it would be really cool if there were a really easy way for people to develop their own IPs

and then maybe just upload them, either open or closed source, to our platform. And then you can be able to buy or download them, license them. Yeah, I think that would be super cool. I mean, one of my ideas, it's somewhat of a joke for the future, is that maybe we run a promotion for Zillogy, which is that if you sign up for two years or something,

then we'll throw in a free PCIe core for you. Right. Yeah, something like that. And it depends on what people are looking for. Hopefully there's a lot more open source, like, silicon interests and people will start open sourcing their IPs. And then maybe we can have a leaderboard for, I don't know, like, fastest PCIe core with the least amount of logic utilization, like yada, yada. Like, I think that'd be super cool. Um, you know,

we have to see whether or not, uh, there's space for that in the market, but, um, yeah, I, I would love that personally. Cause I, I hate having to like, I was like, Oh man, I gotta have to write my own like driver for this or something. And, um, you know, or like, yeah, like it really does bog bog people down like when they can't do like very simple things like quickly uh and i think that is like a huge barrier to entry for a lot of people learning about uh custom hardware absolutely absolutely well cool well thanks for uh kind of walking through some of your product there if folks are interested in in trying out syllogy

how can you go about doing that today oh yeah uh yeah. What they can do is like so they could go to our website, Sylogy.io. If you there's like a log in button on the top right. And you can create a free account just to like try it out. You can even create like an anonymized account if you really want to. But if you're interested in like maybe a more full fledged tour, that's like a very basic version that you can like run some tests on like a very simple verilator hello world but if you want to look at like some of the more like enterprisey like versions of it just click book a demo it will just be like me and paul like we'll walk you through some stuff or yeah just like shoot me an email i this is dangerous

but like you can just email me at like k like k-a at syllogy.io. So, um, yeah, I, I'm a compulsive email checker. So like, uh, yeah, like, uh, if people are like genuinely interested and want to talk about it, like, you know, uh, I'll, I'll find time. Awesome. Awesome. Well, I'm sure folks would definitely appreciate that. Um, you know, one of the things I kind of wanted to wrap up with our chat today is obviously there's a lot of changes happening in the semiconductor industry right now, both on like the manufacturing side, but also in the workloads. And, you know, you mentioned working yourself on kind of like an AI inference chip in some of your free time.

I've talked to a few folks both on the podcast and off of it about how these different training and inference workloads are changing the microarchitecture of some of these chips that are being produced. And, you know, that can always lead to different types of innovation, as well as potentially empower some more like upstart companies to make some progress against the behemoths of the industry. I'm curious, just, you know, as someone who's in the space, right, has experience in it is, you know, potentially going to partner with or sell the customers in that space as well. What kind of your interpretation of the industry is today? And if you see any kind of like major trends that you find interesting. Yeah, I mean, I think that in terms of like major trends or like things that I find interesting. Yeah, I mean, more custom silicon just like being pushed to the edge, like just like niche forms of compute, like, you know, like in like satellites or with like cryptocurrency mining

or just like on your phone, like low power things there, robotics. I mean, there's like so much like interesting work being done with open or with custom silicon right now and custom hardware like that. I think it's like super cool. I think a really important thing that people should be aware of though, is that like this, like the software operability like software hardware like compatibility is like super important and that's kind of like one of the big reasons why NVIDIA has like the you know stranglehold that it does right is that like like CUDA is actually like you know hugely important and yeah I think that and one thing that we are trying to enable is a better way for people to do this

software, hardware co-design, that kind of thing. Yeah, I don't know. I think it's super interesting. I think the new types of chips that are coming out that people are coming to us with ideas about are super impressive and interesting.

And I'm glad to see like different companies like try chips um and um yeah i think uh yeah we're only going to see like more and more of it and hopefully uh in the near future you know we might move back to a future where there are suddenly a lot more electrical engineers out there, like chip designers and people who normally would have just default gone to a bang job or a software engineering role start getting interested in hardware again. And actually, a lot of the people I talked to who are software engineers, they actually did take a CPUs class or something, and they actually did take like, you know, like a CPU class or something,

and they really liked the hardware, but like, you know, some of these like issues were just like, you know, beating them down. So they just went for the easier route instead. Sure, sure. Right. Well, I think that's a pretty insightful take. And, you know, I'm, I'm envious in some ways of your position, and that I'm sure you'll get kind of a front row seat to the way things are going and you know, how folks are using tooling to get there. But I think that, you know, we covered quite a bit today. Kay, I definitely appreciate you being willing to jump on here, especially so soon after y'all launched. And I'd love to have you back on again in the future and kind of like do a progress check in on where y'all are at after, you know, some period of time here. Yeah. Thanks for having me on. It was like a very fun

conversation. You know, hopefully I didn't violate any like non-disclosure agreements. And yeah, I mean, I hope all the folks sitting at home had a good time listening. So yeah, I would love to come back on um you know uh yeah absolutely well uh okay have a great week and uh we'll talk soon all right thank you