Re: array parameters overrides

From: Geoffrey.Coram <Geoffrey.Coram_at_.....>
Date: Thu Apr 19 2007 - 04:57:38 PDT
Marq -
The second bullet, as presently in the LRM, doesn't say anything
about the default value provided.  In some cases, the LRM allows
the default value to be illegal:
  parameter real pos_num = -1 from [0: inf);
is syntatically legal, and effectively requires the user to
supply a value.  I suppose the same sort of thing might be
possible for arrays, that the default array would be the
wrong size, so you'd be required to specify an array when
you instantiate the module.

Actually, we have something of a problem with this:
       parameter integer active[0:1] = { "yes", "no" };
because 1364 Verilog considers a string literal like "yes"
to be an integer type.  In 3.2.1, I put in language to prevent
coercion from string to real or integer, but it was later
pointed out that this is not consistent with 1364.

-Geoffrey



Marq Kole wrote:
> 
> Geoffrey,
> 
> I was trying to work from the original text and apparently got myself in a bigger mess :-)
> 
> I agree with your proposal although I have the impression that the LRM makes a distinction between assignment which is done when providing a default value and overriding the default values by either a defparam, instance parameter override by position or instance parameter override by name. Your first proposed bullet (An array assigned ...) should probably also mention the assignment of the default value for an array parameter.
> 
> The equivalent type was put in as in case of integer vs real arrays coercion can be used, in case of a string array (do have those?) it can't be done. Or put in other words, each array element is assigned a value as though it were a scalar initialized by a scalar constant.
> 
> It allows:
> 
>         parameter real pwl[0:3] = {0, 0, 1, 1}; // initialize real array with integer values
> 
> It disallows:
> 
>         parameter integer active[0:1] = { "yes", "no" };
> 
> Cheers,
> Marq
> 
> ------ original message follows ----
> 
> Marq -
> The existing bullet says:
> * An array assigned to an instance of a module shall be of the exact size
> of the array bounds of that instance
> 
> This seems to say what you needed it to say for the examples
> you sent earlier (trying to override the array parameter
> with shorter or longer arrays).  I don't see how your
> proposed text helps, unless you are saying that "assigned
> to an instance of a module" isn't precise, since it doesn't
> make clear that "assigning to an instance" is really meant
> to be overriding the default value.
> 
> "array bounds of that instance" is a little odd, also, since
> the "instance" doesn't have array bounds, only the parameter.
> 
> I will also note that "equivalent type" isn't necessary; one could
> have coercion (real to integer or vice-versa).  Perhaps, though,
> we should say something about strings.
> 
> How about:
> * An array assigned to an instance of a module to override the
> default value of an array parameter shall be of the exact size
> of the parameter array, as determined by its declaration.
> 
> * Since array range in the parameter array declaration may
> depend on previously-declared parameters, the array size
> can be changed by overriding the appropriate parameters.
> If the array size is changed, the parameter array shall be
> assigned an array of the new size from the same module
> as the parameter assignment that changed the parameter
> array size.
> 
> -Geoffrey
> 
> Marq Kole wrote:
> >
> > All,
> >
> > I propose the following text to replace the second bullet in the list in section 3.2.4 (Parameter Arrays):
> >
> >    * An array assigned to an instance of a module or overriding the default value of an array parameter in an instance of a module shall be of the exact size as defined by the array bounds of that instance parameter. Assigning to an array requires also that each element to be of an equivalent type.
> >
> > Cheers,
> > Marq

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Apr 19 04:58:00 2007

This archive was generated by hypermail 2.1.8 : Thu Apr 19 2007 - 04:58:03 PDT