If you are running on pwf linux, then set up as follows
ssh -X linux.pwf.cl.cam.ac.uk (or login from console) export SOCDAM=/ux/clteach/SOCDAM export SYSTEMC=/use/share/systemc export PATH=$PATH:$SOCDAM/bin
This should enable you to run gtkwave. The other tools needed are gcc and make.
The shell env vars can also be set at the head of the makefile, but this is redundant duplication.
This makefile can be copied from $SOCDAM/classes/class1/Makefile. It compiles hworld.cpp and runs it.
Note that tab characters have significance in makefiles.
# (C) 2009 DJG: University of Cambridge, SoCDAM. SYSCDIR=/usr/share/systemc LDFLAGS= -L$(SYSCDIR)/lib-linux -lsystemc LANG=C SOCDAM=/ux/clteach/SOCDAM/ CXXFLAGS=-Wno-deprecated -I$(SYSCDIR)/include -I$(SOCDAM)/TLM-2008-06-09/include/tlm all: g++ $(CXXFLAGS) hworld1.cpp $(LDFLAGS) ./a.out
Full src file hworld1.cpp.
A first example can be copied from $SOCDAM/classes/class1/hworld1.cpp.
This should work (do something) without modification.
If you have enabled vcd tracing, output will be written to a vcd trace file.
This can be viewed using gtkwave.
Start gtkwave from the command line. Browse one level down in the signal
hierarchy and drag the signals of interest to the signals box.
A second example can be copied from $SOCDAM/classes/class1/hworld2.cpp.
Full src file hworld2.cpp.
Illustrating the sc_uint fixed-field operators.
SC_MODULE(fivebitcounter) { sc_in <bool> clk, reset, load; sc_out <sc_uint<5> > q; sc_out <sc_uint<5> > parallelin; SC_CTOR(fivebitcounter) { void clkme(); SC_METHOD(clkme); sensitive << clk.pos() << reset.pos(); } void clkme() { if (reset.read()) q = 0; else if (load.read()) q = parallelin.read(); else { int nv = q.read() + 1; printf("Five pending set to %i\n", nv); q = nv; } } };Console output log: note the 32 becomes a zero when stored in the field.
Five pending set to 31 Toggle at 4200 ns Toggle at 4250 ns Five pending set to 32 Toggle at 4300 ns Toggle at 4350 ns Five pending set to 1 Toggle at 4400 ns
The files for class 2 are just the simple_fifo example from the SystemC examples directory.
Their copied here for convenience as well $SOCDAM/classes/class2.
Please pay attention to the details of how to use sc_port.
Finally, we'll take a firt look at modelling control and status target registers in various ways: RTL, net-level SystemC and TLM-style SystemC.
The files for class 3 are may be found in $SOCDAM/classes/class3.
This includes an abstract ISS for a really trivial microprocessor called nominalproc as well as a concrete ISS and an RTL-style bus initiator in SystemC.
Some simple IP blocks (address decoder and response mux) for building a tree-structure can be examined.
A high-level model of the nominal processor:
A library of SystemC IP blocks that can be used by various targets in different classes:
TLM (transactional-level modelling) versions of example IP blocks:
In class 4 we look at the TLM version of nominalproc and the TLM version of the RAM tlmram32.h
We also look at the tiny Quantum Keeper embedded in the TLM version of nominal processor.
We look at how the memory models can be called in both a TLM style and an RTL style from a TLM style implementation of nominalproc.
Exercise: complete this example, showing how to call from a C device driver to a C behavioural model directly and via TLM and via RTL style is not here.
Long Exercise (for the really keen): convert the design to use the standardised TLM 2.0 generic transport payload. Then modify further to use the TLM2.0 convenience sockets.
We can extend class 4 with free-standing transactors that connect the TLM processor to RTL-style components, giving us a mixed abstraction simulation.
The new component for this class is the bus arbiter.
Two instances of the nominal processor are connected to one bus.
The ESL-style bus arbiter implements no queueing and allows more than one thread to block in the target at once, but exclusion should be added to model more-realistic sharing.
There is an implementation the DMA controller and other IP blocks to look at.
Under construction: a full working example with a running program that performs the DMA.
... a first look at multiple bus masters and look at DMA controller details. We look at a simple, one-channel DMA unit, but they can be as quite complex in their following of linked lists and so on. So what's the difference from a processor then what: no instruction fetch, functionality fixed at tape out.
END