Most, if not all, designs which are being verified today are configurable. This is just a fact of life, with companies trying to reuse as much IP as possible in multiple different projects, or iterations of the same project. The requirements change as well (sometimes too often) and the interface protocols are getting more elaborate and layered. Just have a look at the table below:
(Ref: http://www.3gpp.org The Mobile Broadband Standard, Typical examples of Radio Access Bearers (RABs))
So as a verification engineer, you have to cope with that and construct your code accordingly. There are multiple ways configurability can be handled and, recently, a new option was added to Incisive Enterprise Specman.
A built-in comparison operator called “in_table” is now supported in Incisive Specman Enterprise. It lets you compare multiple values (called a tuple) with rows in a table. For example:
So the (1,2,3) is the tuple used for the comparison. The table data itself consists of multiple row descriptions separated by a semicolon. Each row contains a comma separating values or ranges, and the amount of elements in the row and in the tuple need to be the same.
Now you might ask: ‘What has this got to do with configuration?’ The answer to this is that you can use the in_table operator in constraints. So you can enforce a number of parameters to be generated in order to have matching values (or fall within matching ranges) of at least one row in a table. Consider the example below:
This is a very concise and easy to maintain/understand description of a set of rules for some configuration parameters. Of course you could implement this with a list of structs containing specific values to reflect the same information, and use constraints to enforce that your choice should be one of the list elements. The benefit of in_table to that is the fact that the in_table constraints can be overlaid with other constraints, like the example below:
If you had just picked values out of a pre-generated list, it would not be possible to overlay other constraints (in a list, this is treated as input). Another benefit is that constraints with in_table offer better performance. The table expresses the information of the legal options, and the tool (IntelliGen) can optimize the solving - this is similar to using list pseudo methods in solving. Such constructs are more concise and explicit and, thus, enable better internal optimization.
Below is a tool output log showing some results when running this code (with some random seeds):
It’s also worth stating that the example above can also be achieved by adding constraints in sub-types or by using imply constraints. There is no need to rewrite your existing code, but next time you need to tackle a highly configurable environment, keep the in_table construct in mind.
Happy coding,
-TeamSpecman
Note: the in_table construct is available starting with version 15.20