source: liacs/ca/opdr3/README@ 422

#/* Author      : Rick van der Zwet

# * S-number    : 0433373

# * Version     : $Id: README.txt 438 2007-12-28 02:53:47Z rick $

# * Copyright   : FreeBSD Licence

# * Description : Assignment documentation

# */



= Index =

* Preface

* Methodology

* Design decisions

* Directory stucture

* Programs structure

* Definitions

* Configurations

** Memory

** Cache

* BUS2 Output

* Usage / Running

* Conclusion

* Recommendationn





= Preface =

Over here you will find the results of assigment 3 -internally also

called assignment 4- of Computer architicture. The main purpose of the

assignment where to determine what the bank conflicts and memory

bandwith where in certain configurations. Cache simulation is done by

using dinero. To calculate the result several C programs had to be

written.



= Methodology =

The only need of the dinero output will be the the BUS2 (-o2) output ,

no need anything else. As perl, awk, grep and others are not allowed, a

small custom C program called grep-bus2 is written. Shell calculate.sh

will determine the correct cache options variables and will call the

proper compu with the memory configuration.



= Design decisions =

* As we are working in 'debugging' a standard program I assume every call

  to the memory will fetch 32 bits (4bytes)

* No cache will be simulated in dinero using 1 word cache, which might

  fake results while accessing multiple times the same memory cell

  (highly unlikely however)

* Shell script will allow output to set benchmark file





= Directory structure =

Makefile              = GNU Make config file

compu.c               = calculate bandwidth and bank conflicts

common.[ch]           = Common functions

memory_std.[ch]       = Standard memory

memory_bank.[ch]      = Bank memory

memory_dram.[ch]      = DRAM memory

calculate.sh          = Shell script to generate results of combinations

develop.sh            = Very simple script to keep running will coding to

                        ensure continues feedback

data                  = directory of the traces

data/lisp.002.din     = provided input

data/spic.002.din     = provided input

docs                  = Some additional documentation

docs/dineroIII.txt    = man page

src/dineroIII.tar.gz  = dineroIII source



= Programs structure =

compu.c will be the logic of choosing the correct memory module to use.

All memory implementations are defined in memory_<type>.[ch]. To avoid double

coding a 'interface' common.c is defined which includes the common

functions mainly outputs.





= Definitions =

The bandwidth of a cache/memory-system is the total number of bytes send

between CPU and cache divided by the number of cycles. We assume here

that memory activity is the bottleneck for the enire system in other

words: that the cache is continuously busy processing requests.



A bankconflict is defined as follows:



For normal memory, a bankconflict is a request that is sent to a bank

that is still busy handling the previous request (either in the access

phase or in the bus transfer phase). The first memory acces incurs no

conflict.



In page-mode DRAM we do not use multiple banks, so the above definition

is not so useful. In the case interpret the following as a bankconflict:

a request for a page (=column) in which the previous request was not for

the same page. The first access here also does not incur a conflict.



= Configurations =



== Memory ==

1)  standard memory with random access time of 8 clock cycles

2)  4-bank word-interleaved memory with random access time of 8 clock

    cycles

3)  8-bank word-interleaved memory with random access time of 8 clock

    cycles

4)  page-mode DRAM with a page-size of 64 words, a random access time of

    8 clock cycles and a 'next access time' of 3 clock cycles.

5)  page-mode DRAM with a page-size of 1024 words, a random access time

    of 8 clock cycles and a 'next access time' of 2 clock cycles.





== Cache ==

a)  no cache, a write buffer of 1 word deep

b)  a 64 KB, unified, direct-mapped, write-through, no write-allocate

    cache with 4 word blocks and a 1 word write buffer

c)  a 64 KB, unified, direct-mapped, write-back, write-allocate cache

    with 4 word blocks and a 1 word write buffer



= Assumptions =

== Given ==

*   All adddresses in this assignment are word-aligned and all

    data-accesses to the cache are 1 word.

*   Per clock cycl, 1 request for 1 word can be handled, but requests

    should remain in order.

*   The time for submitting the requests does not have to be taken into

    consideration

*   If a memory access is requested to the same bank or row of a busy

    memory part it is implied to be to adifferent address

*   When accessing memory, the same 'checking' cycle will be used as

    initial memory call cycle

*   DRAM memory will also have RAS time of 1, all memory will have a bus

    and no need to disticts between all of them

*   Calculating Byte transfer between memory and cache is trivial,

    number of lines * bytes every line

*   Both read and writes are treaded the same, no optimizations are made

    to ensure simplicity

*   Code is not build to be optimized, but to be clear instead, which

    will result in 'dumb' loops

*   With DRAM worst case senario is used, meaning a call to a locked

*   memory adress or diffent page will block for RAS seconds





= BUS2 Output =

BUS2 <type> <size> <adddress> <reference_count> <instruction_count>

*   BUS2 are four literal characters to start bus record access is the access

*   type ( r for a bus-read, w for a bus-write, p for a bus-prefetch, s for

    snoop activity (output style 3 only).

*   size is the transfer size in bytes

*   address is a hexadecimal byte-address between 0 and ffffffff

    inclusively

*   reference_count is the number of demand references since the

    last bus transfer (i.e. cache misses)

*   instruction_count is the number of demand instruction fetches

    since the last bus transfer



= Usage / Running =

# Alter calculate.sh to speficy the right dinero binary path

# Build binaries

$ make

# Call calculate.sh with proper argument for datafile

$ sh calculate.sh <path-to-datafile>

# Result will be posted to stderr and to the files res-xx.txt

# Rerun will simplely overwrite all the old data





= Conclusion =

  It really does depend which type of cache and memory to use. A lot of

  assumptions where made and many generalisations where made. In order

  to have the systems work better with eachother the system must need to

  have good kownleage of the underlaying implementation in hardware. It

  seems that the output traces lisp and spic has been optimized for the

  use of class C cause and type word memory. It's also pretty clear that

  without any cause the system will not preform at all and will just

  suffer from the really slow memory.





= Recommendations =

*   As the input is text and only simple calculations are beeing used, allowing

    to use a interperted like perl, python or else would be pretty handy

*   /usr/local/edu/data does not exists this should be ~csca/edu/data

*   The 'large files' are tar gzipped 100k, 300k ;-)

*   Please specify which version of dinero to use and were the program needs to

    run on

*   dineroIII does not exists online anymore and has been replaced by dineroIV,

    compiling also fails for dineroIII on more modern systems, quick and dirty

    fix patch: http://rickvanderzwet.nl/svn/data/liacs/ca/opdr3/src/

*   Submit does not include an email where to submit to

*   Translate 'Het gaat om' part Assignment