One particular statement in the Mentor paper caught my eye: "this model can still generate false errors: the waveforms show that input sequence A, B, C, D, E, F can result in output sequence A, B, E, E, E, where two consecutive inputs, C and D, are skipped". And this statement bothered me: I had spent a long time figuring out Mark’s model some while back, and while it was not at all intuitive to me, I did convince myself that it could never generate a simulated output sequence that was impossible in real hardware. So if the Mentor paper was correct, then I had missed something about Mark’s model, and I’ll be honest, I didn’t relish going back and studying it again.

Obviously I was just going to have to find a mistake in the Mentor paper instead. And to my considerable relief, I did. In fact, I found two:

1. The schematic (Fig 8, p.9) of Mark’s synchronizer model is missing a small but important feature.
2. The waveform (Fig 9, p.9) of data signal values input to the model is a somewhat misleading representation of an async input.

In the Mentor paper, the select inputs to both muxes are simply "$random()". In Mark’s original model (Fig 11, p.5), the select input of the input mux is indeed just "$random()", but the select input of the output mux is "@(m2 or m3) $random()".

The result of the modified select term is to make the "A,B,E,E,E" behavior impossible except under specific conditions. But under the right conditions, it is indeed a possible behavior in hardware.

The waveform of the d input signal in Fig 9 of the Mentor paper gives a false impression that d is actually synchronous, rather than asynchronous, to the sampling clock clk. The stability of a transitioning async input cannot be inferred forward or backward from the sampling clock. If two consecutive samples are not equal, it is unknown when the transition occurred - it is only known that a transition occurred. So if the sampled values B, C, D, E in simulation were 0, 1, 1, 0, it is entirely possible for hardware to exhibit the output sequence 0, 0, 0, 0.

The fact that samples C and D were both 1 in simulation does not mean that d was stable for two complete clk periods, as implied in Fig 9: The 0->1 transition B->C could have occurred momentarily before the C sampling clock edge, and the 1->0 transition D->E could have occurred momentarily after the D sampling clock edge. And if both transitions violated the sampling setup/hold window, then the metastability could settle to the B value at the C clock edge, and the E value at the D clock edge.

Consider the following:

class FooDataClass;
   integer D1;
   integer D2;
endclass

struct {
   integer D1;
   integer D2;
} FooDataStruct;

program test;
   FooDataClass  X[]  = new[5]; // array of classes
   FooDataClass  Y[];           // array of classes
   FooDataStruct A[]  = new[5]; // array of structs
   FooDataStruct B[];           // array of structs
   ...
   Y = X; // copy array of classes
   B = A; // copy array of structs
   ...
endprogram

In the case of the struct, it’s possible to copy the dynamic array A[] to B[], sizing B to the same as A automatically. It’s equivalent to:

B = new[A.size()];
foreach(A[i]) begin
   B[i].D1 = A[i].D1; // copy value of A[i].D1 to B[i].D1
   B[i].D2 = A[i].D2; // copy value of A[i].D2 to B[i].D2
end

Importantly, B[] has it’s very own copy of the values of variables D1 and D2 for each element in the array. So, if A[2].D1 was modified, B[2].D1 would not be.

In the case of the class, when we copy the dynamic array X[] to Y[], Y is still sized to the same as X automatically, but something subtly different happens (that often catches people out), with D1 and D2. When arrays of classes are copied, the references (aka handles) to the class are copied, not the values of the class members themselves. It’s equivalent to:

Y = new[X.size()];
foreach(X[i]) begin
   Y[i] = X[i]; // copy reference to class X[i] into Y[i]
end

This means that Y[] does not have its own copy of the values of variables D1 and D2 for each element in the array. If X[2].D1 was modified Y[2].D1 would also be modified. In fact they are the same variable, pointed to by the reference Y[2], which is equal to X[2]. That’s, most often times, not the desired behavior of the code. Coding errors like this can be tricky to track down and may stay hidden for some time.

