RE: multiple analog blocks

Marq,
there is one more point to consider from the thread.

Kevin made the point that for solution 1 maybe achieved by supporting a
continued analog block.

This creates another option which may solve the impass.

A continued analog block would be considered an addition to a previous
analog block and not a separate
analog block and hence would be evaluated at the same time steps.

analog variables would continue to be owned by only one analog block but
this would mean that a
continued analog block could access the same variables as the block it
extends.

e.g.

module test_multiple_analog_blocks (p, n);
inout p, n;
electrical p, n;
parameter real res = 1k from (0:inf);
parameter real cap = 1u from (0:inf);

real r, c;

analog begin
c = cap;
I(p, n) <+ V(p, n)/r;
end

analog continue begin
   r = res;
   V(p, n) <+ idt(V(p, n)/c);
end

endmodule


Also following on this I think it might be time to create a proper
analog initial block in which bias dependent operations are not
supported (probes, contributions). 

In this block initialization would be done. This would mean
initialization could be done before an analysis ran rather than at the
first step and I believe would enable more simulator optimizations
particularly for compact models.

I don't think the @initial_step approach works very well particularly
for compact models.

example;

module test_multiple_analog_blocks (p, n);
inout p, n;
electrical p, n;
parameter real res = 1k from (0:inf);
parameter real cap = 1u from (0:inf);

real r, c;

analog initial begin
   r = res;
end

analog begin
c = cap;
I(p, n) <+ V(p, n)/r;
end

endmodule

Thanks,
--Martin


________________________________

        From: owner-verilog-ams@eda.org
[mailto:owner-verilog-ams@eda.org <mailto:owner-verilog-ams@eda.org> ]
On Behalf Of Marq Kole
        Sent: Tuesday, December 19, 2006 1:51 PM
        To: verilog-ams@verilog.org
        Subject: multiple analog blocks
       
       

        All,
       
        Although it momentarily seemed that section 7 was nearly at the
end of the review, I cannot escape the notion that there is still no
resolution on the multiple analog blocks issue. Let me rephrase the
possible options brought forth during the past couple of weeks
discussion.
       
        0) (current situation) multiple analog blocks are not supported.
       
        1) multiple analog blocks in a single module are supported under
the condition that during elaboration they are concatenated into a
single analog block. The consequence is that analog blocks differ from
always and initial blocks in that their order of appearance is
important. This prevents ambiguity/race conditions in the model
behavior.
       
        2) multiple analog blocks in asingle module should behave as
though they were implementing separate entities and therefore their
order of appearance should not matter. Analog blocks are considered to
be run concurrently; ambiguity/race conditions need to be resolved
through better programming.
       
        Question: Does this correctly reflect the current state of the
discussion?
       
        Provisionally assuming an affirmative answer to the above
question, let me try to phrase the pros and cons to above positions
       
        0)        Pros:        (a) clear situation, no ambiguity/race
conditions can occur.
                        (b) protects model creator from having to deal
with concurrency.
                Cons:        (a) no support possible for analog blocks
in generate constructs.
       
        1)        Pros:        (a) situation just as clear as 0), but
now support for analog blocks in
                              generate constructs.
                        (b) model creator still does not have to deal
with concurrency.
                Cons:        (a) conceptual difference between always
blocks and analog block
                        (b) no opportunity for optimization based on
activity of a particular
                              analog block as all blocks are essentially
concatenated together.
       
        2)        Pros:        (a) analog blocks and always blocks have
similar semantics,
                              possibly easier for mixed-signal model
developers.
                        (b) allow activity-based simulation performance
optimization per
                              analog block.
                Cons:        (a) concurrency issues (race conditions)
enters analog/mixed-signal
                              environment
                        (a1) handling of module-level variables
                        (a2) handling of OOMR variables
                        (a3) switch branches
                        (a4) value retention
                        (b) supports "bad" programming
       
        Question: Are the above pros and cons correct? Is anything
missing?
       
        My hope is that if we can get some sort of agreement on the
current situation of the discussion, we may get to a resolution on this
item for section 7 for the coming LRM update.
       
        Cheers,
        Marq
       
       
        Marq Kole
        Competence Leader Robust Design
       
        Research
        NXP Semiconductors