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

> Kevin,
>
> I'll respond to the main issue separately.
>
> A couple of quick notes:
> 1) ...
>
> 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.

I think you'll need to be clearer on what you are objecting too.

The AMS stuff is supposed to be incorporated at some point in the not-to-distant future, and it will have to be incorporated pretty much as-is for backward compatibility.

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

What is the "fundamental shift"? As far as I can tell there is no semantic difference, i.e. you could assume that collapsing is always required, it just happens that with the existing types the result is the same if you don't. AMS requires "collapsing" in order to work correctly, and there doesn't seem to be any plausible argument for doing anything else.

If you agreed with me viewpoint you would not be making port directions more authorative. Port directions are not useful in an AMS context, and I don't think we have any examples of their use with user-defined types.

Kev.

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

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