Final Project Presentation

1
Final Project Presentation

• Viral Infection
• Group 8
• Anya Castillo, Adam Hartman,
• Shambhavi Patel, Colby Ranger

2
Design Goals

• Use-case The design is meant to be used for
  situations in which human presence is not
  desirable and where there may be limited
  communications bandwidth
• Example a biohazard exposure site

3
System Description

• Integration of DSP, ARM, Nios, AVR, and Compact
  FLASH memory to prototype a system-on-a-chip
  design
• Analog to digital conversion, pre-processing of
  data, BLASTP algorithm, database access, and
  alert system broken down into functions which
  could be implemented on programmable components
  and custom hardware

4
Customizations

• Compact FLASH memory for database access
• Network interface for database updates, remote
  access control, and viewing of final results
• Local display of alert messages and status on the
  terminal
• Modified string matching function
  (Knuth-Morris-Pratt) for use in BLASTP algorithm

5
Dataflow
BLASTP
DSP demodulation
ARM processing
3 bits nucleotide sequence
Analog signal gene sequence
16 bits AA sequence
8 bits protein sequences
Nios processing
FLASH database
Data Dangerous Virus
Web Server remote alert
AVR local alert
6
Final Architecture Overview

• DSP performs genetic sequence signal demodulation
  from DaqGen
• Nucleotide to amino acid conversation and find
  neighbor words running on ARM to compensate for
  space limit on DSP and to lighten load of Nios
• Knuth-Morris-Pratt search algorithm used to find
  word hits via a finite state machine implemented
  in customized hardware

7
Final Architecture Overview

• Extend hits, find best match, and remote
  alert system running on a 32-bit Nios processor
  core
• Remote alert system implemented as a TCP/IP web
  server enables control and viewable results via
  the Internet
• Database stored on Compact FLASH memory with
  updates available via the Internet

8
Architectural Design
ARM
1-bit ARM control
DSP
AA Sequence
1-bit DSP control
Signal Processing
Find Neighbor Words
3-bit DSP data
16-bit data
1-bit ARM control
1-bit NIOS control
1-bit NIOS control
AVR
NIOS
1-bit AVR control
Find Word Hits Custom Hardware
Terminal Display
4-bit data
Extend Hits
2-bit FLASH control
32-bit Processor Core
Find Best Match
FLASH
4-bit NIOS control
Database Manager
Database
8-bit data
Server
9
Architectural Changes

• Nucleotide to amino acid conversion moved from
  DSP to ARM
• Encountered memory problems on the DSP
• Nios memory restrictions forced use of 32-bit
  core
• TCP/IP server code and extend hits code were
  too large to be placed on a 16-bit core complier
  warned that space on core would be exceeded by
  program size
• Use of a single Nios core for instead of separate
  cores for the server and the extend hits code
• Currently unsure of the procedure required to
  upload a different programs to different cores
• Not a major problem since each part can block the
  other

10
Nios Memory - Not So Memorable

• char aa_str_inMAX_AA_STR_LEN
• //Other Declarations
• printf("08x\n",aa_str_in)
• while(1)
• printf("08x\n",aa_str_in)
• / Commented Out Code /
• printf("08x\n",aa_str_in)
• printf("Waiting For AA Data From ARM.\r\n")
• aa_len rx_arm_str(aa_str_in)
• printf("Got AA String(d)(s)\n",aa_len,aa_str
  _in)

0x00007ea0
Got AA String (5)()
11
include ltimportantstuff.hgt

• Porting code to programmable parts is not
  necessarily as simple as it may seem
• Why does gcc make something useful and not the
  other compilers?
• Certain functions are handled in different (or
  buggy) ways by different parts
• memory allocation, printf formatting, string
  functions
• Accurate configuration/setup commands and proper
  headers are vital to getting a part to have the
  correct functionality
• defaultconf(), excalibur.h

12
Shambhavi

• Started off with what I thought would be the hard
  part designing the filters
• Tested our board to make sure it read in, stored,
  and outputted correct data
• From there everything just took longer than we
  expected it too
• When to start sampling, filtering, etc.
• Took a while to get used to debugger
• Lesson working with new hardware is difficult
  and time consuming but possible

13
Anyas Corner

• Dont get discouraged when presented with
  problems
• When facing an unfamiliar technology, there is a
  lot that may be learnt from one another and a
  collaborative effort
• Learning through project experience can be a very
  rewarding feeling
• DSP is a powerful tool

14
Evaluation and Performance

• Performance
• Given about 150 neighbor words
• Approximately 5 minutes to scan the 2MB database
• Approximately 20 minutes to scan the 4MB database
• Not a linear scale due to the increased number of
  fetches from the Compact FLASH
• Design Goals vs. Final Product
• Correct findings viewable from a remote location
  via the Internet while still providing
  terminal/local notification
• Ability to compare query against entire database
  without requiring an update from the main
  database, but allow updates from the system to
  the database if requested

15
SoC Design

• Weaknesses
• No comprehensive SoC simulator
• Some development environments are not user
  friendly
• Strengths
• Reuse of proven parts
• Ability of a single chip to perform complex
  procedures
• What we have learned
• Breadboards are not made for SoC prototyping
• Something can always go wrong in communication
  (Whisper Down the Line Syndrome)
• The DSP is temperamental

16
Group Dynamics

• Difficult to work on a project when there is
  limited workspace and resources
• Matching skill sets with to-be-completed tasks
  was a challenge
• Group debugging was helpful
• Gained useful real-world experience

17
Group Dynamics

• Deadlines motivate a group
• Lots of late nights the day before demo is due
• Take out aggression on computer rather than your
  team
• Team communication is key to overall success

18
Questions?(Cmon, two presentations and we still
havent had one)