Feedback Request: Real Time PCB Signal Analysis / Extraction, Simulation, SI...the hard bits you want solved

[matt.berggren]

Hi Fusion 360 Electronics Community,

Im looking for feedback on something we have been planning / discussing and I would appreciate if you have any thoughts or input on the subject.  Specifically, with the addition of the Ansys solver with Fusion 360 what is evident is that there is much greater value to be had with R(Z0), L, C, G extraction of signals in PCB including terminations than simply analyzing signal geometry.  Specifically, one might suspect that the new Layer Stack manager, the addition of myriad layer materials, etc. all point in the direction of Signal Integrity of another sort.  However as we plan for that, we are also evaluating the use of PCB Rules and Constraints a trying to aim one stone to tackle multiple challenges.  

The tldr; is that we would like to provide the means to pivot from the realm of CAD, which is geometry-oriented (eg clearance, width, length) to workflow based on circuit extraction.  This was demonstrated somewhat in Jorge’s recent series on the SI Extension but it has longer tendrils than he intimated in his 4th video in this series.  A few things we are looking at which you could help influence:

Schematic extraction from PCB - ie gathering the results of the method of moments analysis and producing the series / parallel paths as schematic parts wired correctly (think simulation “sheet” versus source schematic).  This would be intended to both:

1. Visualize how the track segments’ transmission lines connect and their respective values as ‘parts’ - this could include single-ended and differential signals, capacitive coupling, impedance anomalies, diff pair inductive loop properties, etc; and 
2. Enable the use of that same schematic for a more pared down analysis of those transmission lines with options to experiment with terminations and filters like you could if SPICE had the extracted detail

This extraction seems to us to be something of a missing piece which, though we are not intending to go anywhere near S-Parameter simulation; we could perform NEXT/FEXT cross talk and model behavior at the signal transitions that seems (at this point) to be better suited to a schematic view of the extracted sub circuit with sim sources and transmission lines in which series/parallel terminations could be added, properties of the source modified and simulations run and re-run until a good, reasonable expectation of a reliable circuit resulted.

Other pivots like replacing a distance input with an intended Tpd  or loop inductance target are also on the table…another example would be to swap a clearance for capacitance, etc. However, before we blaze too much of a trail on what is surely to be a long road, it is valuable to gain insights from you on what sorts of analysis you use today, what you would want to see in this vein, where you give up and just build a prototype because it’s either faster or cheaper to do it than to try and work out the result without instruments, etc.  Also we’d like to unpack any rules of thumb you’d like to see included in such capability that would make the broader community of EEs and Designers more effective and speed the work along.  

I have to stress, limitations exist.  For example, simply modeling a lossy transmission line is possible in SPICE but bundled lossy lines is something we depend on Ansys for and if that is your bread and butter, you would want Ansys as a part of your workflow (ngspice is amazing but hspice and Ansys’ solvers are second to none…we dont aim to replace that but we do want to know the right mix of real-time or near real-time ‘insights’ versus something that warrants a deeper solve, which might interest you).  

With this, we have a heavy emphasis on workflow and as-yet, our feeling is ‘SPICE is great but almost unbearably complicated owing to a lot more emphasis on the core and less on the interface’.  Some tools appear to do a better job but then lack the corresponding consideration of the ‘whole product’ in their workflow.  The idea of placing .params statements in the schematic is an outmoded concept we are just all tired of repeating (many of the team have been there, done that) and we’d rather consider better visualization, interactivity, ease of use, with a yet-unheard of connection into the schematic and PCB you using for production (again, an example would be the ability to model cutoffs and synchronize those back to the core schematic without losing the simulation schematic derived from it).  

Shortly I will drop some images into the thread but I want to open this up for a dialog between the product team and the users to gain some feedback before spending the cycles on as-yet, non-approved, non-committed mock-ups of ideas rolling around in our heads.

All and any feedback is welcome and we look forward to hearing what might make the community more productive!

Best regards,

Matt - Autodesk

[erik.buerV95QJ]

I haven't tested the SI tool yet, so bear this in mind. I had some time to write down my initial thoughts now, so sorry if some issues are already solved in the new module. I will in the coming weeks, just haven't gotten around to it yet.

The main thing I need in Fusion for high-speed design is an improvement of the delay tuning tools.

To my knowledge there is no way of incorporating propagation delay through vias in fusion, meaning any bus with delay timing requirements must follow the same layers and transitions, which is a severe limitation when dealing with DDRx memory layout.  We also really need the ability to apply propagation delay constraints/rules across buses.

If you want to go for a more targeted ruleset, then maybe have some more datasheet-related rules. For instance instead of having impedance rules, maybe have setup and hold time rules. Then a simulation would show if data sent along the line is within the actual limits of the receiver chip. For this, you can incorporate IBIS data on the transmitter. In the IBIS files, chip drivers are modeled as lumped components, so they could fit with your spice approach.

I'm surprised that s-parameter extraction is not something you will pursue with the SI module.
The way we would go about validating some particular transmission line designed in Fusion360 is by using our VNA to measure it.
If we cannot compare the extracted model (spice in this case) with our measurements then I don't see the use of the model extraction (for high-speed design).

I guess the spice extraction could be used for simulating I2C lines, to ensure the line capacitance is sufficient, and that the pullup is dimensioned appropriately. However, I2C is not particularly "high speed", and could easily be debugged by just probing the traces with an oscilloscope.

All in all, I am happy to see some progress on the more complex parts of PCB design.

Hopefully, more timing-related tools are also included in the module, making it more complete.

-Erik