RE: [sv-ac] syntax dependency for property keyword

Yes Dmitry/all to be clear not today of course ... I only meant your
enhancements (btw for sequence or property return), and even there I am
overextending things (or even adding to them) from my now faded
recollection -- did not do a refresh on said enhancements.  

Thx.
-Bassam.

-----Original Message-----
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com] 
Sent: Wednesday, January 10, 2007 10:56 AM
To: Bassam Tabbara; john.havlicek@freescale.com; sv-ac@eda-stds.org
Subject: RE: [sv-ac] syntax dependency for property keyword

I don't see how a function may return a property (unless we define the
let statements as functions).

Thanks,
Dmitry

-----Original Message-----
From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com]
Sent: Wednesday, January 10, 2007 8:53 PM
To: Korchemny, Dmitry; john.havlicek@freescale.com; sv-ac@eda-stds.org
Subject: RE: [sv-ac] syntax dependency for property keyword

Hi All,

Dmitry I think the "hard on the eyes" situation I can think of is with
regards to your enhancements of function return, in that case a function
might end up looking like:

Function property myfunc ...

Still seems ok, ugly but likely ok :).

Thx.
-Bassam.

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
Korchemny, Dmitry
Sent: Wednesday, January 10, 2007 7:02 AM
To: john.havlicek@freescale.com; sv-ac@eda-stds.org
Subject: RE: [sv-ac] syntax dependency for property keyword

Hi John,

Yes, it looks convincing.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On
Behalf Of John Havlicek
Sent: Wednesday, January 10, 2007 4:43 PM
To: sv-ac@server.eda-stds.org
Subject: [sv-ac] syntax dependency for property keyword

Hi Dmitry:

I have retrieved the current syntax leading to the keyword "property"
out a few levels.

Comparing this to the structure of tf_port_list, I think it is pretty
convincing that there will be no syntactic ambiguity in adding
"property" as a type in port lists.

One could carry out the same exercise with "sequence" and "event".

J.H.


Keyword "property":
-------------------

The following are the only productions in which the terminal property
appears:

   assert_property_statement::=
      assert property ( property_spec ) action_block
   
   assume_property_statement::=
      assume property ( property_spec ) ;
   
   cover_property_statement::=
      cover property ( property_spec ) statement_or_null
   
   property_declaration ::=
      property property_identifier [ ( [ tf_port_list ] ) ] ;
         { assertion_variable_declaration }
         property_spec ;
      endproperty [ : property_identifier ]


The following is the only production in which any of the nonterminals
assert_property_declaration, assume_property_declaration, or
cover_property_declaration appears on the RHS:

   concurrent_assertion_statement ::=
      assert_property_statement
      | assume_property_statement
      | cover_property_statement


The following is the only production in which the nonterminal
concurrent_assertion_statement appears on the RHS:

   concurrent_assertion_item ::= [ block_identifier : ]
concurrent_assertion_statement


The following is the only production in which the nonterminal
property_declaration appears on the RHS:

   concurrent_assertion_item_declaration ::= 
      property_declaration
      | sequence_declaration

The following are the only productions in which the nonterminal
conncurrent_assertion_item appears on the RHS:

   module_common_item ::=
      module_or_generate_item_declaration
      | interface_instantiation
      | program_instantiation
      | concurrent_assertion_item
      | bind_directive
      | continuous_assign
      | net_alias
      | initial_construct
      | final_construct
      | always_construct
      | loop_generate_construct
      | conditional_generate_construct

   non_port_program_item ::=
      { attribute_instance } continuous_assign
      | { attribute_instance } module_or_generate_item_declaration
      | { attribute_instance } initial_construct
      | { attribute_instance } final_construct
      | { attribute_instance } concurrent_assertion_item
      | { attribute_instance } timeunits_declaration17
      | program_generate_item

The following are the only productions in which the nonterminal
conncurrent_assertion_item_declaration appears on the RHS:

   package_or_generate_item_declaration ::=
      net_declaration
      | data_declaration
      | task_declaration
      | function_declaration
      | dpi_import_export
      | extern_constraint_declaration
      | class_declaration
      | class_constructor_declaration
      | parameter_declaration ;
      | local_parameter_declaration
      | covergroup_declaration
      | overload_declaration
      | concurrent_assertion_item_declaration
      | ;

   clocking_item ::=
      default default_skew ;
      | clocking_direction list_of_clocking_decl_assign ;
      | { attribute_instance } concurrent_assertion_item_declaration




--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

--
This message has been scanned for viruses and dangerous content by
MailScanner, and is believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.