1. CS 499 Final Presentation
Aaron Drake - Project Manager/Lead Documenter
Dale Mansholt - Lead Designer
Jon Scruggs - Lead Analyst/Lead Tester
Travis Svehla - Lead Programmer

2. 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

3. 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

4. Janus Project Overview

5. Clients’ Problem Our clients’ problem Our solution:
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.)

6. Our Organization Plan Dr. Ehlmann Upper Management
Cris, Adam, and Phil
Clients
Upper Management
Clients
Aaron
Project Manager
Phase Leader
Dale starts here
Dale
Team Member
Jon
Team Member
Travis
Team Member
Team Member
Team Member
Team Member

7. Our Organization Plan Our team was divided into two sub-teams:
Assembler Sub-Team
Aaron (Manager)
Travis
Emulator Sub-Team
Dale (Manager)
Jon

8. 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

9. 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

10. 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

11. System Requirements
The output from the assembler must run on the emulator
Assembler & emulator must both run on Windows 2000

12. Development Lifecycle
Design-to-Schedule

13. 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.

14. Timeline – Spring Semester
Aaron starts here

15. 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

16. Assembler Overview Three-pass assembler Pass one Pass two Pass three
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

17. 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 
#User’s Program
ldi $1, 0x1
ldi $2, 0x2
ldi $3, 0x3
addr $4, $1, $2
subr $4, $4, $3 
ldi $1, 0x1
ldi $2, 0x2
ldi $3, 0x3
nop
addr $4, $1, $2
subr $4, $4, $3     
sample.as
sample.as  
sample.sas
sample.bin

18. 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 (3 bit)
s1 (3 bit)
s2 (3 bit)
Unused (9 bit)
Opcode (6 bit)
dr (2 bit)
Immediate or absolute value (16 bit)
Opcode (6 bit)
dr (2 bit)
a1 (8 bit)
a2 (8 bit)

19. 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

20. 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

21. Assembler Design

22. Emulator Design Emulator Driver Emulator Subsystem Pipeline Crossbar
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

23. Emulator Design Instruction Instruction Memory Data
“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

24. Emulator Design Data Memory Register General Purpose 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

25. Janus Processor Design
I/O Registers
GP Memory
Inst A
Cross Bar
Pipeline A
Data 0, A
Data 1, A
Inst B
Pipeline B
Data 0, B
Data 1, B

26. Janus Pipeline Design Seven stage pipeline General Purpose Memory
Fetch
Decode
Register
Fetch/
Data
Fetch
Memory
Fetch
Execute 1
Execute 2
Commit/
Store
Register File/Data Memory

27. Emulator Subsystem

28. Demonstration User assembly program file Assembler
Second assembly program source file
Binary program file
Emulator

29. Testing Levels of testing: Module Testing Integration Testing
System Testing
Acceptance Testing
Site Testing

30. Module Testing Ensure module does what it should
Check if the functions work
Create test interface with added features

31. Integration Testing Check to see if functions are called correctly
Create a test interface

32. System Testing Make sure functions work together correctly
Test the user interface
User interface can be used to test the whole system

33. 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

34. Site Testing
The binary file created by the assembler works with the emulator
The assembler and emulator run on Microsoft Windows 2000

35. 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.

36. Deployment & Training For our system’s users, we have created:
A reference manual for the Janus assembler language
An operations guide for the emulator

37. 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!

38. Questions? Our Website: Our Clients’ Website:
Our Clients’ Website: