mohitnegi

well Karthik welcome to the group --
you can find a lot books on these topics which are easy to understand with prior knowledge of modelling language (ill PM you if u cannot find)
regarding projects you can start with peripheral IPs like USART ,SPI ,I2C ,etc

Hi Mohit,
 
I'm working on understanding these topics as well currently.  I am working on something very similar to what you described. 
 
After you set the register value, issuing an e.notify() I believe is identifcal to e.notify(void) which is an "immediate notification".  This doesn't mean any threads waiting on this event start running, it just means they are placed into the "runnable set for execution" (p73 systemC: from the ground up).  Therefore whenever your b_transport releases the thread, the "target process" will start running.
 
If you do a e.notify(SC_ZERO_TIME), aka "delayed notification with a time of 0", any processes waiting on this event will only execute after all processes in the "runnable set" have been executed.  Long story short, the "target process" is not placed into the runnable set at the time of the notification.  Once your b_transport releases the thread for the first time,  i.e. wait(SC_ZERO_TIME), it completes the current runnable set, then places the "target process" into the runnable set. 
 
Now your second wait(SC_ZERO_TIME) will kick off the target process.
 
This exact topic is discussed on page 75 (notify(SC_ZERO_TIME)).  It discusses it's merits over notify(void) for a selected scenario (when a process could miss an event).
 
In your scenario I dont believe you can miss the event, so notify(void) seems more appropriate.
 
brian

SystemC TLM is a part of the SystemC standard (both parts TLM1 and TLM2). True, it is an newer addition, but it is never-the-less part of the standard.
 
TLM1 was the first attempt to standardize an API, which worked, but it didn't address the needs of the SystemC community as well as had been hoped. TLM2 standardizes a methodology to model address mapped bus communications and the associated API. It allows for easier exchange of IP blocks for simulation.
 
TLM emphasizes that "ports" are not just wiring connection points, but rather a nexus for higher levels of communication. TLM2 has "sockets", which are really just glorified SystemC port combinations (sc_port & sc_export). TLM2 also standardizes some concepts (even if not stringently) of different styles of transaction level modeling (sometimes called coding styles). For instance, "loosely-timed" (LT) represents "execute as fast as possible while maintaining register functional accuracy"; whereas, "approximately-timed" (AT) means "provide sufficient timing detail to allow bus-level timing analysis[1]". AT does not simulate as quickly as LT because it has to provide extra details and timing behavior.
 
Note 1: Not necessarily the same as clock cycle accuracy.
 
On the other hand, the SystemC core provides the fundamental mechanisms that allow for design encapsulation (sc_module), event-driven simulation (sc_event and wait()), processes (SC_THREAD, SC_METHOD), a notion of simulated time (sc_time) and channels (sc_interface, sc_prim_channel, sc_channel). Channels are one of the most important features and enable abstraction of safe interprocess communications. SystemC also provides the minor addition of hardware datatypes (sc_logic<>, sc_int<>, sc_fixed<>, etc). It also provides primitive communications channels such as sc_signal<> and sc_fifo<>. Thus, the SystemC core provides the foundation needed to implement TLM.
 
Sadly in some sense, SystemC provides a number of simplifications for writing RTL even though it is fundamentally not the strong point of the simulator. To some degree these simplifications are an holdover from SystemC 1.0 for backwards compatibility. I said sad because the simplifications have encouraged many to think of SystemC as an appropriate vehicle for writing RTL code, but then get frustrated at the lack of performance (for RTL). SystemVerilog and VHDL are much better suited for that task. The RTL aspect of SystemC is good in making it easier to interface SystemC to the other languages for co-simulation.

For a functional untimed model, I guess the user needs to know how to set up and control the model, and how to integrate it into the rest of the system, and how to run it.
It's not clear to me if this is an untimed model of the whole system.
 
If it's for spec development and demo, I would expect it to output data for use as a reference later on, and perhaps to display that data in a useful form for a demo.
Another way to think about it would be to develop "use cases" and then write the documentation according to that.
So your person working on the design spec might say
"I want to run the model and see a graph of the results"
 
