Performance Tips and Tricks: Coding e Ports for Enhanced Performance

This blog entry builds on last week's Tips and Tricks posting in which we discussed the usage of list.delete(0) in Tip 1.  This week, we discuss a topic that is close to many users.  Ports are used widely throughout the verification environment as one of the main mechanisms for interacting with HDL code running within the simulator.  Here are a few ways to improve performance when it comes to ports.

Tip 2: Use Port Unification

You can improve performance by using port unification when more than one port is bound to the same external entity.

Impact:

Wall clock

Explanation:

When port unification is enabled, all external ports bound to the same signal (that is, all external ports that have the same HDL path) are unified. This saves access to the simulator and therefore improves run time.

To enable port unification, set the simulation configuration option enable_ports_unification to TRUE. (The default is FALSE.)

Example:

In the following example, there will be only one call from the simulator to Specman for each clock change, as opposed to three (one for each instance of the verifier unit).

unit verifier {

clk : in simple_port of bit is instance;

keep bind(clk,external);

keep clk.hdl_path() == "~/top.clk";

verify()@fall(clk$) is {

...// do something

};

};

extend sys {

v1 : verifier is instance;

v2 : verifier is instance;

v3 : verifier is instance;

...

};

extend sys {

setup() is also {

set_config(simulation, enable_ports_unification, TRUE)

};

};

Tip 3: Use e Ports Instead of Computed Names

In general, computed names impact performance because they require more runtime string operations and searching. When the strings that make up a computed name are known in advance, use ports instead of computed names.

Impact:

Wall clock

Explanation:

In e code, you can define access to HDL objects by using either:

• e ports
• Tick notation (specifying the pathname of an HDL object using a string inside single quotes).

When you use tick notation, you can specify the HDL pathname with a native simulator hierarchical path or a Specman canonical path, or with a computed name. A computed name consists of one or more strings that are computed at runtime.

Note The vr_ad register and memory modeling package for e uses tick access only for "backdoor" access to DUT signals, which means you cannot convert such access to ports.

Example:

In the following example, the computed name is actually resolved at the generation phase because the value of reset_name is fixed in generation.

unit verify {

reset_name : string;

keep reset_name == "rst";

sample()@some_event is {

'(reset_name)' = 1;

};

};

It is better, in this case, to use a simple e port:

unit verify {

rst : out simple_port of bit is instance;

reset_name : string;

keep reset_name == "rst";

keep rst.hdl_path() == reset_name;

sample()@some_event is {

rst$ = 1;

};

};

Tip 4: To Define Simulator Events Sensitive to an Edge, Choose Event Ports (with edge() Attribute) over Simple Ports

It is better to define simulator events sensitive to a specific edge (clocks, for example) with an event port that has an edge() attribute defined, than with a simple port containing an @sim event.

Impact:

Wall clock

Explanation:

To define an event in Specman as sensitive to specific edge in a simulator object, use an event port with the edge() attribute defined rather than a rise/fall of a simple port with an @sim event.

Using an event port with the edge() attribute saves calls to Specman tick because the edge transition condition is checked before the Specman tick.

Example:

Use the following:

clk_rise_port :in event_port is instance;

keep clk_rise_port.hdl_path() == "clk";

keep clk_rise_port.edge() == rise;

event clock_rise is @clk_rise_port$;

Instead of:

clk_rise_port : in simple_port of bit is instance;

keep clk_rise_port.hdl_path() == "clk";

event clock_rise is rise(clk_rise_port$)@sim;

Defining Temporary Events

On the other hand, to define temporary events for bounded times, it is better to use simple ports with @sim inlined inside the wait/sync action. For example:

wait change(top.p$)@sim;

Next week, we will be pulling another tidbit out of the new 9.2 Specman Performance Handbook available within the Cadence Help System.  We will be discussing how to better manage Specman Memory.

Hope this helps! 

Team Specman