Lramseyer

Yes, but that's only the first part of it. The LLM can create 100 good, working, and verified designs. You still need to lay them out and optimize the physical designs. That kind of optimization is not something language models are good at. You need something fundamentally different.

Production grade CPU design is more than just the RTL (the source code.) To achieve the performance numbers that these companies get, you have to do a ton of optimization in your physical design to achieve the power/performance/area (PPA) metrics that make these products competitive. LLMs are not suitable for that kind of work.

There are people working on PPA optimization and trying to shake up how things are done, just not with LLMs.

Being tied to the code editor is the entire point, otherwise I would have just used GTKwave. Integrating it into the code editor - specifically VScode allows me to support terminal links (instance paths and timestamps from sim logs), first class remote SSH support (instead of having to use a laggy VNC session), and design hierarchy to RTL. Though you need a separate extension for that, because the waveform viewer is language agnostic and simulator agnostic by design. If you have ever used Verdi, it does design hierarchy to RTL, and I wanted to make a modern and open source version of that.

Surfer is fantastic, and the developers of Surfer are pretty great people too! It has been on my to-do list to learn Spade.

Another point about HFT - They're mostly using FPGAs (some use custom silicon) which means that they have much tighter control over how DRAM is accessed and how the memory controller is configured. They could implement this in hardware if they really need to, but it wouldn't be at the OS level.

Yeah, I was a bit surprised that the author didn't mention that facet of Open AI. It did mention infrastructure goals, but the reality is that Open AI's infrastructure spending commitments have inflated the stock prices of quite a few hardware companies (like Micron and WD) and caused a strain on the market.

The real danger here is how over-leveraged Open AI is. No other AI player is as exposed. Their massive spending commitments are all precariously balanced on the other end by their user base, and if that evaporates, the whole thing will fall apart and that could crash the stocks of other players ...and by crash, I mean bring them down to a realistic value. But the economy is counting on this to work, which is why I believe that Open AI's strategy here really is to make the market exposed to Open AI's risks.

Crazy idea, but maybe change the rules of Show HN so that you are required to include in the headline how long you have been working on the project. As an example, something like:

Show HN: My Project - A description for my vibe coded project [3 weeks]

A lot of the good stuff I see on Show HN are projects that have been worked on for a long time. While I understand that vibe coding is newer trend, I also know that vibe coded projects are less likely to stand the test of time. With this, we don't have to worry about whether a project is AI assisted or not, nor do we ban it. Instead just incentivize longer term projects. If the developer lies about how long they worked on the project, they will get reported and downvoted into oblivion.

You have to understand the people in the article are execs from the chip EDA (Electronic Design Automation) industry. It's full of dinosaurs who have resisted innovation for the past 30 years. Of course they're going to be blowing hot air about how they're "embracing AI". It's a threat to their business model.

I'm a little biased though since I work in chip design and I maintain an open source EDA project.

I agree with their take for the most part, but it's really nothing insightful or different than what people have been saying for a while now.

> every mention in a package.json or requirements.txt

OK, what about those of us who aren't writing libraries?

As a personal anecdote, the amount of opportunities that have been opened up to me as a result of my open source project are worth way more than any $1 per mention or user.

As much as I love Zed, I am of the belief that VScode (and its derivatives) will remain the dominant build-your-own IDE for a really long time unless something like Zed can support web based extensions. I created a VScode extension for chip designers and I would love to port it to Zed, but I can't because it's a visualization extension with a custom webview.

I realize the irony here that Zed is fast because it's not web based, but I stand by my claim that being able to optionally display web UIs would be a really cool feature to have. It would open the door to a lot of extensions.

Dating apps are a Skinner Box by nature. They give randomized reward in the form of likes and matches. If you're attractive, you're the product because you don't need premium service to get more dates.

Give me Yelp for date spots and take a cut of the ad revenue. That way, there's at least an incentive to get people to not ghost each other long enough to actually meet up for a date. Hopefully that will do some level of incentivizing human connection.

Another one is custom CSS (though it doesn't look like positron does that.) You can change styling properties like spacing and weighting as well.

I have a love/hate relationship with the VScode webview panels, but the message handler is not my favorite implementation in the world. I would love a way to send binary data, and get semantic token colors.

The only issue is that when you have a custom build of VScode, you have to manage a fork of VScode, and potentially pull in updates as VScode updates. How do you manage that?

Unfortunately socketed processors only really work with DDRx type DRAM interfaces. GPUs use GDDR and HBM interfaces, which are not ideal for sockets. In the case of HBM, you have 1024 data traces per DRAM chip, which would make the socket have an insane number of pins. GDDR has fewer pins, but makes up for it with higher data rates (32 pins at 16Gb/s) and that is impractical to use in a socket due to the variance in contact area resulting in impedance matching issues.