RE: [sv-bc] configurations and parameters

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; 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] On Behalf Of
Alsop,
Thomas R
Sent: Saturday, August 11, 2007 3:30 AM
To: Gordon Vreugdenhil; Mark Hartoog
Cc: mills@lcdm-eng.com; 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] 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.
		 
		 
		      

 
  





-- 
==========================================================
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.