mismateched "by order" port connection in Verilog

[Bin Li]

Hi experts,

I have a question about mismateched "by order" port connection. For
follow example:

-----------------
module child ( A, B, C );
input [0:1] A;
output B, C;

INV i1 ( A[0], B );
INV i2 ( A[1], C );

endmodule

module top;
wire [0:1] top_A;
wire top_B, top_C;

child ins1 ( top_A );

endmodule
------------------

ncelab will give follow error message:
ncelab: 05.10-p001: (c) Copyright 1995-2003 Cadence Design Systems,
Inc.
child ins1 ( top_A );
|
ncelab: *W,CUVWSP (./a.v,14|9): 2 ports were not connected:
B
C

And if I change the instance statement to:
child ins1 ( top_A, top_B, top_C, a );

Then ncelab will output:
ncelab: 05.10-p001: (c) Copyright 1995-2003 Cadence Design Systems,
Inc.
child ins1 ( top_A, top_B, top_C, a );
|
ncelab: *E,CUVWLP (./a.v,14|9): Too many module port connections.

My question is: I cannot find corresponding information about
mismatched "by order" port connection in the LRM (IEEE 1364-2001). Do
above ncelab's outputs accord with standard Verilog-2001?

Thanks,
Bin

 

[Peter Lin]

This port order is there in old verilog standard.
I doubt that the new standard will remove it. There is no way
the compiler can guess what is your intention by choosing the order for you.
One other way is to use
child ins1 ( .A( ), .B( ), .C( ) );

/pete
"Bin Li" <binli_work@hotmail.com> wrote in message
news:1e2f5f83.0309111944.10f189df@posting.google.com...

Hi experts,

I have a question about mismateched "by order" port connection. For
follow example:

-----------------
module child ( A, B, C );
input [0:1] A;
output B, C;

INV i1 ( A[0], B );
INV i2 ( A[1], C );

endmodule

module top;
wire [0:1] top_A;
wire top_B, top_C;

child ins1 ( top_A );

endmodule
------------------

ncelab will give follow error message:
ncelab: 05.10-p001: (c) Copyright 1995-2003 Cadence Design Systems,
Inc.
child ins1 ( top_A );
|
ncelab: *W,CUVWSP (./a.v,14|9): 2 ports were not connected:
B
C

And if I change the instance statement to:
child ins1 ( top_A, top_B, top_C, a );

Then ncelab will output:
ncelab: 05.10-p001: (c) Copyright 1995-2003 Cadence Design Systems,
Inc.
child ins1 ( top_A, top_B, top_C, a );
|
ncelab: *E,CUVWLP (./a.v,14|9): Too many module port connections.

My question is: I cannot find corresponding information about
mismatched "by order" port connection in the LRM (IEEE 1364-2001). Do
above ncelab's outputs accord with standard Verilog-2001?

Thanks,
Bin

 

[Steven Sharp]

binli_work@hotmail.com (Bin Li) wrote in message news:<1e2f5f83.0309111944.10f189df@posting.google.com>...

My question is: I cannot find corresponding information about
mismatched "by order" port connection in the LRM (IEEE 1364-2001). Do
above ncelab's outputs accord with standard Verilog-2001?

The LRM does not always describe all possible situations. Sometimes
you have to rely on common sense, based on what the LRM does say. Where
it is still unclear (and doesn't involve new Verilog-2001 functionality),
you can check the behavior of the "de facto" standard, Verilog-XL.

Unattached ports are definitely allowed, since 12.3.6 states that you
can leave out a port expression in connection by name to document that
you are leaving it unconnected. The fact that it says that you do this
only to document leaving it unconnected implies that you can also just
not mention that port. Too few port expressions would be the equivalent
of this for connection by ordered list. So this is legal, but could
still produce a warning. The LRM doesn't restrict where tools can produce
warnings.

(Note that you can also explicitly leave null expressions in your
ordered list, by just putting in commas with nothing between them.
For example, "foo f(1,,2);" lets you leave the second port unconnected,
and "foo f(1,2,);" explicitly leaves the third port unconnected, which
documents that you knew there was another port, but you are deliberately
leaving it unconnected. In this case, you won't get a warning.)

Too many port expressions is clearly a mistake. There are no ports to
connect them to, so this doesn't make sense. So this is an error.

If you test this with Verilog-XL, it produces a warning for the
short list, and an error for the long list. So the first is legal
(though dangerous), but the second is illegal.