David Black

Nope. C++ has no concept of what a sensitivity list is, and no way to figure out what to supply. Remember: SystemC is a library, and C++ is the language. Unless somebody builds a SystemC specific compiler, this won't change. If you are doing RTL design, you are best advised to stick with Verilog, VHDL, or SystemVerilog.

Not related to your problems, but perhaps important as you continue to devleop... Technical detail - TLM 2.0 requires that you: 1. Prior to sending specify 8 attributes in the payload. You are missing the streaming width and DMI hint. 2. Check to ensure the payload matches the attributes of your target Also, tlm::tlm_generic_payload* payload_ptr = new tlm::tlm_generic_payload; is very expensive (computation time), so I would encourage you to reuse the payload object if this code is inside a loop rather than generating a new one each time.

The PoC SystemC simulator implementation is not designed to be restarted at time zero. Thus you cannot run two simulations within one main.

Simulators that support languages such as SystemVerilog and VHDL are optimized for working with RTL; whereas, SystemC is simply a C++ program with no special optimizations. Thus SystemC will run much slower for RTL simulation than the other languages. If you have a really large RTL simulation, this could become problematic. For small designs it is no issue. For example, RTL has lots of processes sensitive to a clock edge to model flip-flops (registers). Optimized simulators will combine all of this code into a single process; whereas, SystemC will result in many processes and many context switches. Of course somebody could write a SystemC optimizing compiler, but to date nobody has.

Since ESL models are supposed to be lightweight and fast (esp. if used for software development), I strongly suggest you do not increment/decrement a counter. Instead, use timed event notification and calculation as you seem to have suggested. I did a presentation at NASUG on this, "Look Ma, no clocks" several years back. I am pretty sure the code was published -- www.nascug.org should have reference to it somewhere.

To re-emphasize: ports do not hold values. Instead they are connected to a channel that implements behavior. sc_in<>, sc_inout<> and sc_out<> are all required to bind (connect) to sc_signal<> channels, which exhibit the behavior you describe.

Another thought is to use uvm_event's and the uvm_event_pool. You would have to agree on an appropriate string name for the event (being careful the name is not too casually selected).

Some code (even pseudo) would help with understanding your need. Your description is unclear.

NOTE: In the following, I am assuming a SystemC ES level model. Also, I do not presume to discuss how SystemVerilog and SystemC interoperate as that is the task of the MLWG. In fact, whether not any or all components are in one language domain or the other is somewhat independent of this discussion. Seems to me that TLM simplifies the driver and monitor because: 1. The driver is supposed to deliver transactions. If it is connected as an initiator to an ES level DUT, then the job of the driver is to translate the sequence item into DUT transactions, which might be 1:1. If it is connected as a target to the ES level DUT, then it's responsibility is to supply the response with directions from the sequence item, and possibly deliver a sequence item response back to the sequencer. 2. The monitor should simply snatch copies of the transactions. The one problem I see is that with RTL, the SystemVerilog interface can be monitored and driven fairly easily, but for transactions it may be the "TLM interface" needs to be a TLM module that provides two TLM sockets. One TLM initiator socket for the monitor, and a separate socket (initiator or target depending on the DUT side). This ES-interface would be essentially transparent between the driver and DUT, while invisibly grabbing copies of transactions to deliver for the monitor. The driver and monitor could simply implement the base protocol (if AT). Details of any bus specific aspects would probably need to be handled in the interface; although, we could have a debate on whether to push that to the driver. However, pushing it to the driver would complicate matters more than probably necessary. I imagine there will situations where the TLM monitor/driver pair are connected to sc_signal<T>'s since not all TLM activity is restricted to sockets. For example, interrupts or reset. This would be a more traditional monitor/driver connection, but still should involve a TLM interface module.

Tudor is dead on. Clock jitter and delays are better debugged with specialized timing tools. Caveat: if your system has reclocked synchronous interfaces, make sure you design the stimulus to have sufficient jitter in the cycles (i.e. +/- whole clocks) to see how that might affect the design. This should of course be randomized. Probably a bit (or two) m_delay in the transaction constrained to let the driver wait a cycle before delivering data. That should be sufficient.

