1 / 18

Damper board (redux) SHARC overview

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

kaiyo
Download Presentation

Damper board (redux) SHARC overview

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Damper board (redux) SHARC overview Bill A. May 17, 2004

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

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

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

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

  6. Python scripts • Updating firmware, software, network numbers from nova, etc. • Converting SHARC compiler output

  7. Remote firmware update rewrite_stratix.py sends Quartus .TTF file into FRAM …/sharc/scripts/*.py in CVS

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

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

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

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

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

  13. Updating network numbers (DANGER!) rewrite_id.py

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

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

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

  17. 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?

More Related