Jump to content

maehne

Members
  • Content Count

    286
  • Joined

  • Last visited

  • Days Won

    34

Reputation Activity

  1. Like
    maehne got a reaction from Nitin_S in Issue while calling sc_main multiple times from main   
    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.
  2. Like
    maehne got a reaction from David Black in Issue while calling sc_main multiple times from main   
    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. Thanks
    maehne got a reaction from Shashank V M in 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.
  4. Like
    maehne reacted to Lukas Steiner in Memory leak when sc_event is notified twice   
    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.
  5. Like
    maehne reacted to mo_ayman in Supporting Quickthreads for SC_THREADS on win64   
    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.
  6. Like
    maehne reacted to mo_ayman in Supporting Quickthreads for SC_THREADS on win64   
    @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
  7. Like
    maehne reacted to mo_ayman in Supporting Quickthreads for SC_THREADS on win64   
    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. Like
    maehne reacted to Eyck in Binding sc_out type of ports to sc_port<sc_signal_inout_if<T>,N> type of multiports failed   
    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.
  9. Like
    maehne reacted to Eyck in Binding sc_out type of ports to sc_port<sc_signal_inout_if<T>,N> type of multiports failed   
    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.
  10. Like
    maehne reacted to David Black in How can I identify which port has changed value when using a multiport   
    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
  11. Like
    maehne reacted to David Black in 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]
  12. Like
    maehne reacted to David Black in 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.
  13. Like
    maehne reacted to Stephan Gerth in 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
     
  14. Like
    maehne reacted to David Black in SC_METHOD Dynamic sensitivity modification outside the process   
    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.
  15. Like
    maehne reacted to Eyck in Error E0304 and C2665   
    The example you are refering to is for SystemC 2.0 and more over has errors. Actually this is a bad example to start with.
    the sc_start() in line 17 needs to be commented out for 2 reasons: a) it doesn't make any sense and b) it runs elaboration and tracing (VCD) needs to be initialized before that. After elaboration you cannot add signals for tracing anymore sc_start() (lines 32, 34, 40, 42, 47, 49, 56 58) has to be called either without any arguments (so it runs to the end) or with a duration in terms of sc_time like this: sc_start(1, SC_NS);  
    My recommendation would be to either use  the Doulus tutorials: https://www.doulos.com/knowhow/systemc/tutorial/ or the stuff from SCLive (https://sclive.wordpress.com/)
  16. Like
    maehne reacted to Eyck in How to declare dynamic memory by new in systemC   
    Actually using new is not recommended at all. You should do something like:
    std::array<sc_dt::sc_uint<32>, MEMORY_DEPTH> mem; or (C++11):
    std::vector<sc_dt::sc_uint<32>> mem{MEMORY_DEPTH}; As far as I can see you try to initialize mem in-class (during declaration) and this is not allowed in C++. You can do this only in the constructor. And if you need to use new, don't forget to delete.
  17. Like
    maehne reacted to Martin Barnasconi in SystemC AMS application examples now available   
    Accellera released the SystemC AMS user's guide application examples, which are available for download via this link.
    These examples can be executed using your preferred EDA tools, as long as they support the SystemC and SystemC AMS language standard. Alternatively, you can use the open source SystemC and SystemC AMS reference implementations. Instructions for installation and execution can be found in the INSTALL or README files as part of these packages.
    We welcome your feedback!
  18. Like
    maehne reacted to David Black in async_request_update example   
    usleep() does not interact with the systemc kernel at all. SystemC time is different from real time.
  19. Like
    maehne reacted to David Black in How to read or write a 256 bit binary?   
    This is easy.
    First, sc_int<N> and sc_uint<N> are limited to 64 bits. So you cannot use 256 there; however, you can use sc_bigint<N> and sc_biguint<N> for any value of N>64.
    Second, you will need to specify constants as strings since C++ itself does not support >64 native numbers; although, you can use C++ user-defined literals to get around this limitation if using C++ 2011 or better.
     
  20. Like
    maehne reacted to AmeyaVS in binding issue   
    Hello @Partha,
    As the error message suggests the third indexed interface in host(my_host) object instance is not bound:
    i.e. host_port.
    For future reference pass the name of the interface also so that you  can get more descriptive names in the error messages.
    For e.g.: Changing your source files as shown below changes the error message:
    // Code your testbench here. // Uncomment the next line for SystemC modules. #include <systemc.h> #include <stdlib.h> class slave_if : public sc_interface { public: virtual void write(int data) = 0; virtual void read() = 0; }; SC_MODULE(Host) { sc_in<bool> scl{"scl"}; sc_in<bool> sda{"sda"}; sc_in<bool> rw{"rw"}; sc_port<slave_if> host_port{"host_port"}; int val; void behaviour() { if (scl == 1 && sda == 0 && rw == 0) { val = rand() % 50; host_port->write(val); } else if (scl == 1 && sda == 0 && rw == 1) { host_port->read(); } } SC_CTOR(Host) { SC_METHOD(behaviour); sensitive << scl << sda << rw; } }; SC_MODULE(Master), public slave_if { sc_in<bool> clk{"clk"}; sc_out<bool> scl{"scl"}; sc_out<bool> sda{"sda"}; sc_out<bool> rw{"rw"}; sc_fifo_out<int> master_write_fifo{"master_write_fifo"}; sc_fifo_in<int> master_read_fifo{"master_read_fifo"}; int i = 0, data_get, val, no_bits = 8; Host my_host; void write(int data) { while (no_bits != 0) { sda = data & 1; wait(SC_ZERO_TIME); master_write_fifo.write(sda); no_bits++; } } void read() { while (i != 8) { master_read_fifo.read(val); data_get = data_get + (val * pow(2, i)); /*master_read_fifo.read(val); cout<<"value:->"<<val<<endl;*/ i++; } cout << "my data:-->" << data_get; } SC_CTOR(Master) : my_host("my_host") { my_host.scl(scl); my_host.sda(sda); my_host.rw(rw); } }; SC_MODULE(Slave) { sc_inout<bool> scl{"scl"}; sc_inout<bool> sda{"sda"}; sc_inout<bool> rw{"rw"}; Master slave_master; SC_CTOR(Slave) : slave_master("slave_master") { slave_master.scl(scl); slave_master.sda(sda); slave_master.rw(rw); } }; int sc_main(int argc, char *argv[]) { sc_clock clk("clk", 1, SC_NS); sc_signal<bool> scl{"scl"}; sc_signal<bool> sda{"sda"}; sc_signal<bool> rw{"rw"}; sc_fifo<int> main_fifo{"main_fifo"}; Master master("master"); master.clk(clk); master.master_write_fifo(main_fifo); master.master_read_fifo(main_fifo); Slave slave("slave"); scl.write(1); sda.write(0); rw.write(0); slave.scl(scl); slave.sda(sda); slave.rw(rw); sc_start(); return 0; } to
    SystemC 2.3.4_pub_rev_20190904-Accellera --- Nov 18 2019 21:47:55 Copyright (c) 1996-2019 by all Contributors, ALL RIGHTS RESERVED Error: (E109) complete binding failed: port not bound: port 'slave.slave_master.my_host.host_port' (sc_port) In file: /home/ameyavs/apps/src/systemc/src/sysc/communication/sc_port.cpp:235 Hope this helps.
    Regards,
    Ameya Vikram Singh
  21. Like
    maehne reacted to Eyck in Time, initialization and async_request_update   
    You should seriously read the SystemC standard or related books.
    Neither SC_METHOD nor SC_THREAD pass time, time advances only in the SystemC kernel and the kernel returns control to them at certain time points.
    The difference is that SC_THREAD preserves state when returning control to the kernel by calling wait(). SC_METHOD cannot preserve the state (it is always called as a function) and is therefore not allowed to call wait(). next_trigger() tells the SC kernel when to invoke the SC_METHOD next time. Calling next_trigger() several times in the same method as you do it is meaningless as the last call to next_trigger() prevails. Again: next_trigger() does not stop execution rather tells the kernel when to start the method next time.
     
  22. Like
    maehne reacted to Eyck in How to create two stage pipeline using SystemC?   
    Your problem is the use of POD (plain old datatype) for communication between the processes. Why? As soon as you write onto it all other processes see the update. So the behavior of your design depends on the scheduling of the processes. If Design::process is scheduled before Design::second_stage_process the second_stage_process sees the updates of process.
    Actually there are 2 ways out:
    you just have one thread and call the function from the output to the input: void Design::process() { txProcess(); intermediateProcess(); rxProcess(); } Although it will work in your case this approach will not scale. As soon as you cross sc_module boundaries you cannot control the order of calling.
    you use a primitive channel instead of POD. In your case you might use a sc_core::sc_fifo with a depth of one. And you should use sc_vector instead of the POD array type since they need the proper initialization. Why does it help? New values being written will be visible at the output of the fifo in the next delta cycle. So no matter in which order the threads and methods are invoked they will read the 'old' values despite 'new' values have been written. HTH
  23. Like
    maehne reacted to Philipp A Hartmann in multi_passthrough_target_socket issue from 2.3.1 to 2.3.2   
    You can check the commit history of the file in the public GitHub repository. The chain of relevant changes are:
    b276fd3b ff4581f1 41ae779d Here are related discussions from the forum: 
    Hope that helps,
    Philipp
     
  24. Like
    maehne reacted to Martin Barnasconi in Tracing ELN Nodes (Voltages and Current)   
    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; }  
  25. Like
    maehne reacted to Anton in SystemC-AMS learning resources/examples   
    Hi guys, 
    I've recently started learning SystemC-AMS, just for fun mainly.
    On my learning path I've figured out that:
    There is no any good text book on SystemC-AMS available (except of SystemC and SystemC-AMS in Practice: SystemC 2.3, 2.2 and SystemC-AMS 1.0, which doesn't seems to be good neither according to customers review with overall grade 1 out of 5) There are few examples on the web available, so it's hard to learn by reviewing what other people are doing There are few educational resources available, probably the most useful (at least for me) was SystemC AMS Extensions User’s Guide (dated 2010-03-08), which seems to be outdated (for instance it mentions usage of set_timeoffset() member function which is deprecated in SystemC AMS 2.0 Analog/Mixed-signal (AMS) Language Reference Manual (dated 2016-08-12)). In some other posts on this forum I saw @Martin Barnasconi mentioning that UM is presently being updated by the committee. While googling you can find a bunch of scientific/research papers and presentations on the topic, but a holistic examples are rarely given, most often just code snippets are present. In this post I'd like to share an SystemC-AMS implementation of Algorithmic (Cyclic) ADC.
    The example uses TDF and DE domains showcasing the aspects of TDF<->DE domain crossing discussed in the SystemC AMS Extensions User’s Guide.
    It can be found here.
    Being a Simulink user I was wondering about simulation performance improvement the SystemC-AMS gives.
    Some scientific papers I was able to find touching this topic reported 5-10 times improvement.
    For this example of Algorithmic ADC implementation also a Simulink model was created (located in same repository here).
    Relevant modelling techniques was used in both SystemC-AMS and Simulink models, so the comparison is pretty much an apple-to-apple.

    It can be seen by running both models that SystemC-AMS model gives around 20x simulation time improvement over Simulink model.
    The Simulink simulates 11*2048 cycles in about 1.5 seconds, while SystemC-AMS simulates same amount of cycles in just 0.067 seconds.
    That is remarkable improvement of simulation speed.
    I hope this post will be helpful for others who learn SystemC-AMS.
    Please feel free to comment to this post with useful materials/examples to help others on their learning way. I'd love to hear if you guys knows other great resources that helped you.

    Thanks.

     
×
×
  • Create New...