Re: Elaboration algorithm proposal

Marq Kole wrote:
>
> 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.
If you really want to do that then I suggest you create some explicit 
syntax for that case (see below), just concatenating all the analog 
blocks is too blunt an instrument.
>
> 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.
>
The fact you can write bad code is not limited to blocks in a module, in 
Verilog most things are available to any block through hierarchical 
references, so making a special case of blocks in a module is a bit 
pointless.

Mostly you need to add scope-limiting rules/syntax, and talk to your 
vendors about getting your design rules applied.

> 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?
It's just an example of bad code, you can write bad code in any 
language. The reason it's allowed (in most languages) is because 
sometimes the functionality is required to handle special cases, and 
outlawing it will make the language unusable.

An alternate example would be to use two blocks that share variables 
e.g. power and temperature and have one of the processes working out 
power while the other evaluates heat transfer and calculates 
temperature. Since the two activities are not particularly tightly 
coupled the simulator could evaluate them in separate matrices - which 
will probably be faster. Concatenating the blocks kills off that 
opportunity.

My suggestion for what you want is to add a keyword like "continue" 
before the analog block name if you want to concatenate multiple segments.

Kev.

>
> Cheers,
> Marq
>
>
> Marq Kole
> Competence Leader Robust Design
>
> Research
> NXP Semiconductors