RE: [sv-bc] Re: 1619 suggestions

I appreciate Cliff sharing his concerns and examples.  I've pondered both
sides of the discussion for a couple of days, and have come to the
conclusion that I do not share Cliff's concerns.  I do not think having
default input values will be an issue for end users, even for those using
.*.

I have a suggestion for a compromise, however.  Let me state up front
though, that I am throwing this idea out without giving it much thought, so
it may be so full of holes that it will sink immediately.  

The compromise is to not have .* automatically infer an unconnected input
port connection when the port has a default.  Instead, when .* is used
require that the user specifically state that they want to use the default
port using .<input_port_name>(default) .

The advantage of having to explicitly state when the default input value
should be used is that .* retains all of the checking that Cliff is
concerned about.  The disadvantage is that if the end-user of an IP model is
using .* inferred connections and the IP vendor adds a new input port with a
default value, existing end-user that are using .* to connect to the IP
model will suddenly fail to compile.  That defeats the idea of being able to
add an input port without breaking existing designs, but only for .*.  Any
other style of connecting to the IP model will automatically use the new
input port's default value.  Note that .* -- and only .* -- would also break
if the IP vendor added a new output port and there was no matching signal at
the netlist level.

Sadly, since .name inferred connections will already infer unconnected
ports, I do not think it makes sense to require .name to explicitly say when
to use a default input value.  However, I think .name and fully named port
connections should be allowed to also specify .<input_port_name>(default) .

There also needs to be a rule for what if .<input_port_name>(default) is
specified and the port does not have a default value, or the port is not an
input port.  I suggest it be an error.

Just an idea...

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Clifford E. Cummings
> Sent: Wednesday, December 05, 2007 6:06 PM
> To: sv-bc@server.eda.org
> Subject: 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.
> 
> 


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