Leaderboard

Welcome to the Accellera Systems Initiative forums. Please register to start new topics or reply to existing topics. We have resently migrated our UVM forums from UVMWorld to this site. If you were registered on the previous UVM forum site, you should be able to log into the forums using your username and password from the UVMWorld forums. If you had an account on both the UVMWorld forums and the Accellera forums and these accounts used the same email address, then log in with the username and password of the forums.accellera.org account, not your UVMWorld account. If you do not remember your password, you may reset it. If you have any questions about using the forums, click the Help button at the bottom of any forum page. If you need any help with your account and you are logged into the site, click the Messenger icon (a letter) in the upper right of your screen, click Compose New, enter “admin” in the Recipient’s Name field, compose your message, and then click Send. You may also send an email to admin@lists.accellera.org. Thank you, Accellera Systems Initiative

India SystemC User Group Conference (ISCUG) A platform to discuss the SystemC based next generation methodologies for design and verification of Electronics Systems (Semiconductor Chips + Embedded Software) Tutorial Day: April 14, 2013 (Sunday) Conference Day: April 15, 2013 (Monday) Venue: Noida, India Register for the event at www.iscug.in. Early bird discount ends on February 28th, 2013. To receive regular updates about the event, register your email at www.iscug.in and follow www.facebook.com/iscug. For sponsorship opportunities, contact info@iscug.in About ISCUG The India SystemC User's Group (ISCUG) organization aims to accelerate the adoption of SystemC as the open source standard for ESL design. ISCUG provide a platform to share the knowledge, experiences and best practices about SystemC usage. ISCUG organize an annual conference which provides a platform for the SystemC beginners, the SystemC experts, ESL managers and the ESL vendors to share their knowledge, experiences & best practices about SystemC usage. The event will also be useful for: SoC Architects involved in architectural exploration, performance optimization, power optimization etc.. Embedded software engineers who want to explore usage of Virtual Platforms for embedded software development Chip verification engineers who want to explore SystemC based verification methodologies Chip design engineers who want to explore SystemC as the language for chip design at higher abstraction level The event is designed on the pattern of similar events happening worldwide: NASCUG, ESCUG, Japan SystemC Forum, etc. Participate You may participate in ISCUG as a speaker. Submit your abstract at www.iscug.in before February 15, 2013. The abstract will be reviewed by the technical review committee; the committee reserves the right to make final decision on speaker selection. You may present a topic related to SystemC modelling, covering virtual platforms, transaction-level modeling, high-level synthesis, SystemC-AMS, modeling for performance analysis, modellng for architectural exploration, SystemC-based SoC verification methodology, or any other topic related to SystemC modeling. You may also present a success story of SystemC adoption in your company. Tutorial Day: There will be a full day of tutorials running in parallel. To participate as a speaker, send details to info@iscug.in. First Half (Before Noon): SystemC and TLM 2.0 Introductory Tutorial Second Half (After Noon): Two/three tracks in parallel (details yet to be finalized) Advanced modeling techniques Virtual platforms for embedded software development and pre-silicon HW/SW co-verification High-level synthesis using SystemC SystemC-based verification methodologies Contact Web: www.iscug.in Email: info@iscug.in

Actually, you can start a sequence in any phase. It is more important to understand the domain/scheduling relationships between the task based (i.e. runtime) phases. UVM undergoes a number of pre-simulation phases (build, connect, end_of_elaboration, start_of_simulation) that are all implemented with functions. Once those are completed, the task based phases begin. The standard includes two schedules. One is simply the run_phase, which starts executing at time zero and continues until all components have dropped their objections within the run_phase. The other schedule contains twelve phases that execute parallel to the run phase. They are: pre_reset, reset, post_reset, pre_config, config, post_config, pre_main, main, post_main, pre_shutdown, shutdown, and post_shutdown. They execute in sequence. Every component has the opportunity to define or not define tasks to execute these phases. A phase starts only when all components in the previous phase have dropped their objections. A phase continues to execute until all components have dropped their objections in the current phase. Many companies use the run_phase for everything because there are some interesting issues to consider when crossing phase boundaries. In some respects it may be easier to use uvm_barriers for synchronization. Drivers and monitors (things that touch the hardware) are usally run exclusively in the run_phase, but there is nothing to prevent them also having reset_phase, main_phase, etc...

