Incell Phonium Processor

CS 499 Final Presentation

Aaron Drake - Project Manager/Lead Documenter

Dale Mansholt - Lead Designer

Jon Scruggs - Lead Analyst/Lead Tester

Travis Svehla - Lead Programmer

Presentation Overview

• Overview of Our Clients’ Project: The Janus Processor• Overview of Our Project

– Team Organization– Project Plan– Project Design– Implementation and Technical Details– Demonstration – Testing– Deployment Training– Retrospective Thoughts

• Question and Answer Session

Janus Processor Overview

• Our clients– An ECE senior project team:

• Phillip Ness, Adam Sloan, and Chris Wade

– Creating a new digital signal processor (DSP) called the Janus Processor, which will be:

• A logarithmic DSP• Targeted for use in cell phones

Janus Project Overview

Clients’ Problem

• Our clients’ problem– No tools to create/test programs for their processor

• Our solution:– Created the following:

• An assembler to convert Janus assembly code to machine code

• An emulator to emulate the theoretical operation of the Janus Processor

• If time permitted, an integrated environment to combine the assembler and emulator into one graphical interface (We chose not to implement this component this semester.)

Our Organization Plan

Phase Leader

Team Member Team Member Team Member

Upper Management Clients

AaronProject Manager

DaleTeam Member

JonTeam Member

TravisTeam Member

Dr. EhlmannUpper Management

Cris, Adam, and PhilClients

Our Organization Plan

• Our team was divided into two sub-teams:– Assembler Sub-Team

• Aaron (Manager)• Travis

– Emulator Sub-Team• Dale (Manager)• Jon

Users & Analysis of User Needs

• The users of our systems are:– Our clients– Writers of Janus assembly programs– Testers of Janus assembly programs

• Analysis of User Needs– Interviews with our clients– Interviews with professors

• Dr. Engel, Dr. Noble, and Dr. Fujinoki

System Requirements

• Assembler requirements– Check user’s program for the following types of syntactical

errors:• Mnemonic (e.g. add instead of addr)

• Parameter (e.g. addr X, $3, $4 instead of addr $1, $3, $4)

– Check user’s program for the following semantic errors:• Label errors (e.g. Branch to a label that doesn’t exist)

• Symbol errors (e.g. Use a variable that doesn’t exist)

– Insert “no-op” instructions as necessary to remove data dependencies from the user’s program

– Translate user’s assembly code into machine code and store it to a file

– However, does not need to optimize assembly program

System Requirements

• Emulator requirements– Must emulate the following:

• Both seven-stage pipelines• Crossbar• Registers• Memories (i.e. data, instruction, general purpose)

– Execute instructions like the Janus Processor– Show contents of registers and memories– Count clock cycles as instructions are executed– Allow the user to test and step through code

System Requirements

• The output from the assembler must run on the emulator

• Assembler & emulator must both run on Windows 2000

Development Lifecycle

Design-to-Schedule

Development Lifecycle

• Why Design-to-Schedule?– We had an immovable deadline – the end of the

spring semester– Design-to-schedule prioritizes features by necessity.

• In case the project wasn’t done at the end of the semester, only low-priority features were not implemented (i.e. the integrated environment)

– Downside: wasted time spent designing• But this is acceptable. Future senior project teams may use

our unfinished designs to expand upon our project.

Timeline – Spring Semester

Development Tools

• Microsoft Visual C++ 7.0 for coding• Microsoft Windows 2000 for testing applications• Microsoft Word for creating documents• Microsoft PowerPoint for creating presentation

slides

Assembler Overview

• Three-pass assembler– Pass one

• Reads in user’s assembly program from file named with “.as” extension and checks for syntactical errors

• Ignores comments– Pass two

• Removes data dependencies by inserting “nop” instructions and inserts comments indicating which instructions caused a data dependency, and also strips out user comments

• Saves changes to a new file named with “.sas” extension– Pass three

• Looks at file named with “.sas” extension• Checks for jump instruction semantic errors• Converts assembly code into machine code• Saves machine code to a new file with a “.bin” extension

Assembler Overview

ldi $1, 0x1

ldi $2, 0x2

ldi $3, 0x3

nop

nop

nop

addr $4, $1, $2

nop

nop

nop

nop

subr $4, $4, $3

001110010000000000000001

001110100000000000000010

001111100000000000000011

000000000000000000000000

000000000000000000000000

000000000000000000000000

000001100001010000000000

000000000000000000000000

000000000000000000000000

000000000000000000000000

000000000000000000000000

000010100100011000000000

#User’s Program

ldi $1, 0x1

ldi $2, 0x2

ldi $3, 0x3

addr $4, $1, $2

subr $4, $4, $3

#User’s Program

ldi $1, 0x1

ldi $2, 0x2

ldi $3, 0x3

addr $4, $1, $2

subr $4, $4, $3

First Pass Second Pass

Third Pass

An Example:

sample.as sample.as

sample.sas sample.bin

Assembler Design Details

• Three operand formats for Janus instruction as designed by our clients:

– Basic register reference format

