Earlier quoted context omitted.
I still have nightmares about the entry level EE class I was required to take for a CS degree. RC circuits man.
“Oh shit I better remember all that matrix algebra I forgot already!” …Then takes a class on anything with 3d graphics… “oh shit matrix algebra again!” …then takes a class on machine learning “urg more matrix math!”
YC is wrong about LLMs for chip design
221–230 of 283 posts
Re: YC is wrong about LLMs for chip design
#222Earlier quoted context omitted.
Author here -- I don't disagree! I actually noted this in the article: > Well, it turns out that LLMs are also pretty valuable when it comes to chips for lucrative markets -- but they won’t be doing most of the design work. LLM copilots for Verilog are, at best, mediocre. But leveraging an LLM to write small snippets of simple code can still save engineers time, and ultimately save their employers money. I think desi…
Thanks for the reply! At large companies with many designers, a lot of time is spent coordinating and planning. LLMs can already help with that. As far as design/copilot goes, I think there are reasons to be much more optimistic. Existing models haven't seen much Verilog. With better training data it's reasonable to expect that they will improve to perform at least as well on Verilog as they do on python. But even if…
There simply isn't enough of that code in existence.
Writing Verilog code is about mapping the constructs onto your theory of mind about the underlying hardware. If that were easy, so many engineers wouldn't have so much trouble writing Verilog code that doesn't have faults. You can't write Verilog code just by pasting together Stack Overflow snippets.
Look at the confusion that happens when programmers take their "for-loop" understanding into the world of GPU shaders or HDLs (hardware description languages) where "for-loops" map to hardware and suddenly are both finite and fixed. LLMs exhibit the exact same confusion--only worse.
Re: YC is wrong about LLMs for chip design
#223I have been working on FPGA's and, in general, programmable logic, for somewhere around thirty years (started with Intel programmable logic chips like the 5C090 [0] for real time video processing circuits.
I completely skipped over the whole High Level Synthesis (HLS) era that tried to use C, etc. for FPGA design. I stuck with Verilog and developed custom tools to speed-up my work. My logic was simple: If you try to pound a square peg into a round hole, you might get it done yet, the result will be a mess.
FPGA development is hardware development. Not software. If you cannot design digital circuits to begin with, no amount of help from a C-to-Verilog tool is going to get you the kind of performance (both in terms of time and resources) that a hardware designer can squeeze out of the chip.
This is not very different from using a language like Python vs. C or C++ to write software. Python "democratizes" software development at a cost of 70x slower performance and 70x greater energy consumption. Sure, there are places where Python makes sense. I'll admit that much.
Going back to FPGA circuit design, the issue likely has to do with the type, content and approach to training. Once again, the output isn't software; the end product isn't software.
I have been looking into applying my experience in FPGA's across the entire modern AI landscape. I have a number of ideas, none well-formed enough to even begin to consider launching a startup in the sector. Before I do that I need to run through lots of experiments to understand how to approach it.
[0] https://www.cpu-galaxy.at/cpu/ram%20rom%20eprom/other_intel_...
Re: YC is wrong about LLMs for chip design
#224Earlier quoted context omitted.
I still have nightmares about the entry level EE class I was required to take for a CS degree. RC circuits man.
I dropped EE entirely and switched from Computer Engineering to Computer Science because of my entry level EE course professor. I know I'm not the only person pushed away from EE due to Neil Cotter. Boggles my mind why he's still allowed to be the gateway to that discipline for so many people.
I graduated in chemistry, and Chemistry 1 in engineering had tests much more difficult than any other Chemistry 1 in any other faculty. After noticing that the same pattern applied to Physics 1 or Calculus I started realizing it was an engineering thing, which was later confirmed to me by an associate professor that was the design.
I asked him why, and he told me that it's a long established thing that you don't want people that struggle with science fundamentals to build bridges, ships or electrical circuits so the first semesters are very focused on this weeding.
Re: YC is wrong about LLMs for chip design
#225I know nothing about chip design. But saying "Applying AI to field X won't work, because X is complex, and LLMs currently have subhuman performance at this" always sounds dubious. VCs are not investing in the current LLM-based systems to improve X, they're investing in a future where LLM based systems will be 100x more performant. Writing is complex, LLMs once had subhuman performance, and yet. Digital art. Music (se…
If LLMs will do well in the space for some use case it's the established chip designers that will benefit from it, not a small startup.
Re: YC is wrong about LLMs for chip design
#226Re: YC is wrong about LLMs for chip design
#227Earlier quoted context omitted.
Only if it fails in the same way. LLMs and the multi-agent approach operate under the assumption that they are programmable agents and each agent is more of a trade off against failure modes. If you can string them together, and if the output is easily verified, it can be a great fit for the problem.
If you're going to do that you need completely different LLMs to base the agents on. The ones I've tried have "mode collapse" - ask them to emulate different agents and they'll all end up behaving the same way. Simple example, if you ask it to write different stories they'll usually end up having the same character names.
In these situations, I’ve been able to sufficiently program the agent that I haven’t seen too much of an issue as you described. Consistency is a feature.
Re: YC is wrong about LLMs for chip design
#228The whole concept of "request for startup" is entirely misguided imo. YC did well because they were good at picking ideas, not generating them.
This doesn't line up with the perennial attitude (as discussed by pg) that YC picks people/teams and not ideas, because while ideas and approaches may change, the people are the same and having a good founder, co-founder and team matters the most.
Their M.O. is to avoid getting too attached to an idea because, in the process of actually building the company, pivots may be required. And so the focus is on a team moreso than a business plan, which again, is not something pg is particularly fond of seeing especially the ones that have lengthy (and therefore improbable/unrealistic) forecasts.
Re: YC is wrong about LLMs for chip design
#229Earlier quoted context omitted.
> I couldn’t believe they whiffed it Why should we expect a general-purpose instruction-tuned LLM to get this right in the first place? I am not at all surprised it didn't work, and I would be more than a little surprised if it did.
> Why should we expect a general-purpose instruction-tuned LLM to get this right in the first place? The argument goes: Language encodes knowledge, so from the vast reams of training data, the model will have encoded the fundamentals of electromagnetism. This is based in the belief that LLMs being adept at manipulating language, are therefore inchoate general intelligences, and indeed, attaining AGI is a matter of sc…
And I'm baffled that HN is not picking up on that and ACTUALLY BELIEVES that you can achieve AGI with a simple language model scaled to billions of parameters.
It's as futile as trying to explain vision to a blind man using "only" a few billion words. There's simply no string of words that can create a meaningful representation in the mind of the blind man.
Re: YC is wrong about LLMs for chip design
#230Other intelligent effects are coincidental.