Once you’ve created a class, people might start using it all over the place. People, who might not have access to modify your class code, only use it. This has an impact on the above mentioned difference between classes and structs. If you want to enable people to make copies of the data values, as opposed to just the references, then you (as the developer of the class), should provide a mechanism to “deep copy” the class. So with FooDataClass we might do:

function void FooDataClass::copy(FooDataClass c);
   this.D1 = c.D1;
   this.D2 = c.D2;
endfunction

Here we copy the values of another class of the same type into our class. It is now possible to make Y[] have its very own copy of the values of variables D1 and D2 for each element in the array. So, if X[2].D1 was modified, Y[2].D1 would not be. However, we still have to do something different for classes than we do for structs. Something like:

// copy of values of values in X[] to Y[]
foreach(X[i]) begin
   Y[i] = new;   // create new instance of the class
   Y[i].copy(X[i]); // copies *values* in class from X to Y
end

So, when you are reviewing code, it’s always prudent to look for places where classes or things containing classes are explicitly or implicitly copied.

Separately, John is compiling a list of DFT related links. If you’ve got some good ones to share head on over to his DFT Bookcase and or his DFT Forum and let him know!

I just got the stats for the fall 2007 meetings. 480 registered in total, 280 attended. Of the people surveyed (nearly everyone that attended the 5 meetings), 60% were using SystemVerilog today. Verification did pretty well out of that, with 67% of the share. Design got 10% and 23% said they used SystemVerilog for both design and verification. From a verification point of view another interesting stat was that 33% of the verification slice, were using the advanced testbench features of the language, and 32% were using SVA. It’s nice to see that more people are starting to use the HVL portion of the language for verification, not just writing assertions. I think this is due in no small to much better tool support and stability by all the vendors.

The growing attendance numbers of the SVUG meetings is a reflection of the interest and uptake of SystemVerilog by the design/verification community. I’m seeing an increase in our client projects using SystemVerilog Verification IP, and finding ways to hook SystemVerilog into their verification environments. Finally, it’s really beginning to feel like SystemVerilog is starting to make a bit of an impact.

///////////
// enum.sv
///////////
class cmd;
  // My enumerated type 
  typedef enum {UNKNOWN, ADD, SUB, MULT} cmd_e;
  
  // Store the string -> enumerated type mappings.
  static cmd_e enum_map[string];
  
  // Configure the mapping from string to enum the first
  // time this data structure is created.
  virtual function void config_enum_map();
     cmd_e e;
      
     string str;
     e = e.first();
     str = e.name();
     enum_map[str] = e;

     // Note - we've already processed the first element above. This loop
     // starts at the *second* element.
     for (int i = 1; i < e.num(); i++) begin 
        e = e.next();
        str = e.name(); 
        enum_map[str] = e;
     end

     foreach (enum_map[m]) begin
        $display("enum_map[%5s] = %5s (%1d)", m, enum_map[m].name(), enum_map[m]);
     end

  endfunction: config_enum_map

  function cmd_e get_enum(string s);
     get_enum = enum_map[s];
  endfunction

  function new();
     if (enum_map.num() == 0) begin
        config_enum_map();
     end
  endfunction: new

endclass: cmd

program test;
  initial begin
     cmd   c = new;
     cmd::cmd_e ce;

     string s = "ADD";
     ce = c.get_enum(s);
     $display("Enum = %s (%1d) for string %s", ce.name, ce, s);

  end

endprogram

In VCS, run the above code using ‘vcsi -sverilog -ntb_opts dtm -R enum.sv’ to see the following output:

Compiler version VCSi Y-2006.06-SP1; Runtime version VCSi Y-2006.06-SP1;  Oct 21 14:43 2007 

enum_map[ADD] = ADD (1)
enum_map[MULT] = MULT (3)
enum_map[SUB] = SUB (2)
enum_map[UNKNOWN] = UNKNOWN (0)
Enum = ADD (1) for string ADD
           V C S   S i m u l a t i o n   R e p o r t 

