RE: [sv-bc] configurations and parameters

In contrast to Tom and Gord, I do think that configurations should be
stronger than parameter assignments and overrides within the code
itself. I think of configs as like command-line switches, which have
that characteristic. The purpose is to be able to change the
configuration without having to touch the code itself. 

Shalom


> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Alsop, Thomas R
> Sent: Saturday, August 11, 2007 1:00 AM
> To: Gordon Vreugdenhil; Mark Hartoog
> Cc: mills@lcdm-eng.com; sv-bc@server.eda.org
> Subject: RE: [sv-bc] configurations and parameters
> 
> Hi Don, I'd like some clarification on what we are proposing. 
> First, since I am new to configs, I'd like to explain my 
> understanding of what they are doing.  A config is used to 
> override the default binding of the instantiated "design 
> element" (i.e. modules, primitives, interface, etc) thereby 
> allowing a designer to place another version of the 
> underlying code in a different library and rebind to that 
> library via a config "instance" line. 
> 
> If I understand things correctly, I am not sure I see the 
> need to override parameters within a config.  If you are 
> rebinding in the first place, you most likely have a new 
> default parameter setting in the newly binded instance.  So, 
> in order to take advantage of parameters overriding the newly 
> binded instance, you would have to have many of them and need 
> to override some of the new ones.  Granted this seems like a 
> valid usage scenario but a complex one and one that I am not 
> sure would be used often. On top of that, most likely the RTL 
> for a specific instance you are already overriding the 
> parameter value with the module instantiation. By using a 
> config with parameters you are stating that not only do you 
> want to change the underlying code but you are changing the 
> input parameters to it as well.  I just can't think of cases 
> where this is needed, at least they seem very rare. Please 
> enlighten me:')
> 
> Your examples do all use literals as Gordon stated and he 
> mentioned that while simple to implement it's not practical. 
> As a methodology enforcer on our design team I can say that 
> we frown on literals in RTL code.
> Which means that we'd want to used parameter values as inputs 
> to the config parameter override. 
> 
> Finally, I would definitely agree with Gordon on parameter 
> win scenarios which goes back to my argument about whether we 
> need this feature.  In a scenario where we do need it, 
> perhaps you can give us an example of why the config should 
> win over the instantiated redefine of the parameter.
> In our RTL models the instantiated redefine seems like the 
> golden location.  Otherwise it really complicates debug and 
> readability. 
> 
> Hope this is clear, Thanks, -Tom
> 
> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Gordon Vreugdenhil
> Sent: Friday, August 10, 2007 10:25 AM
> To: Mark Hartoog
> Cc: mills@lcdm-eng.com; sv-bc@server.eda.org
> Subject: Re: [sv-bc] configurations and parameters
> 
> 
> 
> BTW, Mark, have you thought through how "works like bind" 
> will impact the name resolution?  Since a config impacts an 
> instance in the middle of a module, I think that my view that 
> names shouldn't be imported late would make this much simpler 
> and consistent to describe.  Otherwise we'd have to have yet 
> another set of different rules for this kind of situation versus bind.
> That assumes that you don't want to *change* the meaning of a 
> name binding decision in later code due to the impact of the config.
> 
> Having the tighter more local rules makes language extensions 
> like this much more symmetric and easier to see how they 
> would just fall into place without additional special rules 
> and irregularities.
> 
> Gord.
> 
> Mark Hartoog wrote:
> > This would work for value parameters, but does not work as well for
> type
> > parameters.
> > 
> > Users will want to use user defined types for type parameters and 
> > defparams are not allowed to type parameters.
> > 
> >> -----Original Message-----
> >> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of 
> >> Saikat Bandyopadhyay
> >> Sent: Thursday, August 09, 2007 9:35 PM
> >> To: 'Gordon Vreugdenhil'; mills@lcdm-eng.com
> >> Cc: sv-bc@eda.org
> >> Subject: RE: [sv-bc] configurations and parameters
> >>
> >> Hi,
> >> Few issues/suggestions
> >>
> >> 1. In the example from Gord, where WIDTH is set as parameter from 
> >> configuration, scope resolving can get very complicated.
> >> I would suggest against introducing such changes in SV.
> >>    We should rather have parameter/localparam declarations inside 
> >> configurations which can be used for overriding instance 
> parameters.
> >> This will not work like binding and cannot handle Gord's case.
> >>
> >> 2. For overriding parameters inside configuration, instead of 
> >> introducing a new Syntax, with it's precedence complexity, we can 
> >> think of using defparam inside configuration.
> >>   
> >> Slightly modified version of Don's example with my suggestions:
> >> module top ();
> >>   adder a1 (...);
> >>   adder a2 (...);
> >>   adder a3 #(.size(4)) (...);
> >>   adder a4 (...);
> >>   adder a5 #(.out(16)) (...);
> >>   adder a6 #(.out(32)) (...);
> >> endmodule // top
> >>
> >> //file adder.v, default rtlLib
> >> module adder #(parameter size = 12) (...);
> >>   // rtl adder
> >>   // description
> >>   ...
> >> endmodule // adder
> >>
> >>
> >> //file adder2.v, in diffRTLLib
> >> module adder #(parameter out = 10) (...);
> >>   // different rtl adder
> >>   // description
> >>   ...
> >> endmodule // adder
> >>
> >>
> >> //file adder.vg, in gateLib
> >> module adder (...);
> >>   // gate-level adder
> >>   // description
> >>   ...
> >> endmodule // adder
> >>
> >>
> >> //This configuration is very verbose for discussion purposes.
> >> config cfgl;
> >>   design rtlLib.top;
> >>   default liblist rtlLIb;
> >>   instance top.a2 liblist gateLib;
> >>
> >>   // SUGGESTION
> >>   localparam WIDTH = 8;
> >>
> >>   //using default lib, override instantiated parameter setting 
> >> .size(4)
> >>   // SUGGESTION
> >>   defparam top.a3.size = WIDTH*2; //adder from default liblist
> >>
> >>   //different RTLLib, used parameter setting from module,
> >>   //not changed by instantiation or configuration
> >>   instance top.a4 liblist diffRTLLib; //adder from other 
> than default 
> >> liblist
> >>
> >>   //different RTLLib, parameter is changed by 
> instantiation but not 
> >> configuration
> >>   instance top.a5 liblist diffRTLLib; //adder from other 
> than default 
> >> liblist
> >>
> >>   //different rtl lib, overriding instantiated parameter 
> setting of 
> >> .out(32)
> >>   instance top.a6 liblist diffRTLLib; //adder from other 
> than default 
> >> liblist
> >>
> >>   //parameter specified separately from instance library binding.
> >>   defparam top.a6.out = 8;
> >>
> >> endconfig
> >>
> >> Thank you,
> >> Saikat
> >>
> >>
> >> -----Original Message-----
> >> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of 
> >> Gordon Vreugdenhil
> >> Sent: Thursday, August 09, 2007 11:33 PM
> >> To: mills@lcdm-eng.com
> >> Cc: sv-bc@eda.org
> >> Subject: Re: [sv-bc] configurations and parameters
> >>
> >> Don, your examples all use trivial overrides using literals.
> >>
> >> Would you expect something like the following to work:
> >>
> >>    module top ();
> >>      parameter WIDTH = 16;
> >>      adder a1 (...);
> >>    endmodule
> >>
> >>    config cfgl;
> >>      design rtlLib.top;
> >>      instance top.a1 #(.size(WIDTH));
> >>    endconfig
> >>
> >> It seems to me that such a use model would be required in order to 
> >> make this viable in practice.  I would expect such 
> scenarios to sort 
> >> of behave like "bind" in terms of resolution of provided actuals.
> >>
> >> Of course restricting overrides to literals is much 
> simpler but I'm 
> >> not sure that customers will be happy with that.
> >> Allowing fully general constant expression overrides might be 
> >> difficult and slow implementation, but allowing at least an 
> >> association to another named parameter should probably be 
> permitted.
> >>
> >> As a second comment, I am not sure that I would agree that a 
> >> configuration parameter value *always* wins.  In particular, as I 
> >> mentioned in the meeting, I think that config parameters should be 
> >> handled as just a replacement instantiation override.
> >> The implication of this is that a defparam into "top.a1" 
> >> would win over the configured value.
> >>
> >> Gord.
> >>
> >> Don Mills wrote:
> >>> As I discussed during the conference on Monday - I would like to 
> >>> pursue the enhancement of setting parameters via
> >> configurations.  The
> >>> discussion on Monday noted that there are a number of
> >> issues regarding
> >>> configurations that need to be addressed, with setting
> >> parameters via
> >>> configurations being just one of many.  I was tasked
> >> (volunteered) to
> >>> gather up the issue/wish list regarding configurations and
> >> then start
> >>> working through it.  Based on the verbal discussion we had on 
> >>> configurations and the need to have all items resolved by 
> Nov 1 in 
> >>> order to be part of the next 1800 spec, I see a large task
> >> at hand.  I
> >>> feel we might have to take small steps - put some of the easier 
> >>> enhancements in now and add the rest in the next rev.  Of
> >> course I am
> >>> just speculating at this point.
> >>>
> >>> My enhancement request/proposal for configurations is to add the 
> >>> ability to set/modify parameters within a configuration.  I have 
> >>> pieced together some sample code that shows how I think
> >> this could work.
> >>> // Obviously, parameters set by configurations
> >>> //   must take precedent over instantiation parameter values.
> >>> // For this example, I assume that for models from 
> different lib's,
> >>> //   the port list for each model are (must be?) identical.
> >>>
> >>> module top ();
> >>>  //See configuration below for details of these instantiations.
> >>>  adder a1 (...);
> >>>  adder a2 (...);
> >>>  adder a3 #(.size(4)) (...);
> >>>  adder a4 (...);
> >>>  adder a5 #(.out(16)) (...);
> >>>  adder a6 #(.out(32)) (...);
> >>> endmodule // top
> >>>
> >>> //file adder.v, default rtlLib
> >>> module adder #(parameter size = 12) (...);  // rtl adder  // 
> >>> description  ...
> >>> endmodule // adder
> >>>
> >>>
> >>> //file adder2.v, in diffRTLLib
> >>> module adder #(parameter out = 10) (...);  // different 
> rtl adder  
> >>> // description  ...
> >>> endmodule // adder
> >>>
> >>>
> >>> //file adder.vg, in gateLib
> >>> module adder (...);
> >>>  // gate-level adder
> >>>  // description
> >>>  ...
> >>> endmodule // adder
> >>>
> >>>
> >>> //This configuration is very verbose for discussion purposes.
> >>> config cfgl;
> >>>  design rtlLib.top;
> >>>  default liblist rtlLIb;
> >>>  instance top.a2 liblist gateLib;
> >>>
> >>>  //default default lib, override instantiated parameter
> >> setting .size(4)
> >>>  instance top.a3 #(.size(16)); //adder from default liblist
> >>>
> >>>  //different RTLLib, used parameter setting from module,  //not 
> >>> changed by instantiation or configuration  instance 
> top.a4 liblist 
> >>> diffRTLLib; //adder from other
> >> than default
> >>> liblist
> >>>
> >>>  //different RTLLib, parameter is changed by 
> instantiation but not 
> >>> configuration  instance top.a5 liblist diffRTLLib; //adder
> >> from other
> >>> than default liblist
> >>>
> >>>  //different rtl lib, overriding instantiated parameter setting of
> >> .out(32)
> >>>  instance top.a6 #(.out(8)) liblist diffRTLLib; //adder
> >> from other than
> >>> default liblist
> >>>
> >>> endconfig
> >>>
> >>>
> >>> --
> >>> ==========================================================
> >>> Don Mills
> >>> mills@lcdm-eng.com
> >>> www.lcdm-eng.com
> >>> ==========================================================
> >>>
> >>>
> >> --
> >> 
> --------------------------------------------------------------------
> >> 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.
> >>
> >>
> >>
> >>
> >>
> >>
> >> -- 
> >> This message has been scanned for viruses and
> >> dangerous content by MailScanner, and is
> >> believed to be clean.
> >>
> >>
> 
> -- 
> --------------------------------------------------------------------
> 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.
> 
> -- 
> 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.