Re: [sv-dc] Questions on late resolution function association

Jim,

There was actually a side-discussion already on parameterization.

In SV-BC, there was an explicit decision to not add parameterized functions
directly to the language but instead to just leverage static functions in
parameterized classes to achieve the same effect. So, for example,
one can already have (in a package or a module) something like:

      class fun_wrapper #(parameter p = 1);
           static function real my_fun(input real a[]);
                         return real'(p); // or some other use of "p"
of course
           endfunction
      endclass

I don't see any reason to disallow something like:
     fun_wrapper#(2)::my_fun
for use as a resolution function. That yields the kind of effect that
I think you want. In my suggested approach, such a definition could
in fact then be used with a parameterized TB module to deal with
binding a particular parameterized function as a type's resolution function.

If your simulator permits very late parameterization changes without
full re-elaboration, this could be a very efficient approach to doing
parameter sweeps through resolution function variants.

Gord.

On 1/31/2011 5:44 AM, 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
>>
>>
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.