Subject: Re: [sv-bc] Proposals for SV3.1a
From: Dave Rich (David.Rich@synopsys.com)
Date: Tue Sep 23 2003 - 11:24:27 PDT
Steven,
The original requirement was to address modules, not primitives. It was
just easier to explain the semantics of the feature using primitives.
The motivation for this feature came from the Module Compiler group.
This feature addresses two of their issues.
1. to be able to represent hardware as a function call, and later
replace the call with the actual hardware, without have to change the
function call.
2. to represent hardware as a function call and not need to create names
for all the top level interconnect signals.
I agree there is ambiguity in event expressions, so maybe their use
needs to be restricted. Even without this ambiguity, there is reason to
restrict the use as we did with assignment operators.
Dave
Steven Sharp wrote:
>How does "and(a,b)" give any benefit over "a&b"? The possibility that
>someone might think it is already legal is not sufficient reason to make
>it legal. Someone might also think it is legal to use module names as
>well as primitive names in this way. Should that be added too, and what
>would it mean? You can't take every user error and make it part of the
>language.
>
>How are you planning on dealing with the ambiguity of "or" being used as
>an event-or in event expressions already? Do you expect the user to
>decipher the differences between @(a or(b)) and @(a, or(b)) and @(a or or (b))
>and @(a, or(b,c))? I don't know that there are any situations that are
>actually gramatically ambiguous, but you definitely need a lot of context
>to figure out what an "or" actually represents.
>
>Steven Sharp
>sharp@cadence.com
>
>
>
>
-- -- David.Rich@Synopsys.com Technical Marketing Consultant http://www.SystemVerilog.org tele: 650-584-4026 cell: 510-589-2625
This archive was generated by hypermail 2b28 : Tue Sep 23 2003 - 11:26:16 PDT