Stats

  • Locked Locked
  • Replies 7
  • Subscribers 65
  • Views 14823
  • Members are here 0
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

starting same TCM multiple times.

harip

Hi All,

We have a doubt related to starting the TCM multiple no. of times.

Let us take a TCM used to check some property and takes a few cycles(say 5-10) to execute.

If the event which is used to start this TCM occurs multiple times during the executuion period (5-10 clock for TCM),

does the event forks out multiple threads for the TCM?

Regards,

Harip

Parents

  • So, I think the question you are asking is how to handle the check for pipelined behavior.  If there are multiple requests before the first grant occurs, you need to check that each request will have a grant within 5 cycles.  If that is your question, you need to build a simple queue or list to model the pipeline of requests and then check each of them receives a grant.  There might be simpler ways to do it, but here is an example I created quickly to demonstrate one approach:

    <'

    extend sys {
     monitor: monitor_s;
    };

    // Need to build a list of request/grant pairs to track
    struct gnt_chk_s {
     event clk is @sys.any;
     event grant;

     expect req_gnt_chk is
      {[0..5];@grant exec {out("Grant checked ", sys.time)}} @clk
      else dut_error("No Grant within 5 cycles");
    };

    struct monitor_s {
     !gnt_chk: gnt_chk_s;
     !gnt_chk_list: list of gnt_chk_s;

     event clk is @sys.any;
     event dut_request;
     event dut_grant;

     on dut_request {
      out("New Request ", sys.time);
      gen gnt_chk;
      gnt_chk_list.add0(gnt_chk);
     };

     on dut_grant {
      out("New Grant ", sys.time);
      emit gnt_chk_list.top().grant;
      gnt_chk_list.top().quit();
      gnt_chk_list.delete(gnt_chk_list.last_index(TRUE));
     };

     // Simulate some combination of pipelined requests/grants
     req_gnt_gen() @clk is {
      wait [1];
      emit dut_request;
      wait [1];
      emit dut_request;
      wait [1];
      emit dut_grant;
      wait [6];
      emit dut_grant;
      wait [10];
      stop_run(); 
     };

     run() is also {
      start req_gnt_gen();
     };
    };

    '>

Reply

  • So, I think the question you are asking is how to handle the check for pipelined behavior.  If there are multiple requests before the first grant occurs, you need to check that each request will have a grant within 5 cycles.  If that is your question, you need to build a simple queue or list to model the pipeline of requests and then check each of them receives a grant.  There might be simpler ways to do it, but here is an example I created quickly to demonstrate one approach:

    <'

    extend sys {
     monitor: monitor_s;
    };

    // Need to build a list of request/grant pairs to track
    struct gnt_chk_s {
     event clk is @sys.any;
     event grant;

     expect req_gnt_chk is
      {[0..5];@grant exec {out("Grant checked ", sys.time)}} @clk
      else dut_error("No Grant within 5 cycles");
    };

    struct monitor_s {
     !gnt_chk: gnt_chk_s;
     !gnt_chk_list: list of gnt_chk_s;

     event clk is @sys.any;
     event dut_request;
     event dut_grant;

     on dut_request {
      out("New Request ", sys.time);
      gen gnt_chk;
      gnt_chk_list.add0(gnt_chk);
     };

     on dut_grant {
      out("New Grant ", sys.time);
      emit gnt_chk_list.top().grant;
      gnt_chk_list.top().quit();
      gnt_chk_list.delete(gnt_chk_list.last_index(TRUE));
     };

     // Simulate some combination of pipelined requests/grants
     req_gnt_gen() @clk is {
      wait [1];
      emit dut_request;
      wait [1];
      emit dut_request;
      wait [1];
      emit dut_grant;
      wait [6];
      emit dut_grant;
      wait [10];
      stop_run(); 
     };

     run() is also {
      start req_gnt_gen();
     };
    };

    '>

Children
No Data

Community Guidelines

The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.