Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 10/22/2012 in Posts

  1. 9 points
    Admin

    Welcome!

    Welcome to the Accellera Systems Initiative forums. Please register to start new topics or reply to existing topics. We have resently migrated our UVM forums from UVMWorld to this site. If you were registered on the previous UVM forum site, you should be able to log into the forums using your username and password from the UVMWorld forums. If you had an account on both the UVMWorld forums and the Accellera forums and these accounts used the same email address, then log in with the username and password of the forums.accellera.org account, not your UVMWorld account. If you do not remember your password, you may reset it. If you have any questions about using the forums, click the Help button at the bottom of any forum page. If you need any help with your account and you are logged into the site, click the Messenger icon (a letter) in the upper right of your screen, click Compose New, enter “admin” in the Recipient’s Name field, compose your message, and then click Send. You may also send an email to admin@lists.accellera.org. Thank you, Accellera Systems Initiative
  2. 7 points
    India SystemC User Group Conference (ISCUG) A platform to discuss the SystemC based next generation methodologies for design and verification of Electronics Systems (Semiconductor Chips + Embedded Software) Tutorial Day: April 14, 2013 (Sunday) Conference Day: April 15, 2013 (Monday) Venue: Noida, India Register for the event at www.iscug.in. Early bird discount ends on February 28th, 2013. To receive regular updates about the event, register your email at www.iscug.in and follow www.facebook.com/iscug. For sponsorship opportunities, contact info@iscug.in About ISCUG The India SystemC User's Group (ISCUG) organization aims to accelerate the adoption of SystemC as the open source standard for ESL design. ISCUG provide a platform to share the knowledge, experiences and best practices about SystemC usage. ISCUG organize an annual conference which provides a platform for the SystemC beginners, the SystemC experts, ESL managers and the ESL vendors to share their knowledge, experiences & best practices about SystemC usage. The event will also be useful for: SoC Architects involved in architectural exploration, performance optimization, power optimization etc.. Embedded software engineers who want to explore usage of Virtual Platforms for embedded software development Chip verification engineers who want to explore SystemC based verification methodologies Chip design engineers who want to explore SystemC as the language for chip design at higher abstraction level The event is designed on the pattern of similar events happening worldwide: NASCUG, ESCUG, Japan SystemC Forum, etc. Participate You may participate in ISCUG as a speaker. Submit your abstract at www.iscug.in before February 15, 2013. The abstract will be reviewed by the technical review committee; the committee reserves the right to make final decision on speaker selection. You may present a topic related to SystemC modelling, covering virtual platforms, transaction-level modeling, high-level synthesis, SystemC-AMS, modeling for performance analysis, modellng for architectural exploration, SystemC-based SoC verification methodology, or any other topic related to SystemC modeling. You may also present a success story of SystemC adoption in your company. Tutorial Day: There will be a full day of tutorials running in parallel. To participate as a speaker, send details to info@iscug.in. First Half (Before Noon): SystemC and TLM 2.0 Introductory Tutorial Second Half (After Noon): Two/three tracks in parallel (details yet to be finalized) Advanced modeling techniques Virtual platforms for embedded software development and pre-silicon HW/SW co-verification High-level synthesis using SystemC SystemC-based verification methodologies Contact Web: www.iscug.in Email: info@iscug.in
  3. 5 points
    Do design and verification engineers care about EDA standards? If the Accellera Systems Initiative "Town Hall" meeting at DVCon 2013 Feb. 25 is any indication, the answer is an emphatic yes. A packed audience attended a lively, hour-long meeting in which non-stop questions were answered by Accellera and IEEE standards developers. - Published by Cadence Industry Insights Blo ... View the full article ...
  4. 2 points
    Hi Kevin, if you check here https://github.com/Minres/SystemC-Components/blob/master/incl/scc/utilities.h there are three macros which make live easier: #define TRACE_VAR(F, X) sc_core::sc_trace(F, X, std::string(this->name()) + "." #X) #define TRACE_ARR(F, X, I) sc_core::sc_trace(F, X[I], (std::string(this->name()) + "." #X "(" + std::to_string(I) + ")").c_str()); #define TRACE_SIG(F, X) sc_core::sc_trace(F, X, X.name()) They can be used with local variables and arrays as well with SystemC objects providing the name() funtion. This way tracing a signal becomes as easy as (assuming _STATE_ being a signal or port): TRACE_VAR(_trace_, top.dpu.idu.weight_reader.m_traffic_gen._STATE_); Pls. note: the first 2 macros are assumed to be used within a sc_module. HTH -Eyck
  5. 2 points
    The SystemC AMS TDF model of computation follows the well known data flow semantics, which means that the module is activated (i.e. the SystemC AMS processing() callback is called) as soon as the samples are available at the input port(s). After this computation, the results are immediately available at the TDF output ports (assuming you write to output ports). This means the SystemC AMS modules simply compute the signal as soon as TDF samples come in, and pass them after performing some signal processing to the output. In SystemC AMS 2.0 we introduced the concept of "Dynamic TDF" which allows additional activation of the TDF module's processing() method as soon as discrete-events come in via the converter input ports (sca_tdf::sca_de::sca_in or sca_tdf::sc_in), but this concept should only be used to make reactive systems. I advice *not* to apply this in combination with your coordinator module. Unfortunately your example of module A and B is incomplete (e.g. are module A and B connected?) to give good guidance. But the use of this coordinator module really sounds like overhead to the system simulation, as it is only meant to synchronize the execution of module A and B. Guess this is an artificial module to drive simulation only? This type of modules should be avoided. Architecture design in SystemC and SystemC AMS should represent the system by modules which are really available in the system. Instead, you could implement this example using SystemC AMS only, where module A has a fixed time step of 10ms, and module B a time step of 20ms. You can connect them via a port with a rate of 2, which means module A is called twice, before module B is called. This gives you the right execution schedule. Furthermore, by following this approach, you basically skip the native SystemC discrete event semantics, and simulation even gets much more efficient.
  6. 2 points
    Based on the error message, Incisive seems to be only able to connect Verilog signals to Discrete Event ports of a wrapped SystemC module, i.e., of type sc_core::sc_in<T> or sc_core::sc_out<T>. You will have to wrap your SystemC-AMS TDF model accordingly. It may already suffice to use TDF converter ports of type sca_tdf::sca_de::sca_in<T> or sca_tdf::sca_de::sca_out<T> instead of pure TDF ports of type sca_tdf::sca_in<T> or sca_tdf::sca_out<T>. They ensure the sampling of DE signals to TDF samples and vice versa. If that doesn't fix the error, you will have to further wrap the TDF model into a SC_MODULE having only SystemC ports of type sc_core::sc_in<T> or sc_core::sc_out<T>.
  7. 2 points
    c4brian

    wait() vs wait(SC_ZERO_TIME)

    Hi Mohit, I'm working on understanding these topics as well currently. I am working on something very similar to what you described. After you set the register value, issuing an e.notify() I believe is identifcal to e.notify(void) which is an "immediate notification". This doesn't mean any threads waiting on this event start running, it just means they are placed into the "runnable set for execution" (p73 systemC: from the ground up). Therefore whenever your b_transport releases the thread, the "target process" will start running. If you do a e.notify(SC_ZERO_TIME), aka "delayed notification with a time of 0", any processes waiting on this event will only execute after all processes in the "runnable set" have been executed. Long story short, the "target process" is not placed into the runnable set at the time of the notification. Once your b_transport releases the thread for the first time, i.e. wait(SC_ZERO_TIME), it completes the current runnable set, then places the "target process" into the runnable set. Now your second wait(SC_ZERO_TIME) will kick off the target process. This exact topic is discussed on page 75 (notify(SC_ZERO_TIME)). It discusses it's merits over notify(void) for a selected scenario (when a process could miss an event). In your scenario I dont believe you can miss the event, so notify(void) seems more appropriate. brian
  8. 2 points
    Admin

    Accellera Updates UVM Standard

    New verification standard readied for submission to IEEE; 90-day public comment period begins. - Published by Semiconductor Engineerin ... View the full article ...
  9. 2 points
    dave_59

    Randomization in an initial block

    This is the correct functionality. There is a random number generator (RNG) for every module instance in your design, and it is seeded with a RNG from the module instance it starts from. All all modules instances start out with identical seeds. Every thread that starts inside a module instance grabs a new RNG. Threads in parallel blocks get seeded in declaration order, not in the indeterminate order they might actually start. Objects that get constructed get seeded with an RNG from the thread calling the constructor. This random stability model has a few problems that the UNM attempts to correct by using a path name as an initial seed. You just need to make sure your path names are unique enough to generate distinctive seeds. A good paper to read on this topic is: Random Stability, Don't leave it to chance.
  10. 2 points
  11. 2 points
    OK, two answers - firstly, it'll probably work without that, assuming you have a c++ compiler installed, so you could just leave that out completely. Second answer - setenv is specific to c-shell. You're probably running bash, in that case the equivalent command is export CXX=g++ regards Alan
  12. 2 points
    Update: EDA Playground now supports SystemVerilog and UVM. You can edit and simulate this simple UVM testbench: http://www.edaplayground.com/s/example/546
  13. 2 points
    dakupoto

    array inside class

    Hello, Please note that SystemC is just a C++ library. So, there is no reason why an array cannot be declared, initialized and used inside a class. But there are some problems: 1. unsigned char* host_hci_pkt_arr == this is just a pointer to a single unsigned char NOT an array of pointers to unsigned chars. Why not : unsigned char* host_hci_pkt_arr[<SOME_SIZE>]; This is declaring array of pointers to an array of SOME_SIZE, explicitly. You could then fill the elements in as : host_hci_pkt_arr[0] = "0x01"; 2. The moment you use the "new" operator, you have to use the corresponding "delete" to clear memory in the destructor. On the other hand, by explicitly declaring the array as above, the compiler and runtime system takes care of memory allocation/deallocation. It appears that you are trying to model packets, and realistically a packet consists of a large number of bytes. If there are a large number of packets moving around, that are created dynamically, and then not deleted when the container object is deleted, one is looking at annoying memory leak issues. HTH.
  14. 2 points
    thomas.haber

    Parallel Simulation

    Hi Sumit, just some tought on this. I had similar ideas when i was covered with the spin simulator. If you want to keep a "systemC sync" on all processes you probably have to give more effort than you can take from it. A solution could be to allow async for a given amout (like tlm). In spin you have the possibility to do parallel calculation for a given "simulator time". In these proclets you calculate but can not change any signals, and change signals when your are out and back in sync. The same you can do in systemC. Doing parallell calculations in a seperate "real" thread, but keep systemC running in its own process means. regards, thomas
  15. 2 points
    Philipp A Hartmann

    Casting in systemC

    The implicit conversion between these types is not possible in all cases, mostly due to the danger of ambiguities in the API. Just add an explicit type conversion instead in terms of a C++ static_cast here: void do_cast(){ castout.write( static_cast<sc_uint<8> >(castin.read() ) ); } Greetings from Oldenburg, Philipp
  16. 2 points
    dakupoto

    solution for problem ...

    Hello, If you have read my responses to three recent queries on this newsgroup, you like the others, have run into a fundamental drawback/problem of C++ templates. The reason why your fifo works with single characters only is because during the crucial SystemC elaboration step, the size (number of bits) for a single character is known to the compiler. Also note that the SystemC built-in sc_fifo module can tackle built-in C++ primitive data types(char, double, float int ....) ONLY. As a character string can be of any size, it is an user defined data type, and so the user has to provide the mechanism to handle it. So, to transfer character strings via a custom fifo, a good option would be to: 1. Declare a custom interface - subclass of sc_core::sc_interface 2. Create a class that implements the interface - must ensure FIFO order in the input/output. This would be the character string FIFO. 3. Create custom ports to read/write character strings from/to custom channel Yes, it is rather messy, but it is straightforward. Hope this helps.
  17. 2 points
    apfitch

    Use cases of TLM over systemC

    Hi Cam, the idea of TLM2 was to create a standard API for transaction level modelling, that runs at high speed, and models memory-mapped buses. So the TLM Working group decided to create standard functions for both blocking and non-blocking transport; and a standard payload object. So the first advantage of using TLM2 over plain SystemC is simply that it is a standard API and payload. To model pipelined transactions, the TLMWG decided to use function calls from target to initiator and initiator to target. To allow function calls to be made in both directions needs a port on the calling module and an export on the target (forward), and a port on the target model connected to an export on the initiator. You could of course do this without sockets but you'd have to make two connections - by using a socket, a single bind call connects both export and port. Also you'd have to explicitly declare the initiator port and target export with tlm_transport_fw_if, and the target port and initiator socket with tlm_transport_bw_if - initiator socket is based on tlm_transport_fw_if and the target socket on tlm_transport_bw_if so you get that "for free". Finally, the sockets also have extra template arguments compared to SystemC ports - the Bus Width parameter. This ensures that the user cannot accidentally connect busses of different widths together. kind regards Alan P.S. There is another answer I could give: TLM2 *is* SystemC there is no difference. An initiator is a channel that implements the tlm_bw_transport_if. The target is a channel that implements the tlm_fw_transport_if. So the only difference from the "traditional" use of SystemC is the idea of a socket to provide simultaneous binding of the both port and export. If you want to, you could create your own exports and ports, and connect them yourself.
  18. 1 point
    If you want immediate communications between threads, then you should use regular SC_THREADs and wait on event, like wait(some_signal.value_changed_event());
  19. 1 point
    If you code your FFT as a pure C++ function, Vivado HLS will generate inputs and outputs automatically from function parameters and based on INTERFACE pragmas. And you can import generated RTL into Vivado IP integrator. Check out Xilinx documentation, and ask on Xilinx forums. Please also note that you can implement FFT in a various ways (with different micro-architectures), and achieve various performance vs area numbers. And HLS also requires quite a lot of learning to achieve good results.
  20. 1 point
    You cannot not check typeid() against a string as this is compiler dependend. What you shoudl do is void write_out{ if(typeid(T) == typeid(sc_dt::sc_logic){ out.write(SC_LOGIC_Z); }else{ out.write(0); } } } But actually this is more a C++ related question, in my experience Stackoverflow is a good source of help. Cheers
  21. 1 point
    You should start with learning your synthesis tool documentation. C++/SystemC synthesis is very tool-specific.
  22. 1 point
    David Black

    Temporal Decoupling

    I believe it would be fair to say that there are no universally accepted best practices, and the system design will dictate much of the implementation. In the case of shared memory, the target would need to have some idea that the memory of interest is shared. So you would need somewhere in the system to have a mapping. It might be the entire device, or a memory map might exist as a configurable object. When the target receives a read request for shared memory, it would then synchronize in order to be certain that any writes from the past are completed in other initiators. Depending on your design, you might be able to reduce the number of synchronizations if you can know apriori the nature of the sharing. E.g. if a block of memory was shared using a mutex, then synchronization might be limited to the mutex with the assumption that if you own the mutex, then the block is not written to by other initiators. This of course has some risks in the face of software defects.
  23. 1 point
    Hi Maxim, "addr" is a pointer, so you need to access its fields and methods by using operator-> : SCV_CONSTRAINT(addr->range(1,0) == 0); -- greetz, Bas
  24. 1 point
    Minimal example of the actual underlying issues posted here: http://forums.accellera.org/topic/6232-killing-a-process-with-an-included-sc_event_andor_list/
  25. 1 point
    karsten

    Tool support for SystemC-AMS

    Due SystemC AMS is a C++ library on top of SystemC only, all simulators, which support SystemC principially also support SystemC AMS. We tested this for different Cadence, Synopsys and Mentor versions.
  26. 1 point
    Quoting IEEE 1666-2011, 8.1.2 (color highlighting mine): So I think, the implementation in SystemC 2.3.2 is in line with the SystemC standard. Instead of failing with an assertion, a more explanatory error message would be helpful, of course. Greetings from Duisburg, Philipp
  27. 1 point
    David Black

    approximately timed

    IEEE 1666-2011 section 10.2 states: IEEE 1666-2011 section 10.3.4 states:
  28. 1 point
    AmeyaVS

    SystemC 2.3.2 Public Review Now Open

    Hello, Also hit a build issue when mixing different compiler standard compiler flags: The build error: SystemC review error: when building example using c++11 option and compiler supports: C++14 also. CMakeFiles/systemc.run.dir/src/main.cpp.o: In function `__static_initialization_and_destruction_0': /home/ameya/sysc2.3.2_rew/include/sysc/kernel/sc_ver.h:179: undefined reference to `sc_core::sc_api_version_2_3_2_cxx201103L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201103L(sc_core::sc_writer_policy)' Compiler used g++ 6.3 Using same compiler to build systemc-2.3.1a results in no issues, also when mixing C++ standard compiler flags to build SystemC models. While building the SystemC_2.3.2_draft one has to maintain the C++ standard compiler flags(-std=c++11 or -std=c++14), that is supported by the g++ compiler by default and any project using overridden standard compiler flags also needed to be updated to to default compiler standard flags. Here are the differences in the symbols generated by the same compiler over different versions of systemc: SystemC-2.3.1a: (Using g++ 6.3.0) 000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy) 000000000000023e T sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy) 000000000000002c b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config 000000000000002a b sc_core::sc_api_version_2_3_1<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_1(sc_core::sc_writer_policy)::default_writer_policy_config_seen SystemC-2.3.2-draft review:(Using g++ 6.3.0) 00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy) 00000000000007d0 T sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy) 0000000000000028 b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config 000000000000002c b sc_core::sc_api_version_2_3_2_cxx201402L<&sc_core::SC_DISABLE_VIRTUAL_BIND_UNDEFINED_>::sc_api_version_2_3_2_cxx201402L(sc_core::sc_writer_policy)::default_writer_policy_config_seen Can anyone comment why C++ standard specific API specs are required? For now I can circumvent the issue while setting either no compiler standard flags, or commenting out the compiler standard is passed into the build system. Is the SystemC library will be following this trend to build different version supporting different compiler standard flags? Note: As per cursory look into the source code I don't see any other API dependency to have information about the C++ standard being used to build and compile the SystemC library and the SystemC models. Would like to hear community members thoughts on this? Best Regards, Ameya Vikram Singh
  29. 1 point
    The philosophy behind nested classes is that they have access to private members of the parent class. If you want to do scoping, you're better off using packages (though it's not possible to define a nice hierarchical structure of packages).
  30. 1 point
    apfitch

    Dynamic communication path in SystemC/TLM

    There's not a dynamic port. The structure (modules/ports/channels) of a SystemC model is static once elaboration is complete. TLM is intended to model systems using memory-mapped busses. In that case you could use a router, and re-program the routing during simulation - but there's no direct built-in support for that, you'd have to make or buy a router model, kind regards Alan
  31. 1 point
    dave_59

    Output `uvm_info to file

    Use *_hier to set all components below the top level. (I don't know why they abbreviated hierarchy) uvm_top.set_report_default_file_hier(log_file); uvm_top.set_report_severity_action_hier (UVM_INFO, UVM_DISPLAY | UVM_LOG);
  32. 1 point
    Well, like I said, for brevity's sake I excluded the text from the book. But in short: you can use the wait_next_delay() within a sequence to wait a period of time, or you can embed this delay object in your driver and wait for a number of clocks. Maybe I'm being too idealist, but you never want to tie your sequences to a number of "clocks". Sequences have no notions of clocks or interfaces. Drivers see clocks, sequences see time. There are good reasons for this, but that would be a longer conversation. Your issue with regards to falling off of the clock boundary in your driver is a known one, so the book will show you how to avoid that. In short, your driver should try to fetch the next item, but if there isn't one it should call get_next_item() and then wait for a clock cycle. Then it drives. This allows back-to-back items if the sequencer is pushing quickly. After driving an item, you would call get_next_delay() and wait that number of clock cycles. This has probably gone on too long. The bigger answer to your question that I think Linc and I would agree upon is to create a reusable OO solution.
  33. 1 point
    Checking for bus response is a very specific topic, as it is intimately tied to the protocol being used. I'd say a good first step is getting the infrastructure to stimulate accesses to unmapped areas and let users implement their own response checking.
  34. 1 point
    Hi Biplab, Please consider using sc_core::sc_stop() from the place where you want to stop the simulation. Regards, Sumit
  35. 1 point
    Even afterwards, catching timing issues is best done with other tools, not with simulation. Simulation is there to show you that the RTL works, IMO. STA and CDC verification tell you that you don't have timing problems. You already have a huge stimulus space to cover when just considering that your signals come right after the clock edge. Adding randomness to the signal timings is only going to blow up your stimulus space even more. You'd be trying to model way too much.
  36. 1 point
    Philipp A Hartmann

    disbale sc_assert statements

    Yes, defining NDEBUG also disables the sc_assert statements in the SystemC proof-of-concept implementation. Having said that, I don't think it is a good idea to do so globally. You usually want your simulation to reliably abort in case of an error/bug, instead of running into arbitrary undefined behaviour. I would recommend to leave assertions active by default until profiling proves that (specific) assertions have a significant performance impact. In such cases, selectively disable only these assertions in optimized configurations. /Philipp
  37. 1 point
    Actually, the initiator does not send a delay but he OWNs the sc_time object for the delay (as well as he owns the transaction/payload object). This allows loosely timed modeling and quantum keeping. For more information see: http://forums.accellera.org/topic/110-b-transport-interface/ or http://www.doulos.com/knowhow/systemc/tlm2/tutorial__1/
  38. 1 point
    My guess would be, that you didn't configure your application project in MSVC to be built as 64-bit application. You need to (add and) select the 'x64' platform and make sure that the settings are consistent with the SystemC library project. You can use the project files for the examples as a starting point. Update: I should read the question properly. Please forget the above answer. Using the command-line requires to select the "correct" set of tools for the platform you want to use. Have a look at the TLM examples (examples/tlm/build-msvc), which provide command-line Makefiles for MSVC as well. Most importantly, have a look at "vsvars.bat" in this folder, which can be used to choose the correct MSVC command-line configuration. You can then derive additional command-line settings from the "Makefile.config" file in the same directory. /Philipp
  39. 1 point
    C++ before C++11 does not allow initialisation of non-static class members at declaration (which is what your red example is trying to do). So you must use a member initializer list (your blue example) regards Alan
  40. 1 point
    nosnhojn

    We named our new dog UVM

    UVM doesn't have to be serious all the time, does it? fyi... we got a new dog to keep us company in the office. His name is uvm. He's a good dog. He does tricks, but he can't jump. www.realityreused.com/support.html -neil
  41. 1 point
    You are free to use my solution. All you need is a C++ compiler that supports the new 2011 standard (i.e. C++11). There are several free solutions out there including GCC 4.7, Clang 3.4, and Microsoft Studios Visual C++ 2013 Express Edition. They all work with SystemC versions 2.3 and later. I provide the complete code including a testbench. Any practioner proficient in SystemC should be sufficiently proficient with C++ that this is not hard to do. The solution could also have been rewritten using function pointers, but the result would be less compact code. I can point you to many tutorials and documents on C++11, which has many very good features. A few of the more forward thinking EDA vendors are about to introduce C++11 support in the near future; however, I cannot reveal their names due to confidentiality.
  42. 1 point
    Hey CAM, I have been in conversation with many people around for the same topic. underwritten are some replies: 1: WRT to hardware already built: it can be used as golden reference model for future enhancements as new features can easily be embedded to it then to hardware , thus indeed helping the driver team to run the updated driver on it. 2: in case the SOC already built need to be integrated to some other large SOC then this virtual platform there it is playing the vital role as above WRT to architectural exploration , needs to create daisy chain equation using matlab or other tool which can thus be simulated using virtual platform: - courtesy : `best architect` thats all i know , some others may add better. Regards, Karandeep
  43. 1 point
    Simple answer: no Slightly longer: Since SystemC is really just a methodology using a standardized API to a C++ library, it would rely heavily on users creating their components to have rollback. I have heard rumor of work exploring this goal. Adding this to the standard would fundamentally affect existing implementations.
  44. 1 point
    If you want to guarantee the # of bits, but want speed then you should include <cstdint> or stdint.h (which has become part of the C++11 standard, but has been available for many years). You only have access to multiples of 8-bits, but at least least it's fast. Of course to grab bit ranges you will need to do the standard software masking rather than the convenience of sc_int. sc_int<W> should be used for situations where modeling the exact number of bits will make a difference in the results. For example, if the hardware implementation will have 13 bits and you do arithmetic (addition/subtraction), then sc_int<W> can catch overflow issues. Another example is synthesis of a register, where you need to control size of the hardware. The difference in performance is dramatic. Consider the following code and timing results: { using data_t = int32_t; //< replace this with sc_int<32>, sc_fixed<32,32>, float, etc... data_t result = 1; data_t A = 1103515245; data_t C = 12345; start_timer(); //< Calls a routine to get CPU time using C++11 constructs -- portable for (size_t loop=loop_count; loop!=0; --loop) { result = A * result + C; } cout << "result=" << result << endl; // Ensure compiler doesn't optimize loop out report_time(typeid(data_t).name); //< Calculates final time -- Be sure to filter with c++filt } I saw results for SystemC 2.3.0-ASI --- Jan 6 2014 07:20:27 (on 2.7GHz Intel i7) with no optimization using clang++ compiler: loop_count = 1e8 int took 0.343008s sc_dt::sc_int<32> took 2.01204s double took 0.755805s sc_dt::sc_fixed<32, 32> took 41.3482s With -O3 optimization: loop_count = 1e8 int took 0.125028s sc_dt::sc_int<32> took 0.199671s double took 0.364543s sc_dt::sc_fixed<32, 32> took 25.6714s So be careful what you select AND what compiler options you use. You can view the source code at https://github.com/dcblack/scdataperf
  45. 1 point
    Hi Darrenxu, the code you've written in green won't work because SystemC has no shorthand for a concurrent signal assignment (VHDL) or assign (SystemVerilog). One solution is to write a helper process, e.g. void assemble_proc() { num1_t=num1; num1_s1=num1_t[0]; num1_s2=num1_t[1]; num2_s1=num2_t[0]; num2_s2=num2_t[1]; sum2_t[0]=sum_s1; sum2_t[1]=sum_s2; sum2=sum2_t; } // in the constructor SC_METHOD(assemble_proc) ; sensitive << sum2_2 << sum_st << sum_s1 << num2_t << num1_t; Another solution would be to use sc_vector (available in 1666-2011, Proof-of-Concept simulator 2.3.0). Instead of using sc_uint, you could then create a vector of sc_in<bool> and sc_signal<bool> for instance, and assemble and dis-assemble the vector. kind regards Alan P.S. I am also tempted to say "do it in VHDL or SystemVerilog instead" but that's not very helpful if you're trying to learn SystemC :-)
  46. 1 point
    apfitch

    string directly as input ??/

    Thanks Mohit - I think the error is here: void fifo_write(unsigned char c); Static SystemC processes may not have arguments. You need to remove the argument from the function declaration, e.g. void fifo_write(); regards Alan
  47. 1 point
    apfitch

    b-transport interface

    Regarding your questions about blocking transport... wait(delay) means that the initiator has chosen to synchronise to sc_time_stamp() by calling wait. In the target, the delay parameter represents the time at which the target should consider the request to have been received. In the initiator, the delay parameter contains the time at which the initiator should consider the response to have been received. If you have wait(delay) in the target, it means the target has chosen not to use temporal decoupling and has instead decided to wait to the actual sc_time_stamp() when the request should be received. The delay returned by the target does represent the time at which the response should be considered to have arrived (relative to sc_time_stamp()), which is the time at which the transaction ends. You can think of b_transport as representing a protocol with only two timing points, the time at which the request is sent, and the time at which the response is received. regards Alan
  48. 1 point
    I'd say it does not. Below you can see an example. I tried to attach it. But I am not allowed to. Raul #include <systemc.h> SC_MODULE(Testbench) { sc_trace_file * traceFile; sc_signal<bool> toggle_o; void toggle(); SC_CTOR(Testbench) { toggle_o = 0; traceFile = sc_create_vcd_trace_file("testbench"); traceFile->set_time_unit(10, SC_US); sc_trace(traceFile, toggle_o, "toggle_o"); SC_THREAD(toggle); } ~Testbench() { sc_close_vcd_trace_file(traceFile); } }; void Testbench::toggle() { while(true) { toggle_o = !toggle_o; wait(100, SC_US); } } int sc_main(int argc, char * argv[]) { Testbench testbench("Testbench"); sc_start(500, SC_US); //simulate for 500 microseconds return 0; }
  49. 1 point
    Philipp A Hartmann

    sc_signal<vector<T> >

    Gurunath, Torsten, The "name" parameter needs to be passed as const-reference const std::string&, since the stringstream returns a temporary object which can't be bound to a non-const reference. The "inline friend definition" used by Gurunath does not define a member function. It should work as expected and will be selected via argument-dependent lookup. Greetings from Oldenburg, Philipp
  50. 1 point
    gurunath.kadam

    Deleting dynamic objects

    hi all, Normally, in C++, all dynamically created objects (pointer = new object) are deleted after their use is done to avoid memory leaks. This operation can be carried out in a destructor or special function as well. I have seen many SystemC (done by some experts) codes where such objects are not deleted. Is that not required in SC? Also now I am attempting to create a vector of pointers to objects. Shall I delete these objects later or does SC take care of this (I think SC can not do that)? Thank you.
×
×
  • Create New...