On the contrary, the 2.2 LRM says, "Parameters represent constants, hence it is illegal to modify their value at runtime. However, parameters can be modified at compilation time to have values which are different from those specified in the declaration assignment. This allows customization of module instances. A parameter can be modified with the defparam statement or in the module_instance statement." A -defparam on the command line is just a substitute for a defparam statement in the code. It is still evaluated at compilation time. You should have some basic understanding of what compilers do. Among others things, compilers translate the source code into a data structure. Changing the data structure requires a recompilation. It may be an incremental recompilation, but a recompilation nevertheless. There might be special cases of parameters which you could change without requiring a recompilation, such as a transistor value, but that is not changing the data structure. Shalom > -----Original Message----- > From: owner-verilog-ams@eda.org [mailto:owner-verilog- > ams@eda.org] On Behalf Of Jonathan David > Sent: Wednesday, January 04, 2006 4:15 AM > To: Kevin Cameron; Muranyi, Arpad > Cc: Verilog-A Reflector > Subject: Re: Compilation question > > Hi Arpad.. > I agree with Kevin that this is not something that > must necessarily be defined in the LRM, but rather > would be a product of the LRM definition of what > things can depend on a parameter, and where in the > simulation cycle compilation happens.. > > Since I would assume you are talking about a "pre-run" > compilation - ie separate from the actual simulation > run. Its my understanding of the LRM that the > parameter should be modifiable at RUN time.. (ie with > a -defparam on the command line) so I would assume > that a requirement of the compiler would be NOT to > compile for one specific value of the parameter .. - > unless perhaps one used a parameter to define the > width of a signal (not something I got in the habit of > doing since my normal overall environment didn't have > the right kind of flexibility to make it a practical > proposition.. though I have seen it commonly used by > those with a more text-based overall design > environment than I was used to.) > > Hope this kind of info helps you.. > Jonathan > > > > > --- Kevin Cameron <kevin@sonicsinc.com> wrote: > > > > > The question should be aimed at your simulator > > supplier - rather than > > the committee. Compilation is (or isn't) a > > requirement of the > > implementation, so you won't find it discussed much > > in the LRM. > > > > Kev. > > > > Muranyi, Arpad wrote: > > > > >Happy New Year to everyone! > > > > > >I have a question about the compilation of modules. > > Let's > > >take an example which is a model for a resistor, in > > which > > >the resistance value is parameterized. > > > > > >1) Does this module have to be re-compiled for > > every value > > >of the parameter value (in multiple instances in > > the same > > >simulation, or in the same instance of a sweep > > simulation)? > > > > > >Let's modify the problem, and consider a module for > > a PWL > > >source, for example, in which the data table is an > > array > > >parameter. > > > > > >2) If the size of the array parameter is fixed > > inside the > > >module, will this module need to be recompiled for > > each > > >instance or iteration that causes the data to be > > different? > > > > > >Let's modify this PWL module so that the array size > > is > > >dynamic, i.e. it is determined by another > > parameter, > > >therefore the various instances are allowed to have > > >a different array length. > > > > > >3) Will this module need to be recompiled for each > > instance > > >if the instances get different array parameter > > sizes? > > > > > >4) Will this module need to be recompiled for each > > >iteration of a sweep simulation if the array size > > is > > >not the same between the iterations? (I don't know > > >if this could realistically happen or not...) > > > > > >5) Any related comments, cautions, suggestions? > > > > > >Thanks, > > > > > >Arpad > > > >============================================================= > > > > > > > > > > > > > > > >Received on Wed Jan 4 04:30:50 2006
This archive was generated by hypermail 2.1.8 : Wed Jan 04 2006 - 04:30:53 PST