Do design and verification engineers care about EDA standards? If the Accellera Systems Initiative "Town Hall" meeting at DVCon 2013 Feb. 25 is any indication, the answer is an emphatic yes. A packed audience attended a lively, hour-long meeting in which non-stop questions were answered by Accellera and IEEE standards developers. - Published by Cadence Industry Insights Blo ... View the full article ...

Hi Kevin, if you check here https://github.com/Minres/SystemC-Components/blob/master/incl/scc/utilities.h there are three macros which make live easier: #define TRACE_VAR(F, X) sc_core::sc_trace(F, X, std::string(this->name()) + "." #X) #define TRACE_ARR(F, X, I) sc_core::sc_trace(F, X[I], (std::string(this->name()) + "." #X "(" + std::to_string(I) + ")").c_str()); #define TRACE_SIG(F, X) sc_core::sc_trace(F, X, X.name()) They can be used with local variables and arrays as well with SystemC objects providing the name() funtion. This way tracing a signal becomes as easy as (assuming _STATE_ being a signal or port): TRACE_VAR(_trace_, top.dpu.idu.weight_reader.m_traffic_gen._STATE_); Pls. note: the first 2 macros are assumed to be used within a sc_module. HTH -Eyck

Hi @vasu_c, thanks for finding this. The patch below should fix your issue if you want to try it out early. Apologies for the inconvenience. --- a/src/sysc/packages/qt/md/aarch64.s +++ b/src/sysc/packages/qt/md/aarch64.s @@ -59,8 +59,10 @@ qt_blocki: mov x0, sp // arg0 = old_sp mov sp, x3 // sp = new_sp + sub sp, sp, 160 // (*helper)(old_sp, a0, a1) blr x4 + add sp, sp, 160 // Callee-saved ldp x29, x30, [sp, #-16] // frame, link

You use fork/join_any statements when you want to create a number of time consuming processes and block waiting for one of them to finish. You create two processes, but they do not bloc - the finish immediately because they have fork/join_none statements in them . What you probably meant was something like initial begin me[0] = 1; me[1] = 2; me[2] = 3; repeat(5) begin : repeat_loop fork begin : b1 foreach(me) fork automatic int id = me; print_value (10+id,id); join_none wait fork; end : b1 begin :b2 foreach(me) fork automatic int id = me; print_value (20+id,id); join_none wait fork; end : b2 join_any disable fork; $display(" Disable Fork "); end :repeat_loop $display("@%g Came out of fork-join", $time); #20 $finish; end // initial begin

The SystemC AMS TDF model of computation follows the well known data flow semantics, which means that the module is activated (i.e. the SystemC AMS processing() callback is called) as soon as the samples are available at the input port(s). After this computation, the results are immediately available at the TDF output ports (assuming you write to output ports). This means the SystemC AMS modules simply compute the signal as soon as TDF samples come in, and pass them after performing some signal processing to the output. In SystemC AMS 2.0 we introduced the concept of "Dynamic TDF" which allows additional activation of the TDF module's processing() method as soon as discrete-events come in via the converter input ports (sca_tdf::sca_de::sca_in or sca_tdf::sc_in), but this concept should only be used to make reactive systems. I advice *not* to apply this in combination with your coordinator module. Unfortunately your example of module A and B is incomplete (e.g. are module A and B connected?) to give good guidance. But the use of this coordinator module really sounds like overhead to the system simulation, as it is only meant to synchronize the execution of module A and B. Guess this is an artificial module to drive simulation only? This type of modules should be avoided. Architecture design in SystemC and SystemC AMS should represent the system by modules which are really available in the system. Instead, you could implement this example using SystemC AMS only, where module A has a fixed time step of 10ms, and module B a time step of 20ms. You can connect them via a port with a rate of 2, which means module A is called twice, before module B is called. This gives you the right execution schedule. Furthermore, by following this approach, you basically skip the native SystemC discrete event semantics, and simulation even gets much more efficient.

