@Ryan R: If you are reading into magic from GDS, then the easiest way is either use

gds flatten true

which automatically flattens trivially simple cells (cells with < 10 shapes in them), or by the

gds flatglob <string>

where you can give it a glob-style matching string, if there is a syntactical commonality in the names of the cells you want to flatten (like the

$

in the middle of the name).

@Tim Edwards one strange thing is happening -- the pcells which are from klayout are NOT getting flattened ...below are the ones which are getting extracted also.. and precheck is complaining like below ; LAYOUT CHECK FAILED: The GDS layout for user_analog_project_wrapper doesn't match the provided structural netlist. Mismatching modules are: ['via_new' 'via_new$12' 'via_new$14' 'via_new$16' 'via_new$18' 'via_new$19' 'via_new$2' 'via_new$21' 'via_new$22' 'via_new$24' 'via_new$26' 'via_new$27' 'via_new$3' 'via_new$4' 'via_new$6' 'via_new$8' 'via_new$9' 'via_new11'] {{NETLIST CONSISTENCY CHECK FAILED}} user_analog_project_wrapper netlist failed 1 consistency check(s): ['LAYOUT']. {{CONSISTENCY CHECK FAILED}} The user netlist and the top netlist are not valid.

I'm guessing from the picture and the explanation that klayout generates these via cells which contain, it looks like, only the cut layer itself; so magic perhaps complains about these and that's why you have to flatten them to get magic to extract the cell? And then the pre-check complains because there are via cells in the GDS that aren't in the SPICE? That should definitely be flagged as a precheck error. There is never any guarantee that a SPICE netlist is an exact match for the layout hierarchy, and pre-check should never fail a design because all cells in GDS don't appear in SPICE. Assuming I understand the problem correctly.

Yes abosolutely correct. BUt i am not able to flattem them..any other option??

Yell at the Efabless people who wrote the precheck and insist that a design can't be rejected for that reason---and that I said so.

@Stefan Schippers , any way to include any dummy via to the spice subcircuit

@Ryan R: Let me be clear---There is no way that those vias can appear in a netlist, because SPICE doesn't represent contacts. In a horribly inefficient, ungainly way, you could theoretically represent every contact as a zero-ohm resistor or zero-volt voltage source, but that's lunacy. The real problem here is that the Efabless precheck developers have made a dreadful mistake and need to fix it. I have raised the issue privately within the company's internal slack workspace, and I will let you know if I can make progress on it there. But meanwhile, you need to do something like submit a helpdesk ticket with Efabless so that all the right people will be staring at your issue and (I hope) trying to fix it.

@Tim Edwards - seems i have found a solution in magic itself - we are testing it now,, flatten -nolabels... Was not in any case being solved in spice netlist...!! Thanks

I believe that the top structural test is a requirement that all the cells at the top level of the

user_project_wrapper

or

user_analog_project_wrapper

are same between the layout and the verilog/spice level. If you have via cells in your top level now, you might consider adding a level where your current top level is encapsulated. For example, if currently you have,

user_analog_project_wrapper
  macro_1
  macro_2
  via_1
  via_2

Add a level to get

user_analog_project_wrapper
  user_analog_proj_example
    macro_1
    macro_2
    via_1
    via_2

Of course, you'd need to create the corresponding

user_analog_proj_example

verilog.

@Amro Tork - found the issue last time.