Home > Community > Blogs > Functional Verification > when less is more part 3 is e code really infinitely more compact than systemverilog
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

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: *

When Less Is More, Part 3: Is e code really “infinitely” more compact than SystemVerilog?

Comments(0)Filed under: Functional Verification, SystemVerilog, e, Specman, IEEE 1647, OOP, Aspect Oriented Programming, AOP, Object Oriented Programming, IES-XL

Building on the packet generation example of part 1, and the coverage examples of part 2 that compare the ratio of lines e code to lines of SystemVerilog for a given task, in this post I’m going to show you how to “divide by 0” and leverage e capabilities that simply don’t exist in SystemVerilog, technically making e infinitely more capable (pardon the pun – couldn’t resist).

From the beginning, the e language was designed to be Aspect Oriented, which in a nutshell is a Lego like superset of the more common Object-Oriented programming paradigm that allows you to extend, and even overwrite the functionality of a block of code WITHOUT having to modify the base code in any way.  Clearly this capability is perfect for verification, given that verification is essentially open ended -- you can always dream up some new test to write, or some new corner case to explore (vs. the task of design, which has a finite endpoint – tapeout.)

In previous Team Specman posts my colleagues have touched upon the capabilities of AOP, and there are excellent books that go into AOP in depth.  The point being made in this post is to show how e with AOP gives the user some really powerful benefits that are unavailable in any other IEEE standard language.  Consider the following examples build on the packet generator code of parts 1 & 2.

Let's say that a new feature was added late in the project cycle that required packets with their type field set to TYPE_A to have an additional cyclical recovery check (CRC) field added to the packet.  TYPE_B packets are unaffected by this new feature.  In e, the code to create this new feature would be as follows:

extend TYPE_A packet_s {
   crc: byte;

All packets randomly generated to have their type field set to TYPE_A in the environment would automatically be updated to contain the new field.  Lists of packets can still randomly contain a mix of TYPE_A and TYPE_B packets (very important as the DUT supports both packet types) and all copy, randomization, packing/unpacking methods performed on the packet would automatically be adjusted.  The change would automatically be propagated to all objects that use the packet_s struct. 

If a larger new feature were added to the project, such as the introduction of a newly supported packet type altogether (TYPE_C), this is easily introduced into the flow using the following syntax:

extend packet_type_t: [TYPE_C];
extend TYPE_C packet_s {
   // add new functionality

Again, all locations within the environment that use the packet_s struct will be automatically updated to allow for this new type.  There are simply no capabilities within either the SystemVerilog language or the OVM SystemVerilog class library to support this level of flexibility and control.  Creating something similar in SystemVerilog would be extremely difficult (not to mention tremendously tedious) as this packet can be used in many locations within the verification environment (BFMs, Monitors, Sequencers, Scoreboards, etc., etc.)

Finally, it’s important to note that the examples in this series have not been artificially manufactured to unfairly highlight the code reduction that’s possible with e.  These are all simple examples of very common tasks that would be implemented in any verification environment.  We could easily provide dozens of more examples where the e language results in code reductions for other common tasks – we welcome you to share some of your favorites!

Happy coding!

Corey Goss
Staff Solutions Engineer
Team Specman

. Don't forget to join us for a 1 hour Specman-SimVision webinar next week, April 22 at 10:00AM Pacific time.  In short, if you’ve been using Specview with Specman/e and would like to learn all the key advantages of using the SimVision debug tool, this webinar is for you!

Sign Up Today! http://www.secure-register.net/cadence/q2_10_webinars_verification

More background info on the webinar here: http://www.cadence.com/Community/blogs/fv/archive/2010/04/13/specman-simvision-webinar-on-april-22-next-week.aspx


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.