Transcript Testing

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
Dr. Ehlmann
Upper Management
Cris, Adam, and Phil
Clients
Upper Management
Aaron
Project Manager
Dale
Team Member
Jon
Team Member
Clients
Phase Leader
Travis
Team Member
Team Member
Team Member
Team Member
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
An Example:
First Pass
Second Pass
Third Pass



#User’s Program
ldi $1, 0x1
ldi $2, 0x2
ldi $3, 0x3
addr $4, $1, $2
subr $4, $4, $3
sample.as


#User’s Program
ldi $1, 0x1
ldi $2, 0x2
ldi $3, 0x3
addr $4, $1, $2
subr $4, $4, $3

sample.as

ldi $1, 0x1
ldi $2, 0x2
ldi $3, 0x3
nop
nop
nop
addr $4, $1, $2
nop
nop
nop
nop
subr $4, $4, $3
sample.sas


001110010000000000000001
001110100000000000000010
001111100000000000000011
000000000000000000000000
000000000000000000000000
000000000000000000000000
000001100001010000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000000000000000000000000
000010100100011000000000
sample.bin
Assembler Design Details
• Three operand formats for Janus instruction as designed
by our clients:
– Basic register reference format
Opcode (6 bit)
dr (3 bit)
s1 (3 bit)
s2 (3 bit)
Unused (9 bit)
– Absolute memory reference
Opcode (6 bit)
dr (2 bit)
Immediate or absolute value (16 bit)
– Immediate address of DSP-level instructions
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
GP Memory
I/O Registers
Inst A
Pipeline A
Data 0, A
Data 1, A
Cross Bar
Inst B
Pipeline B
Data 0, B
Data 1, B
Janus Pipeline Design
• Seven stage pipeline
General Purpose Memory
Fetch
Decode
Register
Fetch/
Data
Fetch
Memory
Fetch
Register File/Data Memory
Execute
1
Execute
2
Commit/
Store
Emulator Subsystem
HeapType
EmulatorDriver
IoTools
1
1
int Language
Uses
1
1
Stores heap
data in
HeapNode
0...*
1
1
MinHeap
Builds
tree with
Memory
1
Get commands
from
Interface to
1
0...*
1
EmulatorSubsystem
Store data
in
Reg
1
Access memory
with
1
0...*
Stores
data to
1
0...*
1
Token
1
1
Store
Token to
Executes instructions
with
1
MemoryCrossbar
1
2
InstructionMemory
Instruction
cells
GeneralPurposeMemory
1
4
DataMemory
Data cells
InstructionMemory
Scanner
1
Reg
Register
cells
0...*
1
2
1
DataMemory
1
Gets token
from
Register
file
8
1
1
Stores
1
intructions
to
Stores GP
1
items
1
2
GeneralPurposeMemory
Access
Mem
with
2
Pipeline
GP cells
Perfoms the
logarithmic
operations
1
LogOps
1
1
1
7
pcArray
Holds PC
value
7-Stage
pipeline
7
instArray
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/