Jump to content

David Black

  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by David Black

  1. We shall have to wait and see w.r.t. co-routines, but they do look promising.
  2. If you want multiple drivers, use sc_signal_resolved or sc_signal_rv<N>. The reason for SC_ONE_WRITER is to catch errors since the normal use case for sc_signal is single drivers. The SC_MANY_WRITERS was intended to allow one process to initialize and then hand-off to another process. Your use case likely the resolved signal situation. Verilog uses wires for the resolved case. VHDL has you to be more explicit.
  3. I see this question a lot. Perhaps an enhancement idea for a future SystemC. register_port could be augmented by adding a bit of data to channels to record the connecting parent. This would add a small structure (?vector<sc_object*>?), and add a tiny bit prior to start of simulation. Providing a "netlist" helps to confirm everything is connected correctly. Of course it won't for all the connectivity (e.g. a global clock object), but it would go a long way.
  4. Try get_parent_object() -- IEEE 1666-2011 page 128
  5. You should have a top level. If you don’t, create one and instantiate everything there. Set the global quantum in your top level module st end_of_elaboration and reset local quantum’s at start_of_simulation. Set a default and allow for override. You can obtain the override value to use at run time from any of: - command-line argument using sc_argv() - read a file or database if it exists - Enviroment variable set prior to invocation - user input prompt
  6. It is definitely possible to model using c++ threads; however, I think for most things it will actually be more difficult to use than SystemC because of the preemptive nature and requirements to use mutexes and semaphores. By contrast, SystemC provides a simplified cooperative approach multitasking approach. The techniques can also be mixed when appropriate.
  7. Caution: SystemC Kernel is not thread-safe without taking special precautions. If you call into SystemC from outside the SystemC OS-thread, you may need to create a primitive channel utilizing async_request_update(). If on the other hand you are simply stalling SystemC from within, which is what I think is being stated, then you should be fine with simple std::mutex (not sc_core::sc_mutex which is only for use inside SystemC between SystemC internal "processes").
  8. The error looks like a 64-bit library issue with stdc++.
  9. If you are trying to inject events from received TCP/IP running in parallel OS threads or external OS processes, then you will need to create a primitive channel utilizing sc_core::async_request_update() in order to safely (see note 1) inject events into SystemC. Your only other option is to poll, which is rather inefficient. Also be mindful that the SystemC side performance does not guarantee you will only get one event per delta cycle; therefor, you need to use a queue to receive data. You will also likely need to use an OS mutex (C++11 std::mutex should work fine for this application). Note 1: SystemC is not inherently thread-safe and random injection from outside can corrupt the simulation.
  10. Sorry, but tracing TLM is not directly supported. Recording transactions is supported.
  11. Sorry, but this is simply not possible in the convenient manner of Verilog. Reason: SystemC is not about RTL. If you need a few bits, then read all of them and mask off the ones you want.
  12. One way to disable the clock is to completely replace it with a model that does nothing. I presented a concept called no_clock at NASCUG a few years back demonstrating an approach. You can find the code on github: https://github.com/dcblack/no_clock with a link to the presentation. You could even replace the declaration of sc_clock directly with a conditional macro test: #ifdef USE_NO_CLOCK #include "no_clock.h" no_clock myclock{ "myclock", 10.0, SC_NS }; #else sc_core::sc_clock myclock{ "myclock", 10.0, SC_NS }; #endif
  13. I would say it is definitely interesting.
  14. Perhaps you would like to share your code for measurements via GitHub? Measuring performance can be tricky to say the least. How you compile (compiler, version, SystemC version) and what you measure can really change results. Probably helps to specify your computer's specifications (Processor, RAM, cache, OS version) too. Processor (vendor, version) L1 cache size L2 cache size L3 cache size RAM OS (name, version) Compiler (name, version) Compiler switches (--std, -O) SystemC version SystemC installation switches How time is measured and from what point (e.g. start_of_simulation to end_of_simulation) Memory consumption information if possible This will help to make meaningful statements about the measurements and allow others to reproduce/verify your results. It is also important to understand how these results should be interpreted (taken advantage of) and compared. As with respect to TLM, it will get a lot more challenging. For example, what style of coding: Loosely Timed, Approximately Timed. Are sc_clock's involved?
  15. Your code is operating correctly; however, you are displaying the results at the wrong time. This is because the write() method of sc_signal is not the same as a simple store operation. In normal programming, you expect that if you do: variable = 5; Then immediately after storing the value into your variable, the variable will contain the value. You might then assume that the write() of sc_signal is the same. It is not. It takes a small amount of time for the value to be stored. The amount of time is tiny and is refered to as a "delta delay" time. You can cause your program to wait a delta cycle before displaying the result, but it is slightly more complicated because you are using an SC_METHOD style process instead of the SC_THREAD style process. If you are using C++11 you can replace your cout line with this to see correct answer: sc_spawn( [&]{ wait( SC_ZERO_TIME ); ///< wait one delta-cycle delay cout << "@" << sc_time_stamp() <<"(" << sc_delta_count() << ")" << " || in1:" << in1.read() << " + in2:" << in2.read() << "= val:" << out.read() << endl; });
  16. This is a C++ question. SystemC is simply a library under C++. Floating point (double & float) are part of C++. There are some implementation bits with IEEE floating point in the current proof of concept source; however, this is not documented nor supported in the official standard presently. Whether or not the is_inf works as defined you could ascertain by examining the source code if you like, but really should not count on it. If you have questions about fixed point types, those are addressed in the standard. Please redirect your question to a C++ forum on the topic of floating point. Here is a link <http://www.cplusplus.com/reference/limits/numeric_limits/> of related interest.
  17. Not directly, but you could create two knobs and use them in a constraint. +uvm_set_config.int=*,minsize,100 +uvm_set_config_int,*,max_size,500 then internally class MySeq extends uvm_sequence #(MyTrans); `uvm_object_utils(MySeq) rand int var_size; rand int min_size, max_size; constraint Size { min_size <= var_size; var_size <= max_size; } .... endclass: MySeq
  18. Yes, you can supply clocks to TLM, but this is a very bad idea in general. Clocks will slow down your simulations There are many ways to insert clocks: ports, local instances, global references. The best b_transport implementations find ways to avoid calling wait. More precisely, we attempt to reduce context switching to a minimum and its associated overhead.
  19. TLM does have a response status, but that is intended to catch modeling failures rather than modeled failures. So if you consider your case a modeling error, which seems unreasonable to me on the surface, then you should either set the error response to something like a generic error or issue SC_REPORT_ERROR. In any event, do not set both. If this is a modeled error, then you are left to your own devices. See section 14.17 of IEEE-1666-2011 for details.
  20. Let's move this to EDA playground... https://www.edaplayground.com/x/55Sj Doesn't compile. You can COPY into your own playground and fix the compile issues. Then I can look at it if you provide me with the URI.
  21. The term 'interface' (and for that matter 'virtual') is used in somewhat different ways in SystemVerilog than in SystemC. TLM is simply and library built on SystemC that has some well understood standard SystemC interfaces. Fundamentally, the concept of direction as used in hardware (and hence Verilog) does not translate to SystemC particularly well. In fact, it is somewhat annoying that we have the sc_in<T>, sc_out<T> ports in SystemC because it confuses most folks. It is best in SystemC to think like a C++ programmer. The way that SystemC views "input" and "output" is by observing data flow semantics of function calls. If I have a function with the signature put(int value), then I expect I am moving data from the caller to the callee. SystemC views the concept of interface in the same manner as other object oriented (OO) programming languages do. An OO interface class is simply an abstract class that exclusively contains pure virtual methods. SystemVerilog as of 2012 also has this concept in the manner of 'interace class', but this was added later. Thus SystemVerilog uses the keyword 'interface' in three completely different manners: interface blocks provide a wrapper around signals as a method of bundling signals hence the syntax: interface Bus( input clock ); logic[7:0] address, data; logic rw; modport cpu_mp( output address, rw, inout data ); modport mem_mp( input address, rw, inout data ); clocking cb @(posedge clock); input address, data, rw; endclocking modport verif_if; endinterface Note: semantically an interface is somewhat of a super module because it may contain initial, always, assign and hierarchy. SystemVerilog's virtual interface is simply references to instances of interface blocks to be used inside classes. SystemVerilog interface classes are more like C++ interface class Print_if; pure virtual function void print( string message ); endclass class A implements Print_if; function void print( string message ); $info("%s", message ); endfunction endclass By contrast C++ would use: class Print_if { virtual void print( std::string message ) = 0; }; class A : Print_if { void print( std::string message ) { std::cout << message << std::endl; } };
  22. Notify (either case) is non-blocking, so your call to notify followed by initialize will happen. Then after you return, the notified element(s) may execute. Notify() implies execution will be in the same delta-cycle; whereas, notify(SC_ZERO_TIME) postpones to the next one and allows other processes in the current delta-cycle to complete. Take a look at <https://github.com/dcblack/SystemC-Engine/blob/master/Engine_v2.4.pdf>.
  23. sc_signal is not really a good channel for bi-directional signaling since by design it is intended for single driver (writer) multiple reader use. You should use sc_signal_rv<T> or sc_signal_resolved for multiple drivers so that contention can be properly modeled.
  • Create New...