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

edaorg@v-ms.com wrote:
> 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.
>>>

But for a given timestep, the simulator solves each instance through a 
set of iterations using the previous timestep's converged values as a 
starting point. Lets assume that it does 2 iterations, and that P == 1 
(I didn't mean to have 0). If it solves each instance in some seemingly 
random order, maybe due to parallel processing, then on the first 
iteration, we load a potential contribution between circuit nodes a and 
b of 5 volts. On the second iteration, we happen to solve instance top 
last, hence we load a flow of 0 between a and b. This is going to mean 
that we won't converge, so it does possibly another iteration and gets a 
different answer and so on.
This is a problem isn't it?
While writing this, I am assuming that the hierarchical reference is the 
same as if you had it in the same analog block (hence the sequential 
nature applies), i.e.
analog begin
I(a,b) <+ 0;
if(P)
    V(a,b) <+ 5;
end

on iteration one. And then on iteration two
analog begin
if(P)
    V(a,b) <+ 5;

I(a,b) <+ 0;
end

Is this the wrong way to look at hierarchical contributions.

Dave

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