SystemVerilog Discrete Real Modeling Committee: [sv-dc] Notes fr

From: Little Scott-B11206 <B11206@freescale.com>
Date: Thu Jan 27 2011 - 11:47:37 PST

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

-------------------
---SUMMARY NOTES---
-------------------
2010-01-25
----------
SV-DC Meeting Notes

Attendees:
v 1111--11111 Jim Lear (Cirrus)
v 1111-11-111 Achim Bauer (EXL-Modeling)
v --111111111 John Havlicek (Co-Chair, Freescale)
v 11111111111 Scott Little (Chair, Freescale)
n -------1111 Scott Cranston (Cadence)
v 11-1111111- Sundaram Sangameswaran (TI)
v 11111111-11 Gord Vreugdenhil (Mentor)
n ---1111-11- Top Lertpanyavit (Intel)
n ----------1 Dana Fisman (Synopsys)
v 1-11--1-1-1 Ghassan Khoory (Synopsys)
v 1-11111-1-- Ian Wilson (BDA)
n ---------- Ken Bakalar (Mentor)
v --1111-111- Kevin Cameron (obs)
v 1111-11-111 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 11111-11111 Shekar Chetput (Cadence)
v -11111111-- Martin O'Leary (Cadence)
n 1-----1---- Francoise Martinolle (Cadence)
n --1--1----- Prabal Bhattacharya (Cadence)
n 1.......... Abhi Kolpekwar (Cadence)
n 1.......... Steven Sharp
|-> attendance on 2010-01-26
|---> voting eligibility on 2010-01-26

