Cadence® system design and verification solutions, integrated under our System Development Suite, provide the simulation, acceleration, emulation, and management capabilities.
System Development Suite Related Products A-Z
Cadence® digital design and signoff solutions provide a fast path to design closure and better predictability, helping you meet your power, performance, and area (PPA) targets.
Full-Flow Digital Solution Related Products A-Z
Cadence® custom, analog, and RF design solutions can help you save time by automating many routine tasks, from block-level and mixed-signal simulation to routing and library characterization.
Overview Related Products A-Z
Driving efficiency and accuracy in advanced packaging, system planning, and multi-fabric interoperability, Cadence® package implementation products deliver the automation and accuracy.
Cadence® PCB design solutions enable shorter, more predictable design cycles with greater integration of component design and system-level simulation for a constraint-driven flow.
An open IP platform for you to customize your app-driven SoC design.
Comprehensive solutions and methodologies.
Helping you meet your broader business goals.
A global customer support infrastructure with around-the-clock help.
24/7 Support - Cadence Online Support
Locate the latest software updates, service request, technical documentation, solutions and more in your personalized environment.
Cadence offers various software services for download. This page describes our offerings, including the Allegro FREE Physical Viewer.
Get the most out of your investment in Cadence technologies through a wide range of training offerings.
This course combines our Allegro PCB Editor Basic Techniques, followed by Allegro PCB Editor Intermediate Techniques.
Virtuoso Analog Design Environment Verifier 16.7
Learn learn to perform requirements-driven analog verification using the Virtuoso ADE Verifier tool.
Exchange ideas, news, technical information, and best practices.
The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information.
It's not all about the technlogy. Here we exchange ideas on the Cadence Academic Network and other subjects of general interest.
Cadence is a leading provider of system design tools, software, IP, and services.
asiGetStimulusGlobals methods only works if you prev. called dialog "ADE - Setup->Stimuli...". Is there any workaround for that? How can I get the global nets of current design?
I am using Virtuose 6.1.5
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).
In reply to Andrew Beckett:
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:
; calling "ADE - Setup->Stimuli..."
asiGetStimulusGlobals(asiGetCurrentSession())(((name "vdd!") (nodes ("vdd!" "/gnd!") ) (enabled nil) ))
(The same issue is on asiGetStimulusInputs)
In reply to MLindig:
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).
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?
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).