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. >> >> -- -------------------------------------------------------------------- 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.Received on Mon Aug 13 09:48:00 2007
This archive was generated by hypermail 2.1.8 : Mon Aug 13 2007 - 09:48:39 PDT