[sv-bc] Mantis 1526 subsumed in 1707?

I've just uploaded an updated proposal for Mantis 1707.
As part of the clarification in that proposal, I wrote
the following...


-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

This e-mail and any  attachments are  confidential and Doulos Ltd. reserves 
all rights of privilege in  respect thereof. It is intended for the use of 
the addressee only. If you are not the intended recipient please delete it 
from  your  system, any  use, disclosure, or copying  of this  document is 
unauthorised. The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.


> -----Original Message-----
> From: Brad Pierce [mailto:Brad.Pierce@synopsys.com]
> Sent: 22 June 2007 19:05
> To: sv-bc@server.eda-stds.org; sv-ec@server.eda-stds.org
> Subject: Re: [sv-bc] RE: [sv-ec] Formatting strings using %b ???
> 
> 
> If 'expr' is an expression that returns a string, could you 
> bitstream it
> before $displaying it?
> 
>       {>>{expr}}
> 
> See also
> 
>       http://www.eda-stds.org/svdb/view.php?id=1526
> 
> There are frequent needs in real RTL to easily pull the bits out of an
> unpacked data object and into an anonymous simple bit vector and to do
> so in the middle of a larger expression.  This is why I proposed
> 
>       http://www.eda-stds.org/svdb/view.php?id=1401  
> 
> Yes, I know, you can use a macro
> 
>    `define PACKED(expr) $bits(expr)'(expr)
> 
> But we need some clean, standard solution.
> 
> -- Brad
> 
> -----Original Message-----
> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
> Michael (Mac) McNamara
> Sent: Friday, June 22, 2007 11:02 AM
> To: Arturo Salz; Bresticker, Shalom; Jonathan Bromley;
> sv-bc@eda-stds.org; sv-ec@eda-stds.org
> Subject: RE: [sv-bc] RE: [sv-ec] Formatting strings using %b ???
> 
> I would submit that the most user friendly is to convert the offending
> item into something that can be displayed.
> 
> So a %v of a non-scalar takes the least significant bit, and displays
> that; if it is a two state variable, displays St1 or St0;  a %v of a
> real converts the real to a 1 if it is non zero, and 0 if it is zero.
> 
> Similarly a %g, %e or %f of a non real displays the closest 
> real value;
> so %g of 123 yields 123.0
> 
> This is what we did with VCS way back when; I am not sure if that is
> still the case, or if with new data types and format characters this
> concept is still practical to extend to every format from 
> every type of
> argument.
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Arturo Salz
> Sent: Friday, June 22, 2007 9:51 AM
> To: Bresticker, Shalom; Jonathan Bromley; sv-bc@eda-stds.org;
> sv-ec@eda-stds.org
> Subject: RE: [sv-bc] RE: [sv-ec] Formatting strings using %b ???
> 
> Jonathan,
> 
> Unfortunately, the LRM has long been silent regarding the outcome of a
> particular format when an improper (or illegal) data-type is passed to
> the $display calls.
> 
> Other examples of incompatible behavior include using %v with 
> non-scalar
> data, %g, %e, or %f with non-reals, etc...
> 
> If we determine that improper combinations of formats/data-objects are
> to be caught by the tools. The LRMS should list all instances of such
> improper use.
> Making such uses run-time errors at this point will no doubt have an
> impact on legacy runs. Perhaps, the best we can do is a 
> run-time warning
> - and, even a warning will impact legacy runs.
> 
> 	Arturo
> 
> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Bresticker, Shalom
> Sent: Friday, June 22, 2007 1:55 AM
> To: Jonathan Bromley; sv-bc@eda-stds.org; sv-ec@eda-stds.org
> Subject: [sv-bc] RE: [sv-ec] Formatting strings using %b ???
> 
> Actually, I think the LRM never quite defines the string type as an
> unpacked aggregate. I don't think it ever uses the term 
> 'unpacked' with
> respect to string types. It just says that a string is an ordered
> collection of characters.
> 
> Shalom
> 
> > -----Original Message-----
> > From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org]
> > On Behalf Of Jonathan Bromley
> > Sent: Friday, June 22, 2007 11:45 AM
> > To: sv-bc@server.eda-stds.org; sv-ec@server.eda-stds.org
> > Subject: RE: [sv-ec] Formatting strings using %b ???
> > 
> > When a data object of string type is fed to a %b format specifier...
> > 
> > [Shalom Bresticker]
> > 
> > 	%b in normal context prints 0s and 1s. I don't see any
> justification
> 
> > to
> > 	display a string type as a string if %b is specified.
> > 
> > 
> > [Dave Rich]
> > 
> > 	The string data type is an unpacked aggregate. To convert to an 
> > integral
> > 	type requires a cast, and under any other circumstance, this
> should 
> > be
> > 	an error. However, an argument to a system task does not create
> an
> > 	assignment context, so we are free to choose the behavior we
> want.
> > 
> > I don't think you are free so to choose.  See the paragraph 
> in P1800 
> > draft 3a that immediately follows Table 20-2:
> > 
> > 	These [integer] format specifiers [...] shall not be used
> > 	with any unpacked aggregate type.
> > 
> > So, on more careful reflection I conclude that *both* simulators I 
> > tried are non-conforming.
> > 
> > Is this OK with everyone?  Or do we need a further change 
> to 1789 to 
> > permit automatic coercion of strings to packed arrays of 
> bit by this 
> > set of system tasks?  From a user's viewpoint I would have 
> been much 
> > happier if my programming slip-up had been reported as an error, as 
> > indicated by the LRM text I quote above.
> > 
> > --
> > 
> > Jonathan Bromley
> > 
> > 
> > -- This message has been scanned for viruses anddangerous 
> content by 
> > MailScanner, and isbelieved to be clean.
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
> 
> 
> 
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
> 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 
> 

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