-
Posts
146 -
Joined
-
Last visited
-
Days Won
32
ralph.goergen last won the day on February 5 2020
ralph.goergen had the most liked content!
Recent Profile Visitors
1,686 profile views
ralph.goergen's Achievements
Advanced Member (2/2)
60
Reputation
-
karthickg started following ralph.goergen
-
Abdelrahman started following ralph.goergen
-
Hi
I wanna install lib and include library by using cygwin 64 for systemC 2.3.3
-
Nitin_S started following ralph.goergen
-
haase reacted to a post in a topic: Compiler error: using is_reset() with sc_signal<bool> in sc_signal.h
-
Padma vathi reacted to a post in a topic: Events notifications and wait for events
-
dilawar reacted to a post in a topic: can't instantiate sub-modules using vector `port not bound` error
-
maehne started following ralph.goergen
-
Hi. I think that the explanation of setting values with password could be improved. void cci_param_if::set_cci_value(const cci_value &, const void* pwd, const cci_originator& orig); There are some statements saying that 'Writes to a locked parameter are rejected'. But with the pwd overload of set_cci_value, it is possible to write to a locked parameter without being rejected. The LRM should be more clear about this: Will the param be unlocked temporarily or not? If not, user needs to be aware that write callbacks can occur and latest originator can change even in locked state. Another aspect is reset: Should it be allowed to reset a locked param without password? Greetings Ralph
-
Hi. To my impression, the explanation of the callbacks could be more clear about multiple callbacks for one stage. I could not find an explicit statement that is should be possible to register more thean one callback to a single stage. It is mentioned that 'callbacks are invoked in order of registration' which implies having more than one. Mentioning it explicitly could avoid misunderstandings. Greetings Ralph
-
Hi. While reading through the LRM in the CCI review release, I observed some typos and minor issues. They might be known already, but I wanted to mention them here for completeness. 1. missing '_' in listings The underscore character is not printed in some of the names of types and methods in some listings, e.g. in Section 5.4.1 class cci_originator, 5.4.2 cci_param_if, ... 2. missing ';' in listing in Section 5.4.2.1 No semicolon at end of second line in the get_cci_value listing 3. NULL vs. nullptr Since C++11 is presumed as minimum supported standard, nullptr could be used instead of NULL Greetings Ralph
-
Hi. I guess it is the same as before. The implicit conversion from a signal to the type of the inner value is not supported correctly by the HLS library you are using. The following should help again: T v = v2.read(); Greetings Rlaph
-
Hi. Seems as if the compiler is confused by too many implicit casts. Could you try explicit read: XMT_datareg=data_bus.read(); Should save one implicit conversion and might help. Actual root cause could be in the _ap_sc stuff (synthesizer internals?). Greetings Ralph
-
maehne reacted to a post in a topic: Delta Cycle and concurrency
-
Hi. Maybe you should have a look at SystemC AMS. It offers the TDF (timed data flow) model of computation. It follows the data flow concept, i.e. you have a cluster of blocks; the solver defines an order of evaluation of each block; and in every time step, the blocks (or modules) are evaluated in that order. The output of one block is immediately visible at the input of the following block. Greetings Ralph
-
maehne reacted to a post in a topic: How to drive DUT clock and reset signal in UVM-SystemC?
-
Hi. This seems to be related to SystemC in general and not to UVM. sc_start() - without argument - starts the simulation until there is no activity anymore. No activity means no more events in the event queue. sc_clock generates new events all the time because the value changes independent from everything else in your design. As a result, the event queue will never be empty and the simulation never stops. (For completemess: the simulation ends as well when the maximum time is reached, i.e. the maximum time value that can be represented by sc_time). Normally, there are two ways to stop simulation, either by calling sc_start with a argument or by calling sc_stop. The first has been mentioned already by AmeyaVS. It runs the simulation for the given time and stops. The second can be done for instance from a testbench thread, e.g. from a sequencer when all sequences are done. Greetings Ralph
-
noay reacted to a post in a topic: Transaction Data Pointer
-
Transaction Data Pointer
ralph.goergen replied to noay's topic in SystemC TLM (Transaction-level Modeling)
Hi. Normally the initiator is considered as owner of the payload, i.e. he should take care of allocating and de-allocating it. The target should decide how to use the data. If the target wants to keep it/store it, the target should make a copy of the data. In that sense, the transaction is completed when b_transport returns because the initiator transfered it to the target and the target had a chance to handle it. A benefit of this is that you do not need dynamic allocation of the buffer buf. Greetings Ralph -
Hi. You cannot do an array or a std::vector of SystemC modules. Both would require a default constructor which is not available for sc_modules. Use sc_vector instead. See Section 8.5 in the SystemC LRM (IEEE 1666:2011). Regards Ralph
-
Problems using sca_tdf::sc_in<bool>
ralph.goergen replied to adias's topic in SystemC AMS (Analog/Mixed-Signal)
Hi. The line you posted shows the wrong order of libs. They should be in opposite order of their dependencies, i.e. first systemc-ams the systemc. The same should be done for the object files. Some compilers expect the correct order for them as well. And are you sure that you compiled both libs (systemc and systemc-ams) with the same compiler and settings? Are you sure that there are no remainders of the gcc4.9 experiments in the libs? Regards Ralph -
Converting sc_signal<T1> to sc_signal<T2>
ralph.goergen replied to Roman Popov's topic in SystemC Language
Hi Roman, Why reference? Because handing over variabels as const reference should be default whenever you don't have a good reason to do something else. When a signal contains a complex data type and not only an int, you do not want to copy it with every read. From your example, I am not sure if I got your scenario well. So, returning a const reference is normally not a problem. It is the same as normal sc_signal does. If your problem is that '*host_ptr' changes without temp_val being updated, you need to get grip on its write or update method and implement a write-through to temp_val. And this leads you to implementing a channel. Actually you did implement something like a primitive channel. So, implementing a full primitive channel that allows to be bound to different types could help. But this requires some thoughts and effort. Or you do it the easy, classical way with an hierarchical conversion channel. I would not expect the performance impact of the additional method to be very critical. In some cases, the additional delta cycle can be more problematic, mainly when this affects the clock edge. In both cases, you can benefit from knowing the direction of data transfer and conversion and reduce effort in comparison to using normal signals. Greetings Ralph -
TLM 1.0 => TLM 2.0
ralph.goergen replied to sarav's topic in SystemC TLM (Transaction-level Modeling)
Hi. AFAIK, there is nothing like that. In TLM1 communication is based on fifos. In TLM2 it is sockets and transport calls. This is a big difference. TLM2 is conceptually different and not just a slight improvement over TLM1. What you need is a channel that does the conversion from fifo content to payload and transport calls. This is not straightforward and not possible in a generic way. Greetings