Update on IEEE 1800-2009 standard, fresh from the oven!

As you all may know by now, IEEE 1800-2009 was recently approved.
There were many updates in SystemVerilog core, the Assertions, and the addition of the checker, a new type of entity where several assertions and verification code can be defined just like a module/interface. In addition the checker can be inlined procedurally unlike a module.

Immediate next step will be to get real users exposed to the power of new constructs. We would expect tool vendors to start adopting this new version, probably sooner than we may think as some vendors were actively implementing the new features as the LRM was being refined. Now atleast 2 major EDA vendors have released support for varying sets of constructs from this new LRM. Ping your EDA support for updates!

As far as book support, we're please to announce the release of our SystemVerilog Assertions Handbook, 2nd Edition that includes the IEEE 1800-2009 updates.
For more information, see http://systemverilog.us/sva2_toc_preface.pdf
http://systemverilog.us/sva_handbook2_cover.jpg

SystemVerilog Assertions Handbook, 2nd Edition is an excellent reference for learning the basics of the assertion language. Syntax summaries along side examples help in learning the syntax. There are many examples with graphical representations that demonstrate the concepts. Basic rules are listed, often with quotes from the standard, and then explained. The book goes beyond the standard to demonstrate many subtleties that produce unexpected results and poor performance, and flags the pitfalls to avoid. It is a great refresher for experienced users and for those looking to understand what is new in the SVA language for the IEEE 1800-2009 release. Additional chapters present methodology and application perspectives. This book is co-authored by:
Ben Cohen, Srinivasan Venkataramanan, Ajeetha Kumari, and Lisa Piper

Training on “Protocol Verification using SystemVerilog Assertions”

 

December is usually the time of holidays, relatively work load etc. Given the challenging job scenario this is also the best time to hone your skills and face the New Year with new skills, explore new job avenues, segments etc.

CVC is announcing a week long certificate course on standard protocol verification. At the end of this course you would have finished developing a MIP (Monitor IP) for a standard protocol based on SVA. Assertions are very powerful to capture temporal behavior. Broadly it covers the following topics:

• ABV Introduction
• SystemVerilog Assertions (SVA)
• Project – develop a real life Protocol Monitor IP (MIP) with SVA

Course contents:  http://www.cvcblr.com/trng_profiles/CVC_LG_SVA_profile.pdf

Topic	Duration
SystemVerilog Assertions	2.0 days
Project	3.0 days

Schedule

Tentative: 2^nd week of December, 2009

For exact schedule visit http://www.cvcblr.com/blog/ or contact us.

Contact

Send an email to: training@cvcblr.com and/or cvc.training@gmail.com for more details, cost etc. Or call us at: +91-9620209226/+91-80-42134156

Please include the following details in your email:

Name:

Company Name:

Contact Email ID:

Contact Number:

Make best use of your Dec holidays: Verification Fest (VFest)

 

December is usually the time of holidays, relatively work load etc. Given the challenging job scenario this is also the best time to hone your skills and face the New Year with new skills, explore new job avenues, segments etc.

CVC is launching its highly successful 2 weeks certificate course on Functional Verification using SystemVerilog with a project in one of the following domains.

· Networking

· Communication

· Image Processing

VFest also focuses the language aspect SV in depth. Broadly it covers the following topics:

• SystemVerilog basics (SVB) http://www.cvcblr.com/trng_profiles/CVC_LG_SVD_profile.pdf
• Verification Using SystemVerilog (VSV) http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf
• Verification Methodology (VM)

Duration

Topic	Duration
SystemVerilog Basics	0.5 day
Verification using SystemVerilog	2.5 days
Mini Project	2.0 days
Verification Methodology	2.0 days
Project	3.0 days

Schedule

Tentative: 1^st week of December, 2009

For exact schedule visit http://www.cvcblr.com/blog/ or contact us.

Contact

Send an email to: training@cvcblr.com and/or cvc.training@gmail.com for more details, cost etc. Or call us at: +91-9620209226/+91-80-42134156

