Hi Everyone,

The general question: Is there a way to access simulation parameters in an OCEAN script?

Current use case: I am running an AC analysis with design variable sweep at a fixed frequency. In the post processing I use the frequency value, what now I have write into the code. Magic number in the ocean code! It could lead to trouble if the frequency changes. The elegant solution would be to get the frequency used in the simulation automatically. Is something like that possible? What is the keyword I should look for in the documentation?

I've had a discourse with a more senior engineer where he meant that on-chip inductors are not a threat, they are used in mobile phone for 25+ years, and the only reason why an inductorless circuit is preferred for similar performance is the reduced area. On the other hand I fear that we can not so easily dismiss any coupling between the inductors, and even in the presence of a ground plane they could introduce spurs, pulling or shift the DC bias by down-convertion on non-linearities.

If any of you worked on such chips, could share how much trouble did those inductors caused for you? Does the system architect live in a constant paranoia about the possible sources of spurs, or these can be kept within limits required by the strict emission standards by good engineering practices. In the latter case - I guess - the main mischief makers are the IR drops, substrate coupling, conducted interference on the bias and reference lines.

Hi Ken,
Thanks, Will try CV/I kind of delay element.
Thanks
Marshnil

The only non-hidden state is the state of capacitors and inductors. If you want to implement a delay that does not have issues with hidden state, use capacitors and inductors. Consider designing an all-pass filter.

-Ken

Hi Ken,
Thanks for your input.
I found a workaround for running PSS with a "delay" cell.
I ended up using an ahdlLib inverter for which we can specify the delay value. I also specified non-zero tr and tf for the ahdlLib inverter.

With this, PSS  analysis does not give me an error about "distributed element" or "hidden state". However, PSS does not converge !!!

Is it possible that the ideal ahdlLib inverter transfer function is not smooth causing PSS convergence errors?


The log file shows the following. "PSS failed to converge PSS will adjust tstab a little and try again".
finally, "Even after adjusting tstab value, PSS failed to converge"

I checked the transient waveforms at the end of "tstab" time, they look periodic and correct.

Thanks
-CMOSA

In the presence of a large input signal, the DC and the average steady state voltage will differ due to the non-linear device characteristics.

Hi,
In my recent work, I need to calculate the electrical power consumed by a conductor (using Verilog-A).

As we know, the impedance of a conductor varies with the frequency of the electrical excitation applied. For example, its dc resistance is assumed to be R_dc, and the resistance at 20 GHz is assumed to be R_ac (because of skin effect).
The electrical excitation is a sinusoidal voltage source, which is expressed as
V=V₀+V_a*sin(2*pi*freq*t)
where V₀ is the dc component; V_a is the amplitude of the ac component; freq is the frequency; t is the time.

My question is, in the following, which is the correct way to calculate the electrical power consumption of the conductor?
(1) Power consumption on R_ac with both dc and ac voltage component applied
(2) The summation of dc power consumption on R_dc and ac power consumption on R_ac

Any help would be greatly appreciated, thank you.

Actually, I just checked in the base release (IC6.1.7-64b.78) and RealVsImag is there - so I'd be surprised if it went missing in a later sub-version.

Here's what it looks like for me in the results browser...

Andrew

That's only the first part of the version number - I asked for the entire version number (which is shown on the Help->About form)

If it makes it easier, type in the CIW: getVersion(t)
and then post the result here.

Andrew.

Presumably this depends on what you're simulating or measuring. If all your input frequencies are below the Nyquist rate, then it's not necessary to include the anti-aliasing filter. If you potentially have significant signal levels at frequencies above the Nyquist rate, or are trying to assess the effectiveness of your anti-aliasing filter, then yes you would...