The Designer's Guide Community
Forum
Welcome, Guest. Please Login or Register. Please follow the Forum guidelines.
Aug 16th, 2024, 3:21am
Pages: 1
Send Topic Print
iprobe and STB analysis (Read 2862 times)
sck236
Junior Member
**
Offline



Posts: 15

iprobe and STB analysis
Jul 09th, 2008, 8:24am
 
To use STB analysis in the top circuit, an iprobe(or cmdm probe) component
must be placed in a block where I want to break the loop.

This means that I have to modify the original schematic.

After an analysis is complete,
I have to remove the iprobe from the schematic
to export the schematic as a cdl netlist in order to do LVS.

It is very cumbersome. Does anyone know  better ways?

My guess
1. another schematic view for the STB analysis
and use the hierarchy editor?

2. or bring the two nodes that I want to break upto the top symbol?

3. or stb analysis upgrades.
With those, you have only to point out the net that must be broken.
Back to top
 
 
View Profile   IP Logged
sheldon
Community Fellow
*****
Offline



Posts: 751

Re: iprobe and STB analysis
Reply #1 - Jul 10th, 2008, 6:48am
 
Sck236,

  Usually the iprobe or cmdm probe is connected to either the inputs
or outputs of the block, so placing the probe in the top level testbench
schematic is not an issue. Is there something unusual about the design
that prevents you from placing the probe in the top level testbench?


                                                           Best Regards,

                                                              Sheldon
Back to top
 
 
View Profile   IP Logged
ywguo
Community Fellow
*****
Offline



Posts: 943
Shanghai, PRC
Re: iprobe and STB analysis
Reply #2 - Aug 5th, 2008, 11:45pm
 
Hi Sheldon,

Sometimes the hierarchy is not so clear that the feedback path is in the bottom/lower level. What sck236 asked really bothers me, too.


Sck236,

I think you have already put forward a few good solutions. What I do is to remove the iprobe/cmdm probe after doing the stb analysis.


Yawei
Back to top
 
 
View Profile   IP Logged
sheldon
Community Fellow
*****
Offline



Posts: 751

Re: iprobe and STB analysis
Reply #3 - Aug 6th, 2008, 7:00am
 
YW,

One other option that is a little crude is to use inherited connections
to bring the node up to the top level. The only impact of this approach
is to name the nets at the lower level.

                                                                Best Regards,

                                                                  Sheldon
Back to top
 
 
View Profile   IP Logged
wave
Senior Member
****
Offline



Posts: 117
Silicon Valley
Re: iprobe and STB analysis
Reply #4 - Aug 6th, 2008, 5:58pm
 
Better yet, put the iprobe in a symbol.  Get your CAD dept to make that symbol LVS as a metal resistor.  Voila!  No schematic changes after verification.

Cool
Back to top
 
 
View Profile   IP Logged
HdrChopper
Community Fellow
*****
Offline



Posts: 493

Re: iprobe and STB analysis
Reply #5 - Aug 8th, 2008, 7:53am
 
I think option 1 from Sck236 works but it is still somehow risky...you cannot guarantee the customized schematic view you use for stb analysis is exactly the same one you LVS...

Option 2 is better from my perspective although YW brougth a good point about it.

Certainly wave´s option sounds like the best one...

Tosei
Back to top
 
 

Keep it simple
View Profile   IP Logged
sugar
Community Member
***
Offline



Posts: 54

Re: iprobe and STB analysis
Reply #6 - Dec 3rd, 2008, 9:55pm
 
Hi Sheldon,

What do you mean by "inherited connections"?
Could you please give more explanations or simply give us an example.

Thanks,
River
---------------------------------------------------------------------------

One other option that is a little crude is to use inherited connections
to bring the node up to the top level. The only impact of this approach
is to name the nets at the lower level.

                                                               Best Regards,

                                                                 
Back to top
 
 
View Profile   IP Logged
Andrew Beckett
Senior Fellow
******
Offline

Life, don't talk to
me about Life...

Posts: 1742
Bracknell, UK
Re: iprobe and STB analysis
Reply #7 - Jan 2nd, 2009, 8:37am
 
Whilst inherited connections could be used for this, I don't think it's a terribly practical solution to the problem. The idea is that you'd have two nets in the lower level of hierarchy, each with net expressions on them to define that the net is connected via netSet property higher up, or defaults to a global net if the netSet is not present.

The trouble is that you can't have two nets in the same level of hierarchy which have the same default global net - so in practice you can't have them connected by default - you'd have to ensure you placed a netSet somewhere above to short the two sides of the loop. That sounds error prone to me.

A better solution is to use something like the "cds_thru" component, which can be seen as a short in LVS and VirtuosoXL - this is a similar idea to that posted earlier, of using a metal resistor.

