stineje/CharLib

Robustness - specify a single yml file

Closed this issue · 10 comments

CharLib seems to crash and not produce any output in case there is any problem in any of the cells given. Additionally it handles all cells sequentially which takes a lot of time. Therefore I would prefer to generate an individual .yml file and run it on just on a single .yml file, and to combine the liberty files of all the cells into a single library at the end in my flow.
CharLib currently does not seem to allow me to specify a single .yml file, so the only workaround I can see is to dynamically generate a new directory for each cell and to place the .yml files into those directories, to make sure CharLib doesn't accidently run over additional cell's yml files. But I would prefer if CharLib could be extended to support specifying a single .yml file on the commandline. It's nice to have the option to be able to specify a whole directory, so I wouldn't recommend to remove that option. What's your opinion on it?

I like this idea. In general I want Charlib to be as easy to use as possible, and this seems like a great way to make it behave more like one might expect it to.

Multithreaded parsing would also probably be a worthwhile improvement

At the moment it seems like CharLib can utilize 2 CPU cores, I think we could go to a higher utilization with multi-processing, to run several SPICE simulations for a single cell at the same time. I would suggest to control that parallelism with commandline parameters charlib run -j 8 . And please whenever you add parallelism, make sure that the resulting outputs are reproducible (that any race-conditions between the parallel running tasks cannot have any effect on the output)

At the moment it seems like CharLib can utilize 2 CPU cores, I think we could go to a higher utilization with multi-processing, to run several SPICE simulations for a single cell at the same time.

SPICE simulations are already multithreaded. I've tested it with up to 24 cores simultaneously. This is controlled via the multithreaded flag in your config file, which is on by default.

If you're seeing runs that aren't making full utilization of your system, that should be considered a bug. How did you determine that Charlib is only using 2 cores on your system?

Reading through this issue again, I think (?) we already have the part of the functionality you're looking for. It just isn't documented well as it ought to be.

CharLib allows you to specify cell entries as file paths instead of dictionaries of keys and values. So in my toplevel yaml file (the idea being that this is the single source of configuration defaults for the whole cell library), perhaps I have the following cells:

# In toplevel library config
cells:
    AND2X1:
        netlist:    osu350_spice_temp/AND2X1.sp
        area:       128
        inputs:     [A,B]
        outputs:    ['Y']
        functions:  [Y=A&B]
    OR2X1:
        netlist:    osu350_spice_temp/OR2X1.sp
        area:       128
        inputs:     [A,B]
        outputs:    ['Y']
        functions:  [Y=A|B]

Alternatively, if I wanted to store cell configs with cell spice files instead, I could have separate and2x1.yaml and or2x1.yaml files, with the content of all three files something like this:

# In toplevel library config
cells: 
  AND2X1: and2x1.yaml
  OR2X1: or2x1.yaml
# In and2x1.yaml
netlist:    osu350_spice_temp/AND2X1.sp
area:       128
inputs:     [A,B]
outputs:    ['Y']
functions:  [Y=A&B]
# In or2x1.yaml
netlist:    osu350_spice_temp/OR2X1.sp
area:       128
inputs:     [A,B]
outputs:    ['Y']
functions:  [Y=A|B]

CharLib does recursive glob searching within the library directory to find cell yaml files, so you can store them with your cell spice files (or anywhere under the library directory) if you want. If you want to leave a particular cell out of the characterization run you're doing, just don't include it under the cells list.

Bringing things back around to your initial issue description, you identified several problems we ought to solve. I'm going to split these out into separate issues:

  • CharLib shouldn't just crash and exit when a single cell has a problem (#35 )
  • Splitting cell configurations into individual yaml files needs to be better documented (slightly improved by #34 )
  • If you have multiple valid CharLib configuration yaml files in your library directory, CharLib should allow you to specify which one to use instead of just using the first valid one it finds (#36 )
  • A feature to combine multiple characterization runs into one liberty file would be pretty handy
  • There may be a bug in multithreaded execution (this remains unclear; please provide steps to replicate)

I think it's obvious how to split the cell configurations into individual yaml files.
I prefer to handle the multithreading configuration on the commandline (enabling/disabling), since the datafiles should be reproducible.
Yes, I would suggest to support a command like charlib run AND2.yml to specify a single yaml file to be used.
Multiple parallel runs of charlib in the same directory on different yml files should not interfere with each other -> we might want to specify the output liberty filename on the commandline? But the default of "results/<lib_name>.lib" is fine for me at the moment.
lctime from librecell already provides a liberty merging tool that we are using already to merge the liberty files from individual cells into a whole library.

I appreciate the feedback on splitting out cell configs. Glad that's clear.

You listed a couple more features there:

  • Specify (or perhaps filter with e.g. regex?) cells from CLI (#37 )
  • Specify .lib name from CLI (#38 )

Closing this issue. Please direct comments to the task-specific issues linked.

It seems to me this bug was accidently closed without the solution being implemented yet? I can't see a way to specify a single .yml yet.

It seems to me this bug was accidently closed without the solution being implemented yet? I can't see a way to specify a single .yml yet.

I didn't want to close it as wontfix, but GH only gives you the option of Resolved or Wontfix. Currently it's not yet fixed, but no longer tracked by this issue, as our discussion covered many different issues; please see #36.