asiGetStimulusGlobals is only valid after calling ADE - Setup->Stimuli...

Michael,

It's supposed to get global stimulus, not to get the global nets - so it does exactly what it is supposed to do. For me, if I load a state which has global stimulus set up, it returns the global stimulus that have been enabled.

If you're trying to find the global nets in the design, you'd have to traverse the design to find any global signals (look at cvId~>signals and find any that have isGlobal set to t).

Regards,

Andrew.

Ok, it seams there are some missunderstandings; I mean: if I have a design which contains global stimulus (which are mostly global nets like vdd!) and setup ADE for that design without calling "ADE - Setup->Stimuli..." (and without loading a saved session state) and call asiGetStimulusGlobals it will return nil. If I call now "ADE - Setup->Stimuli..." and do nothing in the dialog only call cancel. After that asiGetStimulusGlobals returns the expected one:

asiGetStimulusGlobals(asiGetCurrentSession())
nil

; calling "ADE - Setup->Stimuli..."

asiGetStimulusGlobals(asiGetCurrentSession())
(((name "vdd!")
 (nodes
     ("vdd!" "/gnd!")
 )
 (enabled nil)
    )
)

(The same issue is on asiGetStimulusInputs)

Michael

Michael,

I checked what it's doing - as part of the form being launched, it needs to identify the available global signals, and when it finds them it stores them in the data structure but all disabled. So there is no practical difference between it returning a list of disabled global signals and it returning nil.

So there's nothing wrong here.

If you want to find out the global signals for the session, effectively it is just doing this:

setof(sig asiGetTopCellView(asiGetCurrentSession())~>signals sig~>isGlobal)~>name

Note that it doesn't traverse the hierarchy; it assumes that any global signal will also be defined at the top level (that's what the form population does too).

Andrew.

Sorry, but there is a difference if you want the signal names. Nil assumes there are no global (input) signals and the function name does not give a hint that it will only return prev. specified global stimulus. That's why: it is a bug for me (not a feature).

I will use your "~>signals" solution to extract the global signals. Could you give a hint how a hierarchy traversion could be done?

Michael

 Michael,

It is not a bug or a feature. The function is supposed to return any stimulus globals that have been set up - it is not intended to be a means of finding the global signals in your design - it doesn't say anywhere that this is what the function is for.

The fact that it returns something after the first time the form has been used (even if cancelled) is really an implementation side effect - even that behaviour I wouldn't rely on because the form wasn't OK'd.

If you want to find the globals in the design, the correct way to do it is to use code similar to that which I posted before. Most of the time any global signals will appear in the top level testbench, because you'll want to apply a signal to them, so generally the code I gave is sufficient. There are quite a few threads in these forums which show how to do recursive hierarchical traversal - you can use the Search facility to find them - I suspect you don't really need to do that here though - looking at the globals in the top level will probably be sufficient (that's all the global stimulus setup does).

Regards,

Andrew