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

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.
Before all this hierarchical contribution mess, the only way to have a 
switch branch was by having a contribution inside a conditional statement.

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.
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.

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.
>
>
>


-- 
=====================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
=====================================