RE: [sv-bc] Re: 1619 suggestions

Cliff,

I'll avoid mentioning defparams here so as not to provoke you.

My original thought was to respond like Tom did at the beginning, that
default behavior should not change. Afterwards, I thought that in
reality, default behaviors change frequently in non-trivial software,
and a Verilog model is software. Heck, even Verilog simulators change
their default behavior now and then and don't provide adequate
protection against it.

Some thoughts:

1. You have talked about using .* to avoid accidental unconnected ports
and accidental implicit net declarations. You have said that many people
do not use Lint tools and you want some protection within the language.
But look at the other side of the story. Many people do use Lint tools
to detect these and will continue to do so for several reasons. For
example, 
A. Lint tools detect many other problems. So since they will use Lint
tools anyway for the other problems, they will use them for these as
well.
B. Lint tools allow more flexibility. For example, some people want to
allow implicitly unconnected outputs. The Lint tool allows them to pick
and choose.
C. Lint tools allow you to check legacy code.
And many people will continue to connect all the ports explicitly, if
for no other reason than that there is not much name matching between
the formal and actual port names. Most of these probably won't add .*,
which will seem to them redundant.

All that was just an introduction to say that the same problem would
occur if one used simple named connections without any .*. If the
instantiated module is changed to include a new port with a default,
then the default will be used and there will not be an unconnected port.
That is the very essence of the default. This can happen with tasks and
functions, too. If the task/function is changed to add an additional
argument, with a default, the same thing happens. You'd maybe like to
add .* to task and function calls also. I would not object. 

2. The same thing can happen today also if the instantiated module is
changed to add a new parameter with a default that changes the behavior.
All the old module instantiations will not include the new parameter.
The same thing can also happen if the parameter already exists, but its
default value is changed. Then the behavior of all the instantiations
which do not override the parameter changes.

3. Maybe you would like instead a compiler directive or tool switch that
would not allow using .* with defaults. This could work two ways. One is
as you suggest, in the instantiated module with the defaults. The other
way is it could be defined in the instantiating module. Then each user
could decide for himself how he wants it.

4. I personally see the main benefit of .* as a way to make the code
much more compact and eliminate redundant information. I see what you
call the stronger checking as only a secondary side-effect. Defaults are
an additional way to make the code more compact. I see defaults and .*
as complementing each other. Thus, I don't see a big disadvantage in the
risk you see, because I don't see that eliminating that risk was a main
goal of .*. And as I wrote above, the risk would still occur with
regular named association. 

5. You wrote to Tom, "Understood and agreed. Although the new notation
is convenient, the old notation was not terrible. That was the intent of
this example." Your example had only 1 such port. I have seen examples
of blocks with dozens of ports that are connected to default values. The
classic case is an input which is not always used. If you don't need it,
you can then just leave it off the port connection list. With dozens of
such ports, the difference is tremendous.

And I didn't even mention defparams. But see below.

Regards,
Shalom
 

> >If I understand correctly, if an IP provider uses () in the default 
> >port declaration, this means that the default port semantics 
> WRT .* as 
> >defined by 1619 apply to this port. In other words, if there is no 
> >parent declaration for this signal, the instantiation will use the 
> >default.  If we do not use the (), then the semantics change which 
> >force the implicit .name semantics.  In other words if the 
> parent does 
> >not have the signal, then an error occurs.
> >
> >So, if an IP provider were to start using default port values and 
> >wanted to protect themselves from unconnected ports that 
> have default 
> >values, they would not use the () in order to force users to always 
> >have a matching name in the parent and the child.
> >
> >The distinction which becomes clear, then is whether or not 
> the signal 
> >exists in the parent and the child.  When an IP provider 
> uses () there 
> >does not have to be a match.  If they do not have the () then parent 
> >and child MUST match, even when using a default.
> 
> This is correct.
> 
> >Okay, that makes sense now. The bottom line is whether or 
> not we want 
> >to provide this enhancement.  This will complicate the 
> proposal and I 
> >am not convinced it provides a lot of benefit to it. I still 
> go back to 
> >my argument that IP providers need to be diligent and 
> understand what 
> >they are getting into.  If they really wanted to ensure that 
> their IP 
> >not be misused with default port connections then they shouldn't use 
> >them at all.
> 
> As long as IP providers and the general SystemVerilog RTL 
> designer population can be trusted to use the proposed 
> default-ports enhancement correctly, then my concern is 
> unfounded.  I do not believe IP and RTL designers will always 
> do the right thing; hence, my concern.
> 
> >But I don't see that this is something that can't be added 
> in a later 
> >version of the spec.  In fact, it shouldn't be too hard to add this 
> >enhancement later such that it is backwards compatible with the 
> >existing proposal.
> 
> Unfortunately, I do not think this is true. If default ports 
> are used and then later enhanced with () declarations, 
> previously working default ports could start to fail.
> 
> That having been said, I believe Gord understood what I was 
> talking about and is opposed to this modification both now 
> and in the future. 
> I am not even 100% convinced that my modification adequately 
> addresses my concern, but it does get me part way.
> 
> I say, go ahead and pass this. I will vote no so I can tell 
> those I teach that I thought this was a bad idea. When I tell 
> students that something is a bad idea, they pay closer 
> attention to the feature and will more likely use it correctly.

Like you know what?
---------------------------------------------------------------------
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.