or
 
"I want to run the model"
"I need to set bus precision of data"
"I need to output data as a video frame for import into Matlab"
 
From those use cases, you should be able to derive the documentation.
 
For the architect, I would expect to need to specify a register map and how to program the registers as well as the above.
 
It's a very general question, so it's hard to answer! But thinking about use cases is probably a good place to start.
 
kind regards
Alan

I suggest that the key is to decide who you're writing the document for. If your model is going to be used for architectural analysis, then you should write the document for an architect.
 
The next question, is what is the architect going to do? If they need to decide how to partition an algorithm between hardware and software then you have to assume that they need a model that can support both hardware and software.
 
If you are targeting a known platform (e.g. a particular processor and bus and set of peripherals) then you can assume the CPU is fixed, and concentrate on the platform. In that case the architect needs to know how to configure the model to vary bus widths, bandwidth, bridges, and so on; and how to read performance information from the model.
 
regards
Alan

hy KS,
 
In refernce to section 13.2 of LRM
 
 
 socket which i understood is can have both forward and backward path but i am not sure whether full duplex is possible ..
May be other could help ...
 
An option i would suggest  in systemC is to make a bidirectional sc_port(inout) and use it ...
Note- benefits of sockets wont be there as mention in the same section ...

Hi All,
 
I have few question regarding QEMU ....
 
1.What is QEMU and what is its use ...??
2.Can QEMU be used for VP modeling ..if Yes then how ???
 
 

Hi Mohit
 
QEMU is an open source software mostly written in C. It emulates different architectures (ARM,MIPS, PPC, and more) from host and can run binaries on it.
So you can boot android for arm on x86 PC.
As far as I know the typical use cases of QEMU are
System Emulator Frontend for Virtualization As a system emulator, android sdk uses QEMU to boot android to let developer check the application on x86 pc not on arm development board. Xilinx Xynq development kit also uses QEMU to run the software for the FPGA on x86 pc.
For virtualization, QEMU is used to virtualize x86 pc on x86 pc (or arm on arm) with KVM or XEN.
 
 
 
Shorter answer:
Yes, Green Socs and TLMu are famous project for it. Iguess there may be similar projects more.
 
Longer answer:
QEMU consists of many kinds of processor models and peripheral models, so many tried to use it with SystemC.
I also succeeded to boot arm linux on my customized TLMu( QEMU processor model + SystemC peripheral models).
 
IMHO QEMU has 3 difficulties for integrating with SystemC.
Building QEMU is sometimes troublesome because of its dependencies on many libraries. QEMU is written in C with gtk-like object system and with so many global/static variables. It is tough to understand and modify the source code. Global variables prevent you from multi-instantiation. QEMU source code is always changing and its speed is fast. It will be a painful work to catch up with the mainline release after you fork QEMU. QEMU is a really really useful software, actually I use it for virtualization and appreciate it. But honestly its source code is not something that I would love to recommend for learning material.
 
I hope you will find a cool way to integrate it with SystemC.
 
Regards,
Yutetsu.

Hello,
If you have read my responses to three recent queries on
this newsgroup, you like the others, have run into a fundamental
drawback/problem of C++ templates. The reason why your
fifo works with single characters only is because during the
crucial SystemC elaboration step, the size (number of bits)
for a single character is known to the compiler. Also note
that the SystemC built-in sc_fifo module can tackle built-in
C++ primitive data types(char, double, float int ....) ONLY.
As a character string can be of any size, it is an user
defined data type, and so the user has to provide the
mechanism to handle it.  
So, to transfer character strings via a custom fifo, a good
option would be to:
1. Declare a custom interface - subclass of sc_core::sc_interface
2. Create a class that implements the interface - must ensure
FIFO order in the input/output. This would be the character
string FIFO.
3. Create custom ports to read/write character strings from/to
custom channel
 
