Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 06/06/2020 in all areas

  1. 1 point
    AFAICS you don't increment the index i in the while loop. But your code is way to complex.: std::ifstream ifs("TEXT.txt"); if(ifs.is_open()){ int buf = 0; for (int i = 0; i < MEM_DEPTH; i++) { ifs >> buf; buff_1[i]=buf } } ifs.close(); should replace everything from fopen() until fclose(). And you should avoid using macros, they will bite you. '#define MEM_DEPTH 20' should become 'const size_t MEM_DEPTH=20;'.
  2. 1 point
    David Black

    A weird question about UVM

    UVM is all about reuse. Reuse has several different aspects: Reuse of an engineers knowledge -- those experienced with UVM can usually jump onto an existing or new UVM project with very little ramp time. I have seen some verification environments using their own methodology that literally took months for new engineers to come up to speed on. Mind you misuse of UVM can lead to the same conclusion if you don't stay within the standard itself. Reuse of verification components -- means you can reuse a UVM environment without editing a single line of code provided by that environment. This is huge. It is possible to purchase UVM components that test standard interfaces (e.g., 1G Ethernet) and not have to create the code yourself. It still requires the expertise to plug the component into your environment, but it is relatively easy to do. UVM also means application of a tried and tested methodology rather than role your own. Downsides to UVM include: UVM is fairly complex and to get the most out of it generally requires training UVM is fairly large as a body of code and has a lot of boilerplate code Bottom-line: You don't have to use UVM to verify your code, but if your designs are large enough, it seem crazy not to adopt it. You can hire employees and contractors that know how to do leverage UVM and purchase components to shorten your design task. For small/tiny designs, it may not make sense.
  3. 1 point
    Eyck

    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/)
  4. 1 point
    David Black

    Determining change in signals

    module who_changed_first(input a, b, start); always @(posedge start) begin byte changed; fork @a changed = "a"; @b changed = "b"; join_any case (changed) "a": work_1; "b": work_2; endcase end Assumes SystemVerilog. If Verilog you will need to add . See https://edaplayground.com/x/2NXz for example code.
  5. 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.
  6. 1 point
    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.
  7. 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; } };
  8. 1 point
    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
×
×
  • Create New...