Job openings at Cadence Design Systems, India (Bangalore and Noida)

In this tough time, there are some openings at Cadence Design Systems for its India centers (Bangalore and Noida). Please have a look at the openings for more details here.

Verification Engineer required for Cadence Design Systems, Bangalore or Noida

Experience: 4 to 5 years

Location: India, Bangalore or Noida

Job Requirement:

• This engineer’s primary role will be to work in a team oriented environment to deliver digital logic design and verification methodologies, customised design environments and design implementation solutions that align with client goals. He/she will interact and work with other engineers on the worldwide D&V VCAD delivery team.
• Responsibilities will include creating and customising design environments, design and verification methodologies.
• Ideally the canddate should be able to assist with the optimisation of acceleration and emulation technologies using the Cadence Incisive verification flows including the Palladium and Xtreme hardware.
• The engineer must have a solid background in logic design and verification experience with Cadence technology in the digital domain.
• The client should have at least a basic understanding of modeling (e.g. Architecture or system), and both block and system level verification experiance, preferably with coverage driven methodologies.
• The candidate should possess the necessary engineering and consultancy skills, i.e. that he/she is technically mature with the necessary communication skills to be able to consult effectively with clients, e.g. to talk to, coach and advise Customers.
• The engineer must have a solid background in the electronics industry with at least 4 to 5 years experience, and should be willing to learn new technical and consulting skills.

Key Accountabilities:

• Execution on VCAD Customer support projects, e.g. Implementation and functional verification of design systems.
• Development of customer specific verification environments including components, methodology support, operation and maintenance.
• Be prepared to provide design and verification support in VCAD Customer design projects, both remotely and onsite.
• Ability to handle all design environment implementation tasks and architectural tasks with the minimum support or through working in a joint team of Cadence and Customer engineers.
• Work on multi person projects of varying complexity, working especially in a multi-site/multi-cultural project. The latter requires excellent communication skills in English.
• Acquire a basic understanding of the (service) business environment of Cadence within 6 months including pre sales support.

Contact: getjobsinindia2007@gmail.com

DFT Engineer required for Cadence Design Systems, Bangalore

Experience: 3 to 6 Years

Location: Bangalore, India

Skill Sets: Scan, Jtag, Atpg, Tester interface.

Good to have skills: Exposure to ATPG tools like Encounter Test

Job Description:

• This engineer’s primary role will be to work in a team oriented environment to deliver DFT activities for implementation services. He/she will interact and work with other engineers on the worldwide delivery team.
• This engineer is expected to provide services using the following technical skills: Scan, JTAG, ATPG, Logic Synthesis, Static Timing Analysis, and to interface with designers / testing team.
• In addition to the technical skills they will be expected to operate effectively in project teams delivering the design of leading edge. Additional responsibilities include customer interactions and pre-sales activities.

Key Accountabilities:

• Ability to handle all design environment implementation tasks assigned, either personally or through supervising other Cadence and Customer engineers.
• Work on multi person projects of varying complexity, working especially in a multi-site/multi-cultural project. The latter requires excellent communication skills in English.
• Acquire a basic understanding of the (service) business environment of Cadence including pre sales support.

Contact: getjobsinindia2007@gmail.com

OVM 2.0 Webinar on 16th Oct, 2008

There is a OVM 2.0 Webinar organized on 16th Oct, 2008.

Details of webinar is mentioned below.

Date : Thursday, October 16th, 2008
Time : 10:00 AM - 11:00 AM (Pacific Daylight Time)
Location : Online via Microsoft Office Live Meeting (details provided upon registration)

For more information and registration, please click here.

OVM 2.0 update contains some technical advances. Few of are listed bellow

• Unified sequence mechanism
• OVM User Guide
• Improved debugging and expanded use of parametrized classes
• Driver/sequencer communication enhancements

IEEE Working Group Announces Updated e Language Standard

The e Functional Verification Language Working Group (eWG) was formed to define a standard for the e language, and the initial 1647-2006 standard was published in September 2006. And now, IEEE has approved a revision to IEEE 1647, Standard for the Functional Verification Language e. This revision is called 1647-2008 e Language Standard

