Jump to content

All Activity

This stream auto-updates     

  1. Today
  2. Hi all, I got some issue when test memory check (valgrind 3.11.0). ==467== Use of uninitialised value of size 8 ==467== at 0x300B000: ??? (in /lib64/libsystemc-2.3.1.so) ==467== by 0x3000B02: sc_core::wait(…) (in /lib64/libsystemc-2.3.1.so) ==467== by 0x3000C04: sc_core::sc_module::wait(…) (sc_module.h) ==467== by 0x40B0B9A: SAZZ::EndThread() (SAZZ.cpp:813) ==467== by 0x40EB0B1: sc_core::sc_thread_cor_fn (in /lib64/libsystemc-2.3.1.so) ==467== by 0x4139044: ??? (in /lib64/libsystemc-2.3.1.so) ==467== Uninitialized value was created by a stack allocation ==467== at 0x300B000: ??? (in /lib64/libsystemc-2.3.1.so) ==467== Use of uninitialised value of size 8 ==467== at 0x700B000: sc_core::sc_sc_event_expr<sc_core::sc_event_or_list>::~sc_event_expr() (in /mywork/execute.x) ==467== by 0x40BC9A: SAZZ::EndThread() (SAZZ.cpp:813) ==467== by 0x413D0D8: sc_core::sc_thread_cor_fn(void*) (in /lib64/libsystemc-2.3.1.so) ==467== by 0x4130300: ??? (in /lib64/libsystemc-2.3.1.so) ==467== by 0x4136094: ??? (in /lib64/libsystemc-2.3.1.so) ==467== Uninitialized value was created by a stack allocation ==467== at 0x300B000: ??? (in /lib64/libsystemc-2.3.1.so) ==467== Invalid read size 8 ==467== at 0x600B000: sc_cor_qt_yieldhelp (in /lib64/libsystemc-2.3.1.so) ==467== at 0x600BC00: ??? (in /lib64/libsystemc-2.3.1.so) ==467== by 0x6000B02: sc_core::wait(…) (in /lib64/libsystemc-2.3.1.so) ==467== by 0x6000C04: sc_core::sc_module::wait(…) (sc_module.h) ==467== by 0x60BC9A: SAZZ::EndThread() (SAZZ.cpp:813) ==467== by 0x613D0D8: sc_core::sc_thread_cor_fn(void*) (in /lib64/libsystemc-2.3.1.so) ==467== by 0x6130300: ??? (in /lib64/libsystemc-2.3.1.so) ==467== by 0x6136094: ??? (in /lib64/libsystemc-2.3.1.so) ==467== Address 0xE14be48 is 598 bytes inside a block of size 624 alloc'd ==467== at 0x400BD00: operator new[](unsigned long) (vg_replace_malloc.c:422) ==467== by 0x600BA00: sc_core::sc_core_pkg_qt::create(unsigned long, void (*), void*)(in /lib64/libsystemc-2.3.1.so) void SAZZ::EndThread(){ while(1){ ... wait( period, time_resolution, next_event[index] | change_event[index]);//line 813 } } Have you any idea? Thanks for your support
  3. Yesterday
  4. Last week
  5. Hi all , The m_check_relationship function checks the following :: That the connection is between ports that are hierarchically adjacent (up or down one level max, or are siblings), and check for legal direction, requirer.connect(provider) . In case of a violation we return 0 ( with a warning ) else we return 1 . But we always use a void cast while calling m_check_relationship function . Even if I get a warning I see that the transaction does transfer . Eg :: For put_port( txn ) called from component will invoke the put_imp connected to the port ( with a warning ) . I tried it with uvm 1.1d as well as 1.2 , but I still see a warning with the transaction transfer . Is the function meant for future versions to give an error ?
  6. This is like an OO or C++ question. If you draw out the class diagram including the classes you are interested in and their relationships, that should answer your question. I would suggest using doxygen on your code base to see what it observes.
  7. Dear experts, I'v create a user-defined TLM-2.0 socket which inherit from tlm_target_socket/tlm_initiator_socket. I want to know if there is a way to bind my user-defined TLM-2.0 socket with TLM-2.0 standard socket, like multi_passthrough_target_socket/multi_passthrough_initiator socket?
  8. The SystemC AMS standard defines in section 9.1.2.6 (sca_util::sca_trace) that it can trace objects of type sca_traceable_object. Since all ELN primitives are derived of this type, you can simply trace the ELN component itself, see example below SC_MODULE(eln_circuit) { // node declaration sca_eln::sca_node n1; // ELN node sca_eln::sca_node_ref gnd; // ELN ground // component declaration sca_eln::sca_vsource vin; sca_eln::sca_r r1; // constructor including ELN netlist eln_circuit( sc_core::sc_module_name nm ) : vin("vin", 0.0, 1.23), r1("r1", 1e3) { // Only ELN primitives requires explicit timestep assignment to one element vin.set_timestep(1.0, sc_core::SC_MS); // netlist vin.p(n1); vin.n(gnd); r1.p(n1); r1.n(gnd); } }; int sc_main(int argc, char* argv[]) { eln_circuit cir("eln_circuit"); sca_util::sca_trace_file* tf = sca_util::sca_create_tabular_trace_file("trace.dat"); sca_util::sca_trace(tf, cir.n1, "v_n1"); sca_util::sca_trace(tf, cir.vin, "i_through_vin"); sca_util::sca_trace(tf, cir.r1, "i_through_r1"); sc_core::sc_start(1.0, sc_core::SC_MS); sca_util::sca_close_tabular_trace_file(tf); return 0; }
  9. Hi, According to the SystemC AMS User Guide 2020 (p.g. 92), Can I know how exactly this is done, with examples? Many thanks in advance!
  10. The only normative reference for SystemC is defined by the IEEE Std. 1666-2011, see http://ieeexplore.ieee.org/document/6134619/. The is_reset() was never part any version of the standard, so one could never rely on its presence. You would to check, why the ReChannel library tries to call this function and then find another way to implement this functionality. /Philipp
  11. Create an sc_vector<sc_signal<bool>, 4>, but then you have to assign and deal with four separate signals.
  12. I have referred (https://www.xilinx.com/support/documentation/sw_manuals/xilinx2019_2/ug902-vivado-high-level-synthesis.pdf ) the design guide page no:379 and it says that it can be synthesized... Is there any other tool like vivado hls to synthesize my code? or is there any documents to know things more about the usage guides for sc_fifo to make it synthesizable?
  13. Synthesizability rules are ultimately up to the HLS synthesis vendor, and they are definitely different between vendors. The synthesizable subset standard is simply a guideline of commonly agreed upon constructs that either clearly able to be synthesized (e.g. sc_signal) or not (e.g. new and delete). Every synthesis tool will have some variance. Please refer to your sythesis vendor's reference manual to learn their rules. If that fails, contact their support. Simulation does not guarantee synthesizability.
  14. Hello, I am trying to connect a custom fifo between 2 modules, that works fine in simulation and verification in my linux and also vivado hls but when i try to synthesize it using vivado hls , it give an error as, ERROR: [SYNCHK 200-91] Port 'imp.cons.in.m_if.Val.data' (../final/p.h:200) of function 'center_detector' cannot be set to a FIFO ERROR: [SYNCHK 200-91] as it has both write (../final/x.h:19:17) and read (../final/y.cpp:9:4) operations. Is that synthesizable or not ? sc_port<sc_fifo_out_if<line> >out; // producer module port sc_port<sc_fifo_in_if<line> > in; // consumer module port my read and write operations as out->write(f); in->read(f); I saw this similar topic in https://forums.xilinx.com/t5/High-Level-Synthesis-HLS/SystemC-sc-fifo-and-hierarchy/td-p/741511 , but i couldn't get the answer . please help me to solve this.
  15. Hello guys, I'm new to SystemC and I'm learning now but I'm stuck on a very simple issue that I cannot resolve: I have an output that is a 4-bit bus sc_out<sc_uint<4> > counter_out; // 4 bit vector output of the counter that I trace with sc_trace(wf, counter_out, "count"); This will dump the output on a single coordinate system, showing me the numbers on the bus in hex format. However I want to display all four wires on separate coordinate systems, one for each bit. What is the best way to do this? Regards, L. B.
  16. Earlier
  17. I have seen several SV-DPI and pthread related posts in this forum and in stackoverflow. However, it seems no post for SV-DPI and co-routine. I guess the reason is there is NO standard library or C language native support for co-routine ( except C++20). Now I'm trying several C based co-routine libraries mentioned in https://en.wikipedia.org/wiki/Coroutine to support python/javascript type of generator in Systemverilog/UVM testbench. Here is how. 1. One SV thread is working as main thread. A SV function will be working as a co-routine and exported to DPI. 2. The SV thread need to create a co-routine by calling co_create through the DPI. the first argument of the co_create would be a wrapper function to the SV exported function. And co_create will use a dynamically allocated array as standalone stack for the co-routine being created. 3. Then SV thread need to resume the co-routine by calling co_resume through the DPI. Here, stack pointer of the CPU will switch to the new stack of the co-routine and entry point is the wrapper function. And finally, the execution will go to the SV exported function and go back to SV side. 4. In the middle of the SV exported function, co_yield will be called. stack pointer will be switched back to the main thread and program counter will be returned to right after the co_resume. Finally, execution will return back to the SV side of the main thread. 5. Above step 3-4 can be repeated many times until the exported function is finished and co-routine can be destroyed. I don't know how much stack space is needed to run SV functions on it. I just allocated 32KB for each co-routine. That's all. This is completely single threaded with user space cooperative multiple tasking. Again, this is to mimic the python/javascript type of generator for test framework development. Is there any risk ?
  18. Hi Chethan, the issue you see comes probably stems from the driver and sequencer being created during the build phase when you start run_test(...). Your hierarchical logfile setting happens before that, so that the driver and sequencer could not know of that setting. To enable the wanted behaviour, you need to move the log setting to a later place in runtime or make the driver and sequencer full members of the environment.
  19. Hi Ralph, thanks for your reply. I also recognized that this function is private, so i did the workaround making this function public. This fast solution is for the moment ok, but not as long term option. I know that is not a good solution, but it is a qick dirty fix. I have an old SystemC Library(ReChannelv2 from 2007) where this call is used and i want to use this library(the library is not compiling yet). For now i have not the resources to refactor the old library to the newer C++(11 or 14) and SystemC(2.3.3) standard. Also it is an external library, so it is hard to get in and understand how the implementation is done in detail. In theory, i only want to use it 😉 This library is i would say something which wrapped extra stuff around the systemc classes to model reconfiguration during runtime. If i check the SystemC version 2.2, there was this function public, so it was allowed to use this function. Why is this dangerous now? What changed between these two version? Best regards, Julian
  20. Hi. The is_reset method is private. So, you cannot call it on an object. But why are you using is_reset() method? What do you want to achieve? This is not part of the standard API, i.e. it might be dangerous to use. Greetings Ralph
  21. hello, i'm facing the same error error: invalid use of incomplete type ‘class sc_core::sc_spawn_options’_files when running the make file in linux i tried to add the command that Philipp wrote above in the terminal... but still having the same error. Can anyone help please?
  22. Hello, i have the following piece of code not compiling: #include <systemc.h> int sc_main(int argc, char* argv[]){ sc_signal<bool> my_signal_bool; sc_reset* my_reset; my_reset = my_signal_bool.is_reset(); return 0; } I get this error: In file included from /usr/local/systemc-2.3.3/include/sysc/communication/sc_buffer.h:34:0, from /usr/local/systemc-2.3.3/include/systemc:79, from /usr/local/systemc-2.3.3/include/systemc.h:219, from ../src/playground.cpp:12: /usr/local/systemc-2.3.3/include/sysc/communication/sc_signal.h: In function ‘int sc_main(int, char**)’: /usr/local/systemc-2.3.3/include/sysc/communication/sc_signal.h:472:23: error: ‘sc_core::sc_reset* sc_core::sc_signal<bool, POL>::is_reset() const [with sc_core::sc_writer_policy POL = (sc_core::sc_writer_policy)0u]’ is private virtual sc_reset* is_reset() const; ^ ../src/playground.cpp:95:37: error: within this context my_reset = my_signal_bool.is_reset(); ^ make: *** [src/playground.o] Error 1 src/subdir.mk:18: recipe for target 'src/playground.o' failed "make all" terminated with exit code 2. Build might be incomplete. I have installed SystemC 2.3.3 and using Eclipse CDT under Ubunut 16.04. How i can resolve this error? Best regards, Julian
  23. Hi Justin, As promised, I'd like to release the modified uvm_factory.svh file in attachment for your reference. Please search keyword '//CHANGE' for all the changes made. I tested it with some simple test cases for type and instance overrides and it works as the old implementation. May need to be verified more. New data structure of uvm_object_wrapper is as below: uvm_object_wrapper ovrd_type : ultimate overriding type. Initialized to this type. Used to create the object of this type (after no instance override matches). uvm_factory_queue_class inst_override : queue of instance overrides (each override consists of a pair of ovrd_type and full_inst_path). The ovrd_type at which full_inst_path matches with get_full_name() of the object to be created will be used to create that object. uvm_object_wrapper direct_ovrd_type : direct override type, i.e, the overriding type that was set by set_type_override_by_type() or set_type_override_by_name(). Used with affected_types (below) for traversing across type override hierachy (e.g, C overrides B, B overrides A). bit affected_types [uvm_object_wrapper] : types that was overriden by this type. Used with direct_ovrd_type (above) for traversing across type override hierachy (e.g, C overrides B, B overrides A). As explained in previous comment, set_type_override_by_type/name() and set_inst_override_by_type/name() will set the ovrd_type of the requested_type argument. When create_object_by_type/name() is called, the ovrd_type in the object wrapper will be used to create the object handily and least lookup operations needed, as opposed to the old implementation. Since set_type_override_by_name() and set_inst_override_by_name() allow arbitrary (including wildcards) type names (a.k.a, lookup names) which may not have been registered with the factory, a new class is introduced and the 2 new data members below are added into the uvm_default_factory for this purpose. class uvm_factory_lookup_type extends uvm_object_wrapper; function new (); inst_override = new; endfunction virtual function string get_type_name(); return ""; endfunction endclass class uvm_default_factory extends uvm_factory; ... protected uvm_factory_lookup_type m_lookup_type_names[string]; protected uvm_factory_lookup_type m_lookup_type_wildcards[string]; ... endclass Because uvm_factory_lookup_type inherits all the aforementioned data members of uvm_object_wrapper, type and instance overrides which set to a lookup type name is treated just like a normal override setting to a registered type. This makes the implementation cleaner as opposed to the old one where lookup type names and registered type names are mixed together into m_type_names associative array. Finally, there're some notes with the attached uvm_factory.svh file. debug_create_by_type/name() methods are not implemented yet. In old factory implementation, the "override loop" error is checked at run_phase, when the create_object. In new implementation, it is checked when set_type_override_by_type/name() is called, so it may happen in build_phase() and the simulation would be stopped due to "build error" reason. Best Regards, Thien uvm_factory.svh
  24. When I built SystemC as a DLL, it resolved all the issues. Thanks!
  25. As you are already building your SystemC model using DLLs, I would suggest that you also build SystemC as a DLL and link to it. This most probably should fix your problem as suggested by @Roman Popov.
  26. Thanks @Timur Kelin for reporting this issue! I have forwarded it to the SystemC LWG to investigate how to fix it best in the proof-of-concept implementation of SystemC.
  27. Without any self-contained code example exposing this error, it will be difficult for anyone on this forum to help you. Do you observe the same error, when running your example in the Accellera proof-of-concept implementation of SystemC instead of the SystemC version coming with your vendor tool?
  28. Hi, On trying to run systemc simulation for a systemc example, I am getting the following error: sim_sc: /usr/local/bin/Mentor_Graphics/Catapult_Synthesis_10.3d-815731/Mgc_home//shared/include/sysc/kernel/sc_process.h:617: void sc_core::sc_process_b::reference_increment(): Assertion `m_references_n != 0' failed. Aborted (core dumped) Could somebody please help me to resolve the issue? Thanks & Regards
  1. Load more activity
×
×
  • Create New...