generate of specman (vs) randomize of systemverilog

Hi Krishna.

In both e and SV, the pre_ and post_ methods are used as procedural hooks to do things that cannot or should not be done with constraints. Both methods are called automatically by the randomisation engine, either side of the actual randomisation process.

The pre_ method is less commonly needed in Specman, because Specman's generate action actually allocates memory for the objects as it does the randomisation, unlike SV which (unhelpfully) forces the user to new() every object before randomisation can take place. This becomes important when you are randomising a nested object (e.g. a burst class that contains a list of transfer class objects). In SV you might use pre_randomize() to allocate the nested classes so that they can also be randomised.

The post_ method is more commonly used. A typical problem is to generate a valid CRC  for the object.
It can be hard and inefficient to do this with constraints especially if your object has many optional fields, so we typically use a post_generate method to do this. I'll illustrate with e because I prefer it to SV, but the principle applies to both:

struct packet {
  %address : byte;
  %length : uint;
  %payload[length] : list of byte;
  crc_error: bool;
  %crc;
  post_generate() is also {
    if !crc_error {
      crc = crc8(%{address,length,payload});
    };
  };
};

This code would generate a random crc value when you randomise the struct. The post_generate method then computes the correct crc if the crc_error control field is not set.

Hope this helps. I would strongly recommend that you open the Specman docs (type "sn_help.sh" at the Unix prompt) and search for post_generate. The docs give a lot of guidance about how to use these methods properly, to avoid over-constraining your tests.
A little biased note: Specman's documentation is fantastic, and has loads of great info for actually building your testbench; it's almost a proper book in its own right. By contrast, SystemVerilog is just a dry LRM spec which leaves you try to work out how and why you should do things. This is just one of the many reasons I prefer Specman to SV, it's so much easier to use!

Hi Krishna.

In both e and SV, the pre_ and post_ methods are used as procedural hooks to do things that cannot or should not be done with constraints. Both methods are called automatically by the randomisation engine, either side of the actual randomisation process.

The pre_ method is less commonly needed in Specman, because Specman's generate action actually allocates memory for the objects as it does the randomisation, unlike SV which (unhelpfully) forces the user to new() every object before randomisation can take place. This becomes important when you are randomising a nested object (e.g. a burst class that contains a list of transfer class objects). In SV you might use pre_randomize() to allocate the nested classes so that they can also be randomised.

The post_ method is more commonly used. A typical problem is to generate a valid CRC  for the object.
It can be hard and inefficient to do this with constraints especially if your object has many optional fields, so we typically use a post_generate method to do this. I'll illustrate with e because I prefer it to SV, but the principle applies to both:

struct packet {
  %address : byte;
  %length : uint;
  %payload[length] : list of byte;
  crc_error: bool;
  %crc;
  post_generate() is also {
    if !crc_error {
      crc = crc8(%{address,length,payload});
    };
  };
};

This code would generate a random crc value when you randomise the struct. The post_generate method then computes the correct crc if the crc_error control field is not set.

Hope this helps. I would strongly recommend that you open the Specman docs (type "sn_help.sh" at the Unix prompt) and search for post_generate. The docs give a lot of guidance about how to use these methods properly, to avoid over-constraining your tests.
A little biased note: Specman's documentation is fantastic, and has loads of great info for actually building your testbench; it's almost a proper book in its own right. By contrast, SystemVerilog is just a dry LRM spec which leaves you try to work out how and why you should do things. This is just one of the many reasons I prefer Specman to SV, it's so much easier to use!