SV-DC meeting minutes Date: 2015.02.06 Attendees: Shekar Chetput (SC) - Cadence Mark Hartoog (MH) - Synopsys Scott Little (SL) - Intel Francoise Martinolle (FM) - Cadence Martin O'Leary (MO) - Qualcomm Arturo Salz (AS) - Synopsys Aaron Spratt (AaS) - Cadence Ian Wilson (IW) - Cadence Gordon Vreugdenhil (GV) - Mentor Graphics Kyl Scott (KS) - Texas Instruments Agenda: 1. IEEE patent policy (http://standards.ieee.org/board/pat/pat-slideset.ppt) Please read the above content if you aren't familiar with it already. 2. Minutes Approval SC made a motion to approve the minutes with GV as second. 3. Discuss potential work items * UPF/multiple power supply support for adapters [MartinO] MO: Multi-power supplies are a common situation. We are thinking about adding adapters which are power aware. One way that people talk about adding it is via UPF. UPF is often not suitable for the more analogy parts of the design. We should support UPF and have another mechanism to pass the power supply information to the adapter. I see this as passing a power supply connection explicitly to the adapter. AS: This could result in two different flows. In F2F, we had discussed about using APIs to query about power supply set - which works independent of power specification format. We would have some API to determine the power domain associated with a particular driver and receiver. MO: We also potentially discussed connecting nets to an adapter when specifying the adapter rules and have those scoped. AS: That is precisely what doesn't scale in the current VAMS. I would need to see a real example. SC: If we have the power ports specified in the adapter rules, is that considered as explicit ports of an adapter? AS: That doesn't work when you have multiple supplies. The power supply ports belong to the adapters. SC: Seems two approaches are discussed here. One is where you have a generic adapter - where the ports are not part of the adapter but are optionally tagged on in the rules. That way, they can be parameterized. The other is where you explicitly specify the power ports to the adapter. MO: Attaching a supply to an adapter via the rules. It helps to do multiple power supplies without UPF. On the user side you have to be careful in terms of drivers and receivers. If you have a situation where you want to add power supply to adapters then it may only be a small percentage of the adapters. The ability to hard code it into the rules would be useful. AS: You are saying that you don't want to use UPF, so you are going back and explicitly hooking them up. Please think about hundreds of power supplies. It does get large and complex. MO: This method doesn't scale well but in many cases it is convenient. UPF doesn't work well for analog. SL: Only supply information needed because supernets are broken on the UPF boundary. AS: Yes. AaS: If you don't have UPF then it becomes hard to break the supernets at boundaries. SC: Besides, you could have primary and secondary power with power switching. If you have some sort of UPF API then everything is managed there. If you have explicit rules then I am not sure how this would work. MO: In some sense power management is done differently for analog and digital. In analog the supplies are explicit and in digital they aren't. AS: If you add them in the rules these things have to have a name and they have to be connected. You can't support dynamic supply switching. MO: If I am attaching a port on the adapter, then I can do this. AS: We should be working toward an API. The requirement is clear that you don't want a full-fledged UPF. MO: One use-case to consider is when you have logic gates inside the analog and then these gates need to communicate w/ the digital. This creates problems. SL: High level requirement is to have power supplies in the adapters. Up for debate about how. * Support for strings in UDNs MO: Application is switched networks. It would be nice to have a UDN with a string field and then set the name of the field to what the signal represents and then check if the string is as expected. SL: Can't you just use integers? MO: Sure, but isn't as pretty. KS: Want to give the users a human readable version of the UDN value. GV: Wouldn't you want that to be a data converter that takes the value and outputs the string? KS: How do you call such a function in a waveform tool? Today we have a waveform that is a single real. Now with UDNs we have large structs that are hard to use. If we turn it into a string then it is easier to figure out what is going on without decoding the structural elements of the UDN. AS: I have an adverse reaction to putting dynamic objects into structural components. You run out of memory and it is hard to debug. Also, rather than making it a debug feature, you are forcing things into user space upfront. GV: There are a lot of way to separate this question if you wanted to do this. You could create a string value for debug purposes. You could talk to your vendor about function evaluation to create a string at debug time. I agree with Arturo. I am really nervous about dynamic objects, even strings in UDNs. You can use a fixed size string today. KS: Ok. One thing with the fixed length arrays is that the tool doesn't recognize it by default as a string. GV: I would suggest discussing that problem with the vendor. I see this as a vendor issue. KS: That is perfectly valid. I am expecting you guys to be the responsible parent. AS: We are still working on the core capabilities. We haven't gotten too deeply into the debug. It may need to be on the C side instead of the SV language side. KS: We have log files generated with printf and waveforms. How does the API fit into this? AS: One thing is correlating the log file messages to which src line and when. KS: That is way beyond what we need. Right now I just need a way to make meaningful messages to users. I just want to know which net is causing the problem. AS: This isn't needed in Verilog. You are looking at either drivers or receivers. KS: This is the first time that users are coding resolution functions. There are tons of errors coded. What happens if one message fires. How to determine which UDN caused it? GV: In situations like that, there are multiple options. 1. Add ability to map inputs to outputs. 2. Encode error states in the UDNs and then do debug that way. I think it is a solvable problem. KS: We tried the encoding but it doesn't work well. If the resolution function is called twice then you don't get the event. You don't have state and can't do something like use a counter. We want to isolate things at the source. Finding X through its propagation to the source in digital is a similar problem. There are tools today to help you find the source of X. Say someone miscodes a model and gives you a negative R. How can we quickly find the source of that problem? AS: Usually an X being propagated isn't a design error. You wait for an assertion to fire. Wouldn't a negative R be caught at the source and you can control the source instead of the resolution function? KS: Sure. It is convenient to catch it at the source but can't control the source as it is all across the company. However, can control from the resolution function. I don't know that assertions can catch everything. It is easier to validate the results of my math when I am doing the math. I want to be able to check these things there. SL: This discussed has veered into different directions. Sounds like it request isn't something that vendors thought was feasible. Martin are you ok to drop it? MO: Didn't realize the issues. I will check back with my folks and get back. KS: Okay w/ fixed length Verilog. * Resolution function debugging MO: What about a display function in the resolution function? KS: We use %m and %t a lot. Can we get something similar that gives us the driver? GV: There can be multiple names. KS: Desire is to have top most name - a name with least hierarchical value. GV: That is an issue. Vendor optimization choices start coming into play here. KS: I will settle for a reasonable name. AS: What would you do w/ that name? KS: Give it in the error message. AS: Then what? KS: Pull up the schematic or net and try to figure out what is going on. AS: It is easier to push that onto the debug vendor. Have the tool automatically take you to that place. KS: Your simulator isn't our schematic tool. We want to be able to have something that can be used in various ways. MO: Higher level names are more useful. Low level names can often be confusing. Maybe something that could be accessible via VPI to write C code. AS: There isn't a %m for nets. KS: Right we want that concept in the language, now that we have user-defined resolution function. MO: Can I call a VPI function from within a resolution function? KS: The only place we want a net name is inside a resolution function. GV: One thing that vendors have to consider is how users will abuse the features. Users will abuse the functionality. KS: Sure the language could restrict it to be used within a resolution function. Add a system call which is valid only within UDR. It could be as basic as %m. AS: Modules exist but nets don't. You could call an API function and get a handle to the net then do something useful. KS: If it is VPI and I can write it and reuse it then we are fine. If it is a %m equivalent or a $system call then it is easy and we are fine. I am looking for a facility in the language that supports the feature. If it can be packaged for reuse, great. Otherwise, we end up with vendor specific solutions. GV: Let me take half a step back. There is a difference between something loose and descriptive vs authoritative. Typename is my favorite whipping boy. The LRM says effectively that typename should be authoritative. People have tried to use it that way and it isn't. It is virtually impossible for the vendors to make it as strong as LRM envisioned it to be. If you want something loosely defined for the vendors to tell you something approximate about the state of things like - give a name of some segment of the net which is resolved - that may be more amenable. Words about "at the top" or "near the top" make me nervous. If you say something about the name in the collapsed net, then, that is easier. We should put on the agenda something about understanding the state of the resolution function by the user. KS: Sounds reasonable. Also, brainstorm if there are ways to get driver info, loads, etc. GV: Loads are going to be difficult. KS: Today have some workarounds by loading them with fixed length arrays, etc. Topic for a different day. SL: Will put something in the requirements list. MO signs off. * Event sensitivity on aggregates SL: Is this a topic for SV-DC or should someone else tackle it? KS: Everyone falls into the trap of trying to do this. A UDN is a signal in the user's mind. We have taken an aggregate and imposed it on the signal space. Users seem them as signals, developers see them as aggregate. GV: Original intent is when combining things with interconnect, you want users to be thinking about things in a conceptually similar manner. This one introduces a disconnect. MH: I don't see a problem with always @(UDN or struct). It is the posedge, negedge. KS: I don't have a strong need to go inside. I am more interested if an event happened on the net. GV: If you are doing RNMs and do @(UDN) then one of the first questions is what is the tolerance for change. KS: It is an event. It is an event-based simulation. GV: But there may be some numerical noise to filter. KS: That is the user's responsibility to filter small changes. GV: Ok. If you are willing to deal with that it is fine. One question was do users need to describe what constitutes a change on the UDN. AS: Think big. GV: There are aspects of efficiency that come into place here. If you start adding additional info into the UDN for debug. That starts to participate in determining what causes events. SL: Have seen bunch of debug stuff. Would be nice to say which parts are event sensitivity and a tolerance. That way don't have to look at changes due to changes in debug related fields. GV: I have some ideas. Not sure what users want. KS: I am not sure we know for sure yet. Does adding tolerance introduce state in a resolution function? AS: That's where adapters kick in, not in resolution functions. GV: The simulator has to maintain some state somewhere to calculate events. KS: How about the case where you have a sequence of small events but not one that is big enough to trigger the event. Will it be guaranteed to eventually get an event? GV: We need to pay attention to the math in real numbers here. KS: This can really improve the efficiency of the simulation because things don't trigger when needed. GV: Could easily see a bunch of different ways. One approach is using a predicate function. Did the output of resolution function and current value of net change? Compare aspects of UDN to determine if there is an event. The user could write the predicate function and whether true or false and event would happen. KS: Just giving the previous value would be a big help. SL: Ok, call it event sensitivity to UDNs GV: Yes, even something like a wreal could benefit. * Resolution function error messages SL: Covered it already? KS: Yes * Global variable access in resolution functions SL: Does this merge into error message topic? KS: This is a separate one. Can be used for a number of things. Instead of having fixed length strings in my UDNs, use dynamic strings that I can store them in a global data structure. That way, it is not created many times. GV: We could say that any updates would affect only outputs of the resolution function. This prevents users from affecting other parts of the design. You can add warnings in the LRM, but it is a support nightmare. KS: You can't idiot proof things but not having it is limiting. We would prefer it to be in the LRM. GV: I think if there is interest in dealing w/ the definitional side. If updates to global variables from resolution functions don't cause update events, it would reduce the risk of user abuse. The fact that you could have diagnostic info that produces different counts and states is easier to deal with someone triggering events off in the design and having users complain about when the event happens. KS: Would be okay if we use some other heart beat event to look at the variable(sideways access to globals). That could be ok. On the surface those restrictions seem ok. SL: Ok to add it to the list and keep it restrictive. * Advanced run time timing control KS: This is something that we see coming but don't deal with today. We have struggled with delays in our models. At Verilog all of the advanced delay stuff is gate level. If you look at UVM there is phasing and our models are moving in that direction. They don't have as many phases but they are using the phasing. Having the "parameters" changing at runtime is a reality. AS: You can do more advanced stuff but you have to model it. You need move away from the declarative state. GV: General question is, is it in verification space? These aren't synthesizable models? KS: Right. GV: There are lots of things you can do already with fine grain process granularity. Once you get into the space of wanting to model delays in a dynamic landscape then it gets into methodology. If you want to start tying into delays into the connectivity of UVM. This doesn't belong in the core language it belongs in the methodology/UVM committee. KS: We want runtime control over the delays. We have to assign with delay and non-blocking or blocking, ability to track glitches, put out unknowns, etx. When I looked at things I ended up trying to build my own scheduler. How do I cancel an event, etc. GV: This ties into some of the SV/VAMS discussion regarding inertial vs. transport delay in an adapter. There are some parallels. If you want to have that level of control you can probably do it. Before we go down that route in SV-DC we should probably wait a bit. This is something of interest between SV/VAMS and SV-DC. I don't think we are ready to go that way in DC yet. KS: Somebody had the idea of adding primitives to the language and users can use them. AS: What sort of primitives? KS: Something to say that I want to cancel this event or have one assign be transport vs. inertial. AS: Once the users have built up enough collateral then they can push the vendors to add something. GV: If you can express this as a clear set of requirements around this then we can take a look at it. I am with Arturo that this needs time to mature. I don't think we have enough information to be general today. KS: The problem is that if we don't do something this rev, then it will be another 10 years before we see something in the tools. I expect this modeling methodology to explode and would like to be ready. SL: Will keep it on the list, probably lower priority. * Ability to model a trireg like behavior on a net of a UDN SC: A user is trying to model transistor-level behavior with real number models. I thought it would be worth it to see what this group thought. GV: The huge question here is when you look at trireg and rtran and even tran there is a basic built in view of cap and R. It is very simplistic and not clear if it makes sense to extend much of that into a UDN space. I think it adds a bunch of complexity. There may be some room for tran and tranif but most of the rest of it makes me very uncertain about what number of hooks users would need to describe stuff correctly and still have the simulators do their relaxation algorithms correctly. SC: At this point if they have to try and model something in the user space how do they manage some sort of state in the UDN? AS: Think of a capacitive component. Now model it with capacitors and switches. Trireg merges those. Storing simulation state goes against everything we have done. I haven't thought about how to do it. GV: There are things that we can do w/ tran and tranif to help users understand the contribution from other parts. My question is whether or not a simplified approach of for UDNs a tran connection should collapse across the tran. Is that accurate enough? My guess is no. SC: Let me see if I can get more information about what they are trying. Maybe tran or tranif can help accomplish this. GV: From a large design perspective, seeing a tran across a logic net and then being able to substitute a more accurate UDN would be nice. Is it defined for interconnect? The question becomes interesting to me only when you want to have a tran on an interconnect and substitute in a logic or UDN and leave the tran as an artifact in the netlist. I can't see a user encoding a tran when they are dealing w/ a UDN. KS: We had a design with a pass through with an open drain with different power. You couldn't model it unless you knew the state of the driver in the other power domain. When we discussed it in the UDN context and the resolution function will report back driver state so that everyone can see that. We were really struggling w/ bidirectionality. GV: Can we simplify the question a bit? I thought about a set of invariants for a tran connection across a UDN. I think we can do this, but I think the user side restrictions are sufficiently complicated that is probably isn't a winning strategy. GV: Will a simple model be acceptable from the user side? SL: Will leave prioritization as-is for now. We have about 3 weeks to discuss. How long should we ask for? GV: If ability to spend time outside meetings is limited, it can stretch the PAR. So, that should also be discussed. How much time can people commit to working on proposals? SL: Good point. Follow up to determine forum bandwidth/participation. 1. Roadmap document [http://goo.gl/OOI0gN] a. Review work items b. Prioritize work items c. Estimate time required for work items Upcoming dates to note: 2011-02-20 - SV-DC meeting 2011-02-27 - SV-DC meeting -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Feb 17 11:32:32 2015
This archive was generated by hypermail 2.1.8 : Tue Feb 17 2015 - 11:32:42 PST