[Libre-soc-bugs] [Bug 526] create dry-run 180nm GDS-II files for IMEC

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=526

--- Comment #43 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #42)
> (In reply to Luke Kenneth Casson Leighton from comment #35)
> > (In reply to Cole Poirier from comment #34)
> > 
> > > I had this problem yesterday JP. Try manually running `git submodule update
> > > --init --recursive`,
> > 
> > hm git submodule --init --remote is supposed to be enough, and is in
> > build_full.sh
> > 
> > i will try it and add it if necessary.
> 
>   OK. Did that plus a git pull and ran build_full.sh, and it worked.

excellent.  there are some errors but rhey do not stop the build (still a
corona error on vss and vdd for example)

>   I have the json file. My question now is, could you elaborate on
>   it's structure (give a small example perhaps) about it's semantic?

well, it was originally just pads.instances (the list of lists)

however the change to niolib i had to "construct" the new format including the
IoPad.SOUTH by parsing additional information from the pinmux json file that,
really, should be done *by* rhe pinmux program.

if given a choice i would simply use that exact format (the niolib list of
lists IOPadsSpec), and get the pinmux program to generate that.

now, one other useful idea: have the entire chipconf constructed by json.

stored as a dict, every key of the toplevel dict is a name of a property in the
chipconf class.

this is easy to do with setattr:

jd = json.load()
cconf = ChipConf()
for k, v in jd.items():
   setattr(cconf, k, v)

although that is messy, it can be hidden behind cconf.update(jd)

-- 
You are receiving this mail because:
You are on the CC list for the bug.