apfitch

In SystemC, the word "channel" simply means "something that implements an interface" and so can be bound to ports. In that sense, a "channel" doesn't have to be a means of communication. For instance you could have a RAM model that implemented an interface with read and write functions. The extra things you get in SystemC, beyond C++, are the ability to make your system modular with modules and ports; and threads (processes), events and time. Ports are templated with interfaces (classes derived from sc_interface) which specify that the thing bound to the port must provide the required functions. If you look at TLM2, for instance, ports are bound to exports, and the modules with the exports implement the functions that the modules with the ports require. In the original SystemC usage, both an initiator and a target are "a channel" in the sense that they implement an interface. What I'm trying to say is that you don't have to really think about channels at all. You can simply think in terms of interfaces, classes that implement those interfaces, and ports and exports that promote modularity by (in a sense) acting as special pointers with strong type checking. Of course in the SystemC library there are some built-in primitive channels, which have the special feature that they follow evaluate-update semantics. But that's just a special case of the more general concept of implementing an interface and accessing implemented methods remotely via ports/exports. So if you don't need the features that ports/exports/modules give you, you don't have to use them. Which is a long way of saying "yes" to your question :-) The main disadvantage of using immediate notify is non-deterministic behaviour. regards Alan

I just have a (possibly unhelpful) comment - you don't have to use primitive channels with evaluate/update semantics in SystemC. You can use your own channel with immediate notify, or you can write a "systemc program" which is really C++ and has no use of time or deltas. Whether that helps with the original problem I don't know :-) regards Alan

"It's just C++" so you can derive from existing classes. If you look in the code for sc_buffer, it is a derived class of sc_signal, which modifies the semantics of write. If you want to create your own primitive channel, then you need to derive from sc_prim_channel (not sc_channel as you've shown in your code). Otherwise you won't have access to request_update(). There's a very simple primitive channel example here: http://www.doulos.com/knowhow/systemc/tutorial/primitive_channels/ regards Alan

I think I don't quite understand the issue. When you say "(My task is to convert float number to Double precision floating point format, and with it do some arithmetical operations)." you can do that easily in C float f; double d; d = static_case<double>(f); // or d = f; If you mean that you want to be able to manipulate the individual bits of a floating point number, then you could possibly use the sc_fixed_fast data type, which is based on double - see the IEEE 1666-2011 language reference manual 7.10.3.2 regards Alan

Hi Tudor, VHDL 2008 does allow hierarchical signals. However of course for use cross-language, you are at the mercy of your simulator. regards Alan P.S. bind is better of course as you say - and cross-language bind works, again subject to your simulator.

There's no way to find out which event triggered. You could just use sc_signal, because then you can use the event() method of the sc_signal class.

I've used it just because for a simple virtual sequence there's no need to create a virtual sequencer whose only purpose is to hold references to the sub-sequencers. You can put those references in the virtual sequence instead. So I suppose it just saves a bit of typing! regards Alan P.S. I wish UVM had used different words that "sequence" and "sequencer"... it's a recipe for confusion.

Type mismatch means that the type of the port and the type of the thing you're binding it to don't match. For instance if you tried to bind sc_in<int> to sc_signal<bool>. port 4 is the 5th port in order of declaration on that module. regards Alan

To find out if line endings are an issue, you can use the "file" command. Pick one of the untarred file, e.g. Makefile, and do file Makefile It will tell you if you have DOS line endings. Another possibility is some weird Unicode problem - try doing export LANG=C before you do the install. regards Alan

Yes value_changed_event() and default_event() return the same for an sc_signal channel. For sc_signal they only notify when there is a change in value. If you want to detect any assignment, you could use the sc_buffer channel instead, regards Alan

I don't know about SystemC synthesis tools, but generally for VHDL/Verilog synthesis tools you'd typically use the place and route tools together with component instantiation to initialize a memory. But the answer is tool specific, so you'll have to read the manual of the tool you're using, or contact the vendor, regards Alan

It works OK for me. What do you have SYSTEMC_HOME and TARGET_ARCH set to? Do they match your system and SystemC install? regards Alan

I agree with David. Having said that, you can simply attempt to retrieve the type of extension you expect. If it's there, you'll get a non-null pointer, if it's not there you'll get a null pointer. Regarding your second question, an extension can be ignorable or mandatory. If it's ignorable, then the target doesn't need to know if the initiator set it. If it's mandatory, then it must exist at the target. regards Alan

You need to install the register assistant itself, it's a separate install from QuestaSim. If it is already installed, then I guess it's not in your path. regards Alan

Your soft constraint only covers the case when my_pkt is ether_pkt, so perhaps my_pkt is *not* ether_pkt, Suppose there are four packet types, and data_len is 16 bits. Then you're randomizing 18 bits, that's 262144 values. But your constraint is only satisfied for 512 of those values, so there's only a 1 in (262144/512) = 1 in 512 chance of generating the value you seem to want. regards Alan

A code example would help - but can't you just use $display? If you're using Questa and you've got the correct license features, the Assertion Thread Viewer is nice, Alan

Again the LRM says "NOTE—A trace file can be opened at any time, but no mechanism is available to switch off tracing before the end of simulation." I suppose you could open and close multiple different trace files with the same signals, and then combine after simulation using a script. regards Alan

From the LRM section 8.1 "A trace file shall not be closed before the final delta cycle of simulation." So no, you may not close it early, regards Alan

Hi C4brian, no I don't recommend always using wait(SC_ZERO_TIME). I recommend understanding how the scheduler works, which I guess is what your aim is too! The scheduler is well described in the LRM. A shortened description (ignoring lots of details) is 1. if there are runnable processes, execute them. ( a process that calls immediate notify here can make another process runnable at this point) repeat 1 until no more runnable processes 2. advance to evaluation phase update all primitive channels and events. A call to notify(SC_ZERO_TIME) here will cause you to go back to step 1 (execute another delta) keep going round until there's nothing to do. 3. Advance time to the earliest future event go back to step 1 If there are no future events, end simulation. So the answer to your last question is yes, calling notify() with no arguments during step 1, the evaluation phase, causes any process that was waiting for that event to become immediately runnable. But as I said, the LRM is your friend, regards Alan

Use two initiators Alan

You'll need to keep track of some identifier for each transaction. Typically people use the address of the payload object as a unique identifier. regards Alan

notify() makes a process runnable within the evaluation phase. So it can cause non-deterministic process execution. You might use notify() when modelling something like multi-threaded software, because software does not have delta cycles. notify(SC_ZERO_TIME) triggers on the next delta, which avoids some non-deterministic behaviour, and is closer to how languages like VHDL and Verilog work. Note that all runnable processes are still picked in an unknown order when choosing which process to run next in the evaluation phase. regards Alan

Making a soft link works,but is a bit hacky. If you want a library to appear in the library linker path for all users, you should add it using ldconfig. Add your library information into /etc/ld.conf, then run ldconfig to add it to the system path. Also in your solution you've linked libsystemc2.3.1.so to libsystemc2.3.0 which suggests something else is wrong with your setup (i.e. mixing up 2.3.0 and 2.3.1). However your original approach (adding the library path to Eclipse, and adding systemc to the linker list) should have worked. It's a mystery... regards Alan

It could be that the text is buffered. Try using << endl; instead of \n. Also try doing quit -sim at the Modelsim command prompt after the simulator has finished, to flush the files to disk. regards Alan

The release notes don't explicitly mention Visual C++ 2010 with 64 bit. But I expect it should work. I'd guess some option is wrong on your command line, perhaps in how you specify the linker options? Can you post the command line you use? regards Alan