apfitch

I'm not really sure, but I'd guess that because you're making an sc_vector of ports, you need to obey the rules for ports. In particular, ports can only be instantiated during elaboration - by calling init() during a process, I think you're creating ports after elaboration. Can you try putting the call to init() into the before_end_of_elaboration() callback instead? Actually I'm not even sure that will work, but I think that's the underlying problem, the ports haven't been created at the point you're trying to bind them, Alan

I think it might be vcs -V Alan

Could you use set action to set the action for all info messages to uvm_none? Something like +uvm_set_action=uvm_test_top.*,_ALL_,UVM_INFO,UVM_NO_ACTION Alan

You need to separate your dff.cpp into two files, dff.h and dff.cpp. Put the class in dff.h, and put the function func() in dff.cpp. Change the main to include dff.h instead of dff.cpp, Alan

You should be able to use std::randomize(id_array) with { unique {id_array}; }; Untested though, regards Alan

You can write both sequential and combinational logic using SC_THREADs. You can write both sequential and combinational logic using SC_METHODs. SC_THREADs are more flexible for modelling because you can call wait(). SC_METHODs generally execute faster (more efficiently) than SC_THREADs because they do not need to store state (because you are not allowed to call wait()). Because you can do everything with SC_THREADs, including call wait(), there is no real need for SC_METHODs, except to optimise simulation speed. regards Alan

It looks to me that if you assign h true and the first value to p_in using the same clock as your process, then it should work, i.e. you should be able to sample p_in with i = 0 and j = 0 correctly. It's hard to say without seeing now you are applying the stimulus to h and p_in. regards Alan

Scheduling order of processes in the same run phase is random. It's important to realise that because a is a primitive channel (sc_signal), it doesn't update its value immediately. a will only update after all processes have and reached a wait statement, regards Alan

It's kind of hard to say without know what triggers the printing of a and b. How do you print a and b? Also what is the sensitivity of each process? regards Alan

Hi, I've got a couple of comments. Firstly, in template <int N> class Generator_Register: public sc_module { public: Generator_Register(sc_module_name reg_Name_, string file_name_): sc_module(reg_Name_), reg_Name(reg_Name_), file_name(file_name_) { //... General_Reg<N> reg_Name(reg_Name_, reg_Default, bit_RangeNum, bit_Name, bit_Start, bit_Length, bit_Status); } public: int reg_Num; int bit_RangeNum; sc_module_name reg_Name; string *bit_Name; int *bit_Start; int *bit_Length; int *bit_Status; sc_bv<N> reg_Default; string file_name; }; the declaration of the variable General_Reg<N> reg_Name is a local variable inside the constructor - so it will disappear when the constructor completes. You should make it a class member if you want it to persist. Secondly from section 5.3.3 of IEEE 1666-2011 In other words you're not allowed to declare a variable of type sc_module_name, which you've done in both your classes. That's because sc_module_name is "magic", it helps build the hierarchical names of all modules during elaboration. If you need to keep the name inside a class, store it in a string. kind regards Alan

It looks like you have not followed the install instructions correctly. Firstly you should install in a different directory from the one where you untarred the distribution. Secondly you should create a subdirectory "objdir" and do ../configure. regards Alan

Hi Stephan, I believe std::gets was deprecated in c++11, removed in c++14. But std::fgets is still valid. regards Alan

Perhaps you are simulating an un-timed system? Or you don't have any objections and your test environment is quitting too early? Alan

Do you have an infinite loop in the SC_THREAD axi_run? - you need one, otherwise the thread will run once then return, regards Alan

I would say that is not within the spirit of TLM2 approximately timed modelling. In particular 11.2.3.5 b ) in IEEE 1666-2011 Note that the use of nb_transport in the above quote is defined in 11.1.2.4 a) of the same document regards Alan

Hi Brian, your post may be correct when comparing SystemVerilog Interface Classes to SystemVerilog Abstract Classes, but the original poster was talking about SystemVerilog Interfaces, not SystemVerilog Interface Classes, regards Alan

I think this is covered by the example coverpoint x2 in the 1800-2012 standard at the bottom of page 536. At the top of page 537 it says (my emphasis). Interesting... regards Alan

The release notes are inside the SystemC 2.3.1 distribution, in the text file RELEASENOTES. Is the following post relevant? http://stackoverflow.com/questions/12629255/detecting-abi-compatibility-issues-with-gcc regards Alan

There's not a dynamic port. The structure (modules/ports/channels) of a SystemC model is static once elaboration is complete. TLM is intended to model systems using memory-mapped busses. In that case you could use a router, and re-program the routing during simulation - but there's no direct built-in support for that, you'd have to make or buy a router model, kind regards Alan

For your question 1, probably - I don't know exactly what triggers your monitor. But as you say, using a primitive channel such as sc_signal will result in a delta delay. For 2., it jumps to 110ns because that's what you told it to do in your driver here: d_bin = 1; wait(5, SC_NS); wait(100, SC_NS); regards Alan

The obvious problem is that you don't have an infinite loop in the SC_THREAD gtb::proc_graytobinary(). Thus it will only run once at time zero. The quick fix is to make it an SC_METHOD instead, regards Alan

That sounds correct, Alan

I believe that's correct - though I always find endianness very confusing! There are examples on page 489 of the LRM which might help, regards Alan

Hi Rahul, I think I said "during elaboration" rather than "in the end_of elaboration callback". Anyway, the standard says on page 6 "A static process is a process created during the construction of the module hierarchy or from the before_end_of_elaboration callback. A dynamic process is a process created from the end_of_elaboration callback or during simulation." So I was wrong to say "elaboration" (which includes the end_of_elaboration callback according to section 4 of the standard), I should have referred to page 6, kind regards Alan P.S. Have you really been thinking about this for 2 years? :-)

One other thing to note is that I2C uses an open drain connection, which in VHDL you can model with 'H' (weak high). But in sc_logic you've haven't got 'H', so you'll probably have to use 'Z' to model the undriven (no pull down) state of the I2C connections. regards Alan