@yaasshh

Devlog #21

Since the last devlog I finished most of the temperature phases.

First I compared the diode at 400 K against DEVSIM. I saved that result so my other tests compare with it from now on.

Then I added two new sliders to the website. One sets the temperature, from 200 to 500 K. The other sets the fixed charge where the silicon meets the oxide. I picked both ranges by running the simulator across them. Each slider also has a short lesson that explains what it does. While I was writing those, I found some broken math formatting in the temperature lesson and fixed it.

The biggest addition is freeze-out. To make silicon conduct, we add extra atoms that give up electrons. When it gets really cold, those atoms stop giving up their electrons. Before, my simulator assumed they always did. Now there’s a switch for it, and it works. At 100, 200 and 300 K it matches the textbook formula almost exactly. I also checked that a plain frozen silicon bar still follows Ohm’s law, and that the capacitance results still work at 150 K.

Devlog #20

In this devlog i firstly fixed up the website. It now has a little icon in the browser tab, a terms page, a privacy page and a footer with a contact button. The icon didn’t show up on the live site at first, so I fixed that too.

Then I started the next phase, which is all about fixing temperature related stuff. A lot of the calculations of the simulator took room temperature which might have led to some wrong calculations, so I’ve been fixing that.

The gate’s energy level was stuck at its room-temperature value. it was a real bug and its fixed now.
When the silicon gets hotter, electrons now max out at a lower speed, just like in real-life chips.
From 250 to 400 K, the junction’s built-in voltage matches the textbook formula.
From 300 to 400 K, the diode’s leakage current stays within 0.3% of the formula.

I also added a fixed charge that sits where the silicon meets the oxide layer. Real chips always have some, and it changes the voltage where a transistor turns on.

Next up are the big jobs. A long DEVSIM run is still going, and after that I’ll test the temperature effects on a full 2D transistor. I also still need to put the website changes live.

Devlog #8

This update was mostly about cleaning things up.

Firstly, I went through the whole site with a checklist of things that make websites feel cheap or fake. I took out the gradients, made the rounded pill-shaped buttons and badges square, and replaced an emoji warning icon with a normal one. Then I added a Terms page and a Privacy page, linked at the bottom of the side panel. The privacy page explains what the app does and doesn’t track, which isn’t much. All of this was to remove any “ALL AI” msgs ive received

I also changed the license. AtomSim used to be MIT, which meant anyone could take it and sell it. Now it’s CC BY-NC 4.0, so people can still use it, share it and change it, as long as they credit me and don’t make money off it.

Every font on the site is now Poppins, and it’s bundled with the app so it doesn’t have to load from Google.

After that I reread all the text on the site and in the README and fixed anything that sounded robotic. That included a few curly quotes and one sentence that sounded like a press release. I also rewrote the line explaining “provenance” so it just says what it means.

All of that is live on the site now.

Next up is making the atom move. If you mix two states, the electron cloud sloshes back and forth at the exact frequency of the light the atom gives off. I’ve planned it out and I’m starting on it next. I also wrote down a big list of other ideas for later.

#Devlog 5

After the security pass, I mostly worked on new features.

I added a Browse section, so you can look through six part categories without knowing a part number. Then I built a compare tray. You pin up to four parts from anywhere on the site and see them side by side.

I moved the site to Vercel with a database in Singapore. A small job now runs every night and records prices, so later I can show how a part’s price changes over time.

Search had some problems. The free data source I use started returning broken results, so I wrote up what was going wrong and reported it to the people who run it. I also stopped showing results that had nothing to do with what you searched, and I made the “part not found” message more clear. Now it says when a distributor just didn’t answer, instead of saying the part doesn’t exist. You can also sort results by price now.

The biggest new thing is BOM check. You paste in your whole parts list, or load a spreadsheet, and it prices every line at the quantity you need. It tells you which lines it skipped and why, and you can share the checked list as a link.

Part pages now show each distributor’s bulk pricing. There’s also a quantity box, so you see what you’d actually pay for 250 parts and not just one. If you click a part from your BOM, that box already has your quantity in it.

Next, I made a list of 60 more ideas and started building them.

Devlog #19

The speed and robustness numbers are now saved on the scoreboard. On the first 8 benchmarks, my solver takes about 1.6x less time per bias point than DEVSIM. I also added a test that reads the README and fails if the README claims anything the data doesn’t back up (I hate getting 100% vibe code assumptions on my readme btw).

I renamed a lot of variables across the code (to pass the 30% ai rule that im apparently violating) to shorter names. That kind of change can break the tests if some of the variables reference each other across multiple files, so I checked that python turns the old code and the new code into exactly the same instructions. Thankfully it did.

