Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 08/13/2019 in all areas

  1. 3 points
    The Accellera SystemC AMS Working Group released the 2020 edition of the SystemC AMS User's Guide. You will find the user's guide on this page: https://www.accellera.org/downloads/standards/systemc This version of the user's guide is fully compatible with the SystemC AMS standard released as IEEE Std. 1666.1-2016. It describes all the features introduced in the SystemC AMS language standard during the last decade. For example, the user’s guide now explains the use of the dynamic timed data flow capabilities, to make AMS system simulations even more efficient and running even faster. The SystemC AMS Working Group is currently preparing the release of the user's guide application examples as separate download. Availability of these application examples will be communicated at a later stage. Please use this forum to post your questions or remarks on the user's guide.
  2. 3 points
    Eyck

    TLM CPU modeling

    There is no such thing as CPU TLM modeling. Usually you write a C/C++ processor model with the needed accuracy (instruction accurate, cycle approximate, cycle accurate) and wrap it in a way that you translate memory accesses into TLM socket accesses. Along with that you need to manage to syncronization of the time of your model and the SystemC time (to run e.g. in loosly timed mode). Another task is to take the returned execution time of the bus accesses into account for the execution of the CPU model. This involves also the selection and implementation of the accesses (DMI & blocking or non-blocking). You can find a complete example of an instruction accurate VP at https://git.minres.com/DVCon2018/RISCV-VP (or https://git.minres.com/VP/RISCV-VP which is a newer version). The wrapper for the C++ model in SystemC can be found at https://git.minres.com/DVCon2018/RISCV-VP/src/branch/develop/riscv.sc/incl/sysc/core_complex.h To put it straight: doing this correctly is a non-trivial task as it is the implementation of a micro-architecture model of a CPU. One option is to build an instruction accurate ISS and add a microarchitecture model like it is done in the ESECS project (https://github.com/MIPS/esesc) BR
  3. 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.
  4. 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.
  5. 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.
  6. 2 points
    Eyck

    sc_clock Doubt

    sc_clock triggers itself based on the period and the (in your case default) constructor settings. The period is the default_time_unit.
  7. 2 points
    You are initailaizing fl_ptr during consturction, not during execution. In generator.hpp you have: float* fl_ptr = reinterpret_cast<float*>(dmi_mem); //ovo sam ja pisao This never updates fl_ptr to the actual value of dmi_ptr. Actually your access should look like: if (dmi_valid) { dmi_mem = dmi.get_dmi_ptr(); //dmi_mem is pointer to ram[] array in memory.h float* fl_ptr = reinterpret_cast<float*>(dmi_mem); for (int i = 0; i != 20; ++i) fl_ptr[i] = 12.7; }
  8. 2 points
    Your sc_trace function is a member function of the TraceList class and cannot be called like the sc_trace functions coming with the SystemC reference implementation. Those are free functions in the sc_core namespace. Moreover your sc_trace implementation is non-static so it cannot be used without a TraceList object. You need to move the function out of the class scope. Basically this is a valid approach to setup complex types. But under performance considerations I would suggest to use a different container. Best choices are std::vector or std::dqueue. And if you are using C++ 11 I would replace the while loop with a range based loop, something like: for(auto& val: var.lst) { // use namespace, compiler otherwise chooses wrong function sc_core::sc_trace(tf, val, nm + std::to_string(pos++)); }
  9. 2 points
    Actually, you can start a sequence in any phase. It is more important to understand the domain/scheduling relationships between the task based (i.e. runtime) phases. UVM undergoes a number of pre-simulation phases (build, connect, end_of_elaboration, start_of_simulation) that are all implemented with functions. Once those are completed, the task based phases begin. The standard includes two schedules. One is simply the run_phase, which starts executing at time zero and continues until all components have dropped their objections within the run_phase. The other schedule contains twelve phases that execute parallel to the run phase. They are: pre_reset, reset, post_reset, pre_config, config, post_config, pre_main, main, post_main, pre_shutdown, shutdown, and post_shutdown. They execute in sequence. Every component has the opportunity to define or not define tasks to execute these phases. A phase starts only when all components in the previous phase have dropped their objections. A phase continues to execute until all components have dropped their objections in the current phase. Many companies use the run_phase for everything because there are some interesting issues to consider when crossing phase boundaries. In some respects it may be easier to use uvm_barriers for synchronization. Drivers and monitors (things that touch the hardware) are usally run exclusively in the run_phase, but there is nothing to prevent them also having reset_phase, main_phase, etc...
  10. 2 points
    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.
  11. 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.
  12. 1 point
    Dave5144

    Guide/Help for Beginners

    I got the examples to build under VS2019 by modifying the visual studio install to use VS 2015 build tools. It's a box you can click under the C++ install options. I also had to delete the previously downloaded systemC folders then re-download them. Build the VS2010 systemc solution first.
  13. 1 point
    Sure. Just add a method reading all bool sc_in and write to the output. You need to make it sensitive to all inputs Something like: SC_MODULE(conv){ sc_vector<sc_in<bool> > input{"input"}; sc_out<bool> ouput{"ouput"}; SC_CTOR(conv){ SC_HAS_PROCESS(conv); SC_METHOD(method); for(auto& in: input){ sensitive<<in; } } void method(){ unsigned res = input[1]?2:0+input[0]?1:0; output=res; } };
  14. 1 point
    Hello @mo_ayman, Well you could get it early for review comments from the people in SystemC LWG. Plus people with similar setup to yours can also take a jab at it in getting it fixed. Regards, Ameya Vikram Singh
  15. 1 point
    You are writing to ports in the constructor of server. At this point they are not bound. Since you initialize them in the beginning of your thread this is not needed anyways. Aside of that you also do not need the sensitivity list for the monitor thread as you never use the default sensitivity (by using wait() ). And if you use C++11 or newer you should use In-class member initializers which eases the naming of signals (and you should name them to make debugging easier): sc_in<bool> begin1{"begin1"}, begin2{"begin2"}, begin3{"begin3"}; sc_in<bool> end1{"end1"}, end2{"end2"}, end3{"end3"}; sc_in<bool> incoming1{"incoming1"}, incoming2{"incoming2"}, incoming3{"incoming3"}; sc_out<bool> free{"free"}, outgoing1{"outgoing1"}, outgoing2{"outgoing2"}, outgoing3{"outgoing3"};
  16. 1 point
    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.
  17. 1 point
    Eyck

    Queue fifo

    Actually you created an array of inputs of type int, not a pipe. Without more code it is hard to give any advise
  18. 1 point
    David Black

    System c help

    For your specific problem just Google "C++ read CSV": https://thispointer.com/how-to-read-data-from-a-csv-file-in-c/ https://www.gormanalysis.com/blog/reading-and-writing-csv-files-with-cpp/ For C++ try: https://www.geeksforgeeks.org/c-plus-plus/ http://www.cplusplus.com/doc/tutorial/
  19. 1 point
    I suggest to move to SystemC 2.3.3, if possible. (The error message indicates, that you seem to be using SystemC 2.3.1). Secondly, can you show the derived class of the fifo as well (including its constructor)?
  20. 1 point
    Eyck

    Debug assertion fails when using sc_trace

    You create 5 signals carrying a TraceVector. Doing so the default constructor is used which does reserve space for elements but has a size of 0... I can't tell where the assertion comes from. For those cases a debugger is pretty helpfull B-)
  21. 1 point
    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; }
  22. 1 point
    Hi. The is_reset method is private. So, you cannot call it on an object. But why are you using is_reset() method? What do you want to achieve? This is not part of the standard API, i.e. it might be dangerous to use. Greetings Ralph
  23. 1 point
    David Black

    How to generate sc_signal at runtime?

    Sc_signals are not data types. Sc_signals are channels, which represent hardware being modeled and are used as mechanisms to transport data between processes. As such, channels are only allowed to be created during the “elaboration phase” that occurs prior to simulation starting up. Also, strictly speaking, sc_port’s are not normal pointers; although, an underlying mechanism uses pointers for efficiencies sake. The operator->() is overloaded on sc_port<IF_TYPE>. You could of course create an sc_vector< sc_signal<T> >, N >, where N was a maximum of the number of signals required and then allocate specific index to each spawned process.
  24. 1 point
    Anton

    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.
  25. 1 point
    Eyck

    HERITAGE on a SC_MODULE with THREAD

    You are defining a thread in ahb_master and a thread in dummy_master where both have the same name (tick) but a different C++ signature (ahb_master::tick and dummy_master::tick). Actually defining the tick thread in ahb_master doesnt make any sense, moreover since it doesn't do anything it will be declared immediately after simulation start. BR
  26. 1 point
    Since you are talking about timing I would stick to a more AT like modeling style using the non-blocking transport functions. In this case you should use a memory manager (see section 14.5 of the IEEE standard). For this you need to implement the tlm::tlm_mm_interface (there a few implementations out there, you may google them). The mechanism works similar to a C++ shared pointer. The initiator always pulls a new transaction from the memeory manager and sends via its socket. Each component dealing with the transaction calls acquire() on the payload and release() once it is finished with it. Upon the last release() call the transaction is automatically returned to the memory manager and can be reused. HTH
  27. 1 point
    No. For analog, SCV has not solid application.
  28. 1 point
    Eyck

    sc_main function for timer in SystemC

    It would be good if you could provide a description of the problem you see (or better error messages or alike) when building the unit. I see 2 things in your code: the statement labeled with '// sensitivity list' tm << START << TIMEOUT << CLOCK; is wrong. You did this already in the constructor (SC_CTOR(timer)) of your module. The sensitivity list of your timer is wrong. The thread should only wait for the positive edge of clock, start is a data signal which is sampled/read upon the rising edge of the clock I suggest to change the implementation from a coding style point of view: add a trace function to your timer module: void trace(sc_core::sc_trace_file* tf){ sc_trace(tf, clock, clock.name()); sc_trace(tf, start, start.name); sc_trace(tf, timeout, timeout.name()); sc_trace(tf, count, (std::string(name())+".count").c_str()); } The module knows what to trace, so in your sc_main you just call tm.trace(tf); usually it is beneficial to put the stimuli stuff into a separate unit. Either a testbench instantiating and wiring your module. Or into a stimuli module where you have at sc_main only the wiring. This increases re-usability. I personally prefer the testbench approach, this unifies sc_main(): int sc_main(int argc, char* argv[]) { // testbench timer_tb tmtb("timer_tb"); // tracing: sc_trace_file *tf = sc_create_vcd_trace_file("RESULT.vcd"); tmtb.trace(tf); // simulation sc_start(); sc_close_vcd_trace_file(tf); return(!sc_core::sc_stop_called()); } The timer_tb has to call sc_stop() once it is finished with stimuli. But this is a matter of taste. BR
  29. 1 point
    Fix published in https://github.com/accellera-official/systemc/commit/5a94360d. Thanks for the report! Greetings from Duisburg, Philipp
  30. 1 point
    You specified a signed number which was converted to unsigned under rules of twos complement. Change “0x to “0xus and you will obtain desired results. See section 7.3 String literals on page 199 of IEEE-1666-2011 for more information.
  31. 1 point
    vrsm

    sc_fifo.read() does not work

    Its because printer input.num_available() non-blocking call which is executed even before fork.output2 is written. Printer input.read() is working fine as it a blocking call which is waiting for fifo to get filled, once fork.output2 is written and fifo have a item now and now read() is unblocked and things are working fine. You cannot predict the thread execution order unless otherwise you are explicitly making them to happen in order. I suggest you keep multiple print statements to see how threads are executed in your simulation. num_available() is not mandatory for any implementation. But the correct way to use num_available in your experiment is, while(fifo.num_available() == 0) { wait(SC_ZERO_TIME); //by calling wait you are giving chance for other threads in simulation to run } cout<<" items in fifo "<<fifo.num_available()<<endl; Ram
  32. 1 point
    SiGa

    sc_fifo.read() does not work

    SC_MODULE(DF_Fork){ sc_fifo_in<int> input; sc_fifo_out<int> output1,output2; void process(){ while(1){ int value = input.read(); output1.write(value); //output1.write(value); output2.write(value); } } SC_CTOR(DF_Fork) {SC_THREAD(process);} }; You never write on output2. Your printer then remains at value = input.read(); since it waits till data is available. Thus the simulation has nothing to do and stops itself. You can read about sc_fifo methods here: http://www.asic-world.com/systemc/channels4.html
  33. 1 point
    I see at least 1 bug in code sample: for (auto val : var.read()) here you create copies of vector elements on a stack of your function. And then pass references to them into SystemC kernel. So those will be dangling references one you return from your sc_trace overload. Change to: for (auto & val : var.read())
  34. 1 point
    Looks like XY problem to me. If you need pointer to event, use pointer.
  35. 1 point
    Roman Popov

    sc_fifo data_read_event

    Did you probably forget to add wait() into consumer thread to suspend it after first read?
  36. 1 point
    In general avoid using multiple inheritance for aggregation. It is possible, but has many drawbacks and no major benefits. Now I regret that I've written original post, but at that time I had no enough experience myself. Now, if we read any object oriented design book, we will learn that inheritance usually means "is-a" relation ship, and "has-a" relation ship is expressed by composition. Translating into HW modeling : what we want to express is that "some_module has port bundles", and not "some_module is port bundles". We can still use single inheritance in limited cases, for example if all modules in design have clock and reset, we can have a common base class like class clocked_module : public sc_module Back to your example. I recommend to convert your port bundles into modules: struct if_inputs : sc_module { sc_inout<sc_uint<4>> SC_NAMED(R_OP_MODE); sc_inout<sc_uint<8>> SC_NAMED(R_PRESET_MANUAL); if_inputs(sc_module_name){} }; struct if_outputs : sc_module { sc_inout<sc_uint<2>> SC_NAMED(T_BIT); sc_inout<sc_uint<4>> SC_NAMED(T_OP_MODE); sc_inout<sc_uint<8>> SC_NAMED(T_PRESET_MANUAL); if_outputs(sc_module_name){} }; And now you can aggregate any number of them inside monitor. Even have a vector of port bundles: class monitor : public sc_module { public: if_inputs SC_NAMED(sim_inputs); if_outputs SC_NAMED(sim_outputs); if_inputs SC_NAMED(stub_inputs); if_outputs SC_NAMED(stub_outputs); sc_vector<if_inputs> SC_NAMED(inputs_vector, 3); monitor(sc_module_name name_); private : // implementation details };
  37. 1 point
    Since it seems this is not a interesting topic just in case someone is looking for information I came across these papers http://www.verilab.com/files/litterick_register_final.pdf basically claims that factory registration of registers should be avoided to get better performance results Common issues and pitfalls
  38. 1 point
    Because dynamic linker does not know where to find library. You have two options: use -Wl,rpath,<path/to/lib> command line option at compile time, or set LD_LIBRARY_PATH environment variable. Google for more details.
  39. 1 point
    e.notify(); // immediate notification is executed "immediately" - Thread2 added to set of runnable processes e.notify(3,SC_NS); // e added to kernel event queue, it will be triggered in 3 ns e.notify(3,SC_NS); // e added to kernel event queue to be triggered in 3 ns e.notify(); // previous notification canceled, and instead event is notified immediately, Thread2 added to set of runnable processes
  40. 1 point
    Eyck

    bind multi ports to other port.

    Another option would be to use a resolved signal and connect all output ports to it. But this is already about techincal implementation options. The question to me is: what would you like to model? Is this the right way to model the intend? Best regards
  41. 1 point
    What do you mean exactly by "modeling a register"? If you are working on synthesizable code (i.e. using Mentor/Cadence HLS tools), then it is not possible to have 0-delay communication between threads in synthesizable code, as you wanted in original post. At least it was not possible last time I've used these tools. If you are working on some non-synthesizable high-level model, then you can model "register" any way you like, you don't even have to use sc_signal<> for that purpose.
  42. 1 point
    Unfortunately I'm not with a member company. I was hoping that I'd have read permissions regardless of my current affiliation. As a user I'd like to see the connection between discussions in the official forum, the issues reported to the issue management system, and the code being developed in response to that. The ability to immediately test that code and possibly give feedback as code comments or a pull request. More like Github, Gitlab and other platforms. Seems to me that this would be a more efficient way to give and get user feedback.
  43. 1 point
    Are there any plans on continuing using the GitHub repository for such releases or has it been discontinued?
  44. 1 point
    sas73

    UVM Library Test Suite and Git Repository

    Thanks David. It sounds like no such tests are available. Open source projects in general are not always good at providing their test suites but I find it a bit odd that on open source library for verification doesn't provide the test suites showing how the library itself is verified. It would be easier for people to suggest improvements if they can verify whether or not such a modification breaks something else.
  45. 1 point
    David Black

    serial transmission

    [I assume that when you say "TLM", you mean SystemC TLM 2.0.] You need to understand the difference between modeling styles. TLM is precisely about not modeling at the level of RTL. The SystemC TLM 2.0 also has two different modeling styles: Loosely Timed (LT) and Approximately Timed (AT). Let's look at each using a specific case. Suppose you are modeling two UARTs operating at 9600 baud (bits per second) with 8-bits, no parity, and 1 stop bit to transfer the message "Hello World\n". This configuration results in 960 characters per second (1.042 ms/char), which is quite slow, so probably you would be transmitting/receiving characters slowly enough that most systems would either process them one at a time or provide a FIFO (e.g. 16 bytes) and only process empty/full events. There is one more question to answer though. Consider the diagram below. The connections between sender to UART and UART to receiver are clearly memory mapped for most systems. So there is no question of modeling. The connection UART to UART is not memory mapped, which means you need to create a custom protocol. Furthermore, for TLM, it actually requires to connections since communication can be invoked bi-directionally (for a full UART). You need to decide what is important to model. For a high level model and efficiency, I would either transfer as much data as I could. It might even make sense to use TLM 1.0 rather than TLM 2.0. Do you have the requirement to inject errors? For my example, you would configure the transmitter, and then transfer a burst of 12 characters into the transmit FIFO on one end of the transfer and generate an empty FIFO interrupt at 12.5 ms later. The receiver side would be similar. What about the UART/UART transaction? An efficient approach might be as follows: Create a required extension that carries the transmit configuration information (baud rate, bits, parity, etc.) Use TLM_WRITE_COMMAND because all transactions over this socket pair are initiated from the sender. The second pair in the opposite direction would do the same thing. Check and insist that the address always be 0 and the streaming width is 1. Byte enables would be illegal. Check that the configuration matches before accepting data. Place all received data into an unbounded queue and then indicate the size allowed by the hardware model. Send interrupts using the sc_signal when the received queue goes non-empty. Consider the error situation when the timing indicates characters would be lost due to FIFO full and timing of characters. You will have to decide how to deal with interrupts received in your thread process. Notice that I do not model at the bit level. If you wish to add bit-level error injection, then inject errors at the point of transmission.
  46. 1 point
    @daveW you can tryout the SystemC 2.3.2 draft release which fixes most of the issues while building under C++11/C++14 compilers. Have a look here: Regards, Ameya Vikram Singh
  47. 1 point
    apfitch

    Inter modules communciation

    I guess the main advantage of using SystemC is that ports/modules/channels give you a standard approach. Even if you don't care about time passing, you may well care about the order that things happen in, and then events and time are still useful. Also of course you get a ready to use threading library and scheduler. The disadvantage might be simulation speed compared to pure C++. And of course you have to learn SystemC. The main advantage of C++ is that you can do exactly what you want (you're free!) The main disadvantage of C++ is that you can do exactly what you want :-) (You're re-inventing the wheel) regards Alan
  48. 1 point

    177 downloads

    hi, this is the source code for the interface registry along with 3 examples and the paper/ppt from dvcon2015 illustrating the package. The package itself provides a simple scheme to connect DUV and TB using bind, interface self registration and a database. regards /uwe
  49. 1 point
    apfitch

    user defined data type signal assignment

    Hi Zarie, that's what I meant by "you must wait a delta". If no time passes, a primitive channel does not update. Kocha's solution will work (adding a call to sc_start - in fact even sc_start(SC_ZERO_TIME) should work. regards Alan
  50. 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...