seantbaker / systematic-design-notebooks Goto Github PK

If we built this out, we'd have some glue to tie together the Notebook and a matching Schematic. My initial thought is that we do our "design" in the Notebook, using lookup tables, then when we're done sizing everything we run some SKILL / Python+SkillBridge to update the devices in an associated schematic.

Some thoughts:

• I think this lends itself to the idea of having schematic templates, i.e. there's a schematic for [ CS / SF / CG ] amplifiers, diff amps, current mirrors, etc. with pre-defined names for each device, and that schematic gets updated via some code that we run from the Notebook
• Maybe a good place to prototype this is with plain netlists that I can simulate with Xyce?

It would be helpful to have a list of dependencies, ideally in something like a requirements.txt file, so they can be automatically installed.

The list I have so far is:

scipy
pandas

I haven't gotten everything running yet, so I'm not sure if that's the complete list.

Also, I think there's a dependency on ../../Book-on-gm-ID-design-main/starter_kit. I tried grabbing it from: https://github.com/jarvis94/Gm-ID-starter-kit

But then I hit this error:

ValueError: setting an array element with a sequence. The requested array has an inhomogeneous shape after 1 dimensions. The detected shape was (18,) + inhomogeneous part.

It's still a bunch of code in the Notebooks to setup color maps for plots, so I should bundle that together into a function.

Same story with plotting lines - at the least, we probably want to bundle together the line and scatter plot functions, so users have an easy way to just plot a line with or without markers.

Right now, if a user doesn't pass in a string or dict for the col_formats argument, we use a default dictionary of {column name: formatting}.

But, what if users want to format a specific column, and don't care much about the rest? We shouldn't toss out all of the other default formats, like we do now; we should only override the format(s) supplied by the user.

This is a tricky one - once we apply .style() to a DataFrame, we can't transpose it.

But if we transpose it first, we can't apply .format() the way we would if it weren't transposed, because .format() is looking for column header names which have become indices after transposing.

Maybe the way to do this is to have a separate pretty_table_transpose function, where we convert the arguments we'd pass into .format() into something that can be applied to indices, like a pd.IndexSlice() object.