Warning: session_start(): Cannot send session cookie - headers already sent by (output started at /home2/aefody/public_html/specman-verification.com/scripts/sb_utility.php:873) in /home2/aefody/public_html/specman-verification.com/index.php on line 11

Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home2/aefody/public_html/specman-verification.com/scripts/sb_utility.php:873) in /home2/aefody/public_html/specman-verification.com/index.php on line 11

Warning: strpos(): needle is not a string or an integer in /home2/aefody/public_html/specman-verification.com/index.php on line 71
Tips for HVL and HDL users with special emphasis on Specman-e, SystemVerilog and Questa
Specman Verification
Verification engineer? Verifigen has the right project for you!
Who will save us from ourselves? 
Sunday, June 17, 2007, 12:49 PM - Personal
I’m going to break the first rule for someone who is writing a professional blog, and talk just a bit about politics. I guess a few of my readers are aware that I’m an Israeli and a few of those few (hopefully few X few > 0) might have even wondered what is my take on the current situation. After all, people I meet often ask me about it, but having no idea whether they do it out of politeness or just because they have nothing better to talk about during lunch, I try to avoid the gory details. Especially since I have a tendency of becoming quite boring when I talk about these issues…

But here I can be as boring as I want too, and believe me that I will. After all, at any point you can go easily back to those fascinating pieces of SystemVerilog code on my front page.

So here it is in a nutshell: I’m an extremely-pessimist extreme-left guy. I used to be a part of the optimist less-extremist left, then a part of the optimist extreme-left. A year or two ago the optimism was gone. In part, this is what drove me out of Israel. I simply believe Israel is going towards a dead end.

Let’s face it, Israel’s democracy (if there ever was such a thing) is quickly heading down the drain. We’ve been ruling 3 million people that are deprived of the most basic human rights for four decades now; The west bank is criss-crossed with wall fragments, roads for jews only, army check points and expending settlements on stolen lands. Government policy is dictated by military and generals, as was demonstrated in the last war in Lebanon, and as demonstrated almost on a daily basis in the occupied territories. Palestinians are continuously harassed by settlers, but no one is ever brought to trial. Free press is now just an empty word describing a troop of army cheer-leaders: Most of our prominent “journalists” were the first ones to support the war in Lebanon last summer, and as soon as the unhappy results became evident, the first to switch sides and shout that heads should fall. The courts have long fallen in military hands: Tali Pahima’s sentence and Azmi Bashara’s cooked up allegations are just some known example out of many. Whenever they weakly object, as in the case of torture of suspects or of soldiers using Palestinians as human shields, their decisions are simply ignored.

But all of these, depressing as they are, are not the real reason for my pessimism. The real reason is that I now finally understand that we can win the war against the Palestinians. Moreover, I’m now pretty sure that we will. The common belief, in the Israeli left, as well as among many others, is that you can’t win a war against people who are fighting to redeem themselves from foreign rule. I now realize this belief is simply ungrounded. It has some strong cases to support it such as Afghanistan, Vietnam, Algiers or Israel under the British rule, but quite a few that go against it as well, like Tibet or the Basque land. The fact that it is a bit harder to find other names only goes to prove that losers are quickly forgotten, but nothing else.

Would I prefer that Isreal loses this war? Yes I would. Before my Israeli readers have a chance to say the word traitor, let me explain. Sometimes when you’re making stupid or criminal decisions, somebody has got to put some sense into your head. States, like the people that lead them, often make cruel and idiotic decisions, and loosing in a war is a good way to convince them they were wrong. Would the Germans be happier under a Nazi regime now? Would the French be so much better of if they still had Algier? The Americans if they were still occupying Vietnam? Sometimes the battlefield can serve as a good lesson to the limits of power. Israel itself has learned one or two lessons this way: before the Yom Kipur war we arrogantly refused the same peace proposal that we accepted several years afterwards. We’ve also learned something in Lebanon last summer that we will not quickly forget…the next government will take more then a couple of hours to think before they put Hizballa to the test. And if you ask me, that’s a good thing.

