Jump to content

manikanta.mashetti

Members
  • Content Count

    20
  • Joined

  • Last visited


Reputation Activity

  1. Like
    manikanta.mashetti reacted to David Black in Can we write RTL(Register Transfer Level) using SystemC?   
    Simulators that support languages such as SystemVerilog and VHDL are optimized for working with RTL; whereas, SystemC is simply a C++ program with no special optimizations. Thus SystemC will run much slower for RTL simulation than the other languages. If you have a really large RTL simulation, this could become problematic. For small designs it is no issue.
     
    For example, RTL has lots of processes sensitive to a clock edge to model flip-flops (registers). Optimized simulators will combine all of this code into a single process; whereas, SystemC will result in many processes and many context switches.
     
    Of course somebody could write a SystemC optimizing compiler, but to date nobody has.
  2. Like
    manikanta.mashetti reacted to manikanta.mashetti in Can we write RTL(Register Transfer Level) using SystemC?   
    Hi ,
     
    Recently I have studied that SystemC can be used To model High level functional models to detailed clock cycle accurate RTL models.
     
    If any company done like this then the they can save the time and energy too. Because at different levels we are using the same language.
     
    But as of my knowledge many companies uses SystemC at system Modeling only.
    Why they are not using the same language at RTL instead it has many advantages. ?
     
    Please clear this doubt
     
     
     
     
    Thanks,
    Mani
  3. Like
    manikanta.mashetti reacted to apfitch in Can we write RTL(Register Transfer Level) using SystemC?   
    This thread might be useful : http://forums.accellera.org/topic/1354-why-systemc-and-who-uses-it/
     
    regards
    Alan
  4. Like
    manikanta.mashetti reacted to David Black in Why you use systemC / should i learn systemC?   
    [WARNING: The following is philisophical]
     
    Assembly language programmers felt the same way about high level languages like FORTRAN.
    Functional programmers (e.g. C) felt the same way about object oriented languages.
    Schematics were the way of things for many engineers until RTL showed up.
    Verifying a design by occular inspection waveforms was replaced by self-checking testbenches with some resistance.
    Verification using directed test was mainstream and constrained random with functional coverage was resisted for many years. The advantages of reuse and scalability of the new techniques has slowly changed many.
     
    Engineers and programmers facilitate change, but themselves are some of the most resistant to change when it affects their own world.
     
    I think it's inevitable. As complexity increases, we have to find new ways to deal with it, and abstracting upwards is the way of things.
     
    One way to deal with change is to decide not to let the new ways master you. Instead read books, take classes and become a master of the new technology.
     
    Sadly, many universities have not caught up with modern practices at the undergraduate level.
  5. Like
    manikanta.mashetti reacted to Philipp A Hartmann in cycle delay concept   
    In case you've found a solution to your question all by yourself, please consider adding an answer with your findings instead of emptying out your previous post.  This way, all users can benefit in the long run.

    Thanks,
      Philipp
  6. Like
    manikanta.mashetti reacted to David Black in Tracing internal signals declared in sc_module using sc_trace   
    Manikanta's solution assumes temp is public. If not public, you can take the opposite approach and simply call sc_trace from within the module itself. You could even do it conditionally based on run-time command-line arguments:
      
    sc_core::sc_trace_file trace_file = 0; //< initialize to indicate not open top::before_end_of_elaboration() {    for (int i=1; i<sc_argc(); ++i) {       if ( trace_file == 0 && std::string(sc_core::sc_argv()[i]) == "-trace" ) trace_file = sc_core::sc_create_vcd_trace_file("your.vcd"); }//endfor } top::end_of_simulation() {   if ( trace_file != 0 ) sc_core::sc_close_trace_file(trace_file); } ... extern sc_core::sc_trace_file trace_file; void dut::end_of_elaboration() {   if (trace_file != 0) { sc_core::sc_trace(trace_file, temp,"temp");   } }  
    Of course I am assuming fp is made public as shown, and that you have opened it before end of elaboration:
  7. Like
    manikanta.mashetti got a reaction from CliffordPersechino in Why systemC?   
    Hi,
     
    I have some doubts regarding systemC, please help me 
     
     
    What are the main advantages of systemC compare to the other modelling languages?
     
    why architects choose this language ?
     
    In the Behavioural Modelling how ever we are implementing the functionality using systemC, with this model we can move from netlist to GDSII, but this model is not used for synthesis, and we are again writing the RTL coding and move to the futher steps, why?
     
    Why many companies are not using SystemC?
  8. Like
    manikanta.mashetti reacted to Philipp A Hartmann in Type casting && Floating point nos.   
    char is a datatype to represent a single character.  There is the std::string datatype for strings C++, which should be used in SystemC as well.
     
     
    There is no explicit support for these conversions provided by SystemC already.  In the proof-of-concept implementation provided by Accellera, there are the (non-standard) classes sc_dt::scfx_ieee_(double/float), which define bitfields for the individual parts of a float or double type.  With this, you should be able to do the conversion in terms of a concatenation (beware of endianness).  The following is untested:
    double d = ...; sc_dt::scfx_ieee_double id(d); // convert to IEEE 754 bitfield // prepare parts bool sgn = id.negative(); sc_dt::sc_uint<11> exp = id.exponent(); sc_dt::sc_uint<53> mnt = ( sc_dt::uint64( id.mantissa1() ) << 20 ) | id.mantissa0(); // concatenate parts to bitvector sc_dt::sc_bv<64> bv = ( sgn, exp, mnt ); The reverse conversion is left to the reader. ;-)
     
      C++ provides float and double datatypes already.  Usually, C++ implementations follow the IEEE 754 representation internally.  There is no explicit separate SystemC datatype for IEEE 754 floating point numbers.  You can convert sc_fix(ed) numbers via the to_float and to_double member functions.  
    Greetings from Oldenburg,
      Philipp
×
×
  • Create New...