Home > Community > Blogs > Functional Verification > performance aware e coding guidelines part 3
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Functional Verification blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Performance-Aware e Coding Guidelines – Part 3

Comments(0)Filed under: Functional Verification, IES, Incisive Enterprise Simulator (IES), e, Specman, IES-XL, tech tips, specman elite, performance

The constraint solver is a powerful and fun to use tool.  Actually, it is so much fun that  sometimes people tend to use it in cases where generation is not required.  Of course, like any other algorithmic engine, the “price” of using the constraint solver is paid in performance – both memory and CPU.  This price is acceptable whenever the solver is used to process complicated generation problems, but it’s way too expensive when you do not really need the solver’s power.

Fortunately, there is a simple rule you can follow: the constraint solver should not be used when the items are created procedurally

The potential “gotcha” here is that sometimes procedural creation can be disguised as generation.  Watch out for these cases:

• Fields that are computed and assigned in post_generate()
There is no need to generate such fields, and then overriding them with procedural code. Just mark these fields as do-not-generate (using the “!” operator).

• Monitored data items
These fields are assigned procedurally during item collection, using unpack() and other procedural means. By using a simple new statement, you create the data item quickly without any solver overhead.

• Methods return value
I’ve seen cases in which the return value of a method was generated using a single equality constraint. For example, “gen result keeping {it == (my_value == expected_value)};”. Why? A “result = (my_value == expected_value);” gives exactly same outcome with much less overhead.

In the next segment of the series I’ll reveal some performance secrets using the new Sequences API.  Stay tuned …

Efrat Shneydor
Methodology R&D

Reference links to prior posts in this series: 

Part 1 on improving the performance of Lists

Part 2 on memory savings from proper Base types extensions and using CONST fields


Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.