I am using skill script to generate a netlist file of a schematic from 'schematic editor'. For example, there is only one instance in the schematic, 'AND2_tr', showing below. And I want to get the 4 connections of this instance.
Here I used the skill script ::
a=geGetWindowCellView() ; get current window
b=nth(0 a~>instances) ; b is the first element of a
b~>conns~>net~>name ; this should give us the connections of the gate,
But the question is that, I can't find any reasonable order of the nets returned by the command. It's not depend on the pin name, nor the pin location. But it seams to be fixed for a symbol view.
Can anyone help to give me a hint about the order of the returned nets name?
Thank you very much,
Below is my symbol,
There is no defined order. It's dependent upon the order the instTerm objects were created - the schematic has tended to create them so that they match the order of the terminals on the master (symbol), but that's not guaranteed. If you create the instance and instTerms using SKILL, say, the order of the conns/instTerms on one instance can be different from another. So you should not attempt to read anything into the order, nor should you need to.
What you should do instead is use the other attributes of the instTerm objects you're accessing with via ~>conns or ~>instTerms (which are equivalent). This will tell you which terminal name is connected to which net name:
foreach(conn b~>conns printf("%s : %s\n" b~>name b~>net~>name))
Thank you very much.
The reason why I want to do this is to generate a spice-like netlist, like' X1 AND2_tr <net1> <net2> <net3>'. And the order of the connections should match the order in definition. " .subckt AND2_tr <a> <b> <y> "
It's just convenient if I can define the order. So that I can just use the code like this:
foreach( instance schematicCellViewId~>instances fprintf(Out_file "X%s %s " instance~>name instance~>cellName) foreach(tmp instance~>conns~>net~>name fprintf(Out_file "%s " tmp)) fprintf(Out_file "\n") )
And I don't need to search the corresponding terminal name every time. But according to your answer, it seams hard to find the intrinsic order when exported.
Good thing is that, I find the order remains the same for every exporting as long as I created the symbol. Even though it's kind of 'random' order, it's fixed. I can just change my definition file and match the I/O definition order to cadence.
You really should not just use the order you find, because as I said, it's absolutely possible to have different instances with a different order of the connections. Whilst you may not have experienced this, empirical tests on behaviour do not make good code, and tend to lead to hard-to-debug problems later when assumptions turn out to be false. There is no "intrinsic order" in the database.
Our netlisters (when they need to have a determined order) typically use the termOrder in the simulation information section of the CDF for the component they use, or some order based on the sorted terminal names. Sometimes it will be done on a pure alphabetical (well, ASCII) sort, sometimes sorted but with outputs, then inputOutputs, then inputs (depends on the netlister).
Since you have control over this, it would be safer to do it based on the sorted order based on the terminal names. So, do:
conns=sort(instance~>conns lambda((a b) alphalessp(a~>name b~>name)))
Then you can iterate over the connections safely knowing the order is well-defined:
foreach(name conns~>net~>name fprintf(Out_file "%s " name))
I see. I agree with you. Earlier solution maybe 'easy' but can lead to extra problem in the future. I will try you suggestion. Thank you very much.