Jump to content

apfitch

Members
  • Posts

    613
  • Joined

  • Last visited

  • Days Won

    118

Everything posted by apfitch

  1. The error message is complaining about this line: #include <systemc-ams> and says it can't find the systemc-ams. I imagine there is a variable in the Makefile that points to the SystemC AMS code, and the code isn't where the variable points. That Makefile variable may also depend on an environment variable, and perhaps that environment variable is not set? regards Alan
  2. Can you post the code with the SC_METHOD? Alan
  3. wait() is synthesisable if you write in the correct style. Have a look at the Draft Synthesis Guidelines on the Accellera website, section 4.2 regards Alan
  4. Use the c++ standard template library - SystemC *is* C++ Alan
  5. Just as an aside, you can also use the %p formatter to display enumerated types (and pretty well anything else), e.g. $display("Verbosity is %p", m_rh.get_verbosity_level() ); The disadvantage of %p compared to Tudor's string is that %p tends to print things out more verbosely (ironic in this case!) regards Alan P.S. You might have to cast m_rh to the type of the verbosity level in that context.
  6. If you put a delay in b_transport that would represent the processing time of that part of the system you are modelling using b_transport, regards Alan
  7. In module "data_path" you've declared a function process() which is never called. I guess you forgot to register process() as an SC_METHOD and make it sensitive to bus? Alan
  8. Why not post the error message? Anyway, using to_int() looks bad to me, you don't want negative addresses. You should use to_uint(), regards Alan
  9. The error message seems to be saying that you have a tlm_initiator_socket instanced in i_top? From your description in the previous message, that sounds wrong, I thought you were saying that in i_top thee is just an instance of the testbench and the model. Alan
  10. In the original message I've realised it's probably referring to class B (as it mentions the initiator socket). So have you bound the export to *this in class B, the class with the initiator socket? regards Alan
  11. Yes, but I'm just speculating that it might help! Alan
  12. I don't know if your threads have to be SC_THREADs (i.e. if they have to wait) but if they don't, you could spawn SC_METHODs instead. The other thing that might be worth trying is to explicitly kill the threads when they are no longer needed. I've no idea if that will help, but perhaps it might cause the kernel to properly remove the threads? regards Alan
  13. It might just be the stack of the program - are you declaring any large arrays? It might help to replace them with dynamically allocated memory if you are. Also are you allocating the modules on the stack? I would try to use dynamic allocation wherever possible and see if it helps. Also are there any limits on your OS - try using ulmit or limits to find out, Alan
  14. Are you binding the sockets to the classes they're instanced in? You need to bind the sockets so that the exports can export the interfaces of the classes, If you could show more of class A (including the constructor and the socket declaration), that would help, regards Alan
  15. I think the problem is you have used int. This makes the constraint solver work very hard as you are asking it to search through combinations of 64 bits to find a solution. Try this: struct addr_constraint: public scv_constraint_base { scv_smart_ptr<sc_uint<8> > row; scv_smart_ptr<sc_uint<8> > col; SCV_CONSTRAINT_CTOR(addr_constraint) { SCV_CONSTRAINT( (row() *col()) < 50); SCV_CONSTRAINT( col() > 0 ); } }; Regarding the operators, refer to the document vwg_1_0e.pdf in the docs directory, at the bottom of page 34 and the top of page 35. regards Alan
  16. I suggest Google, which came up with this: http://stackoverflow.com/questions/6832272/compatibility-issues-when-upgrading-a-c-project-from-vs-2005-to-vs-2010-expre I've no idea if this is the answer, but it might be worth a try, regards Alan
  17. It's just more complex to implement. Each thread has to have a state that is stored and restored at each resume after the wait. With an SC_METHOD, it's just a C function call and there is no state to remember, Alan
  18. Yes wait is relatively expensive. In SystemC TLM modelling a lot of effort was put into minimising the number of waits (using the concept of a time "quantum" for Loosely Timed modelling), but of course it makes the code much more complex to write and understand. Sometimes it's possible to work out what order the steps of an algorithm should take, and then simply write a program that executes in a well-defined order without using any threads - but the you could write that in plain C++, regards Alan
  19. Hi Arya, I missed your questions above - according to the paper by Martin, the UVM-SC reference implementation should be available "later in 2015". So expect it by 23:59 on 31st December :-) I don't think UVM-SC is meant to replace SCV - but you could ask in the Verification Forum, or join the VWG as an observing member and ask. To Dinesh - UVM-Connect is open source - but of course you need a SystemVerilog simulator with class/randomization/DPI support to use it, for which you'll have to pay. So you need EDA tool support for the SV part of UVM connect. Regarding UVM-SC, the reference implementation is due "later in 2015" To Ruchir - regarding functional coverage, yes if you specify functional coverage properly, you should not have coverage holes at RTL or at TLM level. But functional coverage models are written by engineers, so if you write a functional coverage model which doesn't correctly cover all specification points of your design, you can have a problem. (Compare that to code coverage where you can easily measure how much you have coverage you have achieved). However I was probably thinking more about the issue that the designer and the verification engineer both independently interpret the specification to build the DUT and the reference model independently - so when they are brought together to verify the RTL, it is conceivable that either the designer or the verification engineer or both could find bugs because they have both interpreted the spec independently, regards Alan
  20. Sorry for posting this here, but I can't figure out how to log in to or register for the SV Mantis, so I hope posting here will get to some of the right people... In table 22-2 in 1800-2012, the keyword "instance" is missing, regards Alan
  21. Hi Arya, the verification forum is alive - it's just very new. So I would recommend also asking your question there. You might want to look at UVM-SC (SC implementation of UVM) which is the draft phase. There's a presentation about it on the Accellera website by Martin Barnasconi. People have also attempted to do formal equivalence checking between high level and low level - Calypto Design Systems had a tool called SLEC from memory. I guess at the moment the most popular route is to verify RTL re-using the TLM SystemC as a reference model - but of course that could result in bugs being found in the TLM model as well as in the RTL, regards Alan
  22. By the way, sc_bit was deprecated in 1666-2005 (10 years ago!) so it's preferred to use bool, regards Alan
  23. The simplest way is to write a process (SC_METHOD) to copy the values across, e.g. SC_METHOD(copier); sensitive << bus; void copier() { myreg = bus.read().range(11,0); } Alternatively have a look at the sc_vector introduced in the SystemC 1666-2011 standard, which was introduced to solve this kind of problem, regards Alan
×
×
  • Create New...