Jump to content

apfitch

Members
  • Posts

    613
  • Joined

  • Last visited

  • Days Won

    121

Everything posted by apfitch

  1. Gtkwave doesn't like spaces in labels. Change sc_trace(tf, Value, "SystemC value"); to sc_trace(tf, Value, "SystemC_value"); // no space! regards Alan
  2. If you look in the SystemC LRM IEEE 1666-2011 there is no public method called reset(). You can download the LRM for free by the way. To empty the fifo you could either read all the data, e.g. while ( buffer.nb_read(data) ) {} (sorry that looks like the kind of horrible code C programmers used to write...) or use a different class of your own, or perhaps make a wrapper for STL deque. kind regards Alan
  3. sc_fifo is derived from sc_prim_channel, so operates with the evaluate/update (delta cycle) behaviour of primitive channels. There's an explanation of primitive channels at http://www.doulos.com/knowhow/systemc/tutorial/primitive_channels/ regards Alan
  4. 1) Change the data type in the template parameter e.g. sc_fifo <myclass> fifo and then myclass can be a wrapper for whatever data you want. You must follow the rules for data in primitive channels (operator= etc). 2) It depends if you want primitive channel behaviour. sc_fifo operates with delta cycles. If you don't need delta cycles, you could just use an STL deque (for instance) Alan
  5. There companies with tools to assist with H/W S/W partitioning. A couple I've heard of are Gedae and Cofluent Design - it might be worth having a look at their websites, regards Alan
  6. sc_fifo has its size set by a constructor argument. E.g. in a function you can write sc_fifo<int> fifo_1(72); to get a depth of 72 (72 locations). regards Alan
  7. Hi Mohit, 1. The important issue is not the language, but the technology. Behavioural synthesis tools generally deduce a combination of state machines (for control) and datapath (for signal processing). The key thing is that you as a designer do not have to write the micro-architecture yourself. Hence behavioural synthesis is potentially more productive than standard RTL synthesis. That argument is language independent. A behavioural VHDL tool would be more productive than an RTL VHDL tool. Writing RTL in SystemC would be no more productive than writing RTL in VHDL or Verilog. So your question "why do we require SystemC sythesis when we have HDL synthesis" would be better as "why do we need behavioural synthesis rather than RTL synthesis". And the answer is you only need it if it's better for you in some way (faster time-to-market for instance). No-one is forcing you to use behavioural synthesis :-) 2. I don't know if SystemC synthesis tools are interoperable. 3. How come tools exist even though the synthesis standard is a draft? EDA vendors are free to ignore standards :-) Standards only get adopted (and developed) if EDA vendors and users can see value in those standards. So I guess no-one is motivated to finish the synthesis standard. The key thing about the synthesis standard (as opposed to a language standard) is it's trying to guide how a tool may interpret SystemC code. EDA vendors see that as a legitimate area of product differentiation. The same thing happened with VHDL 1076.6 - the vendors essentially ignored it. 4. You may mix synthesisable and non-synthesisable code, you just have to hide the code using the pre-processor or meta-comments. The same is true in VHDL and Verilog - you can include non-syntheisable code, but it is typically hidden using meta-comments, e.g. -- synthesis translate_off code that won't synthesize goes here -- synthesis translate_on regards Alan
  8. Thanks Mohit - I think the error is here: void fifo_write(unsigned char c); Static SystemC processes may not have arguments. You need to remove the argument from the function declaration, e.g. void fifo_write(); regards Alan
  9. Please show more of your code, including the line where the error occurs, regards Alan P.S. I don't think the quote from the LRM is relevant. What that quote says is that you may write sc_lv<8> = "10101010"; i.e. mix vector types and string literals.
  10. Essentially this is the point of synchronous design. If you can, trigger everything in your code from a single clock source, then you don't need the reset and enable in the sensitivity list. As long as you make sure the signals you sample are stable at the point when the clock changes from 0 to 1, everything will work in a predictable fashion, kind regards Alan
  11. At time 0, all processes execute independent of their static sensitivity list, unless you use dont_initialize(). That's why you see two executions at time 0, your constant process runs once at time zero, then runs a delta later when the rising edge of the clock occurs. If you want to remove this, change the process declaration to SC_CTOR(constant){ SC_METHOD(process); sensitive << clk.pos(); dont_initialize(); Regarding time 3s, I expect the reset signal is changing on a different delta than the enable signal, and thus triggering the process twice. You can test this by printing out the delta count as well as the time - you can use the function sc_delta_count() to return the current delta count. For a tutorial which includes a discussion of dont_initialize(), have a look at www.doulos.com/knowhow/tutorial kind regards Alan
  12. You need to give more bits to counter_out, at the moment it is only 1 bit, Alan
  13. The short answer is probably "no we can't simplify it" :-) If you want to learn about high level synthesis, you need to a bit of reading. You could start with the Wikipedia article on High Level Synthesis https://en.wikipedia.org/wiki/High-level_synthesis and then there's some useful background information on Forte DS website http://www.forteds.com/behavioralsynthesis/ It might be worth reading the documenation on Vivado HLS (www.xilinx.com) as well, there is some introductory material, for instance this video: http://www.xilinx.com/training/vivado/vivado-hls-in-depth-technical-overview.htm One thing to remember with HLS is that it is not as mature as RTL, so different tools may well have different approaches, regards Alan Try reading those and see if that helps, kind regards Alan
  14. The sc_signal class only creates events when it changes value. Because you assign the same value all the time, the counter never gets triggered. Try changing sc_signal<bool> ensignal to sc_buffer<bool> ensignal; sc_buffer is a derived class of sc_signal that notifies an event when it is written, even if you write the same value over and over again. regards Alan P.S. To generate your clock, it would be easier (in sc_main) to do sc_clock clock("clock", 1, SC_SEC); ... sc_start(10, SC_SEC); The sc_clock instance can be directly bound to a port of type sc_in<bool>.
  15. http://www.accellera.org/downloads/standards/systemc Alan
  16. The things that can be synthesized are described in the document Hans mentioned. regards Alan P.S. "for" can be synthesized in Verilog, even in RTL tools (as long as the number of repeats is static).
  17. ESL is not the same as HLS. ESL refers to all Electronic System Level activities (virtual prototyping, system modelling, algorithm development, model-based design, HLS). HLS refers specifically to synthesis. As Hans said, the link describing synthesis in SystemC is here: http://www.accellera...temc-synthesis/ I'm not sure what you mean by "list of keyword". SystemC is C++, C++ keywords are SystemC keywords. I'm not aware of any open source synthesis, though some people have translated RTL SystemC code into Verilog, then used a standard Verilog RTL synthesis tool, regards Alan
  18. No analysis ports are TLM1 (in fact in SystemC they are technically a utility, i.e. not part of the standard). I looked at the docs and it seemed to say you have to use uvmc_tlm (which I think is tlm1) for analysis ports, regards Alan
  19. Hi Sam, in the error message it mentions uvm_tlm_phase_e, which is a TLM2 feature. Are you sure you've declared both sides using uvmc_tlm (not uvmc_tlm2)? kind regards Alan
  20. Hi Gaurav, there's no checker in the TLM2 standard. Are you referring to Doulos or Jeda checkers? If you're referring to Doulos (for whom I work) then send your question to info@doulos.com If it's the Doulos checker, I think it's intended for point-to-point connections only, regards Alan
  21. Actually I couldn't find a download button for the ESP1 package on that page - but it turns out that using my "skill and judgement", this link works... http://www.embecosm.com/packages/esp1/ regards Alan
  22. Hi Philipp, the "about" page http://www.mazdak-alborz.com/About.html shows the involvement of 2 of the authors you mention, regards Alan
  23. The talk by Steve Holloway at DVClub Bristol recently has some information about multiple address maps, i.e. a single set of registers accessed via 2 interfaces. Steve's example talks about 2 different IPs, but I think it's relevant to your problem. The presentation is here: http://testandverification.com/DVClub/09_Sep_2013/DVClub-UVMRegistersAdvanced_Topics-SteveHolloway.pdf and accessible from here: http://testandverification.com/publications/published-articles/dvclub/dvclub-on-9th-september-2013/steve-holloway-dialog-semiconductors/ regards Alan
  24. Hi Madhuri, how you model time depends on how efficient you want your model to be, and how accurate. The simplest model would be to add a wait(10, SC_NS) inside the function call that models the comparator. Regarding LT vs AT, there's a good outline in the SystemC LRM (which you can download free via Accellera). The key idea of LT (loosely timed) is that events in the model don't have to happen at the exact time when they would occur in reality - for instance an initiator may run ahead of sc_time_stamp() by "refusing" to call wait, and so not letting any other thread run. The idea of AT (approximately timed) is essentially that modelled events happen at the sc_time_stamp() when they would really happen in the thing you are modelling. I don't understand what you mean when you say "Function sc_time_stamp() keeps track of the current, when called at the end of the main program, does it say for how long the simulation has run?" If I understand correctly, then calling sc_time_stamp() after sc_start() has returned would return the simulated time value at the end of simulation. For instance if you simulated a time of a million years, sc_time_stamp() would return 1 million years. Of course the amount of CPU time used by your computer would (I hope!) be much less. regards Alan
  25. This link might be interesting... http://www.embecosm.com/appnotes/ean1/ean1-tlm2-or1ksim-2.0.html Alan
×
×
  • Create New...