I also moved all the settings into one file. Things like how many tries the solver gets, how small the mesh can get, and the server limits used to be scattered across about 20 files. I checked that every single value stayed exactly the same after the move. I also deleted the last few leftover comments.

Then I pushed everything. The tests ran on three Python versions, and 2,723 of 2,724 passed. The one that failed was a browser test on Python 3.11 that waited too long for the page to load. The same test passed on the other two versions, so it’s probably just a slow test machine, but I’m going to rerun it to make sure.

My laptop ran out of memory again, which stopped me from finishing the type hints in the tests. That’s next, once I’m not running a bunch of other stuff at the same time.

Devlog #18

The robustness runs are almost done. Robustness checks a simple concept, if I give the solver a device cold, with no warm-up, does it actually finish? I ran 200 test cases through my solver and through DEVSIM, each in a few different setups.

The robustness numbers aren’t final yet. One DEVSIM result is still missing. The first time my laptop ran out of memory, and the second time it went to sleep overnight, so it’s running again now.

I also found out DEVSIM acts much differently depending on how many CPU threads it gets. With only one, some solves failed or took forever which was kinda interesting to see.

On the cleanup side, I turned on the strictest type checking across the whole project and fixed what it found. Every color on the website now comes from one file. I also deleted a bunch of old files nobody used and cut the README down.

Devlog #17

I restarted the scoreboard runs, and before looking/mentioning any of the results I checked my own setup for DEVSIM. That showed a few bugs on my side. My starting guess for the voltage inside the device did a log of zero on heavily doped chips, so DEVSIM crashed INSTANTLY. I also wasn’t giving it enough steps to settle on some devices. I fixed both, because it wouldn’t be fair to count my mistakes as DEVSIM’s.

I also cleaned up the code, I tried to ship all progress so far but there was just too much AI (guilty) so I am working on redoing the python, css and javascript code again mainly from scratch.

(The image shows all the values from the DDSim tests)

Devlog #16

Now that DDSim is live, my next goal is to make it better than DEVSIM, a free, open-source simulator a lot of people already use. “Better” doesn’t count unless I can measure it, so I planned out the next 11 stages of the project, and the first one is a scoreboard.

The scoreboard runs both simulators on the same set of devices and compares them in four ways: how often each one finishes a solve without crashing, how accurate the answers are, how fast they run, and what each one can do at all. Some of these runs take hours, and my laptop ran out of memory partway through, so I paused them. I’ll post the results once they’re done, even the parts where DEVSIM is better than mine.

While building the accuracy check, I found a bug in my own math. Sometimes it reported numbers that didn’t make physical sense, so now it throws those out instead of trusting them.

I also went through all the style files for the website. They’re about a third smaller now, and I checked that the page still looks exactly the same.

Then I found a small bug that had been there all along. The little “i” buttons that explain each setting were supposed to turn blue when you hover over them, but a different style rule was overriding it.

Last, I cleaned up the README again. The pictures are centered now, I took out the GIF, and I rewrote some of the text so it reads more naturally.

Devlog #15

DDSim is FINALLY deployed and live! You can try it at ddsim.fly.dev

Getting it online took one extra step. The cheap shared server was too slow: the hardest transistor solve takes about 50 seconds on my laptop and would have taken around 7 minutes there. That’s past the 5-minute limit I set, so it would have been stopped every time. I moved it to a faster server, and now it finishes in under a minute.

Once it was up, I found a bug. When every contact on a transistor was at the same voltage, the picture still drew current flowing through it. That’s impossible, because with no voltage difference nothing moves. I fixed it, and now the page says “no current flows” instead of showing an empty plot with no explanation.

Then I rewrote the README from scratch. The old one was over 500 lines and way too dense. The new one is about 200 lines, mostly screenshots from the live site plus a few tables, so someone can see what the project does in a couple of minutes.

While doing that, I caught a mistake. One number in my results table didn’t match the graph right next to it. I reran the full simulation, which took 20 minutes, and fixed the table so it matches.

Last, I took the deployment files out of the public code. Anyone who downloads it gets everything they need to run it on their own computer, but not the setup for putting it online.

Next up, I might be thinking of getting a custom name for this simulator and my other atom simulator. If anyone knows where I can get free domains, lmk in the comments

Devlog #14

Since then, most of my work has been getting DDSim ready for other people to use.

First I cleaned up the controls. Some sliders and number boxes let you pick values that made the solver fail, which just showed up as a red error. I went through the diode, the MOS capacitor, the transistor and the draw-your-own device and found the range where each setting actually works. The sliders now stay inside those ranges, so a beginner can’t break things by accident.

