It's a lost cause, you have to pick a new word.

"Diet" was used for women's food product to the point that men didn't want to buy anything with "diet" on it, so CocaCola created coke zero just for men instead of trying to make them drink "diet" coke. They knew it was a lost battle.

My comment is in the context of this topic: large digital ASICs with billions of wires, where the only analog parts are PLLs, DLLs, and digital IOs.

(I see it was meant to be indirectly expressed violent censorship against the use of 'literal' in rhetoric speech... That without a carefully respectful use of 'literal' we will lose the irreplaceable "safe word" out of the bondage of figurative dungeons. Very considerate. Root_axis, rushed writing and reading defies a subtlety hidden in "dad jokes"...)

The meaning of the word has changed. If everyone uses it incorrectly is it really incorrect?

My physics professor had some good examples of how numeric precision vastly outstrips reality: if modelling a 1m iron bar using 32-bit numbers, the error in length is substantially less than a dust mote landing on the end of it. It's about the same as a virus (not a bacterium) on the end... or not. The oil from a fingerprint is thicker. The mere presence of a human in the room will warm up the iron rod enough to cause it to expand more than this.

You only get physically significant errors when using iterated algorithms where the errors accumulate, or when doing what amounts to equality comparisons, which is almost always an error.

Note that 64-bit numbers aren't "twice" as precise.[1] They're four billion times more precise. Going to 128 bits is absurd beyond belief. Numbers like these would allow the entire visible universe to be modelled, down to the width of a proton. You do not need 128 bit numbers for anything made on Earth, by humans, ever. If you think you do, you've made a mistake. It's as simple as that.

[1] floating point numbers and integers are obviously different, but the concepts are the same. A 64-bit double is "just" 536 million times more precise that a 32-bit float, but that is still an awful lot of precision for anything made of matter...

  #include <iostream>
  #include <iomanip>
  #include <cmath>
  #include <tuple>

  // solve ax^2+bx+c=0
  template<typename T> auto
  solve_quadratic(T const& a, T const& b, T const& c) -> std::tuple<T, T> {
    auto t = std::sqrt(b*b - T(4)*a*c);
    return {(-b + t) / (T(2)*a), (-b - t) / (T(2)*a)};
  }

  int main() {
    std::cout << "Expected x1=0.000000075 x2=-200.000000075\n"
    std::cout << "Single precision:\n";
    {
      float a=1.0f, b=200.0f, c=-0.000015f;
      auto [x1, x2] = solve_quadratic<float>(a, b, c);
      std::cout << "x1=" << x1 << ", x2=" << x2 << "\n";
      std::cout << "ax1^2+bx1+c=" << (a*x1*x1 + b*x1 + c) << "\n";
      std::cout << "ax2^2+bx2+c=" << (a*x2*x2 + b*x2 + c) << "\n";
    }
    std::cout << "\nExpected x1=1.000000028975958 x2=1.000000000000000\n";
    std::cout << "Double precision:\n";
    {
      double a=94906265.625, b=-189812534, c=94906268.375;
      auto [x1, x2] = solve_quadratic<double>(a, b, c);
      std::cout << std::setprecision(16);
      std::cout << "x1=" << x1 << ", x2=" << x2 << "\n";
      std::cout << "ax1^2+bx1+c=" << (a*x1*x1 + b*x1 + c) << "\n";
      std::cout << "ax2^2+bx2+c=" << (a*x2*x2 + b*x2 + c) << "\n";
    }
  }

  template<typename T> auto
  solve_quadratic(T const& a, T const& b, T const& c) -> std::tuple<T, T> {
    auto sign_b = b < 0.0 ? -1.0 : 1.0;
    auto t = -b - sign_b*std::sqrt(b*b - T(4)*a*c);
    return {(T(2)*c) / t, t / (T(2)*a)};
  }

PCB routing is generally considered a much harder problem. There are a bunch of reasons that add up, but one of them is almost certainly that a PCB is supposed to look good too. The routing on an IC is total chaos (which actually reduces crosstalk issues), but nobody will ever notice.

So here's my autorouter first-guess analog computer design:

On a basketball court create a pile of metal plates with bar codes and hooks, each one represents a gate, robot uses rubber bands of sizes vaguely representing timing budget from synthesis to hook the gates together. Robot picks up the whole thing using rubber bands representing the external ports and gives the whole thing a few shakes. Puts it all back down, goes over each metal plate and reads the bar code and resting position - that's your initial routing guess - anneal from there

