Jump to content

apfitch

Members
  • Posts

    613
  • Joined

  • Last visited

  • Days Won

    118

Everything posted by apfitch

  1. No, there is no way of finding out. You could re-write your code to use sc_signal<bool>, which has an event() method to determine if the signal was triggered. regards Alan
  2. You have to bind each port in turn i.e. bind port 0 to 0, 1 to 1 etc. Your arrays need to be size 2, i.e. sc_signal<bool> timing[2], sc_in<bool> Timecal[2] and so on. The sc_vector class is intended to help with this issue (that is binding multiple elements of an array in one call) regards Alan
  3. Yes, you've connected the signal timing twice times. That's not allowed with the default options for sc_signal. You can declare two signals, e.g. sc_signal<bool> timing[2]; and then bind timing[0] to the first module, timing[1] to the second. You then need a port sc_in<bool> TimingIn[2] on the timer, and to make the process sensitive to both TimingIn[0] and TimingIn[1]. regards Alan P.S. If this alls seems a bit tedious, you use the sc_vector class (look in the LRM); or, as I always say for this type of code - write it in VHDL instead :-)
  4. Hi, can you post just the code in sc_main? Copy and paste it exactly as written please. kind regards Alan
  5. Hi Al, yes you can of course use just a C++ compiler - but as I say there are areas that are perhaps "less" standardised such as control/config. Regarding Microblaze, I know Xilinx have a qemu model for the Zync platform - and they definitely have a Microblaze quemu model as part of the Petalinux distribution. So it might be worth looking at that as well (though no TLM wrappers there, unlike OVP) regards Alan
  6. Hi, I saw your question here and on comp.lang.vhdl, and I'm not sure it's easy to answer - which is probably why no-one's attempted to answer. I don't know much (well, anything) about NAND flash. So I can't really comment on whether your proposed project is too naive. But I'll attempt to give some pointers on the things I do know about. Firstly, regarding learning SystemC and TLM. If you have a good background in e.g. VHDL or Verilog, and also have a good background in C++ and object-orientated concepts, then SystemC is (in a sense) "just another class library". If however you don't have background in OO or C++ that would be the first place to start. I used to work for Doulos, and when I was there (and it's probably still true, but check the website for details), we had a "c to c++" conversion course in 2 days, followed by 3 days SystemC (including an intro to TLM), followed by a full 3 days TLM. So perhaps nominally 2 + 2+ 3 = 7 days training. If you know c++/OO you could skip the c->c++. The question then is can you teach yourself enough SystemC to just focus on TLM? It's hard to say without knowing your background. If you look at your proposed project, the first thing to decide is what level of modelling detail you want. In TLM standard terms "loosely timed" vs "approximately timed". If you only need LT, TLM is reasonably straightforward - though getting your head round the time quantum needs some thought. If you need approximately timed, there is a lot of detail to understand assuming you want to be able to write your own AT peripheral. So the next question, is do you need to write your own peripherals? If you do, you need the detail (either LT or AT). If you don't i.e. you really are going to attempt to plug together existing items, then perhaps you only need the concepts. If you are going to attempt to "plug and play", the next question is whether to use a proprietary tool to do that (e.g. from Mentor, Synopsys, Cadence etc). And if so, do the models you need exist? If you're going to grab stuff from the internet and plug it together, then you might find that you need to address issues that are addressed by those tools, but that aren't currently standardised (e.g. control and configuration of your model, extracting and recording performance results etc.). Finally, I would take a step back and try to identify what the problem is in your existing projects - was it really the lack of a tool to analyse architecture? Or was it perhaps a tendency to start designing too early :-) Sorry this is vague, but perhaps it gives you some help. If you're interested in a relatively straightforward loosely timed TLM example, the app note on the Embecosm web-site might be an interesting place to start, kind regards Alan
  7. If you put wait() in your put() method, you must call it from the context of an SC_THREAD. Can you show the code where you're calling put()? Alan
  8. The front page of www.accellera.org has information about UVM-SystemC on it at the moment, Alan
  9. Hi Vitorio, the way the sc_signal code works is that it keeps track of the process handle of the first writer, and then if a write from a different process handle occurs, it is considered an error. Using dynamic processes and sc_spawn will still be considered as multiple writers, and you'll get the same error. There's an example of of sc_spawn/sc_spawn_options on page 66 of the Language Reference Manual. regards Alan
  10. If you really want to do this, sc_signal has a template argument WRITER_POLICY which can be set to SC_MANY_WRITERS to allow you to have multiple writers to the same signal (as long as the writes occur in different deltas). See section 6.4.4 in the LRM. This may be what you want - but of course writing to a single object from parallel threads is always going to be "interesting" :-) regards Alan
  11. See the 1666-2011 Language Reference Manual, section 4.5.3 - especially the last paragraph on page 29. The LRM is your friend :-) Alan
  12. What error did you get? Regarding declaring before use, here is a simple example. int main() { int i; j = i; // won't work, j is not yet declared int j; return 0; } In your original code, you are trying to use lp_filter_ltf before it is declared, which is why sc_main should be at the bottom of the file. I notice also that you are trying to use the class name as an instance name - that won't work, you should write e.g. lp_filter_ltf lpf("lpf"); ad_converter adc("adc"); regards Alan
  13. By the way, you don't have to write your own SVA for AXI, you can download them from the ARM website - you need to register first. Though that doesn't include coverage. regards Alan
  14. If you don't know C or C++, using SystemC-AMS is going to be challenging - I highly recommend learning at least how C is compiled first. The problem is that you must declare things before you use them. So you need to put your modules in the correct order. Move the sc_main function to the bottom of your file, kind regards Alan
  15. Hi Dhaval, what you're describing is just standard synchronous design good practice. Instant summary: ideally all blocks have a common clock, communication between blocks uses signals; signals follow evaluate/update semantics, which guarantees that you always see the current value of a signal, not the future value. Hence no race hazards/hold time violations. regards Alan
  16. There's a difference between static function and function static. The rule in 13.5.2 refers to subprograms declared with a lifetime of static, e.g. function static ... task static ... In the UVM code, the declaration is static function which is a static method of a class - section 8.10 in the LRM. regards Alan
  17. What you've described in SystemC sounds like expected behaviour - if you drive the clock and the signals at the same instant in the transmitter, then the receiver module will detect the clock and see the updated values of the signals - if I've understood you correctly. Regarding connecting to SV, there's no standardisation of how multi-language simulation should behave, so you need to read your simulator documentation, regards Alan
  18. Yes, sc_signal can't be used like that. If you want to have multiple drivers you'll have to use sc_signal_resolved and probably sc_inout_resolved as well. Have a look at the Language Reference Manual (which you can download free via the Accellera website), regards Alan
  19. You haven't bound port addr of sr0, regards Alan
  20. A channel is simply a class that implements a SystemC interface. A primitive channel implements an interface and is derived from from sc_prim_channel, and can thus have access to the scheduler (evaluate update). A hierarchical channel implements an interface and is derived from sc_module, and can thus have all the features of an sc_module (processes, hierarchy etc). There'd be no point in deriving from sc_prim_channel and then not implementing the update/request-update behaviour. If you want a channel that is not a primitive channel, and is not a hierarchical channel, you would typically implement an interface but derive from sc_object. regards Alan P.S. To answer your questions more specifically - request_update and update are not pure virtual, so you could ignore them. Though why would you ignore them? If you don't want them, derive from sc_object instead. A hierarchical channel is derived from sc_module. sc_module does not have request_update/update, so you can't use them.
  21. Hi, the trick to understanding this is to notice the difference between sc_in < bool > dout [8]; // an array of 8 boolean ports and sc_in<sc_bv<8> > dout; // a single port containing an 8 bit vector. So you need to get at the 8 bit value within dout. The easiest way round it is probably sc_bv<8> dout_temp = dout.read(); dout_temp[0] = dinp.read()[7]; dout.write(dout_temp); For the use of sc_int<1>, sc_int is not a signal, therefore does not have a write() method. Just do i = 0; Generally if you're going to do code like you've shown above, I would recommend using temporary variables, then assigning the variables to the ports - or even easier, just use VHDL or Verilog :-) regards Alan
  22. You can derive from sc_signal (that's how sc_buffer is defined in the LRM), but that's not how you're supposed to do it. The intention of sc_signal is that you supply your data type as a template argument. The intention of using a template argument is that the SystemC elaboration code can statically detect if you attempt to connect an sc_in<foo> to an sc_signal<Packet> for instance, and give you an error. The error message is telling you that port "busyOut" is not bound. With default template parameters, you must bind all ports (you cannot leave them unbound). With default constructor arguments, the ports are given names "port_0", "port_1" and so on - so the 10th port (busyOut) is the problem. regards Alan
  23. I'm not sure what you mean by "extend". You can use your Packet class as the template argument of sc_signal, sc_in, and sc_out as long as you implement the correct operators (as shown in section 6.4.3 of the 1666-2011 Language Reference Manual). However you can't bind a packet to an sc_in, you must bind sc_signal<Packet> instead, regards Alan
  24. pkt1 and pkt2 need to be signals, e.g. sc_signal<Packet> pkt1, pkt2; regards Alan
×
×
  • Create New...