Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia receives DARPA award to accelerate electronics simulation

juliacomputing.com

Post reply on HN
Print view View original

101–110 of 175 posts

Re: Julia receives DARPA award to accelerate electronics simulation

#101

Post by KenoFischer »

ptarmigan wrote: post #95
KenoFischer wrote: post #70

Earlier quoted context omitted.

We are working on improvements to the baseline simulator also (or rather we basically get them for free because they are part of our core simulation engine), so hopefully that should address some of the first order usability issues in SPICE simulations. For these kinds of design applications, the ML-based speed up may or may not work, since you do have to spend time training the surrogate. You can often re-use pieces…

Sorry if you've already clarified, but is this meant to replace or augment traditional SPICE simulators? I remember Ken Kundert mentioned that, even with the improvements of Spectre over SPICE-based simulators, it took things like SpectreRF's oscillator phase noise modeling to get analog designers to consider changing their ways. Their steadfast use of SPICE is "a form of Stockholm Syndrome," in his own words.

Our plan is to build both some extremely sophisticated analog design tooling that improves the state of the art (by leveraging our existing investments in modeling & simulation from other domains to build a clean simulator implementation) and then have the ML acceleration be an optional "one more thing" that can be used where applicable. Of course the first part is a major undertaking, so we're talking to potential customers to see what particular thing to start with that would really get them to consider using our system. That is independent of the DARPA-funded work though, which is particularly on the ML side (closely aligned of course).

Re: Julia receives DARPA award to accelerate electronics simulation

#102

Post by gugagore »

Sukera wrote: post #16
adgjlsfhk1 wrote: post #9

Earlier quoted context omitted.

the TLDR is that for a lot of high dimensional PDE models, you get a better trade off of speed vs accuracy by using a NN for part of the model that is inefficient to calculate the full physics for. This is already having a lot of success in climate modeling, where NN based solutions do a better job of dealing with some atmospheric effects than previous efforts.

Sounds similar to what stockfish (leading chess computer engine) does. In newer versions, position evaluation comes at least in part from a NN, which lead to an improvement in playing strength. edit: similar in approach, not as a 1:1 mapping. Replace a deterministic model with a faster, slightly fuzzy one.

This can be a useful connection, but I believe it's worth fleshing out in case it is misleading

What's the alternative to using a NN for position evaluation? I can think of two:

1. Do minimax search until you have a winner or a stalemate. Then you have the exact value of the position. Well, this is the problem we're actually trying to solve to begin with, and it's also impractical to do for chess and any interesting game. This is what necessitates an approximation to position evaluation.

2. A human expert writes a position evaluation function. It determines a huge handful of features, a simple example being how many pieces I have - how many pieces you have, and some way to combine those features into a score.

In surrogate modeling, you can get ground-truth data to evaluate your approximation against. You're approximating another model that you can compute, it's just too slow for practical use.

In chess, we don't know THE position evaluation function. We can certainly get data about it, but we don't know it in the same way we know PDE models.

To be clear, I am not saying we _know_ the PDE models are accurate with respect to reality. That's the science part, to determine if the model arising from empirical evidence or first-principles that are themselves arising from empirical evidence, actually summarizes empirical evidence.

Re: Julia receives DARPA award to accelerate electronics simulation

#103

Post by planet-and-halo »

ViralBShah wrote: post #85
planet-and-halo wrote: post #76

Earlier quoted context omitted.

I'd like to second this question. I'm very interested in bioinformatics as a field, but no background. Would be happy to devote some free time but I wouldn't want to be counterproductive.

The way to do this is to find non-domain specific tasks in these projects, and make useful contributions to the team - and slowly learning as you go along. Website, CI, benchmarking, helping out new users, pointing out unclear docs, writing a tutorial as you learn, etc. are all great ways to get involved.

Thanks a lot, these are great suggestions.

Re: Julia receives DARPA award to accelerate electronics simulation

#104

Post by KenoFischer »

ptarmigan wrote: post #91
KenoFischer wrote: post #28

Earlier quoted context omitted.

Chris has posted the relevant papers in a sibling comment, but let me try to give an intuitive explanation. Say you have some sort of electronic device like an amplifier. It is made out of many individual transistors and parasitics, but its time evolution is overall guided mostly by the amplifier characteristics its supposed to implement plus boundary effects and corrections from the parasitics. So what you try to do…

Do you think such an approach could extend to the final verification stage of a large post-extraction chip? My impression is that speedups are most sorely needed in this final sign off phase where the number of nodes explodes with parasitic R's and C's, especially in modern technologies. Simulation times in weeks seem necessary now for sufficient verification accuracy of analog/mixed signal chips.

Yes, we're looking at it. One of our benchmark cases for this work, will likely be a post-extraction structure from one of the Sky130 chips (not that it wouldn't work in a more moderns process, but the NDA issues become complicated while this is still a research project).

Re: Julia receives DARPA award to accelerate electronics simulation

#105

Post by KenoFischer »

nsxwolf wrote: post #56

So, at 1000x the current fastest speed, how close does simulation get to the speed of real circuits?