Disclaimer: I have zero silicon design experience.

However, I have designed computer game engines that use 32-bit floats throughout and encountered rounding errors in practice.

I’ve found that there’s always a solution that avoids the need to go past 64 bits, and even that is a last resort.

So for example the circle could be approximated with a polygon. Or fixed-point arithmetic can be used. Or simply use a quad-tree or related space partitioning algorithms to check for intersections.

There are literally thousands of algorithms that sidestep these issues and are used extensively in computer games, typically at 32-bit precision exclusively.

For example “back in the day” you would often see shimmering due to “z-fighting”. You would also often see white pixels due to “cracks” between adjacent polygons.

All of these are largely gone now. The problems have been solved without the enormous performance hit of 64-bit doubles, let alone 128!

Meanwhile contemporary CAD programs would insist on using 64-bit doubles, even through the OpenGL pipeline out to the screen.

But if you sit down for a second and just divide your screen (or wafer mask) by the range of your chosen numbers you’ll instantly see that you have thousands of steps per pixel (or atom!) to work with.

Any visible noise is your fault for choosing the wrong algorithm, not the fault of the hardware for not providing enough bits.

Of course when you're doing such intersection calculations you know the things you're intersecting are very close. You don't need a general method that can test arbitrarily sized and spaced polygons against each other. You need a method to determine what is sufficiently close to each other to be worthy of a more detailed check. Then a more specific method to do this check.

You could use 32 bit integers with all shapes specified vs say a 0.1 nm grid giving you around a maximum 0.4m x 0.4m chip size which seems ample. Then when you want to check for rules violations in the cases like you specify with very fine precision use a dedicated check that can assume the relevant geometry is within a small number of grid points of each other. For example the check could work using relative coordinates rather than absolute so say switch to a grid on a 0.00001nm basis (to pull an arbitrary precision out of a hat) and convert the 32-bit absolute 0.1nm coords to relative 32-bit 0.00001nm coords.

Easier said then done to be sure (as you say the tools are egregiously expensive!) but just saying I need a 64-bit or a 128-bit float isn't trying to get to the grips with the problem, just hoping you wave it away with more bits.

> are any companies other than Nvidia embarking up AI/ML chipmaking in a closed fashion?

https://www.cadence.com/en_US/home/solutions/machine-learnin...

https://www.synopsys.com/implementation-and-signoff/ml-ai-de...

https://www.plm.automation.siemens.com/global/en/our-story/n...

I think you'll be hard pressed to find any company using open source tools to design a business-critical chip for a foundry that gives any information without an NDA.

AFAIK Google doesn't have a open-source ASIC design for OpenTitan, and WD doesn't have an open-source ASIC design for SweRV.

there are a lot of interesting initiatives, but in the semiconductor industry open source tooling and processes are only a tiny niche that a few companies are playing around with.

> The chip design itself should be the secret sauce. Not the tools you make the chip with.

The secret sauce is generally whatever gives one a competitive advantage. Businesses typically open things up when the want to reduce the cost of something and/or cause pain for someone else (i.e. killing their cash cow), not because they're benevolent and want to share.

> I challenge you to answer your own question in reverse: are any companies other than Nvidia embarking up AI/ML chipmaking in a closed fashion? There probably are, let's follow & watch them.

Isn't Google's floorplanning work closed source? https://ai.googleblog.com/2020/04/chip-design-with-deep-rein...

So intel, TSMC and Samsung have open-sourced their chip manufacturing systems I did not know that. ASML is giving out lithography systems so anyone can make them.

> The chip design itself should be the secret sauce. Not the tools you make the chip with.

I’m sure Cadence, Synopsys, and Mentor would love to hear more about this.

"The NVIDIA Deep Learning Accelerator (NVDLA) is a free and open architecture that promotes a standard way to design deep learning inference accelerators. With its modular architecture, NVDLA is scalable, highly configurable, and designed to simplify integration and portability. The hardware supports a wide range of IoT devices. Delivered as an open source project under the NVIDIA Open NVDLA License, all of the software, hardware, and documentation will be available on GitHub. Contributions are welcome." http://nvdla.org/

> The chip design itself should be the secret sauce.

The chip comes from the chip design, and the chip design is made with tools. None can exist alone.

> Many other companies are starting to get onboard with open chip design.

> There are plenty of company's releasing the chips too. Google's OpenTitan[2] security chip. WD's Swerv RISC-V core for their driver controller ARM R-series replacement[3].

These chips aren't the foundation of Google or WD's revenue stream. You won't see them significantly affecting a line item in their quarterly reports.

