VHDL Issue Number: 1046 Classification: Language Definition Problem Language Version: VHDL-93 Summary: Unclear definition of "resolved signal." Related Issues: 0095, 0219, 0230, 0233, 0246 Relevant LRM Sections: 4.3.1.2 Key Words and Phrases: resolved signal Current Status: Submitted 1076-1993 Disposition: N/A Disposition Rationale: N/A Superseded By: N/A ----------------------- Date Submitted: 1994/03/18 Author of Submission: Charles Swart Author's Affiliation: Mentor Graphics Corporation Author's Post Address: 8005 S.W. Boeckman Road Wilsonville, OR 97070-7777 Author's Phone Number: (503) 685-1332 Author's Fax Number: (503) 685-1268 Author's Net Address: chuck_swart@mentorg.com ----------------------- Date Analyzed: TBD Author of Analysis: TBD Revision Number: $Revision: 1.4 $ Date Last Revised: $Date: 1995/05/15 20:07:17 $ Description of Problem ---------------------- (This combines IR 0233 with IR 0246.) The rules concerning resolved signals given in section 4.3.1.2 are incomplete and inadequate for some forms of composite signals. To illustrate these problems, consider the following VHDL code: entity E is function wired_or (A:bit_vector) return bit; subtype resolved_bit is wired_or bit; type vector_of_resolved_bit is array (natural range <>) of resolved_bit; type array_of_bit is array(1 to 10) of bit; type vec_array_of_bit is array( natural range <>) of array_of_bit; function wired_array_of_bit(b:vec_array_of_bit) return array_of_bit; subtype resolved_array_of_bit is wired_array_of_bit array_of_bit; type array_of_resolved_array_of_bit is array( natural range <>) of resolved_array_of_bit; type mixed_record is record x : bit; y : wired_or bit; end record; type mixarray is array (integer range <>) of mixed_record; function resmix (A: mixarray) return mixed_record; type big is record vect : vector_of_resolved_bit (7 downto 0); rec : resmix mixed_record; end record; signal S1 : vector_of_resolved_bit( 1 to 10); signal S2 : array_of_resolved_array_of_bit( 1 to 10); signal S3 : mixed_record; signal S4 : big register; end E; Is S1 a resolved signal? Everyone would agree that S1 is resolved in some sense (perhaps at the element level.) However, the LRM states (all quotes are from section 4.3.1.2): "If the name of a resolution function appears in the declaration of a signal, or in the declaration of the subtype used to declare the signal, then that resolution function is associated with the declared signal. Such a signal is called a resolved signal." This definition seems to cover only the case in which resolution occurs for the entire composite, and does not cover the case in which resolution occurs at the subelement level. Is S2 a resolved signal? The consensus is that S2 is not itself resolved, but that it consists of subelements which are resolved. Yet the definition of resolved signals does not seem to apply to subelements, but only to the declared signal. There is general agreement that if a process drives S2(1)(1) then it must also drive S2(1)(2) through S2(1)(10), but that it need not drive, for example, S2(2). The applicable LRM paragraph reads: "If a subelement of a resolved signal of composite type has a driver in a given process, then every scalar subelement of that signal must have a driver in the same process, and the collection of all of those drivers taken together constitute one source of the signal." The definition of resolved signal should be such that the above general agreement holds. Is S3 a legal signal? I spoke with several vendors about this. Some had vague recollections about a requirement in the LRM that stated that if one element of a composite signal were resolved, then all elements had to be resolved, but no one was able to find such a reference. Several vendors think that S3 is a legal signal. If S3 is a legal signal, then is it resolved? Again, the general view is that S3 is not resolved, but that it contains resolved elements. IR 0095 deals with related issues in considering null transactions applied to composite signals. It introduces the notion of a basic signal, which seems to be a step in the right direction in resolving this issue. However, that definition uses the concept of resolved signal in its definition, hence, can't be used as written to define a resolved signal. The definition of a resolved signal given at the beginning of Section 4.3.1.2 of the LRM does not seem to include the signal S4 in the above example. Should it? Furthermore, it would seem that S4.vect is not a resolved signal, but that S4.rec is. Finally, what about S4.rec.x and S4.rec.y? Proposed Resolution ------------------- We believe that the term "resolved signal" is applicable only at the level of granularity at which a resolution function is supplied. Thus, in the example, S1 is not a resolved signal, but S1(n) is resolved for each value of n. S2 is not a resolved signal, but S2(n) is resolved. S3 is not a resolved signal, nor is S3.x, but S3.y is resolved. S4 is not a resolved signal, nor is S4.vect. S4.rec is resolved, and so is each scalar S4.vect(n). However, S4.rec.x and S4.rec.y are not resolved signals. Note that S4.rec.y might seem to be resolved, since there is a resolution function mentioned in its element declaration; however, since this is not the effective resolution function, we say that it is not a resolved signal, but only a component of a resolved signal. The concept of resolved signal in the LRM should be revised to include subelements of signals which are resolved, even though the signal itself is not resolved. Rules about drivers and such need to apply to resolved subelements of signals, not just to entire signals. Perhaps there needs to be two definitions of resolved signal. One broad, "high level" definition would describe the situation in which a signal either is itself resolved or contains an element which is resolved. Another "low level" definition would describe the level at which resolution actually occurs, i.e, the leval at which a resolution function is applicable. The LRM seems to incorrectly intermix these two concepts. Under these interpretations all signals S1, S2, S3, and S4 are resolved in the broad sense, while low-level resolution occurs for S1(n), S2(n), S3.y, S4.rec, and S4.vec(n). VASG-ISAC Analysis & Rationale ------------------------------ TBD VASG-ISAC Recommendation for IEEE Std 1076-1993 ----------------------------------------------- TBD VASG-ISAC Recommendation for Future Revisions --------------------------------------------- TBD