RE: Elaboration algorithm proposal

Marq,

 

Such examples can occur in digital Verilog.

 

In behavioral and testbench code, there is no end to what you can do.

 

In design code, typically it comes up in cross-coupled combinational
logic. As long as it deterministically reaches a steady state, it works.
However, for a synthesis-based tool flow, many tools have problems with
combinational loops.

 

In gate-level logic, it comes up as well. For example, you can build a
flip-flop with cross-coupled NAND gates.

 

Shalom

 

________________________________

From: owner-verilog-ams@server.eda.org
[mailto:owner-verilog-ams@server.eda.org] On Behalf Of Marq Kole
Sent: Monday, December 18, 2006 2:58 PM
To: verilog-ams
Subject: Re: Elaboration algorithm proposal

 


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