Jump to content

All Activity

This stream auto-updates

  1. Today
  2. Thank you for the helpful response. I believe I need to think this over a little more. I am still not entirely clear on how the arbiter should handle the case where one of the input threads may not check in during a given arbitration cycle, as the arbiter cannot make its arbitration decision until it is sure that all of the input threads that will check in have done so.
  3. Due to the design of sc_event there will only be one event for a given delta cycle.
  4. Create: sc_event arbiter_event; All arriving processes push to their respective fifo and immediately post: queue.push(data); arbiter_event.notify(SC_ZERO_TIME); Arbiter waits for the event and processes all fifo’s upon receipt.
  5. Yesterday
  6. I am facing a dilemma with the scheduling of SystemC processes. I have a feeling it is because I have erred in my design approach and wanted to see if someone could offer some guidance. Say that you have a SystemC thread that arbitrates transactions that arrive through multiple FIFOs. The threads that enqueue the transactions into the FIFOs are untimed. When a request arrives at an input FIFO of the arbiter, the arbiter gets notified. At this point, the arbiter does not know which of the FIFOs will eventually get a transaction in it at this time stamp. We'd like to wait until all of the other threads have executed before the arbiter proceeds to make its arbitration decision. As I understand, one way to do this would be just to make a bunch of wait(SC_ZERO_TIME) calls. But this seems a bit like a hack, for various reasons (e.g., what if later, there are more untimed processes added upstream from the input threads? Then the arbiter has to add more wait(SC_ZERO_TIME) calls to account for these). I am wondering if this would just be considered a bad design. Since real hardware takes time for activity to occur, perhaps this is not the intended use of the delta scheduling in SystemC. Or, maybe I am just approaching this in the wrong way? Any help is appreciated.
  7. Last week
  8. Thanks @Rob Donnelly, I've opened a bug over at 0007464: Silent buffer overflow in uvm_packer - Accellera Mantis (mantishub.io) to track the issue.
  9. I need to print what phase I am in UVM. I am unable to do so. Pls help
  10. Hi Kushi, Yes, you can express it like this: <ipxact:parameters> <ipxact:parameter parameterId="myparamID" ipxact:resolve="user"> <ipxact:name>myparam</ipxact:name> <ipxact:value>""</ipxact:value> </ipxact:parameter> </ipxact:parameters> The value "" denotes an empty string. The value of the value element is an expression. An empty expression is not allowed. If you want to put a constant string then you have to quote it. You can override it in a design instance by referencing the parameterId attribute value. Best regards, Erwin
  11. Packing more than 4KB with uvm_packer results in a silent buffer overflow. This then causes silent data corruption on unpack. This issue is present in both UVM 1.2 and UVM 1800.2 2020. The attached test case was run on Questa 2020.4_2. UVM 1800.2-2020 1.1 Commands: gcc -m64 -fPIC -DQUESTA -g -W -shared -x c -I${QUESTA_ROOT}/include ${UVM_HOME}/src/dpi/uvm_dpi.cc -o uvm_dpi.so qrun -sv +incdir+${UVM_HOME}/src +define+UVM_1800_2_2020 -sv_lib uvm_dpi ${UVM_HOME}/src/uvm_pkg.sv uvm_packer_buffer_overflow.sv Errors: # UVM_ERROR uvm_packer_buffer_overflow.sv(49) @ 0: reporter [uvm_packer_buffer_overflow] data_out[1024]:0x00000000 != data_in[1022]:0x9b387ab5 # UVM_ERROR uvm_packer_buffer_overflow.sv(49) @ 0: reporter [uvm_packer_buffer_overflow] data_out[1025]:0x00000000 != data_in[1023]:0x5d3822c4 # UVM_ERROR uvm_packer_buffer_overflow.sv(49) @ 0: reporter [uvm_packer_buffer_overflow] data_out[1026]:0x00000000 != data_in[1024]:0xc6462f4a UVM 1.2 Command: qrun -sv +define+UVM_1_2 uvm_packer_buffer_overflow.sv Error: # UVM_ERROR uvm_packer_buffer_overflow.sv(49) @ 0: reporter [uvm_packer_buffer_overflow] data_out[1024]:0x00000000 != data_in[1024]:0xc6462f4a Test program uvm_packer_buffer_overflow; import uvm_pkg::*; `include "uvm_macros.svh" initial begin int uvm_packer_max_bytes = 4096; int uvm_packer_max_dwords = uvm_packer_max_bytes / 4; int unsigned data_in[] = new[uvm_packer_max_dwords + 1]; int unsigned data_out[]; int offset; uvm_packer p = new(); foreach (data_in[i]) begin data_in[i] = $urandom(); end foreach (data_in[i]) begin p.pack_field_int(data_in[i], $size(data_in[i])); end `ifdef UVM_1_2 p.set_packed_size(); p.get_ints(data_out); `endif `ifdef UVM_1800_2_2020 p.get_packed_ints(data_out); // 1800.2 2020 prepends m_pack_iter and m_unpack_iter offset = 2; `endif assert (data_out.size() == (data_in.size() + offset)) else begin `uvm_error("uvm_packer_buffer_overflow", $sformatf( "data_out.size:%0d != (data_in.size:%0d + offset:%0d):%0d", data_out.size(), data_in.size(), offset, data_in.size() + offset )) end foreach (data_out[i]) begin // Don't compare the following entries for UVM 1800.2 2020: // data_out[0]: m_pack_iter // data_out[1]: m_unpack_iter if (i < offset) continue; if (data_out[i] != data_in[i - offset]) begin `uvm_error("uvm_packer_buffer_overflow", $sformatf( "data_out[%0d]:0x%x != data_in[%0d]:0x%x", i, data_out[i], i - offset, data_in[i - offset] )) end end end endprogram uvm_packer_buffer_overflow.sv
  12. Earlier
  13. Thank you Erwin We have a use case where we have a string parameter at component level with a default value "" (empty string) which can be overwritten per instance in the design. This is why I am looking for something like <ipxact:value></ipxact:value> or <ipxact:value/> Is there a way to express this ? Thank you Khushi
  14. Hi Kushi, IP-XACT does not allow that. Parameters always need to have a default value. Best regards, Erwin
  15. I'm in the same boat as previous posts and those posts were in 2014 and 2015. I'm using version 1.2 and the code in uvm_reg_map.svh in the method Xinit_address_mapX(), that calculates the stride is still the same. Currently the database, m_mems_inf[], is defined as local, so it's difficult to override the stride value with derived classes. Could there be support to have the user override the stride value prior to calling lock_model()? If there's suggestions as how to go about doing this that would be great.
  16. All right, as always devil is in the details. This is enforced by construction by the CMake scripts and config files. If you do cd $SYSTEMC_SRC mkdir build && cd build && x86_64-w64-mingw32.static-cmake .. then you will get just an error: The compilation of SystemC as a DLL on Windows is currently not supported! So the end user has no choice but to invoke CMake with explicit settings for static libraries: x86_64-w64-mingw32.static-cmake .. -DBUILD_SHARED_LIBS=OFF On the contrary I mentioned: This is kinda true... or more precisely, the autoconf-based flow is more permissive and lets the end user do silly things... When targeting Windows, there is something inconsistent in the autoconf based flow. The below: ./configure --host=x86_64-w64-mingw32.static will build a static library (libsystemc.a) as expected but it will happily do so using settings for shared libraries by default (assuming --enable-shared) It makes the end-user believe that everything is fine... when it isn't. Once you understand that and you explicitly specify settings that are consistent with building a static library (and aligned with the CMake flow): ./configure --host=x86_64-w64-mingw32.static --disable-shared then everything works just fine. I guess it would be a nice improvement to make the autoconf scripts more robust, so they just throw an error when targeting windows with default settings (assuming --enable-shared), similar to what the CMake scripts do.....
  17. Hello How I can specify a parameter in IP-Xact 2014 with default value is empty (e.g. empty string). If I just omit the value like <ipxact:value></ipxact:value> or <ipxact:value/>, the schema validation fails xml code : <ipxact:parameter parameterId="param1id"> <ipxact:name>param1</ipxact:name> <ipxact:value></ipxact:value> </ipxact:parameter> xmllint -noout -schema schema/1685-2014/index.xsd test.xml test.xml:146: element value: Schemas validity error : Element '{http://www.accellera.org/XMLSchema/IPXACT/1685-2014}value': [facet 'minLength'] The value has a length of '0'; this underruns the allowed minimum length of '1'. test.xml:146: element value: Schemas validity error : Element '{http://www.accellera.org/XMLSchema/IPXACT/1685-2014}value': '' is not a valid value of the atomic type '{http://www.accellera.org/XMLSchema/IPXACT/1685-2014}simpleBaseExpression'. test.xml fails to validate Thank you Khushi
  18. I made some examples of SystemC testbench embedding Python, gnuplot. This SystemC testbench can run under ModelSim. With SystemC, I'm sure, there's no need to use weird procedural language interface. If you're interest in this issue, visit and read ad-free my blog page about HLS. Sorrily, it's written in Korean, but there's google translation service. You can find down link to download design sources. https://hls-goodkook.blogspot.com/2021/09/3-c-c-validation.html
  19. SInce the question is already 4 years old I guess there will be now answer. If you need something like the fair mutex you might have a look at the scc::ordered_semaphore which can also be used as a mutex (with a value of one). At https://github.com/Minres/SystemC-Components/blob/main/src/sysc/scc you will find a complete implementation.
  20. Hi, I've observed some issues when cross-compiling SystemC 2.3.3 libraries for Windows (on a linux machine). The first cosmetic obstacle is that src\sysc\kernel\sc_cmnhdr.h has the following: # include <Windows.h> This is absolutely fine when natively building on Windows, but linux is case sensitive and isn't too happy about this. A simple change to # include <windows.h> is enough to fix the problem. More generally though, this tells me that cross-compiling SystemC libraries hasn't really been tested or verified, correct ? The next observation I would like to share is that the CMake-based and the autoconf-based flow do not exactly produce the same build configuration, which ultimately leads to different behaviors. Essentially in a few words, the autoconf-based flow generates Makefile recipes that define DLL_EXPORT when compiling the SystemC source files. On the contrary, the CMake-based flow generates Makefile recipes that do not define DLL_EXPORT. This is an important aspect because there is an interaction with the toolchain header files, that do check for DLL_EXPORT, and adjust their behavior accordingly. Ultimately this is the difference between a success and a failure at link time. So which SystemC build configuration is correct ? At first sight, this might seem like a moot point, because there is not a single reference to DLL_EXPORT in the SystemC source code. However there might be other tools involved in the whole build process that somehow check for DLL_EXPORT, but only the maintainers of SystemC can confirm that. Note that there might also be a potential issue in the toolchain header files (MinGW-w64), that incorrectly react to DLL_EXPORT being defined or not, I'm too sure. Any experts comments on this ? For the interested reader, you will find all the details and necessary steps to reproduce the issue here: https://stackoverflow.com/questions/69171109/cross-compiling-systemc-libraries-and-linking-to-them/ David
  21. I have uvm_seq_items as below. class a_seq_item extends uvm_sequence_item; bit x; bit y; bit z; ............. endclass class b_seq_item extends a_seq_item; bit p; bit q; bit r; ....... endclass I want to use b_seq_item (p,q,r vars) everywhere in my env , but p , q & r should be equal to x,y & z. How can i assign p = x , q = y & r = z? sequencer is using a_seq_item.
  22. Can anyone explain me where is in_use() function implemented ?
  23. What I expect "support" is more like a guidance to encourage people try their favorite language in their reference model, which can act as another "Option". Currently c/cpp is the most efficient programming language and is believed to develop fastest simulation model in practice, which also give more space to speed optimization. But when people want to develop raw model more early, more syntax friendly language is better choice. Currenly, SWIG is indeed a good approach to integrate other programming language as David's suggestion.
  24. Hi Jeremy, Thanks for submitting this issue. I don't think you are missing anything. The UVM working group is looking into it. Mark Strickland (Accellera UVM Working Group Chair)
  25. Hi, I just tried to use clang under windows to compile some SystemC projects and I experienced a pointer corruption of the instance pointer for the execution of a sc_thread. After some debugging I discovered, that the "hack" for older VS++ compilers referring to the macro "SC_USE_MEMBER_FUNC_PTR" (see https://github.com/accellera-official/systemc/blob/604182509559ae42c34e878f508bae7c18abbbd6/src/sysc/kernel/sc_process.h#L120) will create working simulation binaries with clang (i.e. actually not defining the macro is doing the trick). I actually also realized, that clang under Windows is not officially supported, which explains that it have not arisen yet. Nonetheless, adding here an additional compiler detection macro would be easy and would add (although quite untested) clang support for windows. I tried my fix for clang 10 and clang 12. I got the impression, that clang sometime in the past adapted to the "bad" msvc behavior and did not change it, although msvc got standard compliant. The fix for this problem would be quite easy: #if defined(_MSC_VER) && !defined(__clang__) #if ( _MSC_VER > 1200 ) # define SC_USE_MEMBER_FUNC_PTR #endif #elif defined(_WIN32) && defined(__clang__) //do not define SC_USE_MEMBER_FUNC_PTR #else # define SC_USE_MEMBER_FUNC_PTR #endif Additionally, I would propose to throw a warning in the CMakeLists, if using an unsupported compiler. Do you like to get PullRequest on github?
  26. Although languages like Python have become immensely popular because they are easy to learn, enabling rapid prototyping, and have accumulated vast libraries for many different applications, they have yet to earn their place in Industry practice because of their relatively poor performance. Verification teams constantly struggle keeping their already slow nightly regression runs nightly; having it turn into days or weeks is not acceptable. I do know a number of design teams have successfully developed testbench models in <your_favorite_language_here>. Those are fragmented examples and as the other David says, it would be stretching resources to support all of them. We are still wasting resources from the mistake of having to support both Verilog and VHDL HDLs back in the 1990s. Is it possible optimizing Python overtakes the performance of C/C++ in the years to come? Maybe. But unlikely in the next decade.
  27. Defining SC_MAX_NBITS has not been used for many years, it dates to early in SystemC's development, so I am not surprised it fails. The performance issue you are encountering is caused by the fact that malloc is done for each sc_signed or sc_unsigned value created. This issue is addressed in the next release of SystemC. In the mean time, if it is practical, use statically created variables where possible, e.g., static variables in functions/methods, or variables in structures that are allocated once. This should improve your speed for some cases, but does not solve the problem of dynamic intermediate results, e.g., the results of arithmetic and logical operations. Again, this will be addressed in the next release of SystemC.
  28. Hi, Recently in my design, I used the datatype "sc_biguint",since the simulation speed is slower than before. So, I found that I can modify the SC_MAX_NBTIS for faster speed. ./systemc-2.3.3/include/sysc/kernel/sc_constants.h // Maximum number of bits for arbitrary precision arithmetic. If // defined, the arithmetic becomes faster. If not defined, the // arithmetic becomes slower and the precision becomes infinite. It // is a good idea to define this constant as a multiple of // BITS_PER_DIGIT, which is defined in numeric_bit/sc_nbdefs.h. //#define SC_MAX_NBITS 510 // 17 * BITS_PER_DIGIT #define SC_MAX_NBITS 510 // 17 * BITS_PER_DIGIT But, after I define the SC_MAX_NBITS, compilation has some error showed up as follow. In file included from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/int/sc_signed.h:103:0, from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/bit/sc_proxy.h:66, from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/bit/sc_bit_proxies.h:34, from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/bit/sc_bv_base.h:58, from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/bit/sc_lv_base.h:69, from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/bit/sc_lv.h:51, from /usr/cad/systemc/systemc-2.3.3/include/sysc/communication/sc_signal_rv.h:33, from /usr/cad/systemc/systemc-2.3.3/include/systemc:93, from /usr/cad/systemc/systemc-2.3.3/include/systemc.h:219, /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/int/sc_unsigned.h: In member function ‘sc_dt::sc_digit* sc_dt::sc_unsigned::get_raw() const’: /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/int/sc_unsigned.h:1081:37: error: invalid conversion from ‘const sc_digit* {aka const unsigned int*}’ to ‘sc_dt::sc_digit* {aka unsigned int*}’ [-fpermissive] sc_digit* get_raw() const { return digit; } ^~~~~ In file included from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/bit/sc_proxy.h:66:0, from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/bit/sc_bit_proxies.h:34, from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/bit/sc_bv_base.h:58, from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/bit/sc_lv_base.h:69, from /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/bit/sc_lv.h:51, from /usr/cad/systemc/systemc-2.3.3/include/sysc/communication/sc_signal_rv.h:33, from /usr/cad/systemc/systemc-2.3.3/include/systemc:93, from /usr/cad/systemc/systemc-2.3.3/include/systemc.h:219, /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/int/sc_signed.h: In member function ‘sc_dt::sc_digit* sc_dt::sc_signed::get_raw() const’: /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/int/sc_signed.h:1177:11: error: invalid conversion from ‘const sc_digit* {aka const unsigned int*}’ to ‘sc_dt::sc_digit* {aka unsigned int*}’ [-fpermissive] { return digit; } ^~~~~ In file included from /usr/cad/systemc/systemc-2.3.3/include/systemc:106:0, from /usr/cad/systemc/systemc-2.3.3/include/systemc.h:219, /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/misc/sc_concatref.h: In member function ‘const sc_dt::sc_unsigned& sc_dt::sc_concatref::value() const’: /usr/cad/systemc/systemc-2.3.3/include/sysc/datatypes/misc/sc_concatref.h:258:52: error: incompatible types in assignment of ‘sc_dt::sc_digit* {aka unsigned int*}’ to ‘sc_dt::sc_digit [35] {aka unsigned int [35]}’ sizeof(sc_digit)*result_p->ndigits ); Is there any other setting I should modify, or any solution for this problem? Thank you. Note: GCC version = 7.3.1 Systemc version = 2.3.3
  1. Load more activity
  • Create New...