I also have an enhancement request in to allow the probe to be specified as a device terminal - effectively the idea is that spectre could insert the iprobe in series with this terminal, rather like it does for saving a current. Of course, this would only help if the loop you want to measure is in series with a single device terminal, but it would certainly minimize the number of times you need to modify the design.

However, I tend to recomment the metal resistor approach, as this can also then give you somewhere you can probe a loop after a parasitic extraction too.

Regards,

Andrew.
Back to top
 
 
View Profile WWW   IP Logged
ywguo
Community Fellow
*****
Offline



Posts: 943
Shanghai, PRC
Re: iprobe and STB analysis
Reply #8 - Dec 25th, 2009, 1:15am
 
Andrew,

I stumbled upon that the problem on probe is already resolved in spectre. According to Virtuoso Spectre Circuit Simulator Reference, Product version 7.0.1, June 2008, the stability analysis has two algorithms. One is loop based, which requires probe in the loop. The other is device based, which does NOT require probe in the loop.

The following is copied from the reference manual.

Quote:
Understanding Loop based and Device Based Algorithms
====================================================
Two algorithms--the loop based and the device based, are available for small-signal stability
analysis. Both algorithms are based on the calculation of Bodes return ratio. Loop gain
waveform, gain margin, and phase margin are the analysis output.
The probe parameter must be specified to perform stability analysis. When it points to a
current probe or voltage source instance, the loop based algorithm will be invoked; when it
points to a supported active device instance, the device based algorithm will be invoked.
Loop Based Algorithm
--------------------
The loop based algorithm calculates the true loop gain that consists of normal loop gain and
reverse loop gain. The loop based algorithm requires the probe being placed on the
feedback loop to identify and characterize the particular loop of interest. The introduction of
the probe component should not change any of the circuit characteristics.
The loop based algorithm provides accurate stability information for single loop circuits, and
multiloop circuits in which a probe component can be placed on a critical wire to break all
loops. For a generalmultiloop circuit, such a critical wire may not be available. The loop based
algorithm can only be performed on individual feedback loops to ensure they are stable.
Although the stability of all feedback loops is only a necessary condition for the whole circuit
to be stable, the multiloop circuit tends to be stable if all individual loops are associated with
reasonable stability margins.
Device Based Algorithm
----------------------
The device based algorithm calculates the loop gain around a particular active device. This
algorithm is often applied to assess the stability of circuit design in which local feedback loops
cannot be neglected; the loop based algorithm cannot be performed for these applications
since the local feedback loops are inside the devices, they are not accessible from the
schematic level or netlist level to insert the probe component.
With the probe parameter points to a particular active device, the dominant controlled source
in the device will be nulled during the analysis. The dominant controlled source is defined as
by nulling this source renders the active device to be passive. The device based algorithm
produces accurate stability information for a circuit in which a critical active device can be
identified such that nulling the dominant gain source of this device renders the whole network
to be passive.


Yawei
Back to top
 
 
View Profile   IP Logged
BackerShu
Community Member
***
Offline



Posts: 64

Re: iprobe and STB analysis
Reply #9 - Dec 27th, 2009, 8:47pm
 
Hi Yawei!

Something is different when these two method are used to simulate the following case--gain-boosting amplifier.
As the attachment shows, I think the feedback loop of the gain-boost could also be considered as a local feedback.
In the past, I broke the loop at the gate of M2 and introduced a iprobe in the loop to do the stb analysis.
Now, I remove the iprobe and select M2 for probe instance in stb analysis.
I get these two different stability summary:
use iprobe:
Phase Margin=80.45deg @freq = 524.90MHz(which seems resonable in my design)

use M2:
Phase Margin=74.34deg @freq = 3.64GHz

I'm afraid these two methods may have some difference and couldn't be used in the same situation. Or did I break the loop the  wrong way?


Back to top
 

gain_boost.jpg
View Profile WWW   IP Logged
Andrew Beckett
Senior Fellow
******
Offline

Life, don't talk to
me about Life...

Posts: 1742
Bracknell, UK
Re: iprobe and STB analysis
Reply #10 - Dec 29th, 2009, 7:16am
 
As I pointed out to Yawei (he sent me an email with the same contents as his post above), the Device method is not an alternative to inserting an iprobe within the loop you want to analyze. The device method has been there since the stb analysis was introduced - see http://www.kenkundert.com/docs/cd2001-01.pdf.

What it is for is for analysing a loop within a device - so it's hardly surprising that you get completely different results; it's a different loop you're analysing.

There's still a need to do this insertion somehow, as I mentioned before, and this was discussed within Cadence at some length in CCR 524571.

Regards,

Andrew.
Back to top
 
 
View Profile WWW   IP Logged
Pages: 1
Send Topic Print
Copyright 2002-2024 Designer’s Guide Consulting, Inc. Designer’s Guide® is a registered trademark of Designer’s Guide Consulting, Inc. All rights reserved. Send comments or questions to editor@designers-guide.org. Consider submitting a paper or model.