Jump to content

Leaderboard


Popular Content

Showing most liked content since 01/25/2018 in Posts

  1. 2 points
    David Black

    sc_thread vs pthread

    SystemC follows event driven simulation semantics to simplify hardware modeling. In part, this means using a cooperative multi-tasking model rather than a modern pre-emptive model. In this respect, SystemC is like SystemVerilog and VHDL. This makes it easier to focus on the modeling aspects rather than worrying about mutexes, volatility and other interactions due to multicore and parallel processes. Advanced SystemC users can use OS threads for some tasks, but the synchronization aspects are up to the programmer. So SC_THREAD's are not pre-emptive (nor are SC_METHOD processes) and hence a straightforward SystemC model is single core single threaded from an OS/software point of view. Additionally, you should be aware that the SystemC scheduler is not thread-safe for the most part. If you make use of async_request_update(), you can use multicore and parallel processes to interact with SystemC events. This assumes you are an expert programmer and proficient with C++ (not for beginners). There have been and are some efforts underway to standardize parallelization in SystemC, but it is a volunteer effort and you need to be on the SystemC LWG group to participate. Some commercial entities have developments underway, but keeping those closed for the time being. Always keep in mind that SystemC is not freeware, but was created as part of a commercial coalition to standardize modeling across/between companies. Don't think of SystemC as a free simulator. Also, SystemC is often mistaken as a competitor/alternative to SystemVerilog/VHDL, which it is NOT. SystemC was intended for high-level modeling and abstractions above RTL. The ability to co-simulate with RTL is a requirement for some of the use-cases. SystemC is used quietly by many large corporations to augment specification and verification. It differs from the other languages in that it uses an off-the-shelf C++ compiler and has no requirement of a specialized compiler. This benefits companies with huge software development teams using SystemC Virtual Platform models for early software development. The downside of this approach is the C++ compiler has no understanding of the SystemC domain and has no way to make optimizations that SystemVerilog/VHDL do (e.g. clocks). That is one reason that SystemC coders are advised to avoid explicit clock models to gain performance. Keep the design at as high a level of abstraction as you can.
  2. 2 points
    maehne

    sc_bitref usage

    The compiler has difficulties to decide which overload of the assignment operator it should use. You can help him by doing a static_cast<bool>(myint[7]).
  3. 1 point
    The Accellera Portable Stimulus Working Group (PSWG) is proud to announce the release for Public Review of the latest preliminary version of the Portable Test and Stimulus Standard. This Beta release includes additional work done by the PSWG since the release in June, 2017 of the “Early Adopter” version, reflecting progress on a wide range of issues to improve the standard, including user feedback on the EA version. The PSWG continues to make progress on key features targeted for the 1.0 release of the standard and is committed to ensuring that the standard will open new frontiers of productivity for the industry. The Portable Test and Stimulus Standard defines a domain-specific language (DSL) and an accompanying semantically-equivalent C++ library to create a single representation of stimulus and test scenarios, usable by a variety of users across different levels of integration under different configurations. It will permit the generation of multiple scenarios from a single specification of test intent, and allow tools to create different implementations of a scenario that run on a variety of execution platforms, including, but not limited to, simulation, emulation, FPGA prototyping, post-silicon and virtual platforms. With this standard, users can specify a set of behaviors once, from which multiple implementations may be derived. The Portable Test and Stimulus Standard is still a work in progress, which is why we are asking for public feedback. Enhancements to the Beta version being worked on by the PSWG are: Enhanced control of random selection and scheduling of actions Enhanced coverage constructs for coverage of flows, action scheduling, and resource utilization Enhanced features to handle hardware-software interface and product configurable features Enhanced modeling of memory management Enhanced type system to include additional array types and parameterization by type and value Enhanced reactivity of model to environment Enhanced conditional code processing The Public Review Period will be open until Friday, March 30, 2018. Please provide your feedback via the Accellera Portable Stimulus Forum. All comments will be reviewed by the PSWG. Download the Portable Test and Stimulus Standard Beta release here
  4. 1 point
    This has nothing to do with SystemC, but more to do with your declaration. You are declaring an array of pointers to integers on the stack. Stack in SystemC is 64k by default, which means you are limited to 64k/sizeof(int*). I suspect you intended to declare a pointer to an array of ints: int (*matrix)[]; // Pointer to array of int or int** matrix; I suggest you read at least one of the following: https://www.codeproject.com/Articles/7042/How-to-interpret-complex-C-C-declarations https://www.geeksforgeeks.org/complicated-declarations-in-c/ https://medium.com/@bartobri/untangling-complex-c-declarations-9b6a0cf88c96 For simplicity, I like the following tool: https://cdecl.org
  5. 1 point
    David Black

    Getting a bit from bus

    First thing you need to realize is that sc_signal<> is not a wire and it is not a data type. sc_signal<> is a channel with a non-blocking write and a blocking read. You cannot "connect" a variable to a signal. You have to explicitly make the transfer each time the value changes. There is no equivalent to a Verilog continuous assignment. How do you know if a signal has changed? You have to explicitly watch/wait for the change using additional methods value_changed_event() or possibly posedge_event() if using sc_signal<bool> or sc_signal<sc_logic>. Due to overloading of operator=(), the innocuous looking busCON10 = var_bus_CON[10] turns into: busCON10.write(var_bus_CON[10].read()); which will not return a value until the end of the next delta cycle. Using a cout << busCON directly after this will yield the current delta's value.
  6. 1 point
    Roman Popov

    SystemC and latency simulation

    If your pipeline is simple, like: get data -> process data -> put data, without I/O operations on internal pipeline stages, then you can model latency while keeping throughput: just put output data into fifo-like channel that will delay output for N cycles.
  7. 1 point
    Roman Popov

    SystemC and latency simulation

    No, there is no elegant way to simulate pipelines in SystemC. Commonly you just write a separate thread for each pipeline stage. Like you will do in Verilog/VHDL. 1) All HLS tools I've used do not convert SC_METHODs to pipelines. Only SC_THREADs can be converted to pipelines, if they follow some vendor-specific restrictions. 2) Yes, you can simulate latency by adding wait(N) to clocked SC_THREAD. However it will not simulate throughput. In general, this is a well known problem that HLS-generated code changes timing (expressed in clock cycles) of design. So HLS-generated code can even fail in tests that were working on input SystemC code. To avoid this, your inter-thread communication mechanisms should not depend on latency and throughput of generated hardware. You can also create latency/throughput constraints for HLS tool.
  8. 1 point
    If you insist to instantiate 16 separate ports to transfer each array element separately from each other, you will also have to write/read the elements in your code one after another using, e.g., a loop over the array. From a simulation point of view, all writes will happen at the same time.
  9. 1 point
    AmeyaVS

    thread resets and events

    Hello @fdoucet, What your are trying to do here in this specific scenario is known as dynamic sensitivity. Dynamic sensitivity replaces the default sensitivity of the registered SystemC process, once the event it triggered the default sensitivity would be restored for the corresponding process. Here is a reference to the discussion before in this forum: http://forums.accellera.org/topic/1210-static-and-dynamic-sensitivity/ Hope it helps Regards, Ameya Vikram Singh
  10. 1 point
    leoeltipo

    Socket binding to module itself

    Hello, I am new in the SystemC-TLM world. I am reading the LRM and looking at an example (chapter 13, systemc LRM, page 462). In the module constructor it is written ... init_socket.bind(*this); // Initiator socket bound to initiator itself ... The rest of the code is of no use for the sake of the question. I don't understand why the socket must be bound to the module itself. The example continues and the socket is bound to a target socket, but I don't get this one... Thank you in advance. Leo
  11. 1 point
    AmeyaVS

    Clock to Q Propagation Delay

    Hello, In SystemC you can use SC_THREAD's to model delays by using wait statements but you will incur performance penalty. Instead you can use event's and event queues to model delays using in SystemC as mentioned here: http://workspace.accellera.org/Discussion_Forums/helpforum/archive/msg/msg?list_name=help_forum&monthdir=200803&msg=msg00061.html You can replace the SC_THREAD example given in the above mentioned link with SC_METHOD removing the infinite while loop. Here's the modified example listed from the above mentioned link: template<typename T> class delay_transport : public sc_module { public: sc_in<T> in; sc_out<T> out; SC_HAS_PROCESS(delay_transport); delay_transport(sc_module_name name_, sc_time tdelay_) : sc_module(name_), tdelay(tdelay_), in("in"), out("out") { SC_METHOD(mi); sensitive << in.default_event(); SC_METHOD(mo); sensitive << eq; } sc_time tdelay; void mi() { val = in.read(); vq.push(val); eq.notify(tdelay); } void mo() { val = vq.front(); out.write(val); vq.pop(); } sc_event_queue eq; std::queue<T> vq; T val; }; Regards, Ameya Vikram Singh
  12. 1 point
    I believe 'force' is intended for net types (e.g. wire) and uses the SystemVerilog 'force' statement; whereas, 'deposit' is intended for variables (i.e. var or reg types). Lookup the 'force' and 'release' statements in the SystemVerilog standard for more information.
  13. 1 point
    karthickg

    Socket binding to module itself

    An other way to understand this is to look at SystemC/TLM as pure C++ code and see what is going on.. Let us assume that you have two classes, "Initiator" and "Target", that need to communicate with each other. Target implements a function called "transport" to be called by Initiator, and Initiator implements a function called "response" - that is called by target. For the sake of the explanation here, the payload itself is not important, which we will assume is plain "int" in both directions. You would normally do this as following: // Interface classes: class initiator_if { public: void response(int i) = 0; }; class target_if { public: void transport(int i) = 0; }; class Initiator : public initiator_if { public: // Implement the interface void response(int i) { cout << "Got: " << i << " from target" << endl; } void bind(target_if &_if) { // Store the pointer locally m_target = &_if; } }; class Target : public target_if { public: // Implement the interface void transport(int i) { cout << "Got: " << i << " from initiator " << endl; } void bind(initiator_if &_if) { // Store the pointer locally m_initiator = &_if; } }; Next we instantiate the objects and "bind" them: Initiator initiator; Target target; initiator.bind(target); target.bind(initiator); I hope you are seeing where we are going with this. What has been done above is a crude equivalent of sc_port binding. There is one problem however with the approach above. What if the class "Target" doesn't implement the target_if directly? Like so: class TargetGrandChild : public target_if { public: void transport(int i) { // Implement the interface.. cout << "Got " << i << " from initiator (in grand child)" << std::endl; } }; class TargetChild { public: TargetGrandChild gch; /* Other stuff.. */ }; class Target { public: TargetChild ch; /* Other stuff.. */ }; One way to deal with this is to change the way bind function is called: initiator.bind(target.ch.gch); This is ugly. Firstly, it makes the client of bind function dependent on an internal design aspect of the "Target" class. For example, if the Target class changes tomorrow (to let the TargetChild implement the "target_if" directly), the bind function call needs to change. Also, to allow the client to call the bind function as above, the elements "ch" and "gch" must be made public, which may not be necessarily a good thing. A way out is to have an additional indirection. Let us call this as simple_export (a very simplified version of sc_export): class simple_export : public target_if { public: void transport(int i) { // One level of indirection p_real_target->transport(i); } void bind(target_if &_if) { p_real_target = &_if; } private: target_if *p_real_target; }; The new version of the Target class now looks like the following: class TargetGrandChild : public target_if { public: void transport(int i) { // Implement the interface.. cout << "Got " << i << " from initiator (in grand child)" << std::endl; } }; class TargetChild { public: TargetGrandChild gch; /* Other stuff.. */ }; class Target { public: simple_export port; private: // private is ok TargetChild ch; /* Other stuff.. */ Target() { // Tell "export" where the real implementation is port.bind(ch.gch); } }; The initiator will be "bound" to the target like so: initiator.bind(target.port); So for the simple_export to work, you need two binds: First is where the initiator is bound to the simple_export instance Second is when the "real" implementation is bound to the simple_export instance The simple_export class acts like a bridge. It forward the calls from the initiator to the "real" implementation. In case the "Target" itself implements the interface, the bind would look like: class Target : public target_if { public: simple_export port; private: // private is ok TargetChild ch; /* Other stuff.. */ Target() { // Tell "export" where the real implementation is port.bind(*this); } }; I hope this explains the line you pointed out in the code. The TLM socket has both a port and an export. Please note that the code snips above does not correspond to how OSCI simulator actually implements sc_port/sc_export!
  14. 1 point
    The "sc_export" part of each TLM-2.0 socket needs to be bound to an interface (tlm_bw_transport_if for an initiator, tlm_fw_transport_if for a target socket) in order to provide the implementation of the communication link. As you can see in the referenced example, the Initiator class inherits and implements the backwards interface: struct Initiator: sc_module, tlm::tlm_bw_transport_if<> // Initiator implements the bw interface As a result it can act as the "channel" to provide the behaviour for the sc_export part of the initiator socket. This pattern is a quite common idiom in the TLM-2.0 world, at least if you don't use the convenience sockets. So to answer your question: It's not the "module part" that is bound to the socket. The Initiator is-a backwards interface as well, and this "interface part" is bound. Greetings from Oldenburg, Philipp
×