Re: Verilog-AMS Committee Meeting Minutes - Dec 22 2006

Dave Miller wrote:

> Hi Kevin,
>
>>>> IMO the statement in 5.3.13 is fairly meaningless: there is no way 
>>>> from within a module that you can tell that a branch you are 
>>>> connecting to is a switch branch in some other module (doesn't 
>>>> matter if it's OOMR or not). So if it is illegal it's going to be a 
>>>> elaboration/runtime error, but personally I see no reason for it to 
>>>> be illegal. I'd vote for striking the sentence.
>>>
>>>
>>>
>>> Well I'm not too sure on that, I think that is very implementation 
>>> specific. 
>>
>>
>> It's only implementation specific if the implementation can't do 
>> switch branches, but I'd assume most can since switch branches are 
>> allowed. The only bad case for switch branches (causing a 
>> elaboration/runtime error) is if you have multiple different 
>> potentials applied to the same branch, but for the case which is ok 
>> (you have multiple potential contributions of the same value)  it's 
>> the same as having one, i.e. the simulator never has to deal with 
>> solving more than one switch contribution on a branch .
>
>
> Umm, I don't follow, you said "there is no way from within a module 
> that you can tell that a branch you are connecting to is a switch 
> branch in some other module (doesn't matter if it's OOMR or not)."
> I am saying that this is fairly trivial to detect, hence what I mean 
> by implementation specific.
>
>>
>>> I can certainly tell if a hierarchical contribution to a branch 
>>> turns it into a switch branch.
>>
>>
>> I think you may have the wrong definition of "switch branch", it's 
>> not a switch branch unless the contribution from an analog block can 
>> actually switch between potential and flow. It's problematic for the 
>> simulator because it may have to restructure the matrix used to solve 
>> the circuit when the branch usage changes.
>>
>
> My definition of a switch branch is a branch between two nodes where 
> it is possible to contribute to either nature during the simulation. 
> However it is important to ensure that you only contribute to one 
> particular nature during a time step. You can't switch contribution 
> types during iterations of a time step.

There isn't really anything happening "during a time step", you just 
evaluate the code at the start and then again at the end for the next 
time step. If it doesn't look stable the solver will probably just 
shorten the time step.

> Before all this hierarchical contribution mess, the only way to have a 
> switch branch was by having a contribution inside a conditional 
> statement.

That's still true with OOMRs  - OOMRs are static connections evaluated 
during elaboration (as are port connections).

>
> So here is the example I was thinking of where the hierarchical 
> contribution changed (a,b) into a switch branch. I feel this sort of 
> usage should be disallowed:
>
> module top(a,b);
>    electrical a,b;
>    analog I(a,b) <+ 0;
> endmodule
>
> module other();
>    parameter P = 0;
>    analog begin
>       if(P)
>          V(top.a,top.b) <+ 5;
>    end
> endmodule
>
> Because I don't know which order the instances are going to be solved, 
> so I could swap back and forth between a potential or flow 
> contribution during a particular time step.

As I said before the code is not evaluated that way in the simulator, 
the sequential nature of the code only applies within an individual 
analog block. Since you can't update any values until the matrix is 
solved the simulator evaluates each block with a snapshot of the initial 
conditions, and the only interaction between the analog blocks is 
through the solver.

For the case above you have one 0.0 current contribution and a voltage 
contribution of 5.0 (if P is true) or another 0.0 current contribution 
(which has no effect). A trickier case is:

module top(a,b);
   electrical a,b;
   reg        sw1;
   assign     sw2 = !sw1;
   other #(1.0) (sw1);
   other #(2.0) (sw2);
   initial sw1 = 0;
endmodule

module other(input sw);
   parameter Vo = 0;
   analog begin
      if(sw)
          V(top.a,top.b) <+ Vo;
   end
endmodule

In theory the two "others" should not drive potential at the same time 
so the two switch branches should not conflict, but a simple analysis of 
the blocks would probably say conflict was possible.

> Maybe we should simply disallow multiple contributions to a branch if 
> that branch is involved in any hierarchical contributions? I say that 
> because this is also bad:
> analog begin
>    V(top.a,top.b) <+ 5;
> end

>
> Although this is not a switch branch, it can possibly switch 
> contribution types depending on order of instance evaluation.

Although ordering is an issue for digital, there really is no ordering 
to analog block evaluation. Each analog block forms a separate 
contribution to the branch, and the resolution of those contributions is 
done in parallel. The only problem is that you can't resolve multiple 
potential contributions of different values to the same branch.

Another way to look at: here's a simple component that you might want 
lots of:

module fuse(a,b)
  parameter blown = false;
  electrical a,b;
  analog if (!blown) V(a,b) <+ 0.0;
endmodule

- Why should I not be able to put a few in parallel?

Kev.

>
> Cheers...
> Dave
>
>>> I would certainly prefer to keep a restriction in place that 
>>> prevents users contributing hierarchically to switch branches. It 
>>> seems to me that it would be more likely something they would do 
>>> accidentally, so would probably like to be warned about it.
>>>
>>> Dave
>>
>>
>> I have no problem with issuing warnings.
>>
>> Kev.
>>
>>
>>
>
>