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.