Subject: Re: [sv-bc] SV-BC 26-2: System tasks and functions extensions
From: Gordon Vreugdenhil (gvreugde@synopsys.com)
Date: Fri Mar 07 2003 - 13:48:24 PST
Francoise Martinolle wrote:
>
> Gordon,
>
> %u and %z format specifiers:
> why wouldn't we restrict the %u and %z specifier to only work on packed data
> or scalar? This would force the user to use index selects of field selects to
> get the binary or 4 state value of any other complex type.
> $display("r[1] = %u", r[1]);
> $display("r.a = %u", r.a);
>
> I think it may be dangerous to say that %u on a union returns the value of
> the first
> member.
This was done to be in sync philosophically with the "first field"
in assignment.
> And for unpacked structures, is it a raw dump of the whole struct?
Yes.
> How
> does the user interprets the value coming back?
In exactly the same way as if they had done each of the displays
of fields independently and in sequence. That is what the
proposal was trying to say in the following paragraph:
For unpacked struct data, %u and %z are defined to apply as
though the operation were performed on each member in declaration
order.
> Does the raw dump include pad bits?
Yes, in exactly the same way that individual field dumps would
pad.
>
> $fread.
> I don't understand the proposal at all! An example and detailed description
> would help
>
> Are you adding a new $fread( mystruct, fd)? and $fread(myunion, fd)?
No - there already is a "reg" variant; I am just extending what would
happend to other non-reg variables.
> What is the use for start and count?
There isn't any; V2K defines $fread(reg, fd); my definitions are
simple extensions.
> We could define that start indicates which starting member of the struct
> and count the number of members to load
>
> For $readmem, I am assuming you are keeping the same definition as
> IEEE 1364:
> $reamemb("filename", memory_name[start_addr [, finish_addr]]);
>
> Since memories are 2 dimensional arrays (1 dim on the packed side and 1 dim
> on the unpacked side) and IEEE 1364 did not extend this system task to work
> on multi-dim
> arrays, you may want to add the restriction that unpacked arrays of packed data
> are limited to 1 dimension on the unpacked side, otherwise you have to
> define in which
> order each element of the multi-dimensional array is loaded first in the
> memory.
Absolutely. That was my intent -- it should be changed to read:
$readmemb and $readmemh are extended to ONE DIMENSIONAL unpacked arrays
of packed data
rather than
$readmemb and $readmemh are extended to unpacked arrays
of packed data
Gord.
-- ---------------------------------------------------------------------- Gord Vreugdenhil gvreugde@synopsys.com Staff Engineer, VCS (Verification Tech. Group) (503) 547-6054 Synopsys Inc., Beaverton OR
This archive was generated by hypermail 2b28 : Fri Mar 07 2003 - 13:49:18 PST