The Designer's Guide Community
Forum
Welcome, Guest. Please Login or Register. Please follow the Forum guidelines.
Mar 28th, 2024, 3:13pm
Pages: 1
Send Topic Print
about using (* instrument_module *) flag in verilog-a module (Read 3236 times)
ana2
Junior Member
**
Offline



Posts: 10

about using (* instrument_module *) flag in verilog-a module
Aug 17th, 2016, 6:33pm
 
Hi everyone,

I have a question about using (* instrument_module *) flag in verilog-a module.

[hidden-state] is well-known problem when using verilog-a module in pss simulation. By using (* instrument_module *) flag, hidden-state can be solved according to Cadence Verilog-A Language Reference(veriaref.pdf)

Does anybody konw why (* instrument_module *) flag can solve hidden-state problem, and is there any influence on pss or pnoise pxf results?
I'd appreciate it if someone could help me here.

best regards

Back to top
 
 
View Profile   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2384
Silicon Valley
Re: about using (* instrument_module *) flag in verilog-a module
Reply #1 - Aug 18th, 2016, 4:18pm
 
It does not solve the hidden state problem. All it does is turn off the checking for hidden state. SpectreRF checks for hidden state and refuses to run if it finds it. The reason being that it is unlikely to converge if there is hidden state, and it will be hard to determine why it failed to converge. However, sometimes simple rules for recognizing hidden state are sometimes overly conservative. This simply allows you to disable the hidden state checking. If things converge, you win. If not, well you should know why.

-Ken
Back to top
 
 
View Profile WWW   IP Logged
ana2
Junior Member
**
Offline



Posts: 10

Re: about using (* instrument_module *) flag in verilog-a module
Reply #2 - Aug 21st, 2016, 10:03pm
 
ken

thanks for reply.

>If things converge, you win
i am using a sampling-module to sample some specified points and pss converge.
shoule i think  there is no influence on pss or pnoise pxf results.
am i right?

sampling module
============================================
(* instrument_module *)
module crossing_detector (sigin,sigout);
electrical sigin,sigout;
parameter real pulse_width = 1u from (0:inf);
parameter real sigcrossing = 0;
parameter real vlogic_high = 5;
parameter real vlogic_low = 0;
parameter real tdel = 3u from [0:inf);
parameter real trise = 1u from (0:inf);
parameter real tfall = 1u from (0:inf);
parameter integer direction = 1 from [-1:1];
  real sigout_val;

  real tbreak;   // when switch pulse off.

  analog begin

     @ ( initial_step ) begin
       sigout_val = vlogic_low;
     end

     @ (cross(V(sigin) - sigcrossing, direction)) begin
        sigout_val = vlogic_high;
        tbreak = $abstime + pulse_width;
     end

     @ (timer(tbreak)) begin
        sigout_val = vlogic_low;
     end

     V(sigout) <+ transition(sigout_val,tdel,trise,tfall);

  end
endmodule
==========================================

best regards.
Back to top
 
 
View Profile   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2384
Silicon Valley
Re: about using (* instrument_module *) flag in verilog-a module
Reply #3 - Aug 23rd, 2016, 1:44am
 
Generally instrument modules should have inputs or outputs, but not both.

Also, the long delay/transition times on the transition function could be problematic.  Transition functions should not be in the process of transitioning at the end/beginning of the PSS analysis interval.

-Ken
Back to top
 
 
View Profile WWW   IP Logged
ana2
Junior Member
**
Offline



Posts: 10

Re: about using (* instrument_module *) flag in verilog-a module
Reply #4 - Aug 30th, 2016, 5:56am
 
ken

sorry for reply too late and thanks for comment.

Is there any way to solve hidden state in verilog-A without  (* instrument_module *) ?
i will be appreciated if you can give me any example.
maybe write verilog-A with siwtch and capacitor to memory all the analog state is good way?

best regard
Back to top
 
 
View Profile   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2384
Silicon Valley
Re: about using (* instrument_module *) flag in verilog-a module
Reply #5 - Sep 3rd, 2016, 1:03am
 
You have to reformulate the models so they do not contain hidden state. Any state contained in local variables is hidden from SpectreRF, but state contained in capacitors and inductors is not. So you have to refomulate the models so that state in contains in capacitors. Some examples are given in http://www.designers-guide.org/Analysis/hidden-state.pdf.

It is often surprisingly difficult to do.

-Ken
Back to top
 
 
View Profile WWW   IP Logged
ana2
Junior Member
**
Offline



Posts: 10

Re: about using (* instrument_module *) flag in verilog-a module
Reply #6 - Sep 8th, 2016, 5:03am
 
