Scott, I just reviewed the minutes and have the following clarification, regd: ? SC: This caught the attention of some of our SV experts. Another request is to have parts of a UDT in the sensitivity list. Is that related? ? ? GV: You want to be sensitive to an individual field? ? ? SC: Yes, something like always @(UDT.a). I meant to say that: "Another request is to have whole UDT in the sensitivity list. Currently, individual fields have to be specified which can be cumbersome when a struct has a lot of fields or when arrays of UDTs are used. For example, always @(UDT.x, UDT.y) is supported but I understand that always @(UDT) isn't legal in the standard yet. Hence the request. Cheers, Shekar. From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Little, Scott Sent: Saturday, January 24, 2015 9:47 AM To: sv-dc@eda.org Subject: [sv-dc] Minutes from SV-DC meeting on 2015.01.23 Please let me know if you have any corrections to the minutes below. Please also send along any additional requirements/features you would like to see in the next SV revision related to SV-DC. We will discuss any new items at the first of next meeting. I would prefer to have all major items discussed by that time. Thanks, Scott SV-DC meeting minutes Date: 2015.01.23 Attendees: Shekar Chetput (SC) - Cadence Mark Hartoog (MH) - Synopsys Scott Little (SL) - Intel Dave Miller (DM) - Freescale Francoise Martinolle (FM) - Cadence Martin O'Leary (MO) - Qualcomm Subodh Reddy (SR) - Maxim Arturo Salz (AS) - Synopsys Sundaram Sangameswaran (SS) - Texas Instruments Aaron Spratt (AaS) - Cadence Ian Wilson (IW) - Cadence Gordon Vreugdenhil (GV) - Mentor Graphics Agenda: 1. IEEE patent policy (http://standards.ieee.org/board/pat/pat-slideset.ppt) SL read the slides. Please read them if you aren't familiar. 2. Committee leadership SL will chair the committee for these introductory meetings. We can take a look at electing a chair and co-chair once the PAR is done and we are officially starting work. SL would like a volunteer to take minutes. No volunteers. Please let SL know if you would like to take minutes. 3. Committee expectations a. Role in the upcoming PAR The next SV PAR is expected to be primarily bug fixes. There is a desire to minimize the number of large changes. SV-DC has been given an exception and will be allowed to work on significant items. The purpose of these initial meetings is to come up with a list of items we believe are important to complete in the upcoming PAR cycle. We should also come up with an approximate timeline. The length of time that the PAR will be open is currently undecided. Our input will definitely affect the length of the PAR. b. Relationship to SV/VAMS work There is currently a committee meeting to work on AMS extensions to SV. This work is referred to as the SV/VAMS work. The expectation is that this work will result in a dot standard to SV. The expectation is that it will be 1800.1. SL understands that UVM is targeting 1800.2 with the idea that the AMS extensions will be 1800.1. FM: How does SV-DC differ from 1800.1? SL: SV-DC will make changes that only affect the digital behavior. 1800.1 will define the changes necessary for interaction with an analog solver. For example, the rules for connecting two UDNs will be defined by SV-DC but the rules for connection a UDN to a Spice port will be defined by 1800.1. There is a large amount of overlap and will need to be lots of coordination between the two committees. Fortunately, there is a lot of overlap between the two groups. FM: Will 1800.1 need a PAR? SL: Yes, but my understand is that the creation of this PAR can happen very late in the process. Often the standard is nearly ready and the PAR is opened for final touches and voting. 4. Discuss potential work items (Please bring any additional items you may have to the meeting. I would expect that the result of these 3-4 meetings is something similar to the roadmap document from the last PAR. It can be found at this link: http://bit.ly/apjS6s) SL: I would like to discuss potential requirements for the upcoming PAR. I expect that we will do something like we did for the previous PAR which is to come up with a list of requirements and then rank them as MUST, SHOULD, or COULD. The MUST items will need to be accomplished during the upcoming PAR window and SHOULD items are next in line if we somehow manage to finish the MUST items. Let's go through the list of items that I sent out. Most of these items have come up during SV/VAMS discussions and have some overlap with that group. a. Variable connections to user-defined nettypes (UDNs) and interconnect i. Rules for interconnect abstraction resolution in the presence of variable connections GV: In the last SV-DC work we were conservative about how nettypes are connected and driven. We didn't want to make decisions too early about semantics. We should call out interconnect specifically in this item. It should be variable connections to user-defined nettypes and interconnect. For example, if you have UDN of logic and drive it with a real valued variable port connection it isn't clear even though there are Verilog semantics for converting logic to real that such a connection is a desirable thing for the user. There are some questions about what should be allowed semantically. Do we want to allow Verilog semantics onto a UDN? Then what happens when you allow a variable connecting to interconnect? Right now it is clear. It isn't allowed. One might want to consider if you have a nettype connecting to a variable. Do you connect the nettype first or the variable first. How do you want to order that? What are the rules? These questions rose in the SV/VAMS group. SL: This benefits the usability of nettypes? GV: Yes, most cases are obvious. The questions are how do you deal with things that aren't compatible. That is where we will need discussion. SC: Is this one of the aspects that is addressed through adapters? GV: There will we some interactions. We will probably need a few rounds of discussion and then refine both sides as the proposals converge. SS: What is the concern with allowing an r2l connection? GV: If you have a real value where a user is intending it to be a value in a voltage in a 0.5V domain and has a value of 0.47. Logically in the voltage domain that would be a logic 1. Under Verilog rules you would get a logic 0. When there is a mix of abstractions in a connection was the user's intent to have an abstraction conversion or did the user just screw up? There are situations where you want to allow conversions and insert an adapter. There are situations where the user made a mistake. We need to come up with a set of rules to help the user. SS: Doesn't the same problem exist when you have a logic to logic connection across power domains? GV: Sure. If it is straight logic then you have to assume that the mapping into the logic is correct at the perimeter. If you have mixed representation then you have to think about how to handle that. b. Switch primitives that support UDNs i. Method to define unknown (X) and undriven (Z) values for a given UDN MO: Looking at SV 2012 the UDN was a very useful addition. One challenge with using it effectively is that there isn't a good way to model switches. Switches are prevalent in modern designs. They can be in series or parallel or very complex configurations. We need to verify the proper connections. The request is to have some feature in the language like a primitive that will work with UDNs. GV: In previous discussions people have expressed a desire to use a tran or tranif and even with an abstraction shift still have a functional system. MO: Yeah, it seems like the tran gate is a good model. SL: The list also calls out a way to represent X and Z. This will be needed to determine the output of the tran gate in certain situations. GV: There is a way to do it without defining X and Z. We could apply invariants to the resolution function so that they behave in certain contexts that is compatible with X or Z behavior. SS: Do we come into a situation where we have multiple switches and they have a different definition for X and Z. Do we address that or can we assume it is uniform? GV: I don't think we can assume it is uniform. I think we will have to discuss this in the context of adapters. What if we have different nettypes on each side of the gate? How do we handle that? c. Heterogeneous concatenations involving UDNs d. Packed/unpacked port connections involving UDNs GV: Both 'c' and 'd' are thinking about how interconnect works in practice. We were very conservative in the SV-DC work. You can have concats of interconnect and concats of UDNs. If you have 2 pins as wire and 3 as interconnect talking about that as a concat from a modeling perspective makes sense. From a language perspective talking about the type of the concat is awkward. It isn't conceptually difficult but it is tricky to talk about in the language of the LRM. When you start thinking about packed and unpacked port connections if you have a UDN the difference between packed and unpacked is immaterial. Interconnect concats do not have a value. They are a sequence of connections. You can't display, force, etc. When you have a heterogenous connection it seems like the difference between packed and unpacked is immaterial. We should talk about if we want to relax the rules. AaS: There is no definition of an interconnect concat in the standard. If you have an unpacked interconnect there is no way to do that. AS: Right, we need to resolve it. SC: Is that part of this discussion? GV: It is a bit separate, but we should discuss it. SC: We should maybe add it to the list for scheduling. Concats of interconnect come into play with netlist creation. Should we expand a bit to see how this applies to things that are electrical? GV: The electrical side is out of the scope of SV-DC. My expectation would be that if we do this in a reasonable way in SV-DC that the SV/VAMS extension to handle electrical would be an obvious extension to SV-DC behavior and wouldn't pose any problems. We can talk about it to make sure it is doable but the implementation is out of scope. e. Partial drive of UDN struct fields GV: This was raised originally as part of SV-DC. We didn't get to it due to time constraints. Right now if you have a composite data type when you drive a net you must provide an entire value as part of the drive. If you have a voltage and a current you couldn't just drive the voltage even if one was not really driven. That was ok in SV-DC b/c the user can always write their own state to describe semantics. You could encode it in some way as a user. I think it makes sense to provide a way for the user to do a partial drive. We need to define the semantics, etc. I don't think we have clear ideas but it should be discussed. SC: This caught the attention of some of our SV experts. Another request is to have parts of a UDT in the sensitivity list. Is that related? GV: You want to be sensitive to an individual field? SC: Yes, something like always @(UDT.a). GV: That is something that should be discussed. AS: That is allowed today except on an interconnect. AaS: The users want to be sensitive to an array of UDT. They want to be sensitive to the entire array of UDTs. ShC: Today they can use always @(*) SL: Sensitivity of aggregates of UDTs will be added to the list. SS: I feel that partial drive must be allowed. Forcing someone to drive all members is a bit silly. GV: If the language gives you help to recognize an open drive it would avoid the user from deciding on their own encoding. It isn't that you can't solve the problem right now. Is it worthwhile to provide language facilities to do this. AS: It is a question of priority. GV: Personally, this is lower because it can be done today. f. Adapters (i.e., conversion elements) between non-matching UDNs i. Rules for selecting and specializing adapters ii. Scheduling of adapter evaluation in the digital simulation cycle SS: When it comes to UDN how are we going to come to some standardization on adapters? GV: Why don't we step back and discuss adapters first. We should also discuss the concept of supernets. Let's break down the discussion into two pieces. Adapters are a shift between two different abstractions. You might have a UDN describing something as a struct of real values and connect that to a logic value. It is just an abstracton shift. When the abstraction shift happens you don't want to use Verilog rules even if they are defined. You want to understand the abstraction in one domain and drive it into another domain. Viewed as a uni-directional transfer of data from one abstraction to another. There is a wide range of options in regard to how this works. We need to provide a mechanism in the language for the user to be able to write an adapter and define which UDNs it works on. The rules for selecting adapters and how they work needs to be described. The syntax for an adapter and the properties need to be described. When the adapter is evaluated (how they behave in the simulation cycle) also needs to be described. This will take some time. I now need to talk about supernets. There is a bit of a shift about how digital systems have traditionally worked in Verilog vs. the way analog people must think about their designs. In general w/in a digital system because of the nature of the logic type and logic resolution it doesn't matter how you do the resolution. It can be done partially and in any order. When you start talking about things that more accurately model systems closer to an analog level, the number of loads, biases, etc. start to become more important and you need to view all drives at once. There has been a lot of discussion at the SV/VAMS level. The flexibility that we have had with digital to resolution in any order is no longer true. We will have to have some interesting discussions about whether we want to have a more global resolution analysis in order to provide a higher level of semantic integrity in the design. If we maintain the Verilog method it will be consistent with the current LRM but likely won't be want the end user wants. SS: I was originally thinking only of adapters in the digital domain. I can now see how it makes sense to connect to electrical. We would like them only in the digital domain for sure. Am I envisioning adapters right? GV: This is hard to condense. I am going to appeal to electrical even though that isn't directly an SV-DC concern. If you have an electrical pin connected to digital through logic and then go back to electrical. It is clear that the analog folks need those two electrical things to be the same node. In that situation the electrical resolution is flattened and the connectivity of the various electrical pieces are gathered together. When you look at having various types of UDNs. If you have two UDNs that approximate electrical do you want to collect all drivers in the UDN and present them simultaneously. Questions like that are what we are discussing. It has an impact in one's ability to switch back and forth between abstractions and have a consistent view. The hope is that in real scenarios that we minimize the difference in behavior between the simulation systems when we change between discrete and continous abstractions. This leads us to take on some of the hard requirements in AMS. SS: When we discussed point 'a' and point 'b' we said that adapters may be the way to go. Adapters may be complicated. Are we going to address 'a' and 'b' first or start w/ adapter? GV: We need to talk about a few things repeatedly. We won't come up with a definition for adapters with talking about 'a' and 'b'. We will have to go back and forth until the complete set of rules and syntax becomes clear. It isn't a linear path. SL: Are there any new items to add to the list? MO: I have an interconnect network connected to UDN1, UDN2, UDN3 then what does the interconnect specialize to? Does this fall under rules for specialized adapters? GV: As soon as you talk about networks that have interconnect components the question of where an adapter is inserted and what is its name start to come up. Those need to part of the discussion. Connect modules and discipline imply or determine a location in the hierarchy for them. The SV/VAMS have moved away from that approach. It isn't fully defined yet. IW: The key thing is to find and query an adapter. You need some way to find them but where there isn't important. FM: Are you saying that they won't have a hierarchical name? GV: Yes. SS: Are we considering getting inputs from the vendors that will ease their implementation? GV: Vendors bring up issues in regard to semantics, implementation complexity, etc. That is part of the discussion in these forums. Vendors are careful not to talk about too many details but they are considered. SC: I think it would be good to standardize on some UDTs. Cadence has a package that could be used as a starting point. GV: That is a good thing to add to the discussion list. SC: This could also lead to standard adapters. GV: Yeah, that would be good. This can be a big help to the users. SS: Yes, something that is uniform across vendors would be welcome. SL: Thanks everyone. My expectation is that we will only need 3 meetings. Before the next meeting I would like everyone to send me their requirements. That way we can have the requirements in front of us and start to prioritize things. Then in the third meeting or maybe even over e-mail we can try to figure out the timelines. I don't plan to use Lync as a mechanism to share very often. I know that it doesn't work well for everyone. I will mostly use Google docs to do interactive work in meetings. Upcoming dates to note: 2015-02-06 - SV-DC meeting 2011-02-20 - SV-DC meeting (if needed) 2011-02-27 - SV-DC meeting -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Feb 3 17:00:37 2015
This archive was generated by hypermail 2.1.8 : Tue Feb 03 2015 - 17:00:44 PST