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

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

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.

If you want immediate communications between threads, then you should use regular SC_THREADs and wait on event, like wait(some_signal.value_changed_event());

You cannot not check typeid() against a string as this is compiler dependend. What you shoudl do is void write_out{ if(typeid(T) == typeid(sc_dt::sc_logic){ out.write(SC_LOGIC_Z); }else{ out.write(0); } } } But actually this is more a C++ related question, in my experience Stackoverflow is a good source of help. Cheers

You should start with learning your synthesis tool documentation. C++/SystemC synthesis is very tool-specific.

I believe it would be fair to say that there are no universally accepted best practices, and the system design will dictate much of the implementation. In the case of shared memory, the target would need to have some idea that the memory of interest is shared. So you would need somewhere in the system to have a mapping. It might be the entire device, or a memory map might exist as a configurable object. When the target receives a read request for shared memory, it would then synchronize in order to be certain that any writes from the past are completed in other initiators. Depending on your design, you might be able to reduce the number of synchronizations if you can know apriori the nature of the sharing. E.g. if a block of memory was shared using a mutex, then synchronization might be limited to the mutex with the assumption that if you own the mutex, then the block is not written to by other initiators. This of course has some risks in the face of software defects.

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

Hi! We have now released an updated version of SCV which should fix this issue for you.. You can find it here: http://accellera.org/downloads/standards/systemc

Quoting IEEE 1666-2011, 8.1.2 (color highlighting mine): So I think, the implementation in SystemC 2.3.2 is in line with the SystemC standard. Instead of failing with an assertion, a more explanatory error message would be helpful, of course. Greetings from Duisburg, Philipp

IEEE 1666-2011 section 10.2 states: IEEE 1666-2011 section 10.3.4 states:

