Computer Architecture Simulation & Visualisation

Stanford DASH Architecture: Node Simulation Model

The Stanford DASH architecture was designed to prove the feasibility of building a scaleable high performance machine with multiple coherent caches and a single address space. There are currently two HASE simulation models of parts of the DASH architecture, originally built in 1995/6 by Lawrence Williams as parts of his MSc project, one modelling a single node and one modelling a cluster of four nodes. These models are designed to demonstrate the cache coherency protocols used in the DASH [1]. The Node model demonstrates a simple 2-level cache arrangement.

The files for the HASE DASH Node model can be downloaded from

Instructions on how to use HASE models can be found at Downloading, Installing and Using HASE.

The Stanford DASH Architecture

The DASH architecture [2] [3] was built in the Computer Systems Laboratory at Stanford University. The main motivation underlying its inception was a desire to prove the feasibility of building a scaleable high performance machine with multiple coherent caches and a single address space. The intention was to produce a parallel architecture offering both ease of programmability (facilitated by the single-address space) and very high performance (by using hundreds to thousands of high performance (low-cost) processors).

The DASH hardware is organised as a hierarchy in which sets of processing nodes are grouped together in clusters of four, connected together via a common bus. Clusters are then connected together by an interconnection network. The DASH cluster is based upon a modified version of the Silicon Graphics POWER Station 4D/340 [4], in which the major components are:

