Re: reducing warning messages

Geoffrey,

I agree with Kevin that this needs to be a warning that should be 
specified as part of the simulator command line i guess to surpress the 
warning messages. However, I was wondering whether option-d that you 
have suggested might also be a good idea and can be used in a more 
general purpose way and not just restricted to attributes alone. ie. if 
you want warning suppressed between a block of code then you can use the 
directive. Of course, this means that we would have to put it in the 
language but makes it uniform.

A slightly different question on attributes - Attributes as i understand 
are hints to the simulator ie. do not change the behavior or the 
results. Is this always true? If they actually do impact behavior then i 
guess we need to provide a mechanism to import it as part of the 
language so that models are inter-operable and in these cases probably 
best to have the warning in, to indicate that without the attribute 
support the simulation may not behave as expected.

Regards,
Sri

Geoffrey.Coram wrote:
> In developing Verilog-A compact models, I sometimes have to introduce
> special syntax for one compiler to get the model to run, but the same
> syntax causes trouble in another.
> 
> For example, ADMS likes to have attributes like
>  (* type="instance" ask="yes" *)
> but some compilers issue warnings to tell me that they don't recognize
> the attributes "type" and "ask" -- perhaps in case I mis-typed some
> attribute that they do recognize.
> 
> Once I have reviewed these warnings, I would like to suppress them when
> I distribute the model for other users.  What is the correct mechanism
> to suppress these warnings?
> 
> a) a command-line argument to the simulator: this is not ideal, because
>    the user might need to review warnings for her own modules
> 
> b) a "magic comment" like //SUPPRESS_WARNINGS at the top of the file
> 
> c) an attribute like (* suppress_warnings *) module r3_cmc(n1,nc,n2);
> 
> d) a macro like `define suppress_warnings
> 
> These mechanisms won't be in the AMS LRM, but it would be nice to have
> some simulator vendors agree.
> 
> -Geoffrey
> 

-- 
Srikanth Chandrasekaran
Design Technology (Tools Development)
Freescale Semiconductor Inc.
T:+91-120-439 5000 p:x3824 f: x5199

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.