[sv-bc] Mantis 1619 "default ports" update

Hi Everyone,

I have updated the "default port" proposal with all the requests that
were made.  You don't have to read through all of these answers below if
you want to just look at the latest revision of the proposal itself.
This is more for documentation purposes to make sure I stepped through
everyone's issue and addressed them all.

To follow along with this, just pull up the Mantis item and see the
notes that Shalom posted there.

 

You can find the latest proposal here:

 

1619 - Default Module PortsV3.htm
<http://www.eda.org/svdb/file_download.php?file_id=2747&type=bug> 

 

Thanks, -Tom

 

 

My Notes

In "shall insert the corresponding default value", 'value' -->
'values'??

Fixed
"If .name is used" --> "If an implict .name port connection is used"?

Fixed. 

 

Don Mills: Stu asked during the call what the strength will be of the
default assignment and the discussion noted that the strength will be
strong. Should this be noted in the proposal?
Shalom and I agree that strength is implicitly strong and does not need
to be noted in the proposal. 

Shalom: Maybe more comprehensive would be to say something to the effect
that the default is as though explicitly written in the instantiation.
That would also answer questions like size extension, signing, etc.
Greg Jaxon: That would be the wrong direction to send the reader. Names
in the default expression do not resolve in the instantiation's scope.

To clarify the two comments above I have added this statement in
22.2.2.4 "These default values will be constant expressions evaluated in
the scope of the module where it is defined not in the scope of the
instantiating module.".  I have also added the example below (as
requested by Shalom) which clarifies by example the name scoping
resolution issue. This example also resides in clause 22.2.2.4.

 

Shalom: I would also like to see an example or examples that show the
following:
1. default value is a constant expressionn involving a parameter
2. parameter override in instantiation to show that instance default
uses new parameter value
3. have same parameter identifier defined in scope of instantiating
module, to show that parameter identifier is resolved to that in the
declaration, not in the instantiation location.

 

The following example illustrates default ports semantics and parameter
scoping resolution.  

 

parameter logic [7:0] My_DataIn =  8'hFF;

module bus_conn (

   output logic [7:0] dataout,

   input [7:0] datain = My_DataIn,

   dataout = datain;

endmodule

module bus_connect1 (

   output logic [31:0] dataout,

   input [7:0] datain

   parameter logic [7:0] My_DataIn =  8'h00;

   bus_conn bconn0 (dataout[31:24], 8'h0F);             // Constant
literal overrides default in bus_conn definition

   bus_conn bconn1 (dataout[23:16]);                    // Omitted port
for datain, default parameter value 8'hFF in bus_conn used

   bus_conn bconn2 (dataout[15:8], My_DataIn);          // The parameter
value 8'h00 from the instantiating scope is used

   bus_conn #(My_DataIn = 8'hF0) bconn3 (dataout[7:0]); // The parameter
value in the bus_conn definition is overridden to 8'bF0

endmodule


Maybe also some text to clarify these. (I think the comment I added
above under 22.2.2.4 does this clarification)

 

Gord: It might be good to remove some of the preliminary prose in order
to make the proposal more concise for the editor.

I just put a note in for the editor to skip the prose and where to start
the editing:

 

Stu: I vote no for the followign reasons:
1) The new wording in 22.3.2.3 on .name seems awkward. Why does the
"purpose" of default values need to be explained here? Any purpose and
usage should be described where the construct is defined, not where it
is used.

My comment:  I agree.  I did fix the "hook up" wording on this, but I
kept going over and over in my mind the need to put the "purpose" here.
I think someone asked for this somewhere along the line so we added it
for clarification.  IMHO, I think we should nuke this sentence.
2) Also in 22.3.2.3, the new wording is not clear on if .name will infer
an unnconnected port if the port name is not listed, or if an
unconnected port is only inferred if explicitly listed as unconnected
(e.g. using ".in_port()"). I feel strongly that unconnected ports with
.name and .* should only be inferred if explicitly shown as unconnected,
but I am aware of at least two tools that do not require this.

My comment.  I agree with Stu on this.  I added this comment to the end
of the paragraph "To leave a port unconnected, open brackets must be
used after the implicit .name, i.e. name()."  I also changed the example
to use an empty bracket on rst_n() in the accum instantiation.
3) I re-read the new paragraph being added to 22.3.2.4 on .* several
times, and still cannot figure out what it is trying to define as rules.
Everytime I read the paragraph I come up with a different
interpretation. This paragraph needs to be rewritten, perhaps with a
dashed-list of succinctly stated rules.

I agree.  This paragraph is really wordy and hard to follow.  The new
version should make more sense.

 

Steven Sharp: I think that we need more discussion of the fact that this
creates a difference between .* and a .name connection for every port in
the module declaration. 

We'll have to do this either on the reflector or the next meeting.  I am
not too strongly opposed to just keeping them the same.  I just believe
conceptually the current implementation makes more "end user" sense.

It should also be made clear that the constant expression for the
default is evaluated in the scope of the module where it appears.
Any identifiers will resolve to parameters in that scope, not in the
scope of the instantiation.

Fixed - I added this sentence under 22.2.2.4  "These default values will
be constant expressions evaluated in the scope of the module where it is
defined not in the scope of the instantiating module."

 

There are also some wordsmithing issues. Some of the sentences are
overly complex and hard to follow. There are also some issues with
nonstandard or informal terminology, such as "hook up". Since this was a
first stab at a proposal, I don't think that this is unexpected.

Fixed - Sentence now reads "The purpose of using default values is to
implicitly assign constant expressions to otherwise unconnected input
ports"

 

Dave Rich: I do not like the difference in behavior with explicit port
connection. If the user proved a default, then under no circumstances
should it be left unconnected.

My Response: Our DE's believe the proposal as is makes the most sense.
Also, I believe the proposal as it stands had a consensus on this as
well by the committee. 

 

Cliff: I am not sure if this is really a good idea. I understand the
desire but there are some real potential problems with this proposed
enhancement. I would want to hear Synopsys representatives verbally
commit to support this capability in synthesis, which has generally not
been the case (initial assignments in declarations). If Synopsys
supports this in synthesis, then other tools could be shamed into
supporting this feature. There are other synthesis tools, like
Synplicity, that ignore initial blocks and hence initial assignments.
Here is the potential problem. If you declare the rst_n input of a
module to have a default value of 1'b1 (de-assert reset), and if
synthesis tools ignore the declaration, we now a potentially very
difficult bug to find. During pre-synthesis simulations, reset will be
de-asserted. During postsynthesis simulations, the reset input will
float and lots of other logic will propagate X's in the gate-level
simulation. It might not be obvious that you have a dangling reset
input. Not only that, but we have now introduced another potential
problem that might not be discovered until very late (after synthesis,
not during simulation or compilation). I see some real dangers in this
enhancement.

My response:  I agree with Cliff on this.  Synthesis tools have to
support this. End of story. Otherwise it's too risky to use.

If the above issues are not considered to be significant (because
synthesis would honor the default-inputs), there is still a problem with
the alu_accum3 (.name instantiation of the xtend module), because the
.rst port error has nothing to do with declarations or defaults. The bug
is that there is no rst port on the xtend module, not anything to do
with the default declaration. The
example should be modified.

Fixed: I modified the xtend module so that it used "rst" instead of
"rst_n" and changed all comments appropriately to use the new rst
version.  I then modified the alu_accum3 example to show that the rst
signal did not exist in the instantiating module, even though a default
existed, therefore and error would occur.  

 

 


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.