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

Tamhankar,
Thanks for your feedback
Comments below.
--Martin

>-----Original Message-----
>From: Tamhankar Prasanna-A14507
[mailto:Prasanna.Tamhankar@freescale.com]
>Sent: Friday, June 10, 2005 12:10 AM
>To: Martin O'Leary; verilog-ams@eda.org
>Subject: RE: Draft proposal for (1) Mixed-signal IC analysis (2) Mixed-
>signal 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
It see benefit is defining things more clearly and I provide my own take
with justification below.
> - 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.)
I understand in the Verilog standard (LRM or verilogxl itself!), that
the value of digital net before the simulation runs is 'X'.

For analog values, before analog runs (following the VHDL-AMS
precedence), it would seem reasonable that the value of the analog nets
are any ic's set.

> - How should the mixed-signal simulator arrive at an agreeable node
>voltage/state values for interface elements ?
Oleary> When all A2D and D2A events are consuming just like at any other
timestep.

> - Which engine should in fact have a go first ?
Oleary> For initialization, seems to make more sense for digital to go
first a lot of digital initialization happens at t=0 so when analog runs
it is at least seeing initialized digital values. Then it is at least
trying to get convergence with pretty reasonable digital values. It is a
lot easier to converge a digital simulation than an analog one so I
think analog needs all the help it can get!

> - 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.
Oleary>Agree, that would be good to make it clearer.

>
>>
>> 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.
Oleary> It is also reasonable for a CM to have an 'X' input at t=0 and
beyond - user have the power to write their modules so that this is an
error if they so choose.

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

It could also be argued that this is a bad model.

In the AMS synchronization scheme, analog and digital communicate via
events. With AMS, using A2D events analog is integrated into digital's
event framework.

The use should use an always block perhaps with an @timer(0) to get all
these changes e.g.;

	always @timer(0) digVar = V(brn);


However as this is a DC sweep and DC sweeps are not considered in the
LRM, the standard could be defined to say that when a DC sweep is done
that the digital engine is completely restarted at each point.

Therefore there seems to be at least two key choices in terms of how to
define a DC sweep in AMS;
1. Restart the digital simulator at each Dc point.
2. Just delta-cycle the digital simulator at each Dc point.

>
>>
>> 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 ?
I think we should try to standardize so as to get consistent behavior -
otherwise modules will not be as portable.

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