Jump to content

David Black

Members
  • Content Count

    455
  • Joined

  • Last visited

  • Days Won

    101

Everything posted by David Black

  1. I don't know where you got that specification, but it looks suspiciously like a university project. Also, whoever is using the word 'static' is not using the word correctly. Nor would or should that approach ever work. The diagram implies a hierarchy of SystemC modules with a cluster module containing several DME-array modules, which in turn contain DME, DMA and MemType2 modules. These could of course be modeled without the illustrated boundaries, but it would add unnecessary complication. The outermost module (Cluster module) would have one each of an initiator and target TLM-2.0 socket (NOT
  2. Nothing wrong. Your output will be available after the delta cycle completes. You can view the new value in the next delta cycle. The problem for you conceptually is that you think 'S_val_out = expression' is a blocking statement. In other words, you expect the value to be transferred to the current value of S_val_out at the end of the assignment. Actually what is happening is akin to: S_val_out->write( A_val_in->read() +B_val_in->read() ); External to your sum class object, the S_val_out is bound to a channel sc_signal<T>, where the write() method is implemented. T
  3. No problem. Glad you got what you needed. For what it's worth, the return value from system calls is generally 0, 1 or 256. Believe I read somewhere that values above 256 are reserved for OS. 0 means success, and all others mean failure. I generally return 1 to indicate "errors detected while running".
  4. Yes and no. SystemC ports (e.g., sc_port<T>) sit on the boundary of a SystemC module to allow communication with external channels. They point outward from a module towards the channel. SystemC exports point inward towards a channel within the module or within submodules via additional export. sc_in<T> is a partial template specialization of sc_port using an sc_signal_in_if<T>. So the answer to your question depends on where the ports are located vs. the module and channel. A picture would help. What books on SystemC have your read?
  5. sc_fifo<T> is a channel representing hardware FIFO behavior. sc_fifo_in<T> is a specialized port used to access an sc_fifo channel. Almost identical to sc_port<sc_fifo_in_if<T>> Suggestion: Read the freely available SystemC standards document (IEEE-1666-2011) or obtain a book on SystemC. It's all very clear there.
  6. @GUESTWhen you say the size of each FIFO is an input, do you mean to say that during simulation the maximum legal size of the FIFO's is a dynamically changing input? Or is it the case that each FIFO is a different maximum size that is determined at statically at time zero before the simulation gets beyond the elaboration phase? Your answer to this has a critical impact to the response. sc_fifo is a static hardware feature and the nature of hardware is that it may not be changed after fabrication (elaboration is the simulator terminology). If you are looking to model varying software inputs, yo
  7. Correct. Ports bind to channels located outside the module containing the port.
  8. I don't think sc_vector supports non-sc_object types (pointers are not sc_object's). Maybe you should describe your use-case first, so we can make some sensible solutions.
  9. I can get non-zero values. <https://www.edaplayground.com/x/Zve> If you had read Doug Smith's paper, you would have found the solution, which I put in the above link. Run multiple times and you get multiple seeds. Note: You need to be aware how random seeds are established in SystemVerilog to get this to work properly. So move that function into a package and call it from whatever processes you desire.
  10. Let me start by observing that you probably don't want to initialize an input port. After all, inputs observe information from outside the module. So I will assume you mean an output port. If need be, you could change to use an sc_inout<T> port, but you might create a nasty race condition. The cleanest and most general approach is to write to the port during the start_of_simulation phase. How? Just create a override method, void sc_start_of_simulation(void), in your module. SC_MODULE( Example ) { sc_out<bool> oport{"oport"}; sc_signal<int> local_sig{"local_sig
  11. Even if you do get $system to return 0, using date to choose a random seed has problems as was discussed in Doulos' Doug Smith's excellent white-paper on Random Stability <https://www.doulos.com/media/1293/snug2013_sv_random_stability_paper.pdf>. You would be much better using the TRNG (Truly Random Number Generator) found on most modern processors, and accessible in most OS's including Linux. Better yet, you can use the random_device from the C++11 <random> library as described here: https://www.cplusplus.com/reference/random/random_device/entropy/. Here's some sample co
  12. Using the same socket for multiple modules indicates a fundamental conceptual error in how modules, threads and SystemC work. Multiple issues: 1. Sockets are intended to model hardware communication points, but not actual wires. Modules are intended to model silicon hardware blocks. Silicon cannot be assigned (copied or moved within an implementation). Modules are intended to each have their own sockets/ports and are disallowed specifically from sharing. 2. You can have multiple initiator modules communicate with a single target module using a multi socket. If you expect, initiators
  13. Use the initializer list of the constructor. Or if you are using a compiler with C++11 support, you can use uniform initialization syntax. Easy.
  14. There are numerous ways you can address this: Make the variable public (breaks encapsulation) and provide the object reference. Provide accessor methods to allow restricted access (best) Make the attribute static and public, but then you cannot have a different per instance. Effectively, a class specific global variable. (dangerous)
  15. Three thoughts might be helpful for you to consider: You could of course use next_trigger() in SC_METHOD: SC_MODULE(HARD_WAY) { sc_in<bool> clock, clock_enabled; SC_CTOR(HARD_WAY) { SC_METHOD(gated_method); sensitive << clock; ... } ... void gated_method(void) { if ( clock_enabled and clock.posedge() ) { // Normal operations } else { // Wait until clock is re-enabled next_trigger( not clock_enabled ); } } The better way is to use sc_process_handle::disable() and enable() #define SC_INCLUDE_DYNAMIC_PROCESSES #incl
  16. @omaima RTFM please. It's all in the README and related files. Better yet, signup and take a class from somebody.
  17. If something is not mentioned in the standard, then you should assume it's an internal implementation thing and not to be used by the end-user. Use the syntax of the standard and don't use the syntax of the implementation as your guide. The bug is likely that somebody provided an extra parameter at all.
  18. Or... Use pre-randomize to establish the size and create the array, then you can constrain element creation normally. Determining the size is usually less complex than constraining the contents, so this approach may be more flexible.
  19. Have you tried using CMake installation? That usually works the easiest for me. Of course you need to install cmake (https://cmake.org/download/) and then there's a separate INSTALL guide under the SystemC cmake subdirectory.
  20. Since sc_clock is really just an ordinary SystemC citizen, there is no way to distinguish it per se. Newer versions of SystemC (2.3.3 ff) have sc_event::triggered(). So you could check clock->default_event().triggered(). Don't add a clock to your design. Simulation will be faster. If you need to wait 500 clocks use: wait( 500 * PERIOD ); You might consider looking at my design of no_clock here> https://github.com/dcblack/no_clock
  21. This appears to be a problem for Mentor Graphics since UVM-1.2 compiles fine with their other tools. It may be a limitation of ModelSim. As stated earlier, if you want to use UVM for learning/experimentation, then https://www.edaplayground.com is available. On the other hand, if you are wanting to do a real project, then you must purchase a full blown simulator from a commercial vendor.
  22. @Eyck is correct. It would be a major rewrite of SystemC to allow this. If you are trying to launch multiple simulations (sequentially) perhaps with different parameters, you need to do that from a script. If you are super insistent you have to do it under C++, you could try the following: // Compile your main SystemC as run.exe and place it in the same directory as this program int main(void) { int errors = 0; errors |= system("./run.exe -option 1"); errors |= system("./run.exe -option 2"); return errors; } Or just use your favorite script language (bash, perl, zsh, csh, pytho
  23. First, you have an error in your example corrected below: for(int i=0;i<prt_input.size();i++) sensitive << prt_input[i]->value_changed_event(); } Second, you can use a recent addition to SystemC (if using version 2.3.3 or later) using the new sc_event::triggered() method, which returns true if the event happened in the immediately preceding delta-cycle. You would simply apply this to the default_event() method present in most channels. A less general approach could also be used with sc_signal channel, which has always provided the event() method for the same effect, but
  24. TLM (Transaction Level Modeling) is focused on communication (interconnection) of SystemC models. So your question is slightly irrelevant. From what you indicate, I would say that AT modeling style would accomplish what you are interested in. Sockets are an almost essential aspect of TLM as they simplify modeling and can provide information about the transaction. As to what metrics you can get, that is up to you. SystemC is not a prepacked set of subroutines, nor is it a narrowly focused on one type of analysis. SystemC is a methodology using C++ to model any variety of ideas using an ev
  25. Approximately-Timed (AT) models provide decent timing accuracy for modeling purposes. Common use cases include architectural analysis (cost vs performance). AT models are used to understand the effects of interconnect and bus protocols on overall performance. Loosely-Timed (LT) models provide for simulation performance (i.e. fast), but often use techniques that sacrifice modeled timing accuracy. The intent is for use in software development on virtual platforms. Techniques used include Temporal De-coupling coupled a notion of a Quantum, and Direct Memory Interface. LT models usually try t
×
×
  • Create New...