I have uploaded an update to the proposal for 2037 adding a number of Gordon's recommendations. Don Mills wrote: > See my responses below: > > Gordon Vreugdenhil wrote: >> >> Don Mills wrote: >> > I have opened a mantis item on this subject #2037 and uploaded my >> first >> > draft of the new section. For those of you who have looked at my >> > preliminary draft earlier today - you will find the uploaded draft >> to be >> > much more verbose. >> > >> >> >> Don, >> >> I think the general intent of the proposal is reasonable but I >> have some issues with the current form. >> >> First, I don't like: >> instance top.a1 #(1,2); >> >> Normally, the change part of an instance clause is either >> in a lib_list or a use_clause. I would fold this into >> the "use_clause" part and have something like: >> instance top.a1 use #(1,2); > I prefer my original syntax leaving the "use_clause" for specific cell > binding. But I will concede on this because I have not strong > argument for my approach other then it is similar syntax to > instantiation redefinition of parameters. I like to keep things the > same where I can. Maybe someone else has preferences one way or the > other here. >> >> I would reserve the syntax you used for possible other semantics in >> the future. >> >> > Each of the following will be added to the write up of my next upload. >> I would make (at least) the following restrictions: >> 1) a localparam in a configuration shall only be set to a literal >> value >> 2) index expressions in a hierarchical name shall only refer to >> literals or localparams of the configuration >> 3) if a reference to a name in the target instance context is used >> in an override, it shall be the only term in the expression. >> 4) a hierarchical name in a parameter override shall be resolved >> starting in the context of the configured instance. If a >> hierarchical >> name is used, it must be the only term in the expression. (i.e >> you can't have >> a.b.c + 7). >> 4) a parameter override in a configuration shall not refer to a >> constant function other than a predefined constant system functions >> >> The above are likely enough though I need to think about it some more. >> >> This basically boils down to either having a simple name to name >> remapping of a parameter or having a value that can be determined >> as a literal at the time the configuration is compiled. That avoids >> most of the hard issues that Mark was beginning to raise in terms of the >> context of the evaluation of the parameter override expression. I >> think (from a quick look) that all the examples you have are still >> legal given this set of restrictions. >> >> >> I would reword: >> When an instantiation has parameter overrides and the configuration >> instance does not specificy parameter overrides... >> to be: >> When an instantiation has parameter overrides and the configuration >> instance does not have a parameter override list... > done >> >> >> There also seems to be a contradictory approach. You say: >> instance top.a1 #(); // set all parameters in instance a1 back to >> their default >> but when you have at least one override, the rest don't go back to >> their defaults, they are unmodified. >> >> I would prefer to say that #() means "everything goes back to default" >> and #(.name) means "use the existing instance's value for .name". > This is addressed. I was using ".name" substitution. That is now > removed from the examples. I don't want to have .name substitution as > part of this pass. >> The overall proposal is still somewhat informal, but if we >> can get consensus on a viable rule set, that shouldn't be too >> hard to fix. >> >> Gord >> > -- ========================================================== 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 Tue Sep 18 00:21:00 2007
This archive was generated by hypermail 2.1.8 : Tue Sep 18 2007 - 00:21:36 PDT