[sv-bc] FW: [sv-ec] Mantis Items 3075-3081

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Gordon Vreugdenhil
Sent: Friday, October 29, 2010 3:49 PM
To: Daniel Schostak
Cc: sv-ec@eda.org
Subject: Re: [sv-ec] Mantis Items 3075-3081

The statement in the standard isn't completely useless -- as I did indicate,
there are some VPI implications (and potentially vendor gui implications)
regarding the fact that ordering isn't defined. Ordering is of course
defined
for normal code -- it is the order of appearance. The incorrect assumption
in all of this is that the ordering has any impact to hierarchical
resolution
or similar elaboration effects. It doesn't. If you would like to suggest
some clarifying text there, that would be fine with me, however I would
not want
to get into a long description of various aspects of this discussion at that
point in the LRM.

Gord.

On 10/29/2010 4:05 AM, Daniel Schostak wrote:
> My concern with respect to bind statements was originally to try to get some more defined ordering, as you have addressed in your reply. I understand your arguments as to why this would be problematic and cannot see a solution that would answer them. However, I think the statement that I quoted from the Standard about elaboration order and binds is potentially misleading, and this is what I am concerned about now. I have not found a similar statement about elaboration order and module instantiation not using bind in the Standard and thus the statement about bind looks like it might be imposing special requirements rather than making clear something that is also true for module instantiation not using bind. Indeed, in some discussions (not on sv-ec), this is how it has been presented and I have been given this as a justification for there being limitations on using hierarchical references with bind statements. Although I could now use this email thread as evidence to indicat
 e this is not the intended interpretation of the Standard, I think it is worth clarifying the statement about elaboration order to make it clear that the choice of order should not affect the end result.
>
> From, Daniel.
> ________________________________________
> From: Gordon Vreugdenhil [gordonv@model.com]
> Sent: 27 October 2010 19:40
> To: Daniel Schostak
> Cc: sv-ec@eda.org
> Subject: Re: [sv-ec] Mantis Items 3075-3081
>
> Daniel,
>
> Just some comments on 3075 here.
>
> One must be very careful when talking about elaboration and hierarchical
> resolution
> in SV. Hierarchical names and other elaboration behavior are almost
> completely
> defined in a "declarative" manner rather than a "procedural" manner.
> That means
> that the elaboration relationships describe the "end result" rather than
> the process
> by which one evaluates the design to achieve the end result.
>
> There are a few very minor (historical) exceptions, the most notable
> being that
> the "last" defparam (in a textual manner!) is supposed to win. But even
> that is
> nonsensical in the presence of separate compilation; the restriction
> dates back
> to original implementation.
>
> In a normal design it in fact is the case that a permutation of
> instances within
> a module is immaterial to the end result. Any hierarchical references,
> etc. are
> either legal (in the end design) or not; the order of appearance (of
> either the
> reference or the target) does not matter.
>
> This is true even for randomization effects. The LRM is clear -- "Each
> module instance,
> interface instance, program instance, and package has an initialization RNG.
> Each initialization RNG is seeded with the default seed." (18.14.1). So
> changing
> the order of instances must not impact the results. A trivial example is
> as follows:
>
> module top;
> child c1();
> child c2();
> endmodule
>
> module child;
> int x;
> initial begin
> x = $urandom();
> $display("%d", x);
> end
> endmodule
>
>
> It must be the case (in any implementation) that c1 and c2 provide the same
> result. Not only that, but adding a new instance in top or permuting the
> order cannot impact that result.
>
> About the only thing that I can think of as impacting results are via
> PLI access to items within the parent. But any such application that
> would "hard code" ordering assumptions is likely not very robust so I can't
> really bring myself to worry about that so much.
>
> Now, let me consider the alternative for a moment. If you were to define
> the ordering, how would you do that? Due to the declarative aspect of the
> "bind" itself, I don't think you could use the "order of binding" since that
> is not defined (and I would object to such a definition). So what then?
> Lexographic ordering by instance name? That would be possible, but do
> you really want to worry about perturbations of ordering due to the addition
> of a new bind?
>
> So I think that the LRM text is appropriate as it stands unless there are
> things that I haven't considered. If specific implementations have
> additional restrictions (implicit ordering assumptions as you suggest
> that impact hierarchical resolution), you should take those up with
> the vendor.
>
> Gord.
>
>
>
>
>
>
> On 10/25/2010 11:03 AM, Daniel Schostak wrote:
>> Mantis Item 3075 (elaboration of bind statements):
>> --------------------------------------------------
>>
>>> From the discussion in the meeting on Sep 27 2010, it appears that a number of restrictions on bind statements have been relaxed but the text of the Standard has not necessarily been updated to reflect this. For example, the statement in section 23.11 that:
>> "If multiple bind statements are present in a given scope, the order of those statements is not important. An implementation is free to elaborate bind statements in any order it chooses."
>>
>> could be taken as forbidding one bind statement making hierarchical references to an instance created by another bind statement in the same scope. I believe from the discussion it should not be interpreted in this way and therefore I am not sure what it is trying to add. The simplest proposal would be to delete it, but if someone thinks the statement still has value I think it would be worth adding a clarifying sentence about cross module references and bind statements.
>>
>> [...]
>> From, Daniel Schostak.
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>>
> --
> --------------------------------------------------------------------
> Gordon Vreugdenhil 503-685-0808
> Model Technology (Mentor Graphics) gordonv@model.com
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.