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

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 0x = SHARC program “A” (0.4MB) 0x = network ID numbers (19 bytes) 0x = SHARC program “B” (0.4MB) 0x = Stratix code (1MB) FRAM base addr = 0x 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?