Jump to content

apfitch

Members
  • Content Count

    613
  • Joined

  • Last visited

  • Days Won

    117

Reputation Activity

  1. 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
  2. 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
  3. 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
  4. Like
    apfitch got a reaction from maehne in function with wait   
    funcB is still called in the context of the SC_THREAD.
     
    When you declare an SC_THREAD, the threading library (pthreads or quickthreads) keeps track of the a local stack pointer and local stack variables for that thread. When you call wait(), it pushes the state of the processor onto the stack at that point - it doesn't matter if you're inside lots of nested function calls, as long as you're in the context of an SC_THREAD, the wait() method works.
     
    wait() is a method of the sc_module base class.
     
    regards
    Alan
  5. Like
    apfitch reacted to David Black in Method Process   
    When dealing with pure combinational circuits, the behavior of SystemC is completely reasonable. Usually with pure combinational signals, timing issues prevent signals from arriving at the same time, so the issues of multiple delta cycles is actually an artifact of modeling in the absence of real timing information. It is also the case with pure combinational signals that re-executing a method would not be a problem other than the slight overhead it incurs.
     
    One small issue does remain however... in the current model SystemC model, there is nowhere to identify the final resolved value of a variable as it leaves a timeslot (i.e. after the last delta cycle of a given time). This notion is covered in Verilog with the 'postponed' timing region. Implementation of similar concept is currently under investigation by the SystemC language working group within Accellera. This does not affect most users of SystemC, since the primary use of SystemC is at the architectural level rather than RTL and other low level modeling.
     
    This is all carefully spelled out in section 5 (esp. 5.2.1) of the IEEE 1666-2011 standard, which any serious SystemC user should take time to understand.
     
    I observe that students at universities are most likely to see this issue because they view SystemC as an inexpensive (i.e. free) RTL/circuit simulator with a low learning curve (ie. C++), which SystemC is not designed for. Verilog or VHDL are more appropriate for those activities. SystemC can suffice if you are willing to put up with these small limitations.
  6. Like
    apfitch got a reaction from David Black in Method Process   
    Hi,
     
    the behaviour of SC_METHODs is the same as for Verilog always blocks (note 1).
     
    If you see the SC_METHOD process executing twice, the changes on the signals must be happening on different deltas, which is the same behaviour as you'd get in Verilog. You need to re-write your code so that the signals you are sensitive to change on the same delta.
     
    To confirm what's happening, you can print out sc_delta_count() from within the process to see on which deltas it is called,
     
    kind regards
    Alan
     
    (note 1) except at initialization; unless you're using SV always_comb in which case it really is the same even at initialization.
  7. Like
    apfitch got a reaction from Philipp A Hartmann in Timing Annotation   
    See the glossary of the SystemC standard paragraph B.183 p580.
     
    regards
    Alan
     
    P.S. At the risk of sounding like a broken record, it is always best to look things up in the standard first.
     
    P.P.S. If you're young and don't know what a broken record is, imagine I said "scratched CD"
     
    P.P.P.S If you're really young and don't know what a scratched CD is, imagine I said "sample with corrupted loop points"
  8. Like
    apfitch got a reaction from David Long in Timing Annotation   
    See the glossary of the SystemC standard paragraph B.183 p580.
     
    regards
    Alan
     
    P.S. At the risk of sounding like a broken record, it is always best to look things up in the standard first.
     
    P.P.S. If you're young and don't know what a broken record is, imagine I said "scratched CD"
     
    P.P.P.S If you're really young and don't know what a scratched CD is, imagine I said "sample with corrupted loop points"
  9. Like
    apfitch got a reaction from maehne in Process sensitivity with sc_vector   
    Hi Elliott,
    one other thing - it's not clear from your original post what you mean by a new value - if you mean a change in value, then the event() method will tell you a value has changed *assuming* the ports are connected to sc_signal. If you want to detect an event even if the value hasn't changed (for instance if the same value is assigned twice) you can use the sc_buffer channel instead,
    regards
    Alan
  10. Like
    apfitch reacted to Philipp A Hartmann in Process sensitivity with sc_vector   
    Assuming you're using plain signal ports, you can use the event member function to check, whether a specific port has been triggered in the current delta cycle:

    sc_vector< sc_in< int> > in_vec; // ... SC_METHOD(proc); for( unsigned i= 0; i<in_vec.size(); ++i ) sensitive << in_vec[i]; // ... void proc() { for( unsigned i= 0; i<in_vec.size(); ++i ) if( in_vec[i]->event() ) std::cout << "in_vec[" << i << "] triggered." << std::endl; }
    Greetings from Oldenburg,
    Philipp
  11. Like
    apfitch got a reaction from ehsanullah in Error:<E109> complete binding failed: port not bound:   
    Hi,
    your code's confusing.
    You seem to be mixing up port binding and assigning to channels. You don't need the module "my_mod" at all, as far as I can see.
    Also I can't see how you're generating any stimulus.
    Finally, you haven't shown sc_main.
    But the error message is saying

    SC_MODULE(my_mod){ sc_in_clk clk; sc_in<bool>d; [color=#ee82ee]sc_out<bool> q;[/color]
    port q is not bound.
    You might want to look at our website tutorial, http://www.doulos.com/knowhow/systemc/tutorial/, for a basic introduction.
    Also I would recommend using SystemC 2.3.0 if you've got a choice,
    regards
    Alan
×
×
  • Create New...