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

 
See my comments.

-----Original Message-----
From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Little Scott-B11206
Sent: Friday, January 28, 2011 4:34 PM
To: sv-dc@eda.org
Subject: [sv-dc] Questions on late resolution function association

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.

>> yes, this kind of flexibility always looks good to the user but is painful for the
implementation. It feels more to me like a debugging capability rather than a designing
feature.

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?

>> recompilation (parsing) of the modules containing the late association would be
necessary. What is really costly is the elaboration of the new design,
associating the new resolution function,
checking the compatibility across the network and propagating the resolution function.
If you have a tool that has incremental elaboration, usually that tool will need to exactly determine what needs to be re-elaborated

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.

>>>>I still do not see why the IP models would not provide different packages containing
different resolution functions for the user to select.
In SystemVerilog a lot of complex datatypes (such as struct) are strongly typed.
 That means that the IP
provider has to expose that datatype otherwise it will not be compatible with a struturally
similar datatype defined by the user code. I expect that these datatypes will be provided
in packages so that they can be referred by the user code.

ex:
package ip_res1;
   typedef struct {real m1, realm2} ST1;

   function real f_add (St1[]);
   endfunction

   nettype ST1; //unresolved ST1
   nettype ST1_R: ST1 use f_add ;

endpackage

package ip_res2;

   typedef struct {real m1, realm2, int i} ST1;

   function real f_select (St1[]);
   endfunction

   nettype ST1; //unresolved ST1
   nettype ST1_R: ST1 use f_select ;

endpackage

import ip_res1::*; // Use this package for the entire design
module top;
   wire ST1_R w; // a wire with datatype ip_res1::ST1R and resolution function f_add

   wire ip_res2::ST1_R w1; // a wire with datatype from package ip_res2

   u1 b();

endmodule

module b;
import ip_res2::*;

   wire ST1; // unresolved datatype ST1 from package ip_res2
endmodule

Packages provide declarations that can be shared.
You can select which package you want to import. This is pretty flexible.
>>>>>>>>>>>>>>>

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.