Based on the error message, Incisive seems to be only able to connect Verilog signals to Discrete Event ports of a wrapped SystemC module, i.e., of type sc_core::sc_in<T> or sc_core::sc_out<T>. You will have to wrap your SystemC-AMS TDF model accordingly. It may already suffice to use TDF converter ports of type sca_tdf::sca_de::sca_in<T> or sca_tdf::sca_de::sca_out<T> instead of pure TDF ports of type sca_tdf::sca_in<T> or sca_tdf::sca_out<T>. They ensure the sampling of DE signals to TDF samples and vice versa. If that doesn't fix the error, you will have to further wrap the TDF model into a SC_MODULE having only SystemC ports of type sc_core::sc_in<T> or sc_core::sc_out<T>.

Hi Mohit, I'm working on understanding these topics as well currently. I am working on something very similar to what you described. After you set the register value, issuing an e.notify() I believe is identifcal to e.notify(void) which is an "immediate notification". This doesn't mean any threads waiting on this event start running, it just means they are placed into the "runnable set for execution" (p73 systemC: from the ground up). Therefore whenever your b_transport releases the thread, the "target process" will start running. If you do a e.notify(SC_ZERO_TIME), aka "delayed notification with a time of 0", any processes waiting on this event will only execute after all processes in the "runnable set" have been executed. Long story short, the "target process" is not placed into the runnable set at the time of the notification. Once your b_transport releases the thread for the first time, i.e. wait(SC_ZERO_TIME), it completes the current runnable set, then places the "target process" into the runnable set. Now your second wait(SC_ZERO_TIME) will kick off the target process. This exact topic is discussed on page 75 (notify(SC_ZERO_TIME)). It discusses it's merits over notify(void) for a selected scenario (when a process could miss an event). In your scenario I dont believe you can miss the event, so notify(void) seems more appropriate. brian

New verification standard readied for submission to IEEE; 90-day public comment period begins. - Published by Semiconductor Engineerin ... View the full article ...

This is the correct functionality. There is a random number generator (RNG) for every module instance in your design, and it is seeded with a RNG from the module instance it starts from. All all modules instances start out with identical seeds. Every thread that starts inside a module instance grabs a new RNG. Threads in parallel blocks get seeded in declaration order, not in the indeterminate order they might actually start. Objects that get constructed get seeded with an RNG from the thread calling the constructor. This random stability model has a few problems that the UNM attempts to correct by using a path name as an initial seed. You just need to make sure your path names are unique enough to generate distinctive seeds. A good paper to read on this topic is: Random Stability, Don't leave it to chance.

Google :-)

OK, two answers - firstly, it'll probably work without that, assuming you have a c++ compiler installed, so you could just leave that out completely. Second answer - setenv is specific to c-shell. You're probably running bash, in that case the equivalent command is export CXX=g++ regards Alan

Update: EDA Playground now supports SystemVerilog and UVM. You can edit and simulate this simple UVM testbench: http://www.edaplayground.com/s/example/546

Hello, Please note that SystemC is just a C++ library. So, there is no reason why an array cannot be declared, initialized and used inside a class. But there are some problems: 1. unsigned char* host_hci_pkt_arr == this is just a pointer to a single unsigned char NOT an array of pointers to unsigned chars. Why not : unsigned char* host_hci_pkt_arr[<SOME_SIZE>]; This is declaring array of pointers to an array of SOME_SIZE, explicitly. You could then fill the elements in as : host_hci_pkt_arr[0] = "0x01"; 2. The moment you use the "new" operator, you have to use the corresponding "delete" to clear memory in the destructor. On the other hand, by explicitly declaring the array as above, the compiler and runtime system takes care of memory allocation/deallocation. It appears that you are trying to model packets, and realistically a packet consists of a large number of bytes. If there are a large number of packets moving around, that are created dynamically, and then not deleted when the container object is deleted, one is looking at annoying memory leak issues. HTH.

