apfitch

@Tudor - Doh! Yes I meant TLM1 as standardized in 1666-2011, Alan

The analysis ports came from SystemC TLM2, where the write method is defined with const refs in C++, but since some of the fields in the SystemC payloads are pointers, and hence could be altered, the SystemC standard specifically made rules to say that these arguments should not be modified: "j) The write method shall not modify the transaction object passed as a const reference argument, nor shall it modify any data associated with the transaction object (such as the data and byte enable arrays of the generic payload). k) If the implementation of the write method in a subscriber is unable to process the transaction before returning control to the caller, the subscriber shall be responsible for taking a deep copy of the transaction object and for managing any memory associated with that copy thereafter." So in the original SystemC TLM implementation it was certainly intended that the arguments were const ref, and that the arguments should not be altered. regards Alan

There is one function defined in class sc_interface called default_event(). It's purpose is to allow you to implement static sensitivity by overriding it in your channel. If you already have an event declared in your channel that you want to use for static sensitivity, then you would return a reference to it using default_event() - and then your channel could be used in a static sensitivity list. That is the general use of the default_event() function, see section 5.14.5 of the LRM. Note that this is not specific to sc_signal, it may be implemented by any channel derived from sc_interface. In the case of sc_signal, there happens to be one event object declared inside the channel. Since it is the only one, it can be used as the default event for static sensitivity, so a reference to it is returned by default_event(). The designers of sc_signal also chose to create an access method to that same event. Since that event is triggered by a change in value, they called that method value_changed_event(). I hope that helps, regards Alan

Hi Jlnagel, we do what Tudor suggests (i.e. his first suggestion, supply generics on the command line which we then push into the config_db). This is using the -G or -g arguments to Questa vsim. We use a tcl based flow, so it would be perfectly feasible to randomize those parameter values in Tcl, the supply them as arguments to the simulator. However you do it, you can push the values (in a config object) into the config_db inside your top level module which typically creates the test class. If you use a path of *, you can make those values globally visible in any uvm component. regards Alan

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

I thought my sentence *was* pseudo-code Let me re-write it... Inside b_transport if process handle exists in array I'm being called by someone I know about. Do whatever's appropriate for that initiator else store process handle in array Do whatever's appropriate for that initiator regards Alan

That still sounds odd to me. "value" is a data member in the uvm_reg_field class. If you set the field to be e.g. RO, then it won't be randomized. See this code from uvm_reg_field.svh // Ignore is_rand if the field is known not to be writeable // i.e. not "RW", "WRC", "WRS", "WO", "W1", "WO1" case (access) "RO", "RC", "RS", "WC", "WS", "W1C", "W1S", "W1T", "W0C", "W0S", "W0T", "W1SRC", "W1CRS", "W0SRC", "W0CRS", "WSRC", "WCRS", "WOC", "WOS": is_rand = 0; endcase if (!is_rand) value.rand_mode(0); What types are ABC and Reg2? Alan

Perhaps David's suggestion is easiest (the last post in that thread). Each time b_transport is called, you can look up the process handle in an array. If it exists, you know that's the same caller as before. If it doesn't exist, you know you're being called by a process you haven't seen before, so you can store the handle in the array. Alan

There's a lot of material on the Doulos website http://www.doulos.com/knowhow - follow the links to SystemC and TLM2. You might also want to watch the videos VHDL vs. SystemVerilog and SystemC vs. SystemVerilog. There's an example of high level modelling in EAN1 at http://www.embecosm.com You might want to also look at the websites of companies offering virtual platforms (e.g. Synopsys, Cadence, Mentor, Carbon Design Systems, etc). Look on videos.accellera.org for recordings of various Accellera and Nascug events. regards Alan

See the last two posts in that thread for some ideas, Alan

It's hard to say, but VCS seems to be saying that Reg2.ABC.value is not declared rand? (i.e. the value member of the ABC class is not declared rand). Alan

Have a look at this thread http://forums.accellera.org/topic/1890-model-with-multiple-target-ports/ Alan

To quote Paul Dirac "That is not a question, it is a comment". regards Alan

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

"1. Parsing design file './01cfo_im.txt'" - that doesn't sound right, it sounds like you're trying to compile the text files? Alan

At the risk of furthering discussion on a feature no-one allegedly uses :-) the behaviour you describe is just like a module - if you declare a module and compile it on the command line, you'll get another top, in which initial blocks (and in the case of modules, always_comb blocks) will run at time 0. So you don't have to instantiate a program block for the same reason you don't have to instantiate a module at the top level. A program block isn't like a class, it's like a module, but with various restrictions, and yet more scheduler regions to understand, regards Alan

