Subject: RE: [sv-cc] Updated version of SV VPI extensions (dated Jan 12)
From: Bassam Tabbara (bassam@novas.com)
Date: Wed Jan 14 2004 - 08:47:28 PST
Joao, thx for the hard work, I also did a quick skim and want to add some
comments:
- for "property expr" somehow it points back to sequence expr, it does not
seem to make allowance for (Does it ?):
Prop : prop1 composition_operator prop2
- assume still not there
- expect not there ..
(Please see my list from last time, attached)
Doug's list:
>
> Joao, Team,
>
> Here are some questions/comments on the latest version of the
> VPI spec. Sorry we didn't have time to do a more thorough job on this.
>
> 1. vpiInstance is described on pages 1 and 4 as
> (package, module, interface, program).
> On page 4, there is reference to an "immediately enclosing scope".
> What about named generate scopes? It seems to me that since those
> are valid scopes in the simulation image, a query to vpiInstance
> should return a handle to that scope, rather than its surrounding
> (package, module, interface, program).
>
> 2. What about Compilation unit scope? ($unit)
> I don't see any reference to that.
> $unit is *almost* exactly like a package.
> Some differences are:
> - The scope automatically runs out at the end of a
> translation unit
> (normally a single file, but can be the set of files presented
> to the tool at once as per a user-selectable option)
> - You can declare modules and interfaces in $unit scope but
> not in a package
>
> 3. Typo on page 3, "prgrams" should be "programs"
>
> 4. On the bottom of page 11 there is a red "Needs Note" that should
> be fixed up. There is some half-tone overlaid text to the right
> of that which looks unusual and should be cleaned.
>
> 5. To the right of bit Tspec is a dangling line segment.
>
> 6. In the Scope (26.6.3) section, how does an "unnamed scope"
> come about? I think we should be more explicit in this note.
> The only example I can think of is an unnamed generate block.
> However, the IEEE is leaning towards considering such scopes
> as fully collapsed into their next-outer enclosing scope
> (post-elab view).
>
> 7. In Task, Function Declaration (26.6.18), Note 2 refers to
> vpiInterfaceTask/vpiInterfaceFunction. However, those are not
> defined anywhere in the diagram above. Also, what is "extern"
> and "DPiExtern"? Shouldn't the latter be "DpiImport"?
>
> 8. Starting on page 27, the font describing the various "str:", "int:"
> etc. changes from the font normally used for that job. Should be
> cleaned up to be consistent.
>
> 9. On page 29, the "multiclock sequence expr" balloon has
> weird looking
> astigmatic font problems(!)
>
> 10. Did you have time to look over the tagged unions feature that was
> approved by SV-BC last month?
>
> Thanks for all the good work.
> It's really nice to have VPI up near to the feature set of
> the primary language, rather than lagging far behind.
>
> Regards,
> Doug
>
attached mail follows:
Hi Joao,
The following list of issues is related to draft3 of LRM with the
changes/extensions to the Assertion chapter (17). I think the easiest way is
to refer to the Annex A with the formal BNF.
** Can you please review these issues with Surrendra if need be, I'll be
glad to give it a once over after your changes.
%%%%%%
1) concurrent assertions (start page 26):
ok, my mistake (see 7 and 8 for where the fixes should go).
2) property spec on p. 28
- needs multi_clock_property_expr
3) Add new multi_clock_property_expr
4) property expr on p. 28
- needs another "property expr (detail)" that one is similar to sequence
expr (but more restricted)
(now (draft3) there is property composition as well, properties do not
just necessarily reference a sequence only).
5) multi_clock_seq added (not just expr, there can also be a clocking_event
decl inside), this is a minor addition
6) p. 31, sequence expr need to add "dist" as well.
expression_or_dist::=
expression
| expression dist { dist_list }
LRM 133
7) p. 33 where "immediate assert" is used add also the following (the
assume below)
A.6.10 Assertion statements
procedural_assertion_item ::=
assert_property_statement
| cover_property_statement
| immediate_assert_statement
| assume_property_statement
8) Add "expect_property_statement" (see A.2.10 Assertion declarations) I
think also p. 33 (same as assume above)
A.6.4 Statements
statement_or_null ::=
statement
| { attribute_instance } ;
statement ::= [ block_identifier : ] { attribute_instance } statement_item
statement_item ::=
{ attribute_instance } blocking_assignment ;
| { attribute_instance } nonblocking_assignment ;
| { attribute_instance } procedural_continuous_assignments ;
| { attribute_instance } case_statement
| { attribute_instance } conditional_statement
| { attribute_instance } inc_or_dec_expression ;
| { attribute_instance } function_call ;
| function_call_statement
| { attribute_instance } disable_statement
| { attribute_instance } event_trigger
| { attribute_instance } loop_statement
| { attribute_instance } jump_statement
| { attribute_instance } par_block
| { attribute_instance } procedural_timing_control_statement
| { attribute_instance } seq_block
| { attribute_instance } system_task_enable task_enable_statement
| { attribute_instance } task_enable
| { attribute_instance } wait_statement
| { attribute_instance } procedural_assertion_item
| { attribute_instance } clocking_drive
| void ' ( function_call )
| randsequence
| scope_randomize
| randcase_statement
| expect ( property_spec ) [ action_block ]
| expect ( property_instance ) [ action_block ]
| expect_property_statement
LRM 66
LRM 39
LRM 41
LRM 62
LRM 63
LRM 66
LRM 73
LRM 113
LRM 136
%%%%%%%
-- Dr. Bassam Tabbara Technical Manager, R&D Novas Software, Inc.http://www.novas.com <http://www.novas.com/> (408) 467-7893
This archive was generated by hypermail 2b28 : Wed Jan 14 2004 - 08:49:33 PST