SV-DC notes for 2010-07-14

Hi Folks:

Below are Scott Little's notes from our last SV-DC meeting.

Best regards,

John Havlicek

----------------------------------------
2010-07-14
SV-DC meeting notes
 
Attendees:
1 Jim Lear (Cirrus)
1 Achim Bauer (EXL-Modeling)
1 John Havlicek (Freescale)
1 Scott Little (Freescale)
1 Scott Cranston (Cadence)
- Sundaram Sangameswaran (TI)
1 Gord Vreugdenhil (Mentor)
- Top Lertpanyavit (Intel)
1 Dana Fisman (Synopsys)
1 Ghassan Khoory (Synopsys)
- Ian Wilson (BDA)
- Ken Bakalar (Mentor)
- Kevin Cameron (obs)
1 Arturo Salz (Synopsys)
- Dave Cronauer (Synopsys)
- Ed Cerny (Synopsys)
1 Tapan Halder (Synopsys)
- Jonathan David (obs)
- Jim Holmes (Lynguent)
- Walter Hartong (Cadence)
1 Shekar Chetput (Cadence)

SUMMARY:

-Strawman ideas for SV-DC document from Synopsys was discussed. The
primary concern is the lack of user defined connect modules makes it
very difficult to model some common types of electrical systems (see Jim
Lear's recent e-mail on the subject).

DETAILS:

JH: Resetting the attendance because the P1800 PAR was accepted. I
don't have further information about how the acceptance of the PAR will
be affect the way we do business.

GV moved on patent policy as read.
AS second
0 opposed, 0 abstain

Have been talking about use cases. Suggested that folks combine that
considerations with outlines of features and or capabilities with a view
toward finding a feasible set to work on in this PAR together with a
longer term vision toward that capability. I expect that we will spend
a number of meetings on that and then converge on something that can be
used in a roadmap. Synopsys sent out a document that we can discuss
today.

AB: What about my document? I don't want to forget the ideas and get
too many things swirling around.

JH: My hope for convergence was to hear all ideas and then converge on a
set that seems reasonable. How about we hear SNPS first and then finish
up with your document.

AS: Goal is to normalize floating point values with the integral part of
the language. In particular, digital can be declared as 2 state/4 state
and declare wires and have resolution.

-Builtin resolution functions and types to follow the current design of
Verilog. Advantage is performance and portability. Introduce at least
two types: voltage and current. Have different optimization functions.
Both would be of type wire and could be connected on ports.

-We need new types to support X and Z. Z certainly applies to voltage.
Not exactly sure how it works for current. Don't want to extend current
2-state real due to compatibility issues. Add a new 4-state variable
type. This is consistent with current digital world.

-These new types must allow in, out, and inout.

-Enable new analog types to connect to real type. Need to have the
rules to do these conversions. There is a potential loss of information
when converting from 4-state to 2-state. We need to define this
conversion. Also, need to define the mathematical operators for X and Z
just like digital.

-Allow user defined types using the newly introduced 4 state real types.

GV: One thing to be aware of there is that the rules in SV for aggregate
types is that each atomic piece of information is resolved
independently. If you follow those rules in a struct then those values
are resolved independently without knowledge of the other pieces. Each
item is atomic.

AS: This allows for basic connection, but not other operations.

TH: Only the resolved types will be resolved.

GV: What about unresolved types like real? Currently you can't mix
unresolved types with resolved types in a port.

JL: My first thought was actual complex or polar types and having
separately resolved types wouldn't work for this.

AS: Right, this idea doesn't allow you to resolved the aggregate type as
a whole. This is just an extension of what the digital does.

-The builtin types allow the compiler to distinguish what the real value
is.

-The ability to support $table model.

-There needs to be some predefined initial values. Real is currently
initialized to 0, but we need to think about proper values for voltage
and current.

-You can now use voltage and current in real expressions. These
operators have pessimistic operations so any X results in a final result
of X. $bitstoreal and $realtobits can be updated as well.

-Also, we need to port the relational operators. === doesn't currently
exist for reals. In this world all the bits are X or not. I don't
think we need to split this out.

-Not doing bitwise operations on a floating point number.

-Connections to different types of wires aren't allowed.

AB: Does this mean when you switch flows then you have to manually
attach and elaborate this connection?

AS: Yes.

JL: Or change the types on the port.

AB: Can we make this automatic?

AS: We can think about it. I think that would be useful, but you need
to think about how to do the definition.

AB: More complex data types could contain all of the information needed
to do the resolution. Strong abstractions make the resolution harder.

GV: Another thing I have heard is that one common problem is pin
connection problems where they connect things improperly. For instance,
incorrectly connecting voltage domains. If there is only one voltage
type then the elaborator and connection semantics won't be able to help
catch these types of errors.

AB: This type of example is covered in my document.

JL: This looks like a way of modeling digital signals and
interconnecting them into the real domain. Instead of a conversion
between logic and electrical you end up with a connection between logic
and real. I can see this being useful in a multiple power domain
situation. I don't see it going very deep into the analog type of
environment.

JL: I am thinking that we have many analog circuits that I am not sure
how I would model and external resistor.

AB: In complex projects it is hard to get a clean partition between
digital and analog.

JL: I echo that, but what I like is the discussion about the conversion
between logical and these real types. Mapping voltages into the 4-state
logic is very interesting.

AB: Can you attach drive strength?

JL: Let me give you an example. I have done a 4 state real type. I
reserved to real values that are highly unlikely to encounter.

AB: It is an abstraction because you can't handle a continuous drive
strength.

JL: This is limited to modeling digital style things. In this type of
proposal you have perfect voltage and current sources. You can't model
impedances.

AS: You can't do it at the ports. That is correct.

JL: You should read the article I wrote for and sent to the reflector or
Achim's proposal.

JH: Why can't this be done with what is proposed?

JL: You can't maintain the topology. Say we have a bandgap and an
external resistor. You have a port with a real port and a resistor that
is also a module. How does the resistor transmit back how much current
it is drawing?

GV: I have heard similar arguments from users. One important item is to
be able to do a pretty direct mapping between the analog netlist and the
digital modeling.

GV: I am with Arturo in the fact that user defined resolution functions
will cost us from a performance perspective. I do have a hard time
seeing how we can accomplish the user requirements without them though.

SL: There are users that care very much about the performance. I would
like to see high performance resolution functions available.

GV: The time at which predefined resolution functions get called is
arbitrary and up to the simulator in Verilog. In VHDL this is very
carefully defined. With user defined resolution functions you have to
be careful about when they will be called.

AS: There is not currently user defined resolution functions and if we
introduce them for analog then why not for digital? I am not opposed to
having additional information like maybe a discipline added so that this
can be used.

JL: I can appreciate the reluctance of adding user defined resolution.
It is a big change.

JH: We need to think about phasing and how much work. Do those who want
user defined resolution functions not want predefined resolution
functions? Can we make both work?

AB: I think that if we try to enumerate the options we will lose a fair
bit of momentum.

GV: I think we can do it this way...we should present how we would like
to do it in the long term and then present a shorter term construction
that is compatible with the long term.

AB: I think we should try to start with something strong and work hard
to get it implemented. It is very simple I just want complex data types
and resolution functions.

JH: The concern isn't about the size of the proposal. The concern is
about the thousands of pages of material already there and how this work
fits in with those.

JL: there is a risk that users will hit a wall. I do want to say that
the strawman is satisfactory for one set of use cases, but I don' think
it is satisfactory overall.

ShC: Many of these capabilities are already present in wreal. How does
that play together here?

AS: Wreal doesn't provide the value for 4 state.

SC: The latest proposal does.

JL: Wreal doesn't provide the necessary features. I think it is a
mistake to follow that path.

ShC: Wreal is just a keyword for reals to be treated like signals.

JL: Wreal I consider to limited to do electrical signals like
resistances and impedances. We might consider how to extend wreal to
account for our needs. What is the next step in extending there?

AB: The next step is aggregates.

ShC: We could expand wreal and maybe create it as another wire type.

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