Jump to content


Popular Content

Showing content with the highest reputation since 02/23/2014 in all areas

  1. 6 points


    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
  2. 4 points
    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...
  3. 3 points
    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
  4. 3 points

    conditionnal import package in SV

    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.
  5. 3 points
    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.
  6. 3 points
    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:
  7. 3 points
    Philipp A Hartmann

    SystemC pause

    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
  8. 3 points
    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 >
  9. 3 points
    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!
  10. 3 points
    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.
  11. 2 points
    1) A TDF cluster (in this case formed by modules A, B and C) runs dependently from any other part in the system. This other part can be another (not connected) TDF cluster or any other SystemC module which is executed following discrete-event semantics. Looking from an analog perspective on the matter, this is correct: the analog part is "always active" (assuming there is supply voltage - often we do not model this in system level models). As such, there is no dependency between the TDF cluster(s) and SystemC modules, and the execution order is then implementation defined. In the end, you define that both the TDF cluster as well as the SystemC modules need to be active each 10ms, and this will happen. If you would look at the results in a waveform viewer, you will not notice the difference, because you are not interested which samples are written to the screen (or file) first, as long as the samples appear at the right place in time. 2) Here you touch on one of the fundamental differences between SystemC AMS TDF modules using data flow semantics, and regular SystemC modules which work under a discrete-event regime. Due to the evaluate/update mechanism in the SystemC kernel, is it simply not possible using SystemC modules to write a value and read the value in the same simulation cycle. When using SystemC AMS TDF models, they will form a TDF cluster which defines the execution order, and this cluster can be computed prior to simulation. This means the signal values in the whole cluster are computed and thus known for each time step. In a pure SystemC topology however, there does not exists such dependency graph, and therefore the signal values through the system only propagate after each evaluate/update cycle. This effect is part of the discrete-event semantics and cannot be altered.
  12. 2 points
    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.
  13. 2 points
    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>.
  14. 2 points

    uvm_tlm_analysis_fifo issue

    Do you create separate instances of packets for each one you put in the FIFO? If you don't, then all entries in the FIFO pointing to the same object, which you just update every time before you write it. This means all FIFO locations will see the updated object.
  15. 2 points
    You can't use the "implement interface and export" idiom in this case, as you obviously can implement each function only once (for each transaction type). You can use a small wrapper instead: SC_MODULE(abc) { typedef int T; sc_core::sc_export<tlm::tlm_analysis_if<T> > exp_1, exp_2; SC_CTOR(abc) : exp_1("exp_1") , exp_2("exp_2") , aw_1(*this,&abc::write_1) // create wrapper for each implementation , aw_2(*this,&abc::write_2) { exp_1(aw_1); // bind wrappers exp_2(aw_2); } private: void write_1( const T& ); // implementation for each export void write_2( const T& ); struct analysis_wrapper : sc_core::sc_object, tlm::tlm_analysis_if<T> { typedef void (abc::*write_func)( const T& ); // pointer to member function with implementation analysis_wrapper( abc& owner, write_func f ) : sc_core::sc_object(sc_core::sc_gen_unique_name("analysis_if")) , this_(owner), f_(f){} void write( const T& v ) { (this_.*f_)(v); } // forward call to registered implementation private: abc& this_; write_func f_; }; analysis_wrapper aw_1, aw_2; }; Hope that helps, Philipp
  16. 2 points

    wait() vs wait(SC_ZERO_TIME)

    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
  17. 2 points

    Accellera Updates UVM Standard

    New verification standard readied for submission to IEEE; 90-day public comment period begins. - Published by Semiconductor Engineerin ... View the full article ...
  18. 2 points
    Yes, but you need to write the constructors yourself (don't use the SC_CTOR macro). Something like #include "systemc.h" SC_MODULE(mod) { int i; mod(sc_module_name nm) : sc_module(nm) { // ... } mod(sc_module_name nm, int i_) : sc_module(nm), i(i_) { // ... } }; If you use SC_THREAD or SC_METHOD you must also include the SC_HAS_PROCESS macro. Try looking up SC_HAS_PROCESS in 1666-2011 and you should find an example near there, regards Alan
  19. 2 points

    static and dynamic processes

    Finally I am able to create process using sc_spawn() instead of SC_THREAD. My question is in the following code, is the process process1 is static or dynamic process ? class spawn_test : public sc_module { public: void process1(); SC_HAS_PROCESS(spawn_test); spawn_test(sc_module_name name){ //SC_THREAD(process1); sc_process_handle h1=sc_spawn(sc_bind(&spawn_test::process1,this)); } }; void spawn_test::process1(){ cout<<"Hello1\n"; wait(1,SC_NS); cout<<"Hello11\n"; } int sc_main(int argc, char*argv[]){ spawn_test* st = new spawn_test("st"); sc_start(10,SC_NS); return 0; }
  20. 2 points

    Randomization in an initial block

    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.
  21. 2 points
    There have been some improvements to the performance of the field automation macros, but I still do not believe their benefit is worth the cost. You should be able to prove it to yourself by creating a simple testbench with and without the macros.
  22. 2 points
    [WARNING: The following is philisophical] Assembly language programmers felt the same way about high level languages like FORTRAN. Functional programmers (e.g. C) felt the same way about object oriented languages. Schematics were the way of things for many engineers until RTL showed up. Verifying a design by occular inspection waveforms was replaced by self-checking testbenches with some resistance. Verification using directed test was mainstream and constrained random with functional coverage was resisted for many years. The advantages of reuse and scalability of the new techniques has slowly changed many. Engineers and programmers facilitate change, but themselves are some of the most resistant to change when it affects their own world. I think it's inevitable. As complexity increases, we have to find new ways to deal with it, and abstracting upwards is the way of things. One way to deal with change is to decide not to let the new ways master you. Instead read books, take classes and become a master of the new technology. Sadly, many universities have not caught up with modern practices at the undergraduate level.
  23. 2 points

    Analog data formats used

    Hi Torsten, Markers are now available. So you can add to any signal an annotation, a task or bookmark. If you use an annotation, the text will contain the actual value. cheers, thomas
  24. 2 points
    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.
  25. 2 points
    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