From 628dcccfb94da339db5361f8cbab668bed0b9dee Mon Sep 17 00:00:00 2001 From: Bdale Garbee Date: Mon, 4 Aug 2025 23:05:14 -0600 Subject: [PATCH] add some notes from Tibor --- docs/Tibor_on_DRC | 40 +++++++ docs/Tibor_on_EMS | 269 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 309 insertions(+) create mode 100644 docs/Tibor_on_DRC create mode 100644 docs/Tibor_on_EMS diff --git a/docs/Tibor_on_DRC b/docs/Tibor_on_DRC new file mode 100644 index 0000000..dcd5071 --- /dev/null +++ b/docs/Tibor_on_DRC @@ -0,0 +1,40 @@ + Igor2: if I want to add a check in our Makefile goo to ensure 'c r' + shows all nets connected and no shorts before "taping out" data to an + assembler, can I do that from the command line and if so how? + bdale, you could run pcb-rnd with the batch hid, issue the action + that {c r} runs and grep in the log that goes to stdout I believe + bdale, http://repo.hu/projects/pcb-rnd/keys.html, search for Optimize + rats nest, there's a row for {c r} + And I always have my job here. So that helps. + it runs a sequence of actions + so the pattern is something like this: + echo 'sequence of actions' | pcb-rnd --gui batch | grep Congratulations + + Igor2: got the additional checks added to our Makefile. when all is + well, it runs quickly. when there's a short, completion takes a long + time due to the mincut stuff. is there an easy way to turn that off + in a batch hid invocation? + yes + whether the mincut algo runs or not depends on a config setting + all config settings are totally equal, handled by the same mechanism + (this is in code, not HID dependent) + you can change config node values from config files or from the + command line + in your use case a command line change is probably the best strategy, + that's done with -c + something like this + -c plugins/mincut/enable=0 + with the default priorities, a command line -c change is highest + priority, happily overwriting other values coming from whatever + other config role you may have + technique to quickly look up config node paths: run pcb-rnd in GUI, + {i c p} to invoke the preferences dialog, switch to config tree tab, + use the filter to search (I entered mincut and the only relevant + subtree came out quickly) - click on the node of interest on the + left side, you get a bunch of info on the right side, including full + node path + +Optimize rats nest + Atomic(Save); DeleteRats(AllRats); Atomic(Restore); AddRats(AllRats); Atomic(Close) + + diff --git a/docs/Tibor_on_EMS b/docs/Tibor_on_EMS new file mode 100644 index 0000000..fecd70a --- /dev/null +++ b/docs/Tibor_on_EMS @@ -0,0 +1,269 @@ + about openems: + you may recall pcb-rnd has an exporter there + we have spent considerable time to figure how to use openems, some ~6 years ago + I am not sure how much experience you have with it, did you use it in the past, to simulate microstrips, and now it's only just a technical issue on missing packages or are you new to the simulation stuff with openems? + I have no experience with OpenEMS at all. in the past, I had access to some truly astoundingly useful EM simulation tools that were stupidly expensive. + so I have low expectations, honestly + ok + so, here's the problem: + but I also have a to-do list that includes experimenting with a bunch of different antennas for future products, and a tool that I could use for helping me "think" about some alternative geometries before I start making little proto boards to analyze could be helpful + after years of research and a failed attempt (that spanned more than a year, together with Evan), I believe openems is not usable to signal integrity related simulations out of the box + I also checked a bunch of other options, including other fdtd implementations and one FEM implementation + (sparselizard) + the problem seems to be generic + the guys who wrote these software are generally academic people, which makes sense since the topic needs very deep understanding of Maxwell's equations in differential equation forms then understanding on how these differential equations can be discretized in one way or another + sure + so what they typically end up with is a multiphysics simulator _engine_ + which means it can potentially simulate a lot of different things + I admit that I haven't even thought about having aspirations of doing high speed digital design analysis, which is why I was using such tools a couple decades ago. That seems like a very steep hill to climb with a Free Software tool + but in reality they typically don't provide frontends or at least not frontends usable by practical; EEs + ok + sure, I have good news too + I just first need to explain "current state" and what I have found over the past years of research + so the situation is basically this: + ok. I'll go grab another beverage and be back in a minute .. keep typing + there are multiple engines that in theory could be good for PCB simulation + after more research I figured some are really not good for PCB simulation, OpenEMS included + (I will share details a bit later, after the grand picture) + then there'd be the "application" layer put over the engine, and that seems to be missing + so to use the engine for anything, you, the end user, the EE, first need to undertsand pretty much all the physics, a large bunch of maths, then your specific application, and then the given implementation + we did this with Evan for OpenEMS for antennas + we did have good results in that domain, even the head developer of OpenEMS complimented our code, he said the mesher I wrote for pcb-rnd procudes better quality mesh than their own matlab stuff + so it's not like we totally failed... it's really just that during the process I got to learn how this whole business works, and my conclusion was: + to do any practical signal integrity simulation with existing open source simulators, you basically need to learn so much about all the math and simulation algorithms that compares to the knowledge you would need to write your own + because of the missing applicaiton layer + when I realised this years ago, I tried to talk OpenEMS guys to get into a collaboration so we would end up with an usable application layer + but they didn't seem to undertsand the problem + I think their target audience at the time were happy, mostly doing antennas and related microwave filters and stuff, so there were a lot of examples for those + now, about the technical details: + OpenEMS by default comes with its own GUI CAD and heavily relies on matlab (or octave) too + so it's a huge monster because of dependencies and the intended way of using it is pretty much that you take your board, look at the part of interest and just remodel that in their GUI (or in matlab) + yes, the build-dependency list ends up installing hundreds of Debian packages in the build chroot .. it's .. stunning + which is, again, sort of works with antennas, so their exisiting users are not sad about that + the other, even bigger technical problem: + right, which is sort of what I intend, since I want to investigate different geometries before I actually start a PCB design + OpenEMS works only with rectangular mesh + which again, is good for antennas and microwave stuff + but if you have real traces on real PCBs, like dram lines and gigabit ethernet and such, it becomes a limiting factor + because you will have tons of 45 degree lines and arcs + I can see that + that has two results: + 1. you will have an insanely dense mesh, so simulation time converging to infinite + yeah, we did some crazy traces trying to precisely match signal delays on old digital oscilloscope board designs + 2. you will have a staircasing effect (the literature calls it that), which you won't realize + so + you will definitely get some result out of it + but that result will most likely have nothing to do with physical reality + and we are back to square one: to troubleshoot that, you'd need to have knowledge so deep that you could write your own sim + so these were the bad news + ;-) + I don't say you shouldn't package openems, in its current form I assume it's really useful for antennas + but I would like to share a not-yet-public alternative path + ok + after figuring OpenEMS didn't work for the above reasons initially, the first thing I did was my usual brute force approach with the biggest hammer in hand + I took the code, forked it into tinyopenems end started to remove all the unnecessary cruft, including the GUI and matlab/octave + I did get far + but the more I looked at the remaining code, the more I figured I have to re-evaluate my whole approach + because what remains, the fdtd solver itself, is damn small + tehcnically the fdtd solver is the only thing you really really need + so I went on and looked at the literature + and I figured it's not totally hopeless to write our own fdtd solver, one that could use non-rectangular mesh (so would be meningful for PCBs and signal integrity) + my problem was that the differential equations were over my head + so I tried to get help with that + plan A guy failed + plan B guy failed + plan C guy failed + not because the problem is hard, they just didn't have enough interest/time + ok + however, now that I am winding down my working hours on Ringdove, and not yet back in the industry (I plan to go back maybe in September) + I have some extra time + so I decided to give it a go + I've been doing this the past 3 weeks + by now I think I fully understand the physics, the maths, including all those differential equation things and the discretization too + I also understand a lot of the side sotries you are probably not aware of yet (but as an OpenEMS user you would need to be), like absorber boundary conditions + however.... + my normal approach would be to write an engine and the applications geared to signal integrity + as this is a huge gap in the open sourcemarket + yes + I looked at what kicad was doing on this some 3 years ago and it was clear they were not getting anywhere + but lately I am very disappointed with the community around Ringdove and I relaized that if I do this as a normal open source subproject, originally I called it emsim-rnd, it would be something that at most 5 people would ever use + so it would be pretty much something for /dev/null + which would be a waste, considering how hard/expensive it is to get a full grip on this problem and how hard to come up with a working solution (engine+applications), I mean there were open source efforts on fdtd/mom/fem solvers since the 90s and we still have nothing usable + considering all this, I decided to try something different + I am building a SaaS, targeting low end users (hobbyists, small companies) + not a lot of circuit board designers even understand the need, much less have the motivation to figure out what to do, much less are inspired to try and write code + it's not without precedence, the guy who wrote sparselizard (an open source FEM multi-physics thing) made a startup, selling applications as SaaS, but they are targeting the big playes + well + I think a lot of small time EEs do understand the need + I mean they do have the need, but there are not good tools out there + ok + at the moment I already have working code for the bare bone simulation in 2d, with a working PML (an absorber boundary condition), but everyhting is rectangular still + but I also have collected a bunch of literature on how to do non-rectangular + I had a lot of ideas on the way, and abotu 80% of those turned out to be not unique in the sense I later found research papers describing them + so I think I am on the good track + and funnily, this even connects to our jlc discussion a bit: + if I want to make this useful for the generic public, it can't be pcb-rnd-specific + it will work from gerbers, but gerbers obviously don't have netlists + fortunately there's a file format originally invetned for automated flying-probe testers, ipc-356d, pcb-rnd can export it, kicad too, and as far as I know pretty much every commercial package too (even the low end ones) + which means we have a viable path + so gerber for the geometry and ipc-356d for the netlist metadata? + so imagine a SaaS "in the cloud", you give it the gerbers, the ipc-356d, and you choose an application, like "what's the impedance of the network called dram_data4 in respect to gnd" and it knows what to do + yup + interesting + ipc-356d is a bit more than just a bare netlist, it has geometry + sure, even without reading the spec, I can imagine what it must do + I mean it points to specific coordinates where the given net is accessible for the probe, exposed copper + right + now this whole plan hinges on a few things + 1. administrative/legal part (I don't have a company so I can't do this alone) -> solved (I teamed up with aron, he does have a company with relevant profile) + 2. having the knowledge on the math/sim side (I am on it and so far, to my greatest surprise I do make rather good progress) + 3. having knowledge of the actual application - by now I think I mostly have it, I mean I am also designing high speed stuff sometimes and I am definitely near people designing a lot of high speed stuff + 4. having tools to verify simulation against reality -> last year I bought a VNA that's good enough for this and JLC is cheap to produce test boards + so I think everything is aligned, this could work + why I am telling you all this: I think you are exactly my target audience + (and you mentioned you'd start an effort on OpenEMS for signal integrity, which I believe would either end up as afailure or would end up reproducing this effort mostly, I mean on the understanding maths and simulation algorithms and developing applications over the engine) + are you generally interested in this project? + hrm. I don't think I actually meant to say something about signal integrity, I'm actually interested mostly in analyzing RF circuit structures. But I know others who really want a good signal integrity tool, so no matter. + I'm quite interested. whether what you want to build is actually well aligned with my personal needs is unclear to me + you mentioned microstrip IIRC + yes + so what would be your question to the simulator with a microstrop line? + mostly concerned about impedance management + and how's using a simulator better than using a closed form formula deduced analitically that gives you the width of the trace and clearance? + I've had some odd results with RF traces to antennas and/or PCB antenna structures in the past. I'm not entirely sure how I want to tackle figuring things out, just have some idea. + for the simple cases, no difference + and what's not the simple case? + but for some of the purchased chip antennas, I have aspirations of being able to include part or all of their structures in the analysis. may be lunacy. + you are correct, though, that much of the openems interest I'm aware of in the Debian user community seems to be about antenna design + so I think these are pretty much orthogonal + well, as far as I understand you wouldn't do that with fdtd + I mean + if you trust your microstrip geometry and you don't doubt the PCB implements it correctly + I should just package openems more or less as is and have it available again in Debian, then maybe pay a lot more attention to what you're working on for other needs + then all youknow about an antenna is maybe a smith chart + fair + so you'd do that kind of simulation with spice + you'd use fdtd if you knew the internal construction of the antenna + I lost plenty of hair working with spice over the years. + all the fine patterns on the chip, all the materials used + yes + that way you could 3d model the antenna internals and give it to fdtd + jacobsen is pretty open with such info, others are not + hehe, yes, spice is ... well... + anyway + you wouldn't simulate the antenna together with the microstrip line + all of their parts are well behaved, though, so they're like the least intersting folks to work with + I mean in fdtd + right + because the antenna has features in the range of micrometers, the microstrip in the range of mm + so tehcnically you could of course put them together, but then if you do the mesh, and you get the time stepping you need to do, you'd figure a single simulation would take a few centuries + heh + was always a problem with high precision simulations + (this is exactly the application part I was talking about) + well, it's nost just precision + I could tell you stores about "stealing" cycles from everyone's workstations overnight. some other day. + it's that fdtd has some constraints + hehe + fdtd is simply not very good if you have features that spans magnitudes spatially or in time + in theory you can handle it, but in practice it will require pretty much infinite computation power + ah, ok + the problem is, end users won't know this, because they are rightfully not interested in simulation algorithms or internals.... + for this specific example, my application idea in my system is this: + you put in your board, name your antenna feed network and there's an application that runs fdtd and spits out a spice model + which is probably a trnasmission line model with the parameters extracted from the PCB plus maybe some parasites also added + then you take your antenna's datasheet and create a spice model for your antenna (from smith charts or eqivalent circuit) + then you can put this all together with spice and it can very easily tell you how well they are matched or what inductances/capacitances you need in your PI to match the antenna + (at my very reduced time daytime job I am doing such antenna matching, not in simulation but on real boards, these days) + this path doesn't give you radiation angle characteristics of the antenna on your board + but I think it would give you smith chart of the whole system and a logmag chart so you'd see the attenuation at different frequencies, in dB + that would be pretty cool + (at the moment, and since forever, the missing part of this is the code that extract the transmission line from your pcb - and that's exactly the signal integrity thing I am targeting) + btw, that "since forever" is like this: last year I staretd to read back geda-user@ archives, from the earliest times, 2002, to undertsand more on how it worked before I started to use it + I remember you talking about taht + and this topic came up like once a year as early as 2005 + especially when gnucap's Al Davis joined the list + he had the "spice" simulator, but nobody had the numeric simulation to extract the parameters from PCB + (and Al severely understimated how complicated it is, so he seemingly assumed all the time it's just a question of someone sitting down and coding maybe 2 weekends) + not sure, but I think I started using gEDA around 2006 myself + me too + recovering from the wildfire in 2013, I lost a lot of timestamps on old stuff I had to restore from backups + (then I remember I had this discussion with Al around 2016, not knowing about the earlier discussions, when I was first looking at hooking up pcb-rnd withsims) + but the oldest symbol I created for gschem in my database is 10 Oct 2006 + nice! + about signal integrity vs. antenna: + the overlap is in your microstrop + (for some reason I alays have that i/o typo) + you get the geometry from the closed form formula + but it assumes "infinite ground plane" which you clearly won't have + so you revert to "large enough" ground plane + right + which is what? 3W..6W on each side? but nobody really knows + then the chip antenna will be at the edge of the board, almost always + a huge issue for us in our products over the years has been finding GPS antennas that aren't designed for minimum ground plane geometry bigger than the narrow axis of our boards + so your stripline will be near the edge too + so what if there's no FR4 but air in 4W distance on one side? + detuning a patch antenna by being on too small a groundplane is one of those things a lot of designers never really figure out + exactly + and these are really signal integrity questions in my dictionary + having an 50 ohm feed line is an antenna question + I think I paid for my 8753D in the first 2 hours of use one evening + cool! + (VNA I bought after the fire to replace the older equipment I lost) + that was the other reason I told you about my secret + at a later phase of the project, before it goes full public, you could help + ok + like comparing physical boards to simulation results with your VNA would be a big help + I knowingly "cheat" a lot of RF traces due to trying to fit things on really small PCBs + since your designs tend to be open source, it would also be a great demo when it goes public and I need to start marketing it: I'll need some proof that simulation result converges to real board measurements + often counting on short trace length to minimize the effects .. I "get away with" a lot of stuff, and my designs often exceed mfg specs for various parts which is very satisfying + yeah, exactly the singal integrity issu I am after! short, but how short? + "it depends" (tm) + so you have this with an antenna feed line, but the very same thing happens with a dram line + sure + one of the things openems doesn't do: + animation + because for mathematicians it just doesn't make sense + I used to have fun trying to explain to new college hires that they'd made a big mistake skipping all the RF courses at Uni and thinking they could design computers... + you get your s-params, what else would you need?! + but then as a PCB designed, imagine you could run a simulation and look at wave propagation and you would actually see where exactly reflections happen + that would be youtube-worthy, for sure + so you get your numeric parameters, you see you lose 20% of your power to reflections, but then you actually want to try to fix that..... + nah, I mean it's actually practical! + that was my other problem with openems + yeahj I agree on RF courses for high speed digital + imagine your antenna feed line, with the PI components + those are typically SMD capacitors and inductors + yes + the SMD pad is not exactly as wide as your 50 ohm trace + how much does it matter? + like maybe if you remove one of 3 matching parts, you get a bit less freedom on your matching but you save so much reflections that it is worth - but then which parallel one to remove, the one closed to the antenna or the one further from it? + heh .. if I had a nickle for every time I'd forced the RF trace to be the width of the passive stub component pad and just tolerated the off-perfect-impedance consequence to avoid points of reflection... + where "art" becomes a relevant word + with openems you get a numeric answer on how much reflections you had, but nothing about where that happened + hehe + so that's where animation becomes important + saves you a lot of re-iteration of simulations + simulation can take long, sometimes hours + I know + btw, yet another little technical detail: + which is why in the past I've spent a lot of time with a Dremel multi-tool and some copper-clad board prototyping different geometries, often crudely + OpenEMS, Sparselizard and two others I checked, last time ran only on CPU; with fdtd especially, running on GPU is told to be a big boost + sure + I can see that + I happen to have a librayr I wrote 2 years ago, that makes me able to run stuff on GPU + I recently put up a Jellyfin server in the house to store videos and such, and was amused that they called for a fairly cheap Intel GPU as the optimal engine for hw acceleration of mpeg transcoding + I originally did this hoping I could speed up the poly clipping lib with it, but then I figured I can't because how poly clipping works is not optimal for GPU + hehe + yeah, video encoding and parallel compression is a good task for GPU + I bought such a card, haven't made time to install it yet + my son is about fed up with his Plex setup, I'm trying to drag him away to Jellyfin since it's actually open + I am working on 10+ years old thrown-out GPUs for these experiments (but they are fast enough for me for now) + sounds good! + if my project takes off, I plan to just rent GPU time from some big player, amazon, google, whoever + (but in the beginning I can host the "cloud" at home) + heh. not some ISA-bus PC full of ancient GPU cards? [lol] + lol, no + if there are signs of paying users, I'd obviously buy a dedicated machine for this + ok .. all interesting stuff. keep me in the loop. for now, it's time for me to take a shower and move to doing some actual work today. + ok, thanks for listening! + have fun! -- 2.47.2