Hi Sumit, just some tought on this. I had similar ideas when i was covered with the spin simulator. If you want to keep a "systemC sync" on all processes you probably have to give more effort than you can take from it. A solution could be to allow async for a given amout (like tlm). In spin you have the possibility to do parallel calculation for a given "simulator time". In these proclets you calculate but can not change any signals, and change signals when your are out and back in sync. The same you can do in systemC. Doing parallell calculations in a seperate "real" thread, but keep systemC running in its own process means. regards, thomas

The implicit conversion between these types is not possible in all cases, mostly due to the danger of ambiguities in the API. Just add an explicit type conversion instead in terms of a C++ static_cast here: void do_cast(){ castout.write( static_cast<sc_uint<8> >(castin.read() ) ); } Greetings from Oldenburg, Philipp

Hello, If you have read my responses to three recent queries on this newsgroup, you like the others, have run into a fundamental drawback/problem of C++ templates. The reason why your fifo works with single characters only is because during the crucial SystemC elaboration step, the size (number of bits) for a single character is known to the compiler. Also note that the SystemC built-in sc_fifo module can tackle built-in C++ primitive data types(char, double, float int ....) ONLY. As a character string can be of any size, it is an user defined data type, and so the user has to provide the mechanism to handle it. So, to transfer character strings via a custom fifo, a good option would be to: 1. Declare a custom interface - subclass of sc_core::sc_interface 2. Create a class that implements the interface - must ensure FIFO order in the input/output. This would be the character string FIFO. 3. Create custom ports to read/write character strings from/to custom channel Yes, it is rather messy, but it is straightforward. Hope this helps.

Hi Cam, the idea of TLM2 was to create a standard API for transaction level modelling, that runs at high speed, and models memory-mapped buses. So the TLM Working group decided to create standard functions for both blocking and non-blocking transport; and a standard payload object. So the first advantage of using TLM2 over plain SystemC is simply that it is a standard API and payload. To model pipelined transactions, the TLMWG decided to use function calls from target to initiator and initiator to target. To allow function calls to be made in both directions needs a port on the calling module and an export on the target (forward), and a port on the target model connected to an export on the initiator. You could of course do this without sockets but you'd have to make two connections - by using a socket, a single bind call connects both export and port. Also you'd have to explicitly declare the initiator port and target export with tlm_transport_fw_if, and the target port and initiator socket with tlm_transport_bw_if - initiator socket is based on tlm_transport_fw_if and the target socket on tlm_transport_bw_if so you get that "for free". Finally, the sockets also have extra template arguments compared to SystemC ports - the Bus Width parameter. This ensures that the user cannot accidentally connect busses of different widths together. kind regards Alan P.S. There is another answer I could give: TLM2 *is* SystemC there is no difference. An initiator is a channel that implements the tlm_bw_transport_if. The target is a channel that implements the tlm_fw_transport_if. So the only difference from the "traditional" use of SystemC is the idea of a socket to provide simultaneous binding of the both port and export. If you want to, you could create your own exports and ports, and connect them yourself.

You can run the delta cycles at the current time until everything settles: while( sc_pending_activity_at_current_time() ) sc_start( SC_ZERO_TIME );

If you don't use the member functions added that were added for convenience to `sc_in`, `sc_out`, and `sc_inout` to, e.g., call `read()`, `write()`, and the event member functions via the `.` operator than via the corresponding member function in the interface accessed via the `->` operator, you might be able to avoid entirely the derivation of new port classes. Instead, you could simply use a template alias, which was introduced with C++'11: template<typename T> using sc_in_opt = sc_core::sc_port<sc_signal_in_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; template<typename T> using sc_inout_opt = sc_core::sc_port<sc_signal_inout_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; template<typename T> using sc_out_opt = sc_core::sc_port<sc_signal_inout_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; If you want to also provide all member functions of `sc_in`, `sc_out`, and `sc_inout`, you will have to derive from the `sc_port` class and implement the full interface as defined in IEEE Std 1666-2011.