Hello, Also hit a build issue when mixing different compiler standard compiler flags: The build error: SystemC review error: when building example using c++11 option and compiler supports: C++14 also. CMakeFiles/systemc.run.dir/src/main.cpp.o: In function `__static_initialization_and_destruction_0': /home/ameya/sysc2.3.2_rew/include/sysc/kernel/sc_ver.h:179: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)' Compiler used g++ 6.3 Using same compiler to build systemc-2.3.1a results in no issues, also when mixing C++ standard compiler flags to build SystemC models. While building the SystemC_2.3.2_draft one has to maintain the C++ standard compiler flags(-std=c++11 or -std=c++14), that is supported by the g++ compiler by default and any project using overridden standard compiler flags also needed to be updated to to default compiler standard flags. Here are the differences in the symbols generated by the same compiler over different versions of systemc: SystemC-2.3.1a: (Using g++ 6.3.0) 000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy) 000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy) 000000000000002c b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config 000000000000002a b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config_seen SystemC-2.3.2-draft review:(Using g++ 6.3.0) 00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy) 00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy) 0000000000000028 b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config 000000000000002c b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config_seen Can anyone comment why C++ standard specific API specs are required? For now I can circumvent the issue while setting either no compiler standard flags, or commenting out the compiler standard is passed into the build system. Is the SystemC library will be following this trend to build different version supporting different compiler standard flags? Note: As per cursory look into the source code I don't see any other API dependency to have information about the C++ standard being used to build and compile the SystemC library and the SystemC models. Would like to hear community members thoughts on this? Best Regards, Ameya Vikram Singh

There's not a dynamic port. The structure (modules/ports/channels) of a SystemC model is static once elaboration is complete. TLM is intended to model systems using memory-mapped busses. In that case you could use a router, and re-program the routing during simulation - but there's no direct built-in support for that, you'd have to make or buy a router model, kind regards Alan

Well, like I said, for brevity's sake I excluded the text from the book. But in short: you can use the wait_next_delay() within a sequence to wait a period of time, or you can embed this delay object in your driver and wait for a number of clocks. Maybe I'm being too idealist, but you never want to tie your sequences to a number of "clocks". Sequences have no notions of clocks or interfaces. Drivers see clocks, sequences see time. There are good reasons for this, but that would be a longer conversation. Your issue with regards to falling off of the clock boundary in your driver is a known one, so the book will show you how to avoid that. In short, your driver should try to fetch the next item, but if there isn't one it should call get_next_item() and then wait for a clock cycle. Then it drives. This allows back-to-back items if the sequencer is pushing quickly. After driving an item, you would call get_next_delay() and wait that number of clock cycles. This has probably gone on too long. The bigger answer to your question that I think Linc and I would agree upon is to create a reusable OO solution.

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 PoC SystemC simulator implementation is not designed to be restarted at time zero. Thus you cannot run two simulations within one main.

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.

At the risk of furthering discussion on a feature no-one allegedly uses :-) the behaviour you describe is just like a module - if you declare a module and compile it on the command line, you'll get another top, in which initial blocks (and in the case of modules, always_comb blocks) will run at time 0. So you don't have to instantiate a program block for the same reason you don't have to instantiate a module at the top level. A program block isn't like a class, it's like a module, but with various restrictions, and yet more scheduler regions to understand, regards Alan

Replace start and end address range with another associative array. Populate it with the addresses of interest: class i2c_addr_map; ... typedef int unsigned addr_t; typedef addr_t list_t[$]; local list_t slave2addrs[string]; local string addr2slave[addr_t]; // Constructor -- uses default // function to add a slave function void add_slave(string name, int unsigned addr_list[$]); assert(name != ""); //< minimal criteria if (slave2addrs.exists(name)) `uvm_warning("i2c_addr_map","i2c device name already exists! - adding") foreach (addr_list[i]) begin if (addr2slave.exists(addr_list[i]) && addr2slave[addr_list[i] != name) begin `uvm_error("i2c_addr_map","Overlapping i2c address - ignoring") end else begin addr2slave[addr_list[i]] = name; slave2addrs[name].push_back(addr_list[i]); end end endfunction // a utility function to return the slave at a certain address function string get_slave_by_address(addr_t address); if (addr2slave.exists(address)) return addr2slave[address]; `uvm_error("i2c_addr_map","no such i2c device name registered") return ""; endfunction endclass Now you have to add all the addresses: addr_map.add_slave("slave1", {'h10,'h11,'h13}); Obviously, you could add methods for adding ranges and make it more complex as you like.

Yes, defining NDEBUG also disables the sc_assert statements in the SystemC proof-of-concept implementation. Having said that, I don't think it is a good idea to do so globally. You usually want your simulation to reliably abort in case of an error/bug, instead of running into arbitrary undefined behaviour. I would recommend to leave assertions active by default until profiling proves that (specific) assertions have a significant performance impact. In such cases, selectively disable only these assertions in optimized configurations. /Philipp

Hello Norbert, I will take an action point in the Accellera IP-XACT Working Group to see if we can post the XSL transforms on the Accellera website. Also I already upconverted the busdefs that you mentioned to 1685-2009. I will also see if we can make those available on the website. Best regards, Erwin

UVM doesn't have to be serious all the time, does it? fyi... we got a new dog to keep us company in the office. His name is uvm. He's a good dog. He does tricks, but he can't jump. www.realityreused.com/support.html -neil

You are free to use my solution. All you need is a C++ compiler that supports the new 2011 standard (i.e. C++11). There are several free solutions out there including GCC 4.7, Clang 3.4, and Microsoft Studios Visual C++ 2013 Express Edition. They all work with SystemC versions 2.3 and later. I provide the complete code including a testbench. Any practioner proficient in SystemC should be sufficiently proficient with C++ that this is not hard to do. The solution could also have been rewritten using function pointers, but the result would be less compact code. I can point you to many tutorials and documents on C++11, which has many very good features. A few of the more forward thinking EDA vendors are about to introduce C++11 support in the near future; however, I cannot reveal their names due to confidentiality.

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.

If you want to guarantee the # of bits, but want speed then you should include <cstdint> or stdint.h (which has become part of the C++11 standard, but has been available for many years). You only have access to multiples of 8-bits, but at least least it's fast. Of course to grab bit ranges you will need to do the standard software masking rather than the convenience of sc_int. sc_int<W> should be used for situations where modeling the exact number of bits will make a difference in the results. For example, if the hardware implementation will have 13 bits and you do arithmetic (addition/subtraction), then sc_int<W> can catch overflow issues. Another example is synthesis of a register, where you need to control size of the hardware. The difference in performance is dramatic. Consider the following code and timing results: { using data_t = int32_t; //< replace this with sc_int<32>, sc_fixed<32,32>, float, etc... data_t result = 1; data_t A = 1103515245; data_t C = 12345; start_timer(); //< Calls a routine to get CPU time using C++11 constructs -- portable for (size_t loop=loop_count; loop!=0; --loop) { result = A * result + C; } cout << "result=" << result << endl; // Ensure compiler doesn't optimize loop out report_time(typeid(data_t).name); //< Calculates final time -- Be sure to filter with c++filt } I saw results for SystemC 2.3.0-ASI --- Jan 6 2014 07:20:27 (on 2.7GHz Intel i7) with no optimization using clang++ compiler: loop_count = 1e8 int took 0.343008s sc_dt::sc_int<32> took 2.01204s double took 0.755805s sc_dt::sc_fixed<32, 32> took 41.3482s With -O3 optimization: loop_count = 1e8 int took 0.125028s sc_dt::sc_int<32> took 0.199671s double took 0.364543s sc_dt::sc_fixed<32, 32> took 25.6714s So be careful what you select AND what compiler options you use. You can view the source code at https://github.com/dcblack/scdataperf

Hi Darrenxu, the code you've written in green won't work because SystemC has no shorthand for a concurrent signal assignment (VHDL) or assign (SystemVerilog). One solution is to write a helper process, e.g. void assemble_proc() { num1_t=num1; num1_s1=num1_t[0]; num1_s2=num1_t[1]; num2_s1=num2_t[0]; num2_s2=num2_t[1]; sum2_t[0]=sum_s1; sum2_t[1]=sum_s2; sum2=sum2_t; } // in the constructor SC_METHOD(assemble_proc) ; sensitive << sum2_2 << sum_st << sum_s1 << num2_t << num1_t; Another solution would be to use sc_vector (available in 1666-2011, Proof-of-Concept simulator 2.3.0). Instead of using sc_uint, you could then create a vector of sc_in<bool> and sc_signal<bool> for instance, and assemble and dis-assemble the vector. kind regards Alan P.S. I am also tempted to say "do it in VHDL or SystemVerilog instead" but that's not very helpful if you're trying to learn SystemC :-)

sc_fifo has its size set by a constructor argument. E.g. in a function you can write sc_fifo<int> fifo_1(72); to get a depth of 72 (72 locations). regards Alan

Thanks Mohit - I think the error is here: void fifo_write(unsigned char c); Static SystemC processes may not have arguments. You need to remove the argument from the function declaration, e.g. void fifo_write(); regards Alan

Hi Alan, i wish to do modellng of an IP in systemC and TLM but i am not sure whether should model the register map(a dedicated code for all the register used in IP) also .... IF yes then how would the register map be modelled in systemC and TLM keeping in mind some of them are read only/ write only , R/w or one shot .... Thanks Mohit Negi

Hi Sam. The Accellera implementation of the SystemC simulator is intended to run to completion. At the end of a simulation, the simulation program exits. Thats why there is no total clean-up of the simulation kernel at the end of a simulation. We use SystemC in combination with Simulink, and we observed the same issue when starting a simulation a second time without closing and reopening Matlab/Simulink. Our solution: ignore it and restart Matlab from time to time. The leaks are not that much and we have a lot of memory . Greetings Ralph

Nizamudheen, your analysis is correct. You've implicitly entered C++'s undefined behaviour land by adding several copies of the following function (including its local static variable) to your final executable, one from each .so file using TLM extensions: // Helper function: inline unsigned int max_num_extensions(bool increment=false) { static unsigned int max_num = 0; if (increment) ++max_num; return max_num; } The proposed solution to move the implementation of all extensions to a common base library may help. But this will still heavily depend on your C++ toolchain/implementation. The "correct" solution would be to move the implementation of (at least) the function above itself to an .so file. Sometime last year, we have briefly discussed in the LWG to start moving parts of the TLM implementation from the headers to the (SystemC) pre-built library. This would help to solve this issue as well. In fact, your use case is a strong motivation for this. Greetings from Oldenburg, Philipp

Regarding your questions about blocking transport... wait(delay) means that the initiator has chosen to synchronise to sc_time_stamp() by calling wait. In the target, the delay parameter represents the time at which the target should consider the request to have been received. In the initiator, the delay parameter contains the time at which the initiator should consider the response to have been received. If you have wait(delay) in the target, it means the target has chosen not to use temporal decoupling and has instead decided to wait to the actual sc_time_stamp() when the request should be received. The delay returned by the target does represent the time at which the response should be considered to have arrived (relative to sc_time_stamp()), which is the time at which the transaction ends. You can think of b_transport as representing a protocol with only two timing points, the time at which the request is sent, and the time at which the response is received. regards Alan

I'd say it does not. Below you can see an example. I tried to attach it. But I am not allowed to. Raul #include <systemc.h> SC_MODULE(Testbench) { sc_trace_file * traceFile; sc_signal<bool> toggle_o; void toggle(); SC_CTOR(Testbench) { toggle_o = 0; traceFile = sc_create_vcd_trace_file("testbench"); traceFile->set_time_unit(10, SC_US); sc_trace(traceFile, toggle_o, "toggle_o"); SC_THREAD(toggle); } ~Testbench() { sc_close_vcd_trace_file(traceFile); } }; void Testbench::toggle() { while(true) { toggle_o = !toggle_o; wait(100, SC_US); } } int sc_main(int argc, char * argv[]) { Testbench testbench("Testbench"); sc_start(500, SC_US); //simulate for 500 microseconds return 0; }

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

hi all, Normally, in C++, all dynamically created objects (pointer = new object) are deleted after their use is done to avoid memory leaks. This operation can be carried out in a destructor or special function as well. I have seen many SystemC (done by some experts) codes where such objects are not deleted. Is that not required in SC? Also now I am attempting to create a vector of pointers to objects. Shall I delete these objects later or does SC take care of this (I think SC can not do that)? Thank you.