[sv-dc] notes from SV-DC meeting on 2010-12-01

Here are Shekar's notes from yesterday's meeting.

2010-12-01
----------------

SV-DC Meeting Notes

Attendees:

v 111--111111 Jim Lear (Cirrus)
v 111-11-1111 Achim Bauer (EXL-Modeling)
v -111111111- John Havlicek (Co-Chair, Freescale)
v 11111111111 Scott Little (Chair, Freescale)
n ------1111- Scott Cranston (Cadence)
v 1-1111111-1 Sundaram Sangameswaran (TI)
v 1111111-111 Gord Vreugdenhil (Mentor)
v --1111-11-- Top Lertpanyavit (Intel)
n ---------1- Dana Fisman (Synopsys)
n -11--1-1-1- Ghassan Khoory (Synopsys)
v -11111-1--- Ian Wilson (BDA)
n ----------- Ken Bakalar (Mentor)
v -1111-111-- Kevin Cameron (obs)
v 111-11-1111 Arturo Salz (Synopsys)
n -1--------- Dave Cronauer (Synopsys)
n ----------- Ed Cerny (Synopsys)
n -----1--11- Tapan Halder (Synopsys)
n ----------- Jonathan David (obs)
n ----------- Jim Holmes (Lynguent)
n ----------- Walter Hartong (Cadence)
v 1111-111111 Shekar Chetput (Cadence)
v 11111111--1 Martin O'Leary (Cadence)
n -----1----- Francoise Martinolle (Cadence)
n -1--1------ Prabal Bhattacharya (Cadence)

* IEEE patent policy
  - GV: Move, AS: second

SL: Dec 15 - will try to meet on 15 and cancel on Dec 29. Review again
at the end of this meeting.

SL: We had discussed earlier on whether with start with requirement #1
or look at the general problem. Group decided to work on a general
problem first and then focus on real value net type.

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.