Hi @Tim Edwards @Leo Moser Is CACE able to perform operations on GDS? I'm assuming only mag is supported

CACE only has the function of preparing a netlist from layout. For that, it can take either a GDS or .mag file. The GDS could be more problematic if the layout wasn't made originally in magic. I have not incorporated a method for specifying a Tcl script for reading GDS with options tailored for the specific design.

That would be nice, something like a "layout source" entry on the .txt or a "scripts" directory on the "path" to put tcls with well-defined names, as "extractor-gds.tcl" or something like that. If I make a cace testbench with the extracted netlist directly routed in a

code.sym

, I think it should work also.

Just note that I have to be somewhat careful about allowing user scripts to run in CACE, because it can allow for a "bad actor" to post an open source circuit with malicious code in a script. I don't really expect that, but it's worth putting in some "safety rails". In principle, though, yes, it would be a user script to replace the default script that CACE runs when reading GDS for extraction (or DRC, LVS, etc.).

@Tim Edwards, the information security aspect is a huge can of worms that probably can't be solved with a software engineer's mindset ("in case of inconsistency, add an abstraction layer. Never mind that nearly everything that matters is a side effect."). Trying to think about a way how to make a solution to this huge and principal problem pay my rent in my Asylum for Homeless Intellectuals …

I haven't consider the security, but it's true. I think the some of the stuff on extra-be-checks from @Mitch Bailey could be useful here. Defining flatglob patterns used on the gds extraction and doing some cleaning to avoid code injection should be feasible.. but that's a lot of work, plus more python dependencies. Also, how many

gds <settings>

or

cif <setting>

should be put as flags to read any gds? I don't know. Doing specific gds reading routines for each pdk could be possible. I think the easiest solution is to just put manually the .spice on a common directory if you are not using magic for drawing the layout, and make

cace

use that directory to set the

ngspice

environment.

@aquiles viza: That solution should work. CACE does a check for "out-of-date" netlists; unless you set "force netlist regeneration" in the settings, it will not touch a netlist that is more recent than the layout. So you should be able to read GDS and extract manually and put the netlist in

netlist/layout/

or

netlist/rcx/

, and CACE should run simulations without any problem. The physical parameters section, such as area measurement, are not going to work, so just avoid those.