The Designer's Guide Community Forum
https://designers-guide.org/forum/YaBB.pl Simulators >> Circuit Simulators >> iprobe and STB analysis https://designers-guide.org/forum/YaBB.pl?num=1215617090 Message started by sck236 on Jul 9th, 2008, 8:24am |
Title: iprobe and STB analysis Post by sck236 on Jul 9th, 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. |
Title: Re: iprobe and STB analysis Post by sheldon on 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 |
Title: Re: iprobe and STB analysis Post by ywguo on 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 |
Title: Re: iprobe and STB analysis Post by sheldon on 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 |
Title: Re: iprobe and STB analysis Post by wave on 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. 8-) |
Title: Re: iprobe and STB analysis Post by thechopper on 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 |
Title: Re: iprobe and STB analysis Post by sugar on 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, |
Title: Re: iprobe and STB analysis Post by Andrew Beckett on 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. |
Title: Re: iprobe and STB analysis Post by ywguo on 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:
Yawei |
Title: Re: iprobe and STB analysis Post by BackerShu on 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? |
Title: Re: iprobe and STB analysis Post by Andrew Beckett on 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. |
The Designer's Guide Community Forum » Powered by YaBB 2.2.2! YaBB © 2000-2008. All Rights Reserved. |