This morning (well, morning to me in the US, afternoon to him in one of our European offices) one of the team asked an emacs question on our lively, internal, intercontinental, questions-answered-almost-before-they-are-asked forum. Specifically, he wanted to know how to change this:

 a0_af0_high = a0_af0_high.get_write_data();
    a0_af0_low = a0_af0_low.get_write_data();
    a1_af0_high = a1_af0_high.get_write_data();
    a1_af0_low = a1_af0_low.get_write_data();
    a0_af1_high = a0_af1_high.get_write_data();
    a0_af1_low = a0_af1_low.get_write_data();

into this:

a0_af0_high   = a0_af0_high.get_write_data();
a0_af0_low    = a0_af0_low.get_write_data();
a1_af0_high   = a1_af0_high.get_write_data();
a1_af0_low    = a1_af0_low.get_write_data();
a0_af1_high   = a0_af1_high.get_write_data();
a0_af1_low    = a0_af1_low.get_write_data();

Such a simple problem, so many interesting comments and answers.

First, why is he even bothering about this? Who cares if the code is pretty? Answer - everyone with any sense. The most important reader of code is not the simulator but the next human who has to read it - including the author, three months from now. So, within reason, anything that can be done to improve readability is worthwhile. It is a constant mantra at Verilab that “Verification Engineering Is Software Engineering” and this is just one example of that in practice. Yes, it matters that you correct for metastability between clock domains; yes it’s important that if you gate clocks, you do it in a safe way; yes, it’s important that if you want a synchronous match flag to assert on the same clock edge that created the match you know which side of the relevant register’s flip-flops to look at. But on top of that, it’s important you code it right. Verification Engineering Is Software Engineering.

Next - why wasn’t he using an emacs major editing mode, which probably would have done all this for him. The well-known offering by the inestimable “Mac” was a good choice in my day. Well, turns out he *is* using the mode, it is Mac’s version, and, ahem, it’s not yet up to the task. Cue flurry of lisp hacking by Mac :-).

OK, so next - what’s the answer to the original question? Well, I came up with a simple two-stage approach. First, align the line-starts using “M-x kill-rectangle”. And then use the highly cool “M-x align-regexp” to align around those “=” signs. In emacs, as in Perl, there’s more than one way to do it. But those work.

And finally - how did I manage to figure this out? I mean, half an hour ago I didn’t know about align-regexp, I just sensed it would be out there. Why? Simple - I have had so much past exposure to emacs that I knew that someone just had to have done this before, so it was worth a search. And that raises a useful parting shot, still in the vein of “Verification Engineering Is Software Engineering”. One of the advantages of having a software view of verification (and, to some extent, design) is the tension it creates between the way much verification code is and the way it could be. The mature software mind has a language (perhaps some subtle combination of all the languages the individual concerned has seen, which is why learning languages is useful) in which to think about problems and in which to propose solutions. The whole notion of design patterns is an example of this in action. This is in contrast with the mind which sees the world only in terms of electronics. In that case, sometimes it’s impossible for the engineer even to articulate a problem to themselves, let alone posit an answer. It’s like an English speaker who has had no exposure to German (or to the 1727 edition of the “Universal Etymological English Dictionary”) trying to conceptualize “schadenfreude“. The software mind may have to tolerate for some time tangled code, tools that don’t respect each other and regression environments with more scope for bugs than the design itself. But the fact that it knows There Is A Better Way eventually has a positive impact. It is pretty much a universal experience of Verilab’s engagements with our clients that we start off working inside the client’s existing infrastructure, helping them solve their immediate problems in their chosen way, only to find, a few months down the road, client engineering managers peering over our shoulders saying, “Gosh, how cool is that; could you show everyone else how that works so we can roll it out across the whole team?”

