Adding Pins to selected instance in schematic

Hi Michele,

Having looked at that code and explored some possible failure mechanisms, it appears to be that if you have not done a schematic check (using schCheck() for example), then the instTerms have no nets associated with them, and so it's trying to create nets with nil information and this breaks the schCreatePin.

I'm not entirely sure why you need pins for what you describe. Naming the wires ought to be enough (e.g. using the space bind key or schHiCreateWireStubs) - but perhaps I've misunderstood your overall intent.

Andrew.

Hi Andrew!

Thanks! I'm not sure why I forgot to C&S -- anyhow this got rid of the error message as you predicted.

The script doesn't do exactly what I wanted, because it doesn't appear to take my selection into consideration: it just puts pins everywhere there's no pin, within the schematic window (cellView) I'm working on.

I was expecting the procedure to be applied to the specific block selected within the cellView canvas, however this is no big deal.

Onto my evil plan ;-)

My general interest is to become more proficient at creating, maintaining and simulating 'large' test benches. All this very analog oriented, so no AMS in sight, but still the blocks coming together into the test bench will generally have a considerable amount of interface pins. There will be enabling, trimming, control signals of all sorts, plus supply/gnd, inputs & loads.

While looking around for more manageable solutions than adding hundreds of sources into the test bench, I firstly stumbled upon the concept of 'stimuli files' - I was out to look for a way to generate a 'template' stimulus file to then modify with text-based tools, because the GUI approach is, again, very unpractical when you have more than 10-20 signals to juggle.

I found here in your site a post (or was it a blog entry?) where you point out that the 'stimulus file' concept is also performing a sort of mapping and if you don't need that mapping, why not just ad a piece of netlist to the model files, where you describe your inputs and possibly output conditions? So I've tried a very basic experiment and this suits me well. I'm going therefore to the next stage and tackle something slightly more complicated.

Still, the issue remains: how to 'pre-fill' a netlist with sources connected to the boundary nodes, to spare the leg work and only focus on the important stuff?

I thought of tackling this in two steps:

1) find a way to create PIN items as to differentiate what needs to be taken into account and what doesn't

2) find a way to output the PIN list of a certain cellView to a file. Then take it from there.

Why pins and not nets? Just because then I can select, like in this pic:

So that's why I'm heading towards the 'pin creation'.

Any suggestion - provided I was clear enough - is highly welcome!

Regards,

Michele

Going along the image, you could just list all nets that are connected to only a single instTerm; so maybe something like this is sufficient:

foreach(net deGetCellView()~>nets when(car(net~>instTerms) && !cadr(net~>instTerms) printf("%L\n" net~>name)))

This might look a bit awkward (it's from my "one liner" collection) and it just prints the net names of the currently active cellview to the CIW, so you would need to reformat and add your variables and the file IO to make it fit your requirements. It could be even used to collect the net names for which pins should be created instead of creating pins for all existing instance terminals.
Another option could be to use the warning markers from schCheck (the 'check' part of the Check&Save) that complain about open inputs and outputs. From signal point of view, the open inputs are the points where external data has to be provided, although I think to have explicit pins in the testbench schematic is much more intuitive. This of course requires that your instances have proper input/output directions to allow the connectivity checks.
Similar functionality than schCheck could be achieved by modifying the above line, e.g. instead of testing the number of instTerms, check the instTerms on each net if they are all input or all output. A difficulty might be, that you have to decide on how to handle inputOutput terminals and the combinations but this is just a diligent but routine piece of work.

Best regards,

I like your one-liner!

As far as the general strategy is concerned, I think I'll stick with the pins because - as you also feel - it's just much clearer for a test bench to indicate what's an interface element and what isn't. What I would really find nice is if I could add the pins directly to the nets they belong to, instead of having them sparse around the canvas.

I've done too little SKILL coding and the last time I did was for something similar (automatic schematic creation), but it was like 3 years ago or longer so I managed to lose all my edge.

For something like 'clever pin placement', an extension of the code I found here, probably a check like the one you do would turn out useful.

Thanks!

I like your one-liner!

As far as the general strategy is concerned, I think I'll stick with the pins because - as you also feel - it's just much clearer for a test bench to indicate what's an interface element and what isn't. What I would really find nice is if I could add the pins directly to the nets they belong to, instead of having them sparse around the canvas.

I've done too little SKILL coding and the last time I did was for something similar (automatic schematic creation), but it was like 3 years ago or longer so I managed to lose all my edge.

For something like 'clever pin placement', an extension of the code I found here, probably a check like the one you do would turn out useful.

Thanks!

Hi Michele,

A few relevant suggestions that could be useful in my response here to another recent post.

Andrew

Hi Andrew,

Yes I was 'thinking' along the same lines - of course in my case actually getting to an implementation would take some serious effort, being the noob I am... But I'll get there, thanks a lot for the pointers, looks like all ingredients are there!