apfitch

Hi Manikanta, Unfortunately there's no easy way round this. One solution is to figure out which signal changes first and remove that from the sensitivity list. So for instance if data changes before address, take data out of the sensitivity list and leave address in. However that's not a very easy to use solution as you have to work out which signal changes first. And later changes may break your code. Assuming your model is "just a model" i.e. not for synthesis, you could trigger an event shortly after address and data have changed. So suppose address and data are assigned somewhere in your design. You can create a delayed event based on address. E.g. sc_event e; void memory_needs_updating() { e.notify(1, SC_NS); } void writing_to_memory() { ----- ----- } SC_CTOR .... { SC_METHOD(memory_needs_updating); sensitive << address; // doesn't matter which one as they both change on the same delta SC_METHOD(writing_to_memory); // now runs 1 ns after address/data change sensitive << e; } What you're doing is manually scheduling the order of operations in your processor model. So you could have a fetch event, a decode event, an execute event and trigger them one after the other. I'm sure they are other ways of doing it (like using a clock!) kind regards Alan

There's a tutorial on the Doulos website http://www.doulos.com/knowhow/systemc/tutorial/ which talks about deltas in the last section. The traditional way around problems with deltas is synchronous design, i.e. make sure all outputs are assigned as the result of a clock edge, and sample the inputs on a clock edge. Then the timing depends only on the clock, and not on the delays or deltas of individual signals. In the code you have shown you do not have a clock. Of course it depends if you are modelling hardware. If you are modelling software, you may have to follow a different approach. regards Alan

Hi, the behaviour of SC_METHODs is the same as for Verilog always blocks (note 1). If you see the SC_METHOD process executing twice, the changes on the signals must be happening on different deltas, which is the same behaviour as you'd get in Verilog. You need to re-write your code so that the signals you are sensitive to change on the same delta. To confirm what's happening, you can print out sc_delta_count() from within the process to see on which deltas it is called, kind regards Alan (note 1) except at initialization; unless you're using SV always_comb in which case it really is the same even at initialization.

The backtrace seems to be pointing at Testbenches/TB_CLP_top.cpp:151, so I'd start looking there, Alan

Assuming you're on Unix/Linux, I would run the program under gdb, then when it crashes do a stack backtrace (the bt command). That will show you exactly where the error occurs. Once you know where the error occurs, put in print statements to find out the values of the various pointers and so on, regards Alan

Hi Mr Forever, you probably need to contact Synopsys support. debug_all and debug_pp are described in the VCS manuals, regards Alan P.S. Of course the first thing Synopsys will probably ask is why you're using such an old version :-)

Hi Hany, just returning to your original question yes you can have two analysis *ports* in a class. However as David explained, there is a problem if you try to have two analysis *imp*s in a class. Because then you need two functions called write() (the function implementations), which only differ in argument type - which is not allowed. What the decl_imp macros do is declare a kind of wrapper class, which implements write(), and then automatically forwards write to a function with a different name. You can then write the two functions with different names as that doesn't require overloading. You might find it helpful to look at the macro itself to see exactly what it does, regards Alan

I don't understand this code: module dut_cov_berc #(...) ( input [PCT_DEPTH-1:0] u_dut_berc_cmd.pct_err_status_vec, ........ ) You don't need the u_dut_berc_cmd.pct_err_status_vec doesn't make sense to me. When you use bind, it's like you've instantiated the bound module inside the target. So in your case it's like you wrote module dut_berc #(....) (clk, reset, .... ); dut_berc_cmd #(...) u_dut_berc_cmd (..); dut_cov_berc #() FUNC_COVERAGE (.*); So if you weren't using bind, you'd have to use module dut_berc #(....) (clk, reset, .... ); dut_berc_cmd #(...) u_dut_berc_cmd (..); dut_cov_berc #() FUNC_COVERAGE ( u_dut_berc_cmd.pct_err_status_vec, .*); which means your bind statement should be bind dut_berc dut_cov_berc #() FUNC_COVERAGE (u_dut_berc_cmd.pct_err_status_vec, .*); I think. I haven't compiled this, so I could well be wrong :-) Alan

One way to do it would be to make your base class constraint very wide, then narrow it down with extra constraints (thus avoiding a conflict). E.g. constraint c { i > 0 && i < 1000;} You can then constrain to any value within 0 to 1000 without a conflict. Alternatively you could use variables. There's nothing to stop you saying rand int unsigned num_jelly_bean_flavors; // knob constraint num_jelly_bean_flavors_con { num_jelly_bean_flavors == j; } and then constraining j from outside the class. Alan

You can override constraints in a class hierarchy, but that's not what you're doing. e.g. class a; int i; constraint c { i == 10; } endclass class b extends a; constraint c { i == 1 }; endclass Note the constraints have the same name and are in a class hierarchy, so the class b constraint replaces the one in class a. SV 2012 introduced soft constraints (constraints that will lose if in conflict with another strong constraint). regards Alan

Hi Mrforever, I'm not sure what you're trying to do exactly. It depends how you use your parameter TSID, but can't you just retrieve it from the config_db? Config_db parameters can be set from the command line if necessary. Alternatively you can just create a base class test with a default value for TSID, and override it to create customized test classes (different values of TSID). You can even declare TSID rand, and create randomized configurations of your tests. regards Alan

Hi, I don't really understand your question. Performance modelling is the modelling of performance. Register modelling is the modelling of registers. Behavioural modelling is the modelling of behaviour (i.e. with some or all implementation details missing). regards Alan

To connect UVM and SystemC, depending on your toolset, you could try Mentor's UVM Connect (which they say should work on all tools); Synopsys TLI; or Cadence UVM-SC. regards Alan

There's no easy equivalent. You could do int atemp; // or whatever data type a and b are void proc() { while (true) { atemp = a.read(); wait (10, SC_NS); b.write(atemp); } } SC_THREAD(proc); sensitive << b; You might possibly be able to build some kind of wrapper around sc_event_queue regards Alan

Google :-)