But now in the Palestenian side, the story is quite different, simply because we are way stronger then them, and they have no external support at all. Everyone who has a say, be it the US, the EU or the Arab League, simply could not care less, and I have a strong feeling that things will remain this way. There is simply no one that really likes the Palestinians these days: the Arab states never really cared about them, the US sees red when it sees the green flags of Islam, and the EU states, I believe, are not big fans of Islam as well, although they would have us believe it because they are more PC. However, a closer look into the obstacles the EU puts in front of Turkey, or into the attitude towards Muslim immigrants almost everywhere, makes it clear that under the hood, they are really not that far from the opinions voiced in the US. If you need a further proof remember that the Palestinian Authority is currently under international boycott which prevents any aids or money transfers and which no one, including the EU, has the courage to break.

In luck of external support and under an almost complete occupation, the Palestinians are simply breaking down. The elite is gradually packing up and moving to countries where they can lead normal lives. No one can really blame them for that. Those that can’t move out, try to move inside the territories to areas where army and settlers pressure is smaller. This is how the old town of Al-Halil/Hevron, which used to be populated by around 30000 people, turned into a ghost town in a matter of a few years. Palestinian society and economy are collapsing – people in Gaza or Jerusalem can’t see relatives from other parts of the west bank for months and years, the leadership is gradually fading away, and the whole ex-PA is gradually turning into a complete anarchy, in a quite similar way to what is happening in Iraq. The ongoing civil war, into which Israel will soon become drawn as well in the false hope of making some easy gains, is just another proof that things are heading the wrong way.

Which for me, means only one simple thing: that Israel will continue going down the slippery slide of becoming an apartheid state. The settlers and the army will continue to push, the Palestinians will become weaker and more divided among themselves, the pressure against internal opposition and Arab members of parliament will continue to grow. And any decent man will find Israel a harder and harder place to live in.

And personally I find that quite sad, because Israel is my real home after all.

  |  permalink
Modeling registers with SystemVerilog 
Saturday, June 9, 2007, 02:18 AM - Hardcore verification
Almost everyone doing verification has at some point come across one of these register packages that are supposed to help you out in accessing and checking register fields, registers, memories and any other strange creatures that are connected on your bus (some well known names are vr_ad, RDL and beach). How do you know if these are any good or not? Whether you are about to design, buy, or use such a package it is a good exercise and a good idea, to give a serious thought to the things you would like an ideal package to be able to do. Composing such a requirement list is a big amount of work, so often people just skip it and move straight on to design, buy or use the damn thing. Which goes a way to explain why there are so many not-so-good products out there.

Contrary to what you might have expected by now, I haven’t done this thinking for you. As I said, it is quite a bit of work to do. However, being the good guy that I am, I have decided to take a small limited aspect of register packages, namely the register objects themselves, and talk about the things I would normally like to see from them. Then I will discuss some difficulties with implementing these requirements in SV.

So, given a register object I would be quite upset if:
1.It doesn’t support random generation and doesn’t allow me to easily constrain its fields, either stand alone or depending on the values of other fields in other registers or of other environment variables in general. If you think that this goes without saying when you’re doing constrained random verification, you are obviously right. However, I met people who raised a brow at this requirement more then once.
2.It doesn’t allow you to define default values for some register fields and to override these values from your test.
3.It doesn’t allow you to define register fields as enumerated types, thus allowing you to abstract from bits and bytes. Just imagine that you have to remember, for example, if 0/1 means half duplex/full duplex or the other way around.
4.It doesn’t support one or more of the following functions: (a) a copy function which would create an identical instance of the register. This is highly useful for checking, in order to create shadow registers, and in order to manage registers in general (b) a print function that would print all register fields along with their enumerated values if such values exist (c) a couple of functions that would allow you to easily turn the fields into a bit vector and vice versa. (d) a function that would allow you to compare to register instances field by field.
5.It doesn't support individual access permissions per field (A read only field, write only field etc.), and globally per register.
6.It doesn't support coverage of fields.
7.It doesn’t allow me to put register fields into lists when I feel like it. This is useful when you have, for example, an interrupt vector, and you would like to loop through the bits to check which one is set. Ok, this would not quite upset me, but it is a nice to have.

And that’s more or less it… not only nice guy but quite modest as well. The examples in this entry, however, will cover only 1-4 above, 5-7 do not present any conceptual differences from 1-4, so for the moment I'll leave them out.

In Specman-e requirements 1-4 above would be quite easy to have. It really all amounts to no more then:


<'



type A_values [A0, A1, A2, reserved](bits:2);

type B_values [B0, B1, B2, B3](bits:2);



struct REG1 {

    address : uint;

    %A : A_values;

    keep soft A == A0;

