apfitch

I'm a bit confused by your code - if you do the calls to write *after* returning from sc_start(), I wouldn't expect either write to work as once the simulation has returned from sc_start(), it is either finished or paused. Regarding your main question - the two events created by assigning signals in the same delta will only result in the process running once. Have a look at our (Doulos's - I work for Doulos) little tutorial here: http://www.doulos.com/knowhow/systemc/tutorial/ and see if that helps, regards Alan P.S. An interesting experiment would be to put dont_initialize() ; after the sensitivity of your SC_THREAD and see what happens. All SystemC processes run at time zero without being triggered - by adding dont_initialize(), you will be able to see if your writes are really what is causing the process to run.

Hi, the sc_signal class is designed to trigger sensitive processes when there is a change in value on the data it transfers. In your case that is a change in value *of the pointer* which is quite weird. I would suggest using sc_fifo to communicate the data, using blocking reads and writes. If you must use signals, use sc_buffer instead, as this creates an event on every write to the sc_buffer channel, regards Alan

Hi Dakupoto, in my experience, gcc on Linux generally has much more stack "out of the box" than Visual C++ - I think Visual C++ defaults to about 1MByte of stack. Regarding different users - see the comment above about ulimit... environment changes for each user can affect the amount of stack as well. If you use dynamic memory, it shouldn't matter how much stack the compiler allocates by default, or how much the user environment/sysadmin gives each user/process, regards Alan

I guess you've answered your own question :-) , as it sounds like you feel the work to modify your code is too much. However if you can afford the time, then using dynamically allocated memory is better. Suppose you want to run the code on another operating system in the future? Or give the code to someone else to run? Then using dynamic memory allocation makes it more likely your code will work on other OS, or for someone else. Often in electronics (and life!) there is the "80/20" rule where most of the problem lies in the 20% area - perhaps you can reduce the problem by attacking just the "20%" and leaving other code untouched? Good luck! Alan

I don't think there's a limitation. However you might be running into some stack limit in your compiler. Try creating a dynamically allocated array, e.g. sc_in<double> * input; then allocate the memory using new in the constructor. regards Alan P.S. Or perhaps sc_vector would help in SystemC 2.3.0?

You should be able to increase the Visual Studio stack with /Zm (from memory). You can increase the SC_THREAD stack size with the set_stack_size() method of SystemC - but if that works, I would still suspect you are declaring large stack allocated arrays in the SC_THREADs. Alan

Are you declaring large data structures (e.g. arrays) inside SC_THREADs? That can cause you to run out of stack space in the SC_THREADs. If you are, then re-write the arrays to be dynamically allocated using pointers. regards Alan

One answer is "no" - blocking transport can indeed block "forever" and that would presumably represent a functional error in your model. Another possible answer is: for maximum simulation speed, ideally you should not block (wait) inside b_transport. Any waits would be in the threads that called b_transport. Time modelling can be handled either by explicit synchronization between the master threads; or by using the quantum, together with timing annotation in the b_transport function call (again with the option of explicit synchronization between threads if ordering of operations is required). It's an irony of LT modelling that it works fastest if you don't call wait in b_transport! Perhaps other people can chip in with some other opinions... kind regards Alan

Hi Jocelyn, assuming you are the co-author of the compiler (Jocelyn Serot) then the fix should surely be to fix the compiler - by generating an if statement, instead of using the conditional operator? regards Alan P.S. I was going to suggest you report a bug to the authors of CAPH - but if you're one of the authors you can report it to yourself :-)

Your loop is wrong, it should be for (unsigned int i = 0; i< 10; i++) (you've got the i<10 and i++ back to front) regards Alan P.S. You can use sc_gen_unique_name("frame") to create unique names Even better, use the new sc_vector classes in SystemC 2.3.0 for creating arrays of modules.

Weird. Try replacing any calls to wait() in your SystemC code with sc_core::wait(). If that doesn't help, it looks like you're using an unsupported operating system (gentoo), so try using a supported OS. regards Alan

If you're going to create synchronization between threads, then I guess the length of the wait doesn't matter, it's only purpose is to allow another thread to run and create a scheduling order in your simulation. Regarding init3, I'm not sure - if both threads are waiting for the same notification I'm puzzled. regards Alan

Not sure how that smiley face got there! I was trying to say b ...

The only reasons could be a) the init1 thread never suspends so init2_thread never gets a chance to run or the wait(init1_ev) is not waiting when the event is notified (but that would probably only be true once a time zero) regards Alan

Hi Tanja, We generally advise that in a loosely timed model it is best if the initiators make sure that code executes according to a defined schedule i.e. the software application running on the initiators should handle locking of shared resources and so on. The intention is that if the model is refined to approximately-timed, or if you put delays in the loosely timed targets, the behaviour of the application should still be correct (though of course the performance may not be good enough). So I would say that you would have to explicitly synchronize init2 by notifying an event in init1 when init1 writes to memory. regards Alan

You can't be sensitive to a plain C++ variable, you have to be sensitive to a channel that implements default_event(). Did you mean sc_signal<bool> bsp; By the way, sc_bit is deprecated, just use bool, Alan

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

I don't know if there was a fundamental reason, but as multi-ports can be bound to an unknown number of interfaces (if you set max number of bindings to zero) maybe that's why? When you refer to "port instances" that's not what happens. There's only one port, with bindings to multiple interfaces. If you want that feature, why not just use an array of ports, then you really will have multiple port instances? regards Alan

Hi, one simple way would be to put a delay in that loop - even a delta delay should work, e.g. while(1){ for(int i=0;i<10;i++){ if(fifo_in[i].nb_read(packet)){ cout << "Packet received from Robot " << i << "\n"; wait(SC_ZERO_TIME); // let other processes run // processing } } } Another solution might be to use the TLM1 tlm_fifo - that has a peek interface, and also an ok_to_get() which notifies an event when something is in the fifo. You could wait on the result of the OR of all the ok_to_get() calls. regards Alan

Phew, I'd just about run out of ideas :-)

Yes I think so. The error message seems to say that you have a pointer to the target socket, perhaps you need initiator->isocket.bind( *(target->tsocket) ); It's hard to say without seeing your code, regards Alan

That socket requires SystemC dynamic processes. With the ASI Proof of Concept simulator, you need to define SC_INCLUDE_DYNAMIC_PROCESSES, for instance at the top of the file where you instance the simple_target_socket, do #define SC_INCLUDE_DYNAMIC_PROCESSES regards Alan

I suppose so - though since a simple target socket is not a multi-socket, it would not tag transactions. But you could route incoming transactions on the simple target socket to a particular interface of the tagged initiator socket based on address, and then use the tag to reconstruct the address on the backward path. Alan

Glad it's working now. Regarding the time values, I was asking as another possible problem would be if you specified time values that were smaller than the time resolution - but obviously not, as it's working, Alan

Passthrough doesn't support automatic blocking/non-blocking conversion - see table 59 in the 1666-2011 LRM, regards Alan