apfitch

Hi, yes if you repeatedly randomize the same object you need to be careful to clone it if you want to keep it. But cloning (which invokes copy()) must be more efficient that typeid::create (I hope!). I have done stopwatch style measurements but I didn't write them down, other than noticing that logging has an effect. We've also noticed in our setup that Questa's transcript window actually seems to be a bit faster than running on the command line and logging to the terminal - but that could be an artifact of our setup. And of course we only log to the transcript window when doing interactive debugging. If your simulation gets slower the longer it runs, it might be worth just watching the process in the OS - on Unix you can use vmstat to see what's happening, or top. When I've had simulations that got slower as they went on I've normally found some kind of growth in memory usage, which could either be due to stupid constraints; growing queues; or a genuine tool bug. Sorry it's all a bit wishy-washy... Alan

I was just going to say "use the profiler" :-) The things that have caught us out are - repeated construction of sequence items (as opposed to repeatedly randomising one item and cloning it) - silly constraints (e.g. writing a foreach constraint to set every element of a 2048 element array to its index. It's much faster to do it procedurally in post_randomise()) - Too much logging (of course... sorry if this is obvious). I now set regressions to UVM_LOW as a matter of course. - queues/mailboxes that grow and never shrink Generally we've used the profiler to track down problems. Even if you can't get sensible results from call trees etc, sometimes just capacity profiling is good enough to give you a clue. regards Alan P.S. It seems that even though the 80-20 "rule" is really a heuristic, it's generally true.

I haven't tried it, but I think it should work. As long as you use a Unix style path on Unix, and a Windows style path on Windows, regards Alan

Hi, there are a number of issues to think about there. Firstly, you can approximate the delay however you want. If you are doing LT modelling, then typically you would use a single value. So if your processing took 10 clocks with a 10 ns clock period, you could use a time of 100ns. The argument to the function call represents the time in the future at which the function should be considered to operate. In a simple system using b_transport, you *could* just wait for the time delay in the function, but that's not very efficient. Instead you would just increment the time value by 100 ns (using the example above) and return. However if you keep doing that, only one process will be able to run as no-one is calling wait. The purpose of the time quantum is to decide when a process should wait so that other processes should run. A big time quantum is less accurate but faster. b_transport and the quantum are the LT style of modelling. For AT modelling, you would again increment the time argument to model time passing, but you would typically wait more often. There are utilities in the TLM2 utils directory to assist with scheduling and executing updates in the future (payload event queues). Regarding what time values to pass to the functions - the time values should represent the processing time of what you're modelling. You could pass random time delays. The purpose of that would be to check that the software application running on your platform model behaves correctly independent of time delays (i.e. it has no ordering dependencies or non-determinism). That's the approach ST used to use in their original TLM approach (pre-TLM2 - well pre-TLM1!) regards Alan

I think this is a question for the simulator vendor. There's no standardisation of mixed language simulation in the SC or SV standards. kind regards Alan

I guess the main advantage of using SystemC is that ports/modules/channels give you a standard approach. Even if you don't care about time passing, you may well care about the order that things happen in, and then events and time are still useful. Also of course you get a ready to use threading library and scheduler. The disadvantage might be simulation speed compared to pure C++. And of course you have to learn SystemC. The main advantage of C++ is that you can do exactly what you want (you're free!) The main disadvantage of C++ is that you can do exactly what you want :-) (You're re-inventing the wheel) regards Alan

At time zero all threads and methods run in an undefined order (unless you use dont_initialize()). - the order of instantiation of modules is not relevant. regards Alan

If you're using TLM, I guess you've instanced a socket. That socket consists of an export and a port combined in one object. If it's a standard initiator socket, then you need normally to bind it to *this so that the backward interface is bound. You can give the socket an explicit name by supplying a constructor argument, which might help with debugging, regards Alan

Try typing "systemc eclipse" into a well-know search engine - it worked for me :-) Alan (Well it came up with instructions for setting up SystemC with Eclipse. I confess I didn't actually try those instructions though...)

I would expect the Accellera simulator to produce the same results each time it is run, assuming same OS, same SystemC code. I would be very surprised if you ran a C++ program twice and got different results each time, and the Accellera Proof of Concept simulator is just a C++ program. If you are running exactly the same executable twice and getting different results, you must be using some other source of randomness (such as time of day, or /dev/random) inside your program, regards Alan

Hi Rohit, I would guess it's something to do with include paths and the location of the source files. When you compile the code, there is a whole set of -I options and includes that the compiler uses to find the source code. If gdb doesn't know about all those includes, I guess it can't find the source files. When you install SystemC, all the required header files end up in the include sub-directory - but the source (.cpp) files get left behind in the place you originally untarred the code. So my guess is that you need to tell gdb to look at the folder where you untarred systemc which includes a src directory containing the cpp files. When you install on windows, you generally build the library in the same place, so the src directory is present. Perhaps just copying the src folder into the final install directory would help? regards Alan

It's hard to tell without knowing the value of NUM_TAP. But if NUM_TAP is 10, then if (i == 10) inside your for loop will never execute. Perhaps you should say if (i == NUM_TAP -1) ? Alan

It allows you to wait for a delta, which allows primitive channels to update. You should use SC_ZERO_TIME when you want to wait for a delta, or notify an event a delta in the future. If you have two wait(SC_ZERO_TIME) in two different threads, and both threads suspend at the same delta, there is no defined sequence (either thread may resume first). regards Alan

How is Packet declared? Alan

You can use next_trigger() in an SC_METHOD to modify the sensitivity of the following call to the SC_METHOD. The details of next_trigger() are in the LRM. It's important to realise that next_trigger() is non-blocking. The SC_METHOD will still run to the end and return, but the sensitivity of the immediately following invocation is modified by the last call to next_trigger() in the function, regards Alan

Tudor mentioned in his blog http://blog.verificationgentleman.com/2015/07/rambling-about-uvm-factory-overrides-per-instance.html that you can supply a parent component when you create an object. So one option would be actually to create the config object as part of the component hierarchy, regards Alan

In the first example - the +7 just makes sure you have enough bytes to hold all the bits. E.g. suppose I have 32 bits then I need 4 bytes - but if I have 33 bits, I need 5 bytes. By adding 7 it works correctly (32+7)/8 = 4 (33+7)/8 = 5 etc. Regarding the second rule, the easiest way to visualize it is to think of a real bus. A real bus just consists of a set of wires. You need to specify what order the wires are connected, but you don't know anything about the endianness of the data that is transferred across the bus. So that second rule is saying that if you model 32 wires using a 32 bit socket, wire 0 should be connected to wire 0, wire 1 to wire 1, and so on. The interpretation of endianness lies in the initiators and targets, not in the bus itself (if you see what I mean!) regards Alan

You can also just make your SC_THREAD sensitive to each element in the array, since a process sensitive to multiple events is sensitive to the or of those events, e.g. SC_THREAD(proc) for (int i=0; i< 100; i++) sensitive << my_array_of_100_events; regards Alan

The example you show says checking for g++... no which suggests you haven't got g++ installed. Can you answer my previous question please? What happens if you type g++ --version ? regards Alan

You only need one export e.g. export CXX=g++ Once you've done that, try typing g++ --version and see what happens. That will check if you actually have g++ installed, regards Alan

1666-2011 introduced SC_REPORT_INFO_VERB which has a verbosity argument. I don't know about SV/SC cross-language working, I guess that would be tool specific? Alan

Set the "clear" input? Alan

Essentially I have no idea! But with the magic of Google, I found this: http://www.ti.com/lit/ug/spruft2a/spruft2a.pdf Which says " The minimum (best-case) latency for a burst DMA transfer can be summarized as follows: •For transfers initiating from internal memory:the first access for word read and write takes 8 cycles, while consecutive accesses take 2 more cycles. Thus the DMA takes 2N + 6 system clock cycles to complete a burst transfer, where N corresponds to the burst size in words. • For transfers initiating from a peripheral source: the first access for word read and write takes 6 cycles, while consecutive accesses take 2 more cycles. Thus the DMA takes 2N + 4 system clock cycles to complete a burst transfer, where N corresponds to the burst size in words. " So perhaps between 2N and 3N clock cycles might be a reasonable guess? Obviously it's device specific, so if you know exactly what DMA controller you're modelling, have a look at the data sheet for that. Alan

I don't know agility compiler, but it looks like it doesn't support sc_bit - which isn't surprising at sc_bit has been deprecated for about 10 years! Use bool instead and see what happens, regards Alan

SC_CTOR(controller) { SC_METHOD(process,clk.pos()); That's not right, only SC_CTHREADs take a second argument. You should have SC_CTOR(controller) { SC_METHOD(process); sensitive << clk.pos(); regards Alan