Subject: FW: [sv-ec] Email Vote 3 on proposed changes
From: David W. Smith (david.smith@synopsys.com)
Date: Thu Feb 06 2003 - 09:33:45 PST
Here is Kevin's vote.
David
-----Original Message-----
From: Kevin Cameron [mailto:Kevin.Cameron@nsc.com]
Sent: Wednesday, February 05, 2003 11:23 AM
To: David W. Smith
Subject: Re: [sv-ec] Email Vote 3 on proposed changes
Comment
___yes _X_no 1. Approve CH-17 It's all bad.
_X_yes ___no 2. Approve CH-18
_X_yes ___no 3. Approve CH-20
_X_yes ___no 4. Approve CH-47
_X_yes ___no 5. Approve CH-53
_X_yes ___no 6. Approve CH-60
_X_yes ___no 7. Approve CH-83
___yes _X_no 8. Approve CH-84 Should sample data before any changes,
not after cycle starts
_X_yes ___no 9. Approve CH-85
_X_yes ___no 10. Approve CH-86
_X_yes ___no 11. Approve CH-93
_X_yes ___no 12. Approve CH-94
_X_yes ___no 13. Approve CH-95
___yes _X_no 14. Approve CH-96 Should only use NBA syntax for all
delayed assignments.
___yes _X_no 15. Approve CH_97 I don't think this is a concise enough
description
to implement from. Is it a single shared
driver?
Are parallel assignments inertial or
transport?
___yes _X_no 16. Approve CH-98 It's not clear whether the semantics apply
only
to clocking domain use or all sensitive
processes
in "they are propagated in one fell swoop
without
process execution in between drives"
___yes _X_no 17. Approve CH-99 See # 15.
___yes _X_no 18. Approve CH-100 I'd rather label the fork and use the
label name,
"wait fork" is somewhat ambiguous if you
have more
than one fork/join_none. I'd also prefer
the label
name to be usable as an event so you can
just say:
@(<fork label> or ...)
___yes _X_no 19. Approve CH_101 It isn't separate from the structure if
you declare
signals in it.
Regards,
Kev.
-- National Semiconductor, Tel: (408) 721 3251 2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090
This archive was generated by hypermail 2b28 : Thu Feb 06 2003 - 09:34:43 PST