Maybe a little bit late but there are socket implementations available which do trace tlm transactions int a SCV database. They can be found at https://github.com/Minres/SystemC-Components/tree/master/incl/scv4tlm and are used e.g. at https://github.com/Minres/SystemC-Components/blob/5f7387ab7e3dfc2ff6a7cac6fbe834ed7ec8ae36/incl/sysc/tlmtarget.h which in turn serve as building blocks in https://github.com/Minres/SystemC-Components-Test/tree/master/examples/simple_system The setup given by Kai is put into sysc::tracer where all the tracing setup (VCD & SCV) is impelemted. Best regards -Eyck

Duolos website definetely has examples with mode than two modules or more than two signals: https://www.doulos.com/knowhow/systemc/tutorial/modules_and_processes/ What do you mean by "derived module" ? Word "derived" in C++ and SystemC is used in a context of OOP, i.e. class can be derived from one or more base classes.

This is my plan. My plan is opposite: if this sort of syntax will be helpful for users, commercial vendors will probably support it in existing systemc synthesis tools. Speaking about SystemC "language" complexity: this is indeed the case with current SystemC. Because of that most HW designers prefer Verilog/SystemVerilog. But features I've presented are about reducing SystemC syntax complexity, not about further complication. So code will be more compact, less verbose and error-prone. Personally I find one good thing about HW design in SystemC: If I will lose my job in semiconductor industry, I can find another one as C++ programmer Something I couldn't do if I were a SystemVerilog programmer.

Hi Guys In TLM2 LRM, under section 14.18.2, I am not fully understand the following points Rule i) The effective word length shall be calculated as (BUSWIDTH + 7)/8 bytes. >> from where this expression comes from and why we have additional 7 in this expression. Rule i) initiators and targets are connected LSB-to-LSB, MSB-to-MSB. >> does it mean we direct connect the ports regardless to their endianness and host endianness. Can you please help me to understand these. Thanks Rahul

Hi kihtrak, the issue is right in the first few lines of your screenshot: d1.d_select(t_select); d_select is of type sc_out<bool> and t_select of type sc_signal<sc_uint<2>> which means you can't connect them because they have different data types (connecting an sc_out to an sc_signal is not the issue here). So you can either change the type of one of those or fit a converter in if you can't do that for some reason.

Checking for bus response is a very specific topic, as it is intimately tied to the protocol being used. I'd say a good first step is getting the infrastructure to stimulate accesses to unmapped areas and let users implement their own response checking.

The best method is not to use the macros at all. Learn the basics without the use of the macros. See http://verificationhorizons.verificationacademy.com/volume-7_issue-2/articles/stream/are-ovm-and-uvm-macros-evil-a-cost-benefit-analysis_vh-v7-i2.pdf

I'm not sure what you mean by "extend". You can use your Packet class as the template argument of sc_signal, sc_in, and sc_out as long as you implement the correct operators (as shown in section 6.4.3 of the 1666-2011 Language Reference Manual). However you can't bind a packet to an sc_in, you must bind sc_signal<Packet> instead, regards Alan

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.

I think the key sentence is "If the target represents a dynamically sized variable, such as a queue or dynamic array, the variable is resized to accommodate the entire stream. If, after resizing, the variable is larger than the stream, the stream is left-aligned and zero-filled on the right." So in your first case, the resulting stream is 101 (length 3) whether you stream it >> or <<. You then assign it to a dynamic array of byte. You therefore end up with 10100000 in a dynamic array is size 1. In the case of data source 4, you start with the pattern data_source [0] = 1, data_source[1] = 0, data_source[2] = 1, data_source [3] = 0 When you stream that with << or >> you get two four bit values, either 0101 or 1010 When you assign these to the dynamic array you get either 01010000 10100000 Q.E.D regards Alan

A suggestion for this type of questions: use StackOverflow. There is already a category for SystemVerilog and the you're more likely to get a quick answer.

Last week I had a chance to chat by phone with Accellera Chair Shishpal Rawat, and when I say chance that's accurate. Rawat is so busy these days, it's hard to believe he has time for any extraneous conversations. Not only does he have a full-time job at Intel, he has been chair of Accellera for four years and now is ramping up to take over the reins at CEDA at well. - Published by EDACaf ... View the full article ...

