RE: Draft proposal for (1) Mixed-signal IC analysis (2) Mixed-sig nal non-transient analyses

Hi Martin,

Thanks a lot for the detailed feedback, my comments are below 

> First of all thanks for writing this - think it is good that the mixed
> signal initialization process is clearer in the LRM.
> 
> 9.2.2
> Think it would be better to use another name other than initial
> condition analysis because what you describe seems more to be an
> operation point calculation/analysis or mixed signal initialization.

Agreed, I think "Operating point calculation" seems a better fit.

> 
> 9.3.1.1
> 
> The method describe seems similar to that of Verimix which seeks to
> co-simulate blocks describe in languages that are not naturally
> mixed-signal. Verilog-AMS, however, is a mixed-signal language so
> something cleaner is possible.
> 
> The LRM already describes later in section 9.3 how analog and digital
> naturally synchronize based on d2a and a2d events.
> 
> The same approach can be applied quite naturally to mixed-signal
> initialization as follows;
> 
> 1: Set initial conditions for analog nodes
> 2: Run digital kernel until all events at t=0 are
> exhausted
> 3: Do a DC solution in analog kernel
> 4: If there no zero-delay A2D events goto 7:
> 5: Run digital kernel until all events at t=0 are
> exhausted
> 6: If there are zero-delay D2A events goto 3:
> 7: end of mixed-signal initialization

I added section 9.3.1.4 (along with the figure 9-1: IC relaxation Loop) specifically because arriving at a mixed-signal initialization is not a natural extension to Section 9.3.4 (Synchronization and Comm algo). The reason I say this is because at t=0, these are special conditions that need to be handled which are not handled in Section 9.3.4
 - what should be the values to be used for across-the-domain accesses ? (When analog is let to run first, what should be the value of a digital net being accessed in analog behavior be, "0", "x" ?, similarly if the digital engine has a go first, what should be the value of, say an analog branch accessed in an initial block be ? Etc.)
 - How should the mixed-signal simulator arrive at an agreeable node voltage/state values for interface elements ?
 - Which engine should in fact have a go first ?
 - How should events be handled at time t=0 to synchronize (especially D2A, because at t=0, analog need not step back in time (as described in steps 13, 14, 15 of Figure 9-6, Sample run) 

> Note that digital is left run first so that the t=0 assignments can be
> done to eliminate many of the 'x's.

Letting digital kernel have a go first is opposite to what LRM section 9.3.4 says (see step "1" in Figure 9-6).. This is why I say analog should have a go first in the proposal, which is what happens in a t > 0 part of the transient run. Again, this is exactly why I think documenting which engine goes first is necessary.

> 
> In terms of continuing simulation until no x's are left - this is not
> necessary and might also not be what the users want.
> Note that Verilog-AMS CMs can be written to naturally handle 'x's.

Completely agree with you, I will re-phrase this section (9.3.1.1). The main intention I was thinking was only for interface elements, not the entire design. 

> 
> 9.5.1.1
> As stated about 9.3.1.1, I think the proposal for getting mixed signal
> initialization should be changed - this would also apply to 
> getting the operating point.

You mean the first sentence right ? Yes, I will change the "circuit initialization" to "operating point".
> 
> 9.5.1.2 Point 1;
> I see the changes mentioned above about how to do mixed signal
> initialization also applying here.
> 
> 9.5.1.2 Point 2;
> Re-evaluating initial blocks in digital seems wrong and 
> dangerous to me.
> In Verilog initial blocks are only intended to be run once - they can
> also contain delayed assignments which could cause chaos if scheduled
> more that once by running an initial block multiple times.

Not re-evaluating initial blocks will lead to wrong results.. For example,

  initial
       digVar = V(brn);

  and assume that V(brn) gets controlled by a node voltage that is being swept (say from 0 to 10V in steps of 1V), if the initial block is not re-evaluated at every point in the DC analysis, the digVar just stays at 0, where in fact it should be 0, 1, 2 ... 9 for the steps.

> 
> 9.5.1.2 Point 3;
> My take is that it is an open question whether users would 
> like the a2d
> events processed by digital and d2a events potentially passed back. I
> can see reasons for going both ways so maybe it should be an 
> option the user has.

In my opinion, handling of mixed-signal events at every DC point is exactly same as handling events at t=0 IC part of a transient run (See section 9.3.1.5, items 1 and 2). Supplying a user switch to control the behavior should probably be simulator specific, outside of LRM ? What do you think ?

> 9.5.1.3
> I see the changes mentioned above about how to do mixed signal
> initialization also applying here to get an operating point.
> 
> Re-evaluating initial blocks in digital seems wrong and 
> dangerous to me.
> In Verilog they are only intended to be run once.
> 
> During a small signal analysis, it should be stated that digital
> maintains it state, doesn't advance time and that no A2Ds or D2As are
> generated.

Doesn't item 2 (Frequency Sweep phase) in Section 9.5.1.3 capture this ?

> 9.5.1.4
> This seems like a reasonable approach to me. However it seems like a
> good idea to state that the digital engine and state are fixed/frozen
> when a small signal analysis is done after a transient 
> analysis and that no A2Ds or D2As are generated.

Definitely, I agree, this whole section needs to be expanded further, this is one section where I solicit more feedback from everyone.

> 
> Thanks,
> --Martin

Thanks a lot Martin for all the feedback, much appreciated.

Cheers,
Prasanna