Re: Elaboration algorithm proposal

From: Marq Kole <marq.kole_at_.....>
Date: Mon Dec 18 2006 - 04:57:50 PST

Kev,

Thanks for your input; let me state first that if there is a way to safely handle multiple analog blocks the same way as multiple always blocks, I'd be all in favor of adding this to the language definition of Verilog-AMS. Up to now we didn't see such a way and therefore opted for the safe approach of concatenation-on-elaboration, because that way we could at least handle generate constructs with analog blocks in them.

One of the arguments for Verilog-A over any more generic programming languages is the added security -- there are fewer things to botch for a non-programmer in Verilog-A over, for example, C/C++. So bad programming practise is -- however unfortunate -- probably something we have to take into account. If we can provide failsafes to prevent the worst consequences of these bad programming practises to arise in the model behavior itself, the more likely Verilog-A is adopted as a language of choice for the programmatically-less-proficient analog, mixed-signal or RF electronic designers. The downside is of course that bad programming practises will remain around for longer as they will probably not be sufficiently punished to make the practitioner change his evil ways.

Let me also quote a response from Ken Kundert on the issue of multiple analog blocks:

>     The only issue I am aware of with multiple analog blocks is the
> sharing of variables, much like the issue of analog block sharing
> variables with digital blocks. There are race condition issues that we
> have to be careful of. Presumably we would have the variables owned by a
> particular analog block, but even with this there are issues. Consider
> two analog blocks, b1 and b2, and two variables, v1 and v2. Assume that
> v1 is owned by b1 and so can only be assigned in b1. Similarly, v2 is
> owned by b2. Now assume that in b1 a value is assigned to v1 that
> depends on the value of v2. Further assume that in b2 a value is
> assigned to v2 that depends on v1. How does one reconcile the fact that
> these two assignments are expected to occur simultaneously?
(from: http://www.eda-stds.org/verilog-ams/hm/1643.html)

To put the proposed example of Ken into code:

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
    begin
      r = res;
      V(p, n) <+ idt(V(p, n)/c);
    end

endmodule

Of course: definitely a bit contrived example. Maybe the kind of warning that would help a user is something like "variable r possibly used before given a value in owning block"...

If there is a way to either find a way to add restraints to the language that prevents this issue from occurring in the language by making it illegal or by making it detectable and warning the user of the consequences, I would support that multiple concurrent analog blocks would be the way to go.

Could the above example from Ken be coded in digital Verilog? If so, what would be the consequences; if not, what are the restrictions that prevent this code from being accepted?

Cheers,
Marq


Marq Kole
Competence Leader Robust Design

Research
NXP Semiconductors
 Received on Mon Dec 18 05:01:14 2006

This archive was generated by hypermail 2.1.8 : Mon Dec 18 2006 - 05:01:26 PST