Just recently Cadence announced the new superb simulator, Xcellium. Just as Specman was part of the previous simulator, IES, it is now part of Xcellium.
As always, we keep enhancing and developing Specman, and the new Specman release, now part of Xcellium, contains great new capabilities. The focus in the last year was on tools that will enable you, the verification experts, to create easy to use powerful verification environments.
Here are some of the highlights of Specman 16.11 (aka “First Xcellium”).
interface type was added to the e language. e interface is similar to Java interface—an abstract type used to specify a behavior that a component is supposed to implement. Unlike other languages, an e unit implementing an interface does not have to implement all the interface methods. They can be implemented in a later extension, or not implemented at all (error will be issued only if an unimplemented method is being called).
The basic usage of the interface is to standardize the verification environment, as it defines not only what behavior is required, but also the api of the implementation.
For example, one can define the following interface named monitoring. Each unit that declares itself as implementing this interface, is expected to implement its three methods.
<’
// defining the interface
//
interface monitoring {
write_log_file_header();
dump_and_check_data();
write_end_of_test_status();
};
‘>
<’
// implementing the interface
//
unit abc_monitor like project_abc_base_unit
implementing monitoring {
my_items : list of abc_items;
write_log_file_header() is {
out(“Monitor ABC, protocol version ”, ABC_VERSION);
// etc …
};
dump_and_check_data() is {
for each in my_items {
// …
};
};
// etc...
};
‘>
In the above code, note how using interface we achieve something similar to multiple inheritance; the abc_monitor inherits a company or project base type (project_abc_base_unit, in this example), and “inherits” the monitoring interface behavior.
With interface, you can implement polymorphism. You can instantiate a list of interfaces - containing all units that implement this interface - and thus activate many interfaces in a loop. The list of the interface can be built in many ways, in this example – each unit that implements the interface, adds itself to the list.
<’
// the top component contains units implementing the
// ‘monitoring’ interface
extend my_env {
// a list of all units that implement the
// ‘monitoring’ interface.
!all_monitors : list of monitoring;
// add implementer to the list
add_monitor(monitor_implementer : monitoring) is {
all_monitors.add(monitor_implementer);
};
event power_down;
// we activate the monitoring interface of all the units,
// regardless of the implementing unit type
on power_down {
for each in all_monitors {
it.dump_data();
};
};
};
// extend the unit my_checker to also implement the
// ‘monitoring’ interface
extend my_checker implementing monitoring {
dump_data() is {...};
// if contained within my_env – add myself to the list
post_generate() is also {
var my_env_container := get_enclosing_unit(my_env);
if my_env_container != NULL {
my_env_container.add_monitor(me);
};
};
};
‘>
Another great construct that was added to Specman is the table. This is one of my favorites, so I already wrote about it in creating-code-from-tables.
To make a long story short – you can provide input to the verification environment in table format. The table can be written in e files, CSV, and even Excel, meaning that there is no need to “code” the configuration; one can use in the testbench the same excel files written by the manager or the architect. The very basic use model is for defining configuration, but you can use tables to create code that follows any kind of regular pattern. This is a real eye opener experience, do take a look in creating-code-from-tables.
One of the areas of Specman that is keep evolving, is its interface to other tools, languages and platforms.
To improve the interface with SystemC models, we added two types to the e language - numeric,and fixed point.
The numeric is a template of an interface containing all the methods that are needed in order to define a numeric type. numeric_add(), numeric_to_int(), real_to_numeric(), numeric_ipow() , and many more.
As we got a request to implement fixed point in e—we defined this new type using the new numeric template. The fixed point type is implemented in UVM e, as open source, so you can view it and see how you can define any numeric type.
For the UVM-SV and UVM-SC users, we added multi languageEnd of Test synchronization; when running in a multi-language environment, Specman synchronizes with the UVM-SV objection mechanism. The test will stop only when all components, in all languages, have dropped their objections.
As you can see, we enjoy extending e and Specman toolkit, maintaining it the most powerful (not to mention—cool) verification language.
Efrat Shneydor,
And the rest of Team Specman