@Stefan Schippers is there any functionality in xschem, which permits to validate device parameters ? I mean to check if ie. W of a transistor is within certain range Wmin and Wmax

@Krzysztof Herman Currently not, this information should be added to the device symbol and checked when modifying attributes. If there is interest I can work on that.

Here at IHP we had some discussions on that and this feature would prevent the designer to get into a situation where a netlist simulates and you get not valid results since the simulator does not care about it. From the designer's perspective you should be notified when you introduce out-of-range parameter and the best place to do so is when you actually draw your schematic and size your devices. And yes I totally agree with you that the information about which parameter to check and the actual limits should be part of the symbol definition.

@Krzysztof Herman yes, makes sense. In any case the checks should be in the pdk-related library (the pdk xschem symbols or a separate ERC check file), not in the core xschem.

@Stefan Schippers CVC(RV) can separate model types based on parameters. So it is possible to create a virtual model of illegal devices and assign a maximum EOS check of 0V. This will flag anything not fully connected to ground.

@Stefan Schippers This check has to happen on the schematic side. And as you mentioned, it has to be a callback format. Because in some complex cases, it might combination of values. I see that you depend on TCL as your backend. It might be a good idea make a function per symbol that is written in TCL. And it would be the responsibility of the PDK developers to code those functions. @Krzysztof Herman thanks for the suggestion. Very important one.

@Stefan Schippers: The device generator script for magic for sky130 has such checks; it's all written in Tcl so it is in theory compatible with xschem. I tried just now to read the script as a standalone Tcl script, and if I modify the file to catch one magic command being called, it reads in cleanly with

namespace eval magic {}; source $PDK_ROOT/sky130A/libs.tech/magic/sky130A.tcl

. Making use of it in xschem would be rather complicated, though, as first you need to make a call to get a dictionary of default parameters for a device, then merge that dictionary with parameter values for an instance being created, then pass that dictionary to the check routine to check for any out-of-bounds values.

@Tim Edwards checking the validity of a set of parameters (W, L, nf, ...) for a given transistor instance looks to me clear and there are various ways to do it. I see a problem for parametric blocks. Suppose I instantiate a parametric FlipFlop, with some dimensions passed as attributes, propagated to the two latches that build up the flip-flop, each latch propagating dimensions to the nand gates that implement the latch function and nand gates finally propagating dimensions to the mos transistors. How do I check transistor dimension validity if actual numeric dimensions are defined 3 hierarchy levels up? traversing all the way up to "get the number" can be done, Not sure if this is the right way to go, since the netlisting operation is hierarchic and not flat. So the lowest level is traversed and netlisted only once (and might be instantiated numerous times, each with different parameter values). In my humble opinion in cases like these the validity checker should be in the topmost parametric instance, that is, the parametric flip flop in this example. Just asking, may be there is a more clever solution I don't see...

My opinion about that is that parameter passing of transistor-level parameters like W and L through multiple levels of hierarchy is just a way to get into trouble. For one thing, it makes it impossible to run LVS without a tool that knows how to split a single cell into multiple varieties based on the total number of unique parameters passed down to it. Calibre can do that; netgen can't. My simple Tcl script that converts netlists to layout is going to choke over that, as well. So I wouldn't even try to solve the problem of determining limits on any parameter that isn't in the simple form of

<name>=<number>

.

@Tim Edwards Thank you, that makes sense. Checks on valid parameters can be restricted when the parameters take plain numbers. One question. What about 1-level parametric symbols, like simple sizeable passgate switches, nands, nors, inverters, buffer gates? I have seen these gates (used in analog / mixed designs) in all PDKs i have worked with (see sample picture). In these cases if we want to do parameter checking the check logic should be provided by these gates, where as you said we have assignments like

name=number.

Does that make sense?

I'd want to make a simple example of that and see what happens when trying to import to layout, and when running LVS. It will have the same problem as any example of passing L and W as parameters. If this is a common practice, then I need to figure out how to accommodate it.

@Tim Edwards FWIW, Calibre flattens parameterized circuits.

@Stefan Schippers @Tim Edwards @Mitch Bailey I am glad to see the interest in pushing forward this functionality. It seems that the discussion evolved into direction to have have like a separate step in the flow, which operates on the netlist. My initial idea was just a simple check, when instantiating/editing an element on the schematic. Anyway, one approach does not exclude the other. As far as I could observe commercial tools use to have it implemented in schematic editor and in simulator (you get a warning during simulation). At IHP we can allocate some time to write TCL checks and test it with xschem and our devices.

@Krzysztof Herman a first implementation is done for checking minimum W and L on sky130 FETs. The DRC warnings are printed when changing a device attribute or when loading a schematic that contains dimensions out of range. This first implementation handles a subset of the transistors, I will over time add more and also add checks on other devices (resistors, capacitors and so on). I will use this first implementation for testing and see if there are drawbacks or regressions before moving further. To enable the drc checks you need to create a tcl procedure (i have added one single

fet_drc

procedure that should handle all kinds of mosfets), for example directly in the xschemrc file (or with a source command) and add a

drc

attribute in the symbol that calls the TCL drc procedure:

drc="fet_drc @name @symname @model @W @L @nf"

since the

fet_drc

procedure gets symbol name and model name it can handle all kinds of transistors with a switch statement on the model name.

@Stefan Schippers fantastic! Great to see it working, let me play with IHP primitives, I will report how it goes.

Thanks @Krzysztof Herman and @Stefan Schippers for this new amazing feature.