Re: [sv-bc] configurations and parameters

Hello all;

Don't forget that  one can mimic parameter overrides/definitions by 
using include files with
preprocessor directives to set 1 or more sets of parameters or other 
preprocessor defines.

It would seem this would allow you to do today what you envision doing 
with configurations tomorrow.

Alsop, Thomas R wrote:
>
> Hi Don,
>
>  
>
> Actually, I have recently had conversations with some of our senior 
> RTL designers and one of them stated a very serious concern about 
> parameterization.  When you move into a more SoC ENV, you have many 
> configurations as components are added, multiply instantiated, and 
> chopped.  We are no longer in the mode of one size fits all, but in a 
> space of serving multiple platforms. The concern stated by this senior 
> designer was that we typically have many parameters across many blocks 
> which change as a whole to create multiple platforms of products.  He 
> stated that it's a very tedious and manual process get all the 
> parameters correctly put together on the compiler command line.  And 
> certainly this is easily lost unless he saves that command line. 
>  Better to have configuration files to formalize and revision this 
> process.
>
>  
>
> So now it seems like we need to iron out the proposal on this WRT to 
> how config's take precedence over internal parameters, etc..
>
>  
>
> Is there a mantis on this or a proposal?
>
>  
>
> Thanks, -Tom
>
>  
>
> ------------------------------------------------------------------------
>
> *From:* Don Mills [mailto:mills@lcdm-eng.com]
> *Sent:* Thursday, September 13, 2007 4:07 PM
> *To:* Alsop, Thomas R
> *Cc:* sv-bc@server.eda.org
> *Subject:* Re: [sv-bc] configurations and parameters
>
>  
>
> Thomas,
>
> In addition to the number of replies you got on your questions below, 
> I would like to follow up with a significant usage example of setting 
> parameters withing a configurations.  The products for the company I 
> am working for are processors and micro-controllers.  These are highly 
> configurable parts for the end users and therefore require a large 
> number of test configurations to ensure complete testing.  Our desire 
> is to have one copy of our design (DUT) and one copy of our test for 
> test environment.  We then want to use a Verilog configurations to set 
> parameters to set up a specific DUT configuration to be tested.  Each 
> of these Verilog configurations set up a test environment for our DUT 
> and will be added to CVS
>
> Without the availability of setting parameters inside of a 
> configuration, we have two other approaches:
> 1.  We can make multiple copies of out TEST code, each with unique 
> parameters set to represent each of the DUT configurations available.  
> This is a file management nightmare.  We only need one copy of the 
> test and then just need to modify the parameters to the DUT unique. 
>
> 2.  We can use command line parameter overrides to set the DUT 
> configuration.  This is our current usage model.  This approach does 
> not easily allow revision control.
>
> Alsop, Thomas R wrote:
>
> Thanks Saikat, this is a good example.  And I most definitely appreciate
> a designer's need to do architectural exploration.  This is one place
> that config's can be used and I see some need for parameter overrides in
> this work model so I won't argue it any further.  
>  
> My initial thoughts had been to use this for implementation convergence.
> And in those cases I saw it as rare from a design standpoint to use
> parameters overrides in configs to override the parameter override in
> the RTL.  Wow, did anyone understand that last sentence:)  However, I
> can see some cases where this would be used.  
>  
> And after more thought on the exploration work model, I would lean
> strongly towards agreeing with Shalom.  I also think of configs as a
> method to override what is in the RTL on the build command line. The
> issues I see with this are validation and implementation convergence.
> If for some reason the configs were now associated with released RTL
> models, it's going to be more difficult to debug where the parameter
> values came from. 
>  
> In the exploration world, this is not an issue because this will tend to
> be a designer working in his local area, making these changes (i.e.
> config parameter overrides), finding the optimal solution, ultimately
> changing the RTL parameter overrides, and committing the changes to a
> RTL model.   
>  
> Going back to the debug issue, I could only suggest that design teams
> make a very careful methodology decision to either train their team
> about configs (so they know where to look if a parameter value doesn't
> seem right) or banning configs in the model, but allowing them to use it
> for exploration.
>  
> So my next question would be about how we resolve the literal values
> used in the parameter overrides.  Designers are going to want something
> like this as Gordon suggests
>  
>   
>>>    module top ();
>>>      parameter WIDTH = 16;
>>>      adder a1 (...);
>>>    endmodule
>>>  
>>>    config cfgl;
>>>      design rtlLib.top;
>>>      instance top.a1 #(.size(WIDTH));
>>>    endconfig
>>>       
>  
> I am not the tool expert, but wouldn't this be a simple string
> replacement operation like we do with macro's.  Instead of replacing the
> literal value we just replace the string value of "WIDTH" and let the
> compiler do its job when it evaluates what "WIDTH" is within the RTL
> code.  My point is that we don't have to know what the value of WIDTH is
> at the time we see the config.  
>  
> Finally, I am not sure if this would conflict with having localparams
> and params within configs?  If the parameter is already defined within
> the RTL, I am going to want to just use that RTL parameter value.  But
> if I create another params or localparams in the config, we open up a
> big can of worms. The config must take precedence clearly with the
> parameters seen in the config, but what if the params is already defined
> in the RTL and we are overidding that value.  Do we only override it
> within the config or does it override all the parameter values in the
> RTL model? 
>  
> Anyway, just more food for thought.  Hope I am not dragging this issue
> down. Thanks,
> -Tom
>  
> -----Original Message-----
> From: Saikat Bandyopadhyay [mailto:saikat@cal.interrasystems.com] 
> Sent: Sunday, August 12, 2007 9:54 PM
> To: Alsop, Thomas R; 'Gordon Vreugdenhil'; 'Mark Hartoog'
> Cc: mills@lcdm-eng.com <mailto:mills@lcdm-eng.com>; sv-bc@eda.org <mailto:sv-bc@eda.org>
> Subject: RE: [sv-bc] configurations and parameters
>  
> Hello Tom,
> The need for parameter override from configuration should better be
> answered by designer(which I am not). However I can speculate the
> following scenario:
> - A parameterizable multiplier's size and architecture depends on
> parameters. parameters can be
>         + size of inputs
>         + signed/unsigned
>         + partial product generation architecture (booth/non-booth)
>         + reduction architecture (Wallace tree/regular array)
>         + final adder architecture(ripple/cla/csa etc)
>  
> A designer might want to do an architecture exploration, without
> modifying the RTL(i.e default parameter values or parameter override
> at instance of multipler).
>  
> Configuration with parameter override support can provide him this
> mechanism.
>  
> Without this support for architecture exploration
>    - multipler for all possible architecture
> combinations(booth/Wallace/ripple, booth/regular/cla etc) have to be
> created. In configuration you can bind to appropriate master.
>    - or RTL will need change.
> Either of these is not elegant.
>  
> So parameter override from configuration seems pretty useful.
>  
> Thanks,
> Saikat
>  
> -----Original Message-----
> From: owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org> [mailto:owner-sv-bc@eda.org] On Behalf Of
> Alsop,
> Thomas R
> Sent: Saturday, August 11, 2007 3:30 AM
> To: Gordon Vreugdenhil; Mark Hartoog
> Cc: mills@lcdm-eng.com <mailto:mills@lcdm-eng.com>; sv-bc@eda.org <mailto:sv-bc@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> [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 <mailto:mills@lcdm-eng.com>; sv-bc@server.eda.org <mailto: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> [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 <mailto:mills@lcdm-eng.com>
>>> Cc: sv-bc@eda.org <mailto: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> [mailto:owner-sv-bc@eda.org] On 
>>> Behalf Of Gordon Vreugdenhil
>>> Sent: Thursday, August 09, 2007 11:33 PM
>>> To: mills@lcdm-eng.com <mailto:mills@lcdm-eng.com>
>>> Cc: sv-bc@eda.org <mailto: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 <mailto:mills@lcdm-eng.com>
>>>> www.lcdm-eng.com <http://www.lcdm-eng.com>
>>>> ==========================================================
>>>>  
>>>>  
>>>>         
>>> -- 
>>> --------------------------------------------------------------------
>>> Gordon Vreugdenhil                                503-685-0808
>>> Model Technology (Mentor Graphics)                gordonv@model.com <mailto: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.
>>>  
>>>  
>>>       
>  
>   
>
>
>
> -- 
> ==========================================================
> Don Mills
> mills@lcdm-eng.com <mailto:mills@lcdm-eng.com>
> www.lcdm-eng.com <http://www.lcdm-eng.com>
> ==========================================================
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 

-- 
    Soli Deo Gloria
    Adam Krolnik
    Director of Design Verification
    VeriSilicon Inc.
    Plano TX. 75074
    Co-author "Assertion-Based Design"


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.