apfitch

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

Hi Stephan, I believe std::gets was deprecated in c++11, removed in c++14. But std::fgets is still valid. regards Alan

I'm not sure what you mean. You could change the printing code to use an SC_THREAD, and then you could add a small wait to allow the outputs to settle. And make the printing process only sensitive to sum, e.g. #include "half_adder.h" SC_MODULE (full_adder) { sc_in<bool>a,b ,cin; sc_out<bool>sum,carry; sc_signal<bool> c1,c2,s1; void disp() { while (true) { wait(1, SC_NS); cout<<"a="<<a<<endl; cout<<"b="<<b<<endl; cout<<"cin="<<cin<<endl; cout<<"sum="<<sum<<

It's hard to say. One obvious issue is that if sum and carry change on different delta cycles, you'll see two printouts, Alan

Not as far as I know. If you haven't found it already, you might want to look at http://www.embecosm.com/appnotes/ean1/ean1-tlm2-or1ksim-2.0.html regards Alan

Please post the error message, regards Alan

You need to put a loop and a wait in your SC_THREAD, e.g. void StimGen() { while(true) { cout << sc_time_stamp() << "Hello World!\n"; wait(); } } Alan

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

See Note 4 in 5.2.11 of the LRM Alan

I've used it just because for a simple virtual sequence there's no need to create a virtual sequencer whose only purpose is to hold references to the sub-sequencers. You can put those references in the virtual sequence instead. So I suppose it just saves a bit of typing! regards Alan P.S. I wish UVM had used different words that "sequence" and "sequencer"... it's a recipe for confusion.

Hi C4brian, no I don't recommend always using wait(SC_ZERO_TIME). I recommend understanding how the scheduler works, which I guess is what your aim is too! The scheduler is well described in the LRM. A shortened description (ignoring lots of details) is 1. if there are runnable processes, execute them. ( a process that calls immediate notify here can make another process runnable at this point) repeat 1 until no more runnable processes 2. advance to evaluation phase update all primitive channels and events. A call to notify(SC_ZERO_TIME) here will cause you to go b

notify() makes a process runnable within the evaluation phase. So it can cause non-deterministic process execution. You might use notify() when modelling something like multi-threaded software, because software does not have delta cycles. notify(SC_ZERO_TIME) triggers on the next delta, which avoids some non-deterministic behaviour, and is closer to how languages like VHDL and Verilog work. Note that all runnable processes are still picked in an unknown order when choosing which process to run next in the evaluation phase. regards Alan

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

The danger with that approach is that you have to manually make sure you have no race hazards in your design or indeterminacy in your design. My first answer would be "don't use a signal", use a shared variable instead. Another answer would be to have a shared event between the modules. You could do something like module1 sc_event sig_written; // in a process my_sig.write(true); sig_written.notify(); // immediate notify! /////////////////////////// module2 sc_in<int> sig; // in an sc_thread sc_event * ev; module2(sc_module_name name_, sc_event *

There's a difference between a signal and a variable. A signal does have delta cycle behaviour - so when the clock changes, module 2 will read the current (before the change) value. With a plain C++ variable the result is undefined as you don't know which process will run first (the process in module 1 or the process in module 2) regards Alan