RE: [sv-cc] diagram 27.47 "Patterns" issues

hi all,
 
I like Francoise's suggestions in general because I think it works to
align us more closely to the language, plus I agree with Bassam that it
is unhelpful to convert the sparse notation to a very dense one as it
passes into VPI. But I think we might need to be a little more
aggressive.
 
Here's the BNF from P1800 section A.6.7.1, titled "Patterns"
 
pattern ::=
. variable_identifier
| .*
| constant_expression
| tagged member_identifier [ pattern ]
| '{ pattern { , pattern } }
| '{ member_identifier : pattern { , member_identifier : pattern } }

assignment_pattern ::=
'{ expression { , expression } }
| '{ structure_pattern_key : expression { , structure_pattern_key :
expression } }
| '{ array_pattern_key : expression { , array_pattern_key : expression }
}
| '{ constant_expression { expression { , expression } } }

structure_pattern_key ::= member_identifier | assignment_pattern_key
array_pattern_key ::= constant_expression | assignment_pattern_key
assignment_pattern_key ::= simple_type | default
assignment_pattern_expression ::=
[ assignment_pattern_expression_type ] assignment_pattern
assignment_pattern_expression_type ::= ps_type_identifier |
ps_parameter_identifier | integer_atom_type
constant_assignment_pattern_expression ::= assignment_pattern_expression
assignment_pattern_net_lvalue ::=
'{ net_lvalue {, net_lvalue } }
assignment_pattern_variable_lvalue ::=
'{ variable_lvalue {, variable_lvalue } }
 
(it's easier to read in the PDF because of the colors and tabbing).
 
I would say that the BNF differentiates "pattern" from
"assignment_pattern" but the VPI attempts to force them both into the
"pattern" class, so maybe what we need is to split them apart in the VPI
too, keeping "vpiPattern" for the case usage and adding a
"vpiAssignmentPattern" object (or class). In the BNF, assignment_pattern
is neither an explicit nor implicit subset of pattern, in fact it is
fairly dissimilar. I think it's a good goal to keep the informational
model aligned with the BNF as far as possible.
 
By the way, is it just me, or does the BNF as written disallow mixing
assignment expression types in one assignment_pattern? For example one
of the choices for assignment_pattern is:
 
'{ structure_pattern_key : expression { , structure_pattern_key :
expression } }

which implies that if you start with a structure_pattern_key, that's the
only form you can continue with.
 
I wonder if someone forgot the form:
 
 '{ assignment_pattern { , assignment_pattern } }
 
The 8.13 examples clearly allow it; I can't get them to be valid within
the existing BNF, but reading BNF is pretty tricky in my experience so
I'm prepared to be educated!

Abi

________________________________

From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org] On
Behalf Of francoise martinolle
Sent: Tuesday, April 25, 2006 8:50 PM
To: 'SV-CC'
Subject: [sv-cc] diagram 27.47 "Patterns" issues



The diagram section 27.47 refers to pattern matching expressions used in
case statement and if statements (see 10.4.1). 

At the very least, there should be a note explaining what each of the
classes  (taggedPattern, AnyPattern, StructPattern)

represent as it is not obvious.

Pattern matching expressions are used for tagged unions.

Tagged unions are unions for which you can specify at compile time which
member of the union you are assigning or reading from. 

This pattern diagram 27.47 is supposed to provide access to the
following syntax:

pattern ::=

. variable_identifier

| .*

| constant_expression

| tagged member_identifier [ pattern ]

| '{ pattern { , pattern } }

| '{ member_identifier : pattern { , member_identifier : pattern } }

// from A.6.7.1

Example:

typedef union tagged {

    struct {

              bit [4:0] reg1, reg2, regd;

    } Add;

   union tagged {

             bit [9:0] JmpU;

             struct {

                     bit [1:0] cc;

                     bit [9:0] addr;

           } JmpC;

   } Jmp;

} Instr;

...

Instr instr;

...

case (instr) matches

tagged Add '{.r1, .r2, .rd} &&& (rd != 0): rf[rd] = rf[r1] + rf[r2];

tagged Jmp .j : case (j) matches

tagged JmpU .a : pc = pc + a;

tagged JmpC '{.c, .a}: if (rf[c]) pc = a; endcase

The vpiTaggedPattern represents for example an expression of the form "
tagged Add '{.r1, .r2, .rd}"

 .r1, .r2 and .rd a local variables created for the purpose of doing
pattern matching, they corresponds to the following members 

reg1, reg2, regd of the struct Add selected by the tag "Add".

In a taggedPattern, the typespec relationship will return the typespec
represented by the tag "Add" (a structTypespec).

The pattern relationship should return a structPattern or an expression
(ex: tagged Jmp .j). 

There is a problem in the VPI model for structPattern. It should allow
to iterate over each member of the struct pattern, 

each member should have a name and expression associated with the member
name. I believe that a structPattern

preceded the addition of vpiOperation representing an assignPatternOp
and could be replaced with an operation which operands

are vpiAssocExpr of vpiKey vpiMemberKey (proposed in an earlier email on
assignment patterns).

The anyPattern is supported to represent a ".*" found in a case pattern.
Not sure why we need a vpiName property for the 

anyPattern, since the name is quite obvious :.*

 

I would like to change this diagram and add a few notes describing the
access and illustrating with examples.

The proposed changes are:

  - remove  vpiStructPattern, such expressions of type vpiOperation
(vpiAssignPatternOp)

    can already by obtained with the expr class. The limitation would be
that ony member associations would be returned

    in that case.

 - remove vpiName for vpiAnyPattern

Francoise