Re: [sv-bc] RE: Please respond with your #1 SV-BC enhancement priority (due by end of January)

Bounced mail from Mirek Forczek ( http://bit.ly/95mgVw )

------------------

Sent: Tuesday, February 02, 2010 5:41 AM

I hope it is still not too late to respond and provide priorities
sugestions for SV-BC.

One important issue in a language is 'separate compilation' - already
mentioned in this discussion.
I've just reported few proposals around that (Mantis 2960, 2961, 2962,
2963, also 2959).

New directions for language expansion could be:
- addition of power related syntax and semantics (similar as UPF in
example, filed Mantis 2964)
- addition of transaction syntax and semantics:
     unlike as in Mantis 1037 (where PLI style enhancement is proposed
for transactions recording),
     I would suggest to express transaction and related semantics
explicitly in the language.
     One possible form could be: a protocol grammar (from transactions
scenarios to signals sequences).
     This could reuse syntax of from 'randsequence' (the grammar) and
'assertions' (the sequences).
     The possible utility functions would be:
     - binding protocol grammar to the bus,
     - encapsulation of implementation protocol clients/interfaces
(actions for grammar productions),
     - monitoring activity on the bus and reporting any violations of
the grammar,
     - automatically matching activity with grammar productions ->
recognizing transactions (and sub-transactions) and their boundaries,
     - automatically recording transactions stream.
   (no Mantis filed yet as there is no strictly defined proposal yet)

Other issues are around keeping symmetry in language:
- same syntax capabilities for subroutine argument passing as for port
connection (Mantis 2957),
- same as above but for sequence/property (Mantis 2958 filed for SV-AC),
- wider usage of :: operator (Mantis 2959)

Also I would like to confirm priority for already mentioned topics and
filed mantis:
- preprocessor improvement: a good idea of adoption CPP or M4
preprocessor, for CPP option - consider also replacement of '`'
character with '#' and drop of '`' character at macro substitution,
   sources formatted this way could be processed with already existing
implementations of CPP,
- naming convention for unnamed blocks - critical since they may contain
declarations (Mantis 2167),
- parametrized structures, again: symmetry in language (Mantis 1504)

Other important clarifications (around classes) are assigned to SV-EC.

Regards,
Mirek Forczek

On 2010-02-01 22:01, Bresticker, Shalom wrote:
> 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.