Re: [sv-bc] Issue 548: .* and implicit nets

Hi, Jonathan -

Comments below.

At 09:30 AM 4/6/2005, Jonathan Bradford;Freiburg wrote:
>Hello Adam
>
>That would be rather dangerous.

Not really. Engineers today are writing Perl scripts to make all the named 
connections automatically to bypass the tedium of assembling top-level 
designs so they are already mis-connecting ports with like names.

So far my usage of .* has shown that vendors could help engineers find 
unintended connections if they would offer the following compile warnings:
(1) report nets and buses that have only one connection
(2) report nets and buses that have only drivers or only receivers connected
(3) give me a switch to report all nets or buses that have more than two 
connections (so I can look at the list to see if anything looks out of place)

The new logic data type helps with most of this, but the extra warnings 
would indeed be useful.

Having said all this, I should note that my top-level .* designs go 
together so fast that finding the few mis-connections that I have made so 
far have really been very easy to find and correct. Easier than when I 
assembled10 pages of verbose top-level named port connections.

>Furthermore in general this will not work for connection between modules, 
>even if the nets existed,
>since in general there are often naming schemes on the port names, so in 
>module A you have a port data_out
>and in module B you have a port data_in. The .* notation will not handle 
>such intermodule connections
>as even for explicit nets there can be nothing that matches both ends of 
>the connection.

It is true that many companies use these types of naming conventions (some 
have already requested some degree of regular expression enhancement to 
address these issues - but we have not added it, at least at this time) but 
.* may cause a number of companies to re-think the naming strategies to 
take advantage of the stronger port-checking and concise coding style 
offered by .*

>This problem is more obvious in a datapath application, i.e. a chain of 
>several modules handling red/green/blue
>data for graphics, compared to a processor application with 
>address/data/control. Since in the former case we are talking
>about different but similar connection types whereas the latter case the 
>connections are common to all modules.
>i.e. point to point vs star/broadcast.
>
>The .* connection is intended more for instantiating a DUT/DUV module in a 
>testshell.

Not entirely correct. I proposed .* to reduce the tedious nature of 
assembling the modules in top-level ASIC and FPGA designs where 1,000's of 
ports consume pages of code for the sole purpose of connecting everything 
up at the top-level. The sea of names was both tedious and error-prone.

The DUT/DUV block-level testbench connection was just a nice side-effect 
(and I do like it!)

>To handle the scenarios I describe for inter module connections, 
>constructs similar to regular expressions would
>be required - as a future enhancement someday.

Yep! But like I said, until (or if) we get the regular expressive 
capabilities, we may find engineers re-thinking the naming conventions. To 
be seen.

>Not implict nets. Note so far only scalar nets were ever implicit in 
>Verilog - but only if explicitly connected, not for .*.

I have already had many engineers tell me that they would like the implicit 
connections, scalar and vectored, without wire or wire-vector declarations.

I tell these engineers that it took enough effort to get agreement to .* to 
begin with and that my experience in using it so far has shown that the 
wire-vector and wire declarations can typically be handled with just a few 
lines of code, because many of the desired connection points have already 
been declared as module ports (just my experience so far).

The implicit connections may come as a future enhancement, but for now, 
even with the few extra declarations, the .* capabilities are great.

The one requirement that may be annoying is putting declared nets and buses 
into a package and trying to import the package with import 
package_name::*;     .* implicit ports can't see the ::* nets, so if nets 
are included in packages, engineers will either be required to explicitly 
import the package nets to use .* or mix .name (for the package-declared 
nets) with .*

This latter capability was not legal until just this week, and it was added 
to cover the package declaration import::* problem.

>Regards
>
>    Jonathan Bradford

Regards - Cliff

>Adam Krolnik wrote:
>
>>Hi Steven;
>>
>> > that .* will not implicitly declare nets.
>>
>>It is unfortunate that nets have to be declared for .* to have its 
>>desired effect.
>>I would be nice to be able to add ports between two modules and have them 
>>become
>>connected without having to modify the parent module that instantiates them.
>>
>>Maybe a future enhancement someday.
>
>--
>
>Jonathan Bradford
>CAD Engineer
>Phone +49 (0)761 517 2884
>Fax   +49 (0)761 517 2880
>mailto:jonathan.bradford@micronas.com
>
>MICRONAS GmbH
>Hans-Bunte-Str.19
>D-79108 Freiburg
>Germany
>http://www.micronas.com

----------------------------------------------------
Cliff Cummings - Sunburst Design, Inc.
14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
Phone: 503-641-8446 / FAX: 503-641-8486
cliffc@sunburst-design.com / www.sunburst-design.com
Expert Verilog, SystemVerilog, Synthesis and Verification Training