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

Title: CFV + SystemVerilog basics
Location: www.cvcblr.com
Link out: Click here
Description: SystemVerilog basics.

Look at SVB portion from this profile:

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

This is intended mainly for FPGA designers, so the focus will be building fundamentals than building complex OOP testbench.
Start Date: 2009-12-8
End Date: 2009-12-9

Title: Verification Using SystemVerilog (VSV)
Location: www.cvcblr.com
Link out: Click here
Description: Our popular corporate training on SystemVerilog for Verification. Details at:

http://www.cvcblr.com/trng_profiles/CVC_LG_VSV_profile.pdf
Start Date: 2009-12-5
End Date: 2009-12-7

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]