FIX: mos_sim example

[daquintero]

I have run:

python examples/mos_sim.py

I get:

---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
Cell In[55], line 61
     57     assert idd < 117e-6
     60 if __name__ == "__main__":
---> 61     main()

Cell In[55], line 49, in main()
     46     return
     48 # Run the simulation!
---> 49 results = MosDcopSim.run(opts)
     51 # Get the transistor drain current
     52 idd = abs(results["op"].data["i(v.xtop.vvdc)"])

File c:\users\dario\documents\phd\software\hdl21\hdl21\sim\data.py:392, in Sim.run(self, opts)
    390 def run(self, opts: Optional[vsp.SimOptions] = None) -> vsp.SimResultUnion:
    391     """Invoke simulation via `vlsirtools.spice`."""
--> 392     return run(self, opts=opts)

File c:\users\dario\documents\phd\software\hdl21\hdl21\sim\data.py:411, in run(inp, opts)
    406 from .to_proto import to_proto
    408 # FIXME: I don't see anything that relied on this, but whatever it was, has gotta go
    409 # inp.Tb.props.set("simulator", opts.simulator.value)
--> 411 return vsp.sim(inp=to_proto(inp), opts=opts)

File ~\mambaforge\lib\site-packages\vlsirtools\spice\spice.py:124, in sim(inp, opts)
    122 with concurrent.futures.ThreadPoolExecutor() as executor:
    123     futures = [executor.submit(cls.sim, i, opts) for i in inp]
--> 124     results = [
    125         future.result() for future in concurrent.futures.as_completed(futures)
    126     ]
    128 # For the sequence of inputs case, return the sequence of results that came back
    129 if not inp_is_a_single_sim:

File ~\mambaforge\lib\site-packages\vlsirtools\spice\spice.py:125, in <listcomp>(.0)
    122 with concurrent.futures.ThreadPoolExecutor() as executor:
    123     futures = [executor.submit(cls.sim, i, opts) for i in inp]
    124     results = [
--> 125         future.result() for future in concurrent.futures.as_completed(futures)
    126     ]
    128 # For the sequence of inputs case, return the sequence of results that came back
    129 if not inp_is_a_single_sim:

File ~\mambaforge\lib\concurrent\futures\_base.py:451, in Future.result(self, timeout)
    449     raise CancelledError()
    450 elif self._state == FINISHED:
--> 451     return self.__get_result()
    453 self._condition.wait(timeout)
    455 if self._state in [CANCELLED, CANCELLED_AND_NOTIFIED]:

File ~\mambaforge\lib\concurrent\futures\_base.py:403, in Future.__get_result(self)
    401 if self._exception:
    402     try:
--> 403         raise self._exception
    404     finally:
    405         # Break a reference cycle with the exception in self._exception
    406         self = None

File ~\mambaforge\lib\concurrent\futures\thread.py:58, in _WorkItem.run(self)
     55     return
     57 try:
---> 58     result = self.fn(*self.args, **self.kwargs)
     59 except BaseException as exc:
     60     self.future.set_exception(exc)

File ~\mambaforge\lib\site-packages\vlsirtools\spice\base.py:59, in Sim.sim(cls, inp, opts)
     57 try:
     58     sim.setup()
---> 59     results = sim.run()
     60 finally:
     61     sim.cleanup()

File ~\mambaforge\lib\site-packages\vlsirtools\spice\ngspice.py:73, in NGSpiceSim.run(self)
     69 self.run_sim_process()
     71 # Handle stdout and stderr as needed
     72 # Parse up the results
---> 73 return self.parse_results()

File ~\mambaforge\lib\site-packages\vlsirtools\spice\ngspice.py:87, in NGSpiceSim.parse_results(self)
     84 def parse_results(self) -> SimResult:
     85     """# Parse output data"""
---> 87     data = parse_nutbin(self.open("netlist.raw", "rb"))
     88     an_type_dispatch = dict(
     89         ac=self.parse_ac,
     90         dc=self.parse_dc,
   (...)
     93         noise=self.parse_noise,
     94     )
     95     an_name_dispatch = dict(
     96         op="Plotname: Operating Point\n",
     97         dc="Plotname: DC Analysis\n",
   (...)
    100         noise="FIXME! do we still want this setup?",
    101     )

File ~\mambaforge\lib\site-packages\vlsirtools\spice\ngspice.py:281, in parse_nutbin(f)
    279     if len(plotname) == 0:
    280         break
--> 281     an = parse_nutbin_analysis(f, plotname)
    282     rv[an.analysis_name] = an
    283 return rv

File ~\mambaforge\lib\site-packages\vlsirtools\spice\ngspice.py:328, in parse_nutbin_analysis(f, plotname)
    325 # Read the binary data, should look like the following:
    326 # Binary: \n[Binary data]
    327 binary_line = f.readline().decode("ascii")
--> 328 assert binary_line == "Binary:\n"
    329 # Data is big endian
    330 bin_data = np.fromfile(
    331     f, dtype=np.dtype(nptype).newbyteorder("<"), count=num_vars * num_pts
    332 )

AssertionError:

I've sorted it and will submit a PR iab.

[daquintero]

I have also been thinking about the source of this issue. I think it is important to mention that I am running this from Windows with a mamba install ngspice installation. I was running the latest versions of both vlsir and hdl21 tools.

