RE: [sv-bc] 19.12.5: array of instances connection to packed array port

From: Feldman, Yulik <yulik.feldman_at_.....>
Date: Mon Sep 25 2006 - 07:06:17 PDT
Clearly, the mapping from the bits of the original type to the bits of
the "linearized" vector is well defined already (although not
explicitly). My main point was that the reverse mapping is not currently
defined, and if one would try to define it, he will soon discover some
ambiguities, not existing in the direct mapping.

While the reverse mapping is not strictly necessary in order to define
the language semantics, it may be helpful to explain certain concepts,
like explaining what should be connected to the ports of unrolled arrays
of instances. As of now, the sentence describing this specific language
feature is not clear. It may be improved using the notion of bit
significance, without providing a reference to the explicit definition
of the "linearized" vector. The language may be further improved by
providing such explicit definition (for all types), and providing a
reference to it in this and maybe other places, where it may be
convenient to use it. The definition may be even further improved by
defining the currently undefined "reverse" mapping, as it would allow to
know what "real" objects to expect to be connected to the ports, rather
than just understanding the semantics by knowing what bits are
connected. I'm not sure, but this may be even required in order to
define unambiguously how the model should look like when being accessed
through PLI. Even if it is not required for PLI, it may still be useful
for helping tool implementers developing Verilog data models to create a
"standard" object representation (when a decomposition of the
"linearized" vector to the "original" objects is required).

I think there is no objection that the specific sentence in 19.12.5
should be improved. The question is only whether to do it by providing
an explicit definition of the "linearized" vector, and, if yes, whether
to include the definition of "reverse mapping" in this explicit
definition. Both are nice-to-have, but not required, I think.

--Yulik.

-----Original Message-----
From: Steven Sharp [mailto:sharp@cadence.com] 
Sent: Friday, September 22, 2006 4:22 AM
To: jonathan.bromley@doulos.com; sv-bc@eda-stds.org; Feldman, Yulik
Subject: RE: [sv-bc] 19.12.5: array of instances connection to packed
array port


>From: "Feldman, Yulik" <yulik.feldman@intel.com>

>Once such notion is defined, the bit mapping between the original type
>and the vector will also be needed to be defined, in both directions.
>This will help in understanding how the ports of arrays of instances
are
>mapped.

I think the existing LRM text defines it already.


>Note that there can be some complexities in such definition. For
>example:
>
>1. Mapping from the bit vector to the original type is ambiguous, when
>the original type contains packed unions.

I am not sure what you mean here.  I believe it is completely defined.
What do you think is ambiguous?


>2. Note every slice of the vector can be mapped to a single slice of
the
>original type. For example, if we have two dimensional array
>a[1:0][1:0], which is mapped into a one-dimensional vector a'[3:0],
then
>the slice a'[2:0] doesn't have direct representation using a single
>slice on "a".

Yes.  As I mentioned, this complicates attempts to describe the
behavior clearly.  The slicing that is done on the vector may not
be representable by the user in SystemVerilog code.  That makes it
hard to describe using the usual terminology.


>3. If the original type contains a packed struct with one member,
should
>the slice on the vector that slices the whole struct be mapped to the
>member of the struct, or to the whole struct?

I am not sure what the distinction is that you are making here.  Can
you elaborate?  Anyway, the answer is presumably the whole struct.
If you want it to be the member, then use the member as the port
expression instead of the struct.


Steven Sharp
sharp@cadence.com
Received on Mon Sep 25 07:07:06 2006

This archive was generated by hypermail 2.1.8 : Mon Sep 25 2006 - 07:07:28 PDT