Hi Marq, Marq Kole wrote: > > > 1) Pros: (a) situation just as clear as 0), but now > support for analog blocks in > generate constructs. > (b) model creator still does not have to deal with > concurrency. > Cons: (a) conceptual difference between always blocks > and analog block > (b) no opportunity for optimization based on activity > of a particular > analog block as all blocks are essentially > concatenated together. > > I think I may have been the one that suggested we simply concatenated multiple analog blocks together in the first place, but when I suggested this I wasn't thinking that the scope of the blocks would be removed. I was thinking more that multiple analog blocks at the top level would be treated in the same manner as if I had multiple "begin - end" blocks. I am not sure if the 'Cons (b)' you listed is a problem. Taking the example you posted recently: module test_multiple_analog_blocks (p, n); inout p, n; electrical p, n; parameter real res = 1k from (0:inf); parameter real cap = 1u from (0:inf); real r, c; analog begin c = cap; I(p, n) <+ V(p, n)/r; end analog begin r = res; V(p, n) <+ idt(V(p, n)/c); end endmodule I was thinking that this would internally be treated as if the user had written analog begin begin c = cap; I(p,n) <+ V(p,n) /r; end begin r = res; V(p,n) <+ idt(V(p,n)/c); end end By treating it this way and still maintaining the scope of each of the blocks, it allows an implementation the ability to selectively solve blocks, maybe based on optimizations, or perhaps if "disable" statements are ever implemented in Verilog-AMS. So 'Cons (b)' listed above is not an issue as far as I can see. Cheers... Dave -- ===================================== -- David Miller -- Design Technology (Austin) -- Freescale Semiconductor -- Ph : 512 996-7377 Fax: x7755 =====================================Received on Tue Dec 19 14:42:23 2006
This archive was generated by hypermail 2.1.8 : Tue Dec 19 2006 - 14:42:27 PST