Jump to content

ankushKumar

Members
  • Content Count

    14
  • Joined

  • Last visited

Posts posted by ankushKumar

  1. Hi Alan,

    in class B what actualy i am doing is :

    class B : public sc_module, public my_tlm_interface_forward , public my_tlm_interface_backward{

    tlm::tlm_target_socket<BUS_WIDTH> target_socket;

    tlm::tlm_initiator_socket<BUS_WIDTH> initiator_socket;

    E *e;

    B(sc_module_name name):sc_module(name),target_socket("target_socket"){

    target_socket(*this);

    initiator_socket(*this);

    e = new E(this); // IN THIS e I AM ALSO utilizing THE BACKWard interface

    }

    }

  2. Hello All,

     

    I am trying to create a generic TLM interface for 2 to 3 modules . In which i am virtually inherting the tlm interface . But i am getting an error . Could you tell me the cause of error.

    example

     class A : public sc_module, public my_tlm_interface_fw{

    };

     

    class B : public sc_module, public my_tlm_interface_forward , public my_tlm_interface_backward{

    }

     

    class C : public sc_module, public my_tlm_interface_backward{

    }

     

    and binding

     

    C->initiator(B->target)

    B->initiator(A->target)

     

     

    Error: (E124) sc_export instance not bound to interface at end of construction: export 'i_top.tlm_base_initiator_socket_export_0' (sc_export)
    In file: ../../../../src/sysc/communication/sc_export.cpp:135

  3. Hello all,

     

    i am using tlm socket and declared as following

    tlm_utils::simple_initiator_socket_tagged<current_model> initiator_socket[2];

     

    // in construcot

                   initiator_socket[0] = new tlm_utils::simple_initiator_socket_tagged<current_model>("socket0");
                   initiator_socket[1] = new tlm_utils::simple_initiator_socket_tagged<current_model>("socket1");

     

    error: no match for ‘operator=’ (operand types are ‘tlm_utils::simple_initiator_socket_tagged<current_model<unsigned int, 32u>, 32u, tlm::tlm_base_protocol_types>’ and ‘tlm_utils::simple_initiator_socket_tagged<current_model<unsigned int, 32u>, 32u, tlm::tlm_base_protocol_types>*’)
    initiator_socket[0] = new tlm_utils::simple_initiator_socket_tagged<current_model>(txt);

     

  4. See Note 4 in 5.2.11 of the LRM

     

     

    Alan

    hello

    i got that but would like to know what exactly happening.

     

    see

     

    class A:public sc_module{

    public :

               A(){

                    SC_THREAD(funcA);

               }

               SC_HAS_PROCESS(A);

               void funcA(){

                    funcB();

               }

               void funcB(){

                    wait(100,SC_NS);

               }

    }

     

    Now funcA is a thread thus registered with the systemc scheduler.

    what about funcB it is a C++ based function having wait whether it gets registered with systemc kernel since a normal c++ function cannot suspend.

  5. Hello all,

     

    I have doubt regarding use of c++ function inside systemc threads.

    It is said that a normal c++ function which is declared in a class inherting systemc module and called  inside the thread of that class shall be executed based  c++ kernel simulation not on the basis of systemc scheduler therefor it won't  wait for an event or time if introduced in it. Is that true ? But in my code nothing as such is happening the function is waiting for time introduced in it.

     

    Regards.   

  6. Hello Sir,

    A simple timer can be implemented simply as

    outlined below: First of all, note that a timer

    could be count down/up or simply waiting 

    for a triggering event, and this triggering 

    is essential for any timer to work.

    1. Have a SystemC clock (sc_core::sc_clock),

    with pre-defined time period.

    2. Have a loop that runs while the triggering

    event is FALSE, and resets when the triggering

    event is TRUE. Inside the loop, decrement/

    increment a counter at each clock tick. When 

    the triggering event stops the loop, the counter

    value multiplied by the clock period provides

    the time value that you need.

    Hope that helps.

     

    Hello,

     

    incrementing/decrementing the counter at every clock tick slow downs the simulation process that why  David has recommended for the second method.

  7. Since ESL models are supposed to be lightweight and fast (esp. if used for software development), I strongly suggest you do not increment/decrement a counter. Instead, use timed event notification and calculation as you seem to have suggested. I did a presentation at NASUG on this, "Look Ma, no clocks" several years back. I am pretty sure the code was published -- www.nascug.org should have reference to it somewhere.

     

    May i know what's the difference it will create if have a timed notification or have wait  after every increment or decrement.

    I mean a timed notification will also notify after a dalay that has been provided.

  8. Hello All,

     

    I need some strong suggestion regarding modeling of TIMER.

    I am new in systemc.

     

    Want to know what are the things a best model should consist of and how its modeling should be done ?

     

    Since timer has a clock time period,

    should i model it in by incrementing/decrementing the counter and applying a delay for timer period 

    or i should model it without any delay by using sensitivity to the new write in register and decremnting/ incrementing the counter value by evaluating the current time period and previous sensitivity time period by clock time period.

     

    With Warm Regards.

  9.  

    First, execution order does not depend on the notification order. Changing the order of notification will not change the thread execution order.

     

    Greetings

    Ralph

     

     

    Hiii Raplh

     

    Is it like that the execution order and notification order is independent of simulation kernel

  10. SC_THREAD(A)

    SC_THREAD( B )

    SC_THREAD( C )

     

    A(){

           while(1){

                         wait(e_A);

                         e_B.notify(SC_ZERO_TIME);

                         e_C.notify(SC_ZERO_TIME);

                         -------

                        }

    }

     

     

    B(){

           while(1){

                         wait(e_B );

                         -------

                         -------

                        }

    }

     

    C(){

           while(1){

                         wait(e_C);

                         -------

                         -------

                        }

    }

     

    In the above case acc. to systemc scheduler the threads will be notified in delta phase.

    Now my question is, whether its a nodeterminstic condition which of the thread will run 1st b or c , or is it like that the one notified 1st will get the control 1st.

×
×
  • Create New...