> are any companies other than Nvidia embarking up AI/ML chipmaking in a closed fashion?

Nvidia is in a unique position where the foundation of their profits (chips) happens to be what makes practical AI possible. They're literally running the vast majority of the show. If something falls into the "foundation of existence" circle in their Venn diagram of concerns, they're going to be less open about it. Improving the ability to design chips is at the exact center of that "foundation of existence" circle.

Designing a modern ASIC requires experts across the whole spectrum, from top level architects who increase performance and reduce power from first principles, to RTL designers who have a feel for what kind of code will result in less area or less toggling wires, to standard cell designers who optimize a cell library for an optimal speed vs power vs area trade-off, to floor planning for the area density and speed while not running into IR drop and congestion issues, to DFT to make sure testing is as fast as possible with a high coverage, to DFM engineers who come up with strategies for optimal yield.

All these aspects are part of the chip design, and being bad at one can significantly compromise the competitiveness of the final piece of silicon.

So this statement is hopelessly naive and ignorant:

> The chip design itself should be the secret sauce. Not the tools you make the chip with.

Because all the steps that I listed above are done with tools. And in many cases, having better tools is the secret sauce that makes your design better than the competition.

The article mentions a runtime of minutes instead of a day to do IR drop checking: that's the kind of acceleration that allows trying out multiple configurations for an optimal solution instead of settling for good enough. A lower amount of IR drop allows for a more aggressive, less conservative power curve. End result: a chip that can be clocked at a higher speed without needing to increase the voltage. A major competitive advantage.

> are any companies other than Nvidia embarking up AI/ML chipmaking in a closed fashion?

Of course there are. AI can be used for almost anything where large amount of data is already available, and where there's a clear cost function that must be optimized. AI is a natural for many steps in the ASIC design flow. You could have figured this out by yourself: Nvidia is talking about it. If it were such a big novelty, they'd keep it under wraps.

> WD's Swerv RISC-V core for their driver controller ARM R-series replacement [snip snip] everyone but NVidia playing well together, trying for better, standardizing a future for participation & healthy competition & growth.

Let's talk Swerv: a piece of IP that's definitely useful to Western Digital. Useful to general world too. But not something that scores particularly high on the list of the secret sauce ingredients that makes or breaks their products. Does Nvidia have similar open source IP offerings? Yes, they do! Check out NvDLA: Nvidia's open source DL accelerator. Your day must be a whole lot better now, knowing that, just like WD, Nvidia also open sources some non-critical IP.

I'm sure that you're aware that AMD uses a neural network in their CPU branch predictor. Do you think that AMD should release the tool that was used to figure out the optimal weights? After all, the tool itself is not part of the actual CPU design...

If the tools to make it would more easily allow others to achieve similarly efficient designs, then that is the secret sauce...

They are getting onboard with open chip design, because they need to get onboard with open chip design, and borrow to even be competitive and survive. You only get to use the black rocket when you're not in the lead.

Huge part of why OpenROAD (and as this article.indicates, nvidia) are so focused on machine learning! Because the nitty gritty of chip design has abundant gnarly problems requiring deep deep expertise. Deploying software engineers is hard. But building ml is kind of our bag!

There's another nice upstart opensource project with even fancier ml placememt systems that spawned recently out of the openroad world, dreamplace, https://github.com/limbo018/DREAMPlace

This is just gonna get more & more biased against a couple super smart engineers who we've deeply entrusted to divine inner the workings of the chips on, & become increasingly a set of better modelled problems that we can machine learningly optimize.

So let's get this straight. You know nothing about this area and you assume the experts in it are wrong? Do you know what happens if you accidentally couple lines during one of the manufacturing steps? The wafer can, in the absolute worst case scenario, explode from super heating destroying not just the wafer but potentially the entire chamber it is in (any defect beyond what was designated as allowable by the design engineers means the chamber and everything in it is now scrap).

For somewhat obvious reasons, we have a vested interest in this never occurring. So we default to safety over speed. Meanwhile in the CAD world with 64-bit math not making it into OpenGL, they just wrote a library to do 64-bit math anyways on-top of or in parallel to OpenGL. They didn't switch away from 64-bit math, they just reduced its use where it isn't needed and kept it where it is needed. The semiconductor industry is full of absolutely brilliant engineers who know far too much about all of the problems and if they could use 64-bit instead of 128-bits for a data structure, they'd switch in a heartbeat to save massive amounts of compute time (and thus money).