Jump to content

Leaderboard


Popular Content

Showing content with the highest reputation since 06/15/2020 in Posts

  1. 1 point
    Silly me, I was quite mistaken in my simple solution (and it only took me a few minutes after posting to realize it); however, this exercise reminded me of a 2011 feature: reset. This works for SC_METHOD processes, but is inconvenient for SC_THREADs. I enjoyed working the puzzle. You can see a full working example here: https://www.edaplayground.com/x/39QM Outline: When registering your SC_METHOD process capture the process handle and specify dont_initialize(). At the start of your method implementation, check for the trigger state of reset_event and return immediately if triggered. To reset static sensitivity, simply issue reset on the process. Include a comment that you are simply interrupting. Note 1: This assumes you are using a version of SystemC 2.3.3 or later. If using 2.3, you will need to add a bool flag that is set at the time of invoking reset and cleared inside the process upon detection. Note 2: You could also use reset_signal_is(); however, that would require adding deassertion and would be messier in my opinion. An alternate and less intrusive method would be to simply add an interrupt event into the sc_event_or_list every time you change sensitivity: next_trigger(some_event | interrupt_event); next_trigger(time_delay, interrupt_event); Unfortunately, this doesn't work for sc_event_and_list; however, you can synthesize that situation with another process. I will leave that for you to figure out.
  2. 1 point
    Stephan Gerth

    UVM-SystemC 1.0-beta3 released

    UVM-SystemC 1.0-beta3 was released for public review. Download available at https://www.accellera.org/downloads/drafts-review. Notable changes since 1.0-beta2: Register API Bugfixes & SystemC 2.3.3 support Ubus example Automatic objection mechanism
  3. 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;'.
  4. 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.
  5. 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/)
  6. 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.
  7. 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.
×
×
  • Create New...