katang

Members
  • Content count

    12
  • Joined

  • Last visited

  1. Thanks a lot. In my eyes the g++ error message is misleading. I was looking also for the error in defining macro NAME.
  2. I do not know. This is the complete file, header inserted. #include <systemc> SC_MODULE(NAME) { SC_CTOR(NAME); }; SC_HAS_PROCESS(NAME); NAME::NAME(sc_module_name nm) : sc_module(nm) {} And the error message NAME.cpp:6:11: error: expected constructor, destructor, or type conversion before '(' token NAME::NAME(sc_module_name nm) ^ g++ (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
  3. In the book "SystemC from the Ground Up" book, page 57, an implementation style is suggested which seems to be reasonable. However, when I attempt to compile it, I am presented with the message error: expected constructor, destructor, or type conversion before '(' token NAME::NAME(sc_module_name nm) ^ Did something change in the syntax since the book appeared? (the other form compiles and runs fine)
  4. Hello @AmeyaVS, thanks for providing this solution. It helped more than reading a chapter in a book about SystemC. Could you please add one explanation? You provided a hint to a delay unit previously, which you did not use here. Did you so because of performance of didactic reasons?
  5. Hi, What is wrong with my implementation? I receive the error message I guess I am making the instance at the wrong place/time. What is the expected way of utilization? SC_MODULE (BIT_ADDER) { sc_in<sc_logic> a,b,cin; sc_out<sc_logic> sum,cout; sc_signal<sc_logic> X,Y; delay_inertial<sc_logic> DTT{"BIT_ADDER_DELAY2", sc_time(2, SC_NS)}; SC_CTOR (BIT_ADDER) { SC_METHOD (process); sensitive << a << b << cin; } void process() { sc_logic aANDb,aXORb,cinANDaXORb; sc_signal<sc_logic> X,Y; DTT.in (Y) ; DTT.out (Y) ; aANDb = a.read() & b.read(); aXORb = a.read() ^ b.read(); cinANDaXORb = cin.read() & aXORb; Y.write(aANDb); X.write(aXORb); cout = Y.read() | cinANDaXORb; sum = X.read() ^ cin.read(); } };
  6. If I understood correctly, when a during debugging SystemC program reaches a breakpoint, that thread will be suspended, unlike the other threads. Depending on the actual situation, not sending more events from the breakpointed thread to the kernel might affect execution of the other threads. Is there any mechanism which actually suspends operation of the simulator when a breakpoint reached? (in other words: is it possible to execute a simulation stepwise (in virtual time)?)
  7. Hello AmeyaVS, maybe you are right that if I replace FIFO with LIFO in the hierarchical channels, than I will be closer to the solution, but searching with a key the actual contents of a FIFO, and taking out the found element out-of-order, still remains my task., and that was I was looking for.
  8. Thanks for the hint. How delay_transport should be used? My attempt is below. It compiles and runs, but has no effect on the simulated time. SC_MODULE (BIT_ADDER) { sc_in<sc_logic> a,b,cin; sc_out<sc_logic> sum,cout; SC_CTOR (BIT_ADDER) { SC_METHOD (process); sensitive << a << b << cin; } void process() { //Declare variables of type "logic" to be used in calculations sc_logic aANDb,aXORb,cinANDaXORb; sc_time tdelay( 2, SC_NS); delay_transport<sc_time> DT(BIT_ADDER, sc_time tdelay); aANDb = a.read() & b.read(); aXORb = a.read() ^ b.read(); DT; cinANDaXORb = cin.read() & aXORb; //Calculate sum and carry out of the 1-BIT adder sum = aXORb ^ cin.read(); cout = aANDb | cinANDaXORb; } };
  9. Do you mean something like http://csg.csail.mit.edu/6.175/archive/2014/tutorials/T05-ProgrammingSMIPS.pdf? starting with slide #21
  10. Is there a searchable FIFO implementation around? I mean: my Producers send their product to the FIFO of the Consumer when they like. The Consumer, however, might have a preference: may want to consume products of certain Producers first, independently of their position in the FIFO.
  11. From the docs, it is not quite clear if the scope of dont_initialize() is ALL unspawned processes, or just the ones already created when invoking dont_initialize(). "dont_initialize shall only be called in the body of the constructor ... only after having created an unspawned process instance within that same constructor or callback" From this sentence I guess that processes created *before* invoking dont_initialize() will not be executed in the constructor, but the ones *after* invoking will be executed. Am I right?
  12. Is there a facility for simulation to delay execution? (something like #time in Verilog). Something like sc_sleep(time). (see http://stackoverflow.com/questions/26125756/systemc-module-not-working-with-sc-thread) I understand it would not result in a timed simulation, but would be good for educational purposes.