Depends on the time scales of the circuits (as long as your baseline simulator isn't dumb) ;). For example, consider LRC circuits that have an analytic solution - you can basically simulate them instantly. The primary goal here is to bring analog simulation to similar time scales as digital simulation on realistic problems.

Re: Julia receives DARPA award to accelerate electronics simulation

#106

Post by kurthr »

eternauta3k wrote: post #65
kurthr wrote: post #34

Earlier quoted context omitted.

Because all modern computer chips and electronic systems (e.g. PCBs) rely on electrical simulation for design and build. Typically, these are SPICE based simulators, which are open source and quite old in their methods (you literally set convergence requirements and step times). FPGAs are already digital... meaning that although they (FPGAs) have to be simulated when they are designed, their purpose is digital simula…

Open source? Isn't everyone using Spectre or Eldo?

which are built on BSD licensed SPICE at Berkeley: "SPICE (Simulation Program with Integrated Circuit Emphasis) is a general-purpose, open-source analog electronic circuit simulator."

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

Also see HSPICE, pSPICE, LTspice...

Re: Julia receives DARPA award to accelerate electronics simulation

#107

Post by oxinabox »

vallas wrote: post #88
nicolashahn wrote: post #14

Earlier quoted context omitted.

This is about Julia Computing, the company, not Julia the language.

I mean what is the Julia ecosystem focusing on that Rust would not (or similar languages)

Scientific and technical computing.

---

Not saying you can't do this stuff in rust. I mean its turing complete.

But contrast the description of Rust: A language empowering everyone to build reliable and efficient software.

vs Julia Julia is a high-level, high-performance dynamic language for technical computing.

Julia is for doing "technical computing". Things like simulations, problems where you need to apply a bunch of math. Its easy to write math in julia. The syntax is designed for it (like look at code for manipulating matrixes). The semantics are designed for it (multiple dispatch is the thing you need for efficient linear algebra for example. Specializing on each combination of matrixes)

Re: Julia receives DARPA award to accelerate electronics simulation

#108

Post by multiply »

oxinabox wrote: post #37

A modern circuit simulator, that has a fully featured programable API, that can be run from a real modern programming language, would be a dream. Every simulator i have used has been pretty limited in that way, or at least those features were not well advertized. Even the insanely expensive ones. I mean the most expensive ones (like $100K liscense type deals, like Cadence) are if anything even less modern from a user…

A lot of semi companies have built their own simulation environments because the EDA vendor's provided tools are very limited in what they can do and difficult to use. Many users go to Python, Excel or MATLAB because the programming/math capabilities of the EDA tools are inadequate. Over time these home-grown environments become a burden and the developer disowns it and it becomes a headache.

The EDA tools have no ecosystem you can hook into and they don't really care about the user trying to put the simulators into a flow to solve their problem. It is a bunch of point tools each with their own embedded interpreter that don't play together. I sure hope there is a plan to create a better set of tools so I can write custom netlist checks and do something novel (like get derivatives out of the simulator) and in-memory (no slow disks) and run custom Julia checks during simulation. Julia is a much better match because running Python or MATLAB code within the simulator is way too slow. I'll keep watch for sure.

Re: Julia receives DARPA award to accelerate electronics simulation

#110

Post by kayson »

KenoFischer wrote: post #99
kayson wrote: post #80

Earlier quoted context omitted.

I've been doing analog integrated circuit design for a decade and I'm somewhat skeptical that this is practical. I hope you can convince me otherwise because this would be great to avoid multi week simulations. From your other comments, it seems that the general principle is to create a simple model that captures most of the behavior then apply corrections on top of that. Can you elaborate on how the model is trained…

> From your other comments, it seems that the general principle is to create a simple model that captures most of the behavior then apply corrections on top of that. It's not applying corrections as in doing a taylor expansion and then adding terms to it, it's basically a projection of the systems. The basic details are in the CTESN paper, though I think there's improvements that haven't been published yet to make it…

> improvements that haven't been published yet to make it work in this domain

Are you able to share what some of those are?

> You can choose what parameters to fix and which to keep variable over the training process

Can you explain more about the parametrization? Do your parameters correspond 1-to-1 with schematic parameters like transistor sizes or resistance/capaciance values? Or internal transistor model parameters? Or are they more abstract mathematical parameters?

> I'm not sure I quite understand the distinction that you're drawing and measuring errors in a sensible way here is actually somewhat non-trivial.

Circuit simulator vendors often market their accuracy in terms of "% SPICE Accuracy", and what they mean is if you run a simulation and measure some parameters (usually something like RMS noise voltage or signal-to-noise ratio), then those measurement results will be within 1% of what the measurement results you'd get from running the same simulation with full-accuracy SPICE.

The other way of measuring simulator accuracy is in terms of dynamic range. For example if I have a noisy sine generator circuit where the signal has rms amplitude 1, and the noise is 1e-4 rms, I need to make sure the numerical noise of the simulator is much less than 1e-4.

The first is sort of relevant in your case as a comparison between surrogate and full simulation. The second is an absolute measurement of a single simulator's (or surrogate's) accuracy.

> I believe the error rates Chris quoted are from a smooth distance metric between the signal generated by a full simulation and those generated by the surrogate.

This is interesting because it makes sense as an application-independent metric for measuring the accuracy of your surrogate. It's not immediately clear to me how this would translate to circuit performance accuracy in all cases. However, in one specific case - a Digital to Analog Converter - that 1% smooth distance error could be catastrophic for some performance metrics depending on how it behaves.

That might be an interesting thing for you to consider investigating through the course of your research.

> We are expecting speedups on real-world problems just by using this framework for baseline simulation

Very cool, and I'm looking forward to seeing some data there.

One last question - why did you choose this particular DARPA project? Was it any specific interest/relationship with the circuit design industry? Or did it just happen to be a very cool application of CTESN?

Post reply on HN