Date: Mon Jan 31 2011 - 10:12:50 PST
Jim, nice picture :)
I think, the crucial point is, that typically for 99.9999% of the nets the traditional approach works perfectly well.
To cope with the rest, that tends to show up in complex practical cases of AMS verification, one needs a powerful methodology.
Metaphorically we talk about the few edged stones on the road.
So in my experience, it is not only about HF- or deep-submicron scenarios.
When we have a complex design with many power domains/states, lots of built-in test circuits, a mix of real-value and digital models
and many hierarchy levels, then Murphy will strike. Users need a strong methodology to strike back, otherwise simulation brakes down.
Achim
----- Original Message -----
From: Lear, Jim
To: 'Achim Bauer'
Cc: 'sv-dc@eda.org'
Sent: Monday, January 31, 2011 5:07 PM
Subject: RE: [sv-dc] Questions on late resolution function association
Achim,
Ultimately, it would be nice to treat nets as subcircuits or modules instead of nets. Deep submicron and high frequency design have made the idea of ideal nets obsolete. Treating interconnects as circuits, such as shown below, better reflects reality. But our languages and schematic tools were designed back when wires were perfect. This committee is moving us in the right direction, though, on the language front.
Kindest Regards,
Jim Lear
Cirrus Logic
(512) 851-4612
(512) 293-7248 (mobile)
-----Original Message-----
From: Achim Bauer [mailto:a-bauer@exl-modeling.com]
Sent: Monday, January 31, 2011 9:23 AM
To: Lear, Jim
Cc: 'Little Scott-B11206'; 'sv-dc@eda.org'
Subject: RE: [sv-dc] Questions on late resolution function association
Jim, this is basically what I proposed (and documented) months ago:
a resolution function or "filter", that takes into account all the
drivers respectively parasitics of a net over the complete hierarchy. In
fact this would be a kind of (time-discrete!) resolution "module", that
has an internal state and is parametrized and synchronized by its
environment. In my opinion this is the only clean resolution method that
does not produce an uncertain number of exceptions and shortcomings.
This methodology would not slow ANYTHING down, if implemented
reasonably, neither elaboration nor simulation. It should only result in
additional computational effort at the particular nets, where the user
explicitly specifies (critical) non-default attributes or information.
It goes without saying, that the additional effort in this case would be
the very INTENT of the simulation.
Unfortunately this powerful methodology is kind of orthogonal to the
current implementation within our EDA flows, it does not "scale very
well" with them. Anyway, i.m.o this is what the user needs.
Achim
On Mon, 2011-01-31 at 13:44 +0000, Lear, Jim wrote:
> Thevenin resolution functions with late association could add a specific, layout driven, resistive parasitic to each net. This could be immensely helpful, as many times these resistive parasitics are part of the global interconnect that are "clean" enough for extraction only just before tape-out. They are often overlooked by the designers, despite large scale layout reviews, and usually impossible to simulate. Conceivably, such resolution functions should really be parameterized, but that's a discussion for a future sv-dc committee.
>
> Kindest Regards,
> Jim Lear
> Cirrus Logic
> (512) 851-4612
> (512) 293-7248 (mobile)
> -----Original Message-----
> From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Kevin Cameron
> Sent: Friday, January 28, 2011 4:41 PM
> To: Little Scott-B11206
> Cc: sv-dc@eda.org
> Subject: Re: [sv-dc] Questions on late resolution function association
>
>
> The rules for A/D connect module insertion in Verilog-AMS (a special case of resolution) are separate from the module definitions for the reason you cite: any block in a design can be reused in other blocks in ways not anticipated by the designer of the block. So types within a module refer only to drivers/receivers in the module not the behavior of the entire net, and as such code-generation for the module is pretty much the same whether you have resolution or not. In general you only know if you need resolution or type-conversion functions after you elaborate - i.e. marking something as a resolved type doesn't mean you will have to do resolution, and vice versa. For example: using logic buffers in parallel is common (but you would not normally mark a buffer output as a resolved type), and either trireg or wire-or outputs can be used singly.
>
> In addition: you often can't tell what dimensions things will have until parameters and defparams are evaluated, so if you want to do optimal compilation you leave it until post-elaboration, do a just-in-time compile and cache the code for reuse.
>
> Kev.
>
>
> On 01/28/2011 01:33 PM, Little Scott-B11206 wrote:
> > Hi all:
> >
> > I spent a little bit of time thinking about use cases where late association of a resolution function would be beneficial. I will admit up front that I like the idea of the flexibility provided by late association. What I am trying to understand is where that flexibility makes a difference for my expected use cases in practice.
> >
> > My current understanding is that the benefit I get from having a late association of resolution functions is avoiding a recompile of some modules. To change a resolution function code with late association, the resolution function code would still have to be compiled and elaboration would need to be done for the entire testbench+design. Is that correct? Are there other significant advantages?
> >
> > A possible use case for this would be delivery of models for AMS IP. A precompiled model could be delivered with a full featured interface. The receiver of the model could choose to only use a part of that interface by selecting a resolution function that ignores some of the data provided by the interface. Without the possibility for late association the interface and resolution function must be fixed precompile or the source for the model must be provided. To me this is the case that seems to highlight the differences. If I have the source code for everything I don't think that the recompile is terribly painful.
> >
> > My understanding is that the big negative impact of the late association is on the tool complexity at elaboration. Is that correct? Gord believes this complexity will be confined to a manageable section of the elab process. I believe Steven listed typedef as a primary contributor to current elaboration complexity. To me the association of resolution functions seems like a similar idea to a typedef. How is the complexity different or did I misunderstand someone?
> >
> > Thanks,
> > Scott
> >
> >
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
