dragonphy wants adk/multivt regardless of full_chip default view

[steveri]

Our default for full_chip build is currently to use adk view stdview, as specified in full_chip/construct.py:

  adk_name = 'tsmc16'
  adk_view = 'stdview'

Unfortunately, this breaks the final LVS because our separately-built dragonphy uses LVT cells that do not exist in stdview

% calibre -lvs ...
Error: No matching ".SUBCKT" statement for "DEL100D1BWP16P90LVT" ...
Error: No matching ".SUBCKT" statement for "DEL200D1BWP16P90LVT" ...
Error: No matching ".SUBCKT" statement for "BUFFSKND1BWP16P90LVT" ...
...

Seems like there should be an easy/obvious solution to this problem, but I have not yet been able to discover it. Among the ideas I have come up with so far:

• change full_chip/construct.py to use multivt for everything, so the needed libraries will be available when/if needed

full_chip/construct.py:
  < adk_name = 'tsmc16'
  < adk_view = 'stdview'
  ----------------------
  < adk_name = 'tsmc16'
  > adk_view = 'multivt'

• use pre_extend_commands to change lvs inputs/adk link from stdview to multivt

full_chip/construct.py:
  lvs.pre_extend_commands( [
    'pushd inputs; unlink adk; ln -s ../../12-tsmc16/multivt adk; popd'
  ] )

• make a new custom-lvs node that links multivt instead of stdview

• parameterize adk for lvs node, e.g. similar to what was done with lvs_hcells_file, included below for comparison...

mflowgen/steps/mentor-calibre-lvs/lvs.runset.template:
    *lvsHCellsFile: ${lvs_hcells_file}
  - *cmnV2LVS_SPICEIncFiles: inputs/adk/*.cdl inputs/*.spi inputs/*.sp
  + *cmnV2LVS_SPICEIncFiles: ${adk}/*.cdl     inputs/*.spi inputs/*.sp

mflowgen/steps/mentor-calibre-lvs/configure.yml:
     lvs_hcells_file: ""
  +  lvs_adk            : "inputs/adk"

full_chip/construct.py:
    'lvs_hcells_file'   : 'inputs/adk/hcells.inc',
  + 'lvs_adk'           : 'inputs/adk/../multivt',

For now I'm using option 1, since it was the easiest to do initially. Looking at it now, I'm thinking the final option in the list (lvs_adk parameter) is probably the best, as it kind of goes along with existing flow -- lvs.runset.template is already fairly heavily parameterized.

Thoughts?

[steveri]

Update: I really liked the parameterization option, it's simple and clean, and I have filed an mflowgen git pull to go ahead and implement it, see mflowgen/mflowgen#94