[sv-ec] Apologies, 890 still not ready

Hello SV-EC,

My apologies but I didn't have enough time to finalize
890-5 for the meeting toay.  Some questions have come up,
though, which we can discuss.  The answers to these
will help me conclude 890-5 in the next couple days.

1. Cliff has shown that we need to allow procedural
   assignments to variables that are also driven by
   clocking outputs.  This is useful for initialization.
   This will require exempting clocking blocks from the
   strictures about multiple writers to variables from
   different processes (something I will put in 890).

   A question now arises about continuous assignments
   to variables that are also driven by clocking outputs.
   What should we do with those?  I believe this situation
   can come up in certain highly configurable designs
   involving SV interfaces.  Either we can declare this
   illegal, or introduce some new semantic such as the
   clocking output would deposit a new value on the
   variable until such time that the continuous assign
   changes value, and then that writer would update a
   new value onto the variable.  That would be weird.

2. What about Jonathan's proposal to eliminate the special
   synchronous drive resolution of 15.4.2?

3. If we don't eliminate that, what should happen when
   synchronous drive "conflicts" come up with non-integral
   types? (reals, class handles, dynamic arrays etc.)
   Section 15.4.2 seems written in such a way that only
   integral types are treated.  Going with Jonathan's
   proposal will eliminate this potentially thorny topic.

4. Generalizing on 3, what does it even mean to have
   clocking variables that are of dynamic types?
   The LRM only discusses and shows integral values.
   Should we introduce a rule that limits clocking
   variables to be of integral types?

Thanks and regards,
Doug 

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