Trace a net backwards

Do you need to write SKILL to do this? Could you not just probe the net (RMB->Add Probe over the wire) and then use Window->Assistants->Probes to investigate what is connected to it. This has the ability to filter to show drivers and loads only.

There's also the schTraceNet function - for example: Virtuoso Schematic Editor - Probing and Calculating the Area of a Net using schTraceNet and SKILL to probe a schematic net and print lower-level net name and hierarchical path of all instances including vector or arrayed instances

Andrew

For this task, it has to be done with skill because it will be run in batch mode without the GUI. I have explored the schTraceNet function but it only traces forward and not backwards

You can definitely start from a net at a lower level, and it will trace up and down in the hierarchy from there. You do have to give it a top cellView, and the hierPath to where you're starting from (otherwise it won't know the context of where you're starting from). For example, I just did this:

procedure(abShowStuff(netStruct) printf("SHOW STUFF: %L\n" netStruct->??))

schTraceNet(?topCellView list("ether" "top" "schematic") ?net "PLL_160_IN" ?hierPath "/I22/I5" ?traceCB 'abShowStuff)

and it gives me:

SHOW STUFF: (pathToNet "/I22/I5" netName "CLK_160MHZ" hierPath ((db:0x23a6a3ad 0 0 0) (db:0x3bed191f 0 0 0)) net db:0x33688c1b)
SHOW STUFF: (pathToNet "/I22/I5/I24" netName "CLK160" hierPath ((db:0x23a6a3ad 0 0 0) (db:0x3bed191f 0 0 0) (db:0x33688a9e 0 0 0)) net db:0x33686c3e)
SHOW STUFF: (pathToNet "/I22/I5/I24/I11" netName "Y" hierPath ((db:0x23a6a3ad 0 0 0) (db:0x3bed191f 0 0 0) (db:0x33688a9e 0 0 0) (db:0x33686a1d 0 0 0)) net db:0x33689b1a)
SHOW STUFF: (pathToNet "/I22/I5/I24/I11/PM1" netName "D" hierPath ((db:0x23a6a3ad 0 0 0) (db:0x3bed191f 0 0 0) (db:0x33688a9e 0 0 0) (db:0x33686a1d 0 0 0) (db:0x33689a1a 0 0 0)) net db:0x3bed6c9a)
SHOW STUFF: (pathToNet "/I22/I5/I24/I11/NM1" netName "D" hierPath ((db:0x23a6a3ad 0 0 0) (db:0x3bed191f 0 0 0) (db:0x33688a9e 0 0 0) (db:0x33686a1d 0 0 0) (db:0x33689a1d 0 0 0)) net db:0x3bed261a)
SHOW STUFF: (pathToNet "/I22" netName "PLL160" hierPath ((db:0x23a6a3ad 0 0 0)) net db:0x3bed1ac1)
SHOW STUFF: (pathToNet "" netName "PLL_160_IN" hierPath nil net db:0x23a69b60)
SHOW STUFF: (pathToNet "/I42" netName "PLL_160_IN" hierPath ((db:0x23a6a39d 0 0 0)) net db:0x3aa62226)
SHOW STUFF: (pathToNet "/I42/I49" netName "PLL_160_IN" hierPath ((db:0x23a6a39d 0 0 0) (db:0x3aa623b2 0 0 0)) net db:0x3b0c711d)
SHOW STUFF: (pathToNet "/I42/I49/I61" netName "A" hierPath ((db:0x23a6a39d 0 0 0) (db:0x3aa623b2 0 0 0) (db:0x3b0ce533 0 0 0)) net db:0x3b0cfaa9)
SHOW STUFF: (pathToNet "/I42/I49/I61/PM0" netName "G" hierPath ((db:0x23a6a39d 0 0 0) (db:0x3aa623b2 0 0 0) (db:0x3b0ce533 0 0 0) (db:0x3b0cfa1a 0 0 0)) net db:0x3bed6c9b)
SHOW STUFF: (pathToNet "/I42/I49/I61/NM0" netName "G" hierPath ((db:0x23a6a39d 0 0 0) (db:0x3aa623b2 0 0 0) (db:0x3b0ce533 0 0 0) (db:0x3b0cfa1b 0 0 0)) net db:0x3bed261c)

It's showing me nets in children of where I am, plus in the parents, plus in sibling paths back down from the top level.

So unless I've misunderstood what you're asking for, this can certainly be done...

Andrew

Thanks for this information but somehow its not working for me. Maybe I am missing something. Let me redefine the problem

Assuming I am in some lower level hierarchy D and the origin of a net is from a higher level A.

I want to get the device where the net originates from.

How can I trace it back from lower level D to higher level A 

NOTE: My starting point is the lower level of the hierarchy (D) and the only information available is the lower level cell name I descended into.

Basically doing what the probe command is doing by highlighting the devices on a net from below and you ascend upwards to see the origin

Hope this clarifies what I'm looking for.

I tried using your solution but it returned nil.

Current cellname: inv

Current instance name: I5

net name: a

schTraceNet(?topCellView list("ether" "top" "schematic") ?net "a" ?hierPath "I5" ?traceCB 'abShowStuff)

Well, this is using the same infrastructure that probing uses. If you probe from within a lower-level block in the schematic editor, it knows the top-level cellView, and the instance path that you descended into to get to that block. The same information is needed if you do this procedurally. If you think about it, it's inevitable that this would be required, because how would it know the hierarchical context of the block you're in? There might be many occurrences in the design hierarchy, and it needs to know the net name and the specific occurrence you're in so that it can trace upwards.

The hierarchical path should use / as hierarchy separators, so it would be "/I5". That would mean that the top level design is still ether/top/schematic, and there's an instance called I5 within the "top" schematic, and net "a" is within the instance I5. Is that what you have? If not, it would return nil - the net name has to be in that hierarchical path.

To test it interactively, I suggest you try starting from a top level schematic, descending into the block you want, selecting a wire on the net you want, and then trying:

schTraceNet(?topCellView geGetTopLevelCellView() ?net car(geGetSelSet())~>net~>name ?hierPath geGetInstHier(hiGetCurrentWindow()) ?traceCB 'abShowStuff)

You can probe the same net, and compare with what you get in the probe assistant.

You can then check the values passed in to schTraceNet in the code above, and that should help you understand the requirement.

Regards,

Andrew

Well, this is using the same infrastructure that probing uses. If you probe from within a lower-level block in the schematic editor, it knows the top-level cellView, and the instance path that you descended into to get to that block. The same information is needed if you do this procedurally. If you think about it, it's inevitable that this would be required, because how would it know the hierarchical context of the block you're in? There might be many occurrences in the design hierarchy, and it needs to know the net name and the specific occurrence you're in so that it can trace upwards.

The hierarchical path should use / as hierarchy separators, so it would be "/I5". That would mean that the top level design is still ether/top/schematic, and there's an instance called I5 within the "top" schematic, and net "a" is within the instance I5. Is that what you have? If not, it would return nil - the net name has to be in that hierarchical path.

To test it interactively, I suggest you try starting from a top level schematic, descending into the block you want, selecting a wire on the net you want, and then trying:

schTraceNet(?topCellView geGetTopLevelCellView() ?net car(geGetSelSet())~>net~>name ?hierPath geGetInstHier(hiGetCurrentWindow()) ?traceCB 'abShowStuff)

You can probe the same net, and compare with what you get in the probe assistant.

You can then check the values passed in to schTraceNet in the code above, and that should help you understand the requirement.

Regards,

Andrew

Thanks for this information., this seems to work. That means for my usage, since there will be no GUI. I have to always know the full instance path and the top level schematic for me to use the schtrace function

Genas said:

That means for my usage, since there will be no GUI. I have to always know the full instance path and the top level schematic for me to use the schtrace function

That's right. For any such function it couldn't possibly trace upwards without know where it is starting from in order to go "up". So it has to know the hierarchical context to be able to do this.

Maybe your block only exists once in the hierarchy; in which case you could write some code to start at the top, do a hierarchical traversal of the design, and find the unique occurrence of the block in the hierarchy and thus figure out the hierarchical path down to that block. Then you could use the schTraceNet function to trace from there to follow the net.

However, in the general case, you can't guarantee that a particular block only has a single occurrence in a hierarchical design, which is why it needs to know which occurrence you're starting from, as the parent nets could well be (and are very likely to be) different for each occurrence.

Regards,

Andrew