I have not found time to do a systematic review of existing SV-BC enhancement requests, but I tried to think of what first comes to mind. This relates only to enhancements, not to corrections or clarifications, and not to SV-EC areas.
- One issue that comes up frequently among the designers I support is the lack of variable part-selects (Mantis 2684). I understand that in general, SV has well-defined expression sizes. Nevertheless, it would be very helpful to support this. Even if the construct were limited to specific contexts, such as being alone on the RHS of an assignment, it would be very useful. Today, one typically works around this using a combination of left- and right-shifts, which is difficult to understand and error-prone.
- Parameterized functions and structures (Manti 696, 1504). The SV-2009 "let" construct certainly helps, but it is only partial solution.
- Macro/generate enhancements. (various Manti) Both macros and generate constructs have limitations. Generate constructs are limited to complete statements. Macros don't have loops, for example. It would be good to bring them closer. Adopting a good existing pre-processor as standard instead of having special language compiler directives could be one way to help that might be relatively easy to do.
- Variable numbers of arguments for tasks and functions, macros, etc.(Mantis 1566)
- Out of bounds array write checking (Mantis 1144, 2680).
Regards,
Shalom
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On
> Behalf Of Brad Pierce
> Sent: Tuesday, January 26, 2010 11:00 PM
> To: sv-bc@eda.org
> Subject: [sv-bc] Please respond with your #1 SV-BC
> enhancement priority (due by end of January)
>
> Background 1: http://www.eda-stds.org/sv-ieee1800/hm/0956.html
> Background 2: http://bit.ly/7RDGox
> Background 3: http://tinyurl.com/sv-bc-enhancement-requests
>
> Because of the reasons in the above links, Matt and I need
> your feedback on what SV-BC subscribers consider to be their
> #1 SV-BC enhancement priority for the next revision, and why.
> We'll roll it up into a short presentation to the Working Group.
>
> The rules --
>
> 0) This a public process, so all replies go to the
> reflector, not just to Matt or me.
> 1) You must include the number of a Mantis item. If your
> #1 issue is not yet in Mantis, add it first, or get someone
> to add it for you.
> 2) You must include a reason why this enhancement is
> critical for users.
> 3) Replies due by end of January.
> 4) If you believe no SV-BC enhancements should be made in
> the next revision, that's an OK answer, but it needs a reason, too.
>
> Thanks for your help,
>
> -- Brad
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Feb 1 13:02:06 2010
This archive was generated by hypermail 2.1.8 : Mon Feb 01 2010 - 13:02:24 PST