Re: [sv-bc] configurations and parameters

From: Don Mills <mills_at_.....>
Date: Thu Aug 09 2007 - 14:01:51 PDT
Gordon Vreugdenhil wrote:
> 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.
This is the same thing that Adam Krolnik suggested.  Yes, this needs to 
be part of the enhancement.
>
> 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.
Association with another named parameter is a good extension to my 
simple example. 
>
> 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.
After the discussion on Monday - I agree with you.  There shouldn't me 
anything in my "simple" code example the implies anything different.
>
> 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
>> ==========================================================
>>
>>
>

-- 
==========================================================
Don Mills
mills@lcdm-eng.com
www.lcdm-eng.com
==========================================================


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Aug 9 14:02:13 2007

This archive was generated by hypermail 2.1.8 : Thu Aug 09 2007 - 14:02:25 PDT