Advice needed on how to test circuit board bypass capacitor placement

[BrianSedgewick]

First of all, please excuse that I am very much a beginner so I probably don't know how to even phrase my problem properly.

I have two circuit boards that implement the same netlist. I have authored these in KiCad, so I am able to export a HyperLynx file for each of them. The boards differ in the bypass capacitor placements. I would like to quantify which placement is "better" and by how much and/or evaluate whether the worse placement would likely still "work".

My first question is whether OpenEMS is even the right tool to do this.

Assuming yes to that, how do I set up the problem for OpenEMS? On the board I have two communicating chips, let's say it's an FPGA and a DDR3L memory.

I think what I need to do is create a signal on one trace loop and measure how much of it is coupled onto an adjacent trace loop, with the expectation that a tighter bypass results in less coupling. Proceeding with that assumption, how do I tell OpenEMS that an output pin on a component is a driver that interacts with the nearest ground and power pins?

[LubomirJagos]

Hi, since openEMS is general FDTD solver for electromagnetics you can use it to investigate for trace coupling. I'm not expert but was thinking about this example, so I can assist you, since you will be working with little more complex 3D structures as they are PCB traces of existing circuit.
I haven't worked with hyperlynx format for openEMS but I would suggest different more visual approach for your problem and that will be usage of KiCAD -> FreeCAD export -> my addon for FreeCAD to define openEMS simulation and generate simulation script.

So ideal and fast workflow is as following:
1. use fcad_pcb plugin from here https://github.com/realthunder/fcad_pcb to import KiCAD PCB into FreeCAD, it's easy, fast and what I tried it imports everything right (pcb traces as solid, vias, substrate and everything else what you need)
2. then use my addon for FreeCAD to defined openEMS simulation https://github.com/LubomirJagos/FreeCAD-OpenEMS-Export
3. since you are going work with digital signals you need excitation signal for your ports, there is possibility for openEMS to define user function for electric excitation signal, it's using fparser http://warp.povusers.org/FunctionParser/fparser.html there is table on index page of functions, I tried once to define digital signal, you would be using function "if(A,B,C)" multiple nested or something similar but definitely it's possible to define any digital signal but it requires little playing around
4. run simulation and evaluate S12 params or S13, or whatever Sxy, where x is number of source port and y is number of sink port that way you will get power transfer between ports what is your coupling coefficient

It's not that hard, if your schematic is not secret you can post it here and I can look at that and try it if it will give you expected results. This is great example and I hoped that in future somebody will try this.

[kbocheltree]

Lubomir, thank you for your post. I am building a small circuit to fit in a wildlife dart with a short PCB antenna (1/10 a wavelength) and using Kicad for the layout. I wanted to use openEMS for the modelling of the antenna and was having issues determining the best way to go from a new version of Kicad to openEMS (pcbmodelgen and pcb-rnd only work with old versions) . I like your conversion path and will try that. I can run with the antenna layed out alone to get the antenna impedance, then can add the designed matching network to verify that it works properly.

Is your path better for running in WIndows or Linux? I have both environments readily available, just wanted to know the preferred path.

[biergaizi]

since you are going work with digital signals you need excitation signal for your ports, there is possibility for openEMS to define user function for electric excitation signal, it's using fparser http://warp.povusers.org/FunctionParser/fparser.html there is table on index page of functions, I tried once to define digital signal, you would be using function "if(A,B,C)" multiple nested or something similar but definitely it's possible to define any digital signal but it requires little playing around

I think defining custom excitations in openEMS is usually not worthwhile, especially for newcomers who are not yet familiar with openEMS. Instead, I recommend using openEMS as a "virtual VNA" for S-parameter extraction, once the S-parameters are obtained, further analysis can be done in a pre-existing standard lumped circuit simulator like Qucs just like any RF devices. Although this adds a analysis second step, but it means you can skip all the peculiarities of creating the specific measurements you want in openEMS in favor of tools you're already familiar with (or at least tools that other people have already familiar with numerous guides). Furthermore, if I recall correctly, digital signals usually have sharp edges that would exacerbate numerical errors, meanwhile a Gaussian excitation is more computational friendly.

Previously, I read from a blog post that one experimenter wanted to study the distortion of a digital signal in a coax-to-microtrip transition, so a great amount of time on derivation the correct equations for correct excitation of a band-width limited Heaviside step. Due to various difficulties, that project didn't go really far. If the decision was made to only use openEMS as a "virtual VNA" for S-parameter extraction, that experimenter may have gone further by spending on time on other problems.

For example, for evaluating the impedance of the Power Distribution Network design in a circuit board, usually the two-port impedance measurement method is used - the PCB is connected in parallel to ground in the circuit, a signal is injected from VNA port 1 into a pair of VCC/GND test pads, and received from VNA port 2 from another pair of VCC/GND test pads. Because the power planes have very low impedances, most energy goes into the ground and only a tiny signal appears at port 2. From this S21 measurement, the complex impedance of the PCB's power distribution network can be calculated, from which everything else becomes possible in a standard circuit simulator. Since this real-world-device workflow is documented in multiple textbooks and blog posts - I recommend the textbook Principles of Power Integrity for PDN Design by Larry D. Smith and Eric Bogatin, which covers much of this subject - it can be easily recreated in an openEMS simulation.

To study chip decoupling, for example, you can create the excitation port near the location of the power input side of the PCB, and create another port near the VCC/GND pads of a chip footprint. Running the simulation would reveal its S-parameters - with the transfer function already at hand everything else becomes possible with a circuit simulator, even without directly modeling the signals involved in openEMS.

One major limitation currently exists - the simulator does not support lumped inductance, only lumped capacitance and resistance (there's an experimental patch for lumped inductance, so inductance may be supported in a future release). But for power distribution network analysis at high frequency, it's not a major issue - the inductance of the SMD ceramic decoupling capacitor mostly comes from its physical size, so I think modeling a 0603 rectangular box would approximate the parasitic inductance of capacitors well enough.

[0xCoto]

there's an experimental patch for lumped inductance, so inductance may be supported in a future release

In case anyone's curious, this has been extensively tested and is in close agreement with commercial software (both the inductance and the new RLC-series implementation - @thliebig I would suggest merging the CSXCAD and openEMS PRs). I've been applying the patches to my local builds and never ran into an issue.

[thliebig]

@0xCoto I'm happy to hear your feedback. My plan is to release v0.0.36 as it currently is (latest download is an RC-2) and then start pulling all this nice new improvements. I think this makes sense?
If nobody finds any more issues with v0.0.36 then I guess I should call it done soon? Let me know...

[0xCoto]

Sounds good!