Then I cleaned up the code. I deleted about 2,400 lines of comments that just repeated what the code already said and kept the ones that explain something nessessary.

Next came the writing. The site has about 40 short articles that explain the physics, and a lot of them sounded stiff, so I rewrote all of them. I did the same for the project docs, and on the way I found a few places where the docs no longer matched what the code does, so I fixed those too.

Now I’m working on putting it online. I picked Fly.io to host it, and I’m hoping to get a free custom name. Since anyone will be able to use it, I’m adding some safety limits first. Only a couple of solves can run at the same time, old results get cleared out after a while, and a solve that runs too long gets stopped with a message explaining why. I tested each limit by breaking it on purpose to make sure the test catches it.

It isn’t live yet, but it’s close!

[lazy pic, i dont wanna open server again :( ]

Devlog #13

This one is all about the page itself. The physics didn’t change, but you’ll notice everything else did.

I rebuilt the whole look from scratch. The old version was only friendly if you already knew semiconductors, and I want someone who has never heard of a diode to open it and get somewhere. Now it opens by asking you to pick a device: a diode, a MOS capacitor, a transistor, or draw your own. Each one comes with a sentence or two on what it is. Every number and switch has a little “i” next to it that explains it, and an empty plot tells you what it’s waiting for instead of sitting blank.

Drawing your own device used to happen in a tiny box off to the side. Now it gets the whole screen. Some layers are so thin they basically disappeared, so I stretch the picture up and down until you can see them, and a label says when it’s stretched. Doped areas get a soft color so you can tell them apart.

I also changed the font a couple of times. It started in a terminal style that felt cold. I tried one replacement and ended on Poppins, which just feels warmer.

My favorite change is in the runs panel. It used to list your old runs as text, like “doping 1e17.” Now every solve saves a little picture of its own curve, and they all share the same scale, so you can see at a glance how each change moved the result.

I switched the license to CC BY-NC so that it still stays technically open source but I own intellectual property for commercial use. Anyone can use it and change it for free, as long as they credit me and don’t sell it.

A bit of AI usage in the frontend i will agree but not overkill in terms of it.

Devlog #12

Last time I left off with a transistor sitting on oxide that would not solve. I think ive fixed it. The silicon body had no contact touching it anywhere, so the solver had no idea what voltage that body should sit at. There is no single right answer, so it just wanders. That is not a bug I can fix, it is the physics of the thing, so now the simulator refuses that drawing up front and says why instead of grinding away at it.

Then I went hunting for every other way someone could break it. I wrote something that tries every combination of settings the page can send and watched what fell over. A few things did: A gate metal with a work function no real metal has. Surface scattering asked for on a 1D device, which has no surface to scatter off. A shape so thin the grid ends up dividing by zero. All of them now get refused before the solve starts, with a sentence saying what to change.

A few smaller ones. The device picture was drawn half a grid cell off, which threw off the line you drag across it to read values. That same line returned nothing at all where silicon meets oxide. And the explanations could load out of order and show you the wrong one.

I think now i should wrap the version 1 of the project and finish polishing the frontend considering stardance is getting over soon.

another lazy code pic btw cause i dont wanna open the servers again

Devlog #11

Since the last devlog, you can draw your own 2D devices, not just stack layers in a line.

You draw rectangles of silicon and oxide, paint doping onto them, and place metal contacts along the edges. The simulator builds a grid that fits your drawing and solves it. Before it solves, it checks for mistakes and tells you what’s wrong in plain words: a piece of silicon with no contact touching it, a gate sitting right on silicon, or a shape too small for the grid to see. To make sure drawing works, I redrew the MOS capacitor and the transistor I already had and checked that they give the same answers. The capacitor matched almost exactly and the transistor was within about 1%.

Testing it in a real browser caught two bugs. One made every solve hang forever. The other made the picture of the device grow every time it redrew on high resolution screens. Both seem to be fixed now but I’ll be on the lookout for similar bugs.

Then I tried something new, a transistor sitting on a layer of oxide, the way a lot of modern chips are built. It won’t solve yet. I narrowed it down to the oxide underneath the silicon, and I’m still wondering how breaks things. More on that next time.

random picture cause im too lazy to start the servers again

Devlog #10

Since the last devlog, the simulator has gone from explaining things to letting you play with them.

First, you can now compare runs. Every time you solve, the curve stays on the plot, so you can change one thing and see exactly what moved. The diode also got live sliders. Drag the doping or voltage and the answer updates while you drag. The 2D devices like the MOSFET are too slow for that, so I added a quick mode that uses a rougher grid. It’s a little less accurate, and I wrote down exactly how much.

Then I built five guided lessons: a diode sitting at rest, a diode with voltage on it, a MOS capacitor, a transistor turning on, and what goes wrong when transistors get really small. Each lesson walks you through experiments step by step. The important part is that every claim a lesson makes is checked by a test against the solver I developed as part of the project. For example: if a lesson says “the current goes up,” a test runs it and makes sure it actually does.

The biggest addition is a device builder. You stack layers of doped silicon however you want, and the simulator solves whatever you made. You can also save a design and load it again later.

I agree I used AI for the frontend but I did not go VERY heavy on it. Only to build upon the frontend base I coded

Devlog #9

Since my last devlog, my solver and DEVSIM have started to cooperate. All ten benchmark devices match, the MOSFETs included, so the physics phase is done. THANK THE LORD

Now I’m working on the part I care about most personally, which is making the simulator teach. The browser used to be a wall of knobs and plots with no explanation. Now every knob and every plot has a small “i” button. Click it and a drawer slides out with a plain explanation first, then the real equations for anyone who wants to go deeper.

I wrote 35 of these explanations covering the physics, how the solver works, the devices, and how to read each plot. Then I checked them against the code. One credited the diodes with an accuracy number that actually belonged to a different device. Another claimed that one failed point in a sweep doesn’t ruin the rest, but the code stops at the first failure.

The equations turned out to be hard to figure. The markdown reader treated the backslashes inside the math as its own escape characters and deleted them, so 92 bits of spacing and notation came out messed up. Now I pull the math out before the markdown step and put it back after.

I also bundled the math and markdown libraries into the project, so the page works with no internet.

Next up are band diagrams, which show the energy levels electrons can sit at. The page will draw them straight from the solved device.

Devlog #8

Really tired today. Just ran a bunch of tests today and got a bunch of values ill sort through tomorrow.

Devlog #7

Since my last devlog I have been teaching DEVSIM to run the same physics my own solver runs. Before this it was on a stripped down model set, so the two codes had similar geometry and nothing about mobility. Now it runs the real thing: doping dependent mobility, surface scattering at the oxide, velocity saturation, and proper Fermi-Dirac statistics.

Getting there meant three more small lies.

DEVSIM will easily chain a derivative through one kind of model and silently return zero for another. No error, no warning. My solver just diverged on the first step. It took a dump of every derivative on the device to see a column of exact zeros where numbers should have been.

Then a field magnitude written as a square root of a square. Mathematically, sounds good but numerically it produces a nan wherever the field is exactly zero, which in a neutral chunk of silicon is nearly every edge.

Then the surface mobility. I was refreshing it on every pass, forever. That is not a converging loop, that is two numbers chasing each other. The gate walk climbed to 0.50 V and then refused 0.55 V at every step size I gave it, down to a tenth of a millivolt. A failure that ignores step size is not a step size problem. I gave the refresh a stopping rule and re-ran it. Same answer to the last digit, just reachable now.

The 1 micron device now agrees between the two codes to under 3.3 percent at low drain and under 1.3 percent at high drain, across four decades of current.

The remaining blocker is not code. My browser is holding 15 of the machine’s 16 GB.

Devlog #6

Im not going to say much this devlog. I hate Github CI errors with a passion and everybody that creates software relates.

Devlog #5

Since the license was added, all my time has gone into one stubborn thing, that is getting DEVSIM simulator, to produce trustworthy MOSFET curves.

It has been a long journey of small lies the application tells you. DEVSIM’s solve doesn’t take a device argument, so it solves everything you’ve ever built in that process at once. I was building one device per curve and leaving them around, so the second curve was dragging a finished device along with it and ruining the shared error check. Deleting each device when its curve finishes fixed a whole family of weird failures.

Then I found the equilibrium solve was starting from all zeros, which on this device is 0.6 V off. I supply it from charge neutrality now. Same final output but far less trouble getting there.

2 of my own ideas turned out wrong and got reverted, but I wrote the measurements rather than dropping them. Capping the solver’s pass budget moved the current by 0.4%. Pinning the math library to one thread made a four second step take three minutes. Big Ouch.

Currently, the 1 micron transfer curve at 50 mV of drain runs end to end and confirms with my simulator to within 0.23% above threshold. The 1 V curve still stalls at 0.4 V of gate, and I checked it properly rather than simply loosening the tolerance, because it turns out DEVSIM isn’t converging there at all.

My own code, for contrast, does the same curve in 4.6 seconds.