Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 04/22/2019 in all areas

  1. 2 points
    David Black

    Heartbeat, clock and negedge

    You can use it however you like. We didn't use it everywhere and I'm sure there are more areas where it might be applicable. The main point is that "Performance is a function of simulator CPU activity and how well it used." In some cases such as clocks, there is a lot of activity that goes unused. Many designs really only use the positive edge of the clock. In some designs, the activity can even be reduced significantly. Another instance is timers that often are only touched when they are set up and timeout after N clocks. The RTL approach to modeling a timer decrements the timer value on every clock. A behavioral approach would be: void set_timer( int N ) { assert( N > 0 ); delay = N * clock.period(); setup_time = sc_time_stamp(); projected_time = setup_time + delay; timeout_event.notify( delay ); } The current value of the timer can always be had with: int get_timer_value( void ) { return ( projected_time - sc_time_stamp() ) % clock.period() ); } So you really don't even need the clock in many instances. Instead replace clock.period() with a simple constant. Fast and smart SystemC models don't use sc_clock at all.
  2. 1 point
    From SystemC standard: SystemC requires that you add sc_module_name as a parameter to module constructors, like this: MULT(sc_module_name, int var_a, int var_b); MULT(sc_module_name); This is a hack that allows SystemC kernel to track lifetime of constructor.
  3. 1 point
    Eyck

    why is,what is, and how is tlm used ?

    Hi, TLM2.0 is used to model bus-like transactions as you have in APB, AHB, AXI or alike. It abstracts those transactions in to e.g. read and write with some attribites (liek protection and alike). This saves some from dealing with bit wiggling and, as you have less events, improves simulation performance. If you use in your scenarion fifo between your producer and consumer you are already using TLM as you abstract the transmission of more or less complex data as a write into the fifo. If you keep this style in your design you do transaction level modeling (TLM). If you are asking if it makes sense to use the TLM2.0 standard is a different question and depends on what aspects of your design do you need to represent in your model. If you have some kind bus structure (e.g. some micro processor or controller) then it is highly advisable to use TLM2.0. In that case your producer calls the transfer functions of the initiator socket and your consumer needs to react on the callbacks of the target socket. Actually this does not relate to your file structure but as a starting poitn I would suggest to study the lt example comign with the SysetmC distribution. You will find it under examples/tlm/lt, it contains 2 initiator_top mdouels, a bus and 2 lt_target modules. if you reduce the thing to just one initiator_top and one lt_target being directly connected you have your producer/consumer scenario. HTH
  4. 1 point
    SDeepti

    d flipflop output

    No, you need to have loop with the function registered as SC_THREAD. For your code, it will be: void d_operation() { while(1){ if (reset.read()==1) { d_out = 0; // std::cout << "reset= " << reset << "...din= " << d_in << ".....d_out" << d_out << std::endl; } else { //d_out.write(d_in.read()); d_out=d_in; // wait(1, SC_NS); // std::cout << "reset= " << reset << "...din= " << d_in << ".....d_out" << d_out << std::endl; } wait(); } }
  5. 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.
  6. 1 point
    SDeepti

    d flipflop output

    You have registered d_operation() as a thread. Ideally a thread should have an infinite loop and a wait(). Adding that, you can see changes to your d_out. Also, how about having another thread that does the reset job?
  7. 1 point
    Xilinx HLS tools have very limited SystemC support, you should probably code your FFT in pure C++.
  8. 1 point
    You paint a very bleak and incorrect picture of the HLS tool. I will suggest that you need to get some training on its use. Xilinx have many examples and their documentation is quite good. Document UG902 clearly documents the HLS math library which supports all manner of synthesizable operations. For instance: Trigonometric Functions: acos, atan, cospi, acospi, atan2, sin, asin, atan2pi, sincos, asinpi, cos, sinpi, tan, tanpi Hyperbolic Functions: acosh, asinh, cosh, atanh, sinh, tanh Exponential Functions: exp, exp10, exp2, expm1, frexp, idexp, modf Logarithmic Functions: ilogb, log, log10, log1p Power Functions: cbrt, hypot, pow, rsqrt, sqrt Error Functions: erf, erfc Gamma Functions: lgamma, lgamma_r, tgamma Rounding Functions: ceil, floor, llrint, llround, lrint, lround, nearbyint, rint, round, trunc and that's only a few. Perhaps your grasp of C++ and what can or cannot be synthesized is limited. For instance, dynamically allocated memory is forbidden because it is not reasonable to expect silicon to grow new logic during operation. Please read the fine manual (RTFM).
  9. 1 point
    maehne

    Making a port optional

    If you don't use the member functions added that were added for convenience to `sc_in`, `sc_out`, and `sc_inout` to, e.g., call `read()`, `write()`, and the event member functions via the `.` operator than via the corresponding member function in the interface accessed via the `->` operator, you might be able to avoid entirely the derivation of new port classes. Instead, you could simply use a template alias, which was introduced with C++'11: template<typename T> using sc_in_opt = sc_core::sc_port<sc_signal_in_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; template<typename T> using sc_inout_opt = sc_core::sc_port<sc_signal_inout_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; template<typename T> using sc_out_opt = sc_core::sc_port<sc_signal_inout_if<T>, 1, SC_ZERO_OR_MORE_BOUND>; If you want to also provide all member functions of `sc_in`, `sc_out`, and `sc_inout`, you will have to derive from the `sc_port` class and implement the full interface as defined in IEEE Std 1666-2011.
  10. 1 point
    I gave it a shot locally and noticed that there are indeed quite some compiler warnings due to differences between __declspec(...) and __attribute__((visibility(...))). Most of these warnings can be ignored for now, but are certainly annoying. Additionally, you need to explicitly mark the following with SC_API as well: // src/sysc/communication/sc_port.h template <class IF> class SC_API sc_port_b template <class IF> class SC_API sc_port // src/sysc/communication/sc_prim_channel.h class SC_API sc_prim_channel_registry // src/sysc/communication/sc_signal.h template< class T, sc_writer_policy POL > class SC_API sc_signal_t template< class T, sc_writer_policy POL > class SC_API sc_signal // src/sysc/datatypes/sc_proxy.h template <class X> class SC_API sc_proxy // src/sysc/datatypes/sc_proxy.h extern "C" SC_API int sc_main(int argc, char* argv[]) // src/sysc/utils/sc_temporary.h template<class T> class SC_API sc_vpool For compiling SystemC itself with -fvisibility=hidden, some further changes to the .cpp files are needed. And some of the above changes might break the Windows DLL support. But for me, the above changes work with the examples in the SystemC distribution (i.e. "gmake check CXXFLAGS='-fvisibility=hidden"). Long story short: The feature to SystemC build models with limited symbol visibility will require more changes and testing. I will forward this topic to the Language Working Group for further discussion.
  11. 1 point
    But even this won't fix your error. Because compiler will still complain about assigning sc_logic to double, even if it is in always false branch. What you need is if-constexpr and std::is_same if you have C++17. Or SFINAE, if you don't. Something like this may work: if constexpr (std::is_same_v<T, sc_dt::sc_logic>) { out = SC_LOGIC_Z; } else { out = 0; }
  12. 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
  13. 1 point
    Hi. This is because an unbound port cannot be read. A port forwards all read and write calls to the actual interface (signal) it is bound to. In you module constructor, you are still in the model set up and elaboration phase. The port is not yet bound to any signal. Hence, you cannot read from it. Accessing ports should not be done befor end-of-elaboration. Greetings Ralph
×