RE: When does w change?

Kev,

By "analog variable", I mean a variable of the analog domain:

8.2.2 Contexts
... The domain of a variable [analog or digital] is that of the context
from which its value is assigned.

Assume for the sake of argument that e is an analog variable (the w
change puzzle is only an incomplete fragment of code).

It seems to me that sin($abstime) has got to mean what it says, given
the current value of its argument at the analog solution point.

I think Jon's idea of a "guarded" analog variable and Kev's idea of a
"discretely updated variable" could be formalized. A "guarded" analog
variable or a "discreetly updated variable" is a variable assigned in an
analog block within the statement of an event control. Only guarded
analog variables may appear in an assign statement.

Ken

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of edaorg@v-ms.com
Sent: Monday, February 14, 2005 4:34 AM
To: verilog-ams@eda.org
Cc: Bakalar, Kenneth
Subject: Re: When does w change?

I think you are tackling the wrong problem there. In order to get
consistent behavior across multiple simulators we should just clarify
how the expression "sin($abstime)" is evaluated. Also, the language is a
mixed-signal language and the variable in question (e) is used by both
analog and digital processes, it is value is updated discretely and is
an unresolved type so I see no reason for calling it an "analog
variable" and adding the restriction.

This is the kind of thing that (smart) tools can give warnings for, and
profilers will also tell you where your code is inefficient. I see no
need to modify the language, I just see a need for better tools - as
with programming C or any other language.

Kev.

Bakalar, Kenneth wrote:

>John D.,
>
>I agree that your rewrite was the probable intent of the author (my
>customer), but I disagree with your philosophical point. This committee

>has the responsibility of defining which strings of characters are
>legal models, and for each such legal case, to write down what the
>behavior should be. We can't dismiss cases like this because they seem
unlikely.
>
>What was the author thinking? Reasonably, that the relational operator
>with an operand that contains (in some convoluted sense) an analog
>variable causes action only (more or less exactly) at the transition
>point, not on all changes in the operand, whenever they may occur. An
>engineer not steeped in the details of mixed signal languages will make

