Home > Community > Forums > Functional Verification > C++ Object life cycle through SV DPI

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

 C++ Object life cycle through SV DPI 

Last post Wed, May 16 2007 8:09 PM by archive. 11 replies.
Started by archive 16 May 2007 08:09 PM. Topic has 11 replies and 2208 views
Page 1 of 1 (12 items)
Sort Posts:
  • Wed, May 16 2007 8:09 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    C++ Object life cycle through SV DPI Reply

    Hi all,

    I have a C++ Object life cycle through SV DPI problem.

    For example, I have a C++ reference model class named ALU.  Only one public function revealed to client (e.g. ALU::ALU_EXEC) and was encapsulated in DPI(ALU_EXEC_DPI) . And there are two types of ALU commands was entered to ALU::ALU_EXEC. One is setup ALU parameters (i.e. setup the ALU class private member) , the other is calculating the result.
     
    The question is when I leave DPI, the ALU object is eliminated and all the setup parameter is cleared, right? So can I keep a C++ Object even after I leave DPI (i.e. is the C++ Object life cycle only as long as DPI call life cycle).

    My friend suggest me to return all the ALU parameter out to SV and re-enter these parameters to ALU through ALU_EXEC_DPI when I call the ALU reference model. But it may break the model encapsulation :(

    May be my question is not very clear and any suggestions are welcome!
    Davy




    Originally posted in cdnusers.org by davyzhu
    • Post Points: 0
  • Thu, May 17 2007 1:15 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    Davy,

    Untill and unless you exit the simulation through ncsim and do not call the destructors in C++, you do not need to pass the values again and can use the object in your TB.

    Hope i got your question correctly?

    -Vivek.


    Originally posted in cdnusers.org by prasad_vc
    • Post Points: 0
  • Thu, May 17 2007 2:02 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    Hi Vivek,

    Thank you so much :)

    Yes, you got my question. When I refer back to SV DPI spec, I notice DPI can call task.
    Something like from Stuart Sutherland's paper "Integrate SC model with SV DPI"
    //---SV file
    import “DPI” task SC_alu_run(...);
    always @(clk, a, b, opcode)
    SC_alu_run(clk, opcode,a, b, result,$realtime);
    //---

    //---SC file
    SC_alu_run (
    int clk, opcode,
    double a, b,
    double* result,
    double time) {
    sc_start(time);
    results = ...
    }

    I wonder whether this idea can be implemented in Cadence tools. Or there is some other methods Cadence recommend?

    And I have not used SystemC before and I just encapsulate the C reference model with a simple SystemC synchronization shell. Will there be a long learning curve for me (I am familar with C++ and SystemVerilog)?

    Any suggestions are welcome :)

    Best regards,
    Davy


    Originally posted in cdnusers.org by davyzhu
    • Post Points: 0
  • Thu, May 17 2007 2:20 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    Davy,

    The SV file looks Ok. Just follow the C++ conventions instead of SC in C++ file.

    I don't think tool is an issue here.

    //---SV file
    import “DPI” task alu_run(...);
    always @(clk, a, b, opcode)
    alu_run(clk, opcode,a, b, result,$realtime);
    //---

    //---C++ file
    alu_run (
    int clk, opcode,
    double a, b,
    double* result,
    double time) {
    cpp_start(time);
    results = ...
    }


    This will work. I am calling the tasks in my environment.

    -Vivek


    Originally posted in cdnusers.org by prasad_vc
    • Post Points: 0
  • Thu, May 17 2007 2:27 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    Hi Vivek,

    Thanks a lot :)

    I will try a simple example soon.

    Best regards,
    Davy


    Originally posted in cdnusers.org by davyzhu
    • Post Points: 0
  • Thu, May 17 2007 3:05 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    Hi Vivek,

    I have thought your suggestion and there is a question according to the DPI task scheme.

    When alu_run() in C++ return result, the task will be completed, right?
    How can we get the cycle accurate result from the C++ and make the task always running and output the result? e.g. Shall I make the result in C++ as a reference?

    Any suggestions are welcome :)

    Best regards,
    Davy


    Originally posted in cdnusers.org by davyzhu
    • Post Points: 0
  • Thu, May 17 2007 3:20 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    Davy,

    You are right, when it returns result you will have to re-enter by calling the task.

    Why don't you call the task in the always loop and be in the loop untill certain conditions are met!

    Anyway, you are passing the "$realtime" to the task right?

    This will have some overhead in terms of cpu time, but won't affect severly.

    What exactly you want, can you express it thro an example?

    -Vivek.


    Originally posted in cdnusers.org by prasad_vc
    • Post Points: 0
  • Thu, May 17 2007 4:14 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    Hi Vivek,

    I will try to describe the situation I encounter comprehensively. Please point it out if you think it is ambiguous.

    First, I want to re-use a C++ model as the reference model. It contains a class, ALU. The ALU class have one public function ALU_exec (opcode,src,result). I will keep them untouched.

    Then, if I encapsulate the class ALU with DPI function like
    ALU_exec_DPI (opcode,src, result) {
    ALU::ALU();
    ALU::ALU_exec (opcode,src,result).
    ALU::~ALU();
    }

    But as you see, when the DPI function return, the ALU object is eliminated (But I want to keep the ALU object alive until the simulation end for there are some status information stored in the ALU object), and there will be a new ALU object when I re-enter the DPI function.

    At last, I turn to youi for help, and you suggest to use DPI task.
    I guess if I use DPI task, I can generate the ALU object ALU::ALU(); when I enter the simulation ( or I get the first instruction)
    , while ALU::ALU_exec (opcode,src,result) is always running on the same ALU object through the whole simulation time
    , and ALU::~ALU(); to eliminate the ALU object when I exit the simulation.

    And what do you mean by call task in always loop?
    //---SV file
    import “DPI” task alu_run(...);
    always @(clk, a, b, opcode)
    alu_run(clk, opcode,a, b, result,$realtime);
    //---

    BTW, "$realtime" is copied from Sutherland's example and I don't think it is a must :)

    Any suggestions are welcome!

    Best regards,
    Davy


    Originally posted in cdnusers.org by davyzhu
    • Post Points: 0
  • Thu, May 17 2007 4:32 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    Ok,

    Now, do not use the task. Use function instead.

    You will have one more input to your input argument list, e.g. status.

    //---SV file
    import “DPI-C” context alu_run = function int alu_run(...);
    always @(status)
    alu_run(clk, opcode,a, b, result,$realtime, status);
    //---

    Now, untill and unless you pass status value '2' the C++ shouldn't exit. This way the C++ would be alive and you can continue the simulation. At the time you want to exit, pass the value '2' to the C++. For the normal sim, you can pass the value '1'.

    Also, i would like to suggest you to use two tasks for "constructor" and "destructor" and a function for the alu_run. But one thing is clear that even you are out of the alu_run function the values would still be retained, unless you enter it again and initialize the same.

    I guess, i am showing you the right path.

    -Vivek


    Originally posted in cdnusers.org by prasad_vc
    • Post Points: 0
  • Thu, May 17 2007 7:53 PM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    Hi Vivek,

    Thank you for your generous help:) I have think through your idea and there are some questions.

    First, can I replace "context alu_run " with "pure alu_run "?

    Second, I guess "status" is controlled by a testbench driver and act like a reference model trigger, right? As you said, "For the normal sim, you can pass the value '1' and C++ would be alive", but we know that the function will return result once while C++ object will be killed?

    At last, shall I encapsulate the "constructor" and "destructor" and a function for the alu_run with DPI task/function separately? So how can I share the C++ object between these three task/function?

    Any suggestions are welcome!

    Best regards,
    Davy


    Originally posted in cdnusers.org by davyzhu
    • Post Points: 0
  • Fri, May 18 2007 4:09 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    For the first, please refer the LRM.

    About Second, Let the function return the result. The class members will still be retaining the values. so use one more member function "read_data" to the desired variables in your testbench.

    For the Third, i am not an expert in C++, but i think, once the object is created the scope will be till the end of simulation.

    -Vivek


    Originally posted in cdnusers.org by prasad_vc
    • Post Points: 0
  • Mon, May 21 2007 12:24 AM

    • archive
    • Top 75 Contributor
    • Joined on Fri, Jul 4 2008
    • Posts 88
    • Points 4,930
    RE: C++ Object life cycle through SV DPI Reply

    Hi Vivek,

    After discussion and reading LRM, I have tried svPutUserData() and svGetUserData() to to store and load object in C layer. It works well for me. And thank you for your suggestions :-)

    Best regards,
    Davy


    Originally posted in cdnusers.org by davyzhu
    • Post Points: 0
Page 1 of 1 (12 items)
Sort Posts:
Started by archive at 16 May 2007 08:09 PM. Topic has 11 replies.