David Black

This question is NOT a question for Accellera since Questa is a product of Mentor Graphics. Due to legal requirements it would NOT be appropriate for anybody to respond to your question here except to tell you to go elsewhere. You may read the preceding thread for a few clues, but if that does not suffice then please redirect your questions to Mentor.

Silly me, I was quite mistaken in my simple solution (and it only took me a few minutes after posting to realize it); however, this exercise reminded me of a 2011 feature: reset. This works for SC_METHOD processes, but is inconvenient for SC_THREADs. I enjoyed working the puzzle. You can see a full working example here: https://www.edaplayground.com/x/39QM Outline: When registering your SC_METHOD process capture the process handle and specify dont_initialize(). At the start of your method implementation, check for the trigger state of reset_event and return immediately if triggered. To reset static sensitivity, simply issue reset on the process. Include a comment that you are simply interrupting. Note 1: This assumes you are using a version of SystemC 2.3.3 or later. If using 2.3, you will need to add a bool flag that is set at the time of invoking reset and cleared inside the process upon detection. Note 2: You could also use reset_signal_is(); however, that would require adding deassertion and would be messier in my opinion. An alternate and less intrusive method would be to simply add an interrupt event into the sc_event_or_list every time you change sensitivity: next_trigger(some_event | interrupt_event); next_trigger(time_delay, interrupt_event); Unfortunately, this doesn't work for sc_event_and_list; however, you can synthesize that situation with another process. I will leave that for you to figure out.

You can restore a process' sensitivity only while executing the process prior to yielding. If that is the case, simply invoke next_trigger(void). Once you have yielded (returned), you will have to wait until you are triggered. If you don't call next_trigger() at all inside your method, then static sensitivity is implied for the next invocation. Static sensitivity is really just a precompiled list of of or conditions and is not really different from dynamic sensitivity anyhow. It is called static because it is established prior to the start of simulation (normally during construction). For dynamic processes, it concept is similar, but the "static" list is established prior to sc_spawn. So a simple solution is to add an event designed to get your waiting SC_METHOD back to reset the sensitivity. This can be done with 1 sc_event and a bool. I will illustrate in a followup post.

For ordinary memory transfers, you want the data length equal to the streaming width. For FIFO-like transfers, you would set the streaming width to the width of the FIFO, which will be less than the data length. Having a streaming length greater than the data length is somewhat pointless; however, it you don't want to think about it, using a value of UNINT_MAX (#include <climits>) is a great way of ensuring that streaming won't mess up the transaction. The default constructed value of streaming width is zero and illegal.

You might want to add an else clause and issue an error message in case the file does not open successfully (e.g. due to the filename or location being wrong or permissions). I/O errors always bite when you least expect them and they often waste time figuring out what happened. Clear error messages are very helpful. For more information: <https://www.cplusplus.com/reference/fstream/ifstream/is_open/> look at the example.

I strongly agree with @maehne that you should consider using sc_signal_resolved unless you guarantee that all the writers will be perfectly synchronized and never disagree with one another. If you don't, you risk race conditions. You might even want to consider using a pullup signal, which you can easily derive from sc_signal_resolved.

UVM is all about reuse. Reuse has several different aspects: Reuse of an engineers knowledge -- those experienced with UVM can usually jump onto an existing or new UVM project with very little ramp time. I have seen some verification environments using their own methodology that literally took months for new engineers to come up to speed on. Mind you misuse of UVM can lead to the same conclusion if you don't stay within the standard itself. Reuse of verification components -- means you can reuse a UVM environment without editing a single line of code provided by that environment. This is huge. It is possible to purchase UVM components that test standard interfaces (e.g., 1G Ethernet) and not have to create the code yourself. It still requires the expertise to plug the component into your environment, but it is relatively easy to do. UVM also means application of a tried and tested methodology rather than role your own. Downsides to UVM include: UVM is fairly complex and to get the most out of it generally requires training UVM is fairly large as a body of code and has a lot of boilerplate code Bottom-line: You don't have to use UVM to verify your code, but if your designs are large enough, it seem crazy not to adopt it. You can hire employees and contractors that know how to do leverage UVM and purchase components to shorten your design task. For small/tiny designs, it may not make sense.

Use either the multi_passthrough_target_socket<T> or any of the tagged sockets Not necessary You probably would need to use std::vector to manage various protocol related state variables per port. Obviously use the payload command field to distinguish Read/Write. Simple arrays are definitely faster and allow for DMI Sockets have built-in width already. Since width is generally a multiple of 8 bits, I would probably factor that into an aspect of my arrays. Take a look at Boost library for multi-dimensional arrays that would have decent performance for the memory since it will likely be multi-dimensional.

module who_changed_first(input a, b, start); always @(posedge start) begin byte changed; fork @a changed = "a"; @b changed = "b"; join_any case (changed) "a": work_1; "b": work_2; endcase end Assumes SystemVerilog. If Verilog you will need to add . See https://edaplayground.com/x/2NXz for example code.

This is not really a UVM topic and should be posted under a SystemVerilog or Verilog forum. Sounds like you could use basic SystemVerilog training. You might be served by a simple: initial begin $monitor( $time,,wdata,,rdata ); ///< Display wdata or rdata anytime they change end There can only be one $monitor active at any time. So if you have more than one need, you have to combine all into a single monitor. At any rate, perhaps you could put a code sample illustrating the problem on www.EDAplayground.com then share the link back here.

