A few more comments below - Martin O'Leary wrote: > Kevin, > thanks for your feedback. > Comments below. > --Martin > > ------------------------------------------------------------------------ > *From:* Kevin Cameron [mailto:kevin@sonicsinc.com] > *Sent:* Wednesday, August 24, 2005 11:10 AM > *To:* Geoffrey.Coram > *Cc:* Martin O'Leary; verilog-ams@eda.org > *Subject:* Re: hierarchical parameter passing in DC sweep > > > I agree with Geoffrey: dynamicparam is a bit redundant, you can > tell that a param/genvar needs to be sweepable if it is used in > some kind of sweep statement, i.e. I think you would be better off > using something like: > > sweep <OOMR> [<sweep range>] [ = <local alias>]; > > oleary>This might be how a simulator would implement a sweep > analysis but I see the issues not as being there but as being in > the language definition. > Could use just the non-optional part - sweep <OOMR> - to indicate you want to sweep something, but you don't know the details. I should also have made it something like - sweep (<OOMR>|<local ref.>) [<sweep range>] [ = <local alias for OOMR>]; - so that you can sweep local stuff e.g. parmeter res; `ifdef SWEEP sweep res (`RES_SWEEP); `endif - which optionally gives you the dynamic attribute in a backward compatible way. > oleary>In terms of using analysis statements to determine which > parameters should be alterable, this does not work very well for > interactive simulators where users can add new analysis statements > on the fly. At this point, it is generally not possible > to regenerate module implementations so that some parameters are > not alterable. > True, but equally you don't want to compile everything marked as dynamic as variable at runtime if it's not going to be used that way. I think the user can usually decide the level of debug capability they need ahead of time and go for all or none (or something selective). > > oleary>Furthermore, the dynamicparam proposal does address > another issue; > 1) references to global parameters > which is very important to analog designers using Verilog-AMS > netlists and may be important to modeler's as well. > Not sure what you mean by a "global" parameter. > - then it doesn't matter if defparam is deprecated and you'll be > able to use it with old code. > > Not sure what the semantics/syntax of <sweep range> should be, but > something for doing a +/- range from the elaborated value would be > nice. The local alias is a shorthand for directly assigning the > value from testbench code. E.g.: > > sweep fuse_block[12].fuse (10,1e8) = f12; // resistive fuse (ok > or blown) > > initial_step (...) begin > f12 = 4000; // partial blow > ... > > If you need to know a param is sweepable for pre-compilation I'd > do that outside the language since there is no standard for > compiled code interfaces (yet), but you can always add attributes > in the source. > oleary>That could also work although it would nice to be able to > also have it in the standard for design portability. > I think what the simulator deems "sweepable" will vary quite a lot from vendor to vendor and with what mode the compiler/simulator is operating in. Using dynamicparam only seems useful to me in the narrow case that you know in advance which parameters you want to vary and that you have a simulator that's pre-compiling the models. Since even with a precompiled model all the parameter values have to be determined at elaboration it would seem to me that the dynamic attribute is pretty much redundant in practice. Might want to add some PLI/VPI support for querying whether sweeping is supported. Kev. > Kev. > > Geoffrey.Coram wrote: > >>Martin - >> >> >> >>>FYI - I have uploaded the dynamic parameter proposal to the DB in issue 814. >>> >>> >> >>I see the following statement in the proposal: >> The dynamic parameters are set once before the start of an analysis, and >> are then constant during the simulation of the analysis. >> >>This seems to prohibit a dc sweep of a dynamicparam, which was >>a big part of the motivation. >> >> >>I also think it's a nuisance to have to declare dynamicparams >>for compact models. It's the sort of thing that a model writer >>should not have to think about: what might the analog circuit >>designer / compact model user want to vary? L and W for sure, >>VTH likely, and possibly anything else -- particularly if the >>user is a characterization engineer trying to fit to data. >>If the module is in a read-only location, or provided pre- >>compiled or encrypted, what is the user to do? >> >> >>It also seems to me that all the Spice-like simulators that >>support Verilog-A allow standard "parameters" to be varied. >>(I haven't been able to reproduce Marq's problem with >>simulators I have access to.) Is "dynamicparam" a solution >>looking for a problem? >> >>If the simulator supports dc sweeps, then the Verilog-A >>compiler should be able to set up dependency trees and figure >>out which computations need to be done once per sim, once >>per dc point, or every iteration. If it only supports >>transient, then it is free to optimize parameters as constants >>just as Verilog-D simulators do now. (Your proposal does add >>one new feature, multiple transient analyses in one simulation >>with different values of a dynamicparam, without re-netlisting/ >>re-elaborating. But I haven't heard anyone on the Verilog-D side >>requesting this feature. Probably, if you want multiple >>transient analyses, it's faster to generate two netlists and run >>the analyses on two compute farm machines.) >> >> >>Another secondary concern is that SystemVerilog has a sentence >>to the effect that defparam may be deprecated in the next version, >>but your proposal requires defparam to allow dynamicparams to >>affect other modules through OOMRs. >> >>-Geoffrey >> >> >> >Received on Wed Aug 24 16:44:45 2005
This archive was generated by hypermail 2.1.8 : Wed Aug 24 2005 - 16:45:32 PDT