[sv-bc] RE: [sv-ec] Wrong SV code in VMM

You may be right, but there are other cases already in SV. 8.19 says,

"Virtual methods provide prototypes for the methods that later override
them, i.e., all of the information generally found on the first line of
a method declaration: the encapsulation criteria, the type and number of
arguments, and the return type if it is needed. Later, when subclasses
override virtual methods, they shall follow the prototype exactly by
having matching return types and matching argument names, types, and
directions. It is not necessary to have matching default expressions,
but the presence of a default shall match." 

This says at least that both the prototype and the override need to be
consistent in the presence of a default.

Shalom

> -----Original Message-----
> From: Mirek Forczek [mailto:mirekf@aldec.com.pl] 
> Sent: Friday, July 18, 2008 12:53 PM
> To: Bresticker, Shalom; 'Surya Pratik Saha'; 
> sv-ec@server.eda.org; sv-bc@server.eda.org
> Subject: RE: [sv-ec] Wrong SV code in VMM
> 
> Hi,
> 
> ad 2)
> 
> Please note that in C++ in example having the default in both 
> places is considered as an error.
> 
> And such resolution is reasonable somehow: once you allow the 
> default to be specified in two places, there is a risk that 
> one othe placed will be updated later and the other not, 
> which will lead to hard-tracking bugs.
> 
> Regards,
> Mirek  
> 
> -----Original Message-----
> From: owner-sv-ec@server.eda.org 
> [mailto:owner-sv-ec@server.eda.org] On Behalf Of Bresticker, Shalom
> Sent: 18 lipca 2008 11:41
> To: Surya Pratik Saha; sv-ec@server.eda.org; sv-bc@server.eda.org
> Subject: RE: [sv-ec] Wrong SV code in VMM
> 
> Hi,
> 
> You're correct, there is no SV 1800-2008 LRM.
> 
> 1. You're correct, `" is only defined in macro text. In fact, 
> this is one of the gotchas appearing in the SV Gotchas paper 
> I will be presenting at Boston SNUG in September.
> 
> 2. In Draft 6, 8.23 says,
> 
> "The out-of-block method declaration shall match the 
> prototype declaration exactly; the only syntactical 
> difference is that the method name is preceded by the class 
> name and the class scope resolution operator ::."
> 
> That seems to require that the default appear in both places.
> 
> Regards,
> Shalom
> 
> > -----Original Message-----
> > From: owner-sv-ec@server.eda.org
> > [mailto:owner-sv-ec@server.eda.org] On Behalf Of Surya Pratik Saha
> > Sent: Friday, July 18, 2008 12:19 PM
> > To: sv-ec@server.eda.org; sv-bc@server.eda.org
> > Subject: [sv-ec] Wrong SV code in VMM
> > 
> > Hi,
> > I am not sure whether this is the appropriate body to discuss about 
> > this matter, but since it is related to SV, so I am sending 
> the mail.
> > If it is not appropriate, please ignore this.
> > 
> > I have downloaded the freely available VMM release (version 1.0.1), 
> > where it is mentioned it is compatible with SV 1800-2008. 
> But I don't 
> > think there is any SV 1800-2008 LRM.
> > Or do I miss any?
> > 
> > Moreover, I have seen following problems in that VMM.
> > 1) A special syntax used with `".
> > Consider the e.g:
> > `define VMM_CHANNEL xxx
> > module top;
> >     initial begin
> >         $display("VMM_CHANNEL %s", `"`VMM_CHANNEL`");
> >     end
> > endmodule
> > 
> > Here `" is used in normal position. But as per SV 1800-2005 LRM, `" 
> > can only be used in macro text. Is it changed later?
> > 
> > 2) Function declaration having default argument, though 
> body does not 
> > have.
> > Consider the e.g.:
> > module top;
> >     class C;
> >         extern function int f(input x, input y = 1);
> >         endclass
> >     function int C::f(input x, input y);
> >         f = x;
> >     endfunction
> >     int x;
> >     C c;
> >     initial begin
> >         x = c.f(1);
> >     end
> > endmodule
> > 
> > Where for 'y', the function declaration is having default argument 
> > value, whereas the body does not have. I am not sure whether LRM 
> > supports that or not.
> > 
> > --
> > Regards
> > Surya
> ---------------------------------------------------------------------
> 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.
> 
> 
> 
---------------------------------------------------------------------
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.