Of course you could not start the program, because a library is not an application. You have to write the simulation application yourself using the library to accomplish your goal. SystemC is not an application. It is a library. You need to be suitably proficient in C++ programming to accomplish the tasks.

How proficient are you with C++? Have you read IEEE-1666-2011 (download for free via accellera.org)? Have you downloaded an read all the documentation that comes with the Proof-of-Concept library for SystemC (version 2.3.3)? There are examples and documentation there. Have you visited edaplayground.com? There are limited examples there. Do you hold a degree in Electrical Engineering or Computer Science? Have your read the book, SystemC: From the Ground Up? It contains exercises. You can find associated files at https://github.com/dcblack/SCFTGU_BOOK/blob/master/README.md You will also find some examples on GitHub at various locations. Here is one (I have several others including some currently under development): https://github.com/dcblack/ModernSystemC

You have several errors due to: Failure to specify the compile-time option '-std=c++11' when using C++11 syntax. Compiler defaults to C++03. 'using namespace std' in conjunction with a global named 'array'. std::array<T> is a new templated class in C++11 and conflicts. Changing references from 'array' to '::array' solves the problem. It would be better to rename it to something that does not collide (e.g. data_array) or remove the 'using' clause and properly provide the correct 'std::' prefix where appropriate. Failure to use uniform initialization of a variable used as a global. As of C++11. When creating a global use the syntax 'TYPE VARNAME { CONSTRUCTOR_ARGUMENTS };' This also works for class members. Specifying global variables that should really be private class members (e.g. count). Solved by moving the declarations to the header file and using uniform initialization. Note that use of globals is generally (including this case) a very poor design decision. Note also the use of '#include "systemc.h"' is frowned upon in many circles. Use '#include <systemc>' (without the '.h') instead. You need to take a proper course in modern C++ to avoid C++ syntax errors. These are novice C++ errors. This forum is for real SystemC issues, not C++ syntax.

Dynamic threads have sc_process_handle's that can be used to distinguish them from one another. Dynamic processes can also have arguments passed when they launch by value, reference and const reference. So processes are not a problem. Vectors of sc_event's should be fine (because they are not considered as elaboration time only objects), data structure can be done the same. Ports and modules on the other hand are somewhat problematic; however, you could allocate sc_vector's of these with a fixed upper limit; however, connectivity must be fixed at elaboration. You will of course need to manage the configuration information as to how you use these. I suspect that once you properly define the parameters of your design, it will all be possible. I suggest you first draw a diagram illustrating what you are attempting to do and describe the application. You certainly cannot have an open-ended "I want it to do everything". So please indicate the bounds and time relevant information. Perhaps provide a UML sequence diagram to give a better idea of the dynamic nature required.

@junjiegI apologize for not understanding that your comment was referring to the header of the PSS standard. I will step aside.

Your question is inappropriate for this forum and organization. C++ is used by several of the standards here; however, the definition of C++ and its appropriate use should be redirected to the C++ standards organization elsewhere. This is also not a forum to debate the merits of syntax decisions made elsewhere unless you are proposing and contrasting the syntax with a fundamental language defined here.

This is easy. First, sc_int<N> and sc_uint<N> are limited to 64 bits. So you cannot use 256 there; however, you can use sc_bigint<N> and sc_biguint<N> for any value of N>64. Second, you will need to specify constants as strings since C++ itself does not support >64 native numbers; although, you can use C++ user-defined literals to get around this limitation if using C++ 2011 or better.

Try issuing a fatal message: `uvm_fatal(get_type_name(),"Self-destruct")

usleep() does not interact with the systemc kernel at all. SystemC time is different from real time.

You cannot compile C++ under a C compiler and SystemC is C++. You will need to create an extern "C" wrapper and you will need to deal with maintaining objects. This is really a C++ issue and you should probably read <https://isocpp.org/wiki/faq/mixing-c-and-cpp>.

Nothing in SC_THREAD main has any dependence on anything other than time in your example. The external event will have not effect. If you want to see an event, you must be waiting on it. usleep only consumes time. wait(SC_ZERO_TIME) means that the simulation for that portion will wait zero simulated seconds and resume. You should add wait(event) to see it.

Instructions are in the README and should be clear enough. Let me know which instruction is puzzling. OSX uses a simple bash shell by default, unless you are on Catalina. Which version of OSX are you on?

With the advent of OSX 10.14.x Mojave and OSX 10.15.x Catalina, it becomes a little more complicated because you will need to give permissions to the tools (requires admin privileges), but it is fairly straightforward. If you find the OSX installation too challenging you could try a Docker installation of Ubuntu or a Virtual Machine (VM) such as VirtualBox with Ubuntu. Personally, I am using Mojave and the Cmake install quite successfully. Being a bit old school, I use MacVim (GVim for Mac) as my text editor, and iTerm for my terminal.

I'm sorry, but I really think that if you upgrade your C++ skills, most of these errors will become obvious. Q: Have you tried putting your code onto http://www.edaplayground.com? You can then share a link to your code, which will make it infinitely easier for somebody to comment on the errors. It's free.

Yes, but you need to use a real string (not empty). Usually, the instance name matches the name of the instance itself. For example: #include "top_module.cpp" //< Real code goes in here #include <systemc> // Minimal sc_main function int sc_main(int argc, const char* argv[]) { Top_module top_instance{ "top_instance" }; sc_core::sc_start(); return 0; }