RE: Some review feedback on the DPI chapter

From: Shabtay Matalon <shabtay_at_.....>
Date: Tue Oct 10 2006 - 10:01:34 PDT
John,

>-----Original Message-----
>From: John Stickley [mailto:john_stickley@mentor.com]
>Sent: Tuesday, October 10, 2006 9:14 AM
>To: Shabtay Matalon
>Cc: Per Bojsen; itc@eda.org
>Subject: Re: Some review feedback on the DPI chapter
>
>Per, Shabtay,
>
>Wow, this is getting interesting.
>
>It kind of shows that if you just blindly follow BNF grammar to see
>what syntax allows, that does not necessarily match with what
>intended semantics allow.
[Shabtay] Yep.
>
>There needs to be semantic clarification text such as what you quoted
in
>26.1.1
>below that sort of puts the reins on what the grammar says you can do.
>I know that on the old days with VHDL we encountered many cases where
> you could not always account for everything in the grammar alone and
>that companion semantic text to place some restrictions was, in many
>cases, required.
>
>I'm inclined to agree with your interpretation Shabtay that wait
statements
>should not be allowed in functions and that that should be clarified. 
[Shabtay] So we agree on this one.
I
>would
>go further to say that I would be surprised if even non-blocking
>assignments
>are allowed either since with previous versions of Verilog they were
not
>and
>that I think functions were intended to be able to be executed and have
>their
>effects matured within a delta cycle. I'd be surprised if this has
changed
>and may explain why ModelSim considers it a violation to have a
>non-blocking assignment within in function.
>
>I will also circulate this among some of our own guru's internally to
>get their opinions.
[Shabtay] I'll wait for your Guru's findings on non-blocking assignments
support within in function and check it out with our guys if needed.

>
>-- johnS
>
>Shabtay Matalon wrote:
>
>>Hi Per,
>>
>>
>>>Following the "trust but verify" principle, I was perusing the SV
>>>
>>>
>>standard
>>
>>
>>>to check your assertion that functions are a superset of non-time
>>>consuming tasks.  To my suprise I discovered that the syntax for
>>>functions allow wait statements.  In Section 12.3, p. 155 of P1800 it
>>>is shown that a function definition can have zero or more
>>>function_statement_or_null in its body.  If you read further in
>>>appendix A it turns out that function_statement_or_null can be
>>>a function_statement and a function_statement is just a statement
>>>which includes wait, see Section A.6.3, p. 532.  Does this mean that
>>>functions can be time consuming as well?  Unless I overlooked
something
>>>it looks like the syntax allows it.
>>>
>>>
>>[Shabtay] I further investigated it with some of our SV working group
>>members and it seems that you indeed uncovered a bug (or at least
>>ambiguity) in the spec. He promises to find out more and have this
>>corrected.
>>
>>However, section 26.1.1 third paragraph clearly states that "All
>>functions used in DPI are assumed to complete their execution
instantly
>>and consume zero simulation time, just as normal SystemVerilog
>>functions."
>>
>>We thus believe that this strong statement reflects the intent of the
SV
>>standard and that your discovery will be fixed to match this
statement.
>>
>>Regards,
>>
>>Shabtay
>>
>>
>>
>
>
>--
>
>This email may contain material that is confidential, privileged
>and/or attorney work product for the sole use of the intended
>recipient.  Any review, reliance or distribution by others or
>forwarding without express permission        /\
>is strictly prohibited. If you are     /\   |  \
>not the intended recipient please     |  \ /   |
>contact the sender and delete        /    \     \
>all copies.                      /\_/  K2  \_    \_
>______________________________/\/            \     \
>John Stickley                   \             \     \
>Mgr., Acceleration Methodologies \             \________________
>Mentor Graphics - MED             \_
>17 E. Cedar Place                   \   john_stickley@mentor.com
>Ramsey, NJ  07446                    \     Phone: (201) 818-2585
>________________________________________________________________
>
Received on Tue Oct 10 10:01:42 2006

This archive was generated by hypermail 2.1.8 : Tue Oct 10 2006 - 10:01:52 PDT