Please see following link for more details.
http://standards.ieee.org/announcements/IEEE1647_eLanguageStandard.html

OVM Seminars at Hyderabad and Bangalore

There is an OVM semniar held at Hyderabad on Thursday, March 25, 2008 between 8:30 am to 2:30 pm (IST) and at Bangalore on Thursday, March 27, 2008 between 8:30 am to 2:30 pm (IST).

For registeration, please visit http://www.ovmworld.org/seminars.php

Here are the topics covered in the seminar.

OVM Overview

• Planning for Verification
• Testbench Architecture
• Transaction-Level Modeling (TLM) in Verification

Stimulus and Coverage

• Transaction-Level Stimulus
• Decoupling Stimulus from the Design
• Sequential Stimulus Specification
• Layered Stimulus
• Transaction-Level Layered Coverage

Planning for Verification Reuse

• Flexible Instantiation – Using the Factory
• Configuring Verification Components for Reuse
• Hierarchical Encapsulation & Reuse

Putting it All Together

• OVM Moving Forward

About generation of do-not-generate fields

Say a parent struct is having two fields inside it. One is an ungenerated (with do-not-generate sign) child struct and another ungenerated field is of pre defined data types (like uint, bool etc.).

When this parent struct is generated

1) ungenerated field of pre defined data types will get their initial value (0 for scalars, NULL for structs, empty list for lists).

2) ungenerated field whose value is a range (such as [0..100]) gets the first value in the range.

3) ungenerated field of user defined data types (like sturcts) will not be allocated and none of the fields in it will be generated.

Take a look at following code.

<'

struct child_s

{

!a : uint (bits: 4);

b : uint (bits: 4);

};

struct top_s

{

!child : child_s;

!x : uint (bits: 3);

!y : uint (bits: 3);

keep x in [2..5];

};

extend sys

{

top : top_s;

};

'>

In this example, top_s struct has one ungenerated struct and two ungenerated fields of uint (bits: 3). When top is generated inside the sys

1) y will be generated and will get any random value between 0 and 7

2) x will be generated with value of 2 as it is a range bound ungenerated field.

3) child field will not be generated as it is defined as ungenerated struct. So, the fields a and b of child struct will not be generated as well.

By default MAIN sequence is not empty

By default, body method of MAIN sequence is not empty. It contains a loop which executes random number of times creating the sequence field (randomly unless constrained). The generated/created driver contains an instance of the MAIN sequence, which is started automatically upon run().

So, in your environment, if body method of MAIN sequence of any eVC is not made empty, it will start executing some random sequences at 0 simulation time. This might have adverse effect on the behavior of the stimulus given to the design if you are using virtual sequence, because user defined sequence (executed inside virutal sequence) and MAIN sequence might be running parallely and might be driving same signals and causing undesirable stimulus.

Debugging this will become difficult. You might be wondering why some other sequences are being executed even though you are calling perticular sequence only in virtual sequence?

So, if you are an eVC developer, always provide sequence library with body of MAIN sequence made empty. And if you are verifying any DUT and if you are using virtual sequence and not using MAIN sequence of any eVC, make body method of all MAIN sequences empty.

Take a look at this e code to check that how MAIN sequence is executing a loop which creates and executes the random sequence. Load this e code and give test command with random seed. You will see that even though body method of MAIN sequence is not extended, MAIN sequence is executing random sequneces (TEST1, TEST2, SIMPLE).

OVM available on its new site

Open Verification Methodology (OVM) is now available on its new site http://www.ovmworld.org

Checker implementation dilema

Ever encountered the checker implementation dilemma? How to implement it? Using temporal expressions or using methods? Once in a lifetime, every verification engineer comes to a stage where they have to take decision about the implementation of a checker. Once, I made a wrong decision and implemented a complex event-based checker in temporal expressions using "expect" statement. After that I was introduced to the hell of debugging temporal expressions in Specman. Event chart is a junk feature in the Specman. Filtering of the events, having full path of the events are not so easy to see in the events chart. Even, when-subtypes' events can not be viewed separately.

