Jump to content

Eyck

Members
  • Content Count

    197
  • Joined

  • Last visited

  • Days Won

    61

Everything posted by Eyck

  1. Do you have an error message or stacktrace (gdb)? 'simulation [...] crashes suddenly' is very generic and can have manifold root causes... Where do you execute the code? You can only create sc_object based elements during elaboration. But if PortElement is a plain C++ class I have no idea why it fails...
  2. I guess your problem stem from a particular implementation detail in SystemC: if you have an inheritance hierarchy you should declare all constructor parameters as ' my_module( sc_core::sc_module_name const& nm). For the leaf module can leave it as 'MyModule(sc_core::sc_module_name nm)'. In the second case a copy of the module name is created which manipulates the hierarchy stack of the kernel. I assume this way you srew up your design. It is save to always pass the sc_module_name by const reference in the constructors. This would makeup for a good rule in a modleing guideline
  3. Well, sc_fifo is not TLM. For your example the basic question is: what is the protocol on fifo_out? Should it be clock-based? Valid-Ready signaling? So your queastion and example is too generic and broad. If you are looking for an example to translate from TLM2.0 to pin level of an Amba AHB protocol you may have a look here: https://git.minres.com/SystemC/SystemC-Components/src/branch/master/incl/tlm/ahb/bfm and https://git.minres.com/SystemC/SystemC-Components/src/branch/master/src/tlm_ahb_bfm_initiator.cpp as well as https://git.minres.com/SystemC/SystemC-Components/src/branch/mas
  4. AFAIK the first version should properly instantitate. Maybe you mess up within the constructor ... Since this is not really source code it is hard to tell any further. Maybe you can provide a silghtly mor concrete example e.g. on https://www.edaplayground.com/
  5. Basically yes but just add_attribute is not enough. From the top of my head: you need to declare in your sc_module: sc_core::sc_attribute<A*> attr{"attr", nullptr}; sc_core::sc_in<bool> pin{"pin"}; in the constructor of your sc_module you need to add the attribute to the sc_object/sc_port: pin.add_attribute(attr); via attr.value = new A(); you can assign a value. This way the attribute can be found e.g. via the SystemC object tree (sc_core::sc_get_top_level_objects() ). Alternatives depend of your goal. One option would be to use CCI, esp. cci_para
  6. SCV does not contain an the respective overloads for scv_introspection and _scv_distribution. Therefore there is afaik no way to simply randomize a vector. As a workaround you might use the randomization for plain C-style arrays.
  7. Just to add 2 cents to @David Black proposal: If the instantiation is exepensive you could fork() (https://en.wikipedia.org/wiki/Fork_(system_call)) your programm after instantiating the design. Basically you create a new OS process as copy of the current one and here you can continue the simulation. But in essence it is the same approach as David described.
  8. My point was more of a generic nature and more related to modeling guidelines. If your initiator/test_producer has many signals some of them might belong 'logically' together as they are written at the same time. E.g in AHB you have HADDR, HTRANS, HBURST, HWRITE, etc. Instead of declaring them as sc_out<sc_dt::sc_logic> xxx or alike: sc_out<sc_dt::sc_lv<32>> HADDR; sc_out<sc_dt::sc_lv<4>> HTRANS; sc_out<sc_dt::sc_logic> HWRITE; . . . it would make sense to do it this way: struct ahb_req { sc_dt::sc_lv<32> HADDR; sc_dt::sc_lv<4&
  9. You cannot call sc_main directly from main(). main() comes with the SystemC reference implementation (SystemC simulator) and initailizes the simulation kernel. You miss that in your main function, you migh tlook it up at https://github.com/accellera-official/systemc/blob/master/src/sysc/kernel/sc_main.cpp and https://github.com/accellera-official/systemc/blob/master/src/sysc/kernel/sc_main_main.cpp Despite that, you cannot call your sc_main twice. The simulation kernel in the reference implementation is not re-entrant. Thus the LRM states in section 4.3.4.2 Function sc_start: in t
  10. You cannot bind an output port to an input port. Ultimately each port must bind to a signal either hierarchically (this is where port to port binding can is used) or directly. So you need to define signal for each of the test_module output ports and bind the sc_out and sc_inout ports to it. 2 remarks: you should use sc_in instead of sc_inout to indicate the purpose clearly sc_out is just a child of sc_inout to reduce the number of output ports (and hence signal) you might want to group signals logically belonging together into structs. Those can be used as data typs of si
  11. You may check section 14.12 Data length attribute and '14.15 Streaming width attribute' in the LRM. The first says: while the second states in paragraph 😄
  12. AFAICS you don't increment the index i in the while loop. But your code is way to complex.: std::ifstream ifs("TEXT.txt"); if(ifs.is_open()){ int buf = 0; for (int i = 0; i < MEM_DEPTH; i++) { ifs >> buf; buff_1[i]=buf } } ifs.close(); should replace everything from fopen() until fclose(). And you should avoid using macros, they will bite you. '#define MEM_DEPTH 20' should become 'const size_t MEM_DEPTH=20;'.
  13. Not directly. You need to bind Out to a vector of signals of type bool and create a method being sensitive to all signals in the vector. This method then does the conversion and drives the ALUout signal.
  14. Actually there might be a more versatile approach using Python as 'wrapper' and glue for SystemC. There was last year a paper at DVCon Europe about PySysC: http://events.dvcon.org/events/proceedings.aspx?id=278--2 (the repo can be found here: https://git.minres.com/SystemC/PySysC) This allows to use wxWidget, gtk, or QT to interact with the SystemC simulation (the paper shows some prototype I wrote for internal use).
  15. SCML is not open-source and if you look at section 1 of the LICENSE file the folks already violate the license by providing the source code. So you are left with 2 options... For simple busses you can go with the TLM2.0 base protocol which works fairly well. SCC supports non-blocking accesses at the registers and memories so you are left to get or write some interconnect component. AFAIK there are no bus implementations available as open-source to be used out of the box. But you are invited to contribute e.g. to the SCC (you may contact me directly via github).
  16. That is a typo as the method() function shows. it Should read sc_out<sc_uint<2> >
  17. The example you are refering to is for SystemC 2.0 and more over has errors. Actually this is a bad example to start with. the sc_start() in line 17 needs to be commented out for 2 reasons: a) it doesn't make any sense and b) it runs elaboration and tracing (VCD) needs to be initialized before that. After elaboration you cannot add signals for tracing anymore sc_start() (lines 32, 34, 40, 42, 47, 49, 56 58) has to be called either without any arguments (so it runs to the end) or with a duration in terms of sc_time like this: sc_start(1, SC_NS); My recommendation
  18. Actually using new is not recommended at all. You should do something like: std::array<sc_dt::sc_uint<32>, MEMORY_DEPTH> mem; or (C++11): std::vector<sc_dt::sc_uint<32>> mem{MEMORY_DEPTH}; As far as I can see you try to initialize mem in-class (during declaration) and this is not allowed in C++. You can do this only in the constructor. And if you need to use new, don't forget to delete.
  19. Sure. Just add a method reading all bool sc_in and write to the output. You need to make it sensitive to all inputs Something like: SC_MODULE(conv){ sc_vector<sc_in<bool> > input{"input"}; sc_out<bool> ouput{"ouput"}; SC_CTOR(conv){ SC_HAS_PROCESS(conv); SC_METHOD(method); for(auto& in: input){ sensitive<<in; } } void method(){ unsigned res = input[1]?2:0+input[0]?1:0; output=res; } };
  20. First: I'm not going to solve your problems. I only propose possible solutions. So don't expect read-to-use models Second: doing wait() in an SC_THREAD or SC_CTHREAD creates an implicit FSM. I guess this is not what you want. And as you already noticed, it does not solve you problem. You have a syncronous design and you should model it like that. Third: if your latency is not what you want you need to change your model. Maybe there is a stage to much, maybe there aren't enough. This is left to the modeler....
  21. Just as explanation: pos() returns an event_finder (a proxy object which allows to use an event which is not yet available) while posedge_event() returns the event itself. And the operator|() is ony defined for sc_event.
  22. You are writing to ports in the constructor of server. At this point they are not bound. Since you initialize them in the beginning of your thread this is not needed anyways. Aside of that you also do not need the sensitivity list for the monitor thread as you never use the default sensitivity (by using wait() ). And if you use C++11 or newer you should use In-class member initializers which eases the naming of signals (and you should name them to make debugging easier): sc_in<bool> begin1{"begin1"}, begin2{"begin2"}, begin3{"begin3"}; sc_in<bool> end1{"end1"}, end2{"end2"
  23. Eyck

    Queue fifo

    Actually you created an array of inputs of type int, not a pipe. Without more code it is hard to give any advise
  24. You should seriously read the SystemC standard or related books. Neither SC_METHOD nor SC_THREAD pass time, time advances only in the SystemC kernel and the kernel returns control to them at certain time points. The difference is that SC_THREAD preserves state when returning control to the kernel by calling wait(). SC_METHOD cannot preserve the state (it is always called as a function) and is therefore not allowed to call wait(). next_trigger() tells the SC kernel when to invoke the SC_METHOD next time. Calling next_trigger() several times in the same method as you do it is meaningle
×
×
  • Create New...