In a testbench different parts are likely to be reused in different ways. Standard interfaces are the number one candidates for reuse in the pure sense of the term; it is quite probable that they will be plugged in as is into an altogether different project later on. Data generators (i.e. an Ethernet packet generator), base class libraries and generic packages (register package) follow close. In fact, if you’re lucky enough, you will probably be reusing someone else’s code yourself.

As a rule of thumb, any part in your testbench that is tied to more than one DUT interface will probably remain attached to the same DUT for the rest of its life. Scoreboards, multi-interface sequences (”virtual sequences”) and some coverage collectors are good examples. Such code should be written with system level reuse in mind, but trying to write it for plug and play reuse with another DUT is, in most cases, a waste of time. Other parts of your testbench that are likely to be reused only on system level are coverage of DUT configuration or state machines, signal maps (connection of DUT signals to testbench signals) and the verification environment top file that normally does all the internal interconnect (i.e. connect a scoreboard to the BFMs ports). Since these parts will go together everywhere, they can, for example, rely on the fact that other parts exist. This means, that decoupling issues can be relaxed a little bit: For example, if a scoreboard refers to some public DUT specific configuration member by name, I wouldn’t consider it a crime. If a code for standard interface does something similar, that’s another thing.

Finally, in most testbenches there exist some limited parts that are not going to be reused at all. For example, in a module level testbench you usually have a part that instantiates the DUT and the corresponding verification environment and connects the two together. Obviously, this will not be required anywhere else.

As an example consider the following, over simplified and partly abridged, testbench for a serial to parallel DUT. The serial to parallel can convert words of up to 32 serial bits into one parallel word. The size configuration parameter can be used to determine how many serial bits are grouped into one parallel word.

// *** reused in another project

// monitors know nobody else
class serial_monitor;
   mailbox#(logic) data_bits;
   // implementation
endclass

class parallel_monitor;
   mailbox#(int) data_words;
   // implementation
endclass

// *** reused on system level only

class dut_config;
   logic[4:0] size;
endclass

// scoreboard can know about env
// object and everything that's
// underneath it. No point in
// passing info through mailboxes
// between config object and scoreboard
// because they always go together...

typedef class env;

class s2p_scoreboard;
   env env_p;

   mailbox#(logic) serial_in_p;
   mailbox#(int) parallel_out_p;

   task check();
      forever begin
         int data_in, data_out;

         for (int i = 0; i<=env_p.config_i.size; i++) serial_in_p.get(data_in[i]);
         parallel_out_p.get(data_out);

         assert (data_in != data_out);
      end
   endtask
endclass // s2p_scoreboard

class env;
   serial_monitor serial_monitor_i;
   parallel_monitor parallel_monitor_i;
   s2p_scoreboard s2p_scoreboard_i;
   dut_config config_i;

   function new();
      // instantiate and connect mailboxes
   endfunction
endclass // env

// *** not reused at all

module dut;
endmodule   

module tb;
   env env_i;
   dut dut_i();

   // connect the two;
endmodule

In such a testbench, it is expected that the intricate interfaces will be later dug out to be used in another project. Therefore, the interfaces don’t know the DUT, its configuration or the environment. In case they need to know anything, you should (a) ask yourself if they really need to know it (b) if yes, pass that info in some way that will maintain the interfaces decoupled.

On the other hand, the DUT config object, which is some representation of register values, the scoreboard and the env object are always expected to remain together and attached to the same DUT. Therefore, they can reference each other if this makes things more convenient. For example, there is no point in adding some sort of a port/mailbox/buffer between the scoreboard and the config object. The scoreboard can just have a look at the config, or at any other public parts under env, because it will always be used together with the env. Also, the env can connect the mailboxes together because it knows the interfaces and the scoreboard. This might not seem like a big saving, but when you have hundreds of configuration parameters and you insist on passing each of them to the scoreboard via some kind of a buffer you will note the difference.

So before you go crazy about reuse, it is always good to think ahead. Writing reusable code often comes with a high price tag attached. It demands more effort, and it might make your code more complex and verbose, and hence, harder to maintain.