Jump to content

Roman Popov

  • Content count

  • Joined

  • Last visited

  • Days Won


Roman Popov last won the day on December 14

Roman Popov had the most liked content!

1 Follower

About Roman Popov

  • Rank
    Advanced Member

Recent Profile Visitors

447 profile views
  1. cannot understand error

    Looks like the error is inside Xilinx libraries internals. I suggest you should ask on Xilinx forums.
  2. port binding

  3. port binding

    Does "Table 60—Permitted socket bindings" in SystemC standard works for you?
  4. adder - hierarchy- output issue

    Duolos website definetely has examples with mode than two modules or more than two signals: https://www.doulos.com/knowhow/systemc/tutorial/modules_and_processes/ What do you mean by "derived module" ? Word "derived" in C++ and SystemC is used in a context of OOP, i.e. class can be derived from one or more base classes.
  5. adder - hierarchy- output issue

    Yes. Read about signals and ports. You just trying use brute-force instead of learning before doing.
  6. adder - hierarchy- output issue

    SystemC does not allow to change structure of design during simulation. Modules and other sc_objects like ports and signals could not be created during simulation. Check IEEE SystemC standard , Chapter 4: " Elaboration and simulation semantics " for more details.
  7. Bug at file sc_trace_file_base.cpp

    GtkWave renders correctly with 500 ps timeunit. But commercial viewer I have crashes.
  8. Bug at file sc_trace_file_base.cpp

    I've looked again at VCD generated by 2.3.1. It has no time unit mentioned at all. So it is actually correct : if you substitute 0.5 NS as a timeunit, you will have correct timestamps. Gtkwave renders them as 1ns. But other VCD viewers I've tried just don't show time unit at all in this case.
  9. Bug at file sc_trace_file_base.cpp

    Thanks a lot for reporting! I can confirm that 2.3.2 does not supports v that it is not a multiple of 10. I agree that set_time_unit API is bad (error-prone), and should be changed. Good news that you've received a runtime error early and did not spent lots of time . Do you need support for fractional timeunits? Or just more clear API? I've also checked 2.3.1. It does not works properly with 0.5 either: int sc_main (int argc, char **argv) { sc_trace_file* tf; tf = sc_create_vcd_trace_file("traces"); sc_signal<int> isig{"isig",0}; tf->set_time_unit(0.5, SC_NS); sc_trace(tf, isig, "isig" ); sc_start(0.5, SC_NS); isig = 1; sc_start(2.5, SC_NS); isig = 2; sc_start(3.5, SC_NS); isig = 4; sc_start(3.5, SC_NS); sc_close_vcd_trace_file(tf); return 0; } VCD is incorrect: $date Dec 05, 2017 11:50:52 $end $version SystemC 2.3.1-Accellera --- Dec 5 2017 11:40:15 $end $scope module SystemC $end $var wire 32 aaaaa isig [31:0] $end $upscope $end $enddefinitions $end $comment All initial values are dumped below at time 0 sec = 0 timescale units. $end $dumpvars b0 aaaaa $end #1 b1 aaaaa #6 b10 aaaaa #13 b100 aaaaa So 2.3.2 is better. But not perfect :(
  10. How to use sc_fifo vector

    Hello, SystemC is a C++ library. You should master C++ before learning SystemC, which is just a C++ library. It will be a wisely spent time, since C++ is used in many industries. After you learn C++ you will be able to understand and fix errors in your code.
  11. As I understood, currently only Accellera members have access to SystemC GitHub repos. ( I heard that there are plans to make SystemC development open to general public, but we are not there yet) So if your company is Accellera member, you can ask your account manager to request an access for you. Meanwhile the best thing you can do is to stay on 2.3.1 until bugfix for 2.3.2 will be published.
  12. Looks like specific to multi_passthrough_target_socket. Simple sockets work fine with hierarchical bind.
  13. From my point of view it is a regression. Standard says explicitly that one hierarchical bind is allowed for multi_passthrough_target_socket. I will put a bug to tracker.
  14. Elaboration time sized array

    I thought about it. There are two issues: 1) Raw arrays do not store size. This is inconvenient: for debugging purposes I often want to visualize contents of RAM. But without knowing a size it is not possible to create a pretty printer. (Except for non-trivial constructible types, that actually store size, as specified by GCC/Clang ABI https://itanium-cxx-abi.github.io/cxx-abi/abi.html#array-cookies ) 2) When modeling ROMs it will require to know memory contents at compile time: std::unique_ptr<const int[]> rom(new const int[3] {1,2,3}); As I understand I can't create initializer list {1,2,3} at runtime. So I can't initialize ROM contents from file.
  15. Elaboration time sized array

    Hello, I need a data-structure to model RAMs and ROMs that are defined at elaboration time. For example when size and contents of memory are read from file during model construction. I thought that sc_vector can be a solution, but looks like it has no specialization for members that are not sc_objects. Any suggestions? Currently I'm thinking of creating a wrapper over std::vector with following api: template<typename T> class sc_elab_vector : public sc_object { std::vector<remove_const_t<T>> m_vec; //... }; sc_elab_vector<int> ram; sc_elab_vector<const int> rom; SC_CTOR(mod) { // ELABORATION ram.resize(42); // OK ram[0] = 42; // OK, for example models RAM on FPGA, initialized on reset for(int i = 0; i < 42; i++) rom.push_back(i); // OK rom[0] = 42; // OK } void test_thread() { // SIMULATION ram[0] = 42; // OK ram.push_back(1); // Runtime error rom[0] = 42; // Runtime error } Concept looks pretty generic for me, probably something like that should be standardized? Currently for SystemC synthesis we only have Compile-time sized arrays. But elaboration-time programming is more flexible than compile-time metaprogramming