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

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