RE: [sv-bc] Re: 1619 suggestions

Hi, Shalom -

Thanks for the thoughtful feedback.

I had considered your option #3 below and it might be a good 
compromise. That way, I could generally turn off the default port 
values and then enable them independently after scrutiny of new 
models with default port values. I don't know if the vendors will go for this.

Regarding lint tools, I know they are useful and valuable but I find 
that they are not that commonly used. Reasons: cost & setup. Even 
those who use them tend to do so sporadically. I am not arguing 
against linting tools, just that we don't pass everything to the linting tools.

Oh, and I do rip on defparams in training classes to make sure that 
if they are used, they are not abused :-)

Regards - Cliff

At 01:04 AM 12/4/2007, Bresticker, Shalom wrote:
>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.

----------------------------------------------------
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


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