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 y

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

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

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

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 t

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 100

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. Jav

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 "so

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 s

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.

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 n

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 yo

[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

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

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>

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.

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

I'm seeing the uvm_object get_inst_id() function not returning unique, new IDs for new objects that I create. More specifically, it's returning a repeating cycle of a few different IDs. Looking under the hood at uvm_object.svh it's a pretty trivial mechanism so I can't see why it isn't working. Also, in a derived class I created I mimicked the same mechanism and my mechanism works fine. Test case and example output is below. Note that the static instance count value seems to increment nicely as expected but the instance ID values seem to bear no relation to that count and repeat every

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 requ

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

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 )

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 simula

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 Process

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 { publ

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( "se

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 notification

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

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 fo

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

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 proc

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) #d

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

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 Syste

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 ...