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

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

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 Aaron starts here

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

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 001110010000000000000001 001110100000000000000010 001111100000000000000011 000000000000000000000000 000001100001010000000000 000010100100011000000000      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 (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)

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

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

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

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

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

Emulator Subsystem

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: Our Clients’ Website: http://solar.cs.siue.edu/incel/ Our Clients’ Website: http://www.siue.edu/~pness/janus/