hi, there should be no limitations affecting you. there might be simulator limitations (size of arrays etc.) but even those are far away. the typical bounds for the register model are defined by the number of types (registers, registerfiles,...) and instances for compile/elab/simulation. these are soft (=handling) bounds (memory+time) rather then implementation bounds. /uwe

This isn't a solution to a glaring problem: it's standard operating procedure. If you want your sequences to receive events or access other information from the component hierarchy, this is what you do. However, the way you wrote it isn't entirely clear. I tend to plop a uvm_tlm_analysis_fifo in the sequencer and have the sequence pull from that. Or, I'll implement the write in the sequencer and put the data item in something like a mailbox that the sequence can access. The downside to this practice is that these sequences cannot just run on any ol' sequencer--once you declare the p_sequencer, that's the only one they can run on. It so happens that that is what I want most of the time, but some UVM purists may whince at the notion. Sequences can't have TLM imps or exports because they are not components. They can be created and destroyed throughout the life of the sim and so cannot have these quasi-static elements inside them. The declaration of the p_sequencer roots them into the component hierarchy.

More UVM oriented features are available starting with the 3.5 release. For example UVM Browser for exploring all the components of an UVM-based verification environment or Verification Hierarchy to inspect the topology of an UVM-based verification environment. For an overview of the UVM features in the DVT Eclipse IDE see http://www.dvteclipse.com/UVM_Support_in_DVT_Eclipse.html.

An SC_THREAD runs within its own stack. When an exception is thrown, this stack is unwound until it arrives at a matching exception handler. That's why you can catch your custom exception within the thread itself. If you don't provide your own exception handler, the SystemC kernel's generic exception handler for the thread jumps in and catches the exception on your behalf. Since the SystemC kernel can't know anything about your customException class, it is caught as std::exception (and translated to a new sc_report instance). The only available solution is to wrap your thread implementation (not the sc_start call) with a catch black and to translate and forward it appropriately to your test class (e.g. via a member of the module and then calling sc_stop() to stop the simulation). You can find the translation and forwarding as it is done in the SystemC kernel itself in the (Accellera) kernel's function sc_handle_exception() and its uses. hth, Philipp

Hello Sir/Madam, Real world on chip clock synchronization is achieved with a bautiful analog scheme - phase locked loop(PLL). A phase locked loop can be implemnted in both SystemC and SystemC-AMS very easily. An alternative is to use derived clocks - master clock triggering several other clocks - the derived clock runs at the same frequency as the master clock as: clkout.write(clkin.read()); Hope that helps.