Hi Jocelyn, I think the reason the buffer_out works is that the trace function you are calling is declared in sc_signal_in_if, but isn't part of sc_signal_write_if. However using that trace is "cheating" because it's not part of the public API defined in the standard. Of course it does work with the Accellera Proof of Concept simulator. Regarding the copy constructor error, that's my fault - you need to declare the sc_trace function to take a const ref to the buffer_in, not a const object - because it's an object not a ref, it's invoking the copy constructor when the sc_trace is called, and as you've found some of the base class copy constructors are intentionally disabled. So change the function declaration to sc_trace(sc_trace_file *, const buffer_in<T> &, const std::string &); regards Alan

If you want to trace a user defined data type, you have to write an overloaded sc_trace function for that type. So if you wanted to trace your type you'd have to write a non-member function template<T> sc_trace(sc_trace_file *, const sc_buffer_in<T>, const std::string& ); and then in that function call sc_trace for the member m_sig. The standard says (in 8.2.1) "All changes to the value of the second argument that occur between the time the function is called and the time the trace file is closed shall be recorded in the trace file." regards Alan

I don't know. It's unlikely is SystemC is primarily used for high-level modelling or synthesis. Your best bet is to use a search engine, regards Alan

No there isn't unfortunately. A possible work-around is to use boolean signals instead, and use the event() method to test which boolean signal has an event, regards Alan

The main thing I notice is that in module 3, you have while(enable_clk.read()); At time zero enable_clk is false, so that while loop completes, and then the SC_THREAD never runs again as it has no infinite loop. Perhaps you need void m_multi_phase_clock_gen::module_main(void) { //////////////////////////////////////////////////// //Time 0 initialization !!! //////////////////////////////////////////////////// cout << "Clock Generator Initialized at time " << sc_time_stamp() << endl; clk.write(0); clk_45.write(0); clk_90.write(0); clk_135.write(0); clk_180.write(0); clk_225.write(0); clk_270.write(0); clk_315.write(0); wait(1.00, SC_NS); //////////////////////////////////////////////////// //Main Thread... //////////////////////////////////////////////////// while (true) { while(enable_clk.read()){ //generate phase 0 clk.write(!clk.read()); wait(1.25, SC_NS); //generate phase 1 clk_45.write(!clk_45.read()); wait(1.25, SC_NS); //generate phase 2 clk_90.write(!clk_90.read()); wait(1.25, SC_NS); //generate phase 3 clk_135.write(!clk_135.read()); wait(1.25, SC_NS); //generate phase 4 clk_180.write(!clk_180.read()); wait(1.25, SC_NS); //generate phase 5 clk_225.write(!clk_225.read()); wait(1.25, SC_NS); //generate phase 6 clk_270.write(!clk_270.read()); wait(1.25, SC_NS); //generate phase 7 clk_315.write(!clk_315.read()); wait(1.25, SC_NS); } } // end while(true) } regards Alan

No sorry, I just copied some stuff from Google, I don't really know what it means... Alan

Using the magic of Google... There's a post here http://eab.abime.net/showthread.php?t=74226 which suggests it's SELINUX related, and suggests a possible work-around as follows: Found a workarround. This on terminal starts fs-uae correctly: __GL_WRITE_TEXT_SECTION=0 fs-uae And the relative documentation for it (/usr/share/doc/nvidia-340/html/openglenvvariables.html) Disabling executable memory optimizations By default, the NVIDIA driver will attempt to use optimizations which rely on being able to write to executable memory. This may cause problems in certain system configurations (e.g., on SELinux when the "allow_execmem" boolean is disabled or "deny_execmem" boolean is enabled, and on grsecurity kernels configured with CONFIG_PAX_MPROTECT). When possible, the driver will attempt to detect when it is running on an unsupported configuration and disable these optimizations automatically. If the __GL_WRITE_TEXT_SECTION environment variable is set to 0, the driver will unconditionally disable these optimizations. Obviously replace fs-uae with the name of your SystemC executable, regards Alan

I don't understand the code. The commented code should not compile as you haven't declared event_1 Alan

It's easier to let Questa use it's own built-in copy of UVM. What happens if you try qverilog -timescale "1ns/1ns" -mfcu +acc=rmb +incdir+../../../../../src +incdir+../sv $TB_HOME/tb_top.sv -R +UVM_TESTNAME=$TEST_NAME regards Alan