Hi Everyone,
I'll start entering these into Mantis, but if you want to see the full list from Intel, this is it.
Thanks, -Tom
SystemVerilog Enhancement Request List from Intel - SV-EC work targeting 2012 release:
* SV-EC - Virtual ports - Virtual interfaces allow an interface to be duplicated and still keep a class that virtualizes it the ability to stay generic but this is not port granular. For our CRAB SVTB classes, I had no way to virtualize the port so that I could construct an object and with "new" pass in the names of the ports I wanted that object's methods to work on. See my mails to the SV-EC team on Oct 2, 2008.
* SV-EC - Multi-dimensional queues - I had a really good case where this would have been beneficial to have:
logic [45:0] IdQueueAddr [2:0][$];
logic [2:0] IdQueueMemType [2:0][$];
logic IdQueueType [2:0][$];
* SV-EC - (2012) $void() - vcs concept that allows the expression put in the $void to be solve first when it's within a constraint.
* SV-EC - Soft Constraints - We want the ability to place 'soft' constraints on identifiers. A soft constraint is the ability to place a constraint on an object/identifier or rand/randc value and have that constraint met when possible. If for example the identifier was defined with a vector range of [15:0] and the soft constraint was created for that identifier to be [12:8], then the soft constraint would be kept. If the soft constraint was outside that range, i.e. [31:18], then the soft constraint would not be met. If the soft constraint overlaps the range, i.e. [20:8], then the overlapped region would be kept at the constraint, or in other words [15:8]. Usage of soft constraints should be restricted/limited by the language since they can result in unexpected behavior if they are ever implicitly ignored/overridden. I recommend that soft constraints be limited to the form "soft <var> != <const>". An explicit override from within a randomize () with {} block could be written as "allow <var> == <const>". This could be expanded slightly to allow any comparison/inside operator (not just != and ==). The "allow" statement would explicitly expand the solution space beyond defined soft constraint restrictions. This has the following advantages over the existing capabilities:
a. The user doesn't need to explicitly know the name of the constraint block in order to disable the soft constraint, just the name of the variable.
b. It would be possible for the class writer to put several soft constraints within the same named constraint block and still allow the user to disable the soft constraints one at a time.
c. The soft constraint can be overridden from within the randomize () with {} block, rather than outside the block
d. The soft constraint can be temporarily overridden in a 1-shot manner, without having to disable before randomize() and enable after randomize()
e. It should be possible to allow a user (or macro) to write the "allow" constraint in the randomize () with {} block, even if there isn't actually a soft constraint on the variable.
f. This is a better method compared to other unrestricted soft constraint methodologies because overriding the soft constraints is still explicit. i.e. soft constraints cannot be unexpectedly implicitly overridden.
Also compared to other unrestricted soft constraint methodologies, the simulator will "know" what soft constraints to override prior to solving the randomize(), without back-tracing. This should maintain a predictable behavior and randomization distribution.
* SV-EC - Defaults Constraints - Basically if a default constraint is provided it is used. If for any reason the variables within that default constraint are used in another constraint, the defaults constraint goes completely away. Eg:
class testr;
rand int x, y;
default constraint c_x {
x >= 1024;
x < 2048;
}
default constraint c_y {
y >= 0;
y < 512;
}
endclass
class tr_ext extends testr;
//This one disables c_x, even though they are not conflicting
constraint c_xx {
x > y;
}
//This one disables c_y
constraint c_yy {
y >= 640;
y <= 1024;
}
endclass
* SV-EC - 'Other' soft distribution weight range - This would be the ability to designate 'left-over' distributions to a distribution list within the union of hard and soft constraints. The example 'e' code below assigns a distribution of 5% to all other non-assigned distribution ranges (i.e. 4..9).
byte_offset : int [0..9];
keep soft byte_offset == select {
90 : 0; // normal aligned access
5 : [1..3]; // unaligned but still accesses some implemented bytes
5 : others; // unaligned and doesn't access any implemented bytes
};
* SV-EC - 'Pass' distribution inheritance with superset weight applied along with new constrains added - means that for the specified weight it ignores this select constraint, using the distributions from any previously parsed soft select constraint or an even distribution of remaining legal values if none. This is most useful when a test wants to effectively increase the weight of specific value(s) but still utilize any well constructed default weights that exist in the TE for other values. The test can have a soft select constraint specifying that desired value(s) with a weight of say 10 and then have "pass" with a weight of say 90 ... 90% of the time the well crafted distributions from the TE are still used. A common use would be for sequence kinds ... there are a lot of possible kinds, you typically don't want all kinds to have an equal weight by default (ex: want a lot more normal loads than locks) but the test may want to increase a particular kind without having to specify a full new select/dist constraint that covers all the other kinds.
* SV-EC - Enumerate extension - Conceptually we are asking for is to enable enumerate extension much like we have with class extension. Obviously this only works for typdef'd enum's. 'e' has this concept of enumerate extension while keeping the type name that is created, but we believe that creating a new type name is feasible within SVTB. No examples to provide yet on how to syntactically demonstrate this.
* SV-EC - Enumerate name space scope clashing - The name space chosen by enumerates should not clash with other enumerates within the same scope. Eg. This one works (different scopes) :
module a;
typedef enum { IDLE, BUSY, WAIT } something_e;
endmodule
module b;
typedef enum { IDLE, SENDING, RECEIVING } xaction_status_e;
endmodule
But this one does not (same scope):
class aa;
typedef enum { IDLE, BUSY, WAIT } something_e;
typedef enum { IDLE, SENDING, RECEIVING } xaction_status_e;
endclass
But this one also works (different class scope):
class aa;
typedef enum { IDLE, BUSY, WAIT } something_e;
endclass
class bb extends aa;
typedef enum { IDLE, SENDING, RECEIVING } xaction_status_e;
endclass
* SV-EC - Cross cover points across different cover groups -
* Cross coverage is allowed only between coverage points defined within the same coverage group
* Limits reuse: coverpoint definitions cannot be reused by other covergroups
* Readability: a covergroup may contain a large amount of user-defined bins to cover, need the ability to break coverpoints down into logical covergroups to condense coverage definitions and provide better readablility
* Eg.
covergroup pipe_events (ref bit ovr_bit, ref bit udr_bit, ref bit err ...);
overflow: coverpoint ovr_bit;
underflow: coverpoint udr_bit;
error: coverpoint err;
...
nndgroup
covergroup opcodes (ref bit [71:0] op, ref bit[1:0] precision);
ops: coverpoint op{
wildcard bins sp = {72'h00000????};
wildcard bins dp = {72'h0????????};
wildcard bins ep = {72'h1????????};
}
pre: coverpoint precision{
bins single = {2'b00};
bins double = {2'b01};
wildcard bins extended = {2'b1?};
}
op_prec: cross ops precision;
endgroup
covergroup stage_corners(ref bit ovr_bit, ref bit udr_bit, ref bit err ..., ref bit [71:0] op, ref bit[1:0] precision);
pipe_events pe = new(ovr_bit, udr_bit, err,...;
opcodes op = new(op, precision);
cross pe op.op.prec;
endgroup
initial begin
stage_corner st2_cnr, st3_cnr;
st2_cnr = new(ovr_bit_st2, udr_bit_st2, err_st2..., op_stg2, precision);
st3_cnr = new(ovr_bit_st3, udr_bit_st3, err_st3..., op_stg3, precision);
end
* SV-EC - Introspection - Useful for IDE's and test frameworks and other developer tools. There are other uses, but my main motivation is developer tools. OVM uses a lot of macros for doing property registration, etc. These would not be necessary if there was introspection support in the language.
http://www.iis.sinica.edu.tw/~trc/spe-introspection.pdf
* SV-EC - Exceptions - http://en.wikibooks.org/wiki/C++_Programming/Exception_Handling
* SV-EC - Method overloading - This is the ability to use the same method name, but have two different argument sets. For example:
virtual function myfunc(objectClassA a);
virtual function myfunc(objectClassB b);
The simulator would determine which of these methods to call based on the argument passed to the method. This may or may not be possible to implement with default arguments and it may be acceptable to implement this with the disclaimer that it cannot be used with method that have default arguments.
Method overloading (Description #2). SV doesn't support function overloading. You can only have 1 version of a function inside a class. Since it is possible to create default arguments and pass values to functions by name, it isn't too much of a limitation, until you attempt to overload a function in a sub-class. The overloaded sub-class function must have the exact same prototype as the parent class. I can't add extra functionality in the sub class without adding the same parameter to the parent class (presumably with a default value to avoid breaking existing code). I am proposing is that a sub-class should be able to overload a function and add additional parameters if they have default values. That should be able to work within the existing language. E.g.:
class Animal;
virtual function move (int distance);
...
endfunction
endclass
class Dog extends Animal;
function move (int distance, int speed = 5);
...
endfunction
endclass
Dog myDog = new;
Animal myAni = myDog;
myAni.move(10); // Dog::move() is called with distance = 10 and speed is the default value.
* SV-EC - Multiple Inheritance - Open issue ID 0001356 regarding multiple inheritance. Intel would like to see multiple inheritance implemented, specifically with Java-like restrictions. i.e. allowing multiple inheritance extending zero or more pure virtual classes and up to one other class. (In Java, a special type of pure virtual class is called an "interface" instead of a class). C++ is a little too relaxed on allowing multiple inheritance of non-pure-virtual classes which can get you into trouble.
(Further comments from Paul Baleme request) Java Style interfaces (basically a completely virtual class that other classes must "implement") (http://java.sun.com/docs/books/tutorial/java/concepts/interface.html) These are VERY different from pure virtual classes. It is a mechanism for achieving the goodness of multiple inheritance, without the complexity of multiple inheritance. The key is the "implements" keyword. A single class can "implement" multiple "interfaces". This is different from a pure virtual class where the implementing class can only "extend" a single pure virtual class. This feature is used heavily in Java, and is an important feature for code maintainability.
* SV-EC - Solve...Before enhanced - Intel would like to see a "hard" version of solve...before... added to the spec for the purpose of speeding up simulations. The spec currently states that solve...before... must affect how weights are applied, but it cannot not be possible for a solve...before to create a random contradiction. Eg, if you use solve X before Y, the solver must not report contradictions for Y based on the value that was chosen for X. That requirement puts extra overhead on the constraint solver which slows down simulations. With a "hard" version, it would be possible for the solver to actually solve X first without worrying about back-tracing; it would be up to the user to appropriately restrict X so that Y won't have random contradictions. This would effectively tell the constraint solver how to divide-and-conquer the problem of solving the constraint. It would be required for a simulator to support the syntax, but not necessarily required that the simulator make use of the functionality. For debug, a switch should be available to instruct the simulator to ignore the "hard" directive. As a practical point, it would be up to the user to first get everything working using "soft" solve...before..., and then use the "hard" solve...before... to optimize the code.
* SV-EC - The ability to refer to class handles inside of constraints. Eg.
constraint solve_before {
//This is not supported by the language
solve class1 before class2;
//These ones work
solve class1.a before class2.x;
solve class1.b before class2.y;
solve class1.c before class2.z;
}
* SV-EC - Standardize a warning or a behavior where interdependent distributions cannot be met. For example:
constraint myConst {
x dist {0 := 2, 1 := 1};
y dist {0 := 1, 1 := 2};
x == y;
}
It is impossible to satisfy the distributions for both x and y and it is impossible to determine the user's intent. The SV spec currently does not prevent the user from writing the above and it does not specify how the simulator should behave. At a minimum, the behavior should be defined in the spec. e.g., the distribution shall be determined for all combinations of x and y before applying the interdependent constraint (x == y), which shall result in a final distribution of {x, y} dist {{0,0} := 2, {1,1} := 2}. I would also like the spec to define a (optional) warning (or error) when this type of implicit interdependent distribution is found.
* SV-EC - Proper Polymorphic behavior of instantiation. This code should work (something like this works in C++ and Java) but it doesn't work in SV.
// Standard Polymorphic Construction Example
BasePacket packets[100];
EtherPacket ep = new; // extends BasePacket
packets[0] = ep;
// New Polymorphic Construction Example
BasePacket packets[100];
packets[0] = new EtherPacket; // extends BasePacket
It's relatively easy to work around this limitation, but there is no reason to have this limitation. (Contributor - Brandon Tipp, William Dubel)
* SV-EC - Aspect Oriented Programming (AOP) - This request is to add support within the language of some key AOP features that will exist on top of the OOP functionality that already exists. Specifically we would like the ability to:
* "Inline extension' of classes such that they 'add to' or replace properties and/or methods. This is not true OOP extension and inheritance, and it's not polymorphism. This is the AOP concept that allows the means to take a class and add functionality to it or replace functionality in more of an inline approach like the 'e' language 'is also' construct. The name of the class would not change, only code that "see's" the 'is also' would have the classes changes inlined into their implementation. How we make the code "see" the inline class extension is up for debate.
* With the "inline extension", also provide the functionality to select how methods are changed. If the inlined method is the same as the base method, then allow the inlined method to either replace, be run before, or run after the same base method.
* Method select based on property type (parameterization of method call) - This is another 'e' concept implemented with the 'when' construct. Multiple implementations of a method or constraints of properties can be created in a class and chosen given the type of a specific property at the time of object creation. (See Method Overloading description above)
* SV-EC - Constraint Composition - Add the ability to compose the constraint set of an object to be made up of the collective constraints of multiple objects
myObject1 = new(); // This contains a set of constraints
myObject2 = new(); // This contains a different set of constraints
myObject1.contains(myObject2);
myObject1.randomize(); // The constraints of both myObject1 and myObject2 would be applied to the randomize call.
* SV-EC - Ability to declare classes/methods/variables/constraints final. Causes a compile error if someone tries to override. Example:
virtual final function void myMethod();
//method body
endfunction
final class myClass;
// class body
endclass
etc.
The compiler would flag an error if any user attempted to override any of these items.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Feb 19 15:53:27 2010
This archive was generated by hypermail 2.1.8 : Fri Feb 19 2010 - 15:53:39 PST