ken

thanks for the document.

please let me just confirm one thing.

(* instrument_module *) flag can run the simulation although there are some ture "hidden state" description in verilog-A.
i mean how simulator decides the value while  
hidden state really exist in PSS simulation? Undecided

best regards
Back to top
 
 
View Profile   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2384
Silicon Valley
Re: about using (* instrument_module *) flag in verilog-a module
Reply #7 - Sep 9th, 2016, 12:02am
 
I don't understand the question.

-Ken
Back to top
 
 
View Profile WWW   IP Logged
ana2
Junior Member
**
Offline



Posts: 10

Re: about using (* instrument_module *) flag in verilog-a module
Reply #8 - Sep 12th, 2016, 6:50pm
 
Hi ken

>However, sometimes simple rules for recognizing hidden state are >sometimes overly conservative
you mean simulator may stop the pss analysis even though there is not a really hidden-state.
am  i right?

can you tell me what is the "simple rules" for recognizing hidden-state.
that will be help if there are some documents.

best regards.
Back to top
 
 
View Profile   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2384
Silicon Valley
Re: about using (* instrument_module *) flag in verilog-a module
Reply #9 - Sep 14th, 2016, 10:20pm
 
I assume it is looking for variables that are used before they are assigned. When that occurs the value will be recalled from a previous time, and so represents state. State held in AHDL variables is hidden from the RF simulation algorithm.

However, if that state does not affect the behavior of the component, then it is generally not a problem.

-Ken
Back to top
 
 
View Profile WWW   IP Logged
ana2
Junior Member
**
Offline



Posts: 10

Re: about using (* instrument_module *) flag in verilog-a module
Reply #10 - Sep 20th, 2016, 1:12am
 
Hi ken

Thanks a lot!!
I am clear now.

best regards
Back to top
 
 
View Profile   IP Logged
ana2
Junior Member
**
Offline



Posts: 10

Re: about using (* instrument_module *) flag in verilog-a module
Reply #11 - Oct 4th, 2016, 6:18pm
 
Hi ken

I am clear about the usage of (* instrument_module *).
but I am a little confused about the difference between transient simulation and pss simulation.

I think transient simulation can run whether there are some hidden-states or not.
And tstab part of PSS simulation also OK because actually the same engine as transient simlation is used.
but PSS simulation fails if hidden-state exists.

Can you tell me why PSS fails if hidden-state exists and  what is the difference between PSS and transient ?

best regards Smiley

-ana2
Back to top
 
 
View Profile   IP Logged
Geoffrey_Coram
Senior Fellow
******
Offline



Posts: 1998
Massachusetts, USA
Re: about using (* instrument_module *) flag in verilog-a module
Reply #12 - Nov 29th, 2016, 5:57am
 
Suppose you have a counter that is a variable, and thus hidden state, but you use (* instrument_module *).  Now, for 9 periods, your module puts out a sinusoidal output, and it looks like it's periodic.  But maybe on the 10th, the counter resets and the output is zero.  If the rest of the circuit is simple, then PSS may appear to converge in 5 iterations (eg, 5 fixed-point iterations, which are essentially periods of plain old transient analysis, except that the simulator checks if the voltages and currents (but not internal variables!) have the same value at the end of a period as they did at the start.

But if the circuit is a little complicated and takes more than 9 iterations, all of a sudden your module does something completely different, and the simulator gets confused.
Back to top
 
 

If at first you do succeed, STOP, raise your standards, and stop wasting your time.
View Profile WWW   IP Logged
Ken Kundert
Global Moderator
*****
Offline



Posts: 2384
Silicon Valley
Re: about using (* instrument_module *) flag in verilog-a module
Reply #13 - Nov 29th, 2016, 11:18am
 
Fundamentally, shooting methods find the steady state solution by choosing an initial state that exactly equals after one cycle the final state. Thus, shooting methods needs access to the state. It needs to observe it to determine whether the circuit is in steady state. It needs to set it to accelerate the progress to steady state. And it needs to compute the sensitivity of the final state to the initial state to determine the starting point for the next shooting interval.

Think of an archer. To be successful, the archer needs to be able to observe the target, aim the bow, and adjust the aim after the initial volley.

In Spectre, the shooting algorithm can only observe, adjust, and compute sensitivities, of node voltages and branch currents. Local variables in Verilog-A are inaccessible to the shooting algorithm. To the shooting algorithm, it represents hidden state.

Transient is different. There the initial state need only be set once, and is not super critical. Verilog-A gets away with simply initializing all local variables to zero. From then only it only needs to evolve the internal state over time. The transient algorithm itself does not need access to these variables.

-Ken
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.