[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: Wednesday, October 27, 2010 8:41 PM
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
-- 
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.