Jump to content

David Black

Members
  • Content Count

    372
  • Joined

  • Last visited

  • Days Won

    81

David Black last won the day on September 26

David Black had the most liked content!

About David Black

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

1,919 profile views
  1. No for a port; however, you could accomplish the goal with an sc_port< sc_signal<T> >
  2. 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>.
  3. 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.
  4. UVM-SystemC is a library. It is not a tool. You are expected to be very knowledgeable in both C++ and SystemC before using it. Knowledge of SystemVerilog UVM is useful. To use on the command-line you would have to decide your build methodology (probably make) and create appropriate files for that. RTFM please.
  5. Logging in with a social accounts gives you access to all non-commercial simulators and some commercial simulators. If you want to use all the commercial simulators, you need a commercial/work e-mail address. For SystemC you don't need the commercial simulators.
  6. This is both well known and well defined in the specification: sc_event only queues a single event for future notification notify immediate cancels the outstanding queued event and "happens" immediately. This is why it is called "immediate". If you attempt to queue non-zero notifications, only notifications nearer to the current time replace old ones. SC_ZERO_TIME can only be superceded by immediate notification. If you need to queue multiple notifications use the sc_event_queue.
  7. It is unclear where your std::cout is located. The earliest I would expect is inside start_of_simulation() or as the first thing inside an SC_THREAD. But your code has another issue. You are declaring two independent variables. One in the struct, and the other as a stack located version with an initial value of 4 ms. Perhaps you meant to do something like: https://www.edaplayground.com/x/2c9j
  8. Port not bound means that you forgot to connect a port. SystemC does not allow unconnected ports (at least not without some extra work). If you didn't name your port instances explicitly, SystemC arranges to have them named "port_0", "port_1", "port_2", ... etc. So you apparently have five ports on some module and you've only connected four of them.
  9. wait(SC_ZERO_TIME); But perhaps there is more to your question. You probably need to provide some code to get a more comprehensive answer. For example, the above assumes an SC_THREAD process. If you have an SC_METHOD, then you would use: next_trigger(SC_ZERO_TIME); combined with some FSM mechanism.
  10. Is the concern related to power domains being on or off? I would think it might be more productive if your underlying implementations looked for a hierarchical attribute related to power and you organized modules around power domains. Or perhaps you could have a global lookup unordered map of instance names to power domains. In any event, I would not redefine the API of standard channels. Keep in mind that generally sc_signal is a low level primitive and should be somewhat rare in most modeling situations. I would more likely expect this issue to appear in a TLM socket connection.
  11. We assume you are using SystemC models for the Arm cores.
  12. When you say "verifying hardware targets", may we assume you mean physical (not modeled)?
  13. We shall have to wait and see w.r.t. co-routines, but they do look promising.
  14. If you want multiple drivers, use sc_signal_resolved or sc_signal_rv<N>. The reason for SC_ONE_WRITER is to catch errors since the normal use case for sc_signal is single drivers. The SC_MANY_WRITERS was intended to allow one process to initialize and then hand-off to another process. Your use case likely the resolved signal situation. Verilog uses wires for the resolved case. VHDL has you to be more explicit.
  15. I see this question a lot. Perhaps an enhancement idea for a future SystemC. register_port could be augmented by adding a bit of data to channels to record the connecting parent. This would add a small structure (?vector<sc_object*>?), and add a tiny bit prior to start of simulation. Providing a "netlist" helps to confirm everything is connected correctly. Of course it won't for all the connectivity (e.g. a global clock object), but it would go a long way.
×
×
  • Create New...