The simulation model of the processing node consists of the two data caches and a MIPS `processor' which, rather than attempt to simulate the MIPS instruction set and run programs to generate cache addresses, simply emits a sequence of addresses (with read/write status) held in a notional memory.

diagram of DASH node

Figure 1. The Stanford DASH Node

The HASE DASH Node Model

The HASE DASH Node simulation model is shown in Figure 2. The model has a number of size and timing parameters which can be varied via the HASE GUI.

Image of HASE DASH node model

Figure 2. The HASE DASH Node model


The MIPS entity in the model contains an array of requests (address + request type) to be sent to the Primary Cache. At the start of the simulation, the MIPS sends the first of these addresses, together with its Read/Write type, to the Primary Cache. Once the actions in the cache system are complete and the MIPS has received a reply, it sends the next address, and so on until it encounters an address of type z.

Primary Cache

The primary cache is direct-mapped and operates a write-through/no-write-allocate policy. The line size is fixed at 4 words but the number of lines can be varied from 1 to 256 in multiples of 2 while the delay associated with a cache access can be varied from 1 to 8 clock cycles. As it processes each access, the cache icon displays the result (RH = Read Hit, RM = Read Miss, WH = Write Hit, WM = Write Miss).

The data structure central to the operation of this entity is a HASE memory array which represents the cache memory contents via a C++ based array of structs. This structure specifies storage for valid, modified and shared bits as well as the cache entry tag and stored values:

Valid Modified Shared Tag Block A0 A1 A2 A3

This cache line format is shared with the secondary cache unit; the only difference in use is that the primary cache need never use the shared bit. On receipt of an incoming packet a table lookup is performed and validity bit and tag checks are made. If a hit occurs a delay is initiated before sending the result back to the MIPS entity. On a miss the packet is referred (after the miss delay) to the secondary cache entity.

Secondary Cache

The secondary level processor cache is identical to the primary cache except that it operates a write-back/write-allocate policy. As in the Primary Cache, the user can define cache size and latency through the use of entity parameters.

A line in the Secondary Cache may be:

The Bus

In the full model of a cluster the MPBus is one of the most complex entities in the simulation. It is responsible for displaying a large amount of state information detailing the on-going operation of the snoopy-bus protocol as well as carrying out the conventional tasks of bus arbitration, address and data transfer. In the Node model the Bus entity simply passes memory requests from the secondary cache to the Memory and returns the results of each request back to the node after it has been processed.


The memory is relatively simple in design. Because the simulation is only concerned with modelling the effects of read/writes throughout the system (and not the contents of memory locations) no actual storage needs to be modelled other than that present in the processor caches (and in these only addresses need be stored). Therefore a memory unit cycle consists of receiving an in-bound request, displaying read (R) read and write (W) or write-back (U) and finally transmitting the result packet back onto the MPbus. The memory delay can be varied between 1 and 16 clocks while the size can go up to 65536 words.

Using the Model

The MIPS entity in the model contains the set of requests shown in the table below, chosen to show how the caches operate. A request can be read (r), write (w) or an end of sequence marker (z). All requests are for data (d); the DASH allows for instruction requests but these are not implemented in the model. The table also shows the actions that occur in the caches as each request is issued by the MIPS entity. (RH = Read Hit, RM = Read Miss, WH = Write Hit, WM = Write Miss)

00 r d reads word 0: RM in Primary Cache, line 0 set to Valid;
RM in Secondary Cache, line 0 set to Valid
05 r d reads word 5: RM in Primary Cache, line 1 set to Valid;
RM in Secondary Cache, line 1 set to Valid
02 w d writes to word 2: WH in Primary Cache, line 0;
write through to Secondary Cache (WH), line 0 set to Modified
10 r d reads word 10: RM in Primary Cache, line 2 set to Valid;
RM in Secondary Cache, line 2 set to Valid
03 w d writes to word 3: WH in Primary Cache, line 0;
write through to Secondary Cache (WH), line 0
34 r d reads word 34: RM in Primary Cache, line 0 overwritten;
RM in Secondary Cache, line 8 set to Valid
35 r d reads word 35: RH in Primary Cache, line 0
36 w d writes to word 36: WM in Primary Cache, line 1 overwritten;
WM in Secondary Cache, line 9 set Valid, write through to memory
64 r d reads word 64: RM in Primary Cache, line 0 overwritten;
WM in Secondary Cache, line 0 copied back to memory and overwritten
00 z d stops simulation

This set of addresses can be modified via the HASE GUI or by editing the file MIPS.mem_trace.mem.

Suggested Student Exercise

Create a sequence of read and write accesses which demonstrate all the possible actions of the cache and memory updating protocols. Your submission for this exercise should be in the form shown in the following table.

AddressLine/TagMod?Action (Tag)
000 r dPrimary

Load P line 0 (0)
Load S line 0 (0)
Read Memory
132 r dPrimary

Overwrite P line 0 (1)
Load S line 8 (0)
Read Memory

Thus there should be one line for each access made by the processor showing its address, what happens to the access at the Primary and Secondary Caches, the target line in each cache for that address and the tag of its current content (a tag value of "-" implies that the line is not valid), whether the line had been modified prior to the current access (Mod?), and the action which occurs, e.g. for access 0 in the table above, line 0 of each cache, neither of which has a valid tag, is loaded with the value read from memory and with Tag 0 in both cases.

The memory sizes are set at Primary Cache = 8 lines (P_size 3), Secondary Cache = 16 lines (S_size 4), Memory = 1024 words (M_size 10). These sizes can be altered using the slider bars in the Parameters panel.

A z request is used to terminate the simulation run and a z request must always be placed at the end of an address trace. Without it, the simulation will run on until it times out.

If you need to increase the maximum simulation time of a simulation run, use the Timer slider bar in the Parameters panel. This is calibrated in powers of 2 and preset to 7.


1^     L.M. Williams and R.N. Ibbett,
"Simulating the DASH architecture in HASE",
29th Annual Simulation Symposium, SCS, pp 137-146, 1996.
2^     D.E. Lenoski,
"The Design and Analysis of DASH: A Scalable Directory-Based Multiprocessor",
TR:CSL-TR-92-507 Computer Systems Laboratory: Stanford University, 1992
3^     D.E. Lenoski, J. Laudon, T. Joe, D. Nakahira, L. Stevens, A. Gupta and J. Hennessy,
"The DASH Prototype: Implementation and Performance",
19th International Symposium on Computer Architecture, pp 92-103, May 1992.
4^     F. Baskett, T. Jermoluk and D. Solomon,
"The 4D-MP Graphics Superworkstation: Computing + Graphics = 40 MIPS + 40 MFLOPS and 100000 Lighted Polygons per Second",
Proc. Compcon Spring 88, pp 468-471, February, 1988.

Return to Computer Architecture Simulation Models

HASE Project
Institute for Computing Systems Architecture, School of Informatics, University of Edinburgh
Last change 03/01/2023