RE: [sv-bc] Re: 1619 suggestions

Hi Stu, Cliff,

I really appreciate your suggestions and I am inclined to evolve the
proposal to meet these enhancements.  What I really see being asked now
are two things.  First, from Cliff, a mechanism such that default ports
in conjunction with .* are not implicitly used if the parent does not
have the signal.  Second, from Stu, a proposal that allows users a
mechanism to explicitly use default port values when the parent does not
have said signal(s).  I see that Stu's proposal was intended to answer
Cliff's issue, but I think what you are really driving at Stu, is simply
a mechanism to allow the /end user/ a way to turn on default ports when
the connection does not exist.  Cliff proposal was more along the lines
of embedding this in the definition, i.e. giving the control of this
same mechanism to the IP vendor.

I personally lean strongly towards giving this control to the vendor,
simply because it allows them to make backward compatibility changes to
their IP such that new interfaces can use default ports and work with
their older IP.  In other words, end users can choose to hook up to the
new interface or not and if not, they get the default ports which by all
intensive purposes matches old behavior. 

Also giving control to the vendor means the end users don't have to add
all the additional (default) ports to make it work.  It also, as you
state Stu makes it so they don't have to wade through compilation errors
with new code.  That said, though if we went with something more like
what Cliff wants, we allow the vendors to put in the "compile fail"
behavior for new default ports.  If the vendors want to protect their
code, they wouldn't put in the empty brackets, as per Cliff's
suggestion.  This forces the semantics of default ports not being used.
Which reminds me to follow up on this note below. 

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

I want to be clear about what you have suggested because you confirmed
what I understood.  Taking my last sentence one step further, the
implication is that if vendors do not use () it means that default port
values have become useless for .* and end users using .* will have to
upgrade their code to use the new ports and then tie them off. Otherwise
the compile fails because the parent does not have the signals in it.
This just makes me wonder why we would even offer this. I see the
protection you are offering to end users of .* , but the cost seems too
high to everyone who doesn't use this or who uses it and "behaves".

This puts me on my soap box about punishing good users, which are
typically the vast majority of end users. 

The bottom line that I wanted to get to was to still drive towards a
solution that Cliff wants, I just agree with Shalom on the time issue.
Can we just take the proposal as is for now and even over the next year
work on this enhancement?  Matt tells me that even though we finish on
December 15th, there is still a year of ratification process before this
becomes IEEE standard and much of that work is the champions pushing
back on the committees to get things "cleaner". 

I also do believe we can add this enhancement later in the spec by doing
just the opposite of what Cliff has suggested.  Instead of using
something like () to allow default values with no connection, we can
make it so that () forces the connection, in which case vendors using ()
with a default port value will protect themselves against .* users.

Thanks, -Tom


>-----Original Message-----
>From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On
>Behalf Of Bresticker, Shalom
>Sent: Thursday, December 06, 2007 2:43 AM
>To: stuart@sutherland-hdl.com; sv-bc@server.eda.org
>Subject: RE: [sv-bc] Re: 1619 suggestions
>
>Stu,
>
>The disadvantage of this is that it largely neutralizes the main
benefit
>of defaults, which is to avoid having to list their connections, though
>it does retain the advantage that at least you do not have to know what
>the default value is.
>
>However, I do agree it would be nice in addition to allow explicitly
>connecting a default in this way. I still think the user should be able
>to choose whether or not he wants to allow .* to infer default
>connections. I also agree it should be an error in the cases you
>mentioned. Because time is running out, I would not like to hold up
1619
>for this, though.
>
>Regards,
>Shalom
>
>
>> 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.
>---------------------------------------------------------------------
>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.

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