IOfile refactor

[mkosunen]

Should address issues:
#16
#18
Ping @sporrasm @vlahtin

[sporrasm]

Fixed #22 by refactoring print-file reading away from the spice_iofile, since it is not related to any single IO, but all of them. This may break other things, I guess.

Also, fix #16

[vlahtin]

Tried AC; does not work yet. The reason is that on line 180, the io type is read and it uses tran_analysis_name always for event based results (even though AC can also use those).

Need to implement some method to extract whether or not the simulation was actually AC or Transient. This information is atleast given to spice_simcmd, so have to figure out some method to get it here as well. Did not have time today to debug this further, but leaving this as documentaiton if someone else has the time to figure this out before me.

[sporrasm]

I see. The way I see it is that we three options

1. Either use the same analysis name for all simulations, which is probably not a good idea
2. Infer output file name from properties of spice_iofile. For example, I think AC simulations should have iotype='event' and datatype='complex'
3. Detect which simulation type we are running and infer output file name based on that, which is the same what @vlahtin proposed above.

To me option 1 is the worst and option 2 is not very explicit and hence might be difficult to debug. It probably makes sense to detect the simulation type and infer analysis name from there directly. This will mean that running two different simulations on the same netlist will not work, but I don't think that has been supported for a long time anyway.

[vlahtin]

da34a25 should fix the aforementioned problem.

[sporrasm]

Using libpsf to read in transient and AC. Tested with transient. This now has the downside that sparam, etc, still use psf_utils, which we should probably get rid of, if libpsf is superior to psf_utils. See #25

@vlahtin can you test and see if it is faster now? Please remember to pip3 install --user libpsf

[sporrasm]

Tested also AC with a nonsense example. At least it doesn't crash.

We should probably aim to make release tests for all analysis types to aid with the testing.

[sporrasm]

Okay, tested this together with @MiikkaMaki. transient, dc, ac, sp, noise, pss and pac simulations seem all to work. Of course, further testing would always be nice to catch possible uncaught bugs (mention @vlahtin if you have the time).

iofile reading operation should now be simulator agnostic once again, which is good news.

[vlahtin]

Added the option to select either binary parsing (using libpsf) or ascii parsing (using psf_utils) when use_psf=True. Also made it so, that psf_utils is used for all other analyses (when use_psf is True), as the output file size is not expected to grow as significantly as transient, thus yielding reliable results with reasonable speed.

This change came as libpsf has problems with memory leakage with large output file sizes, and unavailable in some linux distributions. The psf_utils is however quite slow, so if large file sizes in transient are expected, either libpsf or print file parsing may be the best option, which should now be available all according to user selection

@MiikkaMaki can you test that your SP, noise, PSS, PAC testbench still works?

[vlahtin]

Hi,
happened to do something that has not been previously done with Spice. Lets add the fix to that to this merge as well:
#29

Please test that as well before merge. It works in my special case, but if someone has another case with sample IOs, please try that.

[mkosunen]

Notes for the release:As the lint-based code reformat policy has been added to v1.14_RC already, I suggest that you do octopus merge (and some tests) by merging v1.14_RC to this branch and re-test before merging this to v1.14_RC, if not done already.

[mkosunen]

Note for the future developments: If there is a need for a iofiletype where the first column is frequency, (for example in AC-analysis) then the most consistent way to handle this is to add io type 'freq' with an assumption that the data in the other columns are complex. All the other formats address the problem how the time in the first columns is interpreted.

Opened #31 for this, does not need to be addressed now.

Also: AC response is not a 'signal' as in sense of conveying data from a block to another and thus not strictly an IO. To me it seems that it should be handled with some kind of 'extract' rather than IO's. Freq type signal would be for example an OFDM frame.

[mkosunen]

Further notes fro the release: To reduce the number of conflicts at merge, regrdless of which way it is done first, you may run
black -l 80 --check --diff --color <list of python files>
to check the syntax differences and then correct them with
black -l 80 <list of python files>