Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 07/04/2020 in Posts

  1. 2 points
    Just to add 2 cents to @David Black proposal: If the instantiation is exepensive you could fork() (https://en.wikipedia.org/wiki/Fork_(system_call)) your programm after instantiating the design. Basically you create a new OS process as copy of the current one and here you can continue the simulation. But in essence it is the same approach as David described.
  2. 2 points
    The primary reason is that the SystemC Proof-of-Concept (PoC) implementation uses some global data structures, which get constructed during elaboration, which are not fully cleaned up when sc_stop() is called. These data structures are only freed by the OS when the application quits. There have been some efforts improve the PoC implementation in this area, but these are currently stalled. Unfortunately, partially due to bad code examples, bad habits, and laziness, many SystemC models also not cleanly deallocate their dynamically allocated resources, as they still use manual resource allocation using the new operator, but never release that memory using delete as they don't implement a destructor out of laziness. Since the general availability of smart pointers in C++'11, especially std::unique_ptr<T>, managing cleanly dynamic memory management has become much more convenient and there is no justification anymore to write such dirty code. However, there is a lot of legacy code out there making a bad example and hardware engineers often lack a formal education in C++ instead learning the language basically on the job. This will only resolve slowly over time. @David Black's suggestion to launch your multiple simulations from a separate process implemented using your favourite scripting language or even in C++, is the easiest workaround for the above problems.
  3. 2 points
    You cannot bind an output port to an input port. Ultimately each port must bind to a signal either hierarchically (this is where port to port binding can is used) or directly. So you need to define signal for each of the test_module output ports and bind the sc_out and sc_inout ports to it. 2 remarks: you should use sc_in instead of sc_inout to indicate the purpose clearly sc_out is just a child of sc_inout to reduce the number of output ports (and hence signal) you might want to group signals logically belonging together into structs. Those can be used as data typs of signals and ports. This reduces the number of signals and events and increases simulation speed.
  4. 1 point
    maehne

    PSL in SystemC

    I am not aware of a widely used free PSL implementation for SystemC. However, you can find some research papers discussing using PSL together with SystemC, e.g.: Ali Habibi, et al.: Assertion Based Verification of PSL for SystemC Designs, IEEE, 2004. Wolfgang Ecker, et al.: Implementation of a SystemC Assertion Library, Design & Reuse.
  5. 1 point
    Eyck

    randomize a vector of values using scv

    SCV does not contain an the respective overloads for scv_introspection and _scv_distribution. Therefore there is afaik no way to simply randomize a vector. As a workaround you might use the randomization for plain C-style arrays.
  6. 1 point
    The SystemC standard says: 5.10.8 Multiple event notifications A given event shall have no more than one pending notification. If function notify is called for an event that already has a notification pending, only the notification scheduled to occur at the earliest time shall survive. The notification scheduled to occur at the later time shall be cancelled (or never be scheduled in the first place). An immediate notification is taken to occur earlier than a delta notification, and a delta notification earlier than a timed notification. This is irrespective of the order in which function notify is called. If I run the following example the simulation stops after 100000000 ps as intended, however, the memory usage of the program increases rapidly to 1GB and more. #include <iostream> #include <systemc.h> SC_MODULE(Tester) { sc_event event; uint64_t counter = 0; SC_CTOR(Tester) { SC_METHOD(process); sensitive << event; } void process() { if (counter == 100000000) sc_stop(); counter++; event.notify(1, SC_MS); event.notify(1, SC_PS); } }; int sc_main(int argc, char **argv) { Tester tester("Tester"); sc_start(); return 0; } When both event notifications are swapped the memory leak is gone. When SC_MS is replaced by SC_US, the memory usage increases a lot slower. The program was tested with the latest SystemC version from GitHub as well as SystemC 2.3.3 on the WSL with GCC 8 and GCC 6.
  7. 1 point
    Hi all, So, I'll start by stating the problem. The problem is that it is not possible to use Quickthreads on 64 bit Windows. Basically, for sake of consistency with other platforms as well as 32 bit Windows, I need to be able to use Quickthreads as well. So, before I begin I have a question: What is the out of the box choice for SystemC threads on Windows platforms both 32 bit and 64 bit? As far as I understand from the configure script, WinFibers is what will be used for Windows if MinGW is being used: # use WinFiber on MinGW platforms AS_CASE([${TARGET_ARCH}], [mingw*],[QT_ARCH="none"]) Can someone please confirm this? So, I recently had the discussion in this post https://forums.accellera.org/topic/5627-systemc-231-installation-problem-on-windows-7-with-cygwin. I became sure that the issue is coming from Quickthreads and started trying to get it to work. Starting from the 64 bit Linux Quickthreads source iX86_64.s, I created a new file x64.s which has the modifications necessary to fit the Windows 64 bit ABI/Calling convention. I mostly got it to work. I, however, faced an issue related to exception handling. The issue arises from the throw statements found in sc_thread_process.h which affect most of sync/async reset flows: case THROW_SYNC_RESET: DEBUG_MSG( DEBUG_NAME , this, "throwing reset for"); if ( m_reset_event_p ) m_reset_event_p->notify(); throw sc_unwind_exception( this, true ); ... case THROW_KILL: DEBUG_MSG( DEBUG_NAME, this, "throwing kill for"); throw sc_unwind_exception( this, false ); I am using MinGW GCC 7.4.0 with SEH exceptions. The throw statements up there end up calling RaiseException which is a Windows API that then causes the crash. I have spent days debugging that part and I was not able to figure it out. I need to use SEH exceptions instead of SJLJ exceptions. Reason being, that SJLJ exceptions while it works with additions in sc_cor_qt similar to those in sc_cor_fibers, side effects exist such as having an incomplete backtrace in case we're in a try block. So, I went ahead and created a commit here https://github.com/moayman/systemc/commit/e3790038752753bbbc2b0f30c064faae058ff227 that you may want to check out. A note about my commit: I started from SystemC 2.3.2 as I had a problem compiling 2.3.4 due to sc_mutex/sc_host_mutex I would really appreciate any kind of help with this issue. We're so close to having Quickthreads support for 64 bit of Windows. Thanks a lot.
  8. 1 point
    Yes, I have actually created a post on the MinGW forum that can be found there: https://sourceforge.net/p/mingw-w64/discussion/723798/thread/7b5436a4d9/. I though got nothing. Your suggestion about overhauling this part of SystemC sounds really good. The only concern for me is that C++20 is pretty new and it might require users to upgrade their compilers to provide C++20 support.
  9. 1 point
    @maehne, First of all, I would like to thank you a lot for the kind words and the info you provided. So, since my post I have been digging deep into the issue and reached the following: The issue stems from the use of exceptions from within a Quickthread I managed to create a minimal testcase that only includes Quickthreads code and a part of an example that they provided in meas.c. You can find that attached. I came across a couple of good reads and found that: In case of SEH exceptions to be able to unwind a function unwind info must exist in the .pdata/.xdata sections of the binary I also found that GCC provides some assembly pseudos that start with .seh_ that adds the necessary unwind info for assembly functions The pseudos I am talking about are similar to those https://docs.microsoft.com/en-us/cpp/build/exception-handling-x64?view=vs-2019#unwind-helpers-for-masm You can find the GCC ones at https://sourceware.org/legacy-ml/binutils/2009-08/msg00193.html I added those and it failed as it used to do I was able to verify that the unwind info was added for the qt_block function using dumpbin /unwindinfo I really can't figure it out and I have lost hope to be honest, it has been quite a while that I have been trying to get this to work. But, I believe it is either a GCC issue with SEH or we're hitting some kind of a limitation and what we need to do is not achievable given the way Quickthreads messes with the stack and the way Microsoft does things and all the security_cookie_checks that happen. Either that or my code modifications to Quickthreads are bad, although I don't think so given that they work in call cases except for when exceptions are thrown. I really am in a desperate need of some help. sehissue.zip
  10. 1 point
    @Eyck is correct. It would be a major rewrite of SystemC to allow this. If you are trying to launch multiple simulations (sequentially) perhaps with different parameters, you need to do that from a script. If you are super insistent you have to do it under C++, you could try the following: // Compile your main SystemC as run.exe and place it in the same directory as this program int main(void) { int errors = 0; errors |= system("./run.exe -option 1"); errors |= system("./run.exe -option 2"); return errors; } Or just use your favorite script language (bash, perl, zsh, csh, python) to do the equivalent. You can store results in files and read configuration data from files. It's just C++. If you want to rewrite the main.cpp from the library, feel free to do so, but you still won't be able to reset SystemC's internal data structures without invoke a completely new process.
  11. 1 point
    My point was more of a generic nature and more related to modeling guidelines. If your initiator/test_producer has many signals some of them might belong 'logically' together as they are written at the same time. E.g in AHB you have HADDR, HTRANS, HBURST, HWRITE, etc. Instead of declaring them as sc_out<sc_dt::sc_logic> xxx or alike: sc_out<sc_dt::sc_lv<32>> HADDR; sc_out<sc_dt::sc_lv<4>> HTRANS; sc_out<sc_dt::sc_logic> HWRITE; . . . it would make sense to do it this way: struct ahb_req { sc_dt::sc_lv<32> HADDR; sc_dt::sc_lv<4> HTRANS; sc_dt::sc_logic HWRITE; . . . }; sc_out<ahb_req> ahb_out; In the first case you have basically 3 signals/events to observe and deal with. In the latter one you only have 1 event. If you cannot refactor the the producer than doing so just for the receiver is point less. But if you have the option to refactor the initiator then I would recommend to do it in this or a similar way.
  12. 1 point
    You cannot call sc_main directly from main(). main() comes with the SystemC reference implementation (SystemC simulator) and initailizes the simulation kernel. You miss that in your main function, you migh tlook it up at https://github.com/accellera-official/systemc/blob/master/src/sysc/kernel/sc_main.cpp and https://github.com/accellera-official/systemc/blob/master/src/sysc/kernel/sc_main_main.cpp Despite that, you cannot call your sc_main twice. The simulation kernel in the reference implementation is not re-entrant. Thus the LRM states in section 4.3.4.2 Function sc_start: in the sequence you described you would call sc_start() after sc_stop() has been called
  13. 1 point
    First, you have an error in your example corrected below: for(int i=0;i<prt_input.size();i++) sensitive << prt_input[i]->value_changed_event(); } Second, you can use a recent addition to SystemC (if using version 2.3.3 or later) using the new sc_event::triggered() method, which returns true if the event happened in the immediately preceding delta-cycle. You would simply apply this to the default_event() method present in most channels. A less general approach could also be used with sc_signal channel, which has always provided the event() method for the same effect, but won't work on other channels. Of course you can apply this to any method returning events of other types (e.g. sc_fifo_in_if::data_written_event()). This can also be used with SC_THREADs with the sc_event_or_list. I illustrate the more general approach on EDAplayground here: https://edaplayground.com/x/4kgB
  14. 1 point
    David Black

    About AT

    TLM (Transaction Level Modeling) is focused on communication (interconnection) of SystemC models. So your question is slightly irrelevant. From what you indicate, I would say that AT modeling style would accomplish what you are interested in. Sockets are an almost essential aspect of TLM as they simplify modeling and can provide information about the transaction. As to what metrics you can get, that is up to you. SystemC is not a prepacked set of subroutines, nor is it a narrowly focused on one type of analysis. SystemC is a methodology using C++ to model any variety of ideas using an event driven simulation core (provided). You provide the code to stimulate and assess the information. It is common to obtain things such as bus bandwidth and utilization, but there are no primitives provided to do this on its own. Important: You need to be well versed in C++ to effectively use SystemC. Far too many folks approach SystemC thinking it will be a panacea and only requires C. There are companies that provide commercial tools on top of SystemC to help with modeling. I will not comment on their utility, but obviously they have some value or they would not be around for long. There are also consulting companies that specialize in SystemC. Learn more on the main Accellera website (https://www.accellera.com). My employer (and thus myself) focuses on the training/educational aspect.
  15. 1 point
    David Black

    About AT

    Approximately-Timed (AT) models provide decent timing accuracy for modeling purposes. Common use cases include architectural analysis (cost vs performance). AT models are used to understand the effects of interconnect and bus protocols on overall performance. Loosely-Timed (LT) models provide for simulation performance (i.e. fast), but often use techniques that sacrifice modeled timing accuracy. The intent is for use in software development on virtual platforms. Techniques used include Temporal De-coupling coupled a notion of a Quantum, and Direct Memory Interface. LT models usually try to minimize calls to wait() due to overhead of context switching. Fast models almost never use sc_clock (slows simulation). Both modeling styles (AT & LT) should be register accurate and functionally correct. Both include timing, but obviously the degree of accuracy differs greatly. Standards compliant models will provide both modeling styles in a single design; although; it is often the case that early modeling starts with one or the other and later adds the missing style. Generally, b_transport functions provide the LT coding style, and nb_transport_* methods provide the AT coding style. Neither should be as accurate as RTL because that would require adding so much code overhead that you might as well write RTL and skip SystemC. Clock cycle accurate models are generally inappropriate. Cycle-Approximate or Cycle-Count Accurate modeling is a better description of AT models. [As an employee of Doulos Ltd, I teach courses on SystemC modeling with TLM-2.0. You might find that taking an on-line class from us is beneficial. https://www.doulos.com]
  16. 1 point
    Silly me, I was quite mistaken in my simple solution (and it only took me a few minutes after posting to realize it); however, this exercise reminded me of a 2011 feature: reset. This works for SC_METHOD processes, but is inconvenient for SC_THREADs. I enjoyed working the puzzle. You can see a full working example here: https://www.edaplayground.com/x/39QM Outline: When registering your SC_METHOD process capture the process handle and specify dont_initialize(). At the start of your method implementation, check for the trigger state of reset_event and return immediately if triggered. To reset static sensitivity, simply issue reset on the process. Include a comment that you are simply interrupting. Note 1: This assumes you are using a version of SystemC 2.3.3 or later. If using 2.3, you will need to add a bool flag that is set at the time of invoking reset and cleared inside the process upon detection. Note 2: You could also use reset_signal_is(); however, that would require adding deassertion and would be messier in my opinion. An alternate and less intrusive method would be to simply add an interrupt event into the sc_event_or_list every time you change sensitivity: next_trigger(some_event | interrupt_event); next_trigger(time_delay, interrupt_event); Unfortunately, this doesn't work for sc_event_and_list; however, you can synthesize that situation with another process. I will leave that for you to figure out.
  17. 1 point
    Stephan Gerth

    UVM-SystemC 1.0-beta3 released

    UVM-SystemC 1.0-beta3 was released for public review. Download available at https://www.accellera.org/downloads/drafts-review. Notable changes since 1.0-beta2: Register API Bugfixes & SystemC 2.3.3 support Ubus example Automatic objection mechanism
  18. 1 point
    SystemC TLM is a part of the SystemC standard (both parts TLM1 and TLM2). True, it is an newer addition, but it is never-the-less part of the standard. TLM1 was the first attempt to standardize an API, which worked, but it didn't address the needs of the SystemC community as well as had been hoped. TLM2 standardizes a methodology to model address mapped bus communications and the associated API. It allows for easier exchange of IP blocks for simulation. TLM emphasizes that "ports" are not just wiring connection points, but rather a nexus for higher levels of communication. TLM2 has "sockets", which are really just glorified SystemC port combinations (sc_port & sc_export). TLM2 also standardizes some concepts (even if not stringently) of different styles of transaction level modeling (sometimes called coding styles). For instance, "loosely-timed" (LT) represents "execute as fast as possible while maintaining register functional accuracy"; whereas, "approximately-timed" (AT) means "provide sufficient timing detail to allow bus-level timing analysis[1]". AT does not simulate as quickly as LT because it has to provide extra details and timing behavior. Note 1: Not necessarily the same as clock cycle accuracy. On the other hand, the SystemC core provides the fundamental mechanisms that allow for design encapsulation (sc_module), event-driven simulation (sc_event and wait()), processes (SC_THREAD, SC_METHOD), a notion of simulated time (sc_time) and channels (sc_interface, sc_prim_channel, sc_channel). Channels are one of the most important features and enable abstraction of safe interprocess communications. SystemC also provides the minor addition of hardware datatypes (sc_logic<>, sc_int<>, sc_fixed<>, etc). It also provides primitive communications channels such as sc_signal<> and sc_fifo<>. Thus, the SystemC core provides the foundation needed to implement TLM. Sadly in some sense, SystemC provides a number of simplifications for writing RTL even though it is fundamentally not the strong point of the simulator. To some degree these simplifications are an holdover from SystemC 1.0 for backwards compatibility. I said sad because the simplifications have encouraged many to think of SystemC as an appropriate vehicle for writing RTL code, but then get frustrated at the lack of performance (for RTL). SystemVerilog and VHDL are much better suited for that task. The RTL aspect of SystemC is good in making it easier to interface SystemC to the other languages for co-simulation.
  19. 1 point
    apfitch

    Memory mapped bus ??

    When TLM2 was developed, the main requirements were speed interoperability To achieve interoperability, it was decided to standardise the generic payload object. The design of the generic payload was aimed at allowing modeling of memory-mapped busses. A memory-mapped bus uses an address in memory to locate the registers/memories in peripherals attached to a bus. So the generic payload includes a field for address, as well as fields for data. regards Alan
×
×
  • Create New...