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
-----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 Sun Feb 13 20:34:13 2005
This archive was generated by hypermail 2.1.8 : Sun Feb 13 2005 - 20:34:14 PST