View
214
Download
0
Category
Tags:
Preview:
Citation preview
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/
Recommended