# Presentation: 069425

## Damper board (redux) SHARC overview

- Bill A.
- May 17, 2004

## What is a SHARC?

- Analog Devices 21065L processor
- Typically used for (audio) digital signal processing
- 64KB (!) RAM, 32-bit floating point (extended 40-bit too), SDRAM interface, serial ports, DMA, 24-bit addr, 32-bit data external busses; we run at 50MHz
- In-circuit emulator for d/l, single-step, etc.
- Real men (e.g. Brian Chase’s group) code in assembly; I was lazy and used C

## SHARC’s role on damper board

- Initialize Stratix from FRAM on power-up
- Interface board to world via TCP/IP
- Includes remote firmware/software update
- Read/write Stratix “bus” registers, so that damper processing can be controlled and monitored via network
- Read FIFOs (written by Stratix), to allow high-volume DAQ during damper operation

## Telnet to port 128 (or to stripped-down version on port 100); read or write registers in Stratix chip

## Reading/writing Stratix “bus” registers

- Simple text command line interface allows network client to read and write values
- RD addr
- WR addr value
- SHARC decodes commands, jiggles serial line to Stratix, watches Stratix jiggle back, writes out answer on TCP socket
- ACnet OAC (Dennis) essentially logs in and types these same commands
- There is also a binary multi-word read protocol, for somewhat improved speed

## Slide 6

## Python scripts

- Updating firmware, software, network numbers from nova, etc.
- Converting SHARC compiler output

## Remote firmware update

- rewrite_stratix.py sends Quartus .TTF file into FRAM

- .../sharc/scripts/*.py in CVS

## Remote firmware update

- rewrite_stratix.py sends Quartus .TTF file into FRAM

- .../sharc/scripts/*.py in CVS

- With only minor coercion, Quartus outputs .TTF file automatically upon compilation

- Bill F uses same python script from windoze, no problem

## Remote SHARC software update: chicken=1

- SHARC compiler excretes .../sharc/damper_control/Debug/damper_control.ldr
- run parseldr.py
- reads damper_control.ldr
- hacks boot-loader data for subset of program memory that executes from external SDRAM (recall that internal SRAM is 64KB)
- writes boot_b.ldr
- rewrite_b.py writes boot_b.ldr to FRAM
- python reboot.py damprN 1  runs prog “b”
- power cycle (or watchdog) runs stored “a”

## Remote SHARC software update: chicken=0

- Copy boot_b.ldr to boot_a.ldr
- rewrite_a.py writes boot_a.ldr to FRAM
- python reboot.py damprN  runs prog “a”
- power cycle (or watchdog) runs prog “a”
- if prog “a” is screwed up, you have to plug in the in-circuit emulator to fix it

## Rebooting

- reboot.py simply does ‘write 0 1’
- note ‘write’ not ‘wr’
- ‘write’ and ‘read’ affect SHARC address space
- ‘wr’ and ‘rd’ affect Stratix ‘bus’ address space
- bit 0 of address 0 initiates a CPU reset
- to boot prog ‘b’, reboot.py first does a ‘write 8100 deadbeef’
- boot loader has been hacked to set address bit 16 if this value is detected at 8100
- boots from ‘secondary’ bank of FRAM

## FRAM address map

- 0x000000 = SHARC program “A” (0.4MB)
- 0x070000 = network ID numbers (19 bytes)
- 0x080000 = SHARC program “B” (0.4MB)
- 0x100000 = Stratix code (1MB)
- FRAM base addr = 0x1000000 in SHARC memory map (“external” block 1)

## Updating network numbers (DANGER!)

- rewrite_id.py

## Rest of outline

- SHARC & connected components
- Bootstrapping hijinks
- FRAM contents
- Compiling & updating the damper_control SHARC program
- SHARC source code tree
- Main.c
- App_v0.c
- Where to find SHARC info

## Features needed soon

- Ability to lock out the OAC from connecting during FRAM updates.
- Maybe “locked” mode only allows connections from one particular IP address, specified on command line.
- Fake fast time plots.
- To FTP a specific Stratix “bus” address at 720 (?) Hz, this is probably easy to implement.
- Need to know when to start/stop, whether to repeat, when to send data out, etc.
- Maybe have a list of up to 10 (?) bus addresses for which FTP is actively gathering data, under OAC’s control.

## Worries

- Too much home-made code to maintain?
- Maybe it’s not so bad?
- Network throughput of uIP package is limited by lack of pipelining
- advertised TCP “window” only 1 packet deep
- consider upgrading to Adam Dunkels’s other (more performant) package, lwIP?
- Would be nice to be able to use a free compiler, e.g. gcc.
- SHARC compiler licensing is a pain.

## Hardware worries/wishes

- If FRAM gets corrupted, need APEX-ICE, VisualDSP++, etc. to re-load image.  Ouch.
- Simple RS232 to SHARC (& Stratix?) would speed up initial check-out.  Also easier to set network ID numbers that way.
- Test header for connecting Stratix to HP logic analyzer, for tough debugging.
- If MAX chip had a few lines to the Stratix and a few SHARC data lines, it could do more interesting things.  MAX chip plays a special role, as it is non-volatile.
- As many signals as possible (except ultra-high-speed) should go through an FPGA, for debugging, re-gluing, etc.
- Memory-mapped Stratix access on SHARC external bus?