Jump to content

Eyck

Members
  • Content Count

    197
  • Joined

  • Last visited

  • Days Won

    61

Everything posted by Eyck

  1. There is no such thing as CPU TLM modeling. Usually you write a C/C++ processor model with the needed accuracy (instruction accurate, cycle approximate, cycle accurate) and wrap it in a way that you translate memory accesses into TLM socket accesses. Along with that you need to manage to syncronization of the time of your model and the SystemC time (to run e.g. in loosly timed mode). Another task is to take the returned execution time of the bus accesses into account for the execution of the CPU model. This involves also the selection and implementation of the accesses (DMI & blocking or n
  2. It would be good if you could provide a description of the problem you see (or better error messages or alike) when building the unit. I see 2 things in your code: the statement labeled with '// sensitivity list' tm << START << TIMEOUT << CLOCK; is wrong. You did this already in the constructor (SC_CTOR(timer)) of your module. The sensitivity list of your timer is wrong. The thread should only wait for the positive edge of clock, start is a data signal which is sampled/read upon the rising edge of the clock I suggest to change the implementation from
  3. You cannot have a delay in end_of_elaboration() or start_of_simulation() since those are callback functions outside of the (timed) simulation cycle. One thing you could do is to start the gdb within a SC_THREAD where you have a wait(SC_ZERO_TIME) to let the updates settle: void start_gdb_thread(){ wait(SC_ZERO_TIME); start_my_gdb(); } BR
  4. You are initailaizing fl_ptr during consturction, not during execution. In generator.hpp you have: float* fl_ptr = reinterpret_cast<float*>(dmi_mem); //ovo sam ja pisao This never updates fl_ptr to the actual value of dmi_ptr. Actually your access should look like: if (dmi_valid) { dmi_mem = dmi.get_dmi_ptr(); //dmi_mem is pointer to ram[] array in memory.h float* fl_ptr = reinterpret_cast<float*>(dmi_mem); for (int i = 0; i != 20; ++i) fl_ptr[i] = 12.7; }
  5. Your sc_trace function is a member function of the TraceList class and cannot be called like the sc_trace functions coming with the SystemC reference implementation. Those are free functions in the sc_core namespace. Moreover your sc_trace implementation is non-static so it cannot be used without a TraceList object. You need to move the function out of the class scope. Basically this is a valid approach to setup complex types. But under performance considerations I would suggest to use a different container. Best choices are std::vector or std::dqueue. And if you are using C++ 11 I w
  6. You need to connect the output port to a signal and attach a method to the signal driving the multiple output ports. So something like this: template<> struct Carries<1> : ::sc_core::sc_module { sc_vector<sc_in<bool>> a, b; sc_in<bool> rIn; sc_out<bool> p, g, rOut; sc_vector<sc_out<bool>> carries; CarryPropGen pg {"PG"}; SC_CTOR(Carries) : a {"vectA", 1}, b {"vectB", 1}, rIn {"rIn"}, p {"p"}, g {"g"}, rOut {"rOut"}, carries {"vectCarries", 1} { pg.a(a[0]);
  7. If you need more flexibility than systemc-clang allows you may use libclang. This is a Python binding of the Clang library (some intro can be found here: https://shaharmike.com/cpp/libclang/ or here: https://eli.thegreenplace.net/2011/07/03/parsing-c-in-python-with-clang). This way you can easily deal with the Clang AST and its cross references and alike. Best regards
  8. Without concete code it is hard to give any advise. But it looks like that you redeclare a member function of your original module. BR
  9. Again, in your case you model a burst read which means in reality data gets transfered in several beats (32 in your case). Since your model does not deal with timing you wont notice that, all you see is that your data gets transfered. Look, TLM2.0 implements a generic bus protocol. Most of the real-world protocols have a so called burst transfer (e.g. checkout the AMBA specs). So the way to model this in an abstract way is to have a bust with and the amount of bytes being transfered in on bus transaction not in one beat. This way it is also possible to describe byte and half-word transfer
  10. Well, as the name says it is the data transfer with of the bus you are using. So in your case sending 128byte of data across bus having 32bits means you model a burst access having 32beats. Having said this you should notice that the bus width determines mainly the timing of a transaction. Unless you use timing for your transaction and rely on it (e.g. for performance modeling) it should not bother you. Best regrads
  11. It is spelled 'sc_spawn_options' so you missed the trailing s
  12. Without further context it is hard to give a helpful answer. You can try to do event1.notify(SC_ZERO_TIME)
  13. boost::variant would be an option or you use a union. In the latter case you loose the type safety...
  14. If you can you should do it this way. But if the source of the irq is outside of the LT domain you can only reduce the quantum.
  15. In this case you would need to add some syncronization at the ingress and the egress of the NoC. One should run with the clock of the sender and the other with the clock of the receiver. Since SystemC does not have an 'undefined' state the syncronization between ingress and egress is fairly simple depending on the way you model the way the phits/flits are send thru the NoC BR
  16. Well, this topic is not easy to solve. In C++ each template instantiation (like sc_in<bool>) is a separate class in the class hierachy. The common base class is sc_port_base and this is in this context more or less useless. Actually there I see 2 options: You store a sc_port_base pointer in your map and upon each write you check for the typeid of the specific template instance and down-cast it using dynamic_cast. This is inflexible and needs additional coding if you want to use new type. You store a writer function in your map which knows how to translate a generic value
  17. Another option is to use https://github.com/Minres/SystemC-Quickstart as a starting point. This gives you a cmake based project using conan to manage your libraries incl. SystemC (see README.md). Then you have 2 options (I call them 'Eclipse first' and 'CMake first'): either you install the cmake4eclipse Plugin (https://github.com/15knots/cmake4eclipse) via the Marketplace (https://marketplace.eclipse.org/content/cmake4eclipse) or you use cmake to generate your Eclipse project files via cmake -G"Eclipse CDT4 - Unix Makefiles" . I personally prefer the first approach since the latter ha
  18. Another option would be to use a resolved signal and connect all output ports to it. But this is already about techincal implementation options. The question to me is: what would you like to model? Is this the right way to model the intend? Best regards
  19. Well, your interrpt is set in a SC_THREAD or SC_METHOD and these are active when the ISS thread sleeps. In that sense the sensing is immediate when the ISS thread wakes up. But since the ISS thread is ahead of the SystemC simulation when the irq is activated in SystemC there is no way to have an immediate sensing. This is the accuracy you give up to gain simulation speed: the delay until the ISS acts on an external event is determined by the quantum. On solution could be to use a dynamic quantum which changes in the course of the simulation: you start with a large quantum until you reach a ce
  20. Each type of extension has an automatically assigned ordinal number which is available per extension as ID in the base class tlm_extension. So in your case you have 2 tlm_extensions defined somewhere. Under the hood this ID is used as an index into the m_extension array of the tlm::generic_payload. Best
  21. @Philipp A Hartmann you are right, '|=' would imply and or list.
  22. @Khushi This is not a good solution since this way you enforce a quantum from a component maybe deep in the hierarchy. This sacrifies compatibility and makes reuse pretty difficult. You should follow the guidlines outlined by David.
  23. You would want to use an sc_event_and_list. See IEEE1666 section 5.8. As its intended use is with next_trigger() and wait() you would need to move the sensitivity into your method. So the constructor part becomes SC_METHOD(func2); and func2 should something like (snippet of your module): sc_core::sc_event_and_list ev_list; void end_of_elaboration(){ ev_list |= clk.posedge_event(); ev_list |= nreset; } void func2(){ next_trigger(ev_list); // your code here ... }
  24. Well, the global quantum is as the name says global. So there is only one variable and it should be set at on central point. In many cases this is sc_main but it might also be some configuration unit. This depends on the requirement and implementation. I would refrain to set it in the initiators as then you dont know which one is the last one to set the quantum esp.if they want to set it to different values. Usually the leads to hard-to-debug problems. Best regards
  25. Actually in my experience mixing various C++ standard levels is not advisable as they imply changes in libstdc++ which may lead to all sort of issues. So my general recomendation is to have the same setting in all libraries. Hence this general apporach. And conan_set_std() conan_set_std() will set the standard level to C++14 in this example.
×
×
  • Create New...