Hi Marq, Marq Kole wrote: > > All, > > Regarding the ambiguity of transition evalution in the case of > multiple analog blocks, don't we have the same situation currently > when combining a regular contribution with a transition with an OOMR > contribution with a transition for the same unnamed branch? Well I am still in the dark on the whole hierarchical reference. I was under the impression that your example below meant that there was only one branch between n1 and n2 and that both contributions were contributing to the same branch (i.e. matrix contains row for n1, n2 and current(n1,n2)) But then I think it was suggested that the OOMR contribution is actually a unique unnamed branch between nodes n1,n2. If this is the case, then your behavioral code for module mod2(n1,n2); would be that same as if you had written: analog V(n1, n2) <+ *transition*((*$abstime* % 10n) < 5n, 10n, 5n); In this situation, I think the transitions simply add up so become a combination of both? Dave > > *module *mod1 (n1, n2); > *inout *n1, n2; > electrical n1, n2; > > *analog* > V(n2, n1) <+ *transition*((*$abstime* % 10n) < 5n, 5n, 5n); > > *endmodule *// mod1 > > *module *mod2 (n1, n2); > *inout *n1, n2; > electrical n1, n2; > > mod1 inst1 (n1, n2); > > *analog* > V(inst2.inst1.n1, inst2.inst1.n2) <+ *transition*((*$abstime* > % 10n) < 5n, 10n, 5n); > > *endmodule *// mod2 > > *module *top; > electrical n1, n2; > > mod2 inst2 (n1, n2); > > *endmodule *// top > > Which transition will be evaluated first? According to section 4.4.9 > there will be two rather different results depending on the order of > evaluation. I can find no information in either section 7 or section 9 > that would resolve this issue. > > Cheers, > Marq > > > Marq Kole > Competence Leader Robust Design > > Research > NXP Semiconductors > > > > > > > > > *Marq Kole <marq.kole@nxp.com>* > > Sent by: > owner-verilog-ams@server.eda.org > > 23-01-2007 11:05 > > > To > "verilog-ams" <verilog-ams@server.eda-stds.org> > cc > > Subject > transition function > Classification > > > > > > > > > > > > All, > > Transition functions can introduce ambiguities on signals that have > multiple transitions defined for them. According to section 4.4.9 of > the Verilog-AMS 2.2 LRM: > > “With different delays, it is possible for a new transition to be > specified before a previously specified transition starts. The > transition function handles this by deleting any transitions which > would follow a newly scheduled transition. A transition function can > have an arbitrary number of transitions pending.” > > Consequently, it seems to me that when a new transition is applied to > a signal that already has a transition pending then the new transition > is added to the transition function if the new delay is larger, but > any existing transition with a larger delay would be removed. > > However, if the transitions are applied in different concurrent analog > constructs the order of evaluation of these analog constructs becomes > important. > > Would there be any problem with assigning all transitions defined on a > signal, unless the transitions are assigned in a single analog block? So: > > analog > y = transition(x1, 5n, 5n); > > analog begin > y = transition(x1, 10n, 5n); > y = transition(x2, 15n, 5n); > end > > Would have all three transitions pending for signal y, independent of > the order of evaluation of the two analog blocks, and: > > analog > y = transition(x1, 5n, 5n); > > analog begin > y = transition(x2, 15n, 5n); > y = transition(x1, 10n, 5n); > end > > Would only have the transitions from signal x1 pending, as the > transition from signal x2 in the second analog block is deleted per > section 4.4.9 as the second transition from signal x1 has a shorter > delay. Again, independent of the order of evaluation of the two analog > blocks. > > The above approach would keep the concurrency of multiple analog > blocks, while at the same time being backwards compatible with the > Verilog-AMS 2.2 LRM. The only alternative I see is to disallow > transitions from multiple analog blocks. Any other suggestions? > > Cheers, > Marq > > > Marq Kole > Competence Leader Robust Design > > Research > NXP Semiconductors > > -- > This message has been scanned for viruses and > dangerous content by *_MailScanner_* <http://www.mailscanner.info/>, > and is > believed to be clean. > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. -- ===================================== -- David Miller -- Design Technology (Austin) -- Freescale Semiconductor -- Ph : 512 996-7377 Fax: x7755 ===================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jan 23 05:30:58 2007
This archive was generated by hypermail 2.1.8 : Tue Jan 23 2007 - 05:31:07 PST