apfitch

Probably the best thing to do is profile your code. That should tell you in which functions the (wall-clock) time is being consumed. regards Alan

The LRM (section 4.4.4) specifies that end_of_simulation() will be called either after sc_stop(), or if sc_main is not used. Sometimes people call sc_stop() after sc_start() just to trigger the end_of_simulation() callback. Regarding your first question, you've left out the vital piece of information! What is "xxx" in wait(xxx). If it is the word true, then of course the loop will never exit and sc_stop() will never get called. regards Alan

LT is easier to understand that AT, so I would start with that. There's lots of information at http://www.doulos.com/knowhow/systemc/tlm2/ regards Alan

I recommend using the IEEE 1666-2011 standard. Dynamic processes - from B.51 in the appendix "B.51 dynamic process: A process created from the end_of_elaboration callback or during simulation.". A dynamic process is created using sc_spawn, so is also know as a spawned process. Available convenience sockets are described in section 16.1 In the ASI implementation, some of the convenience sockets use dynamic processes. In the ASI Proof of Concept simulator, dynamic processes require the macro SC_INCLUDE_DYNAMIC_PROCESS to be set. regards Alan P.S. OSCI no longer exists, it merged into Accellera Systems Initiative, ASI.

A user defined channel is a class that is derived from an interface. Alan

You can use all three channels in the same module if you want to Alan

Sorry, I don't understand your question, Alan

A hierachical channel is essentially a module that implements an interface. It is very flexible, and so is used to make complex bus models, for instance. A primitive channel has close access to the scheduler delta cycle; it it typically used only with the built-in channels (sc_signal and so on) for low level (hardware like) modelling. You can use sc_signal, sc_fifo, and sc_buffer all in one module, regards Alan

The conventional way to create customized behaviour is to use extensions to the generic payload. If you do this properly (with ignorable extensions), you can still connect your customized payloads via generic payload components and they will ignore your extensions. Alternatively you can create mandatory extensions. There are examples of using extensions on the Doulos website http://www.doulos.com/knowhow/systemc/tlm2/locking_and_snooping/ Please note that this is an advanced topic, so be prepared to do some thinking and learning :-) regards Alan

When you declare the initiator socket, it expects to access an implementation of the functions in the tlm_fw_transport_if - there is no read() function in the tlm_transport_fw_if. If you wanted to follow this approach, you'd have to declare your own sockets. regards Alan

SystemC keeps a count of the total number of delta cycles. You can find it out with the function sc_delta_count(). Deltas are kind of similar to non-blocking verilog assignments. Blocking assignments in Verilog are like standard C++ variable assignments. regards Alan

SystemC does not support SDF modelling. SystemC does have simulation deltas if you use primitive channels. Alan

I'm not sure what's wrong - but it's probably better to use a temporary variable, e.g. // SC_METHOD void proc() { sc_lv<3> bv3 = (bit2.read(), bit1.read(), bit0.read()); bus_output.write ( bv3 & bus_input.read() ); } Can you try that and see if it works? If it doesn't, then something else is wrong. regards Alan

The delays you seen after SDF annotation are not delta delays, they are real (modelled) amounts of time. In RTL you don't see the delta delays on waveforms normally (tools can show them to you if you want), but the deltas are there, and it is possible to write bad code by ignoring the deltas. A good example would be to create a copy of a clock signal using a signal assignment in VHDL - you'll then get hold time violations if you clock flip-flop models off the original and delta-delayed clock. SystemC does have delta cycles if you use primitive channels (sc_signal/sc_fifo), but there's no built-in way of modelling SDF back annotation. You wouldn't use SystemC for that, you'd use Verilog or VHDL/VITAL. regards Alan

SystemC primitive channels (sc_signal, sc_fifo etc) model delta cycles. I'm not sure what you mean by "avoid delta time". If you mean you don't want deltas to be used, write your models without primitive channels, and do not use any time delays. Your program will execute in zero time and have no deltas. If you use more than one SC_METHOD it will also most likely be non-deterministic. If you mean how to avoid the effects of deltas, just use a clock like you would in RTL design. regards Alan

Yes, sorry I meant p_in, Alan

Try u_adder.pin.write(1). Though that style of coding is strange. I would write a stimulus module and drive the stimulus from there - it's more code, but it's much easier to get working rather than trying to do stuff in sc_main. See the example in http://www.doulos.com/knowhow/systemc/tutorial. By the way, sensitive_pos is deprecated, you should use sensitive << p_clk.pos() regards Alan

Hi Carter, can you post the exact error message, and the source of the line number (line 45?). The obvious source of error to me is that you're trying to bind a constant value to a port with pcg.popo_in(1). That is probably where the error message comes from. Secondly, as someone else may have said, you need to call sc_start() to make the simulation start. regards Alan

In the past people recommended adding extra processes to split or combine the vectors. As you say, you'd have to have some SC_THREAD or SC_METHOD, and for convenience you'd probably need arrays of pointers to signals. However in SystemC 1666-2011 there's a whole new set of features to assemble and dis-assemble vectors of SystemC objects - sc_vector etc. See section 8.5 on page 400, regards Alan

The danger with that approach is that you have to manually make sure you have no race hazards in your design or indeterminacy in your design. My first answer would be "don't use a signal", use a shared variable instead. Another answer would be to have a shared event between the modules. You could do something like module1 sc_event sig_written; // in a process my_sig.write(true); sig_written.notify(); // immediate notify! /////////////////////////// module2 sc_in<int> sig; // in an sc_thread sc_event * ev; module2(sc_module_name name_, sc_event * ev_) : sc_module(name_), ev(ev_) { } void thread() { while (true) { wait(sig_written); cout << my_sig << endl; } There must be a better way of doing that, but the idea is to share an event between the modules then use immediate notify to trigger the read. Of course there's no real point using an sc_signal then, as the ordering is given by the event, so you might as well just use a shared variable. A third answer is to put the code in a single module, so you then have direct access to the value you are writing to the signal. regards Alan

No, they're not the same. Alan

OK, I spotted it - you should use ! instead of ~ regards Alan

It looks OK to me, perhaps someone else can see what's wrong? Alan

All I meant was to change your sc_method to SC_METHOD(test); sensitive << popo_in; That makes it run every time popo_In changes. If you want to use an SC_THREAD, you'd need SC_THREAD(test); sensitive << popo_in; void test () while (1) { wait(); popo_out = ~popo_in; } } regards Alan

Hi Carter, your two problems are connected - when you declare an SC_METHOD you need something to trigger it otherwise it will only run once at time zero. That's what I meant by "you need to make your SC_METHOD sensitive to popo_in". If you do that, when it runs it will then assign a new value to popo_out, and you will see the change on the waveforms. There are examples of sensitivity here: www.doulos.com/knowhow/systemc/tutorial Look at the section "Modules and Processes". Also I recommend you read section 5.2.9 of the IEEE 1666-2011 standard, which you can download free via the accellera website, regards Alan