Jump to content

Eyck

Members
  • Content Count

    118
  • Joined

  • Last visited

  • Days Won

    33

Eyck last won the day on November 13

Eyck had the most liked content!

5 Followers

About Eyck

  • Rank
    Advanced Member

Contact Methods

  • Website URL
    http://www.minres.com/

Profile Information

  • Gender
    Male
  • Location
    Munich, Germany

Recent Profile Visitors

730 profile views
  1. 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 would replace the while loop with a range based loop, something like: for(auto& val: var.lst) { // use namespace, compiler otherwise chooses wrong function sc_core::sc_trace(tf, val, nm + std::to_string(pos++)); }
  2. 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]); pg.b(b[0]); pg.r(rIn); pg.p(p); pg.g(g); pg.rOut(rOutS); // What I would like to do. SC_METHOD(propagate); sensitive<<rOutS.value_changed(); } sc_core::sc_signal<bool> rOutS; void propagate(){ rOut.write(rOutS.read()); carries[0].write(rOutS.read(); } }; BR
  3. 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
  4. 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
  5. 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 transfers. HTH
  6. 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
  7. It is spelled 'sc_spawn_options' so you missed the trailing s
  8. Without further context it is hard to give a helpful answer. You can try to do event1.notify(SC_ZERO_TIME)
  9. boost::variant would be an option or you use a union. In the latter case you loose the type safety...
  10. 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.
  11. 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
  12. 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 (like int or double) to the particular value. This might by a lambda which captures the port reference and therefore 'knows' hwo to write to this port. But in this case you would loose type safety as you have to store a generic function unless you can use std::variant. So your map would have to be declared as typedef std::map<std::string, std::function<void(unsigned)> Map0 or (C++17): typedef std::map<std::string, std::function<void(std::variant<bool, sc_dt::sc_uint<2>>> Map0 I personally would go for option 2 as it is simpler and more flexible... HTH
  13. 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 has one drawback: if you add directory or files you have to add them in CMakeLists.txt, run the generator again and the have an updated Eclipse project.
  14. 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
  15. 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 certain point in simulation (e.g. until you booted the system) and then you lower the quantum to get more accuracy.
×
×
  • Create New...