– Absolute memory reference

– Immediate address of DSP-level instructions

Opcode (6 bit) dr (2 bit) Immediate or absolute value (16 bit)

Opcode (6 bit) dr (3 bit) s1 (3 bit) s2 (3 bit) Unused (9 bit)

Opcode (6 bit) dr (2 bit) a1 (8 bit) a2 (8 bit)

Assembler Design Details

• Instruction Table– Text file containing information corresponding to each

mnemonic

• Dependency Table– One-dimensional array of N elements– Contains fields for the symbol of the registers

• Scanner– Reads text files into memory

Assembler Design Details

• Jump Table– Variable size– Contains the addresses of the first instruction after

each label in the assembly file

• Symbol Table– Variables– Constants

Assembler Design

Emulator Design

• Emulator Driver– Command line interface

• Emulator Subsystem– Set up and coordinate the emulation process

• Pipeline– There are two pipelines– Each pipeline executes instructions– Each pipeline has seven stages defined by the ECE

team

• Crossbar– Provides access to: Instruction, Data, and General

Purpose Memory

Emulator Design

• Instruction– “Tells” the pipeline what to do– Stored in the instruction memory– Have an Operation Code (opcode) and operands

• Instruction Memory– One instruction memory per pipeline– Used to store instructions

• Data– Information that is stored– Stored in registers and/or main memory

Emulator Design

• Data Memory– Two data memories per pipeline– Storage for variables

• Register– Used by pipelines to read and store data– Most ALU operations are performed on registers

• General Purpose Memory– Used to store just about anything

Janus Processor Design

Cross Bar

Inst B

Data 0, B

GP Memory

Data 1, A

Inst A

Data 0, A

Data 1, B

Pipeline A

Pipeline B

I/O Registers

Janus Pipeline Design

• Seven stage pipeline

FetchDecod

e

Register

Fetch/DataFetch

MemoryFetch

Execute1

Execute2

Commit/

Store

General Purpose Memory

Register File/Data Memory

Emulator Subsystem

Em u la to rD riv e r I o To o ls

Em u la to rS u bs y s te m To k e n

in t L a n g u a g e

S ca n n e r

H e a pTy pe

H e a pNo de M in H e a p

G e n e ra lPu rpo s e M e m o ry

I n s tru ct io n M e m o ry

D a ta M e m o ry

M e m o ry C ro s s ba r

D a ta M e m o ry

I n s tru ct io n M e m o ry

G e n e ra lPu rpo s e M e m o ry

R e g

R e gM e m o ry

Pipe lin e

in s tA rra ypcA rra yL o g O ps

11

1

1

Us es

I n te r f ac e to

10 . . .*10 . . .*

1

1

S to r e d a tain

Bu ild str ee w ith

S to r es h eapd ata in

1 1

G ets to k enf r o m

1

1

G et c o m m an d sf r o m

11

S to r eT o k en to

1

2

R eg is te rf ile

18

R eg is te rc e lls

1

1

1

0 . . .*

0 . . .*

0 . . .*

D ata c e lls

I n s tr u c tio nc ells

G P c e lls

1

4

12

1

1

1

1S to r esd ata to

S to r esin tr u c tio n sto

S to r es G Pitem s

Ac c es s m em o r yw ith

1

2

Ex ec u tes in s tr u c tio n sw ith

1

7

1

2

Ac c es sM emw ith

7 - S tag ep ip elin e

1

7Ho ld s P Cv alu e

1

1

P er f o m s th elo g ar ith m ico p er a tio n s

Demonstration

• User assembly program file• Assembler • Second assembly program source file• Binary program file• Emulator

Testing

• Levels of testing:– Module Testing– Integration Testing– System Testing– Acceptance Testing– Site Testing

Module Testing

• Ensure module does what it should• Check if the functions work• Create test interface with added features

Integration Testing

• Check to see if functions are called correctly• Create a test interface

System Testing

• Make sure functions work together correctly• Test the user interface• User interface can be used to test the whole

system

Acceptance Testing

• This test is done after completion of each of the three previous tests– Specs may have changed– Could find flaws in clients’ ideas

• Easier to change the programs at the Module Testing level

• Clients can easily see if the system is performing as expected

Site Testing

• The binary file created by the assembler works with the emulator

• The assembler and emulator run on Microsoft Windows 2000

Deployment & Training

• Installation Plan:– We did not install any of the software on the clients’

computers.– Compiled binaries and source code are available on

our project web site.– Full documentation of the software is provided.– Installation is easy: just make sure all the files are in

the same directory.

Deployment & Training

• For our system’s users, we have created:– A reference manual for the Janus assembler

language– An operations guide for the emulator

Retrospective Thoughts

• We should have had better version control• Dividing into sub-teams worked well• Our lifecycle model worked well: We did not

implement integrated environment, but this was acceptable

• We learned a lot about software development & low level system design

• Designing assemblers and emulators is no easy feat!

Questions?

• Our Website:– http://solar.cs.siue.edu/incel/

• Our Clients’ Website:– http://www.siue.edu/~pness/janus/