Jump to content

apfitch

Members
  • Posts

    613
  • Joined

  • Last visited

  • Days Won

    118

Everything posted by apfitch

  1. 1. Yes, see LRM 13.2.4 r) 2. No, see LRM table 60 3. You can connect one sc_in to drive many sc_out, but not the other way round. See the description of sc_writer_policy at LRM 6.3 regards Alan
  2. 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
  3. For question 1, please see Note 1 in the 1666-2011 LRM section 6.30.3. For question 2 - that looks like an error in SystemC from the Ground Up. In c++ before c++11 you can't do any initialisation of class members at declaration, so you must initialise on the constructor initialiser list (I think from memory that's been relaxed in c++ 11). When you say "So if I want to use the form of sc_semaphore pump(12) to the module, what should I do on the constructor?" the answer is you can't (pre C++11). Your second example is correct. Of course you can use a pointer to an sc_semaphore and call new in the constructor if you prefer. For your last question, please see the LRM section 6.29.3, regards Alan P.S. The LRM is free, and can be downloaded via the main Accellera website.
  4. A module isn't a class derived from uvm_report_object, so class methods aren't available. You could do something like uvm_top.get_report_verbosity_level() (assuming you've imported uvm_pkg of course) regards Alan
  5. The key to understanding this is that the simulator you are using is not the standard. The standard is the LRM, the Accellera simulator is deliberately described in the working group as a "Proof of Concept implementation". It is not a "reference simulator" as people sometimes say - the reference is the LRM. The LRM clearly states that the execution order of processes within the evaluation phase of the scheduler is *not* deterministic, the simulator is free to choose any runnable process to run in any order (runnable meaning "triggered"). In the case of sc_semaphore, whether a process is made runnable depends on immediate notification (notification within the evaluation phase of the scheduler) and that is non-deterministic. So the behaviour of a particular simulator/compiler does not prove anything about the order of execution of processes. If you want deterministic behaviour you must guarantee it by your design (e..g by using explicit events and delta delays to guarantee the order of execution of processes) kind regards Alan
  6. The order of declaration of processes in a module constructor is not significant. The behaviour of sc_semaphore is non-deterministic - please read the description in section 6.2.94 of the IEEE 1666-2011 LRM, where it makes it clear that the behaviour is non-deterministic by design (thanks to the use of immediate notify in the evaluation phase of the scheduler), kind regards Alan
  7. I think the issue is your statement "So, when the producer receives the End_Req, it can initiates a new transaction". You shouldn't be creating a new transaction, you should be returning a handle to the original transaction object. The transaction object must remain alive during the complete transaction. You can then tell which transaction object is which by keeping an array of addresses of transaction objects as you create them, and then matching the objects, Alan
  8. Connections in TLM2 are point-to-point. If you need to connect one initiator to many targets you need a router in the middle. With a loosely timed style of coding you might not even need a delta cycle, a single call could take no time at all - though of course the initiator would probably contain a wait after each function call. Have look at the LT example here: http://www.doulos.com/knowhow/systemc/tlm2/tutorial__3/ regards Alan
  9. There was no problem. Right at the bottom of the messages you'll see "Generating Code", so your program did compile. regards Alan P.S. , The warnings were the nice people at Microsoft telling you that the function sprintf is potentially unsafe (as it doesn't have any bounds checking).
  10. Generally LT connections are strictly point-to-point - so an initiator can call a function in a target, one at a time. As you say, in LT one initiator can only make one function call, which must return before it makes a second function call. If you have two consumers, they must have some routing in-between. The initiator calls b_transport in the router (point-to-point); the router inside its implementation of b_transport must interpret the address, call b_transport in the appropriate consumer, and wait. It cannot return to the original initiator until the downstream consumer had returned. There's a comment in the 1666-2011 standard "Although the initiator thread may be blocked, another thread in the initiator may be permitted to call b_transport before the first call has returned, depending on the protocol." Though an initiator with 2 threads could be regarded as two separate but highly co-ordinated initiators in a sense Alan
  11. I could only compile with pthreads (quickthreads didn't work) ../configure --host=i686-linux-gnu --prefix=/home/apf/systemc-2.3.1x86 --enable-pthreads Then in my Makefile for the actual systemc program I was building, I had to add -m32 to g++ regards Alan
  12. That looks good to me. What is wrong with the waveforms? One issue that can catch you out is the time resolution of the simulator, the speed of your clock, and the time resolution of the waveforms. I guess if you're using Questa, you're using the built-in waveform tracing (not using your own vcd trace file). Questa will probably default to a resolution of either 1ns or 1ps. So I would check the clock frequency in your testbench to make sure it is sensible (much bigger than 1ns, say 10ns) regards Alan
  13. It's almost definitely a problem with your code. Questa definitely works. As does the Proof of Concept simulator you can download for free from Accellera. The best simulator depends on your criteria. The lowest cost simulator is the free download - but of course you don't get nice integrated debugging and waveform viewing. If you want a better debugging environment, then you're better off using Questa, or Incisive, or VCS, or Riviera: but it will cost you. regards Alan P.S. sensitive_pos is deprecated, you should use sensitive << clk.pos()
  14. Follow the instructions in the INSTALL file in the download, kind regards Alan
  15. 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
  16. See Note 4 in 5.2.11 of the LRM Alan
  17. Are you sure that systemc is installed in /usr/local/SystemC-2.3.1? Can you do ls /usr/local/SystemC-2.3.1 and does that show the install? regards Alan
  18. We were told by Mentor recently that UVM Connect should now work on Windows, but I can't remember which versions of Questa/UVMC you need - so the best thing is to contact Mentor Supportnet, Alan
  19. SystemC is a single-threaded application at present, if that's what you're asking, Alan
  20. It depends what you mean by "correct". The standard says that the target should not modify the data ptr, so you are not following the standard - see Table 54 of 1666-2011. Also as I said before, you're misusing the length attribute, it indicates the length of the payload in bytes, and in your case should always be 1. You seem to be modelling a bit-addressable bus. TLM2 wasn't designed to do that, it was designed with bus widths that are a multiple of 1 byte. kind regards Alan P.S. I'd also be interested to see a real bus that addresses to the bit level.
  21. I don't know how specific compilers implement bool, but the C++ standard says its size is unspecified, so I probably wouldn't rely on bool to carry the data. I would declare a an array of char, e..g unsigned char data[1]; The other thing I don't understand is your use of len. The length is the number of characters in the data array, so in your example I would always expect trans->set_data_length(1), since a bool value will fit into 1 character. You seem to be using set_data_length() to specify a bit index. There's no support for bit addressing in the TLM payload. If you want to read a particular bit, you either need to work out the address that contains that bit, retrieve a character, and then mask the value you want; or create an extension to the TLM2 payload to specify the bit you want. Whatever you do, the TLM2 payload always moves an array of characters; and the address in the payload points to a particular character. regards Alan
  22. I guess my first question is are you using DMI or not? Because you don't seem to have any code to actually implement the DMI. Assuming you're not using DMI (dmi_valid is false), my second question is what is the data type of "data" - int? I assume you're using something like int but treating it as a 4 character array? Thirdly, in b_transport, where are you looking at the contents of data_ptr? In the case of a read command, you seem to be overwriting data_ptr, which is bad. The data_ptr value shouldn't be modified. Using uint8_t for the address is potentially misleading, as the address is 64 bit. What I'd expect is code something like if(cmd==tlm::TLM_READ_COMMAND){ data_ptr[0] = device_rx_data[addr]>>len)& 0x1; } Though if the original data is something like int, you'll have to think about endianness. regards Alan
  23. Hi Manikanta, regarding your question 3) about IP, in SystemC the IP referred to is normally system level IP. You're right, for RTL IP there is a mature system for IP exchange (IP-XACT). But for System Level IP there was no standard API until TLM2 came along. Regarding question 1), one of the problems with SystemC/C++ high level synthesis is that the tools are not standardized. With traditional RTL VHDL and Verilog synthesis, it is fairly straightforward to change from one synthesis tool to another. With High Level Synthesis that is not the case as far as I know, Alan
  24. This thread might be useful : http://forums.accellera.org/topic/1354-why-systemc-and-who-uses-it/ regards Alan
×
×
  • Create New...