Dave Miller wrote: > 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? No, each analog block is independent, top always contributes a flow of 0.0 and other always a potential of 5 (if P is true). > 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 Why would you do that? > > 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. Yep. It's just a connection made directly rather than through a port. Post elaboration the is no need for the simulator to differentiate between connections by OOMR and connections via ports. There are some issues of syntax and how to attribute a discipline to an OOMR and where to insert A/D convertors - but they're not major. IMO you should be able to describe your design without connecting any ports and just wire it all up with OOMRs and it should behave the same. Kev. > > Dave >Received on Wed Dec 27 13:10:18 2006
This archive was generated by hypermail 2.1.8 : Wed Dec 27 2006 - 13:10:35 PST