Jump to content

David Black

Members
  • Posts

    510
  • Joined

  • Last visited

  • Days Won

    118

David Black last won the day on October 11

David Black had the most liked content!

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

3,256 profile views

David Black's Achievements

Advanced Member

Advanced Member (2/2)

198

Reputation

  1. Create a custom protocol and don't use address field if you don't have an address. If you do have an address but it has different requirements, then add a mandatory extension to the payload for your protocol.
  2. Please read the IEEE-1666-2011 LRM (specifically section 7.9.6.5 Assignment operators). Works fine - see https://edaplayground.com/x/WHnn (morning exercise)
  3. Due to the design of sc_event there will only be one event for a given delta cycle.
  4. Create: sc_event arbiter_event; All arriving processes push to their respective fifo and immediately post: queue.push(data); arbiter_event.notify(SC_ZERO_TIME); Arbiter waits for the event and processes all fifo’s upon receipt.
  5. It is doubtful to support since it would devote too many resources (specification, design, implementation, security, verification, training) from too many companies (SYNOPSYS, Cadence, Siemens EDA, Aldec) for something of little real benefit (commercial and practical). Another language interface would fragment support for an already complex language. No thank you. You can always use SWIG if you really feel the need.
  6. We need you to show more of your code to enable a coherent response. Perhaps even try coding on EDAplayground.com and share the link.
  7. Your observations are correct, but it really is not a problem. Even in Verilog you cannot do differently: // Verilog/SystemVerilog module Design( input CLK, AV, RD ); always @(posedge CLK) if ( AV == 0 && RD == 1 ) begin WriteDataOut(...); end endmodule So in SystemC: #include <systemc> using namespace sc_core; //< Simplifying bad practice SC_MODULE(Design) { sc_in<bool> CLK, AV, RD SC_CTOR(Design) { SC_METHOD(main_method); sensitive << CLK.pos(); } void main_method() { if( not AV->read() && RD->read() ) { WriteDataOut(...); } } }; Event driven simulators trigger on events, not values. In case you get distracted, here is a solution that will not work despite appearances: #include <systemc> using namespace sc_core; //< Simplifying bad practice SC_MODULE(Design) { sc_in<bool> CLK, AV, RD SC_CTOR(Design) { SC_METHOD(main_method); } void main_method() { next_trigger( CLK->posedge_event() & AV->posedge_event() & RD->negedge_event()); //< not what you might think if( not AV->read() && RD->read() ) { WriteDataOut(...); } } }; The & in the next trigger means that invocation will occur when all three events have happened; however, there is no requirement on when they occur. In other words, they won't be lined up correctly.
  8. You could use: #define SC_INCLUDE_DYNAMIC_PROCESSES #include <systemc> //... sc_signal<int, SC_MANY_WRITERS> sig; //... sc_spawn( [&](){ wait(DELAY); sig.write(VALUE); } ); See https://www.edaplayground.com/x/WjWw for an example.
  9. You can also use start_of_simulation, which is a more uniform approach (i.e., the concept works across all types of channels): SC_MODULE(tb) { //... void start_of_simulation() { int_o->write(0); } //... };
  10. Start address is the simulated address of the data that the pointer points to.
  11. Show your code please. Better: get a free account on EDAplayground.com and share your code from there.
  12. It is not correct to bind a port to another port directly except in the case of a hierarchical connection. Furthermore, there is no such thing as an input port or an output port in SystemC. Ports are simply sophisticated pointers to channel objects that provide methods for exchanging information. Some methods are directional in nature by g to heir behavior. For instance, sc_signal<int>::write(value) deposits it’s contents into memory managed by the sc_signal<int> channel.
  13. Look at the SystemC implementation of convenience sockets and try to duplicate the approach in SV. The basic idea is to implement the TLM-2 methods inside the socket and then delegate the implementation via a callback. UVM does have callbacks, so I would guess this is not too hard to do (albeit slightly messy).
  14. You did not post any error message, so it is practically impossible to answer your question. Perhaps you have run-time variables in the template parameters, which are strictly compile-time. In any case, this is not part of SystemC, but looks to possibly be part of an Intel FPGA package. SystemC identifiers generally begin with `sc_`. Consider: 1. Take your question elsewhere (e.g., Intel FPGA forum) 2. Look at the header file from whence it came and learn the C++ API from whence it came. If that does not make sense to you, then consider taking a course in C++.
  15. Have you tried the cmake approach? mkdir build; cd build; cmake ..; make; make install
×
×
  • Create New...