implicit sensitivity of the analog block


Subject: implicit sensitivity of the analog block
From: Martin O'Leary (oleary@cadence.com)
Date: Tue Sep 03 2002 - 16:34:13 PDT


Over the last number of weeks at the LRM conf call, we have spoken back and forth about
whether an analog block containing references to digital signals should be implicitly
sensitive to these signals or not.

If implicity sensitivity is defined thus;

    "Analog processes are implicitly sensitive to all digital value
     references which are not 'guarded' by an event control statement."

Here are a number of points on why implicit sensitivity is
the better choice IMHO.

1) Without implicity sensitivity, the user is at mercy of analog timestep control
Consider the following example;

        module mixed1(clk,vout);
        wire clk;
        electrical vout;

        integer np; initial np =0;

        always @(posedge clk)
                np = np + 1;

        analog V(a) <+ np;

        endmodule

Without implicit sensitivity, V(a) will be updated when
ever the analog kernel is run. If np changed, it will not
be updated, leading to likely erroreous results.

Consider the following simulation timelines;

Analog 0--------------------------2-----------6

Digital 1-----3--4---5-----------------7--------

Here the numbers represent the sequence in which
the kernels run. The associated times are called
tN e.g. t1, t2 ... Note the tN-1 is not necessarily
less than tN. e.g t2 is not less than t3!!

The kernels initialize at time=0 with analog
running (0) and then digital running (1).

Beyond time=0 analog goes first (2 t=t2), then digital
(3 t=t3), then digital again (4 = t4), then digital
again (5 t=5), then analog (6 t=t6) and then digital.
Note - no d2a/a2d events occur.

Analog will choose t2 on the basis of time-step control.
When analog solves at t2, the digital simulator hasn't
executed; so therefore analog will consider np to be
'0' and will solve accordingly.

When digital gets control, at t3 it will calculate np=1,
at t4, np will be 2, at t4 np will be 3.

This means that when analog solved at t2, it used the
WRONG value for np!!! it should have used 3 not 0!!!!

Similar when analog gets control, time step selection
chooses t6 and it solves using np=3 when it should
have solved using np=4 calculated at t7.

Here I say that the behavior is at the mercy of time
step selection, because t2 and t6 were choosen by
this analog kernel mechanism. This mechanism
will vary from design to design and from simulator to
simulator and hence is highly non-standard!

2) Without implicit sensitivity, the user has to add sensitivity
   to all digital values referenced

   If the analog block is not implicitly sensitive to digital
   signals, then the user will have the inconvenience of adding
   event controls to his/her analog block in order to ensure that
   the module is behaving correctly.

   This means that the user has to type every digital signal he
   needs access to twice once to reference it and once to be
   sensitive to it. The obviously makes the language harder
   and riskier to work with.

   But what about the implicit event_expression ;"@*" that was
   introduced in Verilog-2001?? Doesn't this solve this issue?

   This has a number of issues.
   
   1) this is illegal as the contribution statement or indeed other
      analog contructes are not allowed to be used inside an event
      control;

        analog @*
                V(a) <+ np;
        This means that I cannot cover all my analog blocks with @*
  
   2) @* will also make the analog block sensitive to signals that
      are not necessary;

      analog begin
                @* begin
                        aVal1 = dVal1;
                        @(clk) aVal2 = dVal2;
                end
        .....
        end

        In this example the analog block will be sensitive to changes
      in dVal2 when this is not necessary as dVal2 only needs to be
      sampled with clk changes.

3) analog block does not support blocking-control

   The digital behavioral blocks follow a "blocking-control" semantic;
   i.e. all the statements in digital behavioral block will not
   necessarily be executed at the one time.

   e.g.

        always begin
                @(clk)
                        out = #1 in;
                out2 = in2; // this statement will not run until @clk is exec'd
                display("out is assigned\n");
        end

   So making the always block implicity sensitive to referenced signals
   is not a good idea. e.g. consider "out2" in the above example.

   However the analog block supports "non-blocking control" - i.e. all
   the statements in the analog block not disallowed by conditionals
   will execute at the one time. Here implicit sensitivity makes
   sense because when the analog block is executed at a particular time,
   the digital reference that caused the re-execution will be
   re-referenced as well.

4) Digital already has a precedence of implicit sensivity for the
   continuous assignment statement.

   From Verilog-LRM;
   
   "5.6.2 Procedural continuous assignment

   A procedural continuous assignment (which are the assign or force statement; see 9.3) corresponds
   to a process that is sensitive to the source elements in the expression. When the value of the
   expression changes, it causes an active update event to be added to the event queue, using current
   values to determine the target. A deassign or a release statement deactivates any corresponding
   assign or force statement(s)."



This archive was generated by hypermail 2b28 : Tue Sep 03 2002 - 16:36:29 PDT