    %B : B_values;

    keep soft B == B1;

};        

    

The nice thing about the e code is that it is really easy to maintain. So, for example in the code above, if you change a field name, you only have to change it in two places – in the definition and in the soft constraint. The built in "print", "deep_copy", "deep_compare”, "pack" and "unpack" will take care of all the rest.

What about SV? This is somewhat a different story as you probably guessed. There is really no simple way to meet all the requirements above and to still have a code that is easy to maintain. Here is the simple SV equivalent of the code above (in order to compile and run it with Questa use “vlog –novopt” and “vsim –novopt”):




// a pure virtual class only to define a common interface

// and to enforce functionality implementation in each

// register

typedef enum {true, false} bool;



typedef register;



virtual class abstract_register;

   pure virtual function int pack();

   pure virtual function unpack(int raw_data);

   

   pure virtual function register copy ();

   pure virtual function bool compare (register second_instance);

   pure virtual function void print();

endclass // register



// a real base class - you must repeat

// all the funtions if you want to add some 

// real members  



typedef enum {REG1, REG2} registers;



class register extends abstract_register;   

   int address;

   // just because sometimes it makes things

   // easier to see in the GUI

   registers name;



   function int pack();endfunction

   function unpack(int raw_data);endfunction

   function register copy();endfunction

   function bool compare (register second_instance);endfunction

   function void print();endfunction

endclass



// ** start of specific per register part **

   

typedef enum {A0, A1, A2, reserved} A_values;

typedef enum {B0, B1, B2, B3} B_values;



class reg1 extends register;

   rand A_values A;

   constraint A_default {A == A0;}

                                          

   rand B_values B;

   constraint B_default {B == B1;}

   

   function new(registers my_name, int my_address);

      address = my_address;

      name = my_name;

   endfunction // new



   // note that you'll be repeating field

   // names and widths for everyone of the

   // functions below

   

   function int pack();

      int result;

      result |= A << 0;

      result |= B << 2;

      return result;

   endfunction // int



   function unpack(int raw_data);

      // normally you would check that A's

      // value doesn't turn out to be "reserved"

      A = A_values'(raw_data[1:0]);

      B = B_values'(raw_data[3:2]);

   endfunction // unpack



   function void print();

      $display("%s.A = %s", name.name(), A.name());

      $display("%s.B = %s", name.name(), B.name());

   endfunction



   // ok, I think we got the point right?

   // I'll leave those for the imagination

   // I'm only putting them because

   // pure virtual must be implemented

   function register copy();endfunction

   function bool compare (register second_instance);endfunction

endclass // reg1



