Previous month:
November 2006
Next month:
February 2007

Interviewing with Verilab

Verilab is hiring in the US and Europe.  We're looking for folks who are passionate about verification and are interested in learning new things.  Desire to travel is also a big plus.  If you've ever wondered what type of questions you might encounter in a Verilab interview check out Avidan's description over on Specman Verification.  If someone from Verilab asks you those questions in your interview there's now little excuse to get them wrong!


No Introspection in SystemVerilog

Wow, that didn't take long.  Just a few days in to some work with SystemVerilog and I'm starting to feel like I'm back in SystemC land again.  One of the first things I wanted to do in my small SystemVerilog environment was to print out the data structure that I'm working on.  Sadly, printing an object in SV seems to only print out a list of the actual values of the underlying object, not the overall structure of the object itself.  That means I'll have to write some code (as I did in the past when building something similar in SystemC) to create a sort of super-object which I'll refer to from here on out as a 'blob'.  I'll define a blob as having the following features:

  • Ability to distinguish between fields used to capture data that may eventually be sent to the DUT and other fields used to control randomization, maintain object status, statistics, etc.
  • Allows a user to enumerate through all of the fields in an object and determine their type and pretty name.
  • Using the metadata created in the previous two bullets, implement copy(), clone(), print(), and toString() methods.

Let's face it - verification engineers are busy.  Having to waste time hand coding the same functions over and over again for each new class you write is a real pain and gets in the way of getting real verification work done.  I would be interested to hear why introspection wasn't included in the SystemVerilog specification, and whether it may be included at some point in the future.  Anyone with first hand knowledge care to comment?


Potential Flaws in Cummings' SNUG2002SJ_FIFO2 Design

December 11, 2006 Update: Check out the response from Cliff and additional info from Kevin in the comments section of this post.

Editor's Note: Today special guest Kevin Johnston from Verilab will be joining us to provide an analysis of FIFO designs published by Cliff Cummings for SNUG 2002.  Prior to joining Verilab as a consultant in 2005, Kevin spent 14 years at Motorola/Freescale working on a variety of processor and SoC designs including the PowerPC and 68k.  The following article is his first post on Cool Verification.  Hope you enjoy it! -- JL.


There are two basic async FIFO design styles:

  1. "Pointer-less", also known as "fall-through" type: Fully-asynchronous, self-timed control logic (full-custom or compiled, embedded in the data memory array design) autonomously clocks write data from any current memory location to the subsequent memory location if that subsequent location is empty; the data "falls through" the FIFO from the memory cells connected to the Write port to the memory cells connected to the Read port.
  2. "Pointer based": The data array is a standard dual-port SRAM block; all control logic is external to the memory. A Write Pointer supplies the array address on the Write port, and a separate Read Pointer supplies the array address on the Read port. The data remains in the same memory location for the duration of its residence in the FIFO; the Write Pointer and Read Pointer cycle through the memory address range in identical sequences to retrieve the data in the same order it was entered.

Cliff Cummings has written an excellent general treatment of asynchronous FIFO design in his paper, "Simulation and Synthesis Techniques for Asynchronous FIFO Design" ("FIFO1").

Cliff also wrote a follow-on paper entitled "Simulation and Synthesis Techniques for Asynchronous FIFO Design with Asynchronous Pointer Comparisons" ("FIFO2") describing two major modifications to FIFO1: A different method to detect Full/Empty status, and reduction of two multi-bit synchronizers (for the entire Read and Write pointers) down to two single-bit synchronizers (for just the Full and Empty bits themselves).

FIFO1 and FIFO2 are both pointer-based designs.

I believe FIFO2 has both an implementation flaw and a fundamental conceptual flaw; that is, the implementation flaw can be fixed, but the conceptual flaw cannot.

Continue reading "Potential Flaws in Cummings' SNUG2002SJ_FIFO2 Design" »