1 / 15

FPGA and DSP Infrastructure for Supervisory Communications: Implications and Applications

This paper explores the implementation of FPGA and DSP technologies in supervisory communications infrastructure, focusing on control functions, monitoring, and control influence. The study discusses hardware and software status, data histogramming, error handling, and more.

margaretwoods
Download Presentation

FPGA and DSP Infrastructure for Supervisory Communications: Implications and Applications

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. DSP + FPGA Supervisory Communications Infrastructure with possible implications/applications 22 Aug 2001 M. Haney, University of Illinois

  2. Muon Preprocessor Pixel Preprocessor(FPGAs) Segment Preprocessor Segment Preprocessor(FPGAs) Detector Front End Board (DCB) Others... 1 Highway MTSM L1Buf PTSMRegionalControlandMonitoring L1Buf (raw) L1Buf (cooked) Crossing Switch /c/spot Muon DSP Farm BTeV Run Control L1Buf (basis) L1Buf (basis) Pixel DSP Farm(combined track+vertex) L1Buf (basis) L1Buf (details) Opinions GLSM L1Buf (basis) GL1 L1Buf (details) Accept/Reject Decisions Resource Mgr Requested/AssignedCrossing data L2/L3(Linux Farm) m-haney@uiuc.edu 22aug01

  3. Pixel (Muon) Trigger Supervisor Monitor (P/M)TSM • Control Functions: • Initialization • sets the maximum bandwidth necessary • can not take all day... • Command Parsing and Distribution • to subordinates, from RunControl • Error Response • autonomous, “local” (regional) • not to be confused with higher-level driven Error Handling, which appear as “Commands” m-haney@uiuc.edu 22aug01

  4. (P/M)TSM (continued) • Monitor Functions • Error Message Collection and Reporting • organized, formatted, sent higher up • Hardware and Software Status • not unlike Error Messages... • Status and Data Histogramming • utilizes remaining (P/M)TSM system bandwidth m-haney@uiuc.edu 22aug01

  5. Close-up: FPGA EtherNet,for example Preprocessorfor example... BTeV Run Controland database(s), etc. MonitoringAwareness _TSMRegional Controland Monitoring FPGA _TSMLocal Controland Monitoring Local Config(Flash) ARCNet,for example FPGA ControlInfluence JTAG,programming and debug /c/spot run StandaloneOperationalCapability Regional copyof config data,and history Power, Cooling Monitoringand Control Fire Detect m-haney@uiuc.edu 22aug01

  6. Close-up: DSP EtherNet,for example DSP BTeV Run Controland database(s), etc. MonitoringAwareness _TSMRegional Controland Monitoring FPGA _TSMLocal Controland Monitoring Local Config(Flash) ARCNet,for example DMAin Host PortInterface DSP BSPout ControlInfluence JTAG,programming,debug, and monitoring run(spot); run; StandaloneOperationalCapability Regional copyof config data,and history Power, Cooling Monitoringand Control Fire Detect m-haney@uiuc.edu 22aug01

  7. Factoids • ARCNet • 2.5 Mbps, 255 nodes (max), 500 byte packets (max), broadcast capability, “easy” • TMS320C67x DSP • ~70 Kbyte internal RAM, ~1200 MIP • fixed/floating point • TMS320C64x DSP • ~1 Mbyte internal RAM, ~3x faster… • fixed point only m-haney@uiuc.edu 22aug01

  8. More Factoids • Host Port Interface (TI DSP only) • almost-direct access into the DSP • peek, poke • uses DMA (like) resources… • (concept not unique to TI) • DMA • crossing data in • Buffered Serial Port(s) • opinions out; dual, ~75Mbps (C6x) m-haney@uiuc.edu 22aug01

  9. DSP/BIOS (Texas Instruments) • based on SPOX • “the oldest DSP RTOS…” • scalable real-time kernel • small footprint (< 2Kw) • preemptive multithreading • scheduling (tasks, soft/hard interrupts) • synchronization (between tasks, interrupts) • hardware abstraction • extensible m-haney@uiuc.edu 22aug01

  10. DSP/BIOS (continued) • real-time analysis • real-time instrumentation • explicit API calls • (controllably) implicit, at context changes • host-target communications • statistics gathering • same as above • host data channels • binds kernel I/O objects to host files m-haney@uiuc.edu 22aug01

  11. RTDX - Real Time Data Exchange • utilizes JTAG chain (and emulation bits) • target (kernel) component • moves messages to/from DSP/BIOS queues from/to JTAG-accessible buffer • “real time” target to host (?) • host component • data visualization and analysis tools • data to target “not” real-time… (?) m-haney@uiuc.edu 22aug01

  12. RTDX (continued) • fundamental (TI) model • one PC running CCS (or app with CCS API calls) • small number (4’ish) of DSPs on one JTAG chain • JTAG/emulator “pod” connects PC to chain • (2 “extra” emulation bits, in addition to TDI/TDO/TMS/TCLK) • BTeV challenge • not buying 500 PC’s to support 2000 DSPs… m-haney@uiuc.edu 22aug01

  13. ITR (App/Imp)lications • FPGA JTAG chain • (available; role?) • FPGA local _TSM • local VLA comm channel • DSP/BIOS • RTOS for ARMORs? • Implicit monitoring and stat collection • explicit API calls as VLAs? • we have the source code; we can tailor our own… m-haney@uiuc.edu 22aug01

  14. ITR (continued) • RTDX, DSP JTAG chain • VLA(+ARMOR?) comm channel • DSP local _TSM • local manager (ARMORs!) • central _TSM node • regional manager (ARMORs) • RunControl • global manager & experiment interface m-haney@uiuc.edu 22aug01

  15. end m-haney@uiuc.edu 22aug01

More Related