I updated your code. This is the quickest way of using the default printers classes: `uvm_info("REPORT", $sformatf("my_q[%0d]:\n%s", i, my_q[i].sprint(uvm_default_line_printer)), UVM_LOW) // the uvm_default_printer is the uvm_default_table_printer, you can change it globally or pass one these declared printer classes: uvm_default_table_printer uvm_default_line_printer uvm_default_tree_printer I updated your code with the uvm_default_line_printer call and it works.

Hi is object oriented systemc code synthesizable? for example I defined a new data type (a class) and used it in my code. I don't know I can synthesize it or no. is there any free synthesis tool for systemc? or should I translate my code to Verilog and then synthesize it by existing synthesis tools?

Hello, i had used fifo in systemC in following way sc_fifo<int> cmd_fifo; //fifo decleration in constructor hci_top(sc_module_name nm):sc_module(nm), cmd_fifo(buffer_size) its showing no compilation errros but i want its depth like 20, and buffer size of each location of 8 bits(1 byte). Is there something we cannot change the default value of depth 16 of sc_fifo? How it would be possible? i also done in following way, but its not working sc_fifo<int depth> cmd_fifo(buffer size); Regards cam

Page-20 of "SystemC 2.0.1 Language Reference Manual Revision 1.0", "Index 6" of "Table 2. Examples of Fixed-Point Formats" (1) For "range signed" It says [-0.125, 0.109375]. But I think the range should be [-0.125, 0.1171875], because the minimum data is ".1110000" and the maximum one is ".0001111". (2) For "range unsiged" It says [0, 0.234375]. But I think the range shoulde be [0, 0.2421875], because the minimum data is ".0000000" and the maximum one is ".0011111". Whether my understanding is correct? Can anybody give me help? Thanks in advanced.

SystemC 2.3 has been successfully tested on Ubuntu 12.04LTS (32/64 bit), which has GCC 4.6.3 and binutils 2.22 as default toolchain. Therefore, I don't think that there is a fundamental incompatibility between these tool versions. "some if/else expressions cannot be executed correctly" doesn't sound like a linker problem either. You can try, if the problem is reproducable in the SystemC regressions package, that can be downloaded from accellera.org. /Philipp

It launches the function e() as a dynamic process, Alan

Hi KS, Before answering your question, it is worth pointing out the way the SystemC scheduler works. After inititialization, it advances time to the earliest time step where there is a scheduled event notification. It adds all processes that are sensitive to that event (or other events at the same time step) into a list of "runnable" processes. It then resumes execution of every process in the list of runnable processes (one at a time) in some non-deterministic order. This is known as the evaluation phase. An immediate event notification can add processes to the list of runnable processes within the current time step, provided such processes are currently waiting for that event. Once the list of runnable processes is empty, the scheduler proceedes to the update phase where primitive channels (such as sc_signal) that have been written to, get updated. These primitive channels may be in the sensitivity list of other processes, in which case there is another iteration of the evaluate and update phases known as a delta cycle. This continues until there are no more events to process at the current time step, when the scheduler advances to the next time step. Now, sssuming all of your processes above are within infinite loops, then after the end of the initialization phase, P1 and P3 will be suspended at their wait() statements and P2 will be waiting for an event on x. When the event in P1 and P3's static sensitivity list happens, both processes get added into the list of runnable processes in the current time step. P1 or P3 will then run. If P1 runs first, it will notify event x immediately, this will add P2 to the list of runnable processes. The next process to run could be either P2 or P3. Since P2 always waits for the event notified by P1, it will always run after P1 in any simulation cycle. It's not clear to me what instruction1,etc are doing. If they are just variables that are being read and written, then P2 could see the values written by P1. However, P3 could be executed after P1 but before P3. In which case P2 would see the values written by P3. We cannot predict what will happen (although the order will always be the same every time the simulation is run). Instruction3 in P2 would see the values of instruction1/2 set by P1 or P3, depending on the order that the scheduler executes the process. Hope that makes it a bit clearer for you. Regards, Dave

You should read up on C++ functions (and overloading) in general to learn about signatures. In the owning class of the simple_target_socket, a callback is registered instead of an explicit socket binding. One function is called reset_counter, the other one read_counter The stimulus class' socket (called read_increment) is bound in sc_main. But, as I said, the code is a rather bad example to learn about such basic things. /Philipp

The "right set of flags" obviously include (explicitly or implicitly) "-Wundef -Werror". From the C(++) preprocessor standard point of view, it is not a bug. All undefined symbols are supposed to be interpreted as 0: Side note: When using strict GCC compiler flags in your models (which is a very good idea!), you might want to include third-party libraries like SystemC as "system headers" to avoid such problems coming from external sources: $(CXX) $(CXXFLAGS) -isystem $(SYSTEMC_HOME)/include ... It is probably still a good idea to explicitly check for __SUNPRO_CC in sc_interface.h first. Thanks for reporting. Greetings from Oldenburg, Philipp

You can't call constructors in the class definition directly. You need to initialise members in the constructor: axi_master_transactor<> amt; axi_traffic_generator<> atg; SC_CTOR(axi_master_top) : amt("amt") , atg("atg", 2, 4, 0x0000000000000100, 1, 0, 8 ) { /* ... */ } Greetiings from Oldenburg, Philipp

WangYuchen, I am just adding to Philipps comment... Perhaps you do not understand the difference between channels (e.g. primitive channels such as sc_signal<T> or sc_fifo<T>) and data types (e.g. int or double). Channels represent hardware behaviors. In SystemC, hardware is only allowed to be declared and constructed before simulation begins during the "elaboration phase". Channels are used to transfer data between processes. They are NOT containers (e.g. array, struct or std::vector<T>). Thus sc_signal<int> is not a new type of data, but rather it specifies hardware that is able to safely transfer data between processes.