Please include the following details in your email:

Name:

Company Name:

Contact Email ID:

Contact Number:

SystemVerilog tip: watch out enum and randc

Recently an interesting question was raised by SystemVerilog user on randc usage with enum. To illustrate, consider the following code:

[cpp]
typedef enum {red, green, blue, yellow, white} house_color_type;
class c;
randc house_color_type enum_0;
[/cpp]

Spot anything wrong above? Perhaps not? As it goes with randc an implementation needs to remember all values generated so far before recycling! So it does consume extra memory. SV LRM says:

To reduce memory requirements, implementations may impose a limit on the maximum size of a randc
variable, but it shall be no less than 8 bits.

By default an enum is an int – i.e. 32-bits, hence allowing a randc on it blindly is a real challenge for tools – though some advanced tools/versions (Questa 6.5a for instance) allows it. But this default int choice is not something I like so much – it should have been cleverer to choose appropriate sized of vector by the implementation, did we not know LRM committee is often biased by implementers. No pun intended, but just MHO.

Anyway coming back to the question, a very useful tip here (like “Moral of the story is..” – something that’s day-to-day phrase in a typical school boy father’s life , something that I thoroughly enjoy, thanks to my Anirudh Pradyumnan): Model your enum size while declaring it. As in:

[cpp]

typedef enum {red, green, blue, yellow, white} house_color_type;

typedef enum bit [2:0] {red, green, blue, yellow, white} house_color_type_BETTER;

[/cpp]

ASIC Design Verification for FPGA designers

 

…Step upto ASIC world with SystemVerilog, Assertions & Testbench

CVC (www.

Technorati Tags: trainings

cvcblr.com) is announcing a new session of its 10-day course on “FPGA-2-ASIC_DV-with SystemVerilog” - a step-by-step approach to introduce modern day Design & Verification challenges & solutions for FPGA designers. It is structured as follows:

• Basic Session
  • Comprehensive Functional Verification (CFV)
  • SystemVerilog basics (SVB)
• Advanced Session
  • ABV Introduction
  • SystemVerilog Assertions (SVA)
  • Project – develop a real life Protocol IP (PIP) with SVA
  • Verification Using SystemVerilog (VSV)

Course contents: 

http://www.cvcblr.com/trng_profiles/CVC_LG_SVA_profile.pdf

http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf

Topic	Duration
Comprehensive Functional Verification (including UNIX usage, EDA tools)	1.5 days
SystemVerilog basics	1 day
Project	0.5 days
SystemVerilog Assertions	2 days
SystemVerilog Testbench	2 days
Project	3.0 days

All the course contents, agenda can be found at http://www.cvcblr.com/program_offering. It is meticulously prepared with the common expertise of FPGA designers in mind. Having transformed several FPGA designers into ASIC Design-Verification engineers at CVC we fully understand the challenges involved, skills needed etc. The course is structured in a balanced manner with theory and lab sessions tightly embedded in a manner that helps in mastering topics learned so far in the course.

Schedule:

Dec 1^st week at Bangalore

To attend this class, confirm your registration by sending an email to training@cvcblr.com

Ph: +91-9620209226, +91-80-42134156

Please include the following details in your email:

Name:

Company Name:

Contact Email ID:

Contact Number:

SV: implication constraint and its implication/effect