Yes, it is rather messy, but it is straightforward. Hope this helps.

Hi Cam,
  the idea of TLM2 was to create a standard API for transaction level modelling, that runs at high speed, and models memory-mapped buses.
 
So the TLM Working group decided to create standard functions for both blocking and non-blocking transport; and a standard payload object.
 
So the first advantage of using TLM2 over plain SystemC is simply that it is a standard API and payload.
 
To model pipelined transactions, the TLMWG decided to use function calls from target to initiator and initiator to target. To allow function calls to be made in both directions needs a port on the calling module and an export on the target (forward), and a port on the target model connected to an export on the initiator. You could of course do this without sockets but you'd have to make two connections - by using a socket, a single bind call connects both export and port. Also you'd have to explicitly declare the initiator port and target export with tlm_transport_fw_if, and the target port and initiator socket with tlm_transport_bw_if - initiator socket is based on tlm_transport_fw_if and the target socket on tlm_transport_bw_if so you get that "for free".
 
Finally, the sockets also have extra template arguments compared to SystemC ports - the Bus Width parameter. This ensures that the user cannot accidentally connect busses of different widths together.
 
kind regards
Alan
 
P.S. There is another answer I could give:
TLM2 *is* SystemC there is no difference. An initiator is a channel that implements the tlm_bw_transport_if. The target is a channel that implements the tlm_fw_transport_if. So the only difference from the "traditional" use of SystemC is the idea of a socket to provide simultaneous binding of the both port and export. If you want to, you could create your own exports and ports, and connect them yourself.

LegUp 2.0 (an open source high-level synthesis tool)
...............
http://legup.eecg.utoronto.ca/download.php
http://legup.eecg.utoronto.ca/demo.php
or
http://legup.eecg.utoronto.ca/getstarted.php
....................
About the above demo:
The LegUp 2.0 demo will synthesize your C code into Verilog RTL running entirely in hardware (no soft TigerMIPS co-processor). The demo uses the default LegUp settings: Cyclone II FPGA target device, 15ns period constraint, binding enabled for dividers, and pattern sharing enabled. The default code is the MIPS benchmark from CHStone, which implements a MIPS processor and then executes a short MIPS program to sort an 8 integer array.
...................
A good thesis for better learning:
Enabling Hardware/Software Co-design in High-level Synthesis
https://tspace.library.utoronto.ca/bitstream/1807/33380/4/choi_jongsok_201211_MASc_thesis.pdf
 
 
The HercuLeS high-level synthesis tool:
http://www.nkavvadias.com/hercules/

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

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

Hi Mohit,
 
This is described in section 9.4 of the SystemC Synthesizable Subset document:
 
 
Both Fossy and Vivado do not support SC_THREAD, not sure about the high-end Mentor's Catapult-C and Forte Cynthesizer which might support some constructs.
 
Regarding Dynamic Sensitivity, everytime you see the word Dynamic think about how this would translate to hardware. Leaving Dynamic Reconfigurable Hardware to one side in general everything you code must be static.
 
Regards,
Hans.
http://www.ht-lab.com

Hans is absolutely right. As a linked list cannot be implemented in hardware, they cannot be used in synthesis.
In a similar vein, using SC_SPAWN, SC_JOIN macros to instantiate/close dynamic processes is also unwise
as dynamic processes can never be implemented in real hardware.

AFAIK for synthesis you need to stick to fixed size arrays. I would suggest you read up what memory templates vendors recommend before you start coding. You can read the synthesis guides for Vivado, Fossy and probably some others on the web.  Be prepared to instantiate some VHDL/Verilog code if you need more complex multi port memory models.

Good luck,

Hans.
www.ht-lab.com

Hi Alan,
 
i wish to do modellng of an IP in systemC and TLM but i am not sure whether  should model
the register map(a dedicated code for all the register used in IP) also ....
IF yes then how would the register map be modelled in systemC and TLM keeping in mind
some of them are read only/ write only , R/w or one shot ....
 
Thanks
Mohit Negi