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

Francoise,
 
I think what bothers me is *nesting* of structs (not as I asked in
meeting -- structs with same named members, indeed the tag can
differentiate there). It does not seem the keying mechanism (which
separately I like a lot) can handle that so the vpiStructPattern is
needed for iteration I think. 
 
** Is this what you mean with "The limitation would be that only member
associations would be returned in that case." ? 
 
Please provide an example.
 
Thx.
-Bassam.
 

________________________________

From: owner-sv-cc@eda.org [mailto:owner-sv-cc@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