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

GRENOBLE, France, March 19, 2013 (at the Design Automation and Test in Europe Conference) - Accellera Systems Initiative, an independent non-profit organization focused on the creation and adoption of electronic design automation (EDA) and intellectual property (IP) standards for design and verification, today announces completion of the SystemC® Analog /Mixed-Signal(AMS) 2.0 extensions. SystemC AMS 2.0 is an industry-driven mixed-signal standard for electronic system-level design. The SystemC AMS 2.0 language reference manual (LRM) is available for download ... View the full article: http://www.accellera.org/news/pr/view?item_key=88aa269bcefcfb819e6daf9d73cdca118d3fce5a

Napa, California, USA - February 14, 2012 - Accellera Systems Initiative, the not-for profit organization dedicated to create, support, promote, and advance system-level design, modeling, and verification standards for use by the worldwide electronics industry, will host its annual Accellera Systems Initiative Day on Monday, February 25. The day-long event kicks off the View the full article: http://www.accellera.org/news/pr/view?item_key=07fecbd19a605a7a27dbe42d8e86fe2ae56f46e8

You are correct that SystemC does not automatically delete objects. The reason many coders ignore destructors for SystemC modules/objects is several fold: sc_object's (which includes sc_module's, sc_port's, sc_signal's, sc_prim_channel's, etc...) are created during elaboration and would not need to be destructed until the end of simulation when typically a SystemC program simply exits. Thus the operating system will mop up for you. For example: int sc_main(int argc, char* argv[]) { top_module top_instance("top_instance); //< Construct the design hierarchy aka elaborate sc_start(); //< run the simulation return 0; //< exit the simulator and allow OS to clean up } SystemC coders are somewhat lazy and given the above example rationalize it away This is how they were taught (sad but true) That stated, it is probably worth noting that this situation may not always be the case, and some SystemC coders do write destructors (e.g. myself). It should be noted that in a co-simulation environment, the assumption of exiting after simulation may not be true. A vendor simulator might even presume to restart a simulation. Thus I argue it is better to create destructors as good C++ programming habit. TIP: Use the C++11 std::unique_ptr<T> instead of raw pointers. Assumes you can use this class. For older versions of C++, you might consider std::auto_ptr<T>, which is deprecated as I understand it.

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 Reza, The idea of the quantum is that a process does *not* give up to the scheduler until it decides enough local time has passed. For instance, imagine the current time (as returned by sc_time_stamp()) is 1000ns. My initiator has a local sc_time variable t. I initialise t to e.g. 10 ns. An initiator thread executes b_transport(tx, t); That means my local time is now 1010ns (but sc_time_stamp() has not changed, and no other process has run). The target which implements b_transport, now updates t by 100ns i.e. t now contains 110ns. In other words, the target is "pretending" it took 100ns to process my request, and my local "pretend" time is 1110ns. I can then call b_transport again with t = 110 + 10 = 120 ns; The target returns with 220 ns; and so on. So in answer to one of your questions, yes there can be many calls to b_transport within a quantum. Let's now suppose the global quantum is set to 500 ns. Eventually, my local time offset is greater than 500 ns. At that point my initiator calls wait(), and another initiator can run. SystemC time is still at 1000 ns, sc_time_stamp() hasn't changed. The second initiator runs sending calls back and forth until its local time offset exceeds the global quantum. It then calls wait(). Eventually all initiators have run and suspended. sc_time_stamp() increases, and off we go again. Now to keep track of that yourself would be possible, but boring to write the code - so in tlm_utils there is a utility called the tlm_quantum_keeper. The idea is that each initiator has its own tlm_quantum_keeper instance, and that's what keeps track of the local time offset. So the answer to "who manages the time" is either "you do - good luck!". Or use tlm_utils::tlm_quantum_keeper (much easier). In your third example, the idea of the delay parameter is that this represents the offset from systemc time (sc_time_stamp()). In my description above, I assumed the target did *not* call wait. However if the target *does* call wait, then the offset must be reset to 0 ns, because sc_time_stamp() has increased. I hope this helps, regards Alan P.S. I suppose I should really try and sell you a training course http://www.doulos.com/content/training/systemc_tlm2.php

