Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 10/22/2012 in Posts

  1. 10 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. 7 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
  3. 5 points
    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 ...
  4. 2 points
    Hi Kevin, if you check here https://github.com/Minres/SystemC-Components/blob/master/incl/scc/utilities.h there are three macros which make live easier: #define TRACE_VAR(F, X) sc_core::sc_trace(F, X, std::string(this->name()) + "." #X) #define TRACE_ARR(F, X, I) sc_core::sc_trace(F, X[I], (std::string(this->name()) + "." #X "(" + std::to_string(I) + ")").c_str()); #define TRACE_SIG(F, X) sc_core::sc_trace(F, X, X.name()) They can be used with local variables and arrays as well with SystemC objects providing the name() funtion. This way tracing a signal becomes as easy as (assuming _STATE_ being a signal or port): TRACE_VAR(_trace_, top.dpu.idu.weight_reader.m_traffic_gen._STATE_); Pls. note: the first 2 macros are assumed to be used within a sc_module. HTH -Eyck
  5. 2 points
    dave_59

    Help regarding fork_join usage

    You use fork/join_any statements when you want to create a number of time consuming processes and block waiting for one of them to finish. You create two processes, but they do not bloc - the finish immediately because they have fork/join_none statements in them . What you probably meant was something like initial begin me[0] = 1; me[1] = 2; me[2] = 3; repeat(5) begin : repeat_loop fork begin : b1 foreach(me) fork automatic int id = me; print_value (10+id,id); join_none wait fork; end : b1 begin :b2 foreach(me) fork automatic int id = me; print_value (20+id,id); join_none wait fork; end : b2 join_any disable fork; $display(" Disable Fork "); end :repeat_loop $display("@%g Came out of fork-join", $time); #20 $finish; end // initial begin
  6. 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.
  7. 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>.
  8. 2 points
    c4brian

    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
  9. 2 points
    Admin

    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 ...
  10. 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.
  11. 2 points
  12. 2 points
    OK, two answers - firstly, it'll probably work without that, assuming you have a c++ compiler installed, so you could just leave that out completely. Second answer - setenv is specific to c-shell. You're probably running bash, in that case the equivalent command is export CXX=g++ regards Alan
  13. 2 points
    Update: EDA Playground now supports SystemVerilog and UVM. You can edit and simulate this simple UVM testbench: http://www.edaplayground.com/s/example/546
  14. 2 points
    dakupoto

    array inside class

    Hello, Please note that SystemC is just a C++ library. So, there is no reason why an array cannot be declared, initialized and used inside a class. But there are some problems: 1. unsigned char* host_hci_pkt_arr == this is just a pointer to a single unsigned char NOT an array of pointers to unsigned chars. Why not : unsigned char* host_hci_pkt_arr[<SOME_SIZE>]; This is declaring array of pointers to an array of SOME_SIZE, explicitly. You could then fill the elements in as : host_hci_pkt_arr[0] = "0x01"; 2. The moment you use the "new" operator, you have to use the corresponding "delete" to clear memory in the destructor. On the other hand, by explicitly declaring the array as above, the compiler and runtime system takes care of memory allocation/deallocation. It appears that you are trying to model packets, and realistically a packet consists of a large number of bytes. If there are a large number of packets moving around, that are created dynamically, and then not deleted when the container object is deleted, one is looking at annoying memory leak issues. HTH.
  15. 2 points
    thomas.haber

    Parallel Simulation

    Hi Sumit, just some tought on this. I had similar ideas when i was covered with the spin simulator. If you want to keep a "systemC sync" on all processes you probably have to give more effort than you can take from it. A solution could be to allow async for a given amout (like tlm). In spin you have the possibility to do parallel calculation for a given "simulator time". In these proclets you calculate but can not change any signals, and change signals when your are out and back in sync. The same you can do in systemC. Doing parallell calculations in a seperate "real" thread, but keep systemC running in its own process means. regards, thomas
  16. 2 points
    Philipp A Hartmann

    Casting in systemC

    The implicit conversion between these types is not possible in all cases, mostly due to the danger of ambiguities in the API. Just add an explicit type conversion instead in terms of a C++ static_cast here: void do_cast(){ castout.write( static_cast<sc_uint<8> >(castin.read() ) ); } Greetings from Oldenburg, Philipp
  17. 2 points
    dakupoto

    solution for problem ...

    Hello, If you have read my responses to three recent queries on this newsgroup, you like the others, have run into a fundamental drawback/problem of C++ templates. The reason why your fifo works with single characters only is because during the crucial SystemC elaboration step, the size (number of bits) for a single character is known to the compiler. Also note that the SystemC built-in sc_fifo module can tackle built-in C++ primitive data types(char, double, float int ....) ONLY. As a character string can be of any size, it is an user defined data type, and so the user has to provide the mechanism to handle it. So, to transfer character strings via a custom fifo, a good option would be to: 1. Declare a custom interface - subclass of sc_core::sc_interface 2. Create a class that implements the interface - must ensure FIFO order in the input/output. This would be the character string FIFO. 3. Create custom ports to read/write character strings from/to custom channel Yes, it is rather messy, but it is straightforward. Hope this helps.
  18. 2 points
    apfitch

    Use cases of TLM over systemC

    Hi Cam, the idea of TLM2 was to create a standard API for transaction level modelling, that runs at high speed, and models memory-mapped buses. So the TLM Working group decided to create standard functions for both blocking and non-blocking transport; and a standard payload object. So the first advantage of using TLM2 over plain SystemC is simply that it is a standard API and payload. To model pipelined transactions, the TLMWG decided to use function calls from target to initiator and initiator to target. To allow function calls to be made in both directions needs a port on the calling module and an export on the target (forward), and a port on the target model connected to an export on the initiator. You could of course do this without sockets but you'd have to make two connections - by using a socket, a single bind call connects both export and port. Also you'd have to explicitly declare the initiator port and target export with tlm_transport_fw_if, and the target port and initiator socket with tlm_transport_bw_if - initiator socket is based on tlm_transport_fw_if and the target socket on tlm_transport_bw_if so you get that "for free". Finally, the sockets also have extra template arguments compared to SystemC ports - the Bus Width parameter. This ensures that the user cannot accidentally connect busses of different widths together. kind regards Alan P.S. There is another answer I could give: TLM2 *is* SystemC there is no difference. An initiator is a channel that implements the tlm_bw_transport_if. The target is a channel that implements the tlm_fw_transport_if. So the only difference from the "traditional" use of SystemC is the idea of a socket to provide simultaneous binding of the both port and export. If you want to, you could create your own exports and ports, and connect them yourself.
  19. 1 point
    Roman Popov

    Systemc performance

    Real-life simulation performance usually depends a lot on modeling style. For high-level TLM-2.0 models share of simulation time consumed by SystemC primitives is usually much lower, comparing to time consumed by "business logic" of models. Efficiency of simulation kernel (like context switches and channels) is much more important for low-level RTL simulations.
  20. 1 point
    Eyck

    sc_uint and unsigned int

    unsigned int has always the length defined by the underlying platform while sc_uint<> lets you specify the exact bit with of the type. In your case case I would use 'unsigned int' as it is faster and has less overhead. Best regards
  21. 1 point
    Hi Maxim, "addr" is a pointer, so you need to access its fields and methods by using operator-> : SCV_CONSTRAINT(addr->range(1,0) == 0); -- greetz, Bas
  22. 1 point
    Philipp A Hartmann

    tlm_socket_base_if

    Hi Guillaume, I agree, that the new pure-virtual functions in tlm_base_(initiator/target)_socket are not compliant to IEEE 1666-2011. However, I'm curious what use case you have to use these classes directly instead of inheriting from tlm_(initiator/target)_socket, where the functions are implemented? Regarding the implementation on the base socket level, I suggest to add a typedef to the fw/bw interface classes, and use these typedefs in the socket base class then. Something like: template <typename TYPES = tlm_base_protocol_types> class tlm_fw_transport_if // ... { public: typedef TYPES protocol_types; }; // tlm_base_target_socket virtual sc_core::sc_type_index get_protocol_types() const { return typeid(typename FW_IF::protocol_types); } Theoretically, these types could mismatch between FW_IF and BW_IF in manual socket implementations. Therefore, I'd suggest to refer to the FW_IF in the target and BW_IF in the initiator socket. Greetings from Duisburg, Philipp
  23. 1 point
    karsten

    Tool support for SystemC-AMS

    Due SystemC AMS is a C++ library on top of SystemC only, all simulators, which support SystemC principially also support SystemC AMS. We tested this for different Cadence, Synopsys and Mentor versions.
  24. 1 point
    Roman Popov

    SystemC and latency simulation

    If your pipeline is simple, like: get data -> process data -> put data, without I/O operations on internal pipeline stages, then you can model latency while keeping throughput: just put output data into fifo-like channel that will delay output for N cycles.
  25. 1 point
    Roman Popov

    adder - hierarchy- output issue

    Duolos website definetely has examples with mode than two modules or more than two signals: https://www.doulos.com/knowhow/systemc/tutorial/modules_and_processes/ What do you mean by "derived module" ? Word "derived" in C++ and SystemC is used in a context of OOP, i.e. class can be derived from one or more base classes.
  26. 1 point
    kurtlin

    ERROR IN NCSIM Simulation -E,CUVMUR

    Hi Venkatesh, You can check the details of this message via this command: nchelp ncelab CUVMUR I think you did not compile rcd2_top befor gen_ddr4_rcd_chip in your environment. Thanks, Kurt
  27. 1 point
    This is my plan. My plan is opposite: if this sort of syntax will be helpful for users, commercial vendors will probably support it in existing systemc synthesis tools. Speaking about SystemC "language" complexity: this is indeed the case with current SystemC. Because of that most HW designers prefer Verilog/SystemVerilog. But features I've presented are about reducing SystemC syntax complexity, not about further complication. So code will be more compact, less verbose and error-prone. Personally I find one good thing about HW design in SystemC: If I will lose my job in semiconductor industry, I can find another one as C++ programmer Something I couldn't do if I were a SystemVerilog programmer.
  28. 1 point
    Checking for bus response is a very specific topic, as it is intimately tied to the protocol being used. I'd say a good first step is getting the infrastructure to stimulate accesses to unmapped areas and let users implement their own response checking.
  29. 1 point
    Hi Biplab, Please consider using sc_core::sc_stop() from the place where you want to stop the simulation. Regards, Sumit
  30. 1 point
    dave_59

    uvm sequence

    The best method is not to use the macros at all. Learn the basics without the use of the macros. See http://verificationhorizons.verificationacademy.com/volume-7_issue-2/articles/stream/are-ovm-and-uvm-macros-evil-a-cost-benefit-analysis_vh-v7-i2.pdf
  31. 1 point
    I'm not sure what you mean by "extend". You can use your Packet class as the template argument of sc_signal, sc_in, and sc_out as long as you implement the correct operators (as shown in section 6.4.3 of the 1666-2011 Language Reference Manual). However you can't bind a packet to an sc_in, you must bind sc_signal<Packet> instead, regards Alan
  32. 1 point
    I think the key sentence is "If the target represents a dynamically sized variable, such as a queue or dynamic array, the variable is resized to accommodate the entire stream. If, after resizing, the variable is larger than the stream, the stream is left-aligned and zero-filled on the right." So in your first case, the resulting stream is 101 (length 3) whether you stream it >> or <<. You then assign it to a dynamic array of byte. You therefore end up with 10100000 in a dynamic array is size 1. In the case of data source 4, you start with the pattern data_source [0] = 1, data_source[1] = 0, data_source[2] = 1, data_source [3] = 0 When you stream that with << or >> you get two four bit values, either 0101 or 1010 When you assign these to the dynamic array you get either 01010000 10100000 Q.E.D regards Alan
  33. 1 point
    Last week I had a chance to chat by phone with Accellera Chair Shishpal Rawat, and when I say chance that's accurate. Rawat is so busy these days, it's hard to believe he has time for any extraneous conversations. Not only does he have a full-time job at Intel, he has been chair of Accellera for four years and now is ramping up to take over the reins at CEDA at well. - Published by EDACaf ... View the full article ...
  34. 1 point
    uwes

    uvm reg limitation

    hi, there should be no limitations affecting you. there might be simulator limitations (size of arrays etc.) but even those are far away. the typical bounds for the register model are defined by the number of types (registers, registerfiles,...) and instances for compile/elab/simulation. these are soft (=handling) bounds (memory+time) rather then implementation bounds. /uwe
  35. 1 point
    Actually, the initiator does not send a delay but he OWNs the sc_time object for the delay (as well as he owns the transaction/payload object). This allows loosely timed modeling and quantum keeping. For more information see: http://forums.accellera.org/topic/110-b-transport-interface/ or http://www.doulos.com/knowhow/systemc/tlm2/tutorial__1/
  36. 1 point
    cliffc

    Using $display in UVM

    Hi, Dave - I agree. UVM Guideline #1 - quit using $display! I am still trying to find where I read the part about using $display for table headers (and again, I disagree. You should not use $display ... period!) Regards - Cliff
  37. 1 point
    C++ before C++11 does not allow initialisation of non-static class members at declaration (which is what your red example is trying to do). So you must use a member initializer list (your blue example) regards Alan
  38. 1 point
    cristian_amiq

    UVM support in the DVT IDE

    More UVM oriented features are available starting with the 3.5 release. For example UVM Browser for exploring all the components of an UVM-based verification environment or Verification Hierarchy to inspect the topology of an UVM-based verification environment. For an overview of the UVM features in the DVT Eclipse IDE see http://www.dvteclipse.com/UVM_Support_in_DVT_Eclipse.html.
  39. 1 point
    An SC_THREAD runs within its own stack. When an exception is thrown, this stack is unwound until it arrives at a matching exception handler. That's why you can catch your custom exception within the thread itself. If you don't provide your own exception handler, the SystemC kernel's generic exception handler for the thread jumps in and catches the exception on your behalf. Since the SystemC kernel can't know anything about your customException class, it is caught as std::exception (and translated to a new sc_report instance). The only available solution is to wrap your thread implementation (not the sc_start call) with a catch black and to translate and forward it appropriately to your test class (e.g. via a member of the module and then calling sc_stop() to stop the simulation). You can find the translation and forwarding as it is done in the SystemC kernel itself in the (Accellera) kernel's function sc_handle_exception() and its uses. hth, Philipp
  40. 1 point
    Hey CAM, I have been in conversation with many people around for the same topic. underwritten are some replies: 1: WRT to hardware already built: it can be used as golden reference model for future enhancements as new features can easily be embedded to it then to hardware , thus indeed helping the driver team to run the updated driver on it. 2: in case the SOC already built need to be integrated to some other large SOC then this virtual platform there it is playing the vital role as above WRT to architectural exploration , needs to create daisy chain equation using matlab or other tool which can thus be simulated using virtual platform: - courtesy : `best architect` thats all i know , some others may add better. Regards, Karandeep
  41. 1 point
    Simple answer: no Slightly longer: Since SystemC is really just a methodology using a standardized API to a C++ library, it would rely heavily on users creating their components to have rollback. I have heard rumor of work exploring this goal. Adding this to the standard would fundamentally affect existing implementations.
  42. 1 point
    I updated your code. This is the quickest way of using the default printers classes: `uvm_info("REPORT", $sformatf("my_q[%0d]:\n%s", i, my_q[i].sprint(uvm_default_line_printer)), UVM_LOW) // the uvm_default_printer is the uvm_default_table_printer, you can change it globally or pass one these declared printer classes: uvm_default_table_printer uvm_default_line_printer uvm_default_tree_printer I updated your code with the uvm_default_line_printer call and it works.
  43. 1 point
    zareie.ehsan

    synthesizeable systemc code

    Hi is object oriented systemc code synthesizable? for example I defined a new data type (a class) and used it in my code. I don't know I can synthesize it or no. is there any free synthesis tool for systemc? or should I translate my code to Verilog and then synthesize it by existing synthesis tools?
  44. 1 point
    bennymao

    Fixed-Point Formats in SystemC

    Page-20 of "SystemC 2.0.1 Language Reference Manual Revision 1.0", "Index 6" of "Table 2. Examples of Fixed-Point Formats" (1) For "range signed" It says [-0.125, 0.109375]. But I think the range should be [-0.125, 0.1171875], because the minimum data is ".1110000" and the maximum one is ".0001111". (2) For "range unsiged" It says [0, 0.234375]. But I think the range shoulde be [0, 0.2421875], because the minimum data is ".0000000" and the maximum one is ".0011111". Whether my understanding is correct? Can anybody give me help? Thanks in advanced.
  45. 1 point
    SystemC 2.3 has been successfully tested on Ubuntu 12.04LTS (32/64 bit), which has GCC 4.6.3 and binutils 2.22 as default toolchain. Therefore, I don't think that there is a fundamental incompatibility between these tool versions. "some if/else expressions cannot be executed correctly" doesn't sound like a linker problem either. You can try, if the problem is reproducable in the SystemC regressions package, that can be downloaded from accellera.org. /Philipp
  46. 1 point
    apfitch

    static and dynamic processes

    It launches the function e() as a dynamic process, Alan
  47. 1 point
    Hi KS, Before answering your question, it is worth pointing out the way the SystemC scheduler works. After inititialization, it advances time to the earliest time step where there is a scheduled event notification. It adds all processes that are sensitive to that event (or other events at the same time step) into a list of "runnable" processes. It then resumes execution of every process in the list of runnable processes (one at a time) in some non-deterministic order. This is known as the evaluation phase. An immediate event notification can add processes to the list of runnable processes within the current time step, provided such processes are currently waiting for that event. Once the list of runnable processes is empty, the scheduler proceedes to the update phase where primitive channels (such as sc_signal) that have been written to, get updated. These primitive channels may be in the sensitivity list of other processes, in which case there is another iteration of the evaluate and update phases known as a delta cycle. This continues until there are no more events to process at the current time step, when the scheduler advances to the next time step. Now, sssuming all of your processes above are within infinite loops, then after the end of the initialization phase, P1 and P3 will be suspended at their wait() statements and P2 will be waiting for an event on x. When the event in P1 and P3's static sensitivity list happens, both processes get added into the list of runnable processes in the current time step. P1 or P3 will then run. If P1 runs first, it will notify event x immediately, this will add P2 to the list of runnable processes. The next process to run could be either P2 or P3. Since P2 always waits for the event notified by P1, it will always run after P1 in any simulation cycle. It's not clear to me what instruction1,etc are doing. If they are just variables that are being read and written, then P2 could see the values written by P1. However, P3 could be executed after P1 but before P3. In which case P2 would see the values written by P3. We cannot predict what will happen (although the order will always be the same every time the simulation is run). Instruction3 in P2 would see the values of instruction1/2 set by P1 or P3, depending on the order that the scheduler executes the process. Hope that makes it a bit clearer for you. Regards, Dave
  48. 1 point
    So i found these possibilities: * scv has features to record transaction into a text format. * logic poet made some extension to log transactions into a database. * UVM Multi Language/ UVM Connect Unfortunately scv is difficult to use on newer linux distributions (in fact i did not made it so far completely, i just got behind the configuration phase ). Seems to be difficult to use. UVM i did not understand so far.
  49. 1 point
    Kocha, There is no easy solution for your problem! Try following solution (I wrote it for systemc-ams, but you can easily modify that): write a function as follows : template < typename T > void sc_trace_template(sca_util::sca_trace_file* tf,sc_object* obj) { T* object ; if ((object = dynamic_cast < T* >(obj))) sca_util::sca_trace(tf, *object , object->name()); } Then create another function like as follows: void sc_trace(sca_util::sca_trace_file* tf, const sc_module& mod, const std::string& txt) { std::vector < sc_object* > ch = mod.get_child_objects(); for ( unsigned i = 0; i < ch.size(); i++ ) { sc_object* obj = ch[i]; // signals : sc_trace_template < sc_core::sc_signal < bool > > (tf,obj); // Add all other data types below (sc_in <T> , sc_out <T>, T needs to be explicitly specified): ...... // modules : sc_module* m; if ((m = dynamic_cast < sc_module* > (obj))) sc_trace(tf, *m, m->name()); } } Call sc_trace @ sc_main This is an extremely medicore solution, but will work. Regards, Sumit
  50. 1 point
    WangYuchen, I am just adding to Philipps comment... Perhaps you do not understand the difference between channels (e.g. primitive channels such as sc_signal<T> or sc_fifo<T>) and data types (e.g. int or double). Channels represent hardware behaviors. In SystemC, hardware is only allowed to be declared and constructed before simulation begins during the "elaboration phase". Channels are used to transfer data between processes. They are NOT containers (e.g. array, struct or std::vector<T>). Thus sc_signal<int> is not a new type of data, but rather it specifies hardware that is able to safely transfer data between processes.
×
×
  • Create New...