Subject: Fwd: RE: Proposal: Implicit Port Instantiation in SystemVerilog
From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Feb 25 2002 - 09:19:27 PST
>Date: Mon, 25 Feb 2002 08:06:41 -0800
>To: Peter Flake <flake@co-design.com>
>From: "Clifford E. Cummings" <cliffc@sunburst-design.com>
>Subject: RE: Proposal: Implicit Port Instantiation in SystemVerilog
>Cc: <fitz@co-design.com>, Friend_Anders
>
>Morning gents -
>
>Per Anders' recommendation on the last conference call, I suggest two
>styles of implicit port connections:
>
>(1) .* implicit port connections
>(2) .name port connections
>
>The second, and what Anders was suggesting, is instead of repeating names
>twice (D flip-flop instantiation example):
>
>dff d1 (.q(q), .d(d), .clk(clk), .rst_n(rst_n)); // Verilog-1995/2001
>
>dff d1 (.q, .d, .clk, .rst_n); // Anders' idea
>
>If a signal name mismatch occurs:
>
>dff d1 (.q(out1), .d, .clk, .rst_n); // q-output attached to out1
>
>To me, this is the cleanest way to show implicit connections without
>having to type the name twice.
>
>Arguments in favor of the .* style:
>
>Debugging the .* notation should not be a problem:
>The Verilog compiler already had to make the connections so the port names
>should exist in the data base.
>
>ASIC designers hate to do top-level designs because it is generally just a
>bunch of verbose connections.
>
>The .* notation removes all of the unnecessary verbosity and only lists
>ports where there are naming exceptions, size mismatches, and unconnected
>ports. It is much easier to scan a top-level module with 10's to 100's of
>instantiated modules and 1,000's of ports, knowing that everything is
>implicitly connected and just the exceptions are obvious and visible.
>
>If you are doing a simple block-level testbench, you are going to wire up
>the connections with the same names. The .* notation makes it easy to
>quick construct a block-level testbench.
>
>Intel's IHDL has used this style for years and Intel wants this capability
>(i.e. - there is a history of success using this connection style). We
>asked Intel a bunch of questions concerning debugging problems that they
>had had with this style. They claim the problems are almost non-existent.
>I believe it!
>
>Arguments in favor of the .name connections:
>
>For engineers like Anders who want to see all of the signals in the port
>list, this notation satisfies his requirement.
>
>The notation is a natural abbreviation style of existing Verilog coding
>(using the .name notation without having to repeat the signal name inside
>of parentheses)
>
>One important rule needs to be added: you cannot mix .* and .name ports in
>the same instantiation.
>
>You can mix .* and .name(signal) -OR- .name and .name(signal) connections
>in the same instantiation. The .name(signal) connections are required for
>size-mismatch, name-mismatch and unconnected ports.
>
>There is way too much emphasis and importance placed on declarations and
>port-name visibility. For most designers of very large ASICs, the
>top-level model is a painful and necessary evil to satisfy the
>requirements of a simulator. Please keep the .* notation!
>
>Regards - Cliff
>
>At 11:08 AM 2/23/02 +0000, Peter Flake wrote:
>>Hi Tom,
>>
>>If we want to support both kinds of feature, I suggest the following syntax:
>>
>>alu alu (.*(*), .zero(), .neg());
>>
>>alu alu (.*(alu_out,alu_in,acc,alu_op),.zero(),.neg());
>>
>>This has the benefit of needing more than just the dot (which might be
>>missed) to distinguish it from a concatenation.
>>
>>Peter.
>>
>>At 04:06 PM 2/22/02 -0500, Tom Fitzpatrick wrote:
>>>Hi Cliff,
>>>
>>>I read through your proposal, and I'd like to make a few comments, if I may.
>>>I'd like to get your reaction before discussing it in the committee.
>>>
>>>I agree that the '.*' notation saves a lot of typing and possibility for
>>>error in creating designs, but I think that this savings comes at an even
>>>greater cost of the loss of readability and debuggability. My initial
>>>reaction on seeing the example was "this is a lot less code," which is good.
>>>But on looking more at it, my stronger reaction was that I want to see the
>>>singnals connected to each module. Perhaps a compromise is best.
>>>
>>>The big knock against named port connections is that you have to type
>>>everything twice
>>>
>>>foo f(.clk(.clk)...);
>>>
>>>While the knock against positional port connections is that you can't tell
>>>what's connected to what
>>>
>>>module foo(input bit rst,clk...);
>>>...
>>>endmodule
>>>module top;
>>>foo f(clk,rst...); what if I swap the clk and rst signals?
>>>endmodule
>>>
>>>Seems to me that the best way to solve these problems and still maintain
>>>visibility into the connections is to list the ports of the sub-module by
>>>name in the instantiation, and allow non-matching signals to be connected
>>>explicitly.
>>>
>>>Here's a bit of your connect-by-name example:
>>>
>>>module calu2(
>>> inout [15:0] data;
>>> input ld_multop1,
>>> input clk, rst_n);
>>>
>>>wire [31:0] mult;
>>>wire [15:0] mop1;
>>>
>>>multop1 multop1 (.mop1(mop1), .data(data),
>>> .ld_multop1(ld_multop1),
>>> .clk(clk), .rst_n(rst_n));
>>>multiplier multiplier (.mult(mult), .mop1(mop1),
>>> .data(data));
>>>alu alu (.alu_out(alu_out),
>>> .zero(), .neg(), .alu_in(alu_in),
>>> .acc(acc), .alu_op(alu_op));
>>>...
>>>endmodule
>>>
>>>and here's the corresponding section of the implicit connection example:
>>>
>>>module calu2(
>>> inout [15:0] data;
>>> input ld_multop1,
>>> input clk, rst_n);
>>>
>>>wire [31:0] mult;
>>>wire [15:0] mop1;
>>>
>>>multop1 multop1 (.*);
>>>multiplier multiplier (.*);
>>>alu alu (.*, .zero(), .neg());
>>>...
>>>endmodule
>>>
>>>If there's a problem with the mop1 signal, which is an output of multop1, I
>>>have no way of tracing it, except maybe hoping that my debugger can tell me
>>>where it's coming from. An alternative might be something like this:
>>>
>>>multop1 multop1 (.{mop1,data,ld_multop1,clk,rst_n});
>>>multiplier multiplier (.{mult,mop1,data});
>>>alu alu (.{alu_out,alu_in,acc,alu_op},.zero(),.neg());
>>>
>>>Not sure if this is syntactically ok, but you get the idea.
>>>
>>>This does have the disadvantage that, if you change the port list of the
>>>sub-module, then you have to change the instantiation statement as well, but
>>>some (like Anders, judging from some of his comments so far) might see that
>>>as an advantage. If I change my multop1 module definition to add a port
>>>named 'mult', then my .* connection will automatically pick up the mult
>>>signal from the parent module, which may not be what I want. Of course, it
>>>may be what I want, but if it's not it's much harder to debug what happened.
>>>
>>>I was originally thinking that you might be able to use interfaces to
>>>simplify things a bit, but since there's very little overlap between the
>>>connections in this example, that won't really help much, so it's got to be
>>>some combination of port lists and wires. Worst case, I suppose we could add
>>>'.*' for those users who want to live on the edge, and something like '.{}'
>>>for those who are a little more conservative. If we only pick one, I'd
>>>prefer '.{}'.
>>>
>>>What do you think?
>>>Thanks,
>>>-Tom
>>>
>>> > -----Original Message-----
>>> > From: owner-vlog-pp@eda.org [mailto:owner-vlog-pp@eda.org]On Behalf Of
>>> > Clifford E. Cummings
>>> > Sent: Thursday, December 13, 2001 7:08 PM
>>> > To: vlog-pp@eda.org
>>> > Cc: Kris Konigsfeld - 503-712-2889; Matt Maidment
>>> > Subject: Proposal: Implicit Port Instantiation in SystemVerilog
>>> >
>>> >
>>> > Hi, All -
>>> >
>>> > Attached is a proposal for adding implicit port declarations to
>>> > SystemVerilog. This can serve as a starting point for our next discussion
>>> > on the topic. I have copied Kris Konigsfeld and Matt Maidment of Intel,
>>> > Oregon, in case they would like to comment on the proposal, since they
>>> > contributed significantly to the concept of this proposal.
>>> >
>>> > Apologies for the delay, it took a while to come up with and interesting
>>> > example and full explanation of the intended enhancement.
>>> >
>>> > Comments?
>>> >
>>> > Regards - Cliff
>>> >
//*****************************************************************//
// Cliff Cummings Phone: 503-641-8446 //
// Sunburst Design, Inc. FAX: 503-641-8486 //
// 14314 SW Allen Blvd. E-mail: cliffc@sunburst-design.com //
// PMB 501 Web: www.sunburst-design.com //
// Beaverton, OR 97005 //
// //
// Expert Verilog, Synthesis and Verification Training //
//*****************************************************************//
This archive was generated by hypermail 2b28 : Mon Feb 25 2002 - 09:20:12 PST