RE: Analog procedural assignments

From: Bresticker, Shalom <shalom.bresticker@intel.com>
Date: Tue Feb 01 2011 - 06:22:14 PST

I suspect that the use of 'concatenation' here is a remnant from version 2.2 and early versions of 2.3.

2.2 had the following:

"4.1.13 Concatenations

A concatenation is used for joining scalar elements into compound elements (buses or arrays) for the built-in types integer or real, or for elements declared of type net_discipline. The concatenation shall be expressed using the brace characters ({ }), with commas separating the expressions within.

Examples:
module x;
parameter real p1[0:2] = { 1.0, 2.0, 3.0 };
...
endmodule
module y;
parameter real pole1 = 0, pole2 = 0, pole3 = 0;
x #(.p1({pole1, pole2, pole3}) x1;
...
endmodule

Module x defines a real-array parameter p1. Module y instantiates x and overrides the
array value of the parameter p1 of module x via the concatenation of the scalar
parameters pole1, pole2, and pole3."

The text Paul quoted is not in 2.2 but may have been added in an early draft of 2.3 before the use of 'concatenation' was corrected, and this incorrect use may not have been noticed.

See for example, http://www.eda.org/verilog-ams/hm/2228.html on this subect.

Regards,
Shalom

> -----Original Message-----
> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> Behalf Of Geoffrey.Coram
> Sent: Tuesday, February 01, 2011 3:55 PM
> To: Paul Floyd
> Cc: verilog-ams@eda.org
> Subject: Re: Analog procedural assignments
>
> Hi, Paul -
> Thanks for your detailed comments on the various items recently.
>
> Indeed, there are potentially 3 analog_expressions in the
> analog_procedural_assignment, and I think the main point of
> the restriction against concatenations may have been for
> the rvalue, that is, for the analog_expression explicitly
> in analog_variable_assignment.
>
> analog_procedural_assignment ::= analog_variable_assignment ; // from
> A.6.2
> analog_variable_assignment ::= analog_variable_lvalue =
> analog_expression
> analog_variable_lvalue ::= // from A.8.5
> variable_identifier
> | variable_identifier [ analog_expression ] { [ analog_expression ]
> }
>
> I can't seem to find any restrictions on the analog_expression used
> to index an array.
>
> module test;
>
> reg [1:0] A;
> reg [1:0] B;
> integer Y[15:0];
>
> analog begin
> Y[{A, B}] = 5.0; // legal?
> end
> endmodule
>
>
> I think the RHS of this:
> > array = '{x, y, z};
> is an "array literal" because of the tick ('); it's not a
> concatenation.
>
>
> On the other hand, in 3.3, there's an example
> a = {"Hi",b}; // OK
> which I think is a concatenation. I guess this assignment can't be
> inside an analog block, because of the restriction in 5.7.
>
> -Geoffrey
>
>
> Paul Floyd wrote:
> > Hi
> >
> > In 5.7, there is this sentence:
> >
> > "An analog_procedural_assignment is defined is a variable assignment
> > whose ..."
> >
> > I think that ought to be "is defined as".
> >
> > I'm not sure that I understand the first point following that
> paragraph,
> > namely
> >
> > "- Concatenation expressions cannot be used as part of the
> > analog_expression (assigning to list of values
> > in the analog context is not allowed)."
> >
> > Firsly, analog_expression occurs 3 times in the BNF syntax: rvalue,
> > array index and optional array index. I presume only the rvalue is
> > intended.
> >
> > Is this supposed to mean that a construction like this ought to be
> illegal:
> >
> > module test;
> >
> > reg [8:0] A;
> > reg [8:0] B;
> > integer Y;
> >
> > analog begin
> > Y = {A, B};
> > end
> > endmodule
> >
> > or should that be "array initializer", in which case a construction
> like
> > this would be illegal:
> >
> > module test
> > real array [2:0];
> > real x, y, z;
> >
> > analog begin
> > array = '{x, y, z};
> > end
> > endmodule
> >
> >
> > Regards
> > Paul Floyd
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Feb 1 06:23:14 2011

This archive was generated by hypermail 2.1.8 : Tue Feb 01 2011 - 06:23:16 PST