On (3), I think we could possibly define things such that any updates during a resolution function will NOT cause update events (other than the resolution fanout). That would "define away" the potential for users to rely on scheduling impacts. I still don't like global "writes" during resolution functions, even for "counters". I know that you, Kyl, have indicated that you're aware that a "did it happen" count should not be expected to have a consistent cross-vender count, but it is still extremely common for users to in fact depend on such things and complain when there are differences -- no matter how strongly the LRM says "you can't depend on it". Gord On 2/5/15 10:40 PM, Arturo Salz wrote: > Just a few comments to Steven's response. > > For (2) which is strictly a debug issues I believe we can come up with better schemes than just passing some name - printf debugging. It should be possible to build the functionality to retrieve VPI handles to the signals involved in the resolution, but generally I see this more of a simulator debug than of a design. To debug UDN themselves, it is probably better to use a smaller test that doesn't require this. > > For (3) that was precisely the concern. We felt that reading global variables may not be a problem for resolution, but modifying simulation state and possibly creating events/evaluations was definitely problematic. > > For (4) I believe that this is the type of things that we are considering for adapters (state, event management, glitch removal, etc...). I believe that our preference is to push all this out to users space and not build the functionality into the tool. > > Arturo > > -----Original Message----- > From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Steven Sharp > Sent: Wednesday, February 04, 2015 2:40 PM > To: Kyl Scott; sv-dc@eda.org > Subject: RE: [sv-dc] A few SV-DC items from a user's experience... > > Some comments on these items: > > 1) I don't think this is specific to UDNs. It is about the data type. The LRM specifies in 9.4.2 that event expressions must be of singular types, not aggregates. A real or logic is a singular type. An unpacked struct is not. It is not clear to me that there is a strong reason for this restriction at this point in SV. > > One minor issue could be that posedge/negedge/edge are well-defined or at least easily extrapolated for the singular types (with the possible exception of strings, which were reclassified as singular in the current revision). The LRM doesn't actually define them for anything except single bit or vector types, but it doesn't explicitly restrict them either. This issue could be addressed by specifying what is allowed for posedge/negedge/edge, separately from what is allowed as event expressions in general. > > There could also have been an issue in Verilog with arrays as expressions and defining what constitutes an event. However, SV allows aggregates as expressions in other contexts. It defines equality and inequality operators for them, which provides a basis for defining what constitutes an event. > > I think the biggest issue is one of potential performance/memory cost of allowing aggregates in arbitrary event controls, when their values could be very large. The @* construct is generally implemented as allowing aggregates in the resulting implicit event control, but those implicit event controls are restricted in ways that allow the efficiency problems to be avoided pretty easily. The SV always_comb construct, with its "longest static prefix" rule, can produce implicit event controls that are not so restricted. They are not as unrestricted as user-written event controls, but could still have similar problems. > > Given that always_comb can already create problematic implicit event controls containing aggregates, I don't see much justification for disallowing explicit event controls containing aggregates. Unless someone else points out another issue with it, I would favor removing this restriction from the LRM. > > > 2) I can see adding a mechanism to get a hierarchical name for the net currently being resolved. I don't think a new format descriptor is justified for this, but perhaps a system task call. We would have to define what it does if it is called while a net is not being resolved, but that is easy enough. It would not be trivial to define what name should be used. Due to connections or aliases using hierarchical references, there may not be a unique top most name for a given net. > > I think getting the name of the net being driven by a particular driver in the input argument array should also be feasible. Perhaps it could use another system task that takes the array index as an argument. Note that this might not be a port, unless the net being driven happens to be declared as a port. You could also have multiple drivers driving the same net at the same place in the hierarchy, so you could get duplicate names. This might call for additional information about the position of the driver in the source. > > I think loads are more problematic. Note that ports are not loads; they simply pass the net through. Like drivers, I think the only thing that could be provided is the name by which the load refers to the net. It seems more likely that there are multiple loads than drivers at the same place in the hierarchy, making the issue of duplicate names more of a problem. You also may be able to write this functionality yourself using a user-defined VPI system task that takes the hierarchical name of the net being resolved (which you get from the first system task discussed), and finds the loads and prints whatever you want about them. I think you could do something similar to get a list of drivers, but there I think you need to be able to correlate the names to the values in the input argument array, so something built-in would be needed. > > Another possibility for drivers would be to extend the types allowed in UDNs to include strings, so you can continue with the method you are using now, without the cost of a large fixed=length string in each net. > > BTW, does anybody know whether there is anything like this for resolution functions in VHDL? Probably everyone just uses the standard logic resolution and this doesn't come up there. > > > 3) I recall there was discussion about allowing access to globals. I think there was discussion of a scenario where you wanted to be able to set some global parameter that influenced resolution results, and using a variable to enable this to be changed from run to run without having to recompile as would normally be required with a parameter. Ultimately I think we decided to be restrictive, to avoid the kinds of bad coding practices you referred to. Perhaps others will remember more of the issues that were discussed. > > One additional issue that comes to mind now: if you can modify outside variables, this could cause scheduling activity for things waiting on those variables. Doing this while in the middle of resolving a net might lead to some kind of problem, though I can't think of any specific ones right now. > > > 4) As you say, this would need a lot more fleshing out. If the number of variations wanted by users is small enough, it may be reasonable to build them all in. If the number of variations is too large, it would be better to provide some low-level built-in building blocks that users can then use to construct their own variation. For example, would versions of nonblocking assignments that do inertial or transport descheduling be sufficient to build everything you wanted on top of? > > > -----Original Message----- > From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Kyl Scott > Sent: Tuesday, February 03, 2015 10:30 PM > To: sv-dc@eda.org > Subject: [sv-dc] A few SV-DC items from a user's experience... > > Hi Folks: > > I am new to the SV-DC list, but have been working on using the excellent work that all of you have done over the past several years to work on creating a better event driven analog modeling infrastructure than the more limited simple real valued models that we have been using in SystemVerilog. > > I am certainly not as well versed in the nuances and details of the language as the committee, so I will rely on all of you to help translate these ideas into the specific formats and amount of information that the committee needs... I am also hoping to learn a lot from you and the others during the next few years, as well. > > Here are several items that we have encountered already or brushed up against enough to start thinking about: > > 1) always @(UDT) > > Every user I have seen so far immediately hits this one and is very confused. While always @(*) is a workaround, this is a non-intuitive > limitation: > > logic sig_logic; > real sig_real; > UDN sig_UDN; > > always @(sig_logic) is OK, always @(sig_real) is OK, always @(sig_UDN) is an error, and this really confuses people. > > They think of logic, UDN, etc. as signals, and not as non-struct vs. > struct, etc. And I suppose always @(sig_UDN) would work if the UDN was a real and not a struct? So it is not even consistent within the UDN space? This is certainly not the highest priority item to think about, but it would be nice to clean this up and save a lot of people from some very confusing compile errors and wasted time. My understanding is that the LRM does not specify any required behavior for this case, so it might be nice to plug that hole, in the context of UDNs. > > 2) Resolution function error messages > > One thing we quickly noticed once we started writing resolution functions is that there is no way to get the net name of the net that is being resolved. If you have a design with 10,000 nets, and you get a resolution error, it is rather difficult to figure out where the error is located in the actual design. %m is useless in this context, since it simply returns the resolution function, which is the same for all > nets of that type. So we need either a new % format or system call > that would return the hierarchical name of the node being resolved. Our preference is that the name would be the top most name (least number of hierarchical levels) rather than some deep in the design leaf name (since a single node can have many different net names associated with it, as it traverses the hierarchy). I am not sure if there needs to be any options to control the format or not (I don't see the need for other formats, but it might make sense to have them or it might align the system call with other system calls, etc.). > > In a similar vein, it would be nice to have an easy way to get the hierarchical port name of the node driver/loads from within the resolution function. This would be the full hierarchical path to the port on the instantiated module. Today we can do this by generating these names in the models by combining %m with a hard coded port name, and then passing this into the resolution function via the UDN struct, but this is inefficient, as it requires allocating a fair bit of fixed length string space in the UDN struct (for large designs with descriptive names and lots of hierarchy, 1024 chars can be reached, and that is a lot of extra space on every UDN throughout the design). So this would be a nice place to add a system call that could be called from the resolution function with the driver/load index, and which would return the hierarchical port name. With these two items, then we can produce messages like: > > **ERROR** More than one power supply detected on a power supply node: > **ERROR** Net: tb_top.DUT.analog_core.AVDD3P3V. > **ERROR** Supply: tb_top.DUT.analog_core.ldo_3P3V.reg_out. > **ERROR** Supply: tb_top.DUT.analog_core.ldo_5P0V.reg_out. > > This allows a designer or verification person to immediately find the problem in the schematic or netlist. > > In essence, this would be a capability along the lines of %m, but in the context of net/driver/load hierarchies, instead of in the context of module/package/function/task/etc. hierarchies. > > 3) Global variables > > I understand some of the reasons why accessing global variables from a resolution function is prohibited (for example, it introduces the issue of bad code causing execution order dependencies, etc.). However, we have seen where global variables can be used safely and add important features for us, and power/efficiency to the UDN struct. > > a) global error/warning counters - our verification methodology uses a number of global (package) error and warning counters. There is a set for test bench/test case errors, another set for design (i.e.: RTL) errors, another set for model errors, etc. At the end of the test, the test bench will check these global counters and use them to determine the test case pass/fail status, along with generating a summary report. > Without global variables, it is impossible to reliably produce a count of the errors/warnings detected in a resolution function. Instead the test case may indicate PASS but then the log would have to be post-processed to see the resolution function messages, which then turns the situation into a FAIL. Also, simulations might self terminate early if a large error count is reached, rather than running for a long time with problems. If the simulation is not able to track the errors as it runs, then this can not happen. > > b) UDN struct efficiency - rather than pass in the 1024 char hierarchical port name as a member of the UDN struct, we can pass in an integer index to a global dynamic array of string, for example. This saves overall memory as well as the overhead associated with the UDN struct processing. Another case would be for power supply nodes or other special types of node where a model accessible list of all driver/load states is desired. We can pass an index to a global dynamic structure that is the proper size for the data related to that specific node (which the resolution function would then update), rather than having to size the UDN for the worst possible case for any node. > > 4) Advanced run time timing control > > This is a complex one, and we have only thought about it a little bit so far. I'm tossing it out to see where the discussion goes. It is not necessarily an SV-DC topic, but I thought since it does relate to using SV-DC, I would start here. > > The advanced timing infrastructure in SystemVerilog for logic (0/1/Z/X) signals is mainly compile and elaboration time based (specify, SDF, 6/12-tuple timing, etc.), and is aimed at back annotation for gate simulation. There is a reduced level of run time control available (such as assign with 1, 2 or 3 values, for example). > > Our verification is now SystemVerilog UVM, so it is all run time built and configured. Test cases need to control the various model parameters (times, voltages, currents, etc.) at run time and change them during the test run phase. Where we are seeing limitations is with both assign (for UDNs it can only accept a single value, since it does not know the various transition types for a non 0/1/Z/X signal) and with always and <= (where trying to behaviorally assign different delays can lead to incorrect results, because events do not cause cancellation of other events). > > We want to be able to model more complex analog timing, such as turn off/turn on times, rise/fall times, output delays that are input state dependent, etc. We want to be able to select inertial/transport delay modeling, glitch handling, etc. However, there is no simple way to do this today (and to some extent it is limited for logic signals at run time, as well, but less limited for logic than for UDNs). > > At the moment, it seems like we would have to write our own scheduler code, perhaps using queues, for example, and then handle event queuing, cancellation, inertial vs. transport, glitch detection, etc. I am not sure this is even possible, but if it is, it is probably a lot of code for each output of each model, and it may not scale well. Building these features into the language and thus into the simulator kernel probably speeds things up by several orders of magnitude, and avoids a lot of repeated work as different users all try to solve the same basic problems in completely different ways. Essentially, it seems like we want some kind of arc based timing but based on UDN specific conditions. Honestly, until we can get a lot deeper into real world UDN modeling with actual designs, I won't have a lot of details or insight into the specifics of this, but perhaps some of you experts have already been thinking about it. > > A simple contrived example: > > analog output ana1 turns on in 50 ns, turns off in 100 ns, and when on changes values in 10 ns. > > assign can not handle this case (accepts a single time only). > > ana1_int is the model internal value, prior to being delayed. The following is psuedocode, rather than actual model code... > > always @(ana1_int) begin > if (turn_on) ana1 <= #50 ana_int; > else if (turn_off) ana1 <= #100 ana_int; > else if (driven_change) ana1 <= #10 ana_int; > else ana1 <= udn_unknown; > end > > For the sequence: > > 0: ana1_int = off (initial value) > 100: ana1_int = on (1.0 V) > 120: ana1_int = 2.0 V > 140: ana1_int = off > 160: ana1_int = on (3.0 V) > > I think we get events like this (I did not have time to code up a test case and simulate it, so my apologies if I make a mistake here). > > Listed in event creation order: > > 0: ana1 = off (initial value) > 150: ana1 -> 1.0 V > 130: ana1 -> 2.0 V > 240: ana1 -> off > 210: ana1 -> 3.0 V > > Reordering the above events in time order: > > 0: ana1 = off (initial value) > 130: ana1 -> 2.0 V > 150: ana1 -> 1.0 V > 210: ana1 -> 3.0 V > 240: ana1 -> off > > which is clearly not the intended model behavior... (for example, the final value should be on at 3.0 V, not off). > > There are probably other things that we have not hit yet, but these are a few that have come up so far. > > Thanks, > > -Kyl > > -- > +-----------------------------------------------------------------------------+ > | Kyl Scott, Mixed-Signal ASIC Design, Texas Instruments, Dallas, TX | > | email: horseplay@ieee.org, kyl.scott@ti.com (214)480-3810 | > +-----------------------------------------------------------------------------+ > > > > -- > This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. > > > > -- > This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. > > > > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Verification Technologies, Mentor Graphics gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Feb 6 07:27:44 2015
This archive was generated by hypermail 2.1.8 : Fri Feb 06 2015 - 07:27:52 PST