Hi @User I will check it out. Hard to tell exactly but it looks like the nonlinear solver is stalling and failing to reduce the error norm enough to converge. The single terminal connection warnings are probably not a big deal, so I think your intuition is correct about that.

Thanks. It does work in ngspice and hspice.

OK, interestingly, it ran for me in the Xyce development branch just now. I was running in serial on my OSX laptop. And, when I ran it using a verbose build of Xyce, the solver didn’t appear to have any trouble near the 4.8e-9 time (which is where is is bogging down for you). Hmmm.

Yes, on Linux. Either serial or parallel

OK. Which version of Xyce? 7.2?

Xyce DEVELOPMENT-202105141522-g-b37dc80c-opensource

OK. I’ll log into a linux machine and try it there. BTW, there was another “sync” with the external github repository this morning. I can’t think of any obvious updates in that update, however, that would make a difference. On my OSX laptop, my build of Xyce 7.2 also succeeded just now. Possibly there is a subtle compiler difference? On OSX I usually build using clang++.

That makes sense. Lots of uninitialized memory nodes

OK, that helps. I have to run at the moment, but I’ll dig into this more later this afternoon/evening.

No worries. Thanks for the help

Hi @Matthew Guthaus, here is a small update. So far, we’ve been unable to reproduce your issue. It ran fine for me on OSX using clang, as I mentioned before. Then I attempted Linux, RHEL7, using gcc 5.3. (I just happened to be set up to use that gcc variant). Then one of my colleagues attempted BSD with clang. Finally that same colleague used exactly the same config as your: Ubuntu with g++ 9.3.0. All of them ran all the way thru without failure. So, we have a mystery.

Actually, speaking of that, I didn't run any tests to confirm my build actually "works". I think I read somewhere that there are some

Cool

I upgraded to 7.3 and re-ran this test. Interestingly, it fails with >1 threads but passes with a single thread. The error changes too. With 3 threads it does what I posted before, but with 2 or 4 it does this:

ZOLTAN Load balancing method = 10 (HYPERGRAPH)                                                                                                                                               
                                                                                                                                                                                             
        Step size reached minimum step size bound                                                                                                                                            
                                                                                                                                                                                             
        Step size reached minimum step size bound                                                                                                                                            
DC Operating Point Failed.  Exiting transient loop

When I built Xyce, I used these options:

../configure CXXFLAGS="-O3 -std=c++11" ARCHDIR="/software/XyceLibs/Parallel" CPPFLAGS="-I/usr/include/suitesparse" --enable-mpi CXX=mpicxx CC=mpicc F77=mpif77 --prefix=/software/Xyce/Parallel

I was going to use that Xyce_Bundle, but it only builds the serial version.

Hi @Matthew Guthaus, one thing to try is to force parallel Xyce to use the “parallel load, serial solve” option. The output, above, which says

ZOLTAN Load balancing method = 10 (HYPERGRAPH)

indicates that Xyce is attempting to use an iterative solver. Iterative solvers are easier to set up in parallel but tend to be less robust. Direct solvers (which is the Xyce default in serial) are very robust, but hard to make scale well in parallel. Anyway, parallel Xyce looks at the size of the problem, and if the problem size is below a number (I can’t recall the exact number, but it might be 1000 unknowns), it will do the linear solver phase of the calculation using a serial direct solver on proc 0. The device evaluation will still be parallel, however. Direct solvers actually work pretty well at much larger sizes than 1000, so arguably our threshold for direct/iterative is too low. Anyway, you can force Xyce to use a direct method by adding

.options LINSOL type=klu

to the netlist.

I think it might've passed in 7.2 as well in serial...

Ah. I had the vague impression that it had failed in all modes before. But I’m getting confused about which circuit I’m remembering now.

I didn't actually try serial. I didn't think it would be dependent on this...

Of course when you force KLU, that means part of the calculation is serial. So, that will limit the speedup you get, based on Amdal’s law.

Bleh 😞

Well, at the size of problem you are running, most of the work is in the device evals, which are still parallel. So you will get speedup.

This is just a unit test!

How big?

Oh, 10000x bigger

Just checked the output from when I ran this a few days ago. Total Devices is 2605, Number of Unknowns = 11597. That is a size where the KLU option is probably the best choice, even though by default Xyce attempts the iterative solve.

Well, this example is a 64-bit SRAM, so going up to 64kbit is the goal. We do, however, do some pruning internally of bitcells, so it probably won't be exactly 10kx

got it. I have to run to lunch right now but I’ll have more to say later …

I'll try the klu option

So, based on my own experiments, this will run with the KLU option. When I ran it in serial last week, about 80% of the calculation was the device evaluation and 20% was the linear solve phase. With the KLU option in parallel, only the device eval is parallelized, but it is a large enough fraction of the calculation that you should get meaningful speedup. Based on Amdahl’s law, the theoretical max speedup for this circuit would be (1/(1-0.8)) = 5x.

I can then change this in OpenRAM to select which one. Thanks!