Subject: RE: $sv-ec Verilog-A Parameter Ranges
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Nov 25 2002 - 15:25:39 PST
> From: "David W. Smith" <dws@dolcesfogato.com>
>
> Hi Kevin, I think that the second idea (merging range and inside) would
> not be a good idea. The idea of being within a range of continuous and
> ordered values and being a member of an unordered set are sufficiently
> different that I do not know how they could be merged without causing
> confusion.
>
> The range is always denoted using the concepts of from and to (or start
> and end) with ordering required. The inside is always just indicating a
> member of a set of discrete values. I think it makes more sense to
> disambiguate this using syntax as opposed to trying to merge them into a
> syntax with two very different meanings.
>
> Regards
> David
I didn't think any of the mechanisms actually specify any order, they all
appear to define sets/subsets (weight being an attribute of a subset).
The AMS syntax uses "from" in the sense: "X is from range Y", which is
much the same as "X is inside range Y" - not "X is from A to Z". So
I don't think using "from" instead of "inside" would be confusing for
anyone.
Currently AMS doesn't have value weighting, but I think it would be
useful for indicating likely operating conditions for driving analog
optimization/synthesis.
Making "range" a seperate construct would make it easier to re-use a
single definition in the language. Adding and substracting ranges could
be useful testbench functional e.g.:
range real valid = [0.0:3.3], // good voltage
invalid = (-10e3:10e3) exclude valid, // bad
test_v = valid + invalid; // test voltage range
Or maybe -
range real valid = [0.0:3.3], // good voltage
test_v = (-10e3:10e3), // ESD range
invalid = test_v - valid, // bad in normal operation
("-" replaces "exclude")
range bus_low = [0:16'hFFFF], // address check
bus_high = [32'h40000000:32'h4FFFFFFFF],
bus_ok = bus_low + bus_high; // for assertions
bus_rand = bus_low := 1 + bus_high := 10; // weighted bus_ok
Just a thought,
Kev.
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Kevin Cameron
> Sent: Monday, November 25, 2002 1:58 PM
>
>
> Here's the range specification stuff from the Verilog-AMS 2.X LRM:
>
> 3.2.2 Value range specification
> A parameter declaration can contain optional specifications of the
> permissible range of the values of a parameter. More than one range can
> be specified for inclusion or exclusion of values as legal values for
> the parameter.
>
>
> Parameters Data types
> The use of brackets, [ and ], indicate inclusion of the end points in
> the valid range. The use of parenthesis, ( and ), indicate exclusion of
> the end points from the valid range. It is possible to include one end
> point and not the other using [ ) and ( ]. The first expression in the
> range shall be numerically smaller than the second expression in the
> range.
>
>
> Examples:
>
> parameter real neg_rail = -15 from [-50:0) ;
> parameter integer pos_rail = 15 from (0:50) ;
> parameter real gain = 1 from [1:1000] ;
>
> Here, the default value for neg_rail is -15 and it is only allowed to
> acquire values within the range of -50 <= neg_rail < 0. Similarly, the
> default value for parameter pos_rail is 15 and it is only allowed to
> acquire values within the range of 0 < pos_rail < 50. And, the default
> value for gain is 1 and it is allowed to acquire values within the range
> of 1<= gain <= 1000. The keyword inf can be used to indicate infinity.
> If preceded by a negative sign, it
> indicates negative infinity.
>
> Example:
>
> parameter real val3=0 from [0:inf) exclude (10:20) exclude (30:40];
>
> A single value can be excluded from the possible valid values for a
> parameter.
>
> Example:
>
> parameter real res = 1.0 exclude 0 ;
>
> Here, the value of a parameter is checked against the specified range.
> Range checking applies to the value of the parameter for the instance
> and not against the default values specified in the device. It shall be
> an error only if the value of the parameter is out of range during
> simulation.
>
> 3.2.3 Parameter arrays
> Verilog-AMS HDL includes behavioral extensions which utilize arrays. It
> requires these arrays be initialized in their definitions and allow
> overriding their values as with other parameter types. The declaration
> of arrays of parameters is in a similar manner to those of parameters
> and register arrays of reals and integers in IEEE 1364-1995 Verilog HDL.
> Parameter arrays have the following restrictions. Failure to follow
> these restrictions shall result in an error.
>
>
> . A type of a parameter array shall be given in the declaration.
> . An array assigned to an instance of a module shall be of the exact
> size of the array bounds of that instance.
> . If the array size is changed via a parameter assignment, 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.
>
> Example:
>
> parameter real poles[0:3] = { 1.0, 3.198, 4.554, 2.00 };
>
> ---------------------------------------------
>
>
> It would be easy (IMO) to add the ":=" weight syntax to the individual
> ranges as
> in the "dist" syntax, and use the one syntax for ranges in all cases. I
> would prefer to
> depracate "from" (and "inside") and use a seperate "range"
> declaration/keyword, e.g.:
>
>
> range v_r = [0:inf) exclude (10:20) exclude (30:40];
> parameter real val_1 = 1.5 range v_r;
>
>
> range p_r = [0:2] := 5 or (2:inf) := 10; // split range with weights
>
> parameter real val_1 = 3.0 range p_r;
>
>
> Syntax needs work - AMS version is one range with multiple exclusions,
> need
> multiple ranges for adding weights (I used 'or' in the example to do
> it). It would
> probably be useful to be able to do things like:
>
>
> range v_r = [0:inf);
> parameter real val_1 = 1.5 range v_r exclude (10:20);
> parameter real val_2 = 2.2 range v_r exclude (30:40];
>
>
>
> Kev.
> --
> National Semiconductor, Tel: (408) 721 3251
> 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
>
>
This archive was generated by hypermail 2b28 : Mon Nov 25 2002 - 15:26:56 PST