Jump to content

Leaderboard


Popular Content

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

  1. 6 points
    Admin

    Welcome!

    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. 3 points
    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 6 objects. Am I missing something really obvious here or is this a possible bug. I see this using UVM 1.1d downloaded from Accellera. ////////////////////////////////////////////////////////////////////////////////////////////////////////////// class my_object_t extends uvm_object; static int next_id; int my_id; function new (string name="my_object"); super.new(name); my_id = next_id++; endfunction : new `uvm_object_utils(my_object_t) endclass begin my_object_t my_object; for (int i = 0; i < 100; i++) begin my_object = new(); `uvm_info("", $sformatf("my object inst id is %d (0x%0x) or %0d, inst count is %d (0x%0x) or %0d", my_object.get_inst_id(), my_object.get_inst_id(), my_object.my_id, my_object.get_inst_count(), my_object.get_inst_count(), my_object.next_id), UVM_LOW) end end UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72135 (0x119c7) or 0, inst count is 9585 (0x2571) or 1 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72122 (0x119ba) or 1, inst count is 9586 (0x2572) or 2 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 581 (0x245) or 2, inst count is 9587 (0x2573) or 3 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72126 (0x119be) or 3, inst count is 9588 (0x2574) or 4 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72120 (0x119b8) or 4, inst count is 9589 (0x2575) or 5 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 69783 (0x11097) or 5, inst count is 9590 (0x2576) or 6 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72135 (0x119c7) or 6, inst count is 9591 (0x2577) or 7 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72122 (0x119ba) or 7, inst count is 9592 (0x2578) or 8 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 581 (0x245) or 8, inst count is 9593 (0x2579) or 9 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72126 (0x119be) or 9, inst count is 9594 (0x257a) or 10 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72120 (0x119b8) or 10, inst count is 9595 (0x257b) or 11 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 69783 (0x11097) or 11, inst count is 9596 (0x257c) or 12 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72135 (0x119c7) or 12, inst count is 9597 (0x257d) or 13 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72122 (0x119ba) or 13, inst count is 9598 (0x257e) or 14 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 581 (0x245) or 14, inst count is 9599 (0x257f) or 15 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72126 (0x119be) or 15, inst count is 9600 (0x2580) or 16 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72120 (0x119b8) or 16, inst count is 9601 (0x2581) or 17 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 69783 (0x11097) or 17, inst count is 9602 (0x2582) or 18 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72135 (0x119c7) or 18, inst count is 9603 (0x2583) or 19 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72122 (0x119ba) or 19, inst count is 9604 (0x2584) or 20 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 581 (0x245) or 20, inst count is 9605 (0x2585) or 21 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72126 (0x119be) or 21, inst count is 9606 (0x2586) or 22 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72120 (0x119b8) or 22, inst count is 9607 (0x2587) or 23 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 69783 (0x11097) or 23, inst count is 9608 (0x2588) or 24 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72135 (0x119c7) or 24, inst count is 9609 (0x2589) or 25 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72122 (0x119ba) or 25, inst count is 9610 (0x258a) or 26 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 581 (0x245) or 26, inst count is 9611 (0x258b) or 27 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72126 (0x119be) or 27, inst count is 9612 (0x258c) or 28 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72120 (0x119b8) or 28, inst count is 9613 (0x258d) or 29 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 69783 (0x11097) or 29, inst count is 9614 (0x258e) or 30 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72135 (0x119c7) or 30, inst count is 9615 (0x258f) or 31 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72122 (0x119ba) or 31, inst count is 9616 (0x2590) or 32 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 581 (0x245) or 32, inst count is 9617 (0x2591) or 33 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72126 (0x119be) or 33, inst count is 9618 (0x2592) or 34 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72120 (0x119b8) or 34, inst count is 9619 (0x2593) or 35 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 69783 (0x11097) or 35, inst count is 9620 (0x2594) or 36 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72135 (0x119c7) or 36, inst count is 9621 (0x2595) or 37 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 72122 (0x119ba) or 37, inst count is 9622 (0x2596) or 38 UVM_INFO @ 0 ns: uvm_test_top.tb.c [] my object inst id is 581 (0x245) or 38, inst count is 9623 (0x2597) or 39
  3. 3 points
    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
  4. 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
  5. 3 points
    dave_59

    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.
  6. 3 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...
  7. 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.
  8. 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:
  9. 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
  10. 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 >
  11. 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!
  12. 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.
  13. 2 points
    aheimberger

    SystemC 2.3 Pretty-Printer

    Hey Guys, I don't know if you know about GDB Pretty-Printer. GDB Pretty-Print let you print your debug output in a legible way. I tried to write the Pretty-Printers analyzing the SystemC 2.3 implementation and I was learning how the information is stored within the SystemC implementation. You will find the Pretty-Printer under following link. https://github.com/AHeimberger/SystemC-2.3-Pretty-Printer On Github you will find instructions about installing the Pretty-Printer and a verification python file. Hope this Pretty-Printer helps you and does not cause to many problems. I were also able to use them within Eclipse. Cheers Andy
  14. 2 points
    I would strongly recommend using the current version of SystemC 2.3.1. That should install "out of the box" just by following the INSTALL and README files in the installation. The steps you're quoting (1 to 4) are very specific to someone's setup, and not general. Also gcc 2.95.2 is about 10 years old - most modern linux distributions are up to about gcc 4.7 or later. I don't know what version of linux you're running, but there's a good chance that your install will already have gcc and/or g++ installed. Try typing g++ --version at the command line. If it doesn't work, use the package manager for your distribution. On Fedora / RedHat you would type yum install g++ On Ubuntu /Debian you would use apt-get regards Alan
  15. 2 points
    tudor.timi

    uvm reg limitation

    I don't think there is any hard limitation in place. You just instantiate as many registers as you want. There are no fixed size arrays for the registers to go into. You are, probably, limited by the hardware you're simulating on (i.e. memory), but this has nothing to do with UVM RAL itself.
  16. 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
  17. 2 points
    I'm assuming, it is ok for you to have different sockets for these two b_transport functions. The simplest solution is to use two tlm_utils::simple_target_socket instances and just register different functions for each of those: SC_MODULE(target) { tlm_utils::simple_target_socket<target> socket1; tlm_utils::simple_target_socket<target> socket2; SC_CTOR(target) : socket1("socket1") , socket2("socket2") { socket1.register_b_transport(this, &target::first_b_transport); socket2.register_b_transport(this, &target::second_b_transport); } void first_b_transport( tlm::tlm_generic_payload &, sc_core::sc_time & ); void second_b_transport( tlm::tlm_generic_payload &, sc_core::sc_time & ); }; Alternatively, you can use tagged sockets and dispatch to different implementations based on the ID parameter. hth, Philipp
  18. 2 points
    apfitch

    model with multiple target ports

    Have a look at the section on convenience sockets in the LRM. There are some sockets that are described as tagged (see table 59). If you use one of the tagged target sockets, then you can arrange that a socket ID is associated with each initiator, so you can tell them apart. See the example at the bottom of page 531 for instance. If you have two independent register banks accessible from independent ports, why not write one target and make two instances of it? If you do want a single class with two target ports, then it's up to you to decide what to do by checking the address when you receive the generic payload. Remember that TLM2 was intended for memory-mapped busses, so your two register banks would be (I assume) at different memory map locations. regards Alan
  19. 2 points
    San Francisco, Calif., June 3, 2014 (at the Design Automation Conference) -- Accellera Systems Initiative (Accellera), an independent non-profit organization focused on the creation and adoption of electronic design automation (EDA) and intellectual property (IP) standards, announces it has developed new verification and design modeling extensions for its Verilog-AMS standard. Verilog-AMS provides powerful structural and behavioral modeling capabilities for mixed-signal designs in which the ... ... View the full article ...
  20. 2 points
    rahuljn

    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; }
  21. 2 points
    dave_59

    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.
  22. 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.
  23. 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.
  24. 2 points
    David Black

    We named our new dog UVM

    So was the previous pet named OVM or VMM?
  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
×