Alan is of course dead on. Nothing wrong with using program blocks if you know what you are doing. A lot of folks advocate using clocking blocks instead for good reasons, but clocking blocks only apply to synchronous interfaces. Worth your time to read the various points of view to be certain you understand the issues. In particular, you need to understand the SystemVerilog scheduler diagram (see IEEE-1800-2012 for details). Also, you can use a combined approach (i.e. both), but be sure you understand the issues. We include discussions of this in the Doulos training materials [shameless plug].

I think you might do better to use a report catcher for this situation. In the report catcher you can simply fork a delayed fatal: class my_report_catcher extends uvm_report_catcher; int unsigned count = 1; // limit time fatal_timeout = 20ns; // amount to delay before exiting function new (string name = ""); super.new(name); endfunction function action_e catch; uvm_severity severity = get_severity(); string id = get_id(); uvm_action action = get_action(); string message = get_message(); int verbosity = get_verbosity(); if (count) --count; if (count == 0 && severity == UVM_ERROR) //< conditions to set fatal timeout begin fork begin // allow extra time #fatal_timeout; `uvm_report_fatal("","Exiting due to count") end join_none throw; end endfunction endclass Caveat emptor: untested. Also need to create/add the catcher at the appropriate location.

To help you with this, we really need to see some of the code. On first glance you have a bad reference. I would suggest at least the code surrounding logical_unit.tpp line 1314

A better solution is: while(true) { wait(signal->default_event()); // wait for next value = signal->read(); // Do your thing } If you use sc_signal<T>, then default event is every time the value changes; whereas, if you use sc_buffer<T> then the default event is every time there is a write().

But why are you needing an immediate notification? Do you realize that this may cause some processes to never see the event?

I think Philipp's two questions still stand: What are you trying to achieve? Why are you sensitive to an sc_signal event, if you don't want to be triggered? You will get a better response if you can answer these.

thread1 is an infinite loop because you failed to yield in the loop. Add: wait(1,SC_NS); or similar after the notify. You can use SC_ZERO_TIME if you like.

I don't recall a strong reason for this, but I am not sure I see a use either. If you need immediate notification then use sc_event or you can always use a time delay of SC_ZERO_TIME. The purpose of sc_event_queue was to be able to guarantee that every notification would be seen by any interested process. If you allowed for immediate notification, that would no longer be true because two notifications in a row would result in a lost notification. In other words: SC_MODULE(Top) { sc_event_queue eq; SC_CTOR(Top) { SC_THREAD(sending_thread); SC_THREAD(watching_thread); } void sending_thread(void) { for(size_t i=0; i!=4; ++i) { eq.notify(); //< illegal syntax used for illustration eq.notify(); //< illegal syntax used for illustration -- **this would never be observed** wait(SC_ZERO_TIME); } sc_stop(); } void watching_thread(void) { for(; { wait(eq); SC_REPORT_INFO("","Observed eq"); } } };

You can simply write your own report handler to process all messages passed in from SC_REPORT_INFO, SC_REPORT_WARNING, SC_REPORT_ERROR, and SC_REPORT_FATAL. Very configurable and easy to do. I've done it on more than one occasion. We touch on it on our SystemC training. I also created some convenience macros to allow a streaming syntax to be used. If I get some time and there is more intereset, I might dig them up an contribute. You can of course read more about it in the IEEE-1666-2011 pdf standards document available via Accellera.org.

Not very much has been posted about the OSU tools, and I have seen no actual source code. From what I can see, the authors are a bit confused about what SystemC is versus how to properly use it. They contend it is an event driven vs cycle driven difference. Yet, I can create cycle driven models in SystemC just as easily as event driven. SystemC is just a standard wrapper in C++. As to SystemC, just download from Accellera.org

Also, I think you have the wrong operator in the code you show. Hopefully just a typo: wait(e1|e2);

I use Adobe Acrobat Pro with no problems. It just works. If you need to control the format more, that may be more challenging. I think this may be the wrong forum to ask though. Your question is really "How do I convert HTML to PDF?", which may be better suited to Google (which has many results).

How about using tlm_utils::peq_with_get?

I believe you are looking for register aliasing. An obvious comment on prediction: you will have to choose either one of the BFM's or a backdoor to provide prediction since it would be awkward to read multiple versions for this and then decide if they matched. Mind you, this doesn't prevent reading values through each of the different BFM's to compare and verify the read paths are equivalent. Observation: You may have to also consider whether each of the BFM's is always accessible in choosing the solution for prediction. With some of today's electronics, sections may be powered down or disconnected at times.