After having a lot of trouble debugging temporal expressions, I re-wrote the entire checker in the methods format using "check that" and "if else" construct. Debugging of method based checker is such an easy task in Specman, as Specman has a beautiful and reliable debugger. Lot of features, though might be basic, are quiet useful when it comes to debug the method based checkers. In Specman debugger, one can put conditional and unconditional breakpoints, can see the hierarchy of the threads, can add watch points on e fields and a lot more. I will discuss about debugging in Specman for the beginners in the separate post.

After that experience, I concluded following things for the checker implementation.

1. Write down the checker in the simple english to understand its complexity.
2. If checker is simple, I mean, just contains 2 to 3 basic events to check, then go for temporal expressions for the checker implementation.
3. If checker is even a bit complex having more than 3 events, just go for the method based checker implementation. You will save a hell lot of time which might be lost in the debugging temporal expressions.

Method based checker implementation looks more readable, even though it requires extra codes to implement and it's a bit slower than temporal expressions based checkers. But at the end, you are going to save lot of time having clean checker.

Specman Verification Questions - Part III

Question 1: What will be the output if following code is loaded and test command is issued into Specman ?

<'

struct x

{

y : uint;

keep soft y == 8;

};

extend sys

{

run() is also

{

var x : x;

gen x;

var a : uint = 2;

outf ("a = %d x.y = %d\n", a, x.y);

update_field(a);

update_struct(x);

outf ("a = %d x.y = %d\n", a, x.y);

};

update_field(a: uint) is

{

a = 4;

};

update_struct(x: x) is

{

x.y = 4;

};

};

'>

Answer:

a = 2 x.y = 8

a = 2 x.y = 4

Here, variable uint a is not updated and struct x is updated. Why is so? Because in specman, unlike user defined data types (e.g. structs, units), all variables with standard data types are passed by value in the methods. All user defined data types (like structs) are passed by reference. So, whenever, called methods update the passed structs, it is actually updating the original struct and not its copy.

If one wants user defined data types to be passed by value then he/she can use deep_copy to copy the existing variable and pass it to the method as shown below.

<'

struct x

{

y : uint;

keep soft y == 8;

};

extend sys

{

run() is also

{

var x : x;

gen x;

var a : uint = 2;

outf ("a = %d x.y = %d\n", a, x.y);

update_field(a);

update_struct(deep_copy(x));

outf ("a = %d x.y = %d\n", a, x.y);

};

update_field(a: uint) is

{

a = 4;

};

update_struct(x: x) is

{

x.y = 4;

};

};

'>

Question 2: What is the difference between inheritance implemented by "when" construct and implemented by "like" construct?

Answer:

like inheritance is the concept of the object oriented programming (OOP) where as when inheritance is the concept of aspect oriented programming (AOP). For more detail on AOP, please refer Aspect-Oriented Programming with the e Verification Language book written by David Robinson (Verilab).

like construct is used when someone wants to derive a child object from the already defined struct/unit. This derived child will have new struct/unit name. When someone derive the child object using when construct, the base name of the child will remain the same.

Another difference between like and when construct is that, once the child is derived using like inheritance, one can not add extra fields in the parent struct/unit, wherease, if child is derived using when construct, parent struct/unit can have extra fields.

Take a look at the following example. packet_valid field is added in the parent struct packet_s after the child is derived using like inheritance. This is not allowed and Specman will issue an error during loading phase.

<'

type packet_type_t : [GOOD, BAD, UGLY];

struct packet_s

{

kind : packet_type_t;

};

struct good_packet_s like packet_s

{

packet_size : uint (bits: 5);

};

extend packet_s

{

packet_valid : bool;

ack() is

{

outf ("NOTE :: This is packet %s\n", me);

};

};

extend sys

{

packet : packet_s;

good_packet : good_packet_s;

};

'>

Specman will issue following error.

*** Error: Cannot add new field 'packet_valid' to struct 'packet_s': it has like children (e.g. 'good_packet_s') with fields.

Note that ack() method will be added in the parent struct packet_s even though child is derived using like inheritance.