SystemVerilog has a nice implication constraint feature to guard constraint expressions on their applicability. Last week during our SystemVerilog + methodology workshop one of the attendees faced an interesting issue. She was creating a min-VIP for APB as part of our SystemVerilog 10-day workshop (See details at: http://www.cvcblr.com/trng_profiles/CVC_VSV_WK_profile.pdf ).

She wrote a APB scenario code that was intended to create a sequence of transactions with varying address, kind etc. Here is a code snippet:

constraint cst_xactn_kind{
       if(this.scenario_kind == this.sc_id)
       this.length == 10;
       foreach (items[i])
        {
          (i==0) -> items[i].apb_op_kind == APB_WR;items[i].addr == 'b01; items[i].wdata == 'd11;

               (i==1) -> items[i].apb_op_kind == APB_WR;items[i].addr == 'b11; items[i].wdata == 'd12;
                       }
     }

Spot anything wrong in the above code? Perhaps not for the unsuspecting, bare eyes. Code intention: Keep the:

0th transaction KIND == WRITE, address == 01, data == 11;

1st transaction KIND == WRITE, address == 3, data == 12;

Read again the code – it seems to imply just that, isn’t it? Let’s run it.

Here is what Questa says:

###########################################################################                    
#                     WELCOME !!!
#                      APB PROJECT USING VMM
#                     DONE BY PRIYA @ CVC
#                     DATE:21stOctober2009
############################################################################
# Normal[NOTE] on APB_PROGRAM(0) at                    0:
#     APB PROJECT:       Start of APB Random test!    
# ****************************************************************************
# Normal[NOTE] on APB_ENV(0) at              0.00 ns:
#     APB PROJECT: Sim shall run for 10 number of transactions
# Normal[NOTE] on APB_ENV(0) at              0.00 ns:
#                     Reset!!!!!!!!!               
# Normal[NOTE] on APB_ENV(0) at            230.00 ns:
#                    Reset Release!
# ****************************************************************************
# *FATAL*[FAILURE] on APB Generator Scenario Generator(APB_GENERATOR) at            730.00 ns:
#     Cannot randomize scenario descriptor #0

Puzzled? What is wrong? Review by the code author herself few times didn’t reveal anything wrong (bias towards own code?).

Seek expert assistance.. Questa has a simple flag to bring up solver debugger as: vsim –solvefaildebug Let’s try that now..

 

# ../tb_src_scenario/apb_scenario_gen.sv(1): randomize() failed due to conflicts between the following constraints:
#     ../tb_src_scenario/apb_scenario_gen.sv(25): the_scenario.cst_xactn_kind { (the_scenario.items[0].addr == 32'h00000001); }
#     ../tb_src_scenario/apb_scenario_gen.sv(1): the_scenario.repetition { (the_scenario.repeated == 32'h00000000); }
#     ../tb_src_scenario/apb_scenario_gen.sv(25): the_scenario.cst_xactn_kind { (the_scenario.items[0].apb_op_kind == APB_WR); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[0].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[0].wdata == 32'h0000000c); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[1].apb_op_kind == APB_WR); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[1].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[1].wdata == 32'h0000000c); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[2].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[2].wdata == 32'h0000000c); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[3].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[3].wdata == 32'h0000000c); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[4].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[4].wdata == 32'h0000000c); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[5].addr == 32'h00000003); }
#     ../tb_src_scenario/apb_scenario_gen.sv(26): the_scenario.cst_xactn_kind { (the_scenario.items[5].wdata == 32'h0000000c); }

Smell something wrong? Why is the constraint on addr, data getting applied across scenario items 2,3,4,5 etc.? Beyond the 0, 1 that the “implication” supposed to guard it? Relook at constraint code:

          (i==0) -> items[i].apb_op_kind == APB_WR;items[i].addr == 'b01; items[i].wdata == 'd11;

Found it? Not yet? The devil lies in details – here in that SEMICOLON “ ; “. A semicolon in Verilog/SV denotes END of a statement and begin of the next one. Hence the effect of “implication” is ENDED with the variable “kind” alone here – thereby it doesn’t affect the addr, data – hence the implication is invisible to them. At line 25, the addr == 1; At line 26, addr == 3; Hence the contradiction!

The fix will be to use && to imply that the guard is applicable to all the 3 variables – kind && addr && data.

  Instead of:

(i==0) -> items[i].apb_op_kind == APB_WR;items[i].addr == 'b01; items[i].wdata == 'd11;

Use:

   (i==0) –> (items[i].apb_op_kind == APB_WR) && (items[i].addr == 'b01) && (items[i].wdata == 'd11);

Morale of the debug session is: you need to be careful while using implication constraints for more than single variable :-)