# Presentation: 694324

## Modeling of Simple Processor Architectures via YAPI

- Sam Williams
- EE249 Project
- December 3, 2002
- Mentors:
- Trevor Meyerowitz & Kees Vissers

## Mapping YAPI (KPN) toProcessor Architectures

**YAPI Channel**
- Unbounded FIFO’s
- Elements of type Object
- 1 to 1 mapping (no broadcast)
- Nonblocking writes
- Blocking reads

**YAPI Process**
- Parameterizable
- Threadlike behavior
- Sequential Coding
- Unidirectional Ports
- Internal state
- Read/Write ordering
-    defined by user

**YAPI Netlist**
- Create Processes
- Create Channels
- Map processes through channels
- Can be algorithmic

**F**

**D**

**E**

**M**

**W**

**Pipelined Processor**

- Combinational logic and arrays can be
-    represented with process code and arrays.
- Pipeline registers are just one element
-    deep FIFO’s
- Fanout is accomplished via multiple copies
-    of the FIFO
- How can we guarantee bounded length
-    (typical for processors) in an
-    unbounded model?

## Instruction Set Architecture(used in all examples)

- RISC Load/Store Architecture
- 32b instruction word
- 256 x 32b General Purpose Register File
- Memory abstracted into
- 	a virtually addressed cache (Harvard style split cache)
- Scheduling (dynamic/static) is dependent on micro architecture
- Examples were either scalar or super scalar (VLIW falls in between those extremes)
- Branch delay slot and prediction are dependent on micro architecture
- No Kernel mode support

**Core Instructions**
- 0x00 - nop
- 0x01 - bz   rt,ofs16
- 0x02 - bnz  rt,ofs16
- 0x0a - msync
- 0x0b - msyncr // wait for all memory reads to finish
- 0x0c - msyncw // wait for all memory writes to finish
- 0x0d - poison
- 0x0e - flush
- 0x0f - halt
**Memory Instructions**
- 0x10 - lw   rd,ldOfs8(rs)
- 0x11 - sw   rt,stOfs8(rs)
- 0x12 - ldw  rd,ldOfs8(rs) // loads 2 words
- 0x13 - sdw  rt,stOfs8(rs) // stores 2 words
- 0x14 - lqw  rd,ldOfs8(rs) // loads 4 words
- 0x15 - sqw  rt,stOfs8(rs) // stores 4 words
**Scalar Arithmetic**
- 0x20 - li   rd,imm16
- 0x21 - add  rd,rs,rt
- 0x22 - addi rd,rs,imm8
- 0x23 - sub  rd,rs,rt
- 0x24 - subi rd,rs,imm8
- 0x25 - sr   rd,rs,rt
- 0x26 - sri  rd,rs,imm8
- 0x27 - sl   rd,rs,rt
- 0x28 - sli  rd,rs,imm8
- 0x29 - mul  rd,rs,rt
- 0x2a - madd rd,rs,rt (rd+=rs*rt)
**Packed Double Word Arithmetic (ie take upper 7bits of reg address) and take reg,reg+1 from RF**
- 0x30 - dwli   vrd,imm16
- 0x31 - dwadd  vrd,vrs,vrt
- 0x32 - dwaddi vrd,vrs,imm8
- 0x33 - dwsub  vrd,vrs,vrt
- 0x34 - dwsubi vrd,vrs,imm8
- 0x35 - dwsr   vrd,vrs,vrt
- 0x36 - dwsri  vrd,vrs,imm8
- 0x37 - dwsl   vrd,vrs,vrt
- 0x38 - dwsli  vrd,vrs,imm8
- 0x39 - dwmul  vrd,vrs,vrt
- 0x3a - dwmadd vrd,vrs,vrt (vrd+=vrs*vrt)
**Packed Quad Word Arithmetic (ie take upper 6bits of reg address) and take reg,reg+1,reg+2,reg+3 from RF**
- 0x40 - qwli   vrd,imm16
- 0x41 - qwadd  vrd,vrs,vrt
- 0x42 - qwaddi vrd,vrs,imm8
- 0x43 - qwsub  vrd,vrs,vrt
- 0x44 - qwsubi vrd,vrs,imm8
- 0x45 - qwsr   vrd,vrs,vrt
- 0x46 - qwsri  vrd,vrs,imm8
- 0x47 - qwsl   vrd,vrs,vrt
- 0x48 - qwsli  vrd,vrs,imm8
- 0x49 - qwmul  vrd,vrs,vrt
- 0x4a - qwmadd vrd,vrs,vrt (vrd+=vrs*vrt)

