//--------------------------------------------------- // // PROJECT VERIPAGE UPDATE // // April 9, 2009 // //--------------------------------------------------- The trees have started to turn green again with the arrival of spring in the northern hemisphere, indicating the beginning of yet another cycle of life. The news from the economic sectors of the world indicates a similar glimmer of hope. As we go through this worldwide crisis of unprecedented scale, let us remind ourselves of the basic principles that always work at times like this: invest in your knowledge now, get your dividend during good time. Project VeriPage has a new tutorial to announce in this issue. Our new article on SystemVerilog Cover Property will enhance your visibility into internals of your design. In this issue: 1. New Article: SystemVerilog Cover Property 2. Can you spot the problem? 3. Book of the Month 4. Are you receiving this from a friend? //--------------------------------------------------- 1. New Article: SystemVerilog Cover Property Tutorial Verification often assumes a black box approach to the design. But what happens to those specific corner cases that are extremely hard, if not downright impossible, to say if they have been covered? There comes SystemVerilog Cover Properties. As always, this and all other articles on Project VeriPage are free. For complete list of articles, please go to: 2. Can you spot the problem? Vera, the hardworking engineer, is in trouble again. Vera is designing a module where there is a 32 bit counter (cntr) that is set to zero when there is a reset (rst), otherwise it increments in every clock (clk). reg [31:0] cntr; always @(posedge clk) if (rst) cntr = 0; else cntr = cntr + 1; There is a separate asynchronous 32 bit bus (dout) in the module that reads this counter when a active low read control signal (rd) is asserted. always @(negedge rd) dout = cntr; Most of the time, reading cntr works just fine. However, sometimes the value dout gets is invalid - it looks like cntr was read while being incremented and some of the bits had the old value, some had the new value. Can you help Vera in fixing the code so that her module works correctly? Tips: (a) You need to know Verilog event scheduling. (b) Send us your answer to info@project-veripage.com. (c) The answer and the name of the person sending the first correct answer will be published in the next issue of this newsletter. Answer to last month's puzzle: 'correct'. Kudos goes to Jonathan Sushansky for sending us the first correct answer. 3. Book of the Month: We select "Hardware Verification With SystemVerilog: An Object-oriented Framework" by Mike Mintz and Robert Ekendahl as our 'Book of the Month'. "This is a fantastic book that not only shows how to use SystemVerilog and Object-Oriented Programming for verification, but also provides practical examples that are open source", writes one reader. You can finger through the book - or if you wish to buy it - from any page of Project VeriPage or simply clicking here: This and many other recent and classic titles on design and verification are available from our book store - all located at your fingertip at: Take a look and remember, books are gifts that last a life time. 4. Are you receiving this from a friend? If you are receiving this newsletter from a friend, you can get your own copy by subscribing at: And do not let your friends who do not receive this newsletter feel left out! Forward this to your colleague and make their day. That's all in this issue. Happy design and verification! - Project VeriPage Team.