When I printed binary_line on line 327 in vlsir ngspice on the exception above it gave me: 'Values:\r\n' which makes me think the assertion was out of date at some point. Same thing for all the analysis_names in this exception. At the top is the printed data of line 117 of the same file.

{'Plotname: Operating Point\r\n': NutBinAnalysis(analysis_name='Plotname: Operating Point\r\n', numtype=<NumType.REAL: 'real'>, data={'v(xtop.vdc_p)': array([1.39804065e-76]), 'i(v.xtop.vvdc)': array([1.39804329e-76])}, units={'v(xtop.vdc_p)': <Units.VOLTS: 'voltage'>, 'i(v.xtop.vvdc)': <Units.AMPS: 'current'>})}
Plotname: Operating Point

Traceback (most recent call last):
  File "C:\Users\dario\Documents\phd\software\Hdl21\examples\mos_sim.py", line 61, in <module>
    main()
  File "C:\Users\dario\Documents\phd\software\Hdl21\examples\mos_sim.py", line 49, in main
    results = MosDcopSim.run(opts)
  File "c:\users\dario\documents\phd\software\hdl21\hdl21\sim\data.py", line 392, in run
    return run(self, opts=opts)
  File "c:\users\dario\documents\phd\software\hdl21\hdl21\sim\data.py", line 411, in run
    return vsp.sim(inp=to_proto(inp), opts=opts)
  File "c:\users\dario\documents\phd\software\vlsir\vlsirtools\vlsirtools\spice\spice.py", line 124, in sim
    results = [
  File "c:\users\dario\documents\phd\software\vlsir\vlsirtools\vlsirtools\spice\spice.py", line 125, in <listcomp>
    future.result() for future in concurrent.futures.as_completed(futures)
  File "C:\Users\dario\mambaforge\lib\concurrent\futures\_base.py", line 451, in result
    return self.__get_result()
  File "C:\Users\dario\mambaforge\lib\concurrent\futures\_base.py", line 403, in __get_result
    raise self._exception
  File "C:\Users\dario\mambaforge\lib\concurrent\futures\thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "c:\users\dario\documents\phd\software\vlsir\vlsirtools\vlsirtools\spice\base.py", line 59, in sim
    results = sim.run()
  File "c:\users\dario\documents\phd\software\vlsir\vlsirtools\vlsirtools\spice\ngspice.py", line 73, in run
    return self.parse_results()
  File "c:\users\dario\documents\phd\software\vlsir\vlsirtools\vlsirtools\spice\ngspice.py", line 123, in parse_results
    raise RuntimeError(msg)
RuntimeError: Cannot read results for analysis op {
  analysis_name: "op"
}

Then I ran:

$ python examples/mos_sim.py
Traceback (most recent call last):
  File "C:\Users\dario\Documents\phd\software\Hdl21\examples\mos_sim.py", line 61, in <module>
    main()
  File "C:\Users\dario\Documents\phd\software\Hdl21\examples\mos_sim.py", line 56, in main
    assert idd > 115e-76
AssertionError
(base)

This makes me think the sample_pdk was maybe out of date. After I changed the assertion parameters on the simulation, it worked fine.

So I think that somehow in one of the new versions, maybe the ngspice vlsirtool directive got

[daquintero]

I have begun writing a transient example, and from comparing the RAW files to the bin_data parsed file in the vlsir ngspice parse_nutbin_analysis, I think I've found out that I think maybe the file data output changed from however it was encoded before. This version I am running is the mamba install ngspice so I wonder if it's a version issue.

Reading the github actions, I think maybe this is uncaught in the testing as it is now. Potentially something that would solve the issue is if we had a conda recepie to also mantain some form of version control with the simulation tools and related. Maybe you have it somewhere I haven't found. Might try downgrading my ngspice to check.

This is the ngspice version I have on Windows. I might try Linux if it comes down to this being the reason, which I would not be surprised, but maybe could have implications in terms of file output parsing.

ngspice -v

******
** ngspice-38 : Circuit level simulation program
** The U. C. Berkeley CAD Group
** Copyright 1985-1994, Regents of the University of California.
** Copyright 2001-2022, The ngspice team.
** Please get your ngspice manual from http://ngspice.sourceforge.net/docs.html
** Please file your bug-reports at http://ngspice.sourceforge.net/bugrep.html
** Creation Date: Nov  1 2022   12:41:43
******

[daquintero]

Ok I've found the issue finally. No surprise. It has to do with the installation of ngpsice. I've just run the mos_sim example with your latest repo in ngspice 40 in the latest IIC-OSIC-TOOLS ubuntu docker version and worked fine as you had it, so is not a problem with your configuration. I will test if ngspice 40 works fine in Windows as the mamba installation is version 38.

EDIT: I cba dealing with Windows so I'm moving all my development to Linux as I should have done some time ago.

I will keep the issue open because maybe we should think about version control of the toolchain so this helps others.

[dan-fritchman]

Yeah. One thing we do not control especially well are the version requirements on external tools - particularly simulators.
This should be a VLSIR (tools) thing, and is now: https://github.com/Vlsir/Vlsir/issues/78.
That'd be a great first issue to tackle!