• Content count

  • Joined

  • Last visited

About apfitch

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

427 profile views
  1. I guess first you'd need to add an attribute (extension) to the generic payload to represent the priority. Then you could write a variant of the PEQ which takes into account that priority. regards Alan
  2. For that kind of modelling you probably need resolved types, e.g. sc_signal_resolved, sc_in/out resolved. These types model signal strength resolution, i.e. if you drive two values such as '1' and 'Z', '1' will be the resulting value because '1' is stronger than 'Z'. Have a look at the SystemC standard 1666-2011, especially section 6.13.5 where there's a little example that might help, regards Alan
  3. Could you post your code? regards Alan
  4. Have a look at this thread regards Alan
  5. Hi Jean-Claude, one option would be to create an a process sensitive to each event, and then in that process assign (or perhaps toggle the value) of an sc_signal<bool>. You can then make a process sensitive to all the boolean signals, and find out which signal changed by calling the signal's event method. It's a bit messy, but it would work. You could combine the process, the event, and the boolean signal into a hierarchical channel (perhaps using sc_event_queue for guidance), regards Alan
  6. Hi, your approach seems odd to me. If I were you, I would re-write the C++ model to be more synthesisable. I would go back to your HLS vendor and say "what do I need to do to my algorithmic model to get good results? You seem to be taking the approach of using HLS, then re-writing the generated RTL code, which sounds like a very long-winded design flow, regards Alan
  7. It's not apparent what type mod_name and reg_name are. But if they're the SV string data type, you can use mod_name.to_lower(), Alan
  8. Ok, as Roman says above, it's hard to help without the source code. This might be obvious, but if you can't post the code, I would try the following 1. Try the same code on a different compiler and/or OS 2. Try to narrow down exactly what line of code is causing the problem by commenting out code until the problem disappears 3. Try setting breakpoints progressively further in the simulation until you can set a breakpoint just before the failure regards Alan
  9. You can't concatenate ports like that - the concatenation operator is not defined for ports, it's defined for data types such as sc_uint, sc_bv, sc_lv. The best solution is probably (as you hint) to introduce a separate SC_METHOD. If you don't want to use a separate SC_METHOD, you might be able to do what you want using sc_vector - good luck! Alan
  10. Ah, that's not a SystemC or C++ error, that's an Eclipse error - you might have to post to an Eclipse forum or hope that someone here uses Eclipse. Or try Google, which finds this: http://stackoverflow.com/questions/8148235/eclipse-cdt-shows-semantic-errors-but-compilation-is-ok regard Alan
  11. Please can you post the syntax error? thanks Alan
  12. I'm not sure, but try moving -luvm-systemc before -lsystemc Alan
  13. The error message implies that you are calling wait() in your SC_METHOD - that's not allowed, wait() can only be called in SC_THREADS, regards Alan
  14. I'm not really sure, but I'd guess that because you're making an sc_vector of ports, you need to obey the rules for ports. In particular, ports can only be instantiated during elaboration - by calling init() during a process, I think you're creating ports after elaboration. Can you try putting the call to init() into the before_end_of_elaboration() callback instead? Actually I'm not even sure that will work, but I think that's the underlying problem, the ports haven't been created at the point you're trying to bind them, Alan
  15. I think it might be vcs -V Alan