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.comReceived 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