>this same erroneous assumption in an analog context, often with
>surprising and paradoxical results.
>
>Contrast this statement:
>
> assign hiclk = clk&(e>0);
>
>hiclk is, roughly, a copy of clk that has edges only when e>0,
>approximately, under the Jon/Kev interpretation. This looks reasonable
>to -- it is just that the performance is unacceptably bad, as Jon S
>points out. I imagine it would also increase the complexity and reduce
>the overall performance of an implementation, since the "analog
>sensitivity events" have to be accounted for.
>
>I can't think of a cases in which it would be interesting to recognize
>all those events on e. Jon, can you give an example?
>
>Suppose we adopt the strategy implied by John D. ("Without the @cross,
>there is never an EVENT to drive the update in the digital side.") If
>we remove analog variables from the sensitivity list of the assign the
>hiclck problem goes away. Of course, the w change example fails, but at

>least it doesn't take too long to fail. It is hard to describe this
>idea using the current language of the LRM, since the sensitivity list
>of a process is not defined.
>
>How about forbidding the occurrence of an analog variable in an
>expression on the right side of an assign? That makes it impossible for

>a user to make the W change puzzle mistake, but it also forbids the
>hiclk case. And what do you do with integer analog variables? Same
rule?
>
>Ken
>
>
I think you are tackling the wrong problem there. In order to get
consistent behavior across multiple simulators we should just clarify
how the expression "sin($abstime)" is evaluated. Also, the language is a
mixed-signal language and the variable in question (e) is used by both
analog and digital processes, it is value is updated discretely and is
an unresolved type so I see no reason for calling it an "analog
variable" and adding the restriction.

This is the kind of thing that (smart) tools can give warnings for, and
profilers will also tell you where your code is inefficient. I see no
need to modify the language, I just see a need for better tools - as
with programming C or any other language.

Kev.

>
>
>-----Original Message-----
>From: Jonathan Sanders [mailto:jons@cadence.com]
>Sent: Saturday, February 12, 2005 1:02 PM
>To: Bakalar, Kenneth; verilog-ams@eda.org
>Subject: Re: When does w change?
>
>Ken,
>
>Digging way back into discussions when Antrim was still a company
>(~1999) and we were attempting to complete LRM 2.0 we found this to be
>bad form but allowable. Users should "guard" this access to gain
>better control but I've seen unguarded access work for certain
situations.
>
>Anyway at time zero "e" would be evaluated by the analog engine and
>trigger an initial event that would set "w". Then since digital has no

>events schedule the only time "w" would change would be a function of
>the analog time step. At each analog time step "e" would be
>re-evaluated (and based on the expression) and change value thus
>triggering an analog sensitivity "event" in the digital world.
>
>The problem is that each simulator has its own time step algorithm so
>results would be a function of accuracy settings including the
>simulators time step algorithm, not wrong just a function of. This can

>also be very slow as the solvers end up working in lock step.
>
>Note: section 6.1.2 is repeated in the AMS LRM in section
>9.4.3.1 and this concurrency behavior is discussed in section 8.3, 9.3,

>and
>9.4 although maybe more clarity is needed?
>
>Jon
>
>***********************************************************
>Jonathan L. Sanders
>Product Engineering Director
>Custom IC Solutions
>Cadence Design Systems, Inc.
>555 River Oaks Pkwy
>San Jose, CA. 95134
> INTERNET:jons@cadence.com Tel: (408) 428-5654 Fax : (408)
>944-7027
>***********************************************************
>
>
>-----Original Message-----
>From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
>Behalf Of Kevin Cameron
>Sent: Friday, February 11, 2005 8:51 PM
>To: Jonathan David; verilog-ams@eda.org
>Subject: RE: When does w change?
>
>
>I would have thought there would be an event on e at every timestep.
>All the @cross does is make sure you get one at the moment the crossing

>occurs - i.e. without the @cross there will be some delay between the
>time sin($abstime) crosses 0 and the assign is performed.
>
>Kev.
>
>-----Original Message-----
>From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
>Behalf Of Jonathan David
>Sent: Friday, February 11, 2005 4:12 PM
>To: verilog-ams@eda.org
>Subject: RE: When does w change?
>
> It would never have occurred to me to TRY that syntax.
>What I would have used would be..
>module x;
> real e;
> reg d = 0;
> wire w;
> analog e = sin($abstime);
> always @(cross(e)) d = (e > 0.0);
> assign w = d;
>endmodule
>
>Which I think is your intent..
>and should enable you to answer the question.
>Without the @cross, there is never an EVENT to drive the update in the
>digital side.
>
>Jonathan David Mixed-Signal IC
>jbdavid@cadence.com Ph (408)894-2646
>
>-----Original Message-----
>From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
>Behalf Of Kevin Cameron
>Sent: Friday, February 11, 2005 3:58 PM
>To: Bakalar, Kenneth; verilog-ams@eda.org
>Subject: RE: When does w change?
>
>
>I would have thought the assign would be evaluated anytime e changes,
>which begs the question when does the analog statement get evaluated? -

>Is there a maximum/minimum timestep that applies here?
>
>Kev.
>
>-----Original Message-----
>From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
>Behalf Of Bakalar, Kenneth
>Sent: Friday, February 11, 2005 3:00 PM
>To: verilog-ams@eda.org
>Subject: When does w change?
>
>All,
>
>Here is a puzzle. At what series of simulation times is the process
>associated with the "assign" executed?
>
>module x;
> real e;
> wire w;
> analog e = sin($abstime);
> assign w = (e > 0.0);
>endmodule
>
>
>"6.1.2 The continuous assignment statement [Verilog 2001]
>
>....Assignments on nets shall be continuous and automatic. This means
>that whenever an operand in the righthand side expression changes
>value, the whole right-hand side shall be evaluated and if the new
>value is different from the previous value, then the new value shall be

>assigned to the left-hand side..."
>
>
>Regards,
>Ken
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
Received on Mon Feb 14 06:52:24 2005