|  OP |  RD |  RS |  RT |  Arithmetic |
| --- | --- | --- | --- | --- |
|  OP |  RD |  RS |  imm8 |  Arithmetic (immediate) |
|  OP |  RD |  RS |  ldOfs8 |  Load |
|  OP |  stOfs8 |  RS |  RT |  Store |
|  OP |  RD |  imm16 |  |  Load immediate |
|  OP |  bOfs16 |  |  RT |  Branch |

## In-order Statically-Scheduled Scalar Processor (DLX like)

- Learning example
- Each channel contains a single 32b integer
- Instruction word is passed down the pipeline in addition to operands and intermediate results
- Processes slept a number of cycles equal to their depth (no prefilling of channels) and don’t read until data is guaranteed to be present
- Feedback channels stabilize the system ensuring finite FIFO  length
- Reads and Writes were placed ad hoc inside each process  (resulted in several unexpected deadlock cases requiring fixes)
- Future examples use a coding style of {write, read, compute, iterate} to avoid deadlock
- For this example, its more headache than benefit

**F**

**D**

**E**

**M**

**W**

**5 Stage Architecture**

**Fetch**

**Decode**

**Execute**

**Memory**

**IC**

**DC**

**RF**

**4 Process YAPI Netlist**

## Simplify, Abstract, and add Features

- Single process
- Read operands and pass them and the instruction word down pipeline
- 	(multiple channels)
- Execute upon receipt
- Write to register file

## Out-of-Order Architectures

- Tomasulo style register renaming
- Use virtual register allocation
- Arbitrary number of integer units
- Broadcast nature handled with multiple copies of each channel
- Use arrays of ports and algorithms in the netlist to connect them
- Use Object nature of channels to encapsulate an instruction in-flight into an object – ReservationStationEntry
- Functional units are highly parameterizable (entries, depth, etc...)
- Stations stabilize system by replying with the number of free entries and memory of instructions issued on the last iteration
- ReadWriteIssue must also maintain knowledge of which instructions can be issued to the heterogeneous functional units
- Reorder buffer wasn’t implemented in-order to move on to more complex architectures
- Stations are almost identical, so a Station class was created, from which integer units, or a memory unit could be extended

- ...

## Ring Architectures

- Global signals should be avoided (as they can easily become a critical paths and limit frequency)
- Global knowledge should also be avoided (as it can result in significant hardware)
- In some cases, additional latency can be tolerated or neutralized with higher frequency

- Interface is key:  RingInterface is extended into Station and Processors Classes, Stations are extend into Integer, Float, and Memory units

## Future Work

- Timing
- Currently time is based on iterations of processes
- Extensive parameterization could allow for estimates of critical paths or frequency
- AST manipulation could back annotate all processes with the worst critical path time
- This could allow interface to events or modules timed in real time
- Common interface (FIFO’s/Objects) should allow co-simulation of both RTL and YAPI behavioral models
- As each behavioral model is completed it could be handed off for high-level synthesis or RTL design.
- Synthesis to gates would allow refinement of the design (add or delete pipeline stages or reservation station entries, or any other parameter
- Since ring designs can remove global communication, and replace it with neighbor communication, critical paths should appear only within the processes
- Compilers and Benchmarks
- True performance analysis requires benchmarks and a compiler to map to the ISA used by the behavioral model
- Abstraction from ISA to intermediate representation
- Given the parameters passed to each process, the capabilities of the functional units, and the network to interconnect them, perhaps performance number could be estimated from an intermediate representation instead of having to map/compile it to a specific ISA

## Conclusions

- YAPI (KPN) is very useful for construction of complex architectures
- Flops/Registers are mapped into YAPI channels
- Arrays and combinational logic are mapped into metropolis code in a YAPI process
- Feedback can stabilize the system, and thus ensure finite length channels
- For a given architecture, parameterization of processes can allow easy exploration of the design space
- Encapsulation of an instruction in-flight can minimize the number of channels required, and improve flexibility
- Consistent interfaces across all processes can allow module reuse and the potential for HDL/behavioral co-simulation
- Complex architectures (OOO/Rings/etc..) can easily be constructed and simulated