Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Yesterday
  3. 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
  4. No for a port; however, you could accomplish the goal with an sc_port< sc_signal<T> >
  5. Thanks @Asdruv for reporting this bug! I have forwarded your report to the LWG. Best regards, Torsten Maehne
  6. My advice: start with sc_fifo, learn how it works, learn it's source code. Then write your own handshake channel using same principles.
  7. I am trying to make a circuit which computes the carries for an addition. In this piece of code, I would like to connect the output port rOut of the submodule pg to two output ports (rOut and carries[0]) of the parent module, so both get the same value. 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(rOut); // What I would like to do. pg.rOut(carries[0]); // } }; However, I get the error (E109) complete binding failed: 2 binds exceeds maximum of 1 allowed: port 'Carries.PG.port_5' (sc_out). I also tried with a signal, with and without the writer policy SC_MANY_WRITER, as it was suggested by someone on a forum, but it didn't work either. I am new to SystemC and while I understand the error, I don't really understand why this can't work and how to do it differently. So, is there a way to bind one sub-module output to multiple sc_out of the parent module, and how?
  8. Last week
  9. Write your own channel, which is really quite simple(*). You could provide a template specialization of sc_fifo as a convenient and familiar interface. * It's just C++. We show students how to write their own FIFO channel as part of our Fundamentals of SystemC course <https://www.doulos.com/content/training/systemc_fundamental_training.php>.
  10. Hi, I'm looking for a simple channel to use in system-c between sc_modules for the purpose of hardware modelling. The functionality I'm looking for is basically an sc_fifo with size 0. A write should be blocking until the other side does a read. And a read vica-versa (should block until the other side writes). I want the functionality as if I would implement a valid/ready handshake with the data I'm transferring trough the port. Does such a channel exist, and if not what are alternatives I could use ? Trying to keep it as easy to use and as little error prone as possible. I'm not looking to synthesis the code (purely for modelling). Thanks a lot for your help :) Michael
  11. In general avoid using multiple inheritance for aggregation. It is possible, but has many drawbacks and no major benefits. Now I regret that I've written original post, but at that time I had no enough experience myself. Now, if we read any object oriented design book, we will learn that inheritance usually means "is-a" relation ship, and "has-a" relation ship is expressed by composition. Translating into HW modeling : what we want to express is that "some_module has port bundles", and not "some_module is port bundles". We can still use single inheritance in limited cases, for example if all modules in design have clock and reset, we can have a common base class like class clocked_module : public sc_module Back to your example. I recommend to convert your port bundles into modules: struct if_inputs : sc_module { sc_inout<sc_uint<4>> SC_NAMED(R_OP_MODE); sc_inout<sc_uint<8>> SC_NAMED(R_PRESET_MANUAL); if_inputs(sc_module_name){} }; struct if_outputs : sc_module { sc_inout<sc_uint<2>> SC_NAMED(T_BIT); sc_inout<sc_uint<4>> SC_NAMED(T_OP_MODE); sc_inout<sc_uint<8>> SC_NAMED(T_PRESET_MANUAL); if_outputs(sc_module_name){} }; And now you can aggregate any number of them inside monitor. Even have a vector of port bundles: class monitor : public sc_module { public: if_inputs SC_NAMED(sim_inputs); if_outputs SC_NAMED(sim_outputs); if_inputs SC_NAMED(stub_inputs); if_outputs SC_NAMED(stub_outputs); sc_vector<if_inputs> SC_NAMED(inputs_vector, 3); monitor(sc_module_name name_); private : // implementation details };
  12. You have multiple instances of the "bundles" in your monitor class: inherited directly as additional members in the nested classes sim and stub To avoid the name clashes, you can make sim and stub modules themselves via: struct sim : sc_module , if_inputs, if_outputs { SC_CTOR(sim) {} } sim { "sim" };
  13. I'm trying to use this approach for my problem. I created a header with two classes as you mentioned. Then I inherit them into the module where I want the "port bundle" to be. I get a lot of these Warnings: "Warning: (W505) object already exists: monitor.R_OP_MODE. Latter declaration will be renamed to monitor.R_OP_MODE_0 In file: c:\xx\xx\xx\xx\systemc-2.3.3\src\sysc\kernel\sc_object_manager.cpp:153" And one error, which probably causes the abortion. Error: (E109) complete binding failed: port not bound: port 'monitor.T_PRESET_MANUAL' (sc_inout) In file: c:\xx\xx\xx\xx\systemc-2.3.3\src\sysc\communication\sc_port.cpp:235 A minimal example is provided at the of my post with zipped source files. //interface.h #pragma once #include <systemc.h> // Class is meant to be inherited from, to have all Interface inputs struct if_inputs { // port declaration sc_inout<sc_uint<4> > R_OP_MODE{ "R_OP_MODE" }; sc_inout<sc_uint<8> > R_PRESET_MANUAL{ "R_PRESET_MANUAL" }; }; // Class is meant to be inherited from, to have all Interface outputs struct if_outputs { // port declaration sc_inout<sc_uint<2> > T_BIT{ "T_BIT" }; sc_inout<sc_uint<4> > T_OP_MODE{ "T_OP_MODE" }; sc_inout<sc_uint<8> > T_PRESET_MANUAL{ "T_PRESET_MANUAL" }; }; //A.h #pragma once #include <systemc.h> #include "interface.h" class A : public sc_module, public if_inputs, public if_outputs { public: public: SC_CTOR(A) { //SC_METHOD(T01_SBIT_sig_forward); //sensitive << T01_SBIT_in; } }; //B.h #pragma once #define SC_INCLUDE_DYNAMIC_PROCESSES //for sc_spawn #include <systemc.h> #include "interface.h" #include <functional> class B : public sc_module, public if_inputs, public if_outputs { public: // port declaration sc_in<bool> POWER_ON{ "POWER_ON" }; // process functionality void B::some_process(); private: std::vector<sc_time> timings{sc_time(3,SC_SEC), sc_time(6,SC_SEC), sc_time(9,SC_SEC) }; public: //constructor SC_CTOR(B) { //register processes SC_THREAD(some_process); sensitive << POWER_ON; } }; //stimulator.h #pragma once #define SC_INCLUDE_DYNAMIC_PROCESSES //for sc_spawn #include <systemc.h> #include "interface.h" struct if_inputs; struct if_outputs; class stimulator: public sc_module, public if_inputs, public if_outputs { public: sc_out<bool> POWER_ON; //processes void stimulator::stimulus_generator(); public: // constructor SC_CTOR(stimulator): // name ports for easier debugging POWER_ON("POWER_ON") { // Register processes SC_THREAD(stimulus_generator); // waits on fifo write_event } }; // monitor.h #pragma once #define SC_INCLUDE_DYNAMIC_PROCESSES //for sc_spawn #include <systemc.h> #include"interface.h" class monitor : public sc_module, public if_inputs, public if_outputs { public: //// port declaration sc_in<bool> POWER_ON; public: class sim: public if_inputs, public if_outputs { }sim; class stub : public if_inputs, public if_outputs { }stub; public: SC_HAS_PROCESS(monitor); //// constructor monitor::monitor(sc_module_name name_); }; //stimulator.cpp #include "stimulator.h" void stimulator::stimulus_generator() { POWER_ON = true; } //source file: blackbox.cpp #include "B.h" void B::some_process() { } //monitor.cpp #include "monitor.h" monitor::monitor(sc_module_name name_) :sc_module(name_) { } // main.cpp #pragma once #include <systemc.h> #include "B.h" #include "A.h" #include "stimulator.h" #include "monitor.h" int sc_main(int argc, char** argv) { // Set some SystemC time parameters (maybe not necessarily needed). sc_set_time_resolution(1.0, SC_US); // signal declaration sc_signal<bool > POWER_ON{ "POWER_ON" }; sc_signal<sc_uint<2>, SC_MANY_WRITERS> T_BIT_sim{"T_BIT_sim"}; sc_signal<sc_uint<2>, SC_MANY_WRITERS> T_BIT_stub{"T_BIT_stub"}; sc_signal<sc_uint<4>, SC_MANY_WRITERS> T_OP_MODE_sim{ "T_OP_MODE_sim" }; sc_signal<sc_uint<4>, SC_MANY_WRITERS> T_OP_MODE_stub{ "T_OP_MODE_stub" }; sc_signal<sc_uint<8>, SC_MANY_WRITERS> T_PRESET_MANUAL_sim{ "T_PRESET_MANUAL_sim" }; sc_signal<sc_uint<8>, SC_MANY_WRITERS> T_PRESET_MANUAL_stub{ "T_PRESET_MANUAL_stub" }; sc_signal<sc_uint<4>, SC_MANY_WRITERS> R_OP_MODE_sim{ "R_OP_MODE_sim" }; sc_signal<sc_uint<4>, SC_MANY_WRITERS> R_OP_MODE_stub{ "R_OP_MODE_stub" }; sc_signal<sc_uint<8>, SC_MANY_WRITERS> R_PRESET_MANUAL_sim{ "R_PRESET_MANUAL_sim" }; sc_signal<sc_uint<8>, SC_MANY_WRITERS> R_PRESET_MANUAL_stub{ "R_PRESET_MANUAL_stub" }; B sim("sim"); sim.POWER_ON(POWER_ON); sim.T_BIT(T_BIT_sim); sim.T_OP_MODE(T_OP_MODE_sim); sim.T_PRESET_MANUAL(T_PRESET_MANUAL_sim); sim.R_OP_MODE(R_OP_MODE_sim); sim.R_PRESET_MANUAL(R_PRESET_MANUAL_sim); A stub("stub"); stub.T_BIT(T_BIT_stub); stub.T_OP_MODE(T_OP_MODE_stub); stub.T_PRESET_MANUAL(T_PRESET_MANUAL_stub); stub.R_OP_MODE(R_OP_MODE_stub); stub.R_PRESET_MANUAL(R_PRESET_MANUAL_stub); monitor mon("monitor"); mon.POWER_ON(POWER_ON); mon.sim.T_BIT(T_BIT_sim); mon.sim.T_OP_MODE(T_OP_MODE_sim); mon.sim.T_PRESET_MANUAL(T_PRESET_MANUAL_sim); mon.sim.R_OP_MODE(R_OP_MODE_sim); mon.sim.R_PRESET_MANUAL(R_PRESET_MANUAL_sim); mon.stub.T_BIT(T_BIT_stub); mon.stub.T_OP_MODE(T_OP_MODE_stub); mon.stub.T_PRESET_MANUAL(T_PRESET_MANUAL_stub); mon.stub.R_OP_MODE(R_OP_MODE_stub); mon.stub.R_PRESET_MANUAL(R_PRESET_MANUAL_stub); sc_start(); return 0; } MinExample.zip
  14. hi sergio, thank you for the feedback! good recommendation. it is somewhat called out in table 3 in the insertion section of the "Mitigations" field. to see examples, refer to table 7. however i agree with you, we need better language around this. thanks, brent
  15. Hi! I found a minor bug in one of the CMakeLists.txt files: docs/CMakeLists.txt points to the file: docs/tlm/ChangeLog Which doesn't seem to exist anymore. This causes the installation to fail with the current git revision (fd4bedd5). Here's the error message I'm getting on GNU/Linux: -- Installing: /opt/systemc/share/doc/systemc/sysc/archived/FuncSpec20.pdf -- Installing: /opt/systemc/share/doc/systemc/sysc/archived/WhitePaper20.pdf -- Installing: /opt/systemc/share/doc/systemc/sysc/archived/UserGuide20.pdf -- Installing: /opt/systemc/share/doc/systemc/sysc/archived/SystemC_2_1_overview.pdf -- Installing: /opt/systemc/share/doc/systemc/sysc/archived/SystemC_2_1_features.pdf -- Installing: /opt/systemc/share/doc/systemc/sysc/SystemC_2011_New_Features.pdf CMake Error at docs/cmake_install.cmake:77 (file): file INSTALL cannot find "/tmp/systemc/docs/tlm/ChangeLog". Call Stack (most recent call first): cmake_install.cmake:87 (include) make: *** [install] Error 1 Makefile:73: recipe for target 'install' failed The command '/bin/sh -c cmake .. && make && make install' returned a non-zero code: 2 I've attached a patch to remove the file entry which fixes the installation issue. I hope this is useful! Have a nice day. tlm_doc_cmake_fix.patch
  16. Earlier
  17. The link answers the question on how to apply a distribution to any set of constraints. The dist construct only works with explicit values.
  18. Hi, How did you resolve the issue@Hash
  19. Hi all, The paper states "IP vendors will be able to identify security concerns to either 1) mitigate themselves, or 2) acknowledge for the SoC/ASIC owner to address at the integration level". I think it is important to distinguish as clearly as possible security concerns that are - or at least should have been - addressed by the IP provider, and concerns that should definitely be addressed at the IP integration step. At the moment I do not see any provision to make this distinction clear. Thanks, Sergio Marchese
  20. Hi David, the failing test is expected, hence the 'XFAIL' and the green printing. The compile warnings are coming out of the SystemC library. According to the screenshots you are using an outdated version, can you please retry with SystemC 2.3.3?
  21. For beta 2.0 and 1.0 version, i used gmake check but both failed in one example (attached). Could anyone tell me what causes that? btw, when i was installing it shows warning for signed overflow is that ok?
  22. @dave_59 The link you posted as an answer here points to a question about distributed weighting. I think maybe the link is for the wrong post? Anyway, I am quite interested if there is a way to do what the OP is asking about.
  23. SystemC standard does not guarantee any order of process evaluation within a single delta cycle. So in first example both 2,4 and 4,2 will be correct.
  24. I have a simple code as bellow: class Tmodel{ private: sc_event notify_method_2; sc_event notify_method_4; public: sc_event notify_method_3; sc_in<bool> input_port; ... SC_METHOD(method_1); dont_initialize(); sensitive << input_port; SC_METHOD(method_2); dont_initialize(); sensitive << notify_method_2; SC_METHOD(method_3); dont_initialize(); sensitive << notify_method_3; SC_METHOD(method_4); dont_initialize(); sensitive << notify_method_4; ... void method_1(void){ ... notify_method_2.notify(SC_ZERO_TIME); } void method_2(void){ ... printf("method_2\n"); } void method_3(void){ notify_method_4.notify(SC_ZERO_TIME); } void method_4(void){ printf("method_4\n"); } }; int sc_main(int , char *){ ... objectDUT->input_port.write(true); objectDUT->notify_method_3.notify(SC_ZERO_TIME); sc_start(200,SC_PS); ... } when debug, steps as bellow: 1. method_1 , call notify_method_2 2. method_3, call notify_method_4 3. method_4 4. method_2 I dont understand why at step 3 is method_4 ( I think it is method_2 ). if in sc_main, I insert sc_start(0,SC_PS); int sc_main(int , char *){ ... objectDUT->input_port.write(true); sc_start(0,SC_PS); objectDUT->notify_method_3.notify(SC_ZERO_TIME); sc_start(200,SC_PS); ... } steps is correct: 1. method_1 , call notify_method_2 2. method_3, call notify_method_4 3. method_2 4. method_4
  25. They are in namespace sc_core. If you don't want to use namespaces you can change #include <systemc> to #include<systemc.h> and it will pull everything into global namespace.
  26. #include <systemc> SC_MODULE (counter) { sc_in_clk clock ; // Clock input of the design sc_in<bool> reset ; // active high, synchronous Reset input sc_in<bool> enable; // Active high enable signal for counter sc_out<sc_uint<4> > counter_out; // 4 bit vector output of the counter //Local Variables sc_uint<4> count; // Counter logic void incr_count () { // At every rising edge of clock we check if reset is active // If active, we load the counter output with 4'b0000 if (reset.read() == 1) { count = 0; counter_out.write(count); // If enable is active, then we increment the counter } else if (enable.read() == 1) { count = count + 1; counter_out.write(count); cout<<"@" << sc_time_stamp() <<" :: Incremented Counter " <<counter_out.read()<<endl; } } // End of function incr_count // Constructor for the counter // Since this counter is a positive edge trigged one, // We trigger the below block with respect to positive // edge of the clock and also when ever reset changes state SC_CTOR(counter) { cout<<"Executing new"<<endl; SC_METHOD(incr_count); sensitive << reset; sensitive << clock.pos(); } // End of Constructor }; // End of Module counter Hello, I am trying to compile this simple code on SystemC 2.3.3 on MacOSX using the g++-8 compiler. I am receiving the following errors: Are the sc_in and the sc_out types depreciated i the 2.3.3 implementation or is it a compiler specific error?
  27. You also need to include -I, -L and -l for uvm-systemc in your compilation.
  28. It should also be noted that sc_event::notify (all variants) are not blocking methods. You would have to yield your process to see the effects. Yielding is accomplished in SC_THREAD using the sc_core::wait (all variants) methods.
  1. Load more activity
×
×
  • Create New...