Re: [sv-bc] Assignment pattern lvals (mantis 623)

Brad,

I don't have any problem with lval assignment patterns
conceptually and I do appreciate the idea of a "better concat".
My concern, as an implementor, is that the rules as
currently stated don't deal with all of the situations
in which lvals can exist.  If that is clarified, I am fine.
Another possible solution for the port issue is to require that
assignment pattern expression lvals used as out or inout
completely map the elements of the type.  If there aren't
any "gaps" then the net collapsing issues become much easier
and the necessity for describing the mapping in a behavioral
manner using a "temp" goes away.

Oh - another thought - are assignment pattern lvals permitted
in the formal of a port association?  You are normally
allowed to do something like:
    module m (.A({a,b}))
Would assignment pattern expression lvals be permitted in
this situation as well?

The RHS to LHS type flow isn't really a port issue -- the
issues involved in complex port association formals really
raise the same issues.  My concern on this front is a deeper
concern that introducing a right to left type flow in the
context of an assignment could cause weird issues in overall
Verilog resolution.  Again - no precise example but just
a feeling based on my experience.  I'll get further input
on this locally which may resolve my discomfort.  I think
that we should try to resolve the other concerns (port
semantics, assignment as expression semantics) while I try
to figure out if I can come up with a real type issue.

Gord.


Brad Pierce wrote:

> Gord,
> 
> Thanks for the feedback.  There's a lot of good stuff there.
> Let's take your last point first.  You write --
> 
> 
>>we should require
>>typed assignment patterns in all lval contexts for
>>the current LRM.
> 
> 
> Below I offer a compromise on this, but first some background.
> 
> The proposed functionality, while new, doesn't seem all that problematic
> to me except perhaps for port connections.
> 
> Unfortunately, even if your suggested restriction were limited to
> port connections, that would make exactly the requested use model
> nonstandard.  A goal of assignment patterns as the left-hand side
> of an assignment-like context is to generalize the polymorphism
> of port connections.  Users ask, if I can use polymorphic assignment
> patterns to drive signals across a port, then why not also to receive
> signals across a port?
> 
> To users it's about symmetry.  It seems unnatural for concats to
> work on both sides, and then to add an apparently new-and-improved
> polymorphic concat that only works on one side.  But as you point out,
> concats have a self-determined type.
> 
> (A key point for below -- users are viewing these as a generalization
> of concat that does not discriminate against the unpacked.)
> 
> Correct me if I'm wrong, but I'm thinking that your main objection here
> is that the elaboration of a module would need to use a stack discipline
> and wait for the elaboration of its down designs, analogously to a function
> evaluation suspending while the function calls within it are evaluated.
> 
> I can understand that objection, and would be willing to severely
> restrict the form of (untyped) assignment patterns that can be used as
> the left-hand side of an assignment-like context.  For the (untyped)
> assignment pattern, what's needed in real practice is only the positional
> form, and, moreover, only those in which the lvalues in the assignment
> patterns have self-determined types of exactly the same width as the 
> corresponding fields on the right-hand side.
> 
> The effect is a LHS concat that doesn't discriminate against the unpacked.
> 
> I don't think this restriction on the form of left-hand side (untyped)
> assignment patterns is really needed outside of port connections, but
> for consistency I wouldn't be opposed to declaring the more elaborate
> untyped usages as also nonstandard on any kind of left-hand side.
> 
> -- Brad
> 
> p.s. All "assignment patterns" are untyped, i.e., polymorphic.  You can
> combine a type and an assignment pattern to form an "assignment pattern
> expression", which has that self-determined type.
> 
> 

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil,  Staff Engineer               503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com