Re: [sv-dc] notes from SV-DC meeting on 2010-12-01 - Kev's feedback

[thanks Shekar, good notes]

IMO the existing logic type is both "primitive" and "atomic", so I would say there's no reason to add "primitive" as a keyword for anything, it's the existing behavior. If a keyword is to be added I would vote for "abstract" indicating that the type in question does not have a physical representation - and maybe that it follows VHDL signal/resolution semantics. Wreal is also primitive and atomic.

On resolution functions: it's not necessary that the return type from a resolution function be the same as the input type(s), e.g. zero or more bool (0/1) drivers resolve into the 4-state type (Z,0,1,X), because the resolution function requires a greater output range than the inputs. It should be possible to define multiple resolution functions with different return types, for handling cases where there are mixed types of drivers on a net - the key thing is knowing whether the conversions are lossy or not.

Kev.

On 12/02/2010 02:00 PM, Little Scott-B11206 wrote:
> Here are Shekar's notes from yesterday's meeting.
>
> 2010-12-01
> ----------------
>
> SV-DC Meeting Notes
>
> ...
>
> JL: Requirements 5 through 8 - request summary on Arturo's writeup and
> Gord's writeup.
>
> GV: We are approaching it with different biases - based on discussions
> we have add. Briefly characterize Arturo's core direction as - 4-state
> real value, nets of 4 state real with resolutions - symmetrical to
> logic/bit in SV. My general approach is to address composite nets and
> resolution functions.
>
> AS: To add to that - distinction is: any type of non-real value can turn
> it into wire. We cannot do that with reals. We normalize the oddity of
> real. It will enable simple things.
>
> SC: We can also reference the wreal presentation as a background along
> with those two proposals. wreal allows for 4-state and we should look at
> improving it to be SV compliant instead of reinventing the wheel. It
> allows for built-in and user-defined resolution functions - again, needs
> to be improved in the context of SV-DC.
>
> SL: It can be 4 state or 2 state. Work on the general case first and
> derive it further for special type.
>
> AB: Thinking of both bidirectional and unidirectional elements. Should
> we go with bidirectional?
>
> JL: Requirement 5 is not about direction, Requirement 7 goes into it.
>
> SL: We'll start with 5 and work our way to 7 which goes into the
> direction aspect.
>
> GV: Requirement 5 needs a new type of object. My proposal refers to it
> as primitive.
>
> AS: Atomic may be a better word.
>
> GV: Fine with any word - primitive/atomic.
>
> AS: What is the meaning of atomic?
>
> GV: Represents one connection point in the design.
>
> JL: Concern - Will there be ways to say array of primitives?
>
> GV: VHDL allows subelement level resolution functions instead of one for
> a composite. But, suggest we take a simpler model for first PAR for
> composite type.
>
> JL: Can we get a consolidated version of Gord's and Arturo's proposal?
>
> GV: Can redo some parts to bring more focus - can work with Arturo and
> try to bring something for Jan 12 meeting. i.e., update proposal to
> focus on req 5, 7 and 8.
>
> AS: Some concerns about the scope. Let's take an example: real-value
> driver is a sine function - some feature in language allows user to say
> when it crosses a certain threshold. Will this be possible?
>
> GV: Goal is to start with reasonably restrictive core model and figure
> out what we want to add to it over time.
>
> SC: Arturo's proposal focuses on built-in 4 state type while Gord's
> proposal is on composite/atomic type and user defined resolution
> functions. I'd like to see how wreal would be migrated into SV semantics
> i.e., separate data type from data object. Can we have subcommittee
> where the three of us can work together on it?
>
> AB: Another concern - what is the scope of the resolution function?
> Focus on inputs/outputs or factor in loading of nets through the
> hierarchy - say due to probing?
>
> GV: Not clear what the user would like to do - for example: what are the
> semantics of a force across a resolution function?
>
> AB: Let's take an example - Mixed signal system is going into low power
> state. Load changes from 1kOhm to 100kOhm driving strength. User
> definitely needs to model a driving strength in this case. Of course, in
> some other cases, user may not care.
>
> GL: In general, we need to approach the semantics of resolution area
> carefully.
>
> JL: VHDL resolution function is continuous - does not depend on timing.
>
> AB: VHDL resolution function is weak. For multiple driver resolution, do
> we attach driving strength attributes to the different drivers? There is
> no easy way to cope with delays.
>
> JL: Resistive driver and capacitive load driver could be modeled in the
> user defined struct. Doesn't have to be part of the resolution function.
>
> AS: Note that it works only with unidirectional, bidirectional nets will
> introduce race condition.
>
> AB: Are resolution functions hierarchical or will they stop at the port?
>
> GV: Again, need to be careful about how the resolution function
> semantics are formed. It needs further discussion - unidirectional vs
> bidirectional.
>
> JL: My 2c.. unidirectional resolution function should go away. Do we
> want to eliminate it?
>
> AS: Not eliminate it but keep its semantics clear.
>
> SC: In general, Verilog ignores direction for driver resolution while
> VHDL is more strict. Given that, how are we approaching driver
> resolution for reals with SV?
>
> GV: Verilog semantics for driver resolution are loosely defined such
> that vendors can have substantially different implementations and still
> have no effect on results. For LRM defined resolution functions -
> doesn't matter whether they are applied at the top or applied
> hierarchically. Direction is irrelevant for net ports but variable ports
> use them.
>
> JL: In summary, do we have a consensus?
>
> GV: No, we'll have to figure out what everyone can live with. For
> example: wreal - donated 4-state resolution function - can have
> different results depending on what way the resolutions are done.
>
> SC: Again, SV already has a way to apply resolution functions for wire
> data object. Are we thinking about doing something different for real
> type?
>
> GV: The current semantics in SV for built-in resolution functions allow
> vendors to do different implementations and still get the same result.
> With user-defined resolution functions, some of these implementation
> differences will give different results. Need to be careful to specify
> clear semantics.
>
> JL: I'm reading 4.3 in Gord's proposal. Visualizing a flattened system -
> all drivers on a net have one resolution function and the function is
> automatic.
>
> AS: Yes, functions should be automatic.
>
> GV: Can't mess with existing SV semantics like name visibility,
> automatic vs static, etc. Got a net, got a resolution function - what
> does it mean to apply a resolution function throughout the hierarchy?
>
> AS: Understand that the goal is to keep SV semantics as it is. If we
> don't touch the aspect of drivers/loads, it is not going to meet user
> needs.
>
> GV: In the AMS world, would such a definition be accepted globally or
> locally? The hard question must be resolved. Inhaling Verilog-AMS into
> SV is nontrivial.
>
> JL: Isn't it straightforward to have a user defined type with X, Z and
> create user defined resolution functions and overload bit wise
> operators, etc? How will built-in 4 state real types fit into this?
>
> AS: You could create a whole package like that. But, users would like
> those to be implicit. Otherwise, it is systemic issue - other tools in
> the flow will not recognize it. For example: waveform viewer will show
> the raw value - not the encoded one. We are looking at a built-in
> 4-state real type - not necessarily limit it to a wire.
>
> GV: Folks have been asking for user defined functions and operator
> overloading in SV. It is not available yet. Need a consistent type
> calculus to make it work. Expression type resolution rules in Verilog
> are already complex to understand - adding overloading to them is a
> no-no.
>
> AB: I always imagined resolution functions can handle different
> datatypes. e.g., if contributor of wreal type, look for X flag to pass
> on, etc. Isn't that possible?
>
> JL: If you have a user defined type, how could you do operators that
> will work with logic values also?
>
> AB: I like the idea of implicit conversion - automatic conversion from
> logic to electrical using a connect module. Eliminates complexity for
> the user.
>
> JL: My preference would be to avoid creation of a new data type for
> 4-state real. Existing data types and objects are already complex.
>
> GV: I could write an example with user-defined 4-state real state and
> expect folks will say no-no to it once they take a look. So, we should
> be open to a built-in type.
>
> SC: How about a subcommittee to work on specifics by Jan 12 meeting?
>
> MOL: Makes sense for vendors to hash out in a subcommittee.
>
> AS: Agrees
>
> JL: Agrees.
>
> GV: Agrees, Email works best.
>
> SC: Email sounds good.
>
> GV: Who to work with from Cadence?
>
> MOL: Shekar and cc Martin.
>
> SL: Ok, subcommittee can work offline and bring a draft for Jan 12
> meeting.
>
> Happy Holidays everyone!
>
>
>

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