class reg_file;

   rand reg1 reg1;



   function new();

      reg1 = new(REG1, 32'h20);

   endfunction // new

endclass





module top;   

   reg_file reg_file;



   initial

     begin      

        reg_file = new();

        assert(reg_file.randomize());

        

        reg_file.reg1.print();

     end

endmodule


As you can see, because SV doesn’t have any of the extremely useful pre-defined methods mentioned above, you simply have to define those by yourself. Compared with the two repetitions in the e code you will now have probably 10+ places where the field name appears, and at least as many where its width has to be specified. This is obviously much harder to maintain by hand. However, don’t panic just yet, because if you read until the end of this entry you’ll see things are really not that bad.

In order to make the code easier to maintain, you can turn each field into a class instance, and have all of those stored in a dynamic array. This would allow you to use a simple loop to iterate through the fields, hence saving some of the repetitions above. Here’s almost the same example written using lists. Note that the code is somewhat longer and more complex, but the part that is specific per register is shorter:


// ** represants a field in the register **



class reg_field #( type fields_enum = int );

   // so that you can constrain 

   // the strcut using its own field or

   // so that its easier to understand which field 

   // you're looking at in the GUI.

   // you could do without this field as well...

   fields_enum name;

   // note: value is not enumerated. hard to decipher...

   rand bit[31:0] value;

   // we must initalize the field with its width otherwise we

   // can't turn the register into int later on, for example.

   int width;



   // just for sanity...

   constraint value_smaller_then_width {value < (1 << width);}

   

   function new( fields_enum field_name);

      name = field_name;

   endfunction

endclass // reg_field





// ** an abstract class to enforce register functionality **



typedef enum {true, false} bool;



virtual class abstract_register;

   pure virtual function int pack();

   pure virtual function unpack(int raw_data);

   

   pure virtual function abstract_register copy ();

   pure virtual function bool compare (abstract_register second_instance);

   pure virtual function void print();

endclass // register





// ** a template for all registers **



class register #( type fields_enum = int, type regs_enum = int )

  extends abstract_register;



   typedef register#(fields_enum, regs_enum) this_type;



   // of course address width should be easily

   // modified. Normally a template parameter

   // should be used, but I'm leaving this to you

   int address;

   regs_enum name;

   rand reg_field #(fields_enum) fields[];



   function new(regs_enum my_name, int my_address);      

      // initalize each field with its own name 

      fields_enum junk; 

      fields = new[junk.num()];

      for (int j=0; j < junk.num(); j++)

        fields[j] = new(fields_enum'(j));



      //initalize name and address

      address = my_address;

      name = my_name;

   endfunction



   function void print();

      int start = 0;

      fields_enum cur_register;



      $display("\n");

      

      foreach (fields [j]) begin

         cur_register = fields_enum'(j);

         $display("%s.%s = %d", name.name, cur_register.name, fields[j].value );

         start += fields[j].width;

      end



      $display("\n");

   endfunction // int



   // ~ same thing for comparing, copying, converting

   // to bits/bytes and back

   function int pack();endfunction

   function unpack(int raw_data);endfunction

   function abstract_register copy ();endfunction

   function bool compare (abstract_register second_instance);endfunction   

endclass





// ** start of specific per register part **



// note that the number of times field

// names/widths will actually need to be

// repeated is much smaller in this case





typedef enum {REG2, REG1} registers;

// an enum for each regs with all fields (1st repetition)

typedef enum {A = 0, B = 1} reg1_fields;

typedef enum {C = 0, D = 1} reg2_fields;



class reg1 extends register #(reg1_fields, registers);

   function new(registers my_name, int my_address);

      super.new(my_name, my_address);

// initalization of each width is second repetition



      fields[ A ].width = 2;

      fields[ B ].width = 2;

   endfunction // new



   constraint A_default {fields[ A ].value == 1;}

   constraint B_default {fields[ B ].value == 0;}

endclass // reg1



class reg2 extends register #(reg2_fields, registers);

   function new(registers my_name, int my_address);

      super.new(my_name, my_address);

      

      fields[ C ].width = 16;

      fields[ D ].width = 16;

   endfunction // new



   // default constraints are 3rd & 4th repetitions

   // must be named so to be turned off later

   constraint C_default {fields[ C ].value == 2;}

   constraint D_default {fields[ D ].value == 3;}

endclass // reg2



class reg_file;

   rand reg1 reg1;

   rand reg2 reg2;



   function new();

      reg1 = new(REG1, 32'h20);

      reg2 = new(REG2, 32'h24);

   endfunction // new

endclass





// ** a module to try the whole thing out **





module top;   

   reg_file reg_file;



   initial

     begin      

        reg_file = new();

        assert(reg_file.randomize());

        

        reg_file.reg1.print();

        reg_file.reg2.print();

     end

endmodule


This implementation is elegant enough, but it has a major disadvantage, because all of the fields are defined as bit vectors and not as enumerated types. By the 10th time you open the specification in order to check what config.tty = 101 stands for, this is guaranteed to get on your nerves. You could try to have a different class for each field but this would make the list of fields quite difficult to create, plus you’ll end up having a multitude of field classes. Obviously you can try your own ideas, move some stuff from the list and back, create different templates or specializations, but I don’t believe you’ll get anything significantly better then that. And if you do just encrypt and patent it as soon as you can…

So, between one piece of code that is hard to maintain, and another that doesn’t support enumerated fields which one do I prefer? Surprisingly enough, I will go for the first. Why? Because it is quite a rare case that you have to write your register classes by hand these days. In most companies, the HVL (whether e, SV Vera or anything else) register classes will be simply generated by a script from another language that is used to describe the registers, such as RDL or XML. This is not so much to save verification engineers some work, but rather in order to reduce documentation errors and to make integration between HDL, HVL and software smoother. Since all of these must use representations of the same registers written in different languages, it makes much more sense to derive all of these from a single description that is relatively easy to parse.

Which means that whatever HVL you’re using, your register description will be probably created by a script, and therefore maintenance is obviously less of an issue. Whether you’re using e or SV you’ll have to re-create your register classes whenever a new version of the main register representation file is in place, so that you can be sure that you are synchronized with designers, software and whoever else. So, ugly as it looks, the brute force method with the numerous repetitions could do quite well.

But by any means do not conclude that these built in Specman methods are something you don’t really need. Unfortunately, in the majority of cases you still have to code your classes by hand…

  |  permalink
Grow your own - starting a website 
Monday, May 28, 2007, 06:37 AM - Hardcore verification
Nir Dahan, an Israeli-German (or maybe the other way around…) friend of mine has just started a blog for ASIC digital design tips. I like the way it looks (but I’m hardly an authority on the subject as you can probably tell), and it seems like he has been putting a lot of effort in it…So, if just like me, you’re an ex-designer and would like to check if you can still tell a flip-flop from a XOR gate, give Nir a visit, and don’t be shy to tell him what you think. I’m sure he’ll appreciate it.

At this happy opportunity, I would like to answer some questions about having a website that I’ve been asked quite a lot. To begin with, people have often wondered if anything ever comes out of it. The answer depends on what kind of “anything” you expect: if its money, eternal love or fame, that you’re after then you’ll probably have to look somewhere else. If, however, your “anything” stands for interesting career opportunities and a bit of reputation, then (a) you’re a nerd and (b) you’ve come to the right place.

Here are some personal statistics: since I started my website almost three years ago, it had played a major part in practically every job or contract I got, including my last one with Verilab. It is a very effective tool to make yourself a name and important connections, and connections, for those who don’t know, are the most important thing in the EDA world. It can also be used to give future employers a wider and more attractive view of yourself, and this can be achieved even if you don’t rank in google that well. Just place a line like “author of www.x.com” in your CV, and there are quite good chances you’ll see a hit to your page from your interviewer’s desk. That’s an extremely valuable “interview extension” that can be used in very effective ways, and where, unlike at the interview time, everything is in your hands.

If you are convinced that you want one for yourself, my next important tip is “think big” or “think what happens if it works”. That is, don’t say to yourself something like “I will start with this cheap/free host, and if I make it, I will move this website somewhere else. If I don’t then at least no money is lost”. That’s a bad way to go, because moving a website is as bad as moving to a new apartment, especially when google already ranks you well. Plus, the costs for having your own domain and a decent host are usually negligible compared to the effort you will have to invest. You’d better listen because I have spilled some blood over this: my first website was on yahoo’s geocities, and I decided to move because once visitors started arriving I realized it was not serious to have your website called www.geocities.com/avidan_e. More then one year afterwards, this long time “ghost site”, still ranks before this one when you google the words “specman tutorial”. I know that thinking big is a bit like putting a condom in your pocket when you go on a very hot date…you don’t want to put the expectations too high for yourself. In this case you just have…

Next is blog/website software, which was another painful mistake. Once again, don’t go the cheap and lazy way like I did, and just get your software for free without checking or consulting first. I have chosen “simplephp” which does the job and is quite nice, because I’ve learned a good deal of php along the way (it is all open source). However, when I see the things that people put up in about a tenth of the time using wordpress, I just know I have to move away.

Content and audience is another big issue…As you might have noticed, I have an extensive Specman tutorial somewhere around this place. Writing and maintaining such a tutorial is a lot of effort. For example, with Specman 6.1 a lot of my generation related sections are supposed to go out of date, and by the time I rewrite those, something new will already be in place. Also, it is quite rare to have someone reading a tutorial from cover to cover these days…most people are after a very quick solution to a very specific problem they had. They google “specman for loop” and they want to see an example for that, or “specman get_enclosing_unit null” and they want a workaround for that. Therefore, contentwise, at least for a start, a “solution oriented” blog is the right way.

If you would like google to pick up your scent, and to position you at the place you think you deserve, you should also promote yourself. Lucky for us, the EDA world is far from being saturated with valuable websites, so a quality website can still stand out with a reasonable effort. The way that worked for me, and that will probably work for you as well, is to use open forums and discussion groups for that. It is a bit tedious, but it can get you to the top twenty after several months. If your site really has quality material, other people will help you out from there.

That’s it from me. I hope I’ll see many of you out there soon because we are not playing a zero sum game…The more people take the time and effort to join and contribute the better business we will all be making, and the better products we will all be using. I'm just thinking whatif this SystemVerilog standard was discussed in public before it was sealed...wouldn't we all be living better for the next 10 years?
  |  permalink

Back Next