Here is a short list of topics in no particular order you need to be comfortable with in order to be have an easier time learning SystemC: [Note: Others might chime in with variations on this list (add/subtract), and this is not necessarily a complete list, but I am fairly certain if you are able to comfortably use the topics I list below, you will have very little trouble syntactically with learning SystemC. In addition to C++, it helps if you have some familiarity with event driven simulation (e.g. SystemVerilog or VHDL). Also, if you have deep knowledge in another OO language (e.g. Java or SystemVerilog), you might have an easier time learning the C++ part.] Difference between declaration and definition Pass by value vs pass by reference Use of const (5 distinct cases) Casting C++ style (4 types) Implicit vs explicit conversions Use of function overloading and how to deal with ambiguity issues Use of std::string Use of streaming I/O How to declare, define and use classes Definition of default constructor Purpose and syntax of copy constructor How to declare and use namespaces Operator overloading as member functions and global functions. The difference between overloading and overriding. Relationship between class and struct How to extend classes and multiple inheritance Purpose of public and private Storage types and lifetimes: static, automatic, dynamic How to properly use new and delete Use of pointers and understanding of issues with pointer arithmetic Use of arrays and issues Advantages and use of std::vector<> Use of try-catch and throw Use of initializer list in constructor and a proper understanding of the order of construction Polymorphism and RTTI RAII Rule of 4 (6 if using C++11 or later) How and where to define templates/generic programming (does not need to be deep knowledge - just the basics) Use of templates and nested templates. Definition of full and partial template specialization. Different types of constructors and destructors Use of virtual inheritance (hint: it's not polymorphism) Extra topics: More STL including at least std::map<>, std::set<> Boost Modern C++ users (2011 onward) should know about: nullptr Uniform initialization Use of auto Use of ranged for Lambda definition, binding and use constexpr std::unique_ptr<>, std::shared_ptr<>

SystemC TLM is a part of the SystemC standard (both parts TLM1 and TLM2). True, it is an newer addition, but it is never-the-less part of the standard. TLM1 was the first attempt to standardize an API, which worked, but it didn't address the needs of the SystemC community as well as had been hoped. TLM2 standardizes a methodology to model address mapped bus communications and the associated API. It allows for easier exchange of IP blocks for simulation. TLM emphasizes that "ports" are not just wiring connection points, but rather a nexus for higher levels of communication. TLM2 has "sockets", which are really just glorified SystemC port combinations (sc_port & sc_export). TLM2 also standardizes some concepts (even if not stringently) of different styles of transaction level modeling (sometimes called coding styles). For instance, "loosely-timed" (LT) represents "execute as fast as possible while maintaining register functional accuracy"; whereas, "approximately-timed" (AT) means "provide sufficient timing detail to allow bus-level timing analysis[1]". AT does not simulate as quickly as LT because it has to provide extra details and timing behavior. Note 1: Not necessarily the same as clock cycle accuracy. On the other hand, the SystemC core provides the fundamental mechanisms that allow for design encapsulation (sc_module), event-driven simulation (sc_event and wait()), processes (SC_THREAD, SC_METHOD), a notion of simulated time (sc_time) and channels (sc_interface, sc_prim_channel, sc_channel). Channels are one of the most important features and enable abstraction of safe interprocess communications. SystemC also provides the minor addition of hardware datatypes (sc_logic<>, sc_int<>, sc_fixed<>, etc). It also provides primitive communications channels such as sc_signal<> and sc_fifo<>. Thus, the SystemC core provides the foundation needed to implement TLM. Sadly in some sense, SystemC provides a number of simplifications for writing RTL even though it is fundamentally not the strong point of the simulator. To some degree these simplifications are an holdover from SystemC 1.0 for backwards compatibility. I said sad because the simplifications have encouraged many to think of SystemC as an appropriate vehicle for writing RTL code, but then get frustrated at the lack of performance (for RTL). SystemVerilog and VHDL are much better suited for that task. The RTL aspect of SystemC is good in making it easier to interface SystemC to the other languages for co-simulation.

The first video series Introducing What's New in UVM 1.2 is out. Also, here is the UVM 1.2 Class Reference This video series covers the changes and new features introduced in UVM 1.2. It is intended for engineers who are already somewhat familiar with UVM. The series comes with CODE EXAMPLES THAT WORK. That's right, real working code and not just a snippet on a slide. The series has the following parts, covering different areas of UVM 1.2 changes. Recommend viewing in 720p quality or higher. uvm_object must have constructor code example Config DB uvm_enum_wrapper code example set_config code example Objections objections code example set_automatic_phase_objection code example Sequences sequence code example uvm_integral_t type uvm_integral_t code example Reporting (major changes) reporting code example Phasing phasing code example Factory extending factory code example parametrized uvm_event uvm_event code example Transaction recording (coming soon) I hope you find it useful. Let me know what other topics you'd like to see. Note: The videos are based on UVM 1.2 release candidate. I do not expect the features covered in the series to change for the final release. The above code examples will always work. If needed, they will be updated for the final UVM 1.2 release.

San Jose, California, USA, DVCon-21 February 2013-Accellera Systems Initiative (Accellera) announced today that Janick Bergeron, a member of the Verification Intellectual Property (VIP) Technical Subcommittee (TSC), is the recipient of the second annual Accellera Technical Excellence Award. The award is being presented at the Design & Verification Conference (DVCon) on Accellera Systems Initiative Day, February 25, 2013 at the DoubleTree Hotel in San ... ... View the full article: http://www.accellera.org/news/pr/view?item_key=0187f877445369468801500478e7a4e264ddad0e

"This week, Accellera Systems Initiative is announcing a new version of its SystemC library, Version 2.3 to be exact. There hasn't been a new version since way back in 2005 with Version 2.1 (albeit 2.2, a bug-fix release, was published in 2006), so this is the culmination of a lot of hard work." - Published by EDACaf ... View the full article ...

"Accellera Systems Initiative has released the version 2.3.0 of its SystemC open source proof-of-concept library. The offering comes free of charge to the global electronic design community, the organization noted. ... View the full article ...

The Accellera SystemC AMS Working Group released the 2020 edition of the SystemC AMS User's Guide. You will find the user's guide on this page: https://www.accellera.org/downloads/standards/systemc This version of the user's guide is fully compatible with the SystemC AMS standard released as IEEE Std. 1666.1-2016. It describes all the features introduced in the SystemC AMS language standard during the last decade. For example, the user’s guide now explains the use of the dynamic timed data flow capabilities, to make AMS system simulations even more efficient and running even faster. The SystemC AMS Working Group is currently preparing the release of the user's guide application examples as separate download. Availability of these application examples will be communicated at a later stage. Please use this forum to post your questions or remarks on the user's guide.

There is no such thing as CPU TLM modeling. Usually you write a C/C++ processor model with the needed accuracy (instruction accurate, cycle approximate, cycle accurate) and wrap it in a way that you translate memory accesses into TLM socket accesses. Along with that you need to manage to syncronization of the time of your model and the SystemC time (to run e.g. in loosly timed mode). Another task is to take the returned execution time of the bus accesses into account for the execution of the CPU model. This involves also the selection and implementation of the accesses (DMI & blocking or non-blocking). You can find a complete example of an instruction accurate VP at https://git.minres.com/DVCon2018/RISCV-VP (or https://git.minres.com/VP/RISCV-VP which is a newer version). The wrapper for the C++ model in SystemC can be found at https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/riscv.sc/incl/sysc/core_complex.h To put it straight: doing this correctly is a non-trivial task as it is the implementation of a micro-architecture model of a CPU. One option is to build an instruction accurate ISS and add a microarchitecture model like it is done in the ESECS project (https://github.com/MIPS/esesc) BR

SystemC 2.3.2 (and later) does support a query whether an event was triggered in the previous delta cycle (or immediately in the current evaluation cycle). This is similar to the sc_signal<>::event() function. With this, you can ask every element in your array, whether it was triggered and may have caused a wakeup of the process. Of course, multiple events can have triggered simultaneously and will only cause a single wakeup of the process. for( const auto ev& : e ) { if ( ev.triggered() ) { // ... } } Hope that helps, Philipp

Well, this topic could fill an entire book... If you implement a model the first question you should as is: What is the purpose of the model? Which questions should the simulation of the model answer? Looking at architectural exploration which goes quite often hand in hand with performance analysis the question is: does my HW/SW split and my HW partitioning satisfy my perfomance requirements (wrt. latency, thru-put, compute.efficiency, power,...). In this case you usually do not need to implement a particular functionality in detail rather something that 'behaves like' in terms of your requirements. E.g. if you need to check that your communication scheme (buses, arbiters, bridges etc.) fulfills the needed band with you use traffic generators but have a fairly accurate bus model, sometimes even at AT. And you need to implement the mechanisms to observer and extract the needed performance indicators to allow the analysis For software development the requirements are different. Here the maximum simulation speed is required so whereever possible you take short cuts. Bus transaction are not modelled anymore rather DMI is used (of course if functionality allows to do so e.g. when reading from/writing to a memory) and the entire model may run in LT mode which allowes parts to independently advance in time. Peripheral units may be modelled register-accurate but with out real functionality, i.e. a system control unit does not follow the needed scheme if changing e PLL frequency and alike. This might give you some high-level clue. There are many more things to it but all of them depend on the answer to the initial questions. Maybe the DCVon Europe 2017 tutorial on virtiual protorypes might provide a few more answers. You may find a PDF version of it at the MINRES site in the Publications and Papers section or at https://minres.com/downloads/VP_Tutorial_DVCon-2017.pdf as well as at the DVCon Europe website https://dvcon-europe.org/conference/history Best regards -Eyck

[I assume that when you say "TLM", you mean SystemC TLM 2.0.] You need to understand the difference between modeling styles. TLM is precisely about not modeling at the level of RTL. The SystemC TLM 2.0 also has two different modeling styles: Loosely Timed (LT) and Approximately Timed (AT). Let's look at each using a specific case. Suppose you are modeling two UARTs operating at 9600 baud (bits per second) with 8-bits, no parity, and 1 stop bit to transfer the message "Hello World\n". This configuration results in 960 characters per second (1.042 ms/char), which is quite slow, so probably you would be transmitting/receiving characters slowly enough that most systems would either process them one at a time or provide a FIFO (e.g. 16 bytes) and only process empty/full events. There is one more question to answer though. Consider the diagram below. The connections between sender to UART and UART to receiver are clearly memory mapped for most systems. So there is no question of modeling. The connection UART to UART is not memory mapped, which means you need to create a custom protocol. Furthermore, for TLM, it actually requires to connections since communication can be invoked bi-directionally (for a full UART). You need to decide what is important to model. For a high level model and efficiency, I would either transfer as much data as I could. It might even make sense to use TLM 1.0 rather than TLM 2.0. Do you have the requirement to inject errors? For my example, you would configure the transmitter, and then transfer a burst of 12 characters into the transmit FIFO on one end of the transfer and generate an empty FIFO interrupt at 12.5 ms later. The receiver side would be similar. What about the UART/UART transaction? An efficient approach might be as follows: Create a required extension that carries the transmit configuration information (baud rate, bits, parity, etc.) Use TLM_WRITE_COMMAND because all transactions over this socket pair are initiated from the sender. The second pair in the opposite direction would do the same thing. Check and insist that the address always be 0 and the streaming width is 1. Byte enables would be illegal. Check that the configuration matches before accepting data. Place all received data into an unbounded queue and then indicate the size allowed by the hardware model. Send interrupts using the sc_signal when the received queue goes non-empty. Consider the error situation when the timing indicates characters would be lost due to FIFO full and timing of characters. You will have to decide how to deal with interrupts received in your thread process. Notice that I do not model at the bit level. If you wish to add bit-level error injection, then inject errors at the point of transmission.

I agree with your conclusion that the observed behavior of the proof-of-concept implementation does not match the requirements of IEEE 1666-2011. I checked the code and it can be fixed by adding the check for resets to sc_thread_process.h (in the trigger_static() function): diff --git a/src/sysc/kernel/sc_thread_process.h b/src/sysc/kernel/sc_thread_process.h --- a/src/sysc/kernel/sc_thread_process.h +++ b/src/sysc/kernel/sc_thread_process.h @@ -485,5 +486,5 @@ sc_thread_process::trigger_static() #endif // SC_ENABLE_IMMEDIATE_SELF_NOTIFICATIONS - if ( m_wait_cycle_n > 0 ) + if ( m_wait_cycle_n > 0 && THROW_NONE == m_throw_status ) { --m_wait_cycle_n; I'll take this change to the language working group to get it fixed in a future version of the SystemC PoC kernel. Thanks for reporting! Greetings from Duisburg, Philipp

Because your "analyzer" instance is a local variable in the before_end_of_elaboration function, which gets destructed immediately, when the function returns. So there is no analyzer left to call the callback on later (same holds for the local signal sig2, btw.). You would need to allocate the module dynamically instead. You cannot alter/modify/redefine any existing port binding at any time. You can only add new bindings, including during before_end_of_elaboration. Hope that helps, Philipp

Hello, In SystemC you can use SC_THREAD's to model delays by using wait statements but you will incur performance penalty. Instead you can use event's and event queues to model delays using in SystemC as mentioned here: http://workspace.accellera.org/Discussion_Forums/helpforum/archive/msg/msg?list_name=help_forum&monthdir=200803&msg=msg00061.html You can replace the SC_THREAD example given in the above mentioned link with SC_METHOD removing the infinite while loop. Here's the modified example listed from the above mentioned link: template<typename T> class delay_transport : public sc_module { public: sc_in<T> in; sc_out<T> out; SC_HAS_PROCESS(delay_transport); delay_transport(sc_module_name name_, sc_time tdelay_) : sc_module(name_), tdelay(tdelay_), in("in"), out("out") { SC_METHOD(mi); sensitive << in.default_event(); SC_METHOD(mo); sensitive << eq; } sc_time tdelay; void mi() { val = in.read(); vq.push(val); eq.notify(tdelay); } void mo() { val = vq.front(); out.write(val); vq.pop(); } sc_event_queue eq; std::queue<T> vq; T val; }; Regards, Ameya Vikram Singh

Oh, there seems to be still an issue in 2.3.1, you should change the circular_buffer::clear function to template < typename T > void circular_buffer<T>::clear() { for( int i=0; i < used(); i++ ) { // buf_clear( m_buf, i ); // << BUG HERE buf_clear( m_buf, (m_ri + i) % m_size ); // This should(tm) be correct } m_free = m_size; m_used = m_ri = m_wi = 0; } Thanks for reporting. I'll take this to the Language Working Group to make sure a fix will be included in the next release of the proof-of-concept simulator. (I would still recommend to upgrade to 2.3.1... ) Greetings from Duisburg, Philipp

The link order is incorrect. The dependencies are resolved from right to left. Your Makefile should say: # list SCV before SystemC LIBS = -lscv -lsystemc -lm # local objects first, then the required libraries $(TARGET): $(OBJS) $(CC) -o $@ $(LIBDIR) $(OBJS) $(LIBS) As a side note: For C++ applications, you should prefer the variables CXX (for the C++ compiler) and CXXFLAGS (for the compiler flags). CC and CFLAGS are intended for C projects. Secondly, I would recommend not to define DEBUG_SYSTEMC in user code. hth, Philipp

Hi. Yes. A port does not hold a value. Whenever you access a port (read or write) you actually access the channel or signal bound to it. So, the port behaves like that signal. (But you should not write to an input port ) Greetings Ralph

In SystemC, the word "channel" simply means "something that implements an interface" and so can be bound to ports. In that sense, a "channel" doesn't have to be a means of communication. For instance you could have a RAM model that implemented an interface with read and write functions. The extra things you get in SystemC, beyond C++, are the ability to make your system modular with modules and ports; and threads (processes), events and time. Ports are templated with interfaces (classes derived from sc_interface) which specify that the thing bound to the port must provide the required functions. If you look at TLM2, for instance, ports are bound to exports, and the modules with the exports implement the functions that the modules with the ports require. In the original SystemC usage, both an initiator and a target are "a channel" in the sense that they implement an interface. What I'm trying to say is that you don't have to really think about channels at all. You can simply think in terms of interfaces, classes that implement those interfaces, and ports and exports that promote modularity by (in a sense) acting as special pointers with strong type checking. Of course in the SystemC library there are some built-in primitive channels, which have the special feature that they follow evaluate-update semantics. But that's just a special case of the more general concept of implementing an interface and accessing implemented methods remotely via ports/exports. So if you don't need the features that ports/exports/modules give you, you don't have to use them. Which is a long way of saying "yes" to your question :-) The main disadvantage of using immediate notify is non-deterministic behaviour. regards Alan

Hello all, For those who were not able to attend the SystemC AMS tutorial at DVCon 2014, the full tutorial is now made available as webcast, including the presentations with voice-over, examples ("labs") and solutions. Visit the following link (free registration required) http://www.accellera.org/resources/videos/amsnextwave We appreciate your feedback and your experience after following this SystemC AMS tutorial. Regards, Martin

The import statement only makes symbols visible inside the scope of the import. Your import statement is inside a generate block and does not make symbols visible after the generate. If you need to select this package globally, it might be better to have two different versions of the same package compiled into separate libraries. Then just select the library you want at compilation time. If the package only contains parameter values, then you might consider using a structure or class type as a container for your parameters instead of a package.

First, before I discuss the problems with SystemVerilog, I would like to point out that you are really missing a much simpler solution to your problem: module top; int farray[10]; //fixed array initial begin foreach (farray[jjj]) begin farray[jjj] = $urandom_range(121,0); end $display("******************************"); foreach (farray[jjj]) begin $display("%0d: %0d",jjj,farray[jjj]); end end endmodule : top With respect to "how many elements does my container have?", try the following. Note that you may need to comment out a few lines since the EDA vendor simulators don't all agree on whether some of these should work, and to be fair, the standard is not entirely clear... module top; byte Fixed_array[3]; byte Dynamic_array[] = {10, 20, 30}; string String = "abc"; byte Queue[$] = {40,50,60}; byte Assoc_array[string] = '{"a":70,"b":80,"c":90}; initial $display("Fixed_array size is %0d", $size(Fixed_array) ); initial $display("Dynamic_array size is %0d", Dynamic_array.size() ); initial $display("String size is %0d", String.len() ); initial $display("Queue size is %0d", Queue.size() ); initial $display("Assoc_array size is %0d", Assoc_array.num() ); // Alternate approach initial $display("$size(Fixed_array ) is %0d", $size(Fixed_array) ); initial $display("$size(Dynamic_array) is %0d", $size(Dynamic_array) ); initial $display("$size(String size ) is %0d", $size(String) ); // May not be legal initial $display("$size(Queue size ) is %0d", $size(Queue) ); initial $display("$size(Assoc_array ) is %0d", $size(Assoc_array) ); // Yet another approach initial $display("$bits(Fixed_array ) is %0d", $bits(Fixed_array) ); initial $display("$bits(Dynamic_array) is %0d", $bits(Dynamic_array) ); initial $display("$bits(String size ) is %0d", $bits(String) ); initial $display("$bits(Queue size ) is %0d", $bits(Queue) ); initial $display("$bits(Assoc_array ) is %0d", $bits(Assoc_array) ); // Strange result endmodule The standard attempts to rationalize away this inconsistency at the bottom of page 45 (85 in the PDF) in the IEEE 1800-2012 standard:[/size][/font][/color][/code] I for one don't entirely agree with this rationalization. The concepts are all closely related and should have been unified to make the coders job easier. Actually, $size() appears to work with most of them.

Manikanta's solution assumes temp is public. If not public, you can take the opposite approach and simply call sc_trace from within the module itself. You could even do it conditionally based on run-time command-line arguments: sc_core::sc_trace_file trace_file = 0; //< initialize to indicate not open top::before_end_of_elaboration() { for (int i=1; i<sc_argc(); ++i) { if ( trace_file == 0 && std::string(sc_core::sc_argv()[i]) == "-trace" ) trace_file = sc_core::sc_create_vcd_trace_file("your.vcd"); }//endfor } top::end_of_simulation() { if ( trace_file != 0 ) sc_core::sc_close_trace_file(trace_file); } ... extern sc_core::sc_trace_file trace_file; void dut::end_of_elaboration() { if (trace_file != 0) { sc_core::sc_trace(trace_file, temp,"temp"); } } Of course I am assuming fp is made public as shown, and that you have opened it before end of elaboration:

Yes, there is an sc_pause in SystemC (since IEEE 1666-2011 / 2.3.0). By calling this function from within your simulation, you can return to sc_main (see IEEE 1666-2011, Section 4.5.2). Please note that in the context of the SystemC AMS extension, pausing the simulation may be somewhat dangerous, as noted in Section 5.1.1 of the AMS extensions 2.0 LRM: That said, the use cases you have described seem to be blocking in nature. Why not simply call the code to ask for user input directly from the "specified point in the code"? In this case, you don't need to interfere with the simulator directly. NB: sc_halt is not part of IEEE 1666 and is not meant to be used in new code. Greetings from Oldenburg, Philipp

Accellera Day at DVCon Monday, March 3, 2014 8:30am - 7:00pm DoubleTree Hotel, San Jose CA Accellera invites you to a special day dedicated to technical standards at the 2014 Design and Verification Conference. Connect with experts and users as we learn, share, and network on the latest in EDA and IP standards innovations. Tutorial: UVM™ - What’s Now and What’s Next Tutorial: Using UPF for Low Power Design and Verification Lunch Panel and Technical Excellence Award Presentation Tutorial: Case Studies in SystemC™ Tutorial: Experience the Next ~Wave~ of Analog and Digital Signal Processing Using SystemC™ AMS 2.0 Tutorial: OCP: The Journey Continues DVCon Expo - Booth Crawl View full details >

An other way to understand this is to look at SystemC/TLM as pure C++ code and see what is going on.. Let us assume that you have two classes, "Initiator" and "Target", that need to communicate with each other. Target implements a function called "transport" to be called by Initiator, and Initiator implements a function called "response" - that is called by target. For the sake of the explanation here, the payload itself is not important, which we will assume is plain "int" in both directions. You would normally do this as following: // Interface classes: class initiator_if { public: void response(int i) = 0; }; class target_if { public: void transport(int i) = 0; }; class Initiator : public initiator_if { public: // Implement the interface void response(int i) { cout << "Got: " << i << " from target" << endl; } void bind(target_if &_if) { // Store the pointer locally m_target = &_if; } }; class Target : public target_if { public: // Implement the interface void transport(int i) { cout << "Got: " << i << " from initiator " << endl; } void bind(initiator_if &_if) { // Store the pointer locally m_initiator = &_if; } }; Next we instantiate the objects and "bind" them: Initiator initiator; Target target; initiator.bind(target); target.bind(initiator); I hope you are seeing where we are going with this. What has been done above is a crude equivalent of sc_port binding. There is one problem however with the approach above. What if the class "Target" doesn't implement the target_if directly? Like so: class TargetGrandChild : public target_if { public: void transport(int i) { // Implement the interface.. cout << "Got " << i << " from initiator (in grand child)" << std::endl; } }; class TargetChild { public: TargetGrandChild gch; /* Other stuff.. */ }; class Target { public: TargetChild ch; /* Other stuff.. */ }; One way to deal with this is to change the way bind function is called: initiator.bind(target.ch.gch); This is ugly. Firstly, it makes the client of bind function dependent on an internal design aspect of the "Target" class. For example, if the Target class changes tomorrow (to let the TargetChild implement the "target_if" directly), the bind function call needs to change. Also, to allow the client to call the bind function as above, the elements "ch" and "gch" must be made public, which may not be necessarily a good thing. A way out is to have an additional indirection. Let us call this as simple_export (a very simplified version of sc_export): class simple_export : public target_if { public: void transport(int i) { // One level of indirection p_real_target->transport(i); } void bind(target_if &_if) { p_real_target = &_if; } private: target_if *p_real_target; }; The new version of the Target class now looks like the following: class TargetGrandChild : public target_if { public: void transport(int i) { // Implement the interface.. cout << "Got " << i << " from initiator (in grand child)" << std::endl; } }; class TargetChild { public: TargetGrandChild gch; /* Other stuff.. */ }; class Target { public: simple_export port; private: // private is ok TargetChild ch; /* Other stuff.. */ Target() { // Tell "export" where the real implementation is port.bind(ch.gch); } }; The initiator will be "bound" to the target like so: initiator.bind(target.port); So for the simple_export to work, you need two binds: First is where the initiator is bound to the simple_export instance Second is when the "real" implementation is bound to the simple_export instance The simple_export class acts like a bridge. It forward the calls from the initiator to the "real" implementation. In case the "Target" itself implements the interface, the bind would look like: class Target : public target_if { public: simple_export port; private: // private is ok TargetChild ch; /* Other stuff.. */ Target() { // Tell "export" where the real implementation is port.bind(*this); } }; I hope this explains the line you pointed out in the code. The TLM socket has both a port and an export. Please note that the code snips above does not correspond to how OSCI simulator actually implements sc_port/sc_export!

You need to create the ports while the correct instantiation context is established. Since you can't do so during construction of the module, you need to defer it to the 'before_end_of_elaboration()' callback of SystemC. For this matter, you need to temporarily store the signals, in e.g. a vector of pointers. See the following (untested) sketch: SCA_TDF_MODULE(waste) { sca_tdf::sca_in<double> in; // Main 'in' port sc_core::sc_vector< sca_tdf::sca_in<double> > secondary_ins; // prefer sc_vector over vectors of pointers SCA_CTOR(waste) : in("in"), secondary_ins( "secondary_in" ) { } // temporarily store signal pointer void bind(sca_tdf::sca_signal<double> &s) { sc_assert( sc_core::sc_get_status() == sc_core::SC_ELABORATION ); secondary_signals.push_back( &s ); } void processing() { //... } private: // actually do the binding virtual void before_end_of_elaboration() { // create the secondary ports secondary_ins.init( secondary_signals.size() ); // bind the ports for( std::size_t i = 0; i < secondary_ins.size(); ++i ) secondary_ins[i].bind( *secondary_signals[i] ); // cleanup temporary signals secondary_signals.clear(); // be nice and call the base class callback sca_tdf::sca_tdf_module::before_end_of_elaboration(); } // temporarily hold additional inputs during elaboration std::vector< sca_tdf::sca_signal<double>* > secondary_signals; }; Hope that helps, Philipp

Yes. Have a look at IEEE 1666-2011, Section 4, especially 4.3.4.2 (sc_start, the starvation policy, and sc_pause). ("suspend" and "resume" are functions for individual SystemC processes, sc_start/sc_pause/sc_stop control the overall simulation). /Philipp

Hi. The never ending wait may be caused by race conditions. a) Notify with no argument means immediate notification. I.e., all processes sensitive to this event are made runnable in the same delta cycle. This may lead to non-deterministic behavior and should be used with care. Notify means all processes sensitive to this event are made runnable. The process in your case is sensitive to the event when its execution reaches the wait instruction. When the notify instruction is executed before the wait instruction is reached, no process is sensitive to the event. Event notifications are not stored for later waits. Assume the following example: p1(){ wait(ev1); cout << "wait done"; } p2(){ ev1.notify(); } When p1 starts first, it executes until wait is reached. Then p1 is suspended and p2 continues. The notification of ev1 is executed, p1 is made runnable again, and the message is printed. When p2 starts first, the notification of ev1 is done without any process waiting. Hence, it has no effect. Then p1 is started. It reaches the wait statement and will wait forever because the event notification has been executed before. No message will occur. Since SystemC contains no guaranty about the order in which processes runnable in the same delta cycle are executed, a model like the example leads to non-deterministic behavior. Greetings Ralph

Hi Mohit QEMU is an open source software mostly written in C. It emulates different architectures (ARM,MIPS, PPC, and more) from host and can run binaries on it. So you can boot android for arm on x86 PC. As far as I know the typical use cases of QEMU are System Emulator Frontend for Virtualization As a system emulator, android sdk uses QEMU to boot android to let developer check the application on x86 pc not on arm development board. Xilinx Xynq development kit also uses QEMU to run the software for the FPGA on x86 pc. For virtualization, QEMU is used to virtualize x86 pc on x86 pc (or arm on arm) with KVM or XEN. Shorter answer: Yes, Green Socs and TLMu are famous project for it. Iguess there may be similar projects more. Longer answer: QEMU consists of many kinds of processor models and peripheral models, so many tried to use it with SystemC. I also succeeded to boot arm linux on my customized TLMu( QEMU processor model + SystemC peripheral models). IMHO QEMU has 3 difficulties for integrating with SystemC. Building QEMU is sometimes troublesome because of its dependencies on many libraries. QEMU is written in C with gtk-like object system and with so many global/static variables. It is tough to understand and modify the source code. Global variables prevent you from multi-instantiation. QEMU source code is always changing and its speed is fast. It will be a painful work to catch up with the mainline release after you fork QEMU. QEMU is a really really useful software, actually I use it for virtualization and appreciate it. But honestly its source code is not something that I would love to recommend for learning material. I hope you will find a cool way to integrate it with SystemC. Regards, Yutetsu.

As the error says (emphasis mine) you need a default constructor (a constructor without arguments) in your case. In the module, you create an instance of 'decimal' without explicitly initializing it in the constructor of 'seprate_digit'. Theoretically, you could use an initializer list: SC_CTOR (seprate_digit) : in("in"), clk("clk"), d("d") // port names -> recommended practice , decimal(0,0,0,0) // <-- explicitly initialize decimal member Since you use 'decimal' as a signal type, you'll definitely need a default constructor. This could look like the following decimal() /* : dec0(), dec1(), dec2(), dec3() */ // optional, as sc_int has an explicit default constructor {} Secondly, you'll need to define more helper functions to use sc_signal with your own data types, see http://www.doulos.com/knowhow/systemc/faq/#q1 Greetings from Oldenburg, Philipp NB: Why do you post the question three times in 10 minutes? ;-)

Hi Mohit, 1. The important issue is not the language, but the technology. Behavioural synthesis tools generally deduce a combination of state machines (for control) and datapath (for signal processing). The key thing is that you as a designer do not have to write the micro-architecture yourself. Hence behavioural synthesis is potentially more productive than standard RTL synthesis. That argument is language independent. A behavioural VHDL tool would be more productive than an RTL VHDL tool. Writing RTL in SystemC would be no more productive than writing RTL in VHDL or Verilog. So your question "why do we require SystemC sythesis when we have HDL synthesis" would be better as "why do we need behavioural synthesis rather than RTL synthesis". And the answer is you only need it if it's better for you in some way (faster time-to-market for instance). No-one is forcing you to use behavioural synthesis :-) 2. I don't know if SystemC synthesis tools are interoperable. 3. How come tools exist even though the synthesis standard is a draft? EDA vendors are free to ignore standards :-) Standards only get adopted (and developed) if EDA vendors and users can see value in those standards. So I guess no-one is motivated to finish the synthesis standard. The key thing about the synthesis standard (as opposed to a language standard) is it's trying to guide how a tool may interpret SystemC code. EDA vendors see that as a legitimate area of product differentiation. The same thing happened with VHDL 1076.6 - the vendors essentially ignored it. 4. You may mix synthesisable and non-synthesisable code, you just have to hide the code using the pre-processor or meta-comments. The same is true in VHDL and Verilog - you can include non-syntheisable code, but it is typically hidden using meta-comments, e.g. -- synthesis translate_off code that won't synthesize goes here -- synthesis translate_on regards Alan

Hi Karandeep, the main usage of SystemC is in design of large SoC. As such, it is mainly used by large semiconductor companies. Typically such a company may be developing a large chip (very large!). That causes a number of problems How to concurrently develop software and hardware? How to start writing software drivers before the RTL design is finished? How to develop a reference model to be used in with Testbench Automation/Constrained Random Verification environments? How to build and re-use IP models for use in a high level model? (otherwise every company has to build processor models, bus fabric models etc from scratch). If developing a completely new chip, how to analyse bus bandwidths, data flows and so on - especially with multiple processors competing for bus resource. SystemC allows a company to attack all these problems - by building a model with accurate register modelling, the model may be used for software device driver development. Typically using very fast processor models and loosely timed styles, that model can boot multiple pieces of software on processor models at high speed. With some refinement, a similar model can be used as a reference for TBA/CRV. You need a reference model, so why not re-use it? For architectural analysis an approximately timed model is better suited - but remember you might not need it if you are refining an existing platform rather than starting from scratch. For re-usable models - that's the point of TLM2, to create a standard API to allow exchange of models. Existing APIs (SCML, TAC etc) can gradually migrate to a standard, promoting re-use. Finally why SystemC? Why not use SystemVerilog; or Java; or Python; or Haskell; or <fill in your favourite language here>? There are many factors, some practical, some political, some historical. In my opinion the main factors are/were 1. System Architects speak C++ / Excel / Word /Matlab. They don't speak Verilog/SystemVerilog/VHDL 2. SystemC started in 1999 3. EDA vendors got behind SystemC and developed tools to allow virtual platforms to be built I hope that helps, regards Alan P.S. Regarding finding references / information/ facts, the key point to remember is that the world of SoC/VLSI design is small. There just aren't many companies with the resources to develop large chips; and within those companies, there just aren't many system architects / modellers. In a typical large chip development they'll probably be many software engineers - probably considerably more than hardware engineers; within hardware, they'll be a few back-end people; a reasonable number of RTL designers; a similar or larger number of verification engineers; and perhaps 1 system architect. So SystemC just isn't used by large numbers of people, compared the Verilog/VHDL/SystemVerilog.

Hello all, Accellera Systems Initiative annouced the release of the SystemC AMS 2.0 standard. The AMS 2.0 standard is available as Language Reference Manual and can be downloaded here: http://www.accellera.org/downloads/standards/systemc Note that this standards update does not contain the user's guide. The AMS working group is working hard to release this document in the future. Now that AMS 2.0 is available, we anticipate that EDA companies and/or research institutes are getting inspired to make a proof-of-concept compatible with this standard. This means that today there is no simulation platform available, but we expect in the future it will become available. Also ask your preferred EDA vendor or partner when SystemC AMS 2.0 gets integrated in the tool and flow. Feel free to post your questions or remarks on the new SystemC AMS 2.0 standard in this forum. Regards, Martin Barnasconi AMS working group chair

Try: 1. Installed Visual C++ 2012 Express Edition (Note - won't work on XP only Windows 7/8) 2. Download Systemc-2.3.0.tgz 3. uncompress systemc-2.3.0.tgz 4. Assuming in c:\systemc-2.3.0 5. copy msvc80 to msvc11 (optional, but helps if you attempt to run regressions) 6. Run Visual C++ 2012 EE and open msvc11\systemc\systemc.sln 7. Upgrade is offered - click OK 8. Menu Build > Build Solution Build failed due to warning 4005 Edit sc_cmnhdr.h line 75 and add a test for _MSC_VER == 1200 as follows: // MSVC6.0 for() scope bug #if defined(_MSC_VER) && (_MSC_VER == 1200) #define for if( false ); else for #endif Now it should build. 9. Add an environment variable SYSTEMC set to c:\systemc-2.3.0\ 10. Set library, src, include paths as for Visual C++ 2010 Note: to find the property pages, load in a project (e.g. ex6 from the course). Then do View > Other Windows > Property Manager Expand the project name until you find Debug | Win32 > Microsoft.CPP.Win32.user and set the include and library directories to $(SYSTEMC)\src $(SYSTEMC)\msvc11\systemc\debug

San Jose, Calif., USA, 25 February 2013 (at the 2013 Design and Verification Conference) -- Accellera Systems Initiative (Accellera) announce today they have once again partnered with the IEEE Standards Association (IEEE-SA), a globally recognized standards-setting body within the IEEE, to deliver a leading electronic design and verification standard to engineers and chip designers worldwide. The revised version of the IEEE 1800 "Standard ... ... View the full article: http://www.accellera.org/news/pr/view?item_key=fb54cca2b7ac0cdcfd6ffacb85692f1a808adab0

On our website there's a tutorial and a number of videos and examples of TLM2 and SystemC (see www.doulos.com/knowhow/systemc and www.doulos.com/knowhow/systemc/tlm2), though I must admit the tutorial is quite hardware orientated. There used to be a tutorial on the Forte Design Systems website, but I can't find it any more. I would recommend downloading the latest standard (IEEE 1666-2011) via http://www.accellera.org/downloads/ieee/ I certainly would *not* recommend either the 2.0 user guide or the 2.0.1 reference manual, they are very out-of-date. To paraphrase someone, every time I see sc_bit I reach for my revolver :-) Probably the best general book is "SystemC from the Ground Up" by David C Black, Jack Donovan, Bill Bunton and Anna Keist. regards Alan

The old syntax sc_start(int) was deprecated when we removed the sc_set_default_time_unit(sc_time) concept. Your choices for sc_start are limited to sc_start(void), sc_start(sc_time) and sc_start(double),sc_time_unit).

Assuming you're using plain signal ports, you can use the event member function to check, whether a specific port has been triggered in the current delta cycle: sc_vector< sc_in< int> > in_vec; // ... SC_METHOD(proc); for( unsigned i= 0; i<in_vec.size(); ++i ) sensitive << in_vec[i]; // ... void proc() { for( unsigned i= 0; i<in_vec.size(); ++i ) if( in_vec[i]->event() ) std::cout << "in_vec[" << i << "] triggered." << std::endl; } Greetings from Oldenburg, Philipp

Following are European SystemC Users' Group events at the DATE Conference 2013 in Grenoble, France. 27th European SystemC Users' Group Meeting Tuesday March 19th, 2013 6:30pm - 9:30pm Room TBA Join the Accellera update and town hall meeting around Accellera technologies and standards. We give insights into their influence and requirements for future design strategies. More information, including registration and the final program, will be available at: http://www.ti.uni-tu...10.0.html?&L=0/. European SystemC Users' Group Workshop ESL -- Putting the Pieces Together: Integrating SystemC Design and Verification with AMS and Algorithm Design Friday March 22nd, 2013 8:30am - 4:50pm Room TBA This full-day workshop is focused on the integration of SystemC design and verification with AMS and algorithm design. It gives deep insights on how techniques may collaborate and converge. These topics are gaining more and more interest because a seamless integration of all relevant design and verification techniques is crucial. Besides digital hardware design, this is substantially important for the areas of algorithm and AMS design. The keynote from STMicroelectronics discusses the challenges of design flow integration in multi physical domain applications. The workshop includes four invited sessions from TU Kaiserslautern, NXP, Fraunhofer IIS, and Bosch -- providing knowledge about the core technologies, their application, and integration into ESL design flows. The core session’s part is complemented by an interactive discussion with the audience. This session is organized in town hall meeting style. This event requires registration. For an agenda and to register, see http://www.date-conf...nce/workshop-w1.

NAPA, Calif. - November 15, 2012 - Nominations are being accepted now through Friday, January 18 for the 2013 Technical Excellence Award sponsored by Accellera Systems Initiative (Accellera). The Award recognizes outstanding contributions in the creation of electronic design automation (EDA) and intellectual property (IP) standards by a member of an Accellera technical committee. Standards created by Accellera are contributed to the IEEE Standards Association ... ... View the full article ...

Hi Sumit, header guards won't necessarily help. They stop two header files being included sequentially - but if you have a function *body* in the header, and include that header in two independent files, you'll still get multiple definitions at link time. My guess is that Timmy is #including a gnoise.cpp. In that case the fix is to make a gnoise.h with the function prototype, with your header guards of course, and include the .h not the .cpp, regards Alan

Napa, Calif., USA, 16 July 2012 - Accellera Systems Initiative announces the release of version 2.3.0 of its SystemC open source proof-of-concept library, now available at no charge to the worldwide electronic design community. Compatible with the newly revised IEEE 1666 "Standard SystemC Language Reference Manual," announced by the IEEE Standards Association in November 2011, version 2.3.0 provides a number of important new features, ... ... View the full article ...