I'm Ali Elshorbagy and I'm working at Mabrains, I ...
# xyce
a
I'm Ali Elshorbagy and I'm working at Mabrains, I made a small testcase to document a weird behaviour that i found when using .data inside xyce. I'm simply doing dc sweep on sky130 nfet transistor on different widths and lengths. I have 2 parameters for width and length to sweep on them. I found an unexpected behaviour. Initial value for width and length parameters affect solution values.  Normal behaviour during simulation is initial values will be replaced by values given in .data line but surprisingly i found that initial values for parameters affect the results. In this git repo i have 2 netlists (netlist1.net and netlist2.net) exactly the same but initial value for width and length parameters are different. When i invoke Xyce to run those two netlists i have a completely different results @User https://github.com/mabrains/xyce_sky130/tree/main/testcases/Xyce_data_behaviour
e
@Ali Elshorbagy thanks for this report. I have verified that this incorrect behavior is happening in Xyce. I’ll open an internal bug on the issue.
You probably figured this out; but the second netlist fails many of the DC sweep points.
I have entered an issue in our internal bug tracker now. My guess is that this will be (yet again) a problem with “scale”. That is a relatively new feature that seems pretty easy to break.
And in fact, I’ve fixed at least two other “scale” related bugs since I started participating on the Sky130 slack channel.
OK. Here is the issue, or at least part of it. I think that this is a binning problem. Xyce isn’t adjusting the bins when the L,W parameters are updated.
a
@Eric Keiter appreciate all the help.
e
@Amro Tork no problem. The binning issue that I mentioned may be a headache to fix, but we’ll do it.
The problem is that Xyce currently does all the binning during parsing and throws away models it doesn’t need. So, later, once the simulation is up and running, if it needs to update L,W, it no longer has enough information to re-bin the models.
So, the fix will have to involve refactoring that a bit.
a
@Eric Keiter appreciate all the help