Re: [sv-dc] Notes from SV-DC meeting on 2011-01-27

Kevin,

I'll respond to the main issue separately.

A couple of quick notes:
  1) at the previous meeting the main vendor reps were asked to see if
we could come
       up with a consensus proposal to help in making progress. I wrote
up an initial
       proposal and ended up in a longish discussion with Cadence reps.
Some of what
       they recommended I was Ok with; some I wasn't as I wanted some
additional
       flexibility on resolution function handling. I haven't had time
to rewrite my
       proposal to incorporate the changes I agreed with. The main
current disagreement
       is regarding resolution function binding; I'll send out a note on
that this evening yet.
       I won't be able to work on my proposal for at least a week due to
work
       commitments this coming week. So perhaps in 12-14 days I should
have
       out a modified version.

  2) I'm not prepared to tackle partially driven nets (using AMS style
syntax) at this
       point, and likely not in the PAR at all. I think that would need
to be much more
       carefully addressed as part of an 1800.1 standard (SV-AMS) or
if/when AMS
       is ever directly brought into 1800. It isn't strictly necessary
in the digital
       systems since the user-defined types can be used to encode the
meta-information
       about what is "active" in the driven value; ugly, but it should
work.

  3) I agree with your last point that resolution really does need to
be applied at the
       full (collapsed) net segment. The problem is that is a
fundamental shift in verilog
       in that it *requires* collapsing. In my proposal, I addressed
that by making the
       port directions more authoritative than in 1364/1800 and
(effectively) requiring
       collapsing for the new kinds of nets for bidirectional ports and
(more or less)
       for outputs. There will certainly need to be more discussion on
that aspect, but
       I agree with your fundamental concern there.

Gord.

On 1/28/2011 1:33 PM, Kevin Cameron wrote:
> On 01/27/2011 11:47 AM, Little Scott-B11206 wrote:
>> Hi all:
>>
>> Below are the notes from the meeting. Please let me know if there are corrections. I have included the verbose style of notes that we have typically taken as well as a shorter summary. I think it makes sense to have a less verbose set of notes. In the future I will only produce the shorter summary style. If someone has a problem with that please let me know, and we can possibly make some arrangements.
>>
>> Thanks,
>> Scott
>>
>> ----------
> ...
>> 4. Discussion of user-defined nets and resolution functions
>>
>> GV gave a brief summary of progress. He wrote up more LRMish proposal based on his proposal that has been sent to the reflector previously. He shared this proposal with the subgroup who was sent off to develop a proposal. SSh raised some different ideas. One of the primary differences right now is the association of resolution functions with a net.
> Where is the current proposal?
>
>> Originally GV proposed to associate a resolution function with each net declaration. SSh introduced the idea of a nettype. When a nettype is declared it defines the data type and resolution function for the net. The nettype can be used in the declaration of new nets. GV would likes the idea of a nettype and would support this although he wants the option for later association. One way to do this is not allow nettypes without an associated resolution function. Somewhere in the design a resolution function would have to be assigned to the nettype, but it wouldn't be required for compilation. In this way an IP can be compiled without an assigned resolution function. If the user chooses to change resolution functions the IP will not have to be recompiled. SSh stated that he is approaching this from a language consistency point of view. Right now in the SV language the use of typedefs and binds cause many headaches. He isn't keen on introducing the late binding featur
> e

>> unless it is truly needed because it may add complexity similar to typedefs and bind. He would have to defer to AK on the need and use cases for late binding.
>>
> Might I suggest that it would be a good exercise to determine how one would define the existing SV/Verilog type semantics as a user-defined type rather than he loosely defined built-in types? I.e. if you can express how the current stuff works (cleanly) in user-level terms it should be more obvious how to do the extensions.
>
>> Partial assignment to an atomic net is not expected to be legal in the beginning. The use cases for partial assignments can be approximated using additional bits in the net. For instance, you could have a voltage real and a current real in a nettype along with a bit for each to determine if the value was valid. A net only carrying voltage information would only set the voltage and voltage present bit. The current value could be anything and the current present bit would be zero. AB mentioned a use case for a monitor to signal the circuit to make a measurement. This would be tricky with events, but SSh pointed out that this can also be done with additional state to represent when a measurement is required.
> If you want to do simple voltage and current just use the Verilog-AMS syntax/semantics, otherwise we'll end up with a real mess later.
>
>> There was also discussion about how port collapsing is done in the presence of these nettypes. This is an issue that will need to be discussed more in the future.
>>
>> GV requested user opinions and feedback on whether late binding of resolution functions is desired.
> All resolution should be done flat - i.e. ports are about connecting wire segments together to create a single node in the simulator, resolution is performed across all the drivers of the node. Doing anything else will usually give the wrong results. The only exception is if the wire represents some non-physical/abstract type.
>
> Kev.
>
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.