Jump to content

apfitch

Members
  • Content Count

    613
  • Joined

  • Last visited

  • Days Won

    116

Reputation Activity

  1. Like
    apfitch got a reaction from SiGa in user defined data type signal assignment   
    How do you know the assignment is not working?
    When are you printing out the assigned value?
     
    Remember that you must wait at least a delta for a primitive channel to update.
     
    There's more about user defined types and sc_signal here
     
    http://www.doulos.com/knowhow/systemc/faq/#q1
     
    regards
    Alan
  2. Like
    apfitch got a reaction from SiGa in user defined data type signal assignment   
    Hi Zarie,
     that's what I meant by "you must wait a delta". If no time passes, a primitive channel does not update. Kocha's solution will work (adding a call to sc_start - in fact even sc_start(SC_ZERO_TIME)  should work.
     
    regards
    Alan
  3. Haha
    apfitch got a reaction from SiGa in Inter modules communciation   
    I guess the main advantage of using SystemC is that ports/modules/channels give you a standard approach. Even if you don't care about time passing, you may well care about the order that things happen in, and then events and time are still useful. Also of course you get a ready to use threading library and scheduler.
     
    The disadvantage might be simulation speed compared to pure C++. And of course you have to learn SystemC.
     
    The main advantage of C++ is that you can do exactly what you want (you're free!)
    The main disadvantage of C++ is that you can do exactly what you want :-) (You're re-inventing the wheel)
     
    regards
    Alan
  4. Like
    apfitch got a reaction from shubham_v in loosely timed vs accurate timed ??   
    In a loosely timed model you only have two timing points - start of transaction, end of transaction.
     
    In an approximately timed model using the base protocol, you have four timing points - start request, end request, start response, end response - hence you can model overlapped (pipelined) transactions, because you can start a new request before you have the response to the previous request.
     
    In my example above, you would only be able to send a new transaction every 75 ns using loosely timed, so the model of the timing of the transaction is less accurate - in the loosely timed model I can send a new transaction every 75 ns, in approximately timed every 50 ns using that example.
     
    If you do not use overlapped transactions, then you could just use begin request and end response, so as you say the non-blocking (approximately timed) and blocking (loosely timed) models would give the same results,
     
    regards
    Alan
  5. Like
    apfitch got a reaction from jatin jatin in It can have two constructors in a SC_MODULE?   
    Yes, but you need to write the constructors yourself (don't use the SC_CTOR macro). Something like
    #include "systemc.h" SC_MODULE(mod) {    int i;    mod(sc_module_name nm) : sc_module(nm) { // ...    }    mod(sc_module_name nm, int i_) : sc_module(nm), i(i_) { // ...   } }; If you use SC_THREAD or SC_METHOD you must also include the SC_HAS_PROCESS macro.
     
    Try looking up SC_HAS_PROCESS in 1666-2011 and you should find an example near there,
     
    regards
    Alan
  6. Like
    apfitch got a reaction from maehne in It can have two constructors in a SC_MODULE?   
    Yes, but you need to write the constructors yourself (don't use the SC_CTOR macro). Something like
    #include "systemc.h" SC_MODULE(mod) {    int i;    mod(sc_module_name nm) : sc_module(nm) { // ...    }    mod(sc_module_name nm, int i_) : sc_module(nm), i(i_) { // ...   } }; If you use SC_THREAD or SC_METHOD you must also include the SC_HAS_PROCESS macro.
     
    Try looking up SC_HAS_PROCESS in 1666-2011 and you should find an example near there,
     
    regards
    Alan
  7. Like
    apfitch got a reaction from Amol Nikade in loosely timed vs accurate timed ??   
    Imagine you are modelling a bus-based system.
    You send a request to a slave on the bus.
    That request takes keeps the bus busy for 50 ns, and then the peripheral takes 25 ns to process the data.
     
    That means you can send a new request on the bus every 50 ns, before you have received the response from the slave.
     
    Req1 Req2 ---------|---------|--------- |---------|---------|--------- Resp1 Resp2 If you need to model at that level of detail, then you would use approximately timed modeling, with non-blocking transport.
     
    If you don't need that level of detail (perhaps you don't even know what bus you're using yet?) then loosely-timed might be appropriate (and faster)
     
    regards
    Alan
  8. Like
    apfitch got a reaction from Philipp A Hartmann in Clocked thread SC_CTHREAD exclusion during initialization phase   
    Hi Mr SystemCInDepth,
       I think it's important to realise that SC_CTHREAD is special, in that the specified sensitivity is a clock (the rising or falling edge event of a bool or sc_logic).
    There's no such thing as a "clock" for SC_METHOD and SC_THREAD - just events on channels such as sc_signal, sc_fifo, or any other channel that implements an event.
    So I would not say
    because an SC_METHOD or an SC_THREAD does not have a clock. That's what Philipp meant when he said
    Does that make it clearer?
    regards
    Alan
  9. Like
    apfitch got a reaction from yosri ben salah in memory exception   
    You should be able to view the Call Stack in Visual C++ - that may give you an idea of exactly where the exception is being thrown,
    regards
    Alan
  10. Like
    apfitch got a reaction from maehne in Error:<E109> complete binding failed: port not bound:   
    Hi,
    the reason for the error is that you're not binding all your ports. You bind the ports in this loop:
     
    for(int i=0;i<n;i++) { for (int j=0;j<=i;j++) { std::cout << i << " " << j << " " << std::endl; test_CHOL0->chol_in_data[i][j](chol_in_data[i][j]); test_CHOL0->chol_out_data[i][j](chol_out_data[i][j]); } } but in the second loop you have j <= i. I've added printing and you can see that you only bind 6 of the 9 ports
     
    SystemC 2.3.1-Accellera --- Sep 3 2016 13:00:03 Copyright (c) 1996-2014 by all Contributors, ALL RIGHTS RESERVED 0 0 1 0 1 1 2 0 2 1 2 2 I think you need j < n
     
    regards
    Alan
  11. Like
    apfitch got a reaction from AmeyaVS in Priority and PEQ   
    I guess first you'd need to add an attribute (extension) to the generic payload to represent the priority.
    Then you could write a variant of the PEQ which takes into account that priority.
    regards
    Alan
  12. Like
    apfitch got a reaction from Shashidhar in simple sockets and TLM sockets   
    Hi Cam,
      the simple_sockets behave in the same was as the standard sockets, in the sense that an initiator may *call* the four functions (b_transport, nb_transport_fw, get_direct_me_ptr, transport_dbg) and the target *must* implement those functions.
     
    On the reverse path the target may *call* nb_transport_bw and invalidate_direct_mem_ptr, and the initiator implements them.
     
    The only difference with the simple sockets is that they have the bodies of the functions for you. In other words the simple_target_socket implements the tlm_fw_transport_if, it contains function bodies for b_transport, nb_transport_fw, get_direct_mem_ptr, and transport_dbg. However to tell those functions exactly what to do, you register your *own* function with the required behaviour. To do this, you call register_b_transport etc.
     
    So if the initiator calls b_transport in the target with a simple socket, the b_transport function *in the simple socket* is called. That then in turn calls the function you registered with b_transport.
     
    That compares to the standard sockets, where the implementation of b_transport is *in the target* not *in the simple target socket*.
     
    I hope that's a bit clearer,
     
    regards
    Alan
  13. Like
    apfitch got a reaction from Mstones in primitive and hierarchical channel   
    A channel is simply a class that implements a SystemC interface.
     
    A primitive channel implements an interface and is derived from from sc_prim_channel, and can thus have access to the scheduler (evaluate update).
     
    A hierarchical channel implements an interface and is derived from sc_module, and can thus have all the features of an sc_module (processes, hierarchy etc).
     
    There'd be no point in deriving from sc_prim_channel and then not implementing the update/request-update behaviour.
     
    If you want a channel that is not a primitive channel, and is not a hierarchical channel, you would typically implement an interface but derive from sc_object.
     
     
    regards
    Alan
     
    P.S. To answer your questions more specifically - request_update and update are not pure virtual, so you could ignore them. Though why would you ignore them? If you don't want them, derive from sc_object instead.
    A hierarchical channel is derived from sc_module. sc_module does not have request_update/update, so you can't use them.
  14. Like
    apfitch got a reaction from sumit_tuwien in Weird SystemC Context   
    The error message implies that you are calling wait() in your SC_METHOD - that's not allowed, wait() can only be called in SC_THREADS,
     
    regards
    Alan
  15. Like
    apfitch got a reaction from karandeep963 in Turn off `uvm_info messages   
    Could you use set action to set the action for all info messages to uvm_none?
     
    Something like
    +uvm_set_action=uvm_test_top.*,_ALL_,UVM_INFO,UVM_NO_ACTION Alan
  16. Like
    apfitch got a reaction from amar712 in Unique array elements without rand or randc   
    You should be able to use
     
       std::randomize(id_array) with { unique {id_array}; };
     
    Untested though,
     
    regards
    Alan
  17. Like
    apfitch got a reaction from bocuabeucon in Output of systemC   
    Scheduling order of processes in the same run phase is random.
    It's important to realise that because a is a primitive channel (sc_signal), it doesn't update its value immediately. a will only update after all processes have and reached a wait statement,
     
    regards
    Alan
  18. Like
    apfitch got a reaction from amitk3553 in primitive and hierarchical channel   
    A channel is simply a class that implements a SystemC interface.
     
    A primitive channel implements an interface and is derived from from sc_prim_channel, and can thus have access to the scheduler (evaluate update).
     
    A hierarchical channel implements an interface and is derived from sc_module, and can thus have all the features of an sc_module (processes, hierarchy etc).
     
    There'd be no point in deriving from sc_prim_channel and then not implementing the update/request-update behaviour.
     
    If you want a channel that is not a primitive channel, and is not a hierarchical channel, you would typically implement an interface but derive from sc_object.
     
     
    regards
    Alan
     
    P.S. To answer your questions more specifically - request_update and update are not pure virtual, so you could ignore them. Though why would you ignore them? If you don't want them, derive from sc_object instead.
    A hierarchical channel is derived from sc_module. sc_module does not have request_update/update, so you can't use them.
  19. Like
    apfitch got a reaction from Zack63 in Backwards generic_payload   
    I would say that is not within the spirit of TLM2 approximately timed modelling. In particular 11.2.3.5 b )  in IEEE 1666-2011
     
     
    Note that the use of nb_transport in the above quote is defined in 11.1.2.4 a) of the same document
     
    regards
    Alan
  20. Like
    apfitch got a reaction from Tedy in Dynamic communication path in SystemC/TLM   
    There's not a dynamic port. The structure (modules/ports/channels) of a SystemC model is static once elaboration is complete.
     
    TLM is intended to model systems using memory-mapped busses. In that case you could use a router, and re-program the routing during simulation - but there's no direct built-in support for that, you'd have to make or buy a router model,
     
    kind regards
    Alan
  21. Like
    apfitch reacted to Roman Popov in Problem with the case statement   
    Hello kihtrak,
    In your source code you don't assign any value to bin.   Please provide a minimal simulation source code to reproduce your problem. Otherwise nobody can help you.
  22. Like
    apfitch reacted to Stephan Gerth in VCD file not generated   
    Hi kihtrak,
     
    the issue is right in the first few lines of your screenshot:
    d1.d_select(t_select); d_select is of type sc_out<bool> and t_select of type sc_signal<sc_uint<2>> which means you can't connect them because they have different data types (connecting an sc_out to an sc_signal is not the issue here). So you can either change the type of one of those or fit a converter in if you can't do that for some reason.
  23. Like
    apfitch got a reaction from kid123 in Error: (E100) port specified outside of module: port 'simple_target_socket_0_port_0' (sc_port_base)   
    What are you trying to do with this line?
    trans->set_data_ptr( reinterpret_cast<unsigned char*>(&c) ); It looks strange to me. c is class sc_out<bool> so casting "pointer to sc_out<bool>" to "pointer to unsigned char" doesn't make sense to me?
     
    Alan
  24. Like
    apfitch got a reaction from kid123 in Error: (E100) port specified outside of module: port 'simple_target_socket_0_port_0' (sc_port_base)   
    You need to bind the sockets in sc_main
    initiator.socket(memory.socket); Also your do_and thread needs an infinite loop inside it i.e.
    void do_and() { while(true) { // your code here } } regards
    Alan
  25. Like
    apfitch got a reaction from kid123 in Error: (E100) port specified outside of module: port 'simple_target_socket_0_port_0' (sc_port_base)   
    Hi Huy,
      I realised I did not read your code properly.
    You have an instance Top *and* you have instances of Initiator and Memory in your sc_main.
     
    I think the way you have written your code, you do not need Top.
     
    So if you take out Top and also take out the socket declarations in sc_main that is better.
     
    regards
    Alan
×
×
  • Create New...