Jump to content

apfitch

Members
  • Content Count

    613
  • Joined

  • Last visited

  • Days Won

    117

Everything posted by apfitch

  1. 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
  2. Hi Stephan, I believe std::gets was deprecated in c++11, removed in c++14. But std::fgets is still valid. regards Alan
  3. 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<<
  4. 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
  5. 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
  6. 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
  7. 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
  8. See Note 4 in 5.2.11 of the LRM Alan
  9. 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.
  10. 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
  11. 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
  12. 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
  13. 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 *
  14. 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
  15. Hi Manikanta, Unfortunately there's no easy way round this. One solution is to figure out which signal changes first and remove that from the sensitivity list. So for instance if data changes before address, take data out of the sensitivity list and leave address in. However that's not a very easy to use solution as you have to work out which signal changes first. And later changes may break your code. Assuming your model is "just a model" i.e. not for synthesis, you could trigger an event shortly after address and data have changed. So suppose address and data are assigned somewhere i
  16. There's a tutorial on the Doulos website http://www.doulos.com/knowhow/systemc/tutorial/ which talks about deltas in the last section. The traditional way around problems with deltas is synchronous design, i.e. make sure all outputs are assigned as the result of a clock edge, and sample the inputs on a clock edge. Then the timing depends only on the clock, and not on the delays or deltas of individual signals. In the code you have shown you do not have a clock. Of course it depends if you are modelling hardware. If you are modelling software, you may have to follow a different app
  17. 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
  18. I don't think there is such a thing. The Altera Modelsim Starter Edition is free, and supports some SystemVerilog (design constructs), but not classes/UVM/constrained random... regards Alan
  19. 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"
  20. It's definitely on the Questa download page. I suspect it breaks the license agreement for me to post a link, so I'm not going to. When you get to the download page, you may need to scroll down to see it, regards Alan
  21. It's available from supportnet. Click on Questa at the left. Click on the downloads tab. Click through to download, and it's on the download page. Alan
  22. 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
×
×
  • Create New...