Jump to content

David Black

Members
  • Content Count

    455
  • Joined

  • Last visited

  • Days Won

    101

David Black last won the day on September 24

David Black had the most liked content!

About David Black

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

2,447 profile views
  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
×
×
  • Create New...