Hacker News

The problem with "engineers will review" is: Critical review requires expertise. Expertise requires experience. Experience comes from building. Builders build because they like to build. So when builders are asked to do nothing but review, they will eventually tire of their jobs and leave, sometimes not just the job, but the industry entirely. The lower the quality of the agents' output, the faster this will happen.

You can do this for any company now. Any company not announcing this to boost their stock is foolish, ride the train with the crowd.

GPT-Company name brings together frontier AI models with Company's XYZ technology and domain expertise, enabling the specialized model [to] directly operate Company's tools. Engineers will delegate design objectives … with agents running tools, interpreting results, implementing changes, and iterating toward verified outcomes for engineer review.

Eventually... But it is materially relevant if that happens in 2 years or 10.

While I think SWEs(yeah, not HW/chip but that's not my field) are cooked in 5 years, I think we'll be quite busy in the meantime fixing all the bugs that AI finds.

Chips design is expensive. Partly because of engineering costs, partly because of manufacturing costs.

If costs go down enough,because of LLM's and possible manufacturing innovations, more chips will be designed, so maybe this will partially offset job loses.

My observation is even if AI takes 80-90% of my job, the remaining 10% is still going to be more relevant to keeping the company going than other people's 100%.

I wish this was hubris, but no. I would genuninely be happy to not have to do other people's work for them on top of mine.

Exactly. How 'bout “economize” chip design by reducing / eliminating human chip designers ... Go figure.

Aren't hardware design issues incredibly costly? I highly doubt they're going to "dark software factory" it or they'll be eaten alive by failed launches, product recalls, lawsuits.

https://en.wikipedia.org/wiki/Pentium_F00F_bug

I worry that even the electronics industry is falling into the fear of being agentic or being left in the dust. AI slop is already weird for programs.. I wouldn't want that in hardware.

Most of them anyway, and the cutoff bar will continue to rise.

And then the shit won't work, and then they will hire them again lmao

AI didn’t make chip manufacturing more expensive

Manufacturers choosing not to scale with demand or not being able to scale with demand

Is what constrained the supply.

Hopefully will be fixed within a decade , then it’s cool new stuff all the way.

What kind of deviation? Was it something AI could have helped catch earlier?

Local manufacturing is the next open challenge in hardware. If a pizza can be baked locally, why not chips?

This might make some sense if, the cost of any change in design vs requirement wouldn't cost $30-50M in mask and tape-out alone. That doesn't count the first wafer 'hot lots' just to get the design's first wafer out in only 3 months, or the bringup and modified test equipment to validate the design, or the corners testing and optimization, or the package tooling, or... Those can easily be additional $10Ms and that's per design, if you do a full mask change. If you can "fix it in metal", you might get that down to just $10M and 1 month?

This isn't software. The time, labor, and equipment costs of the first wafer dwarf the redesign cost, so it makes sense to get it right the first time. What if every build, compile, and link cost you $10M and 1 month? How would that change your work flow?

Most of the "AI" design tools today are focused on verification, validation and layout, which makes a lot of sense. They might help with architecture in the future (or making something high yield AND easy to fix in metal)?

You could run a small design on an MPW shuttle to reduce these costs, but your TTM get's longer, the yields won't be as high, and if you go to mass production you still face the huge mask costs.

Another place this might make some sense is reworking old large die 130nm designs on 8" wafers to be newer 28mm designs on 12", there are a LOT of those. The mask costs are lower, the design is well understood with lots of process margin, and wafer/yield costs could be modeled and favorable. Of course analog scaling is a whole separate kettle of fish.

> These chips still need to be physically made at TSMC, Intel, or Samsung.

That's for the most advance tech (sub 10nm and such). There is a lot of fab for chips that do not require the latest and greatest. If LLMs make it easier / more accessible to design ASIC, I think those fabs will be the one who will benefit the most.

... > I see you are using Cadence IP in your project, unfortunately this is not allowed per the terms and conditions and you will be reported to the authorities

EXACTLY, prepare to self deport immediately, push <proceed> to execute

its like a fox starting a chicken coop business

OpenAI does, in theory, have ZDR now and private inference soon. But if I'm nvidia I'm not sure how much I would trust it.

The goal - obviously - is the exact opposite.

Toolcalls will end up disappearing to the other side and then you can download the end result - at a price - or arrange for manufacturing, but you'll have no idea about what is in the nice & shiny black box.

There are tools for formal verification of design input, and they are being used, but not for everything.

Why there are still errata for silicon

1. Writing a formal specification of your intended behavior is hard and the best verification tool doesn't help when your assertions don't encode the required or intended behavior. So even with 100% formal coverage, you would still get erratas. And some people don't write any formal verification, instead working with a simulation based approach (either hand-written test cases or random stimulus simulation) 2. Computation complexity of formal verification is exponential. At some point you simply can't formally prove the behavior of a design, because it just won't run on your server. 3. There's different levels of formal verification, not all of them are in the spec -> behavior path. For example, you could classify automated checks like logic equivalence between the synthesis netlist and RTL code as a formal verification. But that checks if the optimizer in the synthesis tool was correct, not that you wrote the correct RTL.

It’s called design verification, formal proofs happen mostly at the EDA tool level and largely already automated. Design verification focus on functional correctness of the chip for its intended use case

Compared to software formal methods have greater adoption. But there are a lot of things that fall under the “formal” umbrella.

The most common type that is used would probably be logical equivalence checking. Proving RTL and a netlist are equivalent is useful for catching synthesis bugs.

Or proving two netlists are equivalent after inserting test functions directly into a netlist, or some other netlist edit.

Property checking is what I use the most. You can check these during simulation which I wouldn’t call “formal” but you can also prove them using tools that use SAT solvers and whatnot to prove things mathematically.

As always, the tricky part of verification is writing the correct test or model. With formal we can use SystemVerilog assertions to write properties and sequences, but the difficulty in getting them right goes from trivial -> inscrutable very quickly.

It’s extreme easy to write assertions that pass and never realize your assertion was not doing what you thought and you weren’t proving what you meant to.

I haven’t used some of the more advanced tools so maybe they have ways to make this easier. But because of this I tend to just write assertions that are pretty easy to understand at a glance, and therefore closer to the trivial side of things.

If a peer has to solve a sudoku puzzle in their head to understand your work, then it’s unlikely the peer review will be worth anything. So I do what I can to make my work understandable at a glance (from a competent peer in the industry).

Of course making something simple can be quite challenging and often takes more time than leaving something complex and opaque.

I’ve never been involved in the foundry side of the work, and for ASICs, that is often half of the schedule.

I remember the stock taking a beating after Kimi K3 created all that buzz about the open model designing chips that could run itself (even though the chip in question seemed small in today's standard of massive AI chips). It was only a matter of time before Synopsys released an offering like this. I can almost see the meeting where the C suite demanded working with an external partner over anything in-house they could build.

Why the overall market cap is smaller than both Synopsys and Ansys combined before the merger still beats me tho.

Would be really nice honestly. But I don't think it will be coming anytime soon, it's just too expensive to build a chip. The one-time costs for masks are just much more expensive as for PCBs, so wafer shuttle services are still really expensive when pooled PCBs are really cheap. And any machines that would be cheaper for prototyping (direct laser writing or direct e-beam writing) don't scale to mass production.

You can already make (tiny) chips for a somewhat affordable cost with tiny tapeout. But that's still not nearly as cheap as PCB prototypes and with much longer wait times.

You get your non-deterministic process (hired humans or LLMs) to create deterministic scripts (='generators' in EDA terms), which can then be audited, corrected, etc.

DRC/LVS/PEX/SPICE are deterministic, but the tools themselves are not without faults.

Physical design (what this seems to be targeting) already uses non-deterministic algorithms because floorplanning, placement, and routing are all difficult problems to solve with a deterministic algorithm. Introducing probabalistic approaches helps to find the right fit within the constraints.