0. IEEE patent policy (http://standards.ieee.org/board/pat/pat-slideset.ppt)
AK was a new attendee not familiar with the IEEE patent policy. SL read the IEEE patent policy slides.

1. Status of IEEE participation rules
SL summarized the e-mail from Neil K. below.

"There was a P1800 Working Group meeting this morning. One of the topics
discussed was the new IEEE participation policy. We have been anticipating
the arrival of a FAQ which will help clarify implementation of this new IEEE
policy.

This FAQ has not arrived and there is now some speculation that this new
IEEE policy may not become enforceable for several more months.

In light of this situation, the Working Group and all of its associated
Technical Committees will operate as we did before. We will continue to operate
this way until the arrival of the FAQ. Everyone is welcome to participate."

AB raised some questions regarding the IEEE-SA membership. GV stated that under currently proposed rules only advanced IEEE-SA members would be allowed to participate in the committee work. Information on the IEEE-SA members and membership can be found at http://standards.ieee.org/develop/corpchan/mbrs1.html.

SL stated that our hope is that we will continue with the current rules at least through the end of this PAR. This is not guaranteed, but we are hoping it will stay that way. We can adjust if necessary, but I plan on proceeding with that hope in mind.

2. TC cutoff date reminder

SL summarized the e-mail from Neil K. below.

"Do be aware that the cutoff for the work in the Technical Committees is the
end of September (technically it is Oct 1st). Make sure that you are pacing
yourselves such that there will be time to complete your work on time."

SL: In light of the deadlines I would like to set some dates for the completion of our current work item. I propose Feb. 23 (at the start of the SV-DC meeting) as the deadline for proposals to be sent to reflector. I want to define proposal as a largely complete document of the form P1800 expects for proposals. Then on Mar. 9 we would have a vote to accept one proposal in principal. This does not mean that
no further changes are permitted, merely that the changes should be limited
in scope to clarifications, examples, and the like and not be substantive. On Apr. 6 we will vote on an LRM proposal. Are there any disagreements?

SC: The Cadence team has had some flux. I don't think we can be ready by Feb. 23. The middle of March would work better.

SL: Okay, how about we move the proposal deadline back to Mar. 9 and have the vote in the Mar. 23rd meeting? We would also push the LRM vote date back 2 weeks.

GV: I want to clarify that you are talking about proposals for user defined nets and resolution functions. I may not be able to attend Mar. 23rd meeting. I am the only Mentor representative and would prefer to not have the vote that day.

SL: Would an e-mail vote be acceptable?

GV: It depends, and I won't know my situation until Mar. 17.

SL: We can push the proposal vote back to Apr. 6. The dates would be Mar. 9 as the deadline proposals. Apr. 6 for a vote in principal and May 4th as the date to vote on the LRM proposal.

SC: What is the scope of the proposal?

SL: It is user defined resolution function and nets. I would really prefer not to break schedule. Please let me know if there is an emergency.

3. Election of new co-chair

Nomination of Jim Lear (GK, GV)

AK: What are the voting rules?

SSh: Subcommittees set their own rules.

GV: Generally try to achieve consensus. When things become an issue they become an issue at the WG level and it gets sorted out there. We can't actually approve LRM changes. The WG approves them. That is entity based. In everyone's best interest to come to a consensus in committee.

SSh: Occasionally there is a deadlock and a vote is needed to move forward.

GV: Happens, but not very often.

SSh: I need to leave.

Vote to elect Jim Lear as co-chair.
0n/0a/7y

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.

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.

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.

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.

-----------------------
---FULL LENGTH NOTES---
-----------------------
2010-01-25
----------
SV-DC Meeting Notes

0. IEEE patent policy (http://standards.ieee.org/board/pat/pat-slideset.ppt)
AK was a new attendee not familiar with the IEEE patent policy. SL read the IEEE patent policy slides.

1. Status of IEEE participation rules

SL summarized the e-mail from Neil K. below.

This FAQ has not arrived and there is now some speculation that this new
IEEE policy may not become enforceable for several more months.

2. TC cutoff date reminder

SL summarized the e-mail from Neil K. below.

SC: The Cadence team has had some flux. I don't think we can be ready by Feb. 23. The middle of March would work better.

SL: Okay, how about we move the proposal deadline back to Mar. 9 and have the vote in the Mar. 23rd meeting? We would also push the LRM vote date back 2 weeks.

SL: Would an e-mail vote be acceptable?

GV: It depends, and I won't know my situation until Mar. 17.

SL: Okay, we can push the proposal vote back to Apr. 6. The dates would be Mar. 9 as the deadline proposals. Apr. 6 for a vote in principal and May 4th as the date to vote on the LRM proposal.

SC: What is the scope of the proposal?

SL: It is user defined resolution function and nets. I would really prefer not to break schedule. Please let me know if there is an emergency.

3. Election of new co-chair

GK: I nominate Jim Lear.
GV: Second.

AK: What are the voting rules?

SSh: Subcommittees set their own rules.

SSh: Occasionally there is a deadlock and a vote is needed to move forward.

GV: Happens, but not very often.

SSh: I need to leave.

Vote to elect Jim Lear as co-chair.
0n/0a/7y

4. Discussion of user-defined nets and resolution functions

GV: I will give a quick description of what I started with, initial feedback, what I liked, and what I am uncomfortable with and center of current discomfort. I will try to not say too much about CDNS position. What I had written up in LRMish form is similar in concept to what I had put out a long time ago. You are allowed to talk about particular net declaration as being atomic nets (used primitive previously). An atomic net is something that represents a single topological connectivity point but has complex information in it (mixes of data types, real values, etc). It is a single topological point and thus needs resolution. It is an atomically resolved net.

AB: Are the nets resolved at top level?

GV: I am going to punt on that for now. I am going to say net declaration and ignore the effects of ports for now. We do have multiple drivers though. We have some issues to work through regarding connectivity impacts.

SSh: A driver must drive the entire net.

GV: Sure, I will let that stand for the time.

AK: Can I have a vector of atomic nets?

GV: Certainly. An atomic net is conceptually a wire with state.

SSh: Not sure vector applies.

GV: Sure, it is an array of atomic nets. You can have an atomic net that contains an array of values. Anything that is an atomic net is resolved in the whole w/ other values

SSh: You could be an unpacked array of atomic nets. Each atomic net would be resolved in the whole and the array parts individually.

FM: Atomic means it is resolved in the whole?

GV: Yes. As soon as you go down that path you need user-defined resolution functions. I am going to have nets that have these complex atomic values and you just associate a resolution function with nets. If and when it is collapsed you just make sure both ends are operating with the same resolution function. SSh observed that this adds quite a bit of specification into the design. He asked that the atomic nature be associated with the type of the net. You would declare a new nettype and say that this is the type of an atomic net. Conceptually similar to wire, tri, wand, wor, etc. Those basically are specific types of nets that are predefined in Verilog. SSh suggested that we associate the atomic types with the nettype instead of the declaration. I am okay with that. Where the current discussion point is whether that association is required.

AB: Resolution function is associated with the type and not the declaration? What is the difference?

GV: Assume you have an electrical type that contains a pair of real values, a current/voltage pair. If you have an electrical type where I started you could have different net declarations that were these atomic electrical nets and you would associate resolution functions with those nets separately. One electrical net could resolve using a particular resolution and a different electrical net resolving a different resolution function. This would associate with the topology and not the type. You can create different resolution functions for the declarations and not create two different types.

SSh: In GV's approach you would specify the data type independently from the resolution function. You could have two different types and then separately declare the resolution. I suggested that you take a data type and a resolution function and wrap them up in a nettype. Once I have done that every time I declare a net of that type I get that data type and resolution function. To use the same data type and a different resolution function I would declare a new nettype. The compatibility rules across ports require that they be the same nettype. In GV's proposal you would specify a resolution function at various spots and then you have to propagate that information around to ensure compatibility.

AB: Sounds very clear. What happens when you hit a net without a resolution function?

GV: This is where we are a little bit stuck. The ability to tie a type and resolution function is definitely useful. I don't' want the only way to specify a resolution function be with the type. If you want different resolution functions associated with type real then you have to create different types. You couldn't make that decision late. You would have to decide that when you declare the net instead of later when you connect it.

AB: Would it be possible if a module comes with a real port that the user has the possibility to associate the real type with a certain type or tag?

SSh: When you are talking about connecting the real to this net is the net also of type real? or is it a struct where you want to convert/resolve?

AB: No, I was thinking of a net multi-driven by complex port types that are standing by structs where something is underspecified where only a real is driving. I want to deal w/ this w/out forcing the user to specify everything. It would be nice to take the missing information as default.

GV: In particular the example I have been using is a scenario where you have IP blocks that have the shape of the net but don't hard code the types. You could then use a generate or design configuration to associate resolution functions. From what I have seen with analog designs particularly when you are slicing and dicing this is a common thing you would like to do.

AK: I thought the use case described a type of net real interacting with a user defined data type.

GV: That is a different problem. This is strictly a case where all of the drivers are providing the same type of value. Does the type of net imply the type of resolution function or can the resolution be decoupled.

SSh: Both proposals imply data type compatibility. Something additional would have to be allowed to allow pure interconnect nets or as is done in VAMS treating some type as pure interconnect. To take something that is real and treat it as a struct is different.

AK: What he is talking about is that I have some information in my net and then based on the connection I may want to use the information differently.

SSh: We discussed how someone may want to connect the two data types and we would need to do some type conversions.

AK: I want to get back to that example.

SSh: Can you explain which behavior you are looking for?

GV: Let's make a concrete example. Looking at the semantics for wreal my understanding of what CDNS permits is that you can associate different resolution functions. That is essentially the kind of thing I want to standardize through deferring the binding of the resolution function to the nettype. You can actually change the resolution function without having to retype all of the nets.

SSh: One of the questions there is, Is the reason why those nets can have the resolution function specified externally because there is a strong need for that capability or is it that there wasn't a language mechanism.

GV: I want the tool-based version to be responsive late and not require a recompile.

AK: How do the proposals address this?

GV: One thing I suggested was to say if you look at the nettype proposal to allow a nettype to have a default but overridable resolution function or not provide a resolution function. It would act as an unresolved net. Then a testbench (TB) could come in and associate the resolution function with a type and then all nets that use that type would get that resolution function. You aren't changing the type.

SSh: You are suggesting to this from a third party module containing a bunch of defparams, etc. to bind this late.

GV: Yes.

FM: You still have to re-elaborate.

GV: Why?

SSh: Let's suppose you are adding new resolution functions. Are you suggesting they are precompiled?

GV: If you change your TB and your TB would do that. Ok, yes. Just the testbench but not the IP would have to be recompiled.

SSh: We don't find that recompilation is a big deal with relation to re-elab.

GV: It is for IP where you don't have the source.

FM: If you don't have the resolution function for these nets you will have to recompute the hierarchy.

SSh: You will have to re-elaborate.

GV: SSh and I have agreed that this is a common problem when you introduce pure interconnect.

SSh: Things are still more localized if you use the nettype approach. Not in a significant way.

AK: Won't this create ambiguity with the same nettype and different resolution functions.

SSh: To figure out if things are the same you will have to group the nettype with the resolution function. I would call a nettype w/out a resolution function an incomplete nettype. You would have to compare the incomplete nettype with resolution functions.

JL: Is there an opportunity for problems if an IP that produces current is accidentally hooked up to something that is a voltage? Is there an option for the typechecking?

GV: That is the direction I am heading. There are a couple of reasonable tweaks. As SSh was suggesting. If you want things tied down then you associate a resolution function with the nettype.

SSh: You may also want a nettype as none where no resolution function is ever associated. You may need some sort of a subtype to say that I am okay with any resolution function that understands this is a current.

AK: The problem then becomes a problem across IP blocks. If one vendor picks type foo and another picks bar for current that is a problem.

GV: Vendors will have to use the same nettype b/c it is a strong type.

SSh: The same applies to GV's proposal where we need data type compatibility.

JL: If I have a block and one port is a current and another port is a voltage. If they are both real values is there a way to distinguish them?

GV: Short answer is not in the same way as VHDL. You could declare an unpacked struct containing a real. If you have two different structs containing the same shape they are not compatible. There are features in the core language that have denoted types.

SSh: If you wrap them in a struct then there is no automatic/implicit conversion. If you do want compatibility they would need to be declared together in the same package or something.

GV: Another example of strength of rf. Imagine you had a struct with a voltage, current, and bias. If you have three values and in some configurations of your block you want to ignore the bias. You know that they are garbage. You might have a resolution function that ignores the bias in one part of the cycle and then may want to switch over and pay attention to bias later. If you go w/ a strong correlation then you have to change the type. Resolution function is part of the type.

SSh: That is presumably in one place.

GV: Right, you have to recompile all the IP.

AK: This is exactly what happens in VHDL today.

GV: I hear complaints from people about this. The strong types make it less flexible.

AB: Could you please add your name when you speak? I can no longer associate voices. I have a little example. We have 3 modules. They meet in one net. They each have one port and are connected. One of the modules has an output port of current. Another module is a reader that wants to read voltage. Why a voltage? The third module. It is a type of accumulator...say a capacitor. It converts the current to voltage. How can we make sure that the reader gets the voltage read and not current?

AK: I don't think that the resolution function plays a role. You create a composite type with both current and voltage. Just read the voltage member. There is only 1 driver.

SSh: The accumulator is providing voltage. This doesn't sound like an atomic net to me.

GV: I have thought about this problem when I was thinking about a partially driven atomic net. I have since backpedaled on this because it is easy to encode it. Imagine you have the voltage and current. You can also have an enum that states what is being driven by the net. Then create a resolution function based on the values being contributed by the drivers I know which aspects to take into consideration and how to determine the value. I think it is possible to write models that are effectively partially driven. You have to encode that separately.

AK: I am confused by the atomic type. If I have two members can I drive them independently?

GV: No. You have to encode it. You cannot say myport.voltage = 1. You have to assign the entire net. You cannot drive a member of the net.

AK: That is hard for analog because you may not have the information.

GV: That is why I described how to model it.

SSh: As Gord described you drive the entire thing and tell it which items to ignore.

FM: These resolution functions are very specific and not particularly reusable. I can't see how they are applied generally.

GV: They are specific to types of behaviors. This is why I am concerned about tightly coupling them w/ the type. What I have seen in some PLI things that have been done is that data types are given that have the universe of possible information and the behavior of the resolution function is dependent on the shape of the design. The type doesn't change, but the resolution function changes what it pays attention to.

FM: What I have seen in VHDL is that you don't know anything about the driver and just resolve what is given. It seems like it would be possible to know the drivers here.

SSh: The tool doesn't provide this. The user writes the data type so that the resolution function can be told the information from the driver.

GV: You can mostly do this w/ VHDL today but hierarchical resolution gets in the way. If you have all drivers at the same level of hierarchy you could do it in VHDL today.

SSh: It isn't something that is built into the system. It is something that the user does.

GV: Essentially I originally started off with a tiny bit of support from the system to have trivial encodings supported within the system. At this point I want to get all of the core language support done and this can be added later if needed. I think we will want to get there b/c of ease of use but it isn't necessary.

FM: I have a question regarding these IP blocks. Doesn't this IP block need to provide its own resolution functions?

GV: It depends on how you want to go. If you want the user to be able to specify it then no. You could also override what is given.

FM: It isn't necessary for them to provide a resolution function?

GV: That is what I would like.

FM: They at least have to provide the data type.

SSh: The user will have to know that.

FM: How is the data type information provided to the user?

GV: A package or common data type.

FM: They may not provide a resolution function and let the user decide.

SSh: Likely they would provide a default.

AS: Under both proposals the shape of the data type can't change.

SSh: If you are going to do SV you will be stuck with that.

GV: There will eventually be a need to talk about conversion functions. I want to get the core rules set first.

AK: What does a partially driven composite net mean?

GV: If you have different contributors to a net that are contributing different aspects there is in either of the base sets of assumptions it is possible for the user to encode the semantic intent of partially driving a net. Eventually, think next PAR there might be room for having core language support for modeling that. I don't want to go there b/c we are struggling with simpler things.

SSh: To make a more concrete example w/ a voltage real and current real you add a bit that says I am driven. The resolution function then only looks at the bits that are driven. It is completely under user control. They are driving the whole thing. These are driving values. They aren't going to see what the drivers put on. They will only see the resolved value.

AS: There are limitations to what you can do with resolution functions. If you have a current driving a cap you want to know the value...this would have to be added to the resolution function.

SSh: Right, you may want to have impedance and capacitance also added.

AB: May I add something to the example. The probe doesn't influence anything but I think there is a situation where it may influence things. Let's say it is an ADC or assertion. The probe will be triggered and at a specific point it should measure what is on the net. Is there a possibility to poke and cause evaluation? Is there a possibility for the event to trigger reevaluation?

GV: I think that you are far ahead from where we are talking. Once we have core infrastructure and semantics for what it means to have a collapsed atomic net we can start talking about models for how we can potentially extend simulation activity with respect to various real problems. I think that is probably far away from where we are. I can't imagine talking about those problems in this PAR.

AB: I think it is an important aspect.

GV: My personal goal is to try to close as few doors as possible. I really want to end up with infrastructure here that is as least restrictive as we can. Within the core functionality we need to be extremely careful about what decisions are made. It could cause problems downstream if we get some of this wrong.

AB: I imagine this is important for the verification folks.

SSh: In theory this could be done with user-defined types. You can stick extra control signals into the type as long as the resolution function passes them through. The probe could drive a control signal but not the voltage and current. The accumulator can watch for this and do the update. You can build a complete communication systems within these resolution functions.

AB: I previously proposed this and thought that events couldn't be used in this way.

SSh: You would have to toggle a bit. There is no easy way to assign events without using dynamic objects. It gets sticky.

AS: There is a slight disconnect between what AB specified and what we are talking about. He mentioned integration and we aren't talking about time.

SSh: The user would have to manage time.

AS: Yes, it would have to be part of the model.

SSh: I don't think we are discussing the resolution functions having a notion of time.

AK: What are you wanting the language to solve? This can be done at the modeling level.

AB: I just want the ability to synchronize the atomic net at a precise time and the contributors are forced to update.

GV: One issue blocking consensus is how closely do we want the resolution functions associated. Can we get a show of hands from the user about what they think here? One thing is where resolution functions get applied in the topology. This will be another significant block.

SSh: Can you explain the last part?

GV: Part of my proposal was to deal with port direction semantics. It breaks with the traditional assumption that port direction doesn't matter.

SSh: You have mentioned the fact that VHDL resolution functions don't work well b/c of hierarchy. SV may have a better semantics but we need to decide what to do w/ input and output.

GV: Yes.

JL: Can we back up a bit. You said that we would be able to have different resolution functions at different parts of the hierarchy. Did I understand that properly?

GV: Nope. Only one resolution function/net. You can have two distinct nets that have the same type but different resolution functions. Or you wouldn't define the resolution function until the testbench is present.

SSh: Hierarchical resolution of VHDL doesn't work with functions that aren't associative. If you actually wanted hierarchical resolution for some reason then that might depend on how we define input and output ports. If you define output ports to never port collapse then you would have different nets on the inside and outside ports.

GV: That is basically what I said.

SSh: The way we implement inout is by collapsing. There may be implementations that have issue w/ an LRM that requires collapsing.

GV: That is why I was going to only apply this only to the new atomic nets. It would create a new obligation only for the new features.

JL: When you read an inout port will you read the resolved value?

GV: Yes.

SSh: Whenever you read it you will always get the resolved value.

JL: What are the differences?

GV: We hadn't opened the issue of port collapsing. SSh had said that I was adopting different semantics from port connectivity that what was traditional. I am prepared to defer this for now. The current issue is how tightly coupled is resolution functions to the net. When you define a net type you set it and are done or can it be set later.

SSh: Let me point out that I am making my arguments from a language consistency point of view. When it comes to do we need this flexibility I would have to defer to AK.

GV: My proposal is a looser coupling. I agree.

SSh: The only things that are similar in current SV are typedefs and binds which cause shivers to go down the backs of anyone who does SV. typedefs and binds intrude in the middle of elaboration and this only messes with a leaf node. This ability to come in from outside causes a lot of interactions. This may bring in a bunch of issues that we have had to fight before.

GV: defparams have a convergence issue. I want user input. I am willing to make it have tighter coupling if that is what the users want.

SL: We need to end. Users please send your thoughts on the coupling issue.

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

Received on Thu Jan 27 11:48:27 2011

This archive was generated by hypermail 2.1.8 : Thu Jan 27 2011 - 11:48:28 PST

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