From: Marq Kole <marq.kole_at_.....>
Date: Wed Dec 20 2006 - 00:46:41 PST
Dave,
Yeah, you're right. There's also Geoffrey
Coram's MOS11 example on the Designer's Guide website. This model relies
on compiler optimization at the level of named sequential blocks to handle
the initializations and thermal calculations efficiently.
Cheers,
Marq
Marq Kole
Competence Leader Robust Design
Research
NXP Semiconductors
Dave Miller <David.L.Miller@freescale.com>
Sent by:
owner-verilog-ams@server.eda.org
19-12-2006 23:42
To
Marq Kole <marq.kole@nxp.com>
cc
verilog-ams@server.verilog.org
Subject
Re: multiple analog blocks
Classification
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 Wed Dec 20 00:49:10 2006
This archive was generated by hypermail 2.1.8
: Wed Dec 20 2006 - 00:49:21 PST