TLM 2 was designed for point-to-point communication - so yes, if you want to model bi-directional communication you need both sides to be both initiators and targets. regards Alan P.S. Of course a typical bus internconnect has both initiator and target sockets. But the definition of an initiator in TLM2 is generally considered to be that it creates transaction objects - whereas an interconnect may not create transaction objects, it may just pass them on (possibly altering the address field to implement routing).

You could have a look on TLM Central http://www.dr-embedded.com/tlmcentral/servlet/catalog It's possible to connect UVM and SystemC together using UVM Connect. That would let you use a SystemC TLM model in an SV UVM environment. Of course you need a simulator that supports both SV and SC to use it. Alan

Sockets are TLM2. Ports and Exports are SystemC. Alan P.S. TLM2 is also SystemC, of course. So perhaps I should say Sockets are features added as part of TLM2.

I can't see anything wrong. Can you post the error message? Alan P.S. tlm_tag is used to disambiguate functions that only differ by return type. As you're using the versions of put() which have different argument types, you should be OK.

There's a nice summary in section 10.1 of the IEEE 1666-2011 standard, Alan

There can be, the TLM2 API is implemented to some extent in UVM. I don't know how much it is used. Alan

OK, I don't remember seeing the phrase. But I assume the configuration space would the the set of all possible configurations that could be made for a given test environment. A configuration object is a wrapper object containing configuration information. Suppose you have an agent with 10 settings that can be randomized. Instead of putting 10 individual settings into the config_db, you could wrap them in a single object (a configuration object) and put that complete object once into the config_db. You also have the advantage that if the setting variables in the configuration object are declared rand, it is easy to create a new randomized configuration by randomizing the configuration object, regards Alan

No, configuration could be used to set up a sequence, for instance, and then by randomizing the configuration you could get different sequences. A simple example would be a sequence to read and write from a start address to an end address. You could put the start address and the end address in a configuration object as rand variables with constraints; and then randomize the configuration to get different ranges of addresses. Of course in that example, it would probably be easier to make the rand variables members of the sequence, but for more complex configurations it could well make sense to have a configuration object. regards Alan

There's no guarantee of the order that start_of_simulation() is called in different modules. Perhaps you can put the thing you want to happen first in end_of_elaboration(), and the thing you want to happen second in start_of_simulation()? regards Alan

I assume when you say "set rand variables" you mean "declare rand variables"? You put rand variables in a configuration class so you can randomize the configuration, regards Alan