Subject: Re: Related Question [Re: your question about digital variable access]
From: Martin O'Leary (oleary@cadence.com)
Date: Fri Mar 16 2001 - 18:54:32 PST
(answer in included message)
On Mar 16, 2:38pm, Graham Helwig wrote:
> Subject: Related Question [Re: your question about digital variable access
>
> Hello Martin and Ian,
>
> A secondary issue but related is descibed below:
>
> What value should the variable 'st' return when access in the digital
> behaviour. I would expect the previous and current analog timepoint to
> be before and after the digital time respectively. I can see 2 methods
> to obtain the 'st' value in the digital context:
> 1) interpolate the 'st' value using the previous and current analog
> time points.
> 2) use the previous time point 'st' value only.
>
> The method to be used is determined based on how the user intends to use
> the variable within the module behaviour. These usages can be classified
> into the following types:
> a) storage of continuous values
> b) storage of discrete values changing at discrete intervals.
>
> Note, a mixture of these types of variables may appear within a single
> module.
>
> Based on this, which method should be used to determine the value of
> analog variables accessed in the digital context?
Graham,
I think that interpolation makes most sense for analog signals.
After all the analog kernel is trying to simulate continuous signals.
References to voltages e.g. V(a) and analog real variables should be
interpolated. However interpolating analog integers is a bad idea so
I suggest that that the previous time point value be used for those,
--Martin
>Is there an
> alternative that I have not considered yet?
>
> Regards
> Graham
>
> --
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Graham Helwig email: A11558@email.mot.com
> ghelwig@asc.corp.mot.com
> Telephone:+61-8-82033532 Fax:+61-8-82033501
> Motorola Australia Software Centre,
> 2 Second Avenue, Technology Park, Adelaide, SA, 5095, Australia
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> [ message/rfc822 ] :
>
> Return-Path: <ghelwig@asc.corp.mot.com>
> Received: from worf.asc.corp.mot.com (worf [217.1.104.70])
> by fraser.asc.corp.mot.com (8.8.7/8.8.7) with ESMTP id OAA09992;
> Fri, 16 Mar 2001 14:32:49 +1030 (CST)
> Received: from asc.corp.mot.com (localhost [127.0.0.1]) by
worf.asc.corp.mot.com (8.8.8+Sun/8.7.3) with ESMTP id OAA11892; Fri, 16 Mar
2001 14:32:48 +1030 (CST)
> Sender: ghelwig@asc.corp.mot.com
> Message-ID: <3AB19068.A89FCB98@asc.corp.mot.com>
> Date: Fri, 16 Mar 2001 14:32:48 +1030
> From: Graham Helwig <ghelwig@asc.corp.mot.com>
> Organization: Motorola Australia Software Centre
> X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.5.1 sun4u)
> X-Accept-Language: en
> MIME-Version: 1.0
> To: "Martin O'Leary" <oleary@cadence.com>, Ian Wilson <imw@antrim.com>
> CC: verilog-ams@eda.org
> Subject: Re: your question about digital variable access
> References: <003401c0a1e7$fccec320$cd01a8c0@imw-laptop.ANTRIM.COM>
<1010315182038.ZM511@cds8364>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> X-Mozilla-Status2: 00000000
>
> Hello Martin and Ian,
>
> After thinking this through, this seems like a reasonable solution to
> the problem.
>
> But, I'm not sure how to handle modules that used cross-domain variables
> in the following way:
>
> module mixed2(clk,vout);
> wire clk;
> electrical vout;
>
> integer np; initial np =0;
> integer vu;
> real st;
>
> always @(posedge clk) begin
> np = np + 1;
> vu = st + ... ;
> end
>
> analog begin
> @np;
> V(a) <+ np;
> ...
> st = V(a) + 1;
> end
>
> endmodule
>
> Variable 'np' determines variable 'vu' value through variable 'st' and
> node 'a'.
> Variables 'np' and 'vu' are digital, while variable 'st' is analog. In a
> MS simualtion when a 'clk' posedge edge occurs the the new 'vu' value
> will be incorrect because the analog time point has not been
> recalculated yet.
>
> How should this erronious behaviour be handled? Should this behaviour be
> illegal? If yes, how should the language prevent this from occurring?
>
> Regards
> Graham
>
> > In the last meeting you gave a similar example as the following
> >
> > module mixed1(clk,vout);
> > wire clk;
> > electrical vout;
> >
> > integer np; initial np =0;
> >
> > always @(posedge clk)
> > np = np + 1;
> >
> > analog V(a) <+ np;
> >
> > endmodule
> >
> > I understand the question you posed was what values of 'np' should be seen
> > in analog block and when.
> >
> > In terms of accessing digital variables in the analog block, section
> > 8.3.6.4 of the LRM;
> >
> > In this case, a digital primary (reg, wire, integer, etc.) whose value is
> > calculated in the discrete domain appears in an expression which is in
the
> > analog context; thus the analog primary is evaluated in the continuous
> > domain.
> >
> > The expression shall be evaluated using the digital value
> > calculated for the greatest digital time tick which is less than or equal
> > to the analog time when the expression is evaluated.
> >
> > This approach does not give very predictable behavior for V(a). Basically
> > the value of V(a) depends on how large a time-step analog takes. In a
> > analog circuit with large time constants, the value of np that analog
> > sees could be very old.
> >
> > If the model is rewritten such that the analog block is made sensitive to
> > np, it is clearer what the value of V(a) will be as the "@np" ensures that
> > an analog time-point will occur when np changes and hence that V(a) will be
> > updated when np changes.
> >
> > module mixed2(clk,vout);
> > wire clk;
> > electrical vout;
> >
> > integer np; initial np =0;
> >
> > always @(posedge clk)
> > np = np + 1;
> >
> > analog begin
> > @np;
> > V(a) <+ np;
> > end
> >
> > endmodule
> >
> > However because module mixed1 gives such unpredictable behavior, I believe
> > that the LRM should be changed so that adding the event control is not
> > neccessary to get predictable results.
> >
> > To this end I propose we change 8.3.6.4 of the LRM to the following.
> >
> > In this case, a digital primary (reg, wire, integer, etc.) whose value is
> > calculated in the discrete domain appears in an expression which is in
the
> > analog context; thus the digital primary is evaluated in the continuous
> > domain.
> >
> > The expression shall be evaluated using the digital value
> > calculated for the greatest digital time tick which is less than or equal
> > to the analog time when the expression is evaluated.
> >
> > If the digital primary's value changes during subsequent digital time
ticks
> > which are less than or equal to the analog time when the expression the
> > was last evaluated, the analog solution must be recalculated using the
> > new digital primary value.
> >
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Graham Helwig email: A11558@email.mot.com
> ghelwig@asc.corp.mot.com
> Telephone:+61-8-82033532 Fax:+61-8-82033501
> Motorola Australia Software Centre,
> 2 Second Avenue, Technology Park, Adelaide, SA, 5095, Australia
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>-- End of excerpt from Graham Helwig
This archive was generated by hypermail 2b28 : Fri Mar 16 2001 - 18:57:55 PST