Andrew Pullin

A mix of general code improvements that net about 2-4x speedups on CPU. I also put together a "random circuit" generator to test it: https://github.com/apullin/spicesmith I also did a track of GPU enablement. 2-6x holds up for FP64 calculations, with an H100 getting the higher scores since it has proper FP64 support. Bigger wins came from an FP32 solver on GPU, which gets ~6-10x commonly. The biggest speedup was ~300x for an OpenRAM design in the IHP PDK, which is where this project started. I was...

I believe github will pretty easily enforce a copyright takeover if you contact them and show them you are the genuine maintainer of this project and control the ngspice.sourceforge.io domain. If there's a trademark then it's compulsory to give you the name. I believe US patent office grants implicit trademark under some rules, as does German. I can try pushing into the issue with github support to see if they easily yield to a trademark claim ... I'm not affiliated yet, but I can report back on...

It looks like the ngspice repo on github is abandoned. Is there any interest in sync'ing it? Fairly easy to do with AI tooling now. I could maintain the sync, if there is interest. My interest is that I have a (significantly) accelerated version that I will publish soon, and github is the common place to do that, so I would end up pushing all of v47 to a fork, anyway.

Hi, It looks like the ngspice repo on github is abandoned. Is there any interest in sync'ing it? Fairly easy to do with AI tooling now. I could maintain the sync, if there is interest. My interest is that I have a (significantly) accelerated version that I will publish soon, and github is the common place to do that, so I would end up pushing all of v47 to a fork, anyway.

Hi, It looks like the ngspice repo on github is abandoned. Is there any interest in sync'ing it? Fairly easy to do with AI tooling now. I could maintain the sync, if there is interest. My interest is that I have a (significantly) accelerated version that I will publish soon, and github is the common place to do that, so I would end up pushing all of v47 to a fork, anyway. Andrew

Not sure how to handle it, really. Having complete support would be great, so other's don't get stuck like I do. But given the number of people who appear to have success with other STM32 parts and other versions of the bootloader, this might be one unique exception. Or there might even be low-RAM parts that have a lower limit. I suppose I'll open a technical support ticket with ST Micro, and ask if they have a complete list of special-case rules like this ...

Alright, I am going trout of my mind over this. I finally went to the extent of installing a serial port sniffer in Windows, and using the official STM32CubeProgrammer there to flash a longer binary, and, sure enough, their extended erase command transmits 0x63 as N, to erase only 100 pages at a time. Changing the stride from 511 to 99 in stm32_erase_memory and rebuilding makes flashing now work. Great that that isn't documented anywhere at all, thanks STMicro. jeeeeeeeeeeeeez

For the sake of thoroughness, I am creating the binaries via: dd if=/dev/urandom of=test.bin bs=2048 count=154 and dd if=/dev/urandom of=test.bin bs=2048 count=155 and flashing with: ./stm32